Lambda the Ultimate

It's even better news for Erlang, which is the only industry-proven mostly-functional (and implicitly parallel language) I know of out there. I consider your other examples to be research languages that haven't yet had a killer application.

http://erlang.org/

It's even better news for Ada, which has been deployed in mission-critical (and by that I mean either it works or people die) parallel systems for even longer than Erlang was around.

Well, occam for one. It was explicitly designed for massive concurrency, and intended to run on networks of transputers. Transputers, in turn, were developed to harness the power of multi-core systems (well, multi-processor really), because the transputer designers believed that single-core systems simply wouldn't advance much further and the future lay in parallelism.

Unfortunately, with the death of the transputer (primarily due to an extremely delayed release of a promised next-gen transputer - at least that's what I've heard), occam fell into disuse, and many of its neat features were forgotten. Nor has occam evolved much to keep up with modern trends in software development. There is some work going on at the University of Kent to add new features to occam, but there're only a handful of people doing that work.

Ada (see above).

languages with explicit support for activities normally associated with the analysis, design...

Since we are dealing with things we can't prove, let me just say that I think (and hope) that this is wrong approach...

I mean especially analysis and design. Am I the only one who smells UML hiding around the corner?!

Since I also believe, but cannot prove, that visual languages are a complete waste of effort, you can be sure I didn't mean UML.

Besides, there's barely any support for design information in UML, beyond that provided by standard OO languages.

Since I also believe, but cannot prove, that visual languages are a complete waste of effort, you can be sure I didn't mean UML.

Glad to hear it.

Since I also believe, but cannot prove, that visual languages are a complete waste of effort

I believe, but can't prove, that "modelling", as the word is used in the UML circles, is metaphysics. Taxonomic reasoning is metaphysics, and the correspondence between "real world entities" and code classes is metaphysics. Since there can't be a physical bridge between the metaphysical realm of objective contents and the physical realm of subjective programs, modelling is an activity forever removed from actual concretion in code. The leap between modelling and programming requires a leap of faith, irreducible and un-analyzable, opening up the door to byzantine discussions about the nature and accidentals of the angels, I mean, "real world objects". This is to me a throwback to primitive, animistic reasoning akin to the scholastic method of the Middle Ages.

Very well said, and I also remember a quote by one of the founders of object-oriented programming (Nygaard or Dahl I think) where they say something like (paraphrased from memory!): ``The meaning of ``object-oriented'' is precisely this: the objects of a program model the physical objects of the program domain.'' Good thing they were able to figure out a true model of physical reality, somthing (meta)physicists have not been able to do for centuries! (I would appreciate someone telling me the correct quote, I cannot remember remember where I read it.)

...but the following from an article on Smalltalk expresses the idea:

object-oriented languages make it much easier to build dynamic systems, because they map concepts much more directly into software. There is a one-to-one mapping between the model (Class) and the phenomena being modelled. Instead of "programming", you simply "model".

Since I also believe, but cannot prove, that visual languages are a complete waste of effort, you can be sure I didn't mean UML.

Since I also believe, but cannot prove, that visual languages are a complete waste of effort

I agree, programmers are comfortable with text based representation of programming languages because they already have the natural language skills necessary to represent complex ideas as text.

I believe, but cannot prove, that there is room for what I'll call "hybrid" languages, which mix visual and textual forms of specification

Would you consider the merger of a text based language, like Java, and a good IDE, like IntelliJ, to be a hybrid language? For example IntelliJ will display an icon next to an override, or a method being overridden, to visually indicate program structure. This eliminates the need for verbose keywords like "overrides" and "overridable".

I agree, programmers are comfortable with text based representation of programming languages because they already have the natural language skills necessary to represent complex ideas as text.

Actually, I think it goes beyond that. Some ideas are just much more easily and clearly expressed in a linear textual form (while others are better suited to some kind of non-linear graphical notation). Note that doesn't preclude the use of graphical symbols in linear text, to provide more compact expressions (conventional mathematical notation, with its mix of letters, numbers, greek letters, and custom symbols such as the integral sign or fraction notation, is a good example). But if you've ever tried to build a complex graphical model (using, e.g. Simulink) you rapidly find that in some cases while you could define a particular construct using the graphical notation, a textual representation is substantially more clear. I suspect that many of the people who push the idea of purely graphical notations for programming have never actually tried to build a large graphical model.

