Wed May 20 20:50:29 CEST 2009
ltu thread on the future of programming
I'm tired so time for wild associations.. But these two posts I found
Since I asked the question....
...you may have guessed I had a few answers myself but wanted to see
what else I could shake loose from you guys first....
Moore's Law and Feeping Creaturism implies ever larger and more
complex systems. The solution to which is not ever larger and more
complex languages, but simpler languages, both syntactically and
semantically that permit tools to assist more in...
* Code Generation.
* Reengineering, understanding and visualization of very large systems.
* The ease of analysis, rewriting and refactoring of the Joy
language will make the Joy language the "parent/inspiration"
language for the next generations of languages.
* Syntax and semantics will become simpler. ie. Towards a simpler
version of Lisp/Scheme or Forth.
Some other beliefs I have stemming from Moore's Law and creeping
featurism driving the exponential growth in software complexity...
* Linear logic will supplant GC.
* Lazy evaluation is not an optimization (or hard to implement nice
to have). It's mathematically the only way to have a consistent,
analizable and manipulatable system.
* Single Assignment or Joy / Forthlike no assignment will become the
* Cyclic dependencies at one or more levels (package / file / class
/ ...?) will be explicitly disallowed by the tools.
* Static typing will lose to Dynamic Typing, and Dynamic Typing will
lose to compiler inferred Static Duck Typing.
* Languages will provide a transparent "each object has one thread
inside it, every method invocation is just another event in that
object's event queue" view to the programmer.
* OO hierarchies are too reminiscent of pre-Codd hierarchical
databases. And SQL ignores Codd on too many points. 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.
Can I prove any of this?
No. Not now. Not yet.
But it's what I keep my mind occupied with when I'm not earning my
The solution to the concurrency problem...
Will be a two language solution:
Language A: be a sequential language designed from the ground up to
be easily parallelizable at the meta level. It will not be a
parallel language with parallel programming constructs, neither
message passing nor multi-threading nor explicit effects. It will
have a lot of restrictions that may seem strange to the sequential
programmer but they will all be there for a good reason which is...
Language B : which is a declarative meta-language which will allow a
different programmer to examine and reason about both language A and
it's potential run-time environment and then re-factor it's code to
run in parallel on the chosen platform(s). At first most programs in
language B will be heuristic and specialized for particular
applications, but as more experience is gained with particular
algorithms (in language A), and with particular hardware
configurations, patterns will begin to emerge and language B will be
able to support automatic parallelization across certain categories
of algorithms on certain categories of hardware. Language B will
have all the nice syntactic sugar parallel programmers love, whether
it be in the language of threading, effects, messages or something
http://lambda-the-ultimate.org/node/1439#comment-16479 (canvas vs.
http://www.info.ucl.ac.be/people/PVR/flopsPVRarticle.pdf (4 x a 4-layer language)