Your own language

[bascule]

If you made a programming language, what would it be?

 

I'd be aiming to create a context free, third generation programming lanugage.

 

I would like to implement the Actor Model in a means which is a superset of the underlying language, which I would desire to be pure object oriented. Pure OO languages and languages based around the Actor Model have some striking similarities (the first pure OO language, Smalltalk, was based in part around the Actor Model)

 

The Actor Model assumes a pure-Actor language. And indeed Actors work much like objects, save for concurrency and message processing control.

 

I believe objects should be the underlying data primitive, but I do not believe threads and asynchronous message queues should form the concurrency primitive. Something higher level, involving synchronization, is needed.

 

What I'm really looking for is a "microthreaded" pure OO language where microthreads implement either Actor or Reactor. I'd be hard pressed to say what I think about Reactor as the fundamental message processing primitive. I'd prefer Reactor be used in the implementation of Actor, but even in that case the kind of sanity checks provided by actor are no longer language-enforced.

 

Bottom line: I see immense value in concurrency and objects. There must be some sort of compromise between pure OO and Actor. It just hasn't yet been realized.

[tadzio]

What's wrong with C++? Does this not suffice? If not, why?

[Sisyphus]

I'm still waiting for a computer that understands English. Can you do that?

[tadzio]

English is an ambiguous language and thus unsuitable for the purposes of computer programming.

[Sisyphus]

Bascule understands English, and he'll assure that he's basically a computer. Check out his signature.

[tadzio]

Bascule understands English, and he'll assure that he's basically a computer. Check out his signature.

 

I have given Bascule's signature some serious consideration and I have concluded that you are correct in your observation. I am, now, assured that he's basically a computer.

[bascule]

What's wrong with C++?

 

A lack of garbage collection is perhaps the most notable deficiency, so much so that its creator, Bjorne Stroustroup, has considered including one in future revisions of the C++ standard.

 

There are several garbage collectors available for C++ but the lack of a definitive one hinders interoperability of code which uses one.

 

This has been corrected in D, a highly C++-inspired language.

 

Does this not suffice? If not, why?

 

There's further problems with C++ which are not addressed by the mere addition of a garbage collector.

 

The issue of concurrency is perhaps the biggest one.

 

My fear is that a concurrent OO language will never be realized, and we will be forced to move to an entirely Actor-based language.

[Aeternus]

bascule, have you considered ObjC? It does message passing nicely apparently, has a lot of cool language features, ObjC 2.0 apparently has native garbage collection etc - http://www.informit.com/articles/article.asp?p=665128&seqNum=3&rl=1 . Plus things like GNUStep etc might make developing cross platform stuff easier.

[the tree]

I'd quite like to create a programming language that is not at any particular level (y'know, if I knew anything about computers). For instance, I'd like to use abstract ideas like objects, to use really abstract ideas like those needed for graphics libraries but also to be able to issue processor commands, all in one language. The advantage being that if the language doesn't do quite what a developer wants it to do, then they can just go one level lower to get what they need right without having to write in multiple languages.

 

I haven't yet got my head fully around the actor model, I probably should look into that sometime.

[tadzio]

Should "garbage collection"and "concurrency" really be part of a language's definition?

 

I think: the program itself should ensure all objects created are destroyed accordingly; and the ability to determine the deployment of a thread or fiber should be a kernel API consideration.

[bascule]

Should "garbage collection"and "concurrency" really be part of a language's definition?

 

C++ is a clear indicator that it should.

 

I think: the program itself should ensure all objects created are destroyed accordingly

 

The enormous success of garbage collection is a clear indicator that many people doesn't agree with this position

 

the ability to determine the deployment of a thread or fiber should be a kernel API consideration.

 

You should look at the actor model. Concurrent languages seem to be quite a bit different than you seem to think they are.

 

About the simplest way I can describe the actor model is: imagine every object were also a thread.

[bascule]

bascule, have you considered ObjC? It does message passing nicely apparently, has a lot of cool language features, ObjC 2.0 apparently has native garbage collection etc - http://www.informit.com/articles/article.asp?p=665128&seqNum=3&rl=1 . Plus things like GNUStep etc might make developing cross platform stuff easier.

 

Objective C is not concurrent. The problem being addressed with concurrency is that of many CPU cores and how to allow programs to leverage them effectively.