If you have ACM access (sorry, I looked but I can't find a free version) you might be interested in Marian Petre's paper Why looking isn't always seeing: readership skills and graphical programming.

Would you consider the merger of a text based language, like Java, and a good IDE, like IntelliJ, to be a hybrid language?

I'd certainly add Modelica to this category, and a few other components-with-enclosed-scripts languages that I've seen come and go, which aren't worth naming, including 'wiring' style Java bean editors.

Though I agree with your general point that the language is changed by the representation, the "override" keyword in C# is not useless. The "override" keyword says "I mean to override something in a super class." IntelliJ can't automatically figure out whether you meant to override a method. Since accidental overriding is something that can happen quite easily, I think the extra keyword is useful.

However, there are other cases where being explicit about intent may not be worth the effort. IntelliJ also highlights references to static fields, which diminishes the utility of prefixing instance variable names with "m_".

Functional and rule systems often have a structure that leads to nice visual representations. Here is one I discovered recently.

I think things are moving in that direction, and is driven not by PL but by an integrated environment like Eclipse. Marrying code and task list (or bug tracker) is already common, then you can of course marry tasks with requirements, with schedule, with design docs, etc. Testing is already integrated to some extent, with unit test attributes integrated into some PLs.

Post-deployment is something that seems neglected. Sure, you can press a button and deploy a web site on some IDEs, but it doesn't annotate the code with stack traces that occur in production and tie them to a customer ticket.

As far as analysis and design ... tools that allow better high-level views of an architecture would be nice. But, it seems these phases are driven more by politics than PL limitations.

Dave Griffith: ...next great productivity gains will be made by languages with explicit support for activities normally associated with the analysis, design, testing, integration, deployment...

That's basically what I've been thinking for a while. Now what to do about this is what occupies my design cycles during Copious Free Time. But I might add an item not noted in your list above: explicit support for learning. That one's tricky to explain, but it basically means bounded documentation: enough docs to explain what you find, and few enough docs (small enough language) that you can plan to get your head around it in a time you can plan.

Typically languages don't have bounding their adequate docs as a goal. But to me this is as helpful as a line in a proof that says there are no more steps.

Okay, now back to your list of things needing explicit support. Productivity gains would derive from saving time on tasks that take too long. Today just hacking out a first draft of code takes a small part of total time consumed by trying to ship a new product, like a complex server. Just to pick a single thing on the list, it takes at least as much time to analyze what a system is doing under debug. In other words, after you write the code, you spend at least as much time wondering what the system is actually doing, even if the code is nearly all correct.

Starting about three years ago, I started telling folks you not only had to write code that runs correctly, you also must provide some kind of support to see whether code is running correctly. Even if there are no bugs, some emergent effect at runtime will puzzle you, and a long time can be consumed by tracing the cause and effect back to appropriate roots. When you work on a team with several other folks, after the first agonizing bug shows up, you can spend a lot of time proving your part of the system does exactly what expected, and didn't play a role in the observed chaos.

Lately I seem to spend most of my time in forensic system analysis as a local coroner for other folks' code fatalities. I never had an ambition to be a code coroner.

It would be enormously helpful if a language -- and not just one particular development environment -- had explicit support for generating evidence of what and how a system actually got from one point to another. At minimum, a count of every method called would be terribly useful for debugging and testing with a bit of scientific method. (Test A should fire method B between M and N times.)

Basically, you'd like to reify a lot of things about the runtime enviroment, so you can minimally evaluate a running system. Better yet, it would be nice to able generate code that automates your evaluation in various ways.

(Generating runtime breadcrumbs can be expensive, but in practice I see this expense being paid anyway, and sometimes in grotesquely ad hoc and inconclusive fashions. If a language supported such features at the conceptual model level, the cost ought to be less than otherwise. And real deployed systems typically want to have logging and auditing of some kind turned on anyway, if only to bill the folks using a system with some backup proof that the bill is not made up.)

These days during my Copious Free Time, I think about doing this kind of thing using a hybrid of Smalltalk and Scheme and XML, where all syntaxes parse to variations on the same parse trees and compile to the same runtime. You'd also want to implement Python too with the same runtime. Using existing syntaxes -- especially ver simple ones -- would reduce size of docs. (You'd need to cheat a little to avoid making syntax for primitive data types vary too much between one code style and another.)

The goal would be a Lisp/Scheme dialect (with full continuations) that also supported a Smalltalk dialect and an XML dialect, and also had namespaces for traditional Scheme and Smalltalk bindings, plus a lot of code for converting between language flavors (and sure, Python too, why not) and a expressly supported native C++ underpinningfor writing primitives. I basically like Patrick Logan's "shared nothing" model which resembles some parts of designs I did a few years ago, so I'd lean in that direction for the network i/o module and server support. I think a web server should be built into the langauge, so you can ask the runtime for a summary of current statistics. Everyone who writes a server wants a web interface, and having the language understand the idea would help. A hello world program ought to generate a web page or some XML someone wants to consume.

I like the idea of being able to nest XML inside of Lisp inside of Smalltalk in whatever order I like. But that doesn't have anything to do with the semantics of explicit support for all the things in Dave Griffith's list. I don't want to make up a new language to get the desired support, though mixing existing languages might seem like that. Because rules for symbols in Lisp and Smalltalk are fairly simple, it would be easy to have a namespace system that allowed one to name any particular runtime value you wanted to sample, as a first class reified object. You kinda want syntax styles agnostic about symbols so the namespace architecture can be beefed up to refer to everything in the conceptual model providing all that extra support.

Um, I am so having diarrhea of the mouth. Sorry -- gotta cut myself off.

I don't know about strict "language-level" support for learning, but I think Dr.Scheme does the next best thing. Like you said, it provides varying levels of documentation based on the environment you specify--for example, there are several environments defined for various Scheme textbooks. It also loads up code for interactive evaluation from those same textbooks. Finally, it also provides some tools based purely restricted nature of the "beginner" environment so that students can actually inspect what's happening, such as a evaluation stepper, and a code-coverage checker.

So, if you're a student working through HtDP using this environment, you've got not only all of the documentation and code from the book at your disposal, but you also have some tools to help you work out exactly what's going on.
(edit 5-3-06 fixed link to point off-site)

Rys: Um, I am so having diarrhea of the mouth. Sorry -- gotta cut myself off.

If the alternative is not to hear from you but once every few months or so, please keep typing. :-) Naturally, you know that I'm a big fan of your ideas. How are things in life with respect to work and CFT? I know things have been tough for a while.

Paul Snively: Naturally, you know that I'm a big fan of your ideas. How are things in life with respect to work and CFT? I know things have been tough for a while.

