Slashdot Mirror

I was struck with how many of the good ideas in programming languages were discovered early on. The decade 1964-1974 seems to have been a "Golden Age": most of the good ideas of programming languages appeared then.

If you like Lisp you like Mathematica. If you like FORTRAN you like MATLAB. If you like Python you like SAGE.

MATLAB is not, repeat not, better at numerics. Not since ancient times. What lowered performance was a linked-list implementation that went away long ago. Here's a Cal Tech CS prof comparing the languages. And he hates Wolfram!
http://lambda-the-ultimate.org/node/2220#comment-33430

Now SAGE is interesting. It bundles Maxima, a weaker old-style Lisp, with Python, a friendly yet dumbed-down language. Python numerics teams spent ~8 years doing arrays, over and over, and are still not done. I don't even track it any more - NumPy? NumericalPython? Whatever. They won't even let you define irregular arrays. And Guido avoids anything functional because he can't understand it.

To each his own, but functional code matches math best. Everyone knows this, and Guido is not trying to build a math language, so it's not his problem.

SAGE does the kitchen-sink approach with Python glue. They take GPL libs from everywhere and stick em together. Well, good on them. Open source needs this.

But compared to Mathematica they are not there yet. In certain sub modules they have world class algorithms. What SAGE lacks interactive typesetting and overall integration. Python and old-style Lisp is not a marriage made in heaven. SAGE also needs to implement typesetting the way Mathematica does it - not post-processing, but real typeset interaction. I am cheering for them but..still being rational about software choice.

When I can look at SAGE notebooks that have typeset code for both input and output AND that use a better functional language than Python or Maxima, I will switch to SAGE.

OK, this hit one of my hot buttons. Before I continue, though, let me preface my statement by saying that I don't disagree with the article (which is right on the button). But I disagree with the way the summary characterizes the situation.

I totally agree that universities shouldn't be teaching Java exclusively. They need to teach the basics of modular, functional, declarative and oo languages. Why? Certainly *not* to fill "software engineering" positions!!! A university's role is to do research, not to act as some technical college. OK, I can see having a programming course aimed at creating programmers for industry if it's going to pay the bills at the uni. But *don't* make that your "Computer Science" course!!

Computer Science should be science (well, math anyway). Universities should be getting the 5 or 10 graduates they need that will move on to academia (or industry research) later in their careers. Because right now, *nobody* is getting taught Computer Science! Lately I've been reading papers posted on http://lambda-the-ultimate.org/ Regularly I have to go back to the basics and learn extremely fundamental theory because nobody *ever* taught them to me in the first place. Half the time I think, "OMG, I never even knew this existed -- and it was done in 1969!!????"

More and more lately, I've been wanting to phone my University up and ask for my tuition back.

