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

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))