LabView exists.

General discussion about COSA and its consequences.

LabView exists.

Postby hcsik » Sun Apr 04, 2010 1:01 pm

Nice concepts.
Alas, not as new as one would have liked to believe.

http://www.ni.com/labview/whatis/

Every proposed COSA feature you find realized in LabView:
"Change-Driven", "causality", and "temporal consistency" (a.k.a dataflow semantics),
"passive and active objects", "cells and components" (called "virtual instruments" with input and output connectors),
"visual software construction", "total overview", and "programming by design" (draw connection diagrams to code).
They seem to offer free time-limited evaluation copies for download; you should really try it out; I guess you'll love it.

LabView saw its first release in 1986.
Nowadays you can purchase specialised hardware with CPU boards dedicated to the parallel code, which don't run a standard OS, but a realtime kernel optimised for the purpose (this should count as a realisation of the proposed "CODA OS").
Nowadays they even offer an FPGA development board to optimally exploit the parallelism of the components you design. http://www.ni.com/fpga/

Sadly, however, LabView didn't apparently succeed in solving all the software reliability problems.

Even though the diagrams look nice and simple (when you start...), and it's easy to design simple applications, in the end it turns out that the concepts of LabView (and consequently COSA) tend to lead to even more complex software solutions then the equivalent typical text-based computer languages (which you would call "algorithmic").