If you want to learn how to program in a professional setting, there's nothing better to do than just start writing code. Get your chops up. Then find some big free software projects and start fixing bugs. Learn how to use the tools (configuration management, etc). Learn how to interact with the other programmers. That's all you really need (well, that and a quick automata and grammar course so that I don't have to look at yet another context free grammar being "parsed" by regular expressions).

But right now, where do you go if you want to actually learn theory? I guess the library... And getting back to the point, this is essentially what the paper is suggesting. Students need to learn all these things because they are relevant to the field. A university supports industry by doing basic research. If you don't understand the concepts that they point out, you just can't do that. Paraphrasing from the article, having a university course that's meant to pad out a student's resume is shoddy indeed.

Like most problems, textual code reuse has via copy & paste has already been studied, and a language based on first-class copy & paste is being developed; it's called the Subtext language. See a more detailed discussion of it on lambda-the-ultimate. Academia is not so far remove from everyday programming as people seem to think!

It was not a fair comparison in 1981, and it's insanely ridiculous in 2007 counting this paper as a proof of pascal is toy language.
It's still not convenient writing C in Pascal :), but almost all objections proposed in this paper against Pascal language/implementations is not applicable anymore.

http://lambda-the-ultimate.org/classic/message4322.html#4671
http://www.freepascal.org/

A lot of efforts are being done to simplify the parallel programming, both on micro scale and component scale. Just look through lambda-the-ultimate archives. Micro scale is mostly invisible to application programmers, and it is mostly done by compilers when they use SSE and friends, one of notable efforts of making it more explicit is OpenMP. On component scale, most of them are based on the message passing concurrency model (after you grok it, it is really really simple). The best effort that I have seen from point of view of usability is E programming language. I tried to clone its core ideas in my pet project AsyncObjects Framework, but usability is less than E's one because of the framework clutter.

Just about everything technology related - http://technews.acm.org/current.cfm
Operating systems - http://osnews.com/, http://osdir.com/
Programming languages (like Ruby and Python and functional langs.) - http://lambda-the-ultimate.org/, http://plnews.org/
Consumer tech news - http://news.bbc.co.uk/2/hi/technology/default.stm
And of course, http://slashdot.org/

Tim Sweeney says that 90% of the CPU budget of Unreal Engine games is spent in functional code doing numerical computations: This functional code makes up 50% of the codebase, and he suggests that the next mainstream language should have more functional elements, learning "lessons from Haskell". According to slide 46, "80-90% of the CPU effort in Unreal can be parallellized" using "Haskell's HT, HTRef solution" which "enables encapsulating local heaps and mutability within referentially-transparent code".

More Tim Sweeny quotes from the presentation: "In the future, we will write these algorithms using referentially-transparent constructs.". "In a concurrent world, imperative is the wrong default!" That, to me, sounds like is using a functional language to write videogames, even if it is not a purely functional one and still has procedural parts. The only procedural code will be running the side effects, for about 10% of the total CPU time.

But games have always been married to the hardware, and I don't see how that could change any time soon.

What makes you think functional programming can't be married to the hardware? In fact, multicore computers are better programed through functional languages than with the glorified Von-Neumann architecture that is C++.

Also, there is nothing keeping you from controlling memory allocation for textures & poligons by using a functional dedicated library.

Cool, with that kind of benefit, I'm sure you can point to some significant applications that have been written in a functional language which have been written for parallel execution.

This kind of pisses me off. People who are functional programming ethusists are always telling other people that they should be using functional languages but they never write anything significant in these languages.

I visit many of the same sites that you do. Freshmeat is essential for keeping up with the OSS community. As a professional programmer, I also need to know what's new when it comes to Python, Ruby and Mono, since those are the languages or platforms I use most often. Sites like the Ruby Forum [http://www.ruby-forum.com/], Planet Python [http://planet.python.org/], and Monologue [http://www.go-mono.com/monologue/] make doing that very easy. And for future language developments, I'm always sure to read Lambda the Ultimate [http://lambda-the-ultimate.org/] and PLnews [http://plnews.org/]. And the comp.lang.misc newsgroup [http://groups.google.co.uk/group/comp.lang.misc/] is also a good place for information, too.

http://slashdot.org/
http://lambda-the-ultimate.org/
http://planet.haskell.org/
then I usually head back to slashdot and start all over again, grumbling about the lack of new posts before I give up and read from the firehose and rinse, wash, repeat.

I find it somewhat troubling that in this article John Backus is remembered primarily for the genie that he tried to put back in the bottle.

FORTRAN was utilitarian and procedural and good at enabling engineers and scientists to get work done. However, the problem with FORTRAN is the imperative pattern of though that it imposed led us to tell the computer a precise sequence of steps to accomplish each task. It doesn't offer information on dependencies, simply a "go here, do that" sequence of instructions. Imperative programs are inherently hard to reason about in terms of global state and effects and as written tend to be subject to off-by-one errors.

Backus saw this in 1978! See http://http//www.stanford.edu/class/cs242/readings /backus.pdf.

His insight spawned a great deal of the interest in functional programming languages. It was been credited by Paul Hudak of Haskell fame http://portal.acm.org/citation.cfm?doid=72551.7255 4 (ACM membership required) (summarized here http://lambda-the-ultimate.org/classic/message4172 .html) and others as really helping to turn the tide and kept functional programming languages from being snuffed out.

A lot of people don't see the point, having never programmed in a functional programming language like Haskell or ML. However even those people see dozens of cores on the horizon and wonder how they are going to deal with the debugging issues associated with all of the threads to keep those processors churning.

Functional programming offers an alternative viewpoint that is arguably much better suited to handle multiple CPUs working on large datasets. A case for this was recently reiterated by Tim Sweeney of Epic Megagames fame who said "in a concurrent world, imperative is the wrong default!" http://www.st.cs.uni-sb.de/edu/seminare/2005/advan ced-fp/docs/sweeny.pdf.

Haskell has brought Software Transactional Memory (STM) into play offering an alternative approach to traditional mutexes and locks that is compositional in nature unlike locking models. This is an approach that isn't readily emulable in an imperative setting because of the lack of guarantees about side effects. http://research.microsoft.com/~simonpj/papers/stm/ index.htm.

These are solutions to real problems that we are experiencing today, not some academic sideshow, and they arise from a school of thought that he helped bring a great deal of attention to.

If you want to do something to remember Backus take the time to learn OCaml or Haskell or even just take the time to learn how to effectively use the map and fold functions in Perl, PHP or Ruby.

It is his willingness to turn his back on what was percieved as his greatest work when confronted with a better idea for which I will remember him and I am a better programmer today for having learned what I could from his ideas.

If you were specifically discussing the functional programming model, you should have stated this clearly.

Since I am talking about Erlang/Haskell, what else other than the functional programming model would I have been discussing? your comment seems a little ...stupid.

However, you don't explicitly mention this, you simply mentioned "a proper type system" (which could include something like- e.g.- Ada's better type-checking

That's why I called you ignorant, because you think Ada has a proper type system.

There is nothing that a Sinclair ZX80 cannot do, given enough memory and time. So what?

Erlang and Haskell do not need more memory and time than C. They can work under the same hardware that C works, and offer same or better performance and much lower development cost.

Or are you claiming that Haskell can replace *all* applications of assembly/C/C++ (even allowing for the fact that in the real world, compilers can often optimise better than doing it by hand)?

Yes. Haskell/Erlang can replace all applications of assembly/C/C++. I advise you to check out this.

You're claiming that Haskell (or Erlang) is capable of carrying out the operations that were (supposedly) too low-level to be done in C? And that they can do this with the performance required by something like the XBox 360?

Yeah!

Furthermore, I suspect that there are "real-world" practical issues surrounding the choice of C/C++/assembly, even if that is only programmer familiarity with the language and procedural paradigms; and that is a good enough "excuse", even if long-term we'd be better off writing everything in Haskell.

The billions of dollars spent each year in debugging and testing prove you otherwise.

• Functional programming: Landin's SECD machine (1964)
• Object-oriented programming: Dahl and Nygaard's Simula (1966)
• Axiomatic semantics: Hoare (1969)
• Logic programming: Elcock's Absys (1965), Colmerauer's Prolog (1972)
• Backtracking: Floyd (1967)
• Capability security: Dennis and Van Horn (1965)
• Declarative concurrency: Kahn (1974)
• Message-passing concurrency: Hewitt's Actor model (1973)
• Shared-state concurrency: Hoare's monitors (1974)
• Software engineering: Brooks's mythical man-month (1974)

[Microsoft has] retained the likes of Simon Payton-Jones and Erik Meijer to work in their research department. In fact, LINQ may just be the best thing to ever happen to functional programming because now that Microsoft is doing it...

[Microsoft has] retained the likes of Simon Payton-Jones and Erik Meijer to work in their research department. In fact, LINQ may just be the best thing to ever happen to functional programming because now that Microsoft is doing it...

[Microsoft has] retained the likes of Simon Payton-Jones and Erik Meijer to work in their research department. In fact, LINQ may just be the best thing to ever happen to functional programming because now that Microsoft is doing it...

It would seem that Guido is not religious. There is a quote at http://lambda-the-ultimate.org/classic/message3555 .html stating as much.

In Relating FFTW and Split-Radix Oleg describes how to generate an optimal FFT from Scheme in a single pass. The secret is not repeated optimization passes or in-depth CPU knowledge, but instead to know exactly which identities (i.e., axioms) contributed to the optimum solution. I believe that in the future it will not be rare to generate optimal solutions, thus making choice of programming language a matter of personal taste or developer speed.

You want to know the latest trends for Java-based web development? Fewer and fewer people are going to be doing Java-based web development in the future.

Fuck trends. They're wrong. Every day the industry continues to stay with its current ridiculous technologies when vastly superior ones were invented decades ago infuriates me further. If it doesn't infuriate you, you're not paying close enough attention.

My advice: read Lambda the Ultimate and Steve Yegge's blog. Endeavor to learn what the lambda calculus and referential transparency are. If you are sincerely interested in bettering yourself as a programmer and don't go find out who Alonzo Church was then so help me God I will kick you in the balls. Learn about SML and type inference. Learn about Haskell and monads. Learn about process calculi and Erlang. Learn about Lisp and code generation and domain-specific languages. Learn about Scheme and lexical closures and continuations. Learn about Smalltalk and what OO was really supposed to be. Learn about type theory and formalism and the Curry-Howard correspondence. Learn about Forth and Joy and how you can have a powerful, expressive language without even so much as a grammar. Learn about Intercal and Befunge and just how badly your choice of programming language can torture you. Learn about UML and Ruby on Rails and Seaside and agile programming and Java generics and Python generators. Learn about aspect-oriented programming, context-oriented programming and concept programming. Learn about multi-paradigm languages like OCaml or Oz. Learn about weird Lisp dialects with syntax like Rebol or Dylan.

Realize that library design is language design. Realize that asynchronous programming with callbacks and explicit state in a world where lightweight coroutines were around in the days of fucking Simula in the 60s for Christ's sake is cruel and unusual torture. (Sorry, pet programming construct.) Realize that the programming language research community, while considering systems programming a solved problem and generally not interested in talking about human factors, is doing some genuinely promising work. Did you know that there are conc

You want to know the latest trends for Java-based web development? Fewer and fewer people are going to be doing Java-based web development in the future.

Fuck trends. They're wrong. Every day the industry continues to stay with its current ridiculous technologies when vastly superior ones were invented decades ago infuriates me further. If it doesn't infuriate you, you're not paying close enough attention.

My advice: read Lambda the Ultimate and Steve Yegge's blog. Endeavor to learn what the lambda calculus and referential transparency are. If you are sincerely interested in bettering yourself as a programmer and don't go find out who Alonzo Church was then so help me God I will kick you in the balls. Learn about SML and type inference. Learn about Haskell and monads. Learn about process calculi and Erlang. Learn about Lisp and code generation and domain-specific languages. Learn about Scheme and lexical closures and continuations. Learn about Smalltalk and what OO was really supposed to be. Learn about type theory and formalism and the Curry-Howard correspondence. Learn about Forth and Joy and how you can have a powerful, expressive language without even so much as a grammar. Learn about Intercal and Befunge and just how badly your choice of programming language can torture you. Learn about UML and Ruby on Rails and Seaside and agile programming and Java generics and Python generators. Learn about aspect-oriented programming, context-oriented programming and concept programming. Learn about multi-paradigm languages like OCaml or Oz. Learn about weird Lisp dialects with syntax like Rebol or Dylan.

Realize that library design is language design. Realize that asynchronous programming with callbacks and explicit state in a world where lightweight coroutines were around in the days of fucking Simula in the 60s for Christ's sake is cruel and unusual torture. (Sorry, pet programming construct.) Realize that the programming language research community, while considering systems programming a solved problem and generally not interested in talking about human factors, is doing some genuinely promising work. Did you know that there are conc

Along those lines, I would also recommend LtU: http://lambda-the-ultimate.org/

Scala is a language that targets the JVM and nicely fuses the object-oriented and functional programming paradigms. It is statically typed, has closures, a powerful collections library, integrates perfectly with Java (all Java classes can be imported 'as-is' in your program), pattern matching, and much more. See also the discussion on Lambda the Ultimate.

Since MS couldn't succeed in screwing over Java into their own image - they reinvented it as C# - nothing more than a pale immitation. Sorry .NET guys - your guiding light in Anders failed.

Bahah, are Java guys the most bitter developers in the world? Sun is busy copying features from C# for Java 5 left and right, and Joe Bitter here calls C# a pale imitation. Hilarious.

First off, take a look at what's coming for C# 3.0 http://lambda-the-ultimate.org/node/1253. Next, realize Java's failures on the client (Swing). After that ponder why even the open source or nothing crowd has nothing to do with Java and why Ruby and Python are big in that sphere.

Face it, Sun crippled Java to such an extent that it'll never be anything more than the next COBOL. If Sun had any clue (and they usually don't), they would call the Java 6 language feature-complete, and in the Dolphin time frame develop a new language to leverage the new VM and all the existing libraries..

I'm in my freshman year of college and I've already learned OOP... some places must really be backwards.

Depends. If you learned OOP according to the gospel of C++, Java, or C#, then you're school is backwards. My personal opinion is: OOP should not be taught in a freshman class. According to Matthias Felleisen:

...a functional semester ideally prepares students for the true essence of object-oriented programming according to Alan Kay: the systematic construction of small modules of code and the construction of programs without assignment statements. Experience shows that these courses prepare students better for upper-level courses than a year of plain object-oriented programming. Initial reports from our students' co-op employers appear to confirm the experiences of our upper-level instructors.

In my experience, students who learn OOP, believe that private member variables (private mutable state) is okay, when in fact, private member variables should be used only when necessary. If it is possible assignments should be avoided, data should be passed to a method via the parameters, and results returned from the method because:

1. It makes the method easier to reason about. The methods behavior can be determined by looking the method call. This is not so when there is private data, or global variables influencing the behavior of a method.
2. It makes the method easier to test. Unit testing a method is hard (and sometimes impossible) when the behavior of a method depend on more than just the parameters.

If you have a procedure with ten parameters, you probably missed some.---Alan J. Perlis

I had written a nice piece of code here, but since Slashdot considers code lame (the lameness filter), and thus discourages intelligent conversation involving code examples and the like, I'll have to point you to these threads discussing some of the problems with OOP as it's taught in many schools (and why I believe a pure OOP or OOP biased computer science curriculum is bad).

I'm in my freshman year of college and I've already learned OOP... some places must really be backwards.

Depends. If you learned OOP according to the gospel of C++, Java, or C#, then you're school is backwards. My personal opinion is: OOP should not be taught in a freshman class. According to Matthias Felleisen:

...a functional semester ideally prepares students for the true essence of object-oriented programming according to Alan Kay: the systematic construction of small modules of code and the construction of programs without assignment statements. Experience shows that these courses prepare students better for upper-level courses than a year of plain object-oriented programming. Initial reports from our students' co-op employers appear to confirm the experiences of our upper-level instructors.

In my experience, students who learn OOP, believe that private member variables (private mutable state) is okay, when in fact, private member variables should be used only when necessary. If it is possible assignments should be avoided, data should be passed to a method via the parameters, and results returned from the method because:

1. It makes the method easier to reason about. The methods behavior can be determined by looking the method call. This is not so when there is private data, or global variables influencing the behavior of a method.
2. It makes the method easier to test. Unit testing a method is hard (and sometimes impossible) when the behavior of a method depend on more than just the parameters.

If you have a procedure with ten parameters, you probably missed some.---Alan J. Perlis

I had written a nice piece of code here, but since Slashdot considers code lame (the lameness filter), and thus discourages intelligent conversation involving code examples and the like, I'll have to point you to these threads discussing some of the problems with OOP as it's taught in many schools (and why I believe a pure OOP or OOP biased computer science curriculum is bad).

You might try mentioning your draft over at Lambda the Ultimate. They're very interested in programming language design over there, including things like type systems. A few stories on Ruby have popped up recently, and I'm sure they'll be interested in the work you're doing.

Sat down at the local Borders and read it in about an hour after it caused a big stink over at javalobby.org and theserverside.com a couple months ago. Ruby's a real nice language and I'd personally choose it over Java for many projects, but it's just falling into it's niche with the Ruby on Rails hype, just like PHP, Perl, and Python fell into their niches a while back.

The thing is that a pure dynamically typed language is never going to be the language "Beyond Java". But it doesn't have to be an either/or situation, as is already the case with languages like Boo and Dylan. Look at languages that do type inference with type declarations for method arguments and return types as "the future". Take a look at http://lambda-the-ultimate.org/node/1253 for what Microsoft is doing with the next version of C#. That seems to be a more reasonable approach to the whole dynamic vs static typing debate. In fact, I would recommend searching http://lambda-the-ultimate.org/ to see what some of the "deep thinkers" about these issues say about the whole debate.

Ruby is nice, but Beyond Java seems more of a book to shake up the Java community and promote consulting services than any real insight onto what's "Beyond Java". I think Guido is even going to be pure some sort of type declarations in Python 3000 - whenever that comes out.

Sat down at the local Borders and read it in about an hour after it caused a big stink over at javalobby.org and theserverside.com a couple months ago. Ruby's a real nice language and I'd personally choose it over Java for many projects, but it's just falling into it's niche with the Ruby on Rails hype, just like PHP, Perl, and Python fell into their niches a while back.

The thing is that a pure dynamically typed language is never going to be the language "Beyond Java". But it doesn't have to be an either/or situation, as is already the case with languages like Boo and Dylan. Look at languages that do type inference with type declarations for method arguments and return types as "the future". Take a look at http://lambda-the-ultimate.org/node/1253 for what Microsoft is doing with the next version of C#. That seems to be a more reasonable approach to the whole dynamic vs static typing debate. In fact, I would recommend searching http://lambda-the-ultimate.org/ to see what some of the "deep thinkers" about these issues say about the whole debate.

Ruby is nice, but Beyond Java seems more of a book to shake up the Java community and promote consulting services than any real insight onto what's "Beyond Java". I think Guido is even going to be pure some sort of type declarations in Python 3000 - whenever that comes out.

Yes, in most cases the list comprehension works can work out (often better) than map and lambda. However, their are some examples using reduce (see discussion at lambda the ultimate). I don't know what the final verdict ended up being but clearly functional programming style is being discouraged.

The only explanation google turned up for this is because python is supposed to have one way to do things. While I don't necessarily want a perl this seems to clash with the culture which prefers no explicit attribute protections. I just don't like feeling pushed and told to do things differently just because I *like* the functional style.

Well I guess their is no reason to turn this into another argument over this issue. I think I have my answer. But I think if a language continues to push our people who prefer to do things in one style it is going to lose a lot of converts to other languages like ruby.

Finally do you really mean a general yield is going to be in python 2.5. I understood this was the one issue that had technical problems unless you went to stackless python. Are you sure it isn't planned for python 3000.

While some people can't stop arguing about the merits of [yet-another-block-structured language], real mathematicians are working on continuations, monads, macros, type inferencing, theorem proving, etc.

Of course, Lisp programmers don't even need to touch a computer anymore. (They already wrote a program in 1970 that does everything they'd need to do :D)

