nemesis wrote:
> http://golang.org/

Hmmm. Interesting. (Three people have told me about this already. :)

 > Interfaces can be added after the fact if a new idea comes along or fo
r 
testing—without annotating the original types.

That's a good step towards the "next language" bit I was talking about 
earlier. Where unit testing is trivial in the language, or some such.

 > Go's concurrency primitives derive from a different part of the family
 
tree whose main contribution is the powerful notion of channels as first 

class objects.

Very nifty. I suspect I'm going to have to look into this more.

 > It is practical to create hundreds of thousands of goroutines in the s
ame 
address space. If goroutines were just threads, system resources would ru
n 
out at a much smaller number.

And this.

I was very skeptical just glancing thru it at first, but it seems there's
 
more going on than evident at a quick glance.


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

Post a reply to this message

>  > Interfaces can be added after the fact if a new idea comes along or 
> for testing—without annotating the original types.
> 
> That's a good step towards the "next language" bit I was talking about 
> earlier. Where unit testing is trivial in the language, or some such.

This is one of my favourit things about Haskell classes [which are 
really interfaces]. You can add them to any type you fancy.

>  > Go's concurrency primitives derive from a different part of the 
> family tree whose main contribution is the powerful notion of channels 
> as first class objects.
> 
> Very nifty. I suspect I'm going to have to look into this more.

I must admit, I'm not sure what this even means. Might be interesting 
though.

"Do not communicate by sharing memory. Instead, share memory by 
communicating. And there is no spoon."

>  > It is practical to create hundreds of thousands of goroutines in the 
> same address space. If goroutines were just threads, system resources 
> would run out at a much smaller number.
> 
> And this.

Lots of languages have light-weight threads, no?

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

Post a reply to this message

Orchid XP v8 wrote:
> 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.

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.

> 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%.

But yes, the availability of lightweight objects and first-class channels is 
a good combination. Either one alone is difficult.

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

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

Post a reply to this message

>> 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