24 May
2010
24 May
'10
8:12 a.m.
On Sun, May 23, 2010 at 1:55 PM, <fons(a)kokkinizita.net> wrote:
I find this sort of thing absolutely beyond comprehension.
It's impossible to understand without knowing the boost::
abstractions, templates and god knows what else.
IMNSHO, the way any software works should be understandable by
a) knowing the language, b) reading the code, at least up to the
point that the reader can have an good idea of the big picture,
of data structures and control flow, only excluding application
domain specific details which require special expertise anyway.
If libraries are used to somehow extend the language rather for
encapsulating application domain specific algorithms, the net
result is code that is utterly unreadable to anyone who happens
not to use the same libraries. This is true for libs such as STL
and to a larger degree, boost.
Exactly.
The issue is that advanced programming concepts are being shoehorned
into a programming paradigm, and language, that is not supportive of
that paradigm. For example, functional programming, which Paul Davis
admits is difficult without garbage collection:
i also can't begin to imagine how to implement
scoped-lifetime objects in C. even without exceptions (which admittedly do cause some
conceptual pain in C++), the ability to know that wherever you return from within a
function, relevant local objects will be cleaned up has a significant simplifying effect
on the design of a function.
Which is why I brought up clojure. Assuming that we get part of the
"real-timeness" of our RT programming by using multiple processors
wisely, and given that we're hitting physics clock-speed limitations
towards further performance increases in single-threaded processing...
the winners will be those that can reliably and scalably orchestrate
multiple slower processors to run fast.
The functionality of "parallel" and "cloud" computation is
fundamental
to Clojure as a language. Instead of being add-on libraries, and even
worse, "design patterns" and "programming by cut and paste," which is
what most complicated library usage ends up being, especially if it is
a language extension.
If there are issues with these constructs or concepts, it'll get fixed
in the language; if implementations don't measure up, there will be a
language standard and reference implementations by which to compare
and dictate what's correct and documented behavior versus bug. If the
language ends up being widely used, then there will be plenty of
documentation and education on formerly esoteric concepts that are now
part of a language (much like how C++ and Java made "object oriented"
to be well understood, "promise" and "future" will be standard
cocepts
for the languages that get popular for parallel computation).
http://www.michaelharrison.ws/weblog/?p=239
.....
Clojure offers more than one option for achieving concurrency. Whereas CommonJS embraces
asynchronous processes, Clojure offers the programmer a choice of synchronized or
asynchronized tools for concurrency. And whereas JavaScript doesn’t offer you the
opportunity to spawn your own threads, Clojure most definitely offers you threads. Clojure
1.1 has added abstractions for promises and futures, and Clojure’s multithreaded
environment colors their usage.
In Clojure, as in CommonJS, a promise is also a stand-in for an asynchronously-computed
value. As Rich Hickey explains in his change notes for the 1.1 release:
( http://github.com/richhickey/clojure/blob/1.1.x/changes.txt )
A promise is a synchronization construct that can be used to deliver a value from one
thread to another. Until the value has been delivered, any attempt to dereference the
promise will block.
A future, however, represents a unit of computation that can be executed on another
thread.
Futures represent asynchronous computations. They are a way to get code to run in another
thread, and obtain the result.
Sean Devlin, the creator of the excellent screencasts at Full Disclojure (
http://vimeo.com/channels/fulldisclojure ), has a screencast covering promises and futures
( http://www.vimeo.com/8320428 ) He offers some examples:....
......
Again IMNSHO, a programming language should be used
'as is',
without trying to extend it or introduce concepts that are
not part of it ('shared_ptr', 'promise' (whatever that means),
'spromise' (whatever that means), etc.). All the rest is just
obfusciation, and useful only to some niche of 'believers'.
It's not obfuscation. It's the wrong-language-for-the-job desperately
attempting to represent a well-known, computer science concept:
http://en.wikipedia.org/wiki/Futures_and_promises
In computer science, future, promise, and delay refer
to constructs used for synchronization in some concurrent programming languages. They
describe an object that acts as a proxy for a result that is initially not known, usually
because the computation of its value has not yet completed.
The difference is that the example I posted -- 13 lines of clojure --
uses "promise" and "future" as built-in, semantically well-understood
language primitives along with some "markup" to distinguish different
mutable storage types associated with variable names
http://stackoverflow.com/questions/1028318/clojure-mutable-storage-types:
* Vars are like regular old variables in imperative
languages. (avoid when possible)
* Atoms are like Vars but with thread-sharing safety that allows for immediate reading and
safe setting.
* An Agent is like an Atom but rather than blocking it spawns a new thread to calculate
its value, only blocks if in the middle of changing a value, and can let other threads
know that it's finished assigning.
* Refs are shared locations that lock themselves in transactions. Instead of making the
programmer decide what happens during race conditions for every piece of locked code, we
just start up a transaction and let Clojure handle all the lock conditions between the
refs in that transaction.
Thus clojure has the needed functionality built-in to the language,
including new types of variables. It is designed to be used "as is"
and there are many excellent examples on programming in clojure, as
well as several books.
It's quite neat, IMHO, especially because some of the brightest minds
in the industry inadvertently worked on the compiler for it. (the Java
JIT) and millions of users have debugged it for the last few decades.
That's a lot of leverage for a new language.
-- Niels.
http://nielsmayer.com