http://lambda-the-ultimate.org/ (no affiliation)

• Erlang Developed by Ericsson for their realtime telephone servers. Is mature and has concurrent communications and database libraries among other things.
• Oz was made as an implementation of the ideas in the book: "Peter van Roy (2004). Concepts, Techniques, and Models of Computer Programming. MIT Press" Where the idea was that different kinds of programming (concurrency, OO, Logic) could be implemented and cooperate in the same language. Not as mature as Erlang.

- Declarative concurrency (synchronization on logical variables):

• Curry is a extension of the language Haskell and, like Oz, combines different kinds of programming in one language. Unlike Oz, Curry uses declarative concurrecy. Curry is in an even earlier stage of development than Oz.
  
  All these languages are open source and free but they are functional programming languages. The difference betwee

Posting to slashdot won't do anything for you.

If you're hardcore into leading-edge language stuff (and based on the functional programming references I figure you might be), Lambda the Ultimate'll give you a run for your money.

CLiki [cliki.net], a programming language blog. Contains lots of stuff on programming languages and paradigms, including debates on merits and disadvantages.

That's not true. CLiki is just the Common Lisp wiki; meaning everything Common Lisp, specially those that satisfy the Debian license. From the site:

"Links to and resources for free software implemented in Common Lisp and available on Unix-like systems. Listed software should satisfy the Debian Free Software Guidelines (DFSG)."

