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?"
Functional Programming, not First Post!
The dangers of excessive individualism are nothing compared to the oppressiveness of excessive collectivism
Nothing is permanent. However, after so long you're gonna start getting rehashed methods. It's like a big circle everyone is running around in, looking for the absolute best. Yes, there are ones better than others, but there is no perfect one. Need OO for a simple 10 line php script? Hell no, unless you're relying on a lot of 3rd party libraries. Need Ruby on Rails for a statistics generator with no front end what so ever? Nope. It all changes, but there is some good stuff we take along the way. But I don't think we'll ever find something that is just "perfect", more of a never ending quest to find the better one, and to stay on top of all the ones from the past.
No new 'paradigms' until we get all the other 'salvations' under control.
Who are the next programming models?
That's the first one I learned. Now I'm in to the lasagna model, with nice layers. Anything beyond that? Well, not me.
Here's a new model who can program:
"Prior to being crowned Miss Universe 2005, Natalie was a motivational speaker, model and a fundraiser. She recently received a Bachelor's Degree in Information Technology Management and Marketing from Ryerson University..."
Life is like a web application. Sometime you need cookies just to get by.
In a specification oriented programming model, you specify the behaviour, not all the million little steps that are needed to perform it. A specification oriented programming model is independent of the underlying techniques, such a networking protocols and marshalling techniques. I think such a specification oriented programming model should be data oriented, meaning that data is the starting point, not an event driven GUI front-end, as it is now with most programming models.
I won't discount the importance of Ajax and "RIAs" as a deployment model -- even as a kind of domain within in which system architectures could be grouped. But these aren't new programming models. We use the same old programming models to build new kinds of apps.
Examples of Programming Models:
0) Hardware based programming (plugboards etc)
1) Stored program (program as data)
2) Assembly programming
3) High level language programming
4) Structured
5) Functional
6) Object oriented
7) Aspect oriented
Post may contain irony: discontinue use if experiencing mood swings, nausea or elevated blood pressure.
Actually, he missed the anti-pattern. It's really: One of the common anti-patterns is over-relying on tools and frameworks and programming paradigms and processes instead of improving the skills and knowledge of the people doing the programming.
I've been programming for a long time too, and I don't think that new programming models do all that much for productivity compared to finding good people or investing in improving the people you have. The recent Joel on Software article discusses this at length. This is one of the big reasons I'm so interested in agile methods and principles.
Helping with organizational effectiveness is our job.
Rich Internet Applications are hardly the next "new" thing. The idea of doing asynchronous applications HTML/DHTML has been around since at least 1997. It's only the recent broad-based browser support that has led to the growth of AJAX, etc. However, trying to program an RIA that targets multiple browsers is like trying to write portable C code all over again. Thought CSS was screwed up between Firefox and IE? Try looking at the JavaScript implementation differences between the two platforms. Throw in a bit of Safari and Opera and you have all the makings of some super-gross client code.
Well lets see now, programming metaphors for the modern age?
Theres oil-oriented programming (everything is a pipeline), terror-oriented programming (everything is a suicide bomber) and dollar-oriented programming (everything has a mandatory dollar sign at the beginning), to name but a few.
In the free world the media isn't government run; the government is media run.
http://www.nwcpp.org/Downloads/2005/Lock-Free.pdf
-- -pjk Perry Kundert perry@kundert.ca http://kundert.2y.net
See Beating the averages for a well-written and thoughtful essay.
In a nutshell, languages themselves vary in power. No one disputes that. All things being equal, you should generally choose the most powerful language you can all the time. As we move more and more to server-hosted software, your choice of language is incredibly important because a) it's your choice, not forced on your by being the language of the OS and b) it can be a huge competitive advantage.
Matz (Ruby's creator) acknowledges ripping off ideas from Lisp (but putting a friendlier face to it). Python is Lispy. Javascript has been called Lisp in C's clothing. These are all functional languages, or can be used functionally.
Graham noted how all languages are trending more towards Lisp in terms of features (see the essay linked above). Want further proof? C# 2.0 is getting lexical closures. Innovation from Microsoft! These were available in Lisp for 30 years, javascript for 10 (since it was created), they're in Perl 5, Ruby, I can go on...
If languages continue to become higher and higher level, wouldn't we need to investigate this weird AI language from 1958 and see what features it doesn't have in order to do more meaningful research? 'cause these days, all the "new" features of today's languages are decades old...
Functional programming greatly simplifies the task of the programmer by removing execution order from the things that programmers have to keep track of. Just as garbage collection in Java got rid of the need to recycle memory manually, so in Haskell the execution order is a matter for the compiler to optimise rather than for the programmer to worry about.
Historically functional programming has had problems doing IO: languages have had to admit impure side effects to do IO. Haskell has a wonderful solution to this problem, which unfortunately this post is too small to contain (really: go see!).
Paul.
You are lost in a twisty maze of little standards, all different.
Pick a good language/environment, even a not so good one, say C and a text editor, and then use some engineering discipline to really DESIGN THE DAMN application. Don't just throw features at it, don't just hack the code. Think about the real world problem you are supposedly trying to solve and work your way through it. Build it right, you don't have to worry about operation, maintenance, or longevity. Build it wrong, and you make a career of fixing it.
Ooops, maybe I've stumbled onto the real secret of IT...
Behold, this dreamer cometh. Come now, and let us slay him... and we shall see what will become of his dreams.
I'm increasingly finding that web programers ( and their managers ) can be like that. Meaning that they're increasingly trying to find ways to make "HTML-server based application with some client interaction" sound new and exciting.
Not that using advanced Javascript||.NET||Java||C||Objective-C||Python||wh atever on the client to communicate to a server running Perl||C||Python||Java||.NET||Ruby||Objective-C||wh atever using XML( or whatever ) isn't interesting or useful, it's just... like calling a personal log-format web page a 'weblog'; it's not really something new in the abstract, it's a new way of doing something that's been done before. In other words, it's marketing hype to make you think you're seeing something truly new. At least in general, the implementations are new, not the ideas.
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.
Breaking Into the Industry - A development log about starting a game studio.
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 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!
"[Regarding the 'cloud,'] ownership was what made America different than Russia." -- Woz
All improvements I have seen the last 10 years in programming language have already been done in Smalltalk from the beginning.
/visual-basic (user-interface) (skipped many ST examples)
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
* web-tools (ruby-on-rails (ruby is based on ST), seaside (build in ST))
)
Now tell me what it means. Specifically, tell me what expression it ends.In contrast, take this XML example:
</p>
Now tell me what expression it ends. See how much easier it is?See, that's the difference: In XML, the angle brackets aren't units really units of syntax in and of themselves; tags as a whole are. Moreover, in XML these units of syntax are self-discribing. Also, angle brackets are never nested; they always occur in "" pairs without any more brackets between them.
"[Regarding the 'cloud,'] ownership was what made America different than Russia." -- Woz