[tadzio]

You should look at the actor model. Concurrent languages seem to be quite a bit different than you seem to think they are.

 

Just to be clear when you say "concurrent" you do mean "processing simultaneously in parallel with other threads”?

[bascule]

Just to be clear when you say "concurrent" you do mean "processing simultaneously in parallel with other threads”?

 

Yes. You can think of Actors as being a combination of an object and a thread. They communicate with asynchronous message passing, as opposed to the synchronous message passing of object-oriented languages. All program behavior is structured around receiving messages (similar to the Reactor pattern in OOP).

[tadzio]

The way you describe this model is very interesting. A few years ago, I wrote a serial comms protocol that used Win32's APC. The code was pretty complex and, as a result, not something that could ever be considered 'eye candy'

 

I now realise (from what you have said here and what it has caused my to investigate) that I was probably trying to reinvent a rudimentary Actor-like structure in the code. So, on these grounds, I'm very inclined to agree with your opinion. Having a language to abstract this a little further, than I could encapsulate in the C++ objects I defined, would have been desirable.

 

But, this brings me to another question: Is it right or possible to aim for a single all encompassing language?

 

I've always thought it best to choose a language for a certain job. C++ does lots stuff but it doesn't serve the same purpose as HTML. PHP is a great language for a web server but it can't be compared it to the function that Javascript serves at the client-side. Chocolate is pleasant enough to eat but useless for making teapots out of....

 

I'm interest in your opinion on this.

 

(BTW: Thanks for putting me on to Actor - I had heard about when I was first learning C++ back in '89 but I just ignored it as it wasn't available to me back then in the dark ages before the Internet. I should read up on it anyway because I could have used the ideas - like when the C guys used write in Quasi-C based on C++ ideas).

[bascule]

But, this brings me to another question: Is it right or possible to aim for a single all encompassing language?

 

Erlang is most certainly obtuse. However, it now comprises many infrastructural parts of America's telecommunications system (a move largely motivated by the January 15, 1990 meltdown of AT&T's long distance system following a single logic error in C code previously used to regulate the network which slipped below the testing they performed)

 

In terms of commodity software written in Erlang, ejabberd is the only program which really comes to mind. Concurrent programming remains a difficult task and a move to an Actor-based language is often a difficult one.

 

I've always thought it best to choose a language for a certain job.

 

In that respect there are a number of targets concurrent languages are aimed at.

 

In the case of Erlang, it's aimed at high-reliability distributed systems. Asynchronous message passing allows for "modules" to be dynamically swapped out (in which case incoming messages are buffered until the new module is in place) and updated with newer versions while a program is running. This ensures that a running program need not be stopped for a software upgrade, rather upgrades can be done piecemeal and while the system is running.

 

C++ does lots stuff but it doesn't serve the same purpose as HTML. PHP is a great language for a web server but it can't be compared it to the function that Javascript serves at the client-side. Chocolate is pleasant enough to eat but useless for making teapots out of....

 

I'm interest in your opinion on this.

 

I would say Actor-based languages like Erlang are especially well-suited to any task that involves message processing (e.g. network servers). Beyond that, the implicit parallelism serves well for general purpose programming on distributed systems. At present CPUs are not highly distributed systems and can still be utilized effectively through multithreading, however multithreaded programming, much like manual memory management, has an enormous list of gotchas, specifically regarding synchronization which can result in terminal errors.

 

Actor abstracts these problems away and dramatically simplifies the process of synchronization. While it may not seem well-suited as the basis of a general purpose programming language now, I think that will change dramatically when we move to processors with dozens, or even hundreds of cores.

 

There are alternative approaches to parallelism which don't require a shared-memory system (as Erlang does). Perhaps the most notable is Google's MapReduce, which takes a "map" instruction (i.e. transform an input set into an output set member-by-member), applied to an index which is distributed among many computers (thus there is no performance hit occured in distributing the transformation as the input is already distributed) with a "reduce" instruction, which combines the output values into a single result.

 

(BTW: Thanks for putting me on to Actor - I had heard about when I was first learning C++ back in '89 but I just ignored it as it wasn't available to me back then in the dark ages before the Internet. I should read up on it anyway because I could have used the ideas - like when the C guys used write in Quasi-C based on C++ ideas).

 