ll-discuss, a mailing list related to programming language concepts. Perhaps most interesting if you're into language implementation, but it's the closest thing to a magazine that I can recommend.

Not really. ll-discuss is for small light-weight languages (think scripting languages, or tiny dynamic languages) The "ll" stands for Light-weight Languages actually, and it grew from the conference by the same name.

People who are into language design frequent LtU. Or more likely they're busy reading their huge required reading list :-)

Bugtraq is for security specialists, or people who code in C/C++ ;-)

Practical Common Lisp is a book, not a magazine.

How to Design Programs is an entry level programming book, meant to teach high schoolers and people with NO programming experience. Any CS graduate should be intimately familiar with its teachings, and that of the more grown-up SICP.

I like dinking around in Lisp, PostScript or Forth from time to time but you quickly realize that without type checking any major program in those languages would be pretty much unmaintainable.

Incidentally, if you think proof of correctness is impossible for undecidability reasons, you're wrong.

I think so too, but try tell it to these guys if you dare.

Your average slashdot poster is more likely to be satisfied with OOP brochure-talk than, say, the more academic types over at LtU.

http://lambda-the-ultimate.org/classic/message1987 .html had an interesting discussion of this. Frank Atanassow's comment was particularly good.

The article you mentioned can only show that the particular forms of graphical programming they looked at perform poorly for the specific tasks they set. Better representations for specific tasks would show different results. In particular, this might be the case for languages implementing the original poster's idea of a: "...specification oriented programming model, [where] you specify the behaviour, not all the million little steps that are needed to perform it"

