>> I must admit, I'm not sure what this even means. Might be interesting 
>> though.
> 
> CSP. A bunch of actors running around exchanging messages 
> asynchronously, each process being a single thread in its own address 
> space. Like Erlang or any of the other dozens of languages designed for 
> real-time distributed processing.

So you mean each thread waits for messages to arrive, processes them, 
maybe sends some other messages, and then waits for the next message?

> That the channel itself is a first class object makes for the ability to 
> do cool stuff like passing the channel to a new version of the program 
> running on a different computer, so you don't lose any outstanding 
> messages. Assuming they really mean "first class" there.

Mmm... In C, an integer is a "first class" thing, but that doesn't mean 
you can send it over a network connection, for example. They might mean 
that these channels only work inside a single running instance of a 
single program.

>> Lots of languages have light-weight threads, no?
> 
> Many have lightweight threads that also occupy multiple processors. 
> I.e., most languages where you can launch 10,000 threads launch them in 
> one process and fake it 100%.

Oh, OK. I assumed they all do what Haskell does - you call forkIO and it 
creates a thread. You specify CLI options to say how many *real* threads 
to use.

[It's mildly irritating that to change the number of real threads, you 
must stop and restart your program - and also you can only control this 
from the CLI args...]

> I'll have to see what kind of introspection they support and what kind 
> of dynamic loading.

Ah, dynamic loading is fun.

-- 
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*

Post a reply to this message

Orchid XP v8 wrote:
> So you mean each thread waits for messages to arrive, processes them, 
> maybe sends some other messages, and then waits for the next message?

Essentially, yes.

> Mmm... In C, an integer is a "first class" thing, but that doesn't mean 
> you can send it over a network connection, for example. They might mean 
> that these channels only work inside a single running instance of a 
> single program.

If you can send a channel over another channel, then all you need is to 
encapsulate channels over sockets and you're done. If you can't send a 
channel over another channel, then it isn't first class.

> Oh, OK. I assumed they all do what Haskell does

No. Generally, desktop languages that supported threading before multi-CPU 
machines were common either fake it or use OS threads. Any language with a 
"threadpool" structure in the library is probably one of these.

Java with green threads faked it, Java with real threads allocates threads 
one for one, C# uses real threads, Smalltalk fakes it, C and C++ tend to use 
real threads, etc.

Of course, java and C# can change the semantics to use lightweight threads. 
C and C++ are probably stuck unless they break compatibility with all the 
other thread languages. Smalltalk is probably stuck with its own threads 
because everything there is "too open".

> Ah, dynamic loading is fun.

It's important for long-running programs, things with plug-ins, etc. Even if 
it's just dynamic linking. Of course, given it's google, they might very 
easily say "crash out if you want to load a different implementation of 
something, because everything we write recovers automatically anyway."

-- 
   Darren New, San Diego CA, USA (PST)
   I ordered stamps from Zazzle that read "Place Stamp Here".

Post a reply to this message

>> So you mean each thread waits for messages to arrive, processes them, 
>> maybe sends some other messages, and then waits for the next message?
> 
> Essentially, yes.

Seems like a conceptually simple model.

>> Mmm... In C, an integer is a "first class" thing, but that doesn't 
>> mean you can send it over a network connection, for example. They 
>> might mean that these channels only work inside a single running 
>> instance of a single program.
> 
> If you can send a channel over another channel, then all you need is to 
> encapsulate channels over sockets and you're done. If you can't send a 
> channel over another channel, then it isn't first class.

I would suggest that sending a channel over a channel is probably 
trivial, but sending a channel over a socket is probably *highly* complex...

>> Oh, OK. I assumed they all do what Haskell does
> 
> No. Generally, desktop languages that supported threading before 
> multi-CPU machines were common either fake it or use OS threads.

Oh. Really? I didn't know that...

Well, now I guess I understand why everybody gets so excited about 
Haskell's concurrency support then. :-}

>> Ah, dynamic loading is fun.
> 
> It's important for long-running programs, things with plug-ins, etc. 
> Even if it's just dynamic linking. Of course, given it's google, they 
> might very easily say "crash out if you want to load a different 
> implementation of something, because everything we write recovers 
> automatically anyway."

It's supposedly one of the big plus points of Java - not that I have 
*ever* seen *any* Java program which actually supports plugins, mind you...

As an aside, GHC theoretically is supposed to support dynamic loading. 
Good luck making it actually work though...

-- 
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*

Post a reply to this message

Orchid XP v8 wrote:
> Seems like a conceptually simple model.

That was the idea. Sort of like Lambda calculus - very simple, easy to prove 
things about with the right formalisms. Then it turned into products.