It's easy to assume folks stop being interested in one's ideas after personal trouble; I'm glad you were not only a fair weather friend. But since life in work and CFT is off topic here, I should keep it really short, like a movie title. So instead of Sleepless in Seattle I might sign myself Insolvent in Palo Alto. (If I still signed myself David McCusker I might see more greetings -- maybe I should use that name again professionally.) Work could be better, but staying in one place has been my goal for a while now, so I'm fourteen months into a startup that plans to drop stealth mode during the next month or two. However, I plan to make few comments on work even then. Maybe after they announce I'll consider moving on. I should resume a blog to chat in a better place.

In this forum, hobby coding in my vanishing free time remains on topic when it's in the interesting programming language vein. I guess I'm gearing up my mind for more implementation. I added a Smalltalk object system to a Lisp dialect once around 13 years ago, and doing it again would be really easy, and this time my product would be enormously better in many ways. Only this time I won't be grafting Smalltalk onto Lisp; a generic VM suiting either equally well is better. Keeping the C++ at the bottom small and understandable is what slows my hand, since I don't want to just spew out an extra thirty thousand lines just because it's easy.

At the moment I plan a first draft in trampolined dispatch style to prevent C stack winding, with an interesting representation of continuations to simplify a mix of code in many formats including interpreted parse trees, VM pcode, and C++ primitives, etc. The idea is the same one I had about eight years ago, and was planning for Mithril, where basically code pointers (a "return address" or a "continuation") are typed, so calling or jumping to executable code is generic. While that slows dispatch with indirection through a how-to-dispatch step, it allows you to mix everything and have reified stack backtraces with return addresses of all flavors. And nothing stops you from having C calling into Lisp calling into assembler calling Smalltalk calling into Python, etc.

When dispatch is not antagonistic to high level tools like debuggers, it becomes incredibly easy to write them, and incremental just-in-time compilers, or whatever. And you can just experiment with code research you find amusing. Like you could just add a 68K emulator to use as pcode (as a random example) and it would plug-and-play with the other code types.

I'm late and really must stop right this second. :-) My girlfriend interrupted the second paragraph above to have a discussion about moving.

If I still signed myself David McCusker I might see more greetings

I know it's you Rys, and I am glad to see you are ok. The LtU forum isn't really a usuall place for personal conversations, which may explain the lack of greetings. I for one am always happy to hear from you, here and elsewhere.

At the risk of getting scolded for being offtopic: +1.

Check out a replay debugger tool.

I believe, but cannot prove, that the languages which support these features will need to be not higher-level, but wider. Something like C++/Boost, Lisp/Scheme macros and Template Haskell but with closer ties to the type system are probably where you need to look here.

Dependently Typed Meta-programming maybe?

That was the whole point behind SQL and it's various competitors, back in the day. Of course, once it solved 9X% of the programming tasks of the time, we then promptly grew a whole new set of programming tasks...

As far as I know, programs in SPARK Ada have to be bounded in space, since neither recursion or dynamic allocation is allowed. I believe (but cannot prove) that this is what makes the SPARK approach of partial correctness proofs feasible.

Wouldn't SPARK be an example of an almost-complete language such as you mention? I'm sure the SPARK marketing departement consider it appropriate for 99% of all programming tasks, but how fun is it to get a message from your compiler saying that it can't handle programs this big, you need to get a version of the compiler which is compiled with higher static bounds? (The SPARK compiler is written in SPARK itself...)

Spark is intended for safety-critical applications where the restrictions you mention are the norm (in some cases they are legally mandated.) AFAIK, Spark programs are compiled using existing Ada compilers. The Spark Examiner is available in different sizes to accommodate different programs.

I should have said the Spark tools.

Would you happen to have any pointers to information on Linear Logic?

I am always interested in the problem of garbage collection, and alternatives to it.

A good starting point might be Henry Baker's Look Ma, No Garbage and Use Once Variables and Linear Objects. Also, search his
paper archive page for the word "linear". Also see Wadler's Linear Logic page. Note that systems based on linear logic can obviate garbage collection, but depending on the properties of the system in question, they don't necessarily do so entirely. As usual, a benefit such as "no GC whatsoever" comes with a cost.

First lets deal with the "don't do so entirely". Since any turing complete language can emulate any other, any linear logic (or any other GC based) based language can say create an interpretor for standard C. ie. No matter how smart our GC we can _always_ do something sufficiently stupid to get us in as bad if not worse a state.

How ever the real benefit I see in linear logic is the way it matches so closely our natural perception of the world as ingrained from preschool days.

"The ball is in my Hand now. You take it from me. The ball is in your hand. The ball is NOT in my hand now. WAAAHHH!!!"

Compare this to the C pointer, the Ball is in my Hand, it's in your Hand, it's also in the cupboard, and Sam playing outside has popped it so you're going to fall flat on your back when you try kick it.

The cost is at the source code level: just compare code in a linear language to equivalent code in a non-linear one, and the cost should be evident. The advantage of GC is that it usually requires no explicit attention in code whatsoever - its costs are all hidden and paid automatically, so the net effect of GC is that it removes complexity from code, reducing the effort required to write and reason about the code. This is not the case for code based on linear logic, no matter how intuitive a micro-example may seem to a preschooler.

I agree with your point about relational vs. current object systems. Multiple inheritance and Java-esque interfaces try to mitigate normal object oriented limitations. The folks over at dbdebunk.com try to preach and defend the relational model, it is unfortunate that sometimes they get down-right nasty and rude.

I expect to see a language that...
** Is fully relational ala Codd Law's.
** The basic Object model is also in at least 4th normal form.

I predict that the language will die in obscurity, because the SQL people will see it coming, and add more cruft to SQL to implement object models a half-arsed way. "Cool", database vendors will say. "Guess we can stick with SQL."

