What are the Next Programming Models?

jg21 writes "In this opinion piece, Simeon Simeonov contemplates what truly new programming models have emerged recently, and nominates two: RIAs and what he calls 'composite applications' (i.e. using Java, .NET or any other programming language). He notes that Microsoft will be trying to achieve RIAs in Avalon, but that it's late out of the gate. He also cites David Heinemeier Hansson's Ruby on Rails project as showing great promise. 'As both a technologist and an investor I'm excited about the future,' Simeonov concludes. It's a thoughtful piece, infectious in its quiet enthusiasm. But what new models are missing from his essay?"

Comments

Lock-free and Wait-free programming.

[pjkundert]

For low level stuff, Lock-free and Wait-free algorithms are the next hot thing. For massively parallel systems, they provide levels of utilisation and efficiency that are un-reachable by using code involving locks.

http://www.nwcpp.org/Downloads/2005/Lock-Free.pdf

Re:We need a way to avoid duplicating work

[Coryoth]

A programming method that involves designing an application such that you break each top level logical component/ability down until you a) know that you have to impliment it or b) it is found to have already been done.

That already exists, and the specification is indeed amenable to proof tools (several specification languages use HOL as their proof assistant even!). Check out B-method, HasCASL, SPARK, Extended ML, or even Z and VDM. There are tools like Perfect Developer. There are specification extensions to Java like JML that support extended static checking and proof via other tools.

Uptake has been slow, and the tools associated with this stuff are still maturing (despite the fact that formal specification is a relatively old field - tracing it's way back to Djikstra and Hoare in the late 60's). Doing specification properly tends to require a little more math background, and does take some work. More importantly, for a great many projects, it simply isn't suitable. There is no magic process you can follow that makes everything work, and there is no "final" programming model. There are whatever mix of techniques and models suit the project at hand. Good developers are ones who know lots of models and techniques and adapt them to best fit the problems at hand.

That said, specification is sorely underrated and underused as a programming technique. Too few people are well acquainted with it, and almost all the complaints that often get raised are based on myths and misnomers. It's not right for everything, but there are plenty of places where perhaps it could and should be used. Knowing how to do proper formal specification is simply another weapon in a good developers arsenal, and I wish more people spent the little extra time required to learn something about it.

Jedidiah.

The Next Programming Model I Want

[ZorbaTHut]

nobody seems to be interested in developing.

I program console games. We've got very strict RAM limits - from 384kb on the GBA to 64mb on the amazingly spacious XBox. (With some curious design decisions that can make it feel smaller than the 32+4mb PS2, but I digress.)

On systems like this you've got to track pretty much every byte. One meg of garbage collector overhead means one meg you don't have available for useful stuff. I generally don't use standard dynamic allocation - at all - it's just too expensive. Maybe one big pool to load files into on the PS2 that can be cleared entirely between levels. Nothing like that on the GBA of course.

As far as I can see, there's three languages that provide this necessary feature - ASM, C, and C++. So I use C++.

I'd love to see an "improved" C++. But it seems like every time someone decides to improve C++, the first thing they do is tack on a garbage collector and get rid of direct memory access. And, you know, those are features I desperately need. Frequently those unwanted features are the only way I can even display graphics.

And yes, it's possible to write modern games in languages with garbage collectors (as I understand it, the entire Jak and Daxter series was written in Lisp) but I know what lengths I go to to squeeze performance out of these systems - I really don't need a garbage-collected albatross hanging off my shoulder.

And before anyone says "garbage collectors are faster than deallocating things manually!" - if I don't *allocate* anything, what makes you think I need *deallocation*? There is no heap. Move on.

Re:Afraid of parenthesis? Stay away from XML!

[mrchaotica]

It just is.

Also, the facts that they're never nested directly next to each other and that they describe themselves helps. With LISP you get stuff like

(((((this)))))

where it's difficult to count the number of parens, and what they close depends solely on their placement. In contrast, something like

<1><2><3><4><5>this</5></4></3></2></1>

would be the equivalent in XML. As you can see, even though there's no whitespace it's still easier to read because each tag describes what its closing and is easier to pick out from its neighbors (for easier counting).

Of course, all this ignores the fact that LISP and XML can't be directly compared anyway, since one is a programming language and the other is a data format!

Smalltalk still is the silver bullet

[DirkWessels]

All improvements I have seen the last 10 years in programming language have already been done in Smalltalk from the beginning.
That is because everything is an object, even the programming constructs (like classes which are objects, and if/then which are called #ifTrue:ifFalse).

The future languages might even be more dynamic, and include Lisp (or Hascell) like constructions that solve problems by defining the answer (functional and logic programming).
Which is in the smalltalk-syntax: [i][:x| x*x=5.0] SolveFor: #x.[/i]


While smalltalk (ST) is advanced, it also encounters the problem of managing 60,000 classes (or more). And everyone can see that simply grouping the classes in seperate modules does not help, which is done in Java. Even the Object-class should be redefinable, preferably on local level. There are some programs on top of ST that help a bit, but I would personnaly like to see it a bit better
Another problem is that there are so many interfaces to different storages and systems. So we need C-interfaces, C++-interfaces, SQL-interfaces, XML-interfaces... etc..

So any future programming model should have:
- objects everywhere. (ST)
- Be very simple and compact. (ST)
- Easy to use and understand. (ST)
- allow scripting (or runtime compilation) possibilities (ST)
- easy modularizing of classes, methods and objects.
- Allow distributed data and execution. (ST)
- Allow easy interfaces to different storages and systems.
- Integrate easily in the system

Any future Object-system will be graphical and allow different programming models (logical, functional, procedural, storage, user-interface) to be build in graphical building-blocks..
Already we can see some of this happening in:
* XML-tools (data-definitions and interfacing),
* visual-age (procedural program definition, ST again).
* net-beans / delphi /visual-basic (user-interface) (skipped many ST examples)
* web-tools (ruby-on-rails (ruby is based on ST), seaside (build in ST))

Beyond Aspect Orientation

[juanescalante]

I once read a paper written by Cristina Videira Lopes, a pioneer of aspect oriented programming, in it she stated that AOP is a significant breakthroug, but that the next step is to include elements of natural language in programming languages.

She says that natural language is not suited to write computer programs, but it has powerful elements that can be useful in transferring ideas more closely to the way we think. An example of such elements are temporal references such as before and after.

You can read the abstract to one of her papers here. Very interesting stuff.