Clearly for intrinsically graphical tasks such as GUI-building a graphical programming method is superior to text. Just as clearly for the case of languages with representations which are somewhere between graphical and linear-symbolic, such as Mathematica, most complicated math is easier to understand in 2-D symbolic format, yet this can also introduce ambiguity in interpretation - converting linear to 2-D and back will not always yield the original equation.

I think that graphical tools also have an important place in debugging, because the execution of programs itself is no longer linear. It is often very difficult to figure out where a particular line, function, method, or whatever fits in the grand scheme of things in code one did not write oneself, and the bigger the codebase, the more external libraries, processes, threads, message-passing and so forth that a program has, the more valuable a good graphical representation can be in figuring out the larger context of what was supposed to happen and what went wrong.

While it may not be possible or desirable to completely eliminate traditional linear programming in favor of graphical programming, I think reversing the relative proportions of each may work better when creating a specification-oriented programming language.

Declarative Programming is like Functional Programming, only it goes one step beyond: it converts a functional algorithm to an imperative one, by identifying at compile time which data can be safely updated.

In Declarative Programming, there are no references or objects; there are only values, even if these values are composite ones like a Window or a database object model. A DP program is a recipie of value transformations: a set of values is transformed to another set of values through I/O and computations.

DP programs can also act as formal specifications, since they manipulate sets of values and specify the transformations between them using the lambda calculus.