Linear logic will supplant GC.

Um... unfortunately, no: this thesis shows what linear logic buys you, and single-usage is not one of those.

The Epigram koolaid. :) I am too waiting for the real version of that... should be simple, right? Just add some IO and support for general recursitivity... :p

Seriously though, I would be overjoyed to see that as a useable style of programming in my lifetime (and I'm only 19...) -- ala what Haskell is nowadays.

I agree with you reuse, as within the current paradigm, is doomed. But I'm a tad more optimistic than you. I believe reuse fails because...
* People fail to write reusable code.
* The "not invented here" syndrome.
both of which may change under a paradigm shift forced by the sheer weight of code we have to maintain.

You seem to be of the gloomy view that only tools may be (partially) reusable, code never. (Ah but then all my Russian friends seem to be innately depressed and pessimistic so maybe that has something to do with it...:-))

With respect your point 3, are you aware of the existence (and failure) of the (attempted) move to syntax aware editors a decade or so ago?

Yeah. Tools and languages are reusable and widely reused now; code isn't. I believe this isn't going to change, for sociological reasons like the ones you cited :-)

Re the paradigm shift: we've already seen it. VisiCalc killed a whole market of specialized financial software. The same thing is going to happen with more and more segments of the software market; this is "progress in CS" in the most real sense. I think it's very good - a future with opportunities for everyone, not just wizard Haskell programmers.

Re syntax editors: when I code Java, I use IntelliJ IDEA. It's very syntax-aware, and does a whole lot of wonderful stuff. In Ruby, however, a simple text editor serves me just fine... But it would be even nicer to have a separate syntax checker that would watch the filesystem; I save the file in my favorite editor, and a separate window shows me the list of syntax errors. And test results. :-)

Vladimir Slepnev: But it would be even nicer to have a separate syntax checker that would watch the filesystem; I save the file in my favorite editor, and a separate window shows me the list of syntax errors. And test results. :-)

That would be omake -P.

I've said it before: the combination of O'Caml, GNU EMACS + Tuareg Mode, and omake, in which I can try things out interactively, put them in an actual source file when they work, and keep my build up-to-date at all times is priceless.

That's really it, thanks! Will try it out.

Just for the record, I think I see a wonderful use for omake. It's called (giggle) Macromedia Flash.

We've had the MTASC compiler for ActionScript for quite some time. It is Open Source and lightning fast (and, incidentally, written in OCaml too). Compile times are almost unnoticeable. After we add something like omake to the mix, rich GUI or game development may look like this: you edit a source file, hit save, refresh the browser and see the results immediately. Faster than AJAX, nicer-looking than most graphics toolkits, integrated with sound and network, providing an advanced language for development (the MTASC brand of ActionScript has GC and type inference), and 100% portable across all browsers in the world.

There's a Flash plugin for Lynx?!

OK, I admit the 100% sounds a bit rude. I heard the actual figure is something like 98%. Not bad either :-)

maybe it could be created if you start with the technology used here (from the mashup experts at Poly9).

Hi Vladimir, did you also have a look at haXe ? http://haxe.org. It might be a lot more appealing to audience there than learning ActionScript 2 :)

Yes, I believe too that using the wide distribution of Flash makes sense for some applications, although you can't do eveything with it, and in particular the current VM is pretty slow (this is fixed in next version - Flash Player 9 will have JIT and should be available on Linux as well).

Player availability is still one of the big problems with Flash : it's a closed source player which is not available on all platforms (and of course not on Lynx ;). Some people are working on an open source Flash Player (FSF project named Gnash). Let's wish them good luck !

Yeah, I'm aware of haXe.

Problem is, ActionScript skills are "portable"; haXe skills aren't. Which means that if I use MTASC, I can (kinda sorta) do one-off consulting work on other people's Flash projects, claim Flash/ActionScript exeperience on my resume, etc.; if I choose haXe, I'm pretty much limited to living in a cave.

While we're at it, thanks for your wonderful work!

I finally made sense of OMake. It wasn't easy - I guess the authors didn't really think about migration from "make".

1) Where there was one Makefile, I have 10 files now: OMakefile, OMakeroot, OMakefile.omc, OMakeroot.omc, .omakedb, .omakedb.lock, src/OMakefile, src/OMakefile.omc, res/OMakefile, res/OMakefile.omc.

2) I can't use wildcards in dependencies. This might make sense for C or OCaml, but is utterly dumb for ActionScript (or Java), where you typically compile a directory of related files, and refactor stuff into new files a lot.

3) I can't use the "cd" command in the build process. (This is why I had to add OMakefiles in subdirectories.) For that matter, I can't use "del" - I'm on Windows, and "nmake" understands it fine, but OMake has its own shell interpreter and chokes.

4) I have to specify .PHONY for clean. Otherwise it just plain doesn't work. No idea why; good old make did fine without .PHONY.

This was just the issues encountered in migrating a really small project with one output file and six source files.

OTOH, after all this pain, the filesystem-monitoring part works great. It really is the productivity boost I had imagined. Now I want a 3-position graphical indicator: build succeeded, build in progress, build failed :-)

Bottom line: Certainly not a drop-in replacement for make, as I had hoped. Very good functionality, but will take half a day to set up, and the docs are mostly irrelevant if you aren't working in C or OCaml.

Vladimir Slepnev: I finally made sense of OMake. It wasn't easy - I guess the authors didn't really think about migration from "make".

That's a fair point. I should have pointed that out.

