On Sun, May 23, 2010 at 1:55 PM, <fons@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
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev
Received on Mon May 24 12:15:01 2010
This archive was generated by hypermail 2.1.8 : Mon May 24 2010 - 12:15:01 EEST