Re: Next Generation of Language


Ben schrieb:

On Jan 8, 8:21 am, "sailormoo...@xxxxxxxxx" <sailormoo...@xxxxxxxxx>
wrote:
From this linkhttp://itpro.nikkeibp.co.jp/a/it/alacarte/iv1221/matsumoto_1.shtml
(Note : Japanese)
Matsu, the creator of Ruby, said in the next 10 years, 64 or 128 cores
desktop computers will be common, it's nearly impossible to simply
write that many threads, it should be done automatically, so maybe
functional language will do a better job in parallel programming than
procedural language like C or Ruby.

Large embedded system quite often have that many threads. Obviously,
they aren't all actually executing simultaneously on the processors we
have right now, but various numbers of them are run depending on the
platform, so the system is (or should be anyway) coded to handle each
thread executing at any time. Not that I disagree with your point -
functional programming would be a great help as our systems grow in
complexity.

Begin old embedded programmer rant:
Kids these days just have no idea how to watch for side effects and
avoid them, or why they should. What are they learning in school?!
And don't even ask them to create a formal state machine for the side
effects they need. They'd rather throw fifteen booleans in there and
hope they can cover every possibility!
End rant.

Regardless of the language used on an actual product, training people
in functional programming teaches them the skills they need when
writing large scale concurrent apps, or small, single threaded apps, or
any code that they don't want to be patching for the next 30 years.

BTW: Has anyone done any hard real time work using Lisp? How'd it go?

There was a LispWorks version with a real-time GC running on a large
ATM Switch.
G2 from Gensym uses a Lisp without GC.

.

Relevant Pages

  • Re: Is Lisp ready to become popular?
    ... the lack of "standard" networking libraries and the like, the fact that free Lisps depend on Emacs as an editor and Emacs is _not_ the default editor of many developers, the unfortunate fact that Lisp syntax is so obviously different. ... It's generating a fair amount of conversation in the Java community. ... Tate is clearly impressed by Ruby, but he dismisses Lisp's chances based on its "history and reputation to overcome". ... or in a programming language ...
    (comp.lang.lisp)
  • Re: Why I never got into Lisp
    ... solutions in languages like Perl. ... and what you tried in Lisp, and how Lisp mapped better, for you. ... While this can be done to some extent in any language, ... liked the fact that Ruby, like lisp, seems to have sensible defaults ...
    (comp.lang.lisp)
  • Re: A "killer" macro
    ... but then Ruby is dog slow anyway: ... Having notational convenience via macros plus efficiency is a big win ... From my perspective as a Ruby programmer learning Lisp, ... thought of having a more powerful language *and* orderof magnitude ...
    (comp.lang.lisp)
  • Re: A "killer" macro
    ... Or perhaps Lisp doesn't have one thing ultra- ... But it's true because of macros. ... indistinguishable from native Lisp - extend the language itself. ... Ruby is totally inefficient (besides what is implemented ...
    (comp.lang.lisp)
  • Re: A "killer" macro
    ... Or perhaps Lisp doesn't have one thing ultra- ... But it's true because of macros. ... indistinguishable from native Lisp - extend the language itself. ... Ruby is totally inefficient (besides what is implemented ...
    (comp.lang.lisp)