Vladimir Slepnev: 1) Where there was one Makefile, I have 10 files now: OMakefile, OMakeroot, OMakefile.omc, OMakeroot.omc, .omakedb, .omakedb.lock, src/OMakefile, src/OMakefile.omc, res/OMakefile, res/OMakefile.omc.

In your case, you might be able to get away with just OMakefile and OMakeroot at your top directory by using a .SUBDIRS rule with a body in your top OMakefile. A .SUBDIRS with a body means that the body will be applied in the subdirs, so you don't need separate OMakefiles in them, as documented here. The .omc and .omakedb* files are, of course, generated; you may wish to tell your version control system to exclude them from consideration, if necessary.

Vladimir Slepnev: 2) I can't use wildcards in dependencies. This might make sense for C or OCaml, but is utterly dumb for ActionScript (or Java), where you typically compile a directory of related files, and refactor stuff into new files a lot.

I don't know what gives you that idea; see here regarding "implicit rules" and wildcards.

Vladimir Slepnev: 3) I can't use the "cd" command in the build process. (This is why I had to add OMakefiles in subdirectories.) For that matter, I can't use "del" - I'm on Windows, and "nmake" understands it fine, but OMake has its own shell interpreter and chokes.

Here's the cd documentation, and here's the unlink/rm/rmdir documentation. The nice thing about having these built-in functions is that they work on either UNIX or Windows systems.

Vladimir Slepnev: 4) I have to specify .PHONY for clean. Otherwise it just plain doesn't work. No idea why; good old make did fine without .PHONY.

I suspect that OMake works by literally treating rules as functions taking files to files, so .PHONY serves the same purpose as "void" in C/C++/Java. The .PHONY docs imply as much: "A 'phony' target is a target that is not a real file, but exists to collect a set of dependencies." They use the example of the "install" target. It's easy to see that "install" and "clean" both fall into the category of "not a real file," and therefore are "phony" targets.

So I think points 1-3 are easily addressed with a bit more familiarity with omake, and point 4 is correct as stated. Regardless of that, your conclusion is perfectly sound: it isn't a drop-in replacement for make (it's quite a lot more powerful than make). Your first time out with it might take half a day, but future OMakefile/OMakeroot development can be much, much faster. Finally, I think most of the docs are perfectly applicable, but no doubt writing a good set of rules for languages other than C/C++/O'Caml will pose some initial challenges also.

Good points all. I'll take note :-)

Re wildcards: as far as I can see, I can't have a dependency like "a.foo: *.bar". Implicit rules don't help, unless I'm being dumb. But this restriction may actually be a good thing - not sure yet.

Yeah, I eventually figured out cd and rm. Not so hard, just a bit different.

.SUBDIRS with a body sounds like a really good idea. Will do that.

Regardless of the problems, OMake will definitely replace make in my personal ActionScript projects. I can't yet push it at work - the current project takes a night to build (C++ with heavy Boost), and the number of Makefiles is in the hundreds or even thousands, I haven't counted.

Thanks!

Re wildcards: as far as I can see, I can't have a dependency like "a.foo: *.bar".

Assuming *.bar refers to source files, not generated files, then a.foo: $(glob *.bar) should work.

Will try.

With respect your point 3, are you aware of the existence (and failure) of the (attempted) move to syntax aware editors a decade or so ago?

Syntax-aware editors are in common use by virtually all Java developers, and have been for about five years. The editors track keystrokes, and interactively calculate compilation errors, syntax highlighting, style issues, and possible bugs, updating all of that in sync as the user types, as well as offering various semantic code restructurings. Syntax-restrictive editors, which prevent all invalid entry by requiring only validity preserving operations, failed due to usability issues.

On the continuous testing front, there exist systems that will automatically retest on user entry, but they are somewhat clunky due to the need to rerun all tests. Commercial systems which will 1) allow the developer to only run tests that could fail (based on previous test runs, awareness of changed code, and code coverage data) and 2) allow developers to checkpoint their codebase and run full build and tests on a remote server, reporting results back when done, should be available in July (unless we slip, which we won't). Between those, it's only a small step to practical continuous testing. I expect IDEs with continuous testing to be commercially available in the next three years in the Java space, and shortly thereafter for .Net developers.

Commercial systems which will 1) allow the developer to only run tests that could fail (based on previous test runs, awareness of changed code, and code coverage data) and 2) allow developers to checkpoint their codebase and run full build and tests on a remote server, reporting results back when done, should be available in July (unless we slip, which we won't).

Just curious, what tool/company is this?

from JetBrains. Here's the roadmap http://www.jetbrains.net/confluence/display/IDEADEV/Demetra+Roadmap .

Disclaimer: I work with but not for JetBrains, and do not speak for them.

Do you believe in the reuse of combinator libraries (DSELs)?

Guess yeah. The success of Rails shows that metaprogramming libraries can be successful. But whether something is a combinator library or a full-blown language doesn't matter to the user one whit :-)

"Do you believe that a HyperCard stack can be a top-selling game?" Yes, the example being Myst. But few Myst fans ever heard about its HyperCard origins.

What the business world REALLY yearns for is a "business DSL". Rails is a "Web 2.0 business DSL" - the next best thing :-)

..and does a great job explaining them in the first half of Patterns of Software

Two or three new abstractions are enough for most medium-sized programs.

Can you give an example? Perhaps we are using the word "abstraction" to mean different things?

For me, every good routine is an abstraction, so I can't see how you can reduce the number of abstraction to two or three...

You know how there are some big abstractions that introduce new vocabularies: POSIX files, Emacs buffers, BSD sockets, Enterprise Java Beans, and so on. I like to have a minimal set of these abstractions and to use them very directly in programs. If a program is supposed to copy one file to another then I would like to see calls to open(), read(), write(), and close() all sitting there together near the top level.