I've been somewhat wary of Actor for awhile, perhaps I've been influenced by Erlang and the restrictions it places on defining modules. I cling to object orientation because that's what I'm familiar with.

 

It's possible that with increasingly parallel architectures object orientation is doomed to death, and implicit parallelism will necessarily take over as the new language paradigm. While I'm not entirely convinced that implicit parallelism in object oriented systems is an unobtainable goal, Actor seems like a much cleaner solution to the problem.

 

For now I'll stick with object oriented Reactor frameworks. But Erlang remains my primary hope for the future of programming.

 

I would still love to see what I set out initially in this post: a hybrid object/actor language where objects can be used in the implementation of higher level Actor-based modules (which can only talk to other Actors). However this can probably best be accomplished through implementing Actor primitives within an existing object oriented language.

[bascule]

And with all that said, does anyone else here have ideas for their own language?

[bascule]

I am, now, assured that he's basically a computer.

 

We're all basically computers. I'm sure John Searle and other monist philosophers would insist otherwise.

[foodchain]

We're all basically computers. I'm sure John Searle and other monist philosophers would insist otherwise.

 

Speaking of such whatever became of programming based around genetics, or was that simply something I read in a mad magazine somewhere. I think a lot of software issues are heavily dependent of course on the hardware being used, or available, and such is a sort of co-evolution of sorts overall. I remember a while back, I mean years ago, about chemical circuits and the ability they had to hold memory far longer then modern circuits, which greatly reduced the rate in which such had to be refreshed, and then of course quantum computers and so on. So I basically just came to wonder if modern day technology for computers to be programmed was basically going to shift overnight and my degree if I had kept working on it would have been somewhat useless, being such technology would make modern computers seem like something out of the stone age, and the need to program them would have, or at least I imagined, changed drastically to be able to reach the kind of work they were capable of overall. Though nanotechnology is still infant and much work on quantum computers and the sort is a constant endeavor all over the world. In regards to my own programming language idea, I put it forth in another thread, just to not appear totally off topic.

[tadzio]

And with all that said, does anyone else here have ideas for their own language?

 

Yes, I'd probably go for something like Erlang

 

Seriously though, bascule, you make a great argument. I'm am now munching my way through "erlang-book-part1.pdf" and it's pretty tasty It's vaguely reminiscent of the Forth language program listings, for the Jupiter Ace, that I used to marvel at in Your Computer Magazine (UK comp mag) back in 1983

 

Thanks for sharing this.

[bascule]

Thanks for sharing this.

 

Thanks for taking part in an actual CS-related conversation in the computer science forum, heh

[bascule]

http://people.csail.mit.edu/gregs/ll1-discuss-archive-html/msg03319.html

 

Well, that may perhaps be what I'm describing. Perhaps Erlang can do what I want after all.

 

Basically, I'd like to stick a synchronous API on Actor. This would be by adding synchronous message support using continuations.

 

The basic idea is that you'd invoke some sort of "superprocess" which could make asynchronous message calls, then defer to the underlying Erlang processes.

 

I don't know how to even begin to describe this process, but it effectively creates synchronous messaging functions by snapshotting the program state at a given point in time, then deferring back to the higher level process, and when receive is invoked with the desired response, control could be returned to the "superprocess" by reloading its continuation.

 

Here's an example in Ruby, on top of Reactor:

 

http://pastie.caboo.se/44544

 

It's pretty hackish and probably very difficult to understand for someone who isn't familiar with Ruby (or rthe Reactor implementation I'm using, EventMachine)

 

At the bottom though, is a synchronous echo server:

 

EventMachine::run do
 EventMachine::start_server('127.0.0.1', 2500, Continuator) do |connection|
   connection.instance_eval do
     run do
       loop { send_data read }
     end
   end 
 end
end

 

You can see what it does here specifically:

 

loop { send_data read }

 

It sends whatever it reads, in an infinite loop. This call is synchronous, but the underlying implementation is completely asynchronous.

[bascule]

NECROMANCER casts revival and summons this thread back to life from the grave!

 

So I'm working on my own language now. It's a lot of fun. If you have the requisite knowledge, it's something I'd suggest you try. If you don't, it's something I'd suggest you learn.

[ecoli]

[Realitycheck]

You could write a program designed to help people write their own video games. You could call it Dungeonmaster Plus.