DP saves the programmer from having to manually insert destructive updates in a program. Updating of a variable is just an optimization anyway...if we had infinite computers, we wouldn't reuse the same variables, but instead act on copies of them. The whole problem is referential transparency, of course, which FP solves, and DP optimizes.

Another promise of DP is algebraic types...i.e. types that their properties are defined by algebra. This covers all possible type categories, like enumerations, classes, etc

There is no concrete mathematical theory yet developed, but there is evidence that any functional algorithm can be converted to the equivalent imperative one. For example, the functional quicksort algorithm can be converted to the in-place quicksort algorithm. Check out this link for further information.

It would be a really good thing if the world of Computer Science (I mean the real thing, with the formal methods and the big O notation and the simply-typed lambda calculus, not "how to become an Excel power-user") were to receive a sudden influx of mature students, especially female, from a variety of class and ethnic backgrounds.

It would mean that our societies had changed, dramatically, for the better, without the apparent necessity of intervention by government planners and public servants. Progress for free! Or, rather, progress paid for by those who instigated it, the price being their own time, energy and dedication.

It would make academic conferences more fun, and LtU a considerably more exciting read (although you'd still have to be the sort of person who's excited by process calculi and monadic subcontinuations to really get anything out of it).

It would mean that widespread acceptance of mediocrity - in programming languages, in software tools, in operating environments - was starting to crumble, as previously "elite" knowledge was disseminated among a wider community of empowered users and technicians.