The good thing about these big and common abstractions is that they give you a framework to think in. For example, you can design a sane Unix program by imagining which systems calls it should make (how it ought to look in strace) and then writing the code that "fills in the gaps" in the simplest way. The same works for imagining how client/server programs should look in Ethereal, what processes and tables to have in Erlang programs, and what buffers and text properties to have in Emacs programs. If you get the initial sketch right then you'll probably end up with a simple program that won't go far wrong.

If your head is too high in the clouds then you can go really far wrong without even noticing. This happens more and more in proportion to the amount of "black box" code between the application programmer and the ground-level primitives that need to be used in a sensible way.

Really The Art of Unix Programming says it all much better than I can.

P.S. "Abstraction is overrated" is what I always think after my annual chat with CLOS hackers. :-)

I think I understand what you have in mind, but I am not sure the best way to put it is to say "abstraction is overrated"...

First, it seems you favour big abstractions - yet these are built on top of lower and simpler abstractions. You don't like the semantic gap this creates (the distance between the abstraction and what really goes on). This is a well known issue, of course. I think that be defining good abstractions, with clear semantics, this problem can be mitigated.

Second, it seems you like application frameworks, rather than ADTs and such. It is important to note that these two classes of abstractions solve different problemsw (e.g., STL vs. MVC or Rails). More interesting is the fact that not long ago FW were considered to be doomed, since it seemed that most good FW solve only one thing: i.e., they were basically MVC frameworks. Nobody managed to show a wide variety of FW. Things have changed, as is witness by thins from Rails to Spring...

Finally, you like languages that provide a flexible and very useful set of builtin abstractions (e.g., process in Erlang, lists in Scheme/Lisp). This is one reason why you don't find a great need for abstraction facilities (e.g., ADTs). But, on the other hand, it just means that you favour another *kind* of abstraction. Thus, you are a fan of programming languages as abstraction mechanisms. I agree, of course. No wonder we are haing this disucssion on LtU...

Thank you for clarifying my thoughts!

The picture you paint sounds right, except that I do like ADTs (like 'file', 'buffer', and 'socket') and I don't like frameworks (assuming framework = library + indirection). I wonder how I gave the opposite impression? I do like to be economical with ADTs, e.g. to use a plain list of strings instead of inventing a DirectoryFileList.

"Any problem in computer science can be solved by one more level of indirection." That philosophy is actually what I am objecting to. On reflection I think the problem is that it takes a lot of work to make a really good abstraction and most frameworks / metaobject hacks / code-walkers are too ambitious. They hide things that you actually should know about.

Really The Art of Unix Programming says it all much better than I can.

There has long been the saying that those who don't understand Unix are doomed to reinvent it. Poorly. My catty thought for the day was "Embedded Systems Programming is the last refuge of those who don't understand Unix."

Which probably wins me The Sugar Coated Sandbox Award.

I hear what you're saying, but it's also true that Unix doesn't understand modern embedded systems programming. Thankfully, Unix, in all its incarnations, is adapting, as it always will. We can profitably put a Unix-alike in an MRI scanner, but we can't put it in a pacemaker yet.

My cynical thought for the day is that I currently work as an embedded systems developer. My main qualification: "Had an 8-bit micro as a teenager."

This sounds like you don't believe in Abstract Data Types and encapsuluation. That every function should know the details of the data structure it is working with. Is that about right?

I don't think this works very well as systems get larger.

That is about right. Unix and Emacs suggest to me that it works exceptionally well for some very large systems. I wonder what's wrong with other large systems that prevents it from working for them too?

My opinion is that you can write a large system in just about anything, and still have it work. Unix is built on C, but I don't think you would advocate C over a language without all the razors and barbwire.

I'm curious, what do you think of Lisp's macro facility? Are you totally against it?

What you say reminds me of my comment that good API design is like finding a basis for a vector space. You have to find a minimum set of abstractions that spans the whole space of problems to be solved, constructed such that no single element can be expressed as a trivial combination of the other elements. So if abstractions are overrated because of this, then vectors are overrated too. :)

Thanks Peter! That was an interesting paper. Although I'm not really all that familiar with Eiffel's SCOOP concurrency model, based on what I do know it sounds like Eiffel would fit into your proposed schema as well (there seems to be a lot of similarity between the E and Eiffel approaches).

Classes in languages like C# and Java have always seemed to rigid to me. I've always been partial to OO in languages like Dylan/Common Lisp (CLOS) and open classes in Ruby.

But prototype-based OO seems to be even more unconstrained than static structures.

Here is an interesting paper on the psychological aspects of prototypes versus class-based OO. The author's contention seems to be that prototypes are a more natural way of thinking about objects.

I have similar misgivings about objects and prototypes. To me the reality of a thing or group of things is a method of "parsing" or recognizing that thing. This usually amounts to a set of actions and the results they produce. The results can be described as information and stand for the thing. Not suprisingly such a representation often looks like an object definition but put the emphasis in the right place. I would also define recognition as an event. A formalization of these ideas is found in Syntactic Pattern Representation.

The author's contention seems to be that prototypes are a more natural way of thinking about objects.

I believe, but can't prove, that to a first approximation, exactly zero programming language issues will be resolved by appealing to how "natural" a given solution is.

I believe that classes have to many responsibilities: defining types, defining behavior and creating objects. All three features are desirable but one hammer to nail them all is awful. A better idea is to have separate features for each with decent combinators for mixing them. An object model I think it's great is this, but E's syntax could be a bit terser IMHO.

Part of me agrees whole heartily.