> I would suggest that sending a channel over a channel is probably 
> trivial, but sending a channel over a socket is probably *highly* 
> complex...

Could be, could be. But you can conceptually make it work without breaking 
the language.

> Well, now I guess I understand why everybody gets so excited about 
> Haskell's concurrency support then. :-}

That's part of it.

> It's supposedly one of the big plus points of Java - not that I have 
> *ever* seen *any* Java program which actually supports plugins, mind you...

At the time Java did it, it was rather new. Nowadays, Java's mechanisms are 
fairly lame compared to the competition.

-- 
   Darren New, San Diego CA, USA (PST)
   I ordered stamps from Zazzle that read "Place Stamp Here".

Post a reply to this message

>> Seems like a conceptually simple model.
> 
> That was the idea.

I gathered. ;-)

> Then it turned into products.

LOL.

>> It's supposedly one of the big plus points of Java - not that I have 
>> *ever* seen *any* Java program which actually supports plugins, mind 
>> you...
> 
> At the time Java did it, it was rather new. Nowadays, Java's mechanisms 
> are fairly lame compared to the competition.

Question: How many Java programs have you seen that are more than 
Tic-Tac-Toe demo programs? ;-)

(Personally, I haven't seen many - although there are a few...)

-- 
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*

Post a reply to this message

Orchid XP v8 wrote:
> Question: How many Java programs have you seen that are more than 
> Tic-Tac-Toe demo programs? ;-)

Quite a few.

-- 
   Darren New, San Diego CA, USA (PST)
   I ordered stamps from Zazzle that read "Place Stamp Here".

Post a reply to this message

Orchid XP v8 escreveu:
> Question: How many Java programs have you seen that are more than 
> Tic-Tac-Toe demo programs? ;-)
> 
> (Personally, I haven't seen many - although there are a few...)

A large part of the e-commerce web is powered by java application 
servers.  The reason you only see old tic-tac-toe java "applets" is 
because that's what is left on the web after Sun's goals for desktop 
java apps got spoiled by Microsoft with their own incompatible Java runtime.

That said, desktop java apps are still used at a fairly large scale. 
Federal Postoffice agency here in Brazil uses one such app for all its 
transactions.  It has that caracteristic Swing look-and-feel.  I gather 
banks also rely on java infrastructure heavily.  You quite never deal 
with it directly, though.  Only with the familiar generated HTML.

-- 
a game sig: http://tinyurl.com/d3rxz9

Post a reply to this message

>> Question: How many Java programs have you seen that are more than 
>> Tic-Tac-Toe demo programs? ;-)
>>
>> (Personally, I haven't seen many - although there are a few...)
> 
> A large part of the e-commerce web is powered by java application 
> servers.  The reason you only see old tic-tac-toe java "applets" is 
> because that's what is left on the web after Sun's goals for desktop 
> java apps got spoiled by Microsoft with their own incompatible Java 
> runtime.
> 
> That said, desktop java apps are still used at a fairly large scale. 
> Federal Postoffice agency here in Brazil uses one such app for all its 
> transactions.  It has that caracteristic Swing look-and-feel.  I gather 
> banks also rely on java infrastructure heavily.  You quite never deal 
> with it directly, though.  Only with the familiar generated HTML.

...so what you're saying is, Java ended up being big server-side rather 
than client-side?

Oh, the irony of designing a language that works anywhere, and then only 
running it in one place. ;-)

-- 
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*

Post a reply to this message

nemesis wrote:
> because that's what is left on the web after Sun's goals for desktop 
> java apps got spoiled by Microsoft with their own incompatible Java 
> runtime.

I think you need to listen to less hype and read more actual accounts of 
what happened there. MS's JVM passed more of Sun's compatibility tests than 
Sun's did.  Java applets sucked *everywhere* from incompatibility, at least 
as broken as HTML was, even from V1.0, long before MS wrote their own JVM.

-- 
   Darren New, San Diego CA, USA (PST)
   I ordered stamps from Zazzle that read "Place Stamp Here".

Post a reply to this message

Darren New wrote:

> Java applets sucked *everywhere* from incompatibility, 
> at least as broken as HTML was, even from V1.0, long before MS wrote 
> their own JVM.

Write once, debug everywhere(tm).

Also amusing was the way that every single revision of Java deprecated 
massive chunks of the APIs and added entire new ones. And also how all 
the APIs were insanely over-complicated and scantily documented. 
(Anybody know the difference between Applet.init() and Applet.start()? 
Because I don't! How many million methods does Component have?)

I especially liked how in one release they deprecated a set of methods 
and provided replacements, and in the next release they deprecated the 
new set and UNdeprecated the originals! o_O

I haven't used Java for ages. I wonder if it's calmed down yet?

-- 
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*

Post a reply to this message