It would be great. But it isn't happening now, and it's not likely to happen soon.

Maybe we should start thinking about how to make it happen?

I used to think C++ was the best general purpose programming language, until I met LISP. At first, I had difficulties understanding it, but after playing with LISP, I realized how much more powerful than C++ is.

I suggest everyone to read the material at lambda-the-ultimate. You will be surprised on how little you know on programming languages...it was a real eye opener for me.

Also powers Lambda the Ultimate: The Programming Languages Weblog.

Shameless plug from LtU contributing editor. :-)

Parallel computers with tens of thousands of processors are typically programmed in a data parallel style, as opposed to the control parallel style used in multiprocessing. The success of data parallel algorithms - even on problems that at first glance seem inherently serial - suggests that this style of programming has much wider applicability than was previously thought.

Look at what these people are saying though (I am the one that supports C++ in that thread!). These people are giving C++ a bad name, yet they are totally unaware about its capabilities. C++ is the greatest programming language ever (feel free to flame me) considering the large set of domains that it covers.

I agree, Lambda the Ultimate is a great way to keep up with academic research, at least related to programming languages (which are pretty central to computing, of course). It seems like one of a kind, though. What other good ones are out there?

Since when can you write a domain specific language/interpreter in just about a day or two???

This book teaches functional programming as a way of thinking and problem solving, using Haskell, the most popular purely functional language. Rather than using the conventional mathematical examples commonly found in other programming language textbooks, the author draws examples from multimedia applications, including graphics, animation, and computer music, thus rewarding the reader with working programs for inherently more interesting applications. Aimed at both beginning and advanced programmers, this tutorial begins with a gentle introduction to functional programming and moves rapidly on to more advanced topics. An underlying theme is the design and implementation of domain specific languages, using three examples: FAL (a Functional Animation Language), IRL (an Imperative Robot Language), and MDL (a Music Description Language)...

Since when can you write a domain specific language/interpreter in just about a day or two???

This book teaches functional programming as a way of thinking and problem solving, using Haskell, the most popular purely functional language. Rather than using the conventional mathematical examples commonly found in other programming language textbooks, the author draws examples from multimedia applications, including graphics, animation, and computer music, thus rewarding the reader with working programs for inherently more interesting applications. Aimed at both beginning and advanced programmers, this tutorial begins with a gentle introduction to functional programming and moves rapidly on to more advanced topics. An underlying theme is the design and implementation of domain specific languages, using three examples: FAL (a Functional Animation Language), IRL (an Imperative Robot Language), and MDL (a Music Description Language)...