So let's try pick a language based on it. On one end we have something like C++, and at another something like Common Lisp.

C++ is horrible, it's in your face and Scott Meyer's has written Books and Books on how to write C++ without it upping and biting you in the bum in some very very obscure corner cases.

Common Lisp on the other hand disappears. You can write anything and everything in Lisp anyhow. And in the hands of an eloquent Lisp Guru it is all your comment can wish.

However the thought of Common Lisp in the hands of a very large team of so-so programmers generating mega slocs of code adapting to shifting goal posts while under huge schedule pressure gives me the cold shudders.

Common Lisp doesn't really disappear, it slides under the surface requiring deep insight and understanding of what it is and how it does it.

So some measure of Bondage and Discipline, some measure of idiot proofing, because there are days when I'm an idiot. And under shifting goal posts and schedule pressure we are all less bright than we wish to see ourselves.

So I agree with your post, but I'm not sure I can convert the warm fuzzy feelings it generates in me into programming language design criteria.

I disagree with that. A good programming language focuses your thinking without dominating it.

Exactly. It's impossible for a programming language to disappear; it'll always be there influencing the way you think about problems.

For example, a very lispy way of thinking about a lot of problems is to simply shoehorn your data into some list form, and then you'll have a lot of nice tools for dealing with the data. It may not always be elegant, but it's remarkably easy to fire off some deeply indented algorithm involving REMOVE-IF and N-MOST-EXTREME and a few lambdas.

In contrast, Haskell seems to encourage programmers to define their data structures properly, then make functions that deal with those data structures, then eventually get around to writing the main program logic. The lazy evaluation semantics also encourage a different way of thinking about a lot of problems. Suppose, for example, that you wanted to find the N smallest elements of a list of type "Ord a => [a]". In most programming languages, the natural thing would be to define a function specifically for this purpose. But in Haskell, it's actually a valid option to say "take the first N elements of the list, sorted using this selection sort that I already have".

In Java, objects dominate your thinking even when they shouldn't. I've seen APIs for downloading a file which actually require you to instantiate an HTTP downloader object, call the setUrl() method, and then control it via other methods. This is fine for heavyweight control of the downloading process, but for most simple cases it's object-oriented overkill. Deep object hierarchies are encouraged (though I'm not sure if it's the language or the people who encourage this).

I believe, but cannot prove, that no single programming language can encompass all the different ways of thinking about programming. I also believe that many programming languages will still try to do so, and that the Lisp family of languages will cling tenaciously to its current undead status because its easy quick-and-dirty malleability makes it a prime candidate to assimilate new styles of programming, albeit not as elegantly as a language designed from the ground up for the purpose.

I noticed in the recent Ginseng paper discussed on Lambda that they used real-world, open source projects to apply their ideas. I think this is great, and hopefully more papers will take this approach. However, I think this approach will remain ad hoc, and not be the "scientifically gathered statistical sample" you are looking for.

The big trouble with that one is yes, Academics do these studies, on small teams writing micky mouse systems.

It's way too expensive to have a large team writing a very large system... and having another 2 other teams trying other process / language variants and a control team doing just the usual thing.

But unfortunately all the problems that really matter now are at the "largish team (5+)/ large system (200000+ SLOC)" scale.

Once you get into that scale it just too noisy, too many variables, etc.

Even at the small scale end it hard to get a Good experimental design since the primary source of variability (As Alistair Cockburn points out) is the Human one. Which Human is doing the programming? How is he/she feeling today? Was his wife nice to him last night?

My absolute favourite paper in all the CS literature is..

Characterizing People as Non-Linear, First-Order Components in Software Development by Alistair Cockburn.

My absolute favourite paper in all the CS literature is..

Characterizing People as Non-Linear, First-Order Components in Software Development by Alistair Cockburn.

Having just read this, while I probably wouldn't say it is my favorite paper in all CS literature (perhaps in SE literature?), this is an extremely good read.

As I have noted elsewhere, I strongly believe in Quasi Natural Language as a viable notation system for non-math geeks.

I know I can communicate with fellow programmers in *unambiguous* natural language.

I believe that subset of Natural Language to be parsable with a Parsing Expression Grammar; I believe that any potential ambiguity expressible in a QNL Grammar can be avoided by providing the User with negative examples of what pathological constructions should not be used or delt with by an IDE -- particularly if we move to a conversational interface where information extraction techniques can be combined with a restatement of the system's understanding or query for clarification.

However, I also believe that virtually all PL Researchers have written off NLP approaches or just aren't familiar/comfortable with the current state of the art in this domain which creates a self-fulfilling prophesy that we will never see a serious NL-based programming language. Likewise, NLP researchers might benefit from delving into conventional PL Research, but have probably written off our work the second they saw our notation conventions which in all candor often take a non-trivial amount of mental overhead to transliterate into English on an initial reading.

Mainly, I know that novice End Users, no matter how motivated they might be to take up some measure of programming to accomplish whatever they have been tasked with on their Day Job, will not embrace seas of nested parentheses, braces, C type definitions, or whatever other terse syntax might seem most "natural" to us after years of immersion in "the literature". I also know that I can and have explained the underlying ideas behind mundane programs to them once I cut through the syntax.

I also believe that our notation choices make Computer Science look scary and intimidating to women and minorities, which is not a good thing.

If you find yourself in agreement with any of this and would like to help us pursue QNL End User Programming, drop us a line at The Institute for End User Computing, Inc.

I also believe that our notation choices make Computer Science look scary and intimidating to women and minorities...

Yes, I agree. The current computer languages and interfaces are far less End User Friendly than is possible.

