Other Software > Developer's Corner

Blog Post: Manifesto of the Programmer Liberation Front

<< < (2/2)

mouser:
you're right..

hmm, wysiwyg programming.. that seems kind of silly.  doesn't really make sense.

but graphical programming - that is an area of active development and is likely to get more useful and mainstream over time.  there is some interesting research by IBM in this area - i think there is a video demo of a node-based graphical programming environment floating around somewhere.. anyone remember the link?


myself, i use c++ builder a lot (sister of delphi), which i think has done a remarkable job of making visual components and RAD stuff useful and complementary to standard coding.  i think this kind of stuff is likely to grow in popularity and usefulness and show incremental improvement in programming languages.

so i guess i would count myself in the non-revolutionary camp, who believes that areas most ripe for increased efficiency are making reusable components easier to use and more reliable, and easier to interface with.

Rover:
@mouser: agreed
All of the cool RAD stuff you do in C++Builder and Delphi is still described using regular text based OOP.

pao:
When I worked at the Georgia Tech Research Institute as a co-op a few years back, most of my programming was done in LabView, a highly successful graphical dataflow programming environment which tends to be used for real-time data capture and processing, but which is in truth far more flexible.  Similarly, the Aerospace Controls Lab class has 100% of the programming work done in a combination of MATLAB, a conventional procedural language with a focus on numerical (particularly vector) work; and SIMULINK, a graphical dataflow language used by engineers, among others, to simulate physical processes and control systems.

This is anecdotal, but I've seen people who haven't written a large-scale program in their lives (myself included) "writing" large programs with reusable components in LabView with almost no problems whatsoever.  People who never really got the hang of MATLAB (after taking a class on it!) get SIMULINK figured out in a week and a half.  It seems unfair to call these languages a "failure."  Perhaps they won't make everyone a programmer--I think the proprietary and expensive nature of these tools is a factor--but they are clearly easier to learn by engineering students than conventional programming languages.  I'm interested in the IBM graphical language project mouser mentions above.


But there's a large difference even between text-based, non-functional languages.  I learned BASIC (my first language), Pascal, and MATLAB almost instantly.  Perl I can handle with the O'Reilly pocket guide.  I never got the hang of C and C++ is complicated as all get-out, but I'm starting to get it.  But a few years back I was helping people with their CS homework in Java despite never having learned it.

On a different note, I think the remark about excessively nested structures is a valid one.  Forth had even worse luck than the Lisp-y languages, except among owners of HP graphing calculators, and Forth has no parentheses.  Back when I carried an HP 49G as my primary calculator, I'd pore for many minutes over the program flow of even a simple RPL program which I would readily understand in BASIC, C, MATLAB, Perl, etc.  (I've since switched to a 32SII, which I have no idea how to program.)

mouser:
It seems unfair to call these languages a "failure." 
--- End quote ---


far from being a failure, matlab and simulink are incredibly successful tools in every way.  they illustrate the value of working with higher level interactive components when dealing with complex structures and functions.

i do think though that matlab suffers from the thing that most powerful tools suffer from after many years of evolution towards more powerful scripting, which is that the underlying language is not quite up to par with a full clean well designed oop language.  i think in the future we will see the move torwards a bigger separation of libraries and languages and the standardization of programming/scripting interfaces.

in other words, i predict that in 10 years i suspect that programs will not have their own little languages.
in 10 years when you buy a tool like matlab, microsoft office, firefox, whatever - they will all use a standardized interface for scripting.

pao:
i do think though that matlab suffers from the thing that most powerful tools suffer from after many years of evolution towards more powerful scripting, which is that the underlying language is not quite up to par with a full clean well designed oop language. ... in other words, i predict that in 10 years i suspect that programs will not have their own little languages.
in 10 years when you buy a tool like matlab, microsoft office, firefox, whatever - they will all use a standardized interface for scripting.
-mouser (July 05, 2006, 05:40 PM)
--- End quote ---

The underlying language of MATLAB is C*, and advanced users could write really advanced stuff as a C library instead, but this doesn't seem to come up much.

I don't think we'll see a generalization of scripting languages--for example, MATLAB is syntactically refined to be an excellent language for programming numerical algorithms, down to details like myvector(end) (shortcut for last element) and myvector(1:2) = [] (shortcut to remove first two elements from the vector).

Similarly, Perl is the greatest thing in the world for messing around with text files and strings, and its syntax, particularly with the simple use of regexes, seems geared to that.

I think the best example of a general-purpose scripting language that interfaces with many applications is AppleScript, which I'm not very familiar with, but sounds closest to mouser's prediction.  VBA is similar, though limited mostly to Microsoft apps.  But I don't see these replacing, just augmenting, existing scripting interfaces.  If nothing else, the group of people who might be called "non-dedicated programmers" for whom programming is only a part of what they do will have a resistance to the changes that would lead to the loss of their favorite niche language.

Okay, I'm just rambling now.  My original point was that the OP (not mouser, the blog poster) seems to either dismiss or ignore graphical programming environments, notably LabView, as failed attempts.  While LabView (in particular) has not seen broad acceptance by programmers, this probably has more to do with typecasting--in the acting sense--not as a general purpose language, but as a data acquisition language, no doubt because (1) that was its original purpose, and (2) National Instruments uses LabView primarily as a way to sell DAQ cards.  Thus, programmers, even those with access to LabView, often don't consider it for other tasks which it is perhaps just as well suited for.  It's a shame because it's an extremely rapid application development environment.  If only it weren't so expensive...

* The IDEs of MATLAB 6 and above are written in Java, and the language has access to the JRE, though I'm not exactly sure how to do this, as it too has never come up.

Navigation

[0] Message Index

[*] Previous page