Besides, the graphical representation tends to really get in your way with everyday practical software engineering necessities like version control, merging, or simply navigating through a huge code base (you can't easily "grep" for graphical symbols). The development model doesn't scale to large teams, the typical LabView app is a one-man show.
LabView is quite successful in its commercial niche of measurement, production, and test automation, but it's a niche nevertheless.

Ironically, I've personally experienced that the developers which most fervently detest LabView and schematic entry tools
are exactly the FPGA guys who would know best how to do parallelism. They swear by their purely textual VHDL development environments.
hcsik
 
Posts: 1
Joined: Sun Apr 04, 2010 10:45 am

Re: LabView exists.

Postby sixwings » Sun Apr 04, 2010 4:56 pm

hcsik wrote:Nice concepts.
Alas, not as new as one would have liked to believe.

http://www.ni.com/labview/whatis/

Every proposed COSA feature you find realized in LabView:
"Change-Driven", "causality", and "temporal consistency" (a.k.a dataflow semantics),
"passive and active objects", "cells and components" (called "virtual instruments" with input and output connectors),
"visual software construction", "total overview", and "programming by design" (draw connection diagrams to code).
They seem to offer free time-limited evaluation copies for download; you should really try it out; I guess you'll love it.

LabView saw its first release in 1986.
Nowadays you can purchase specialised hardware with CPU boards dedicated to the parallel code, which don't run a standard OS, but a realtime kernel optimised for the purpose (this should count as a realisation of the proposed "CODA OS").
Nowadays they even offer an FPGA development board to optimally exploit the parallelism of the components you design. http://www.ni.com/fpga/

Believe me, I have heard this many times before. You are mistaken. Here are some fundamental differences between COSA and LabView:

Not Dataflow

COSA is not a dataflow language. The idea of data flowing like a stream from one component to another is not a fundamental aspect of COSA. COSA does have reactive data connectors but they are not used for dataflow in the LabView sense. A COSA program consists of actors (sensors and effectors) and the environment (data). That's pretty much it.

Fine-grained Parallelism

My understanding is that LabView is a high-level coarse-grained dataflow language that propagates variables or data structures from one so-called 'virtual instrument' (a code subroutine or algorithm) to another. COSA, by contrast, is a fully reactive, non-algorithmic, execution and programming environment for fine-grained parallelism. COSA is a software model that redefines the way we build and program our computers. The fine-grained, instruction-level parallelism of COSA is the reason that a COSA program will run slow on existing processors. COSA will require special processors specifically designed and optimized for this sort of processing. LabView seems to run fine on current machines because it is not a new software model. A COSA processor is a pure vector processor and will have no trouble handling any kind of high throughput parallel processing, including the kind of graphic processing now being done by GPUs.

Control Hierarchy and Complementarity

COSA has control concepts like sensor/effector associations, self-activated effectors, motor and sensor coordination principles and hierarchical composition; none of which exists in LabView. A component in COSA is either a supervisor or a slave, a concept that is analogous, at the lowest level, to sensors and effectors. Complementarity is a fundamental aspect of COSA.

Timing and Temporal Determinism

Timing is also a fundamental aspect of COSA, so much so that there are no logic gates in the traditional Boolean sense. The logic detectors in COSA are strictly timed, meaning that they are signal-based as opposed to being state-based. In COSA, temporal determinism is an absolute must. This is the reason that COSA programs, unlike Labview programs, cannot use multithreading since multithreading is non-deterministic by definition. Same goes for existing multicore processors.

As Few Icons as Possible

One of the things that I don't like about LabView is the proliferation of icons. COSA uses as few icons as possible: the connection line, the sensor, the effector, the synapse, the data icon, the component and the component connector. That's it.

Image

Hierarchical Composition

Sadly, however, LabView didn't apparently succeed in solving all the software reliability problems.
Even though the diagrams look nice and simple (when you start...), and it's easy to design simple applications, in the end it turns out that the concepts of LabView (and consequently COSA) tend to lead to even more complex software solutions then the equivalent typical text-based computer languages (which you would call "algorithmic").

Besides, the graphical representation tends to really get in your way with everyday practical software engineering necessities like version control, merging, or simply navigating through a huge code base (you can't easily "grep" for graphical symbols). The development model doesn't scale to large teams, the typical LabView app is a one-man show.
LabView is quite successful in its commercial niche of measurement, production, and test automation, but it's a niche nevertheless.

It is because LabView is doing it wrong. They use the wrong compositional approach and too many icons. The COSA compositional tree will solve all the problems that plague LabView. Top to bottom complementarity (master/slave) is the key to effective software composition and large-scale component reuse.

Ironically, I've personally experienced that the developers which most fervently detest LabView and schematic entry tools
are exactly the FPGA guys who would know best how to do parallelism. They swear by their purely textual VHDL development environments.

Again, It is because LabView is doing it wrong. But then again, so is FPGA. All that stuff will eventually be supplanted.
Louis Savain
sixwings
Site Admin
 
Posts: 131
Joined: Tue Mar 09, 2010 2:57 am

Re: LabView exists.

Postby harry666t » Mon Apr 05, 2010 5:37 am

@hcsik,

First off, COSA has not been implemented yet. I think the only way to prove that COSA is NOT going to solve the problems (reliability, scalability, productivity, etc) is to actually implement it and show that it does not solve them.

Second, Louis has stated that COSA is not LabView, like, a thousand times? Before you bash the project, learn its history. These "COSA is dataflow" rants are getting boring.

However...

Besides, the graphical representation tends to really get in your way with everyday practical software engineering necessities like version control, merging, or simply navigating through a huge code base (you can't easily "grep" for graphical symbols). The development model doesn't scale to large teams, the typical LabView app is a one-man show.


Excellent points.

User Interface: I believe that we're going to need someone with UI-oriented brain and skills to explore this area. I have a lot UI ideas, but I don't (yet) have the skills to try all of them out. (I think that a variant of Raskin's ZUI concept could work extremely well here.)

Version control: This is going to be hard. We'd probably need to lay out some fundamental theory for branching, merging, diffing, etc of object hierarchies (maybe there's already something like this out there, dunno). Also, this work should benefit the CS community at large; not only COSA programs are object trees.
harry666t
 
Posts: 48
Joined: Thu Mar 11, 2010 7:38 am

Re: LabView exists.

Postby sixwings » Tue Apr 06, 2010 12:20 am

User Interface: I believe that we're going to need someone with UI-oriented brain and skills to explore this area. I have a lot UI ideas, but I don't (yet) have the skills to try all of them out. (I think that a variant of Raskin's ZUI concept could work extremely well here.)

Yeah. In this vein, I am rather excited about the touchscreen interface of the iPad. I think it can be put to excellent use in the COSA 3-D design studio. In truth, I think the user interface will turn out to be the most complex and most challenging aspect of Project COSA, both in terms of application design and the look and feel. It's got to be intuitive, pleasant to look at, personalizable, friendly to use and, above all, fun. Eventually, of course, it should be implemented in pure COSA code. That being said, I envision that, once COSA becomes mainstream, there will be many competing COSA development environments to choose from.

Version control: This is going to be hard. We'd probably need to lay out some fundamental theory for branching, merging, diffing, etc of object hierarchies (maybe there's already something like this out there, dunno). Also, this work should benefit the CS community at large; not only COSA programs are object trees.

Well, I don't think version control will be an exceptionally hard problem in COSA. Essentially, you check out a component for editing, modify it, and put it back in the application branch when you're done. The Version Control software takes care of recording the history of changes, who did what when, who has what and that sort of thing. It's not much harder than what is currently out there.
Louis Savain
sixwings
Site Admin
 
Posts: 131
Joined: Tue Mar 09, 2010 2:57 am

Re: LabView exists.

Postby opticabo » Tue Apr 06, 2010 12:48 am

harry666t wrote:Version control

Louis beat me to it, I just started a version control thread:

viewtopic.php?f=7&t=23
James
opticabo
 
Posts: 45
Joined: Fri Mar 12, 2010 4:24 am

Re: LabView exists.

Postby harry666t » Tue Apr 06, 2010 11:32 pm

I am rather excited about the touchscreen interface of the iPad


There is no way Apple would ever let anyone distribute a development environment running on anything with iPhone OS. But the touch screen interface itself, who knows.

I personally prefer keyboard over pointing devices, and I think it could do pretty well for navigating large programs - some kind of intelligent search-as-you-type. I think that it could also be possible to create a programming language that could be efficiently compiled to COSA (Louis don't kill me! :P).
harry666t
 
Posts: 48
Joined: Thu Mar 11, 2010 7:38 am


Return to Project COSA

Who is online

Users browsing this forum: No registered users and 1 guest

cron