But, there are deep mathematical reasons why the heart of programming language design will actually go in the opposite direction.

As a counter example I hold up the work of boost.org and Alexandrescu in C++ template design and meta programming.

The syntax of C++ template meta programming language is an absolute horror and as unfriendly as you can get. Yet even if you were to devise the most pleasant and courteous face to it...

• What the template meta programming guys are doing will remain deeply subtle requiring minds of profound genius to progress, probably quite beyond Joe Average programmer today. (I'll admit what they are doing strains my brain to the max.)
• Since the easy computing tasks have been done... The next generation of real world tasks will require these tools.

If you want to write down something very concisely and try to catch a lot of possible misunderstandings, you probably end up in something like juristic prosa - not that readable, at least if you are not used to it. It is still my hope, that we don't need to understand public static void main() to figure the functionality of a piece of code.
So i believe but i can't prove, that it is possible to get rid of all the technical artefacts a programming system implicates, and thus make it easier to understand a program.

Cheers,
Ralf.

And the same piece of program can be viewed as graphics, strings or whatever depending on the problem at hand.

Having written some DSL's myself, and use several others I'm finding more and more I provide/download the Domain Specific framework for my language of choice and use that. Better faster more powerful.

When stuck in a DSL I find I have to learn yet another syntax, and I have lost all the power of my language of choice.

Personally I'm starting to think DSL's are so popular because language tools have become so powerful that DSL's are very easy to create. So Oo looky, I have created my own language. In the mean time it would have been easier and faster and more powerful to just to use a scripting language + a framework as a DSL.

I didn't say prove... but can you defend this assertion a little?

Actually, you said _can't_ prove ;)

I don't mean DSLs, to me a DSL is a language specific for some problem domain "out there"; like a language for performing matrix arithmetic, or a language for the AI in a game. These sorts of things were not what I meant.

In my opinion, some programming paradigms are better at certain parts of systems than others. Imperative is good for the top-level co-ordination and IO of a system; declarative is good for data access; and logic programming is good for business rules and conditionals.

Instead of trying to beat one language into accepting multiple paradigms, or tweak the paradigm until it matches the language how about just using different languages for these separate parts? The Haskell IO Monad could be regarded as a case of trying to force incompatible paradigms together.

How about just putting the IO and interface management in an imperative language, and once the data is gathered the imperative part of the program calls some Haskell functions? The imperative part would then also be free to use a dynamic or declarative language to assist with its UI as well.

Achieving this would require much better integration between languages. Possibly when designing a language people should think not about how an entire program could be written in this language but how could a small chunk of logic implemented in this language be integrated into a larger program written in another language?

"How about just putting the IO and interface management in an imperative language, and once the data is gathered the imperative part of the program calls some Haskell functions?"

That's more or less what the IO monad does. It just treats the imperative code as yet another Haskell value while it's at it.

I like programming in R (a stats DSL). I don't mind octave a matrix DSL. But I hate hate hate hate GNU linker script.

I do embedded systems development for my bread and linker script is a classic DSL gone wrong.

It's obscure, the error and warnings are very weak by the standards of modern laguages.

But what gets to me is as soon as you step one tiniest step beyond the Specific Domain (assigning ELF segments to address regions) it does nothing. Can't even add two numbers, not even a sane conditional.

The net result is you tend to generate linker script either via the C preprocessor or a scripting language like ruby.

Moral of the Story. It would all be so so much easier if instead of linker script it a general purpose scripting language such as ruby / guile / ... had been used.

Of course, historically it all happened the other way round, in that linker script probably evolved long before the scripting languages.

Partial evaluation was one thing I wanted to write about, but forgot. It sounds like a really good idea, but not widely implemented. Any pointers to useful work?

A good book to start with about partial evaluation is Partial Evaluation and Automatic Program Generation.

Now reading. Thanks!

Here's a good place to look partial-eval.org.

* Partial evaluation...
Excellent! I Agree.

* From the ashes of JVM, .NET CLI ...
You aren't working on Parrot are you? Hmm. I'm prepare to "keep an eye on the field", but I wouldn't bet on this one.

* C will outlive us all.
Can I quietly go and shoot myself now. Please no, no, NO!!!

* Eventually the tide will turn on the current fashion for scripting languages..
Perhaps, but I don't believe that tide will return to C/C++/Java.

* Concurrency.
I'm going to be a heretic here and say 99.9% of concurrency problems are in category "Well don't do that then" and the only language support needed are tools to detect foolishness and a larger clue bat to use on nidjits that do.

I'm not working on Parrot (or any other VM/JIT Compiler) and know little about it. AFAIK it's a dynamically typed VM which does have its uses but I doubt it will take over the world.

* Eventually the tide will turn on the current fashion for scripting languages..
Perhaps, but I don't believe that tide will return to C/C++/Java.

I'd agree, I should have also mentioned that now that Ruby, Python et al have become popular many of their LISPy and functional features will be expected in newer languages.

"* C will outlive us all.
Can I quietly go and shoot myself now. Please no, no, NO!!!"

Playing right into C's pointer, if everyone that doesn't want C to survive kills themselves at the prospect of C's survival then C will survive.

Considers matter for a few minutes.. goes kills self.

Partial evaluation will start to make commercial inroads...

Do you know of any commercial organizations currently doing research into PE?

Supercompilers LLC seems to be doing Supercompilers for Java. Not exactly partial evaluation but they want to accomplish the same things.

I really, really wouldn't have pick that one. But that could well be because I'm ignorant, so please tell me more.

I have always regarded coroutines as "Like thread's but less efficient since you the only way of getting the other routine going is to do a context switc