Slashdot Mirror

PHP and Ruby have lots of easy to use code libraries. But for secure, scalable, solid performing, provable code...I just can't get over my happiness with erlang. http://www.erlang.org./ I worked with Java for over 7 years. We developed very scalable network oriented apps. We built our own frameworks and used others as well. Much of the code was well engineered, but at a high cost of dev time and testing. The problem of massive concurrency was a continual worry. We could be very diligent in making things thread safe, but little things would pop up every now and again. Things that were very difficult to debug. New server, more CPUs...get ready for new found concurrency bugs. As I started over last year to build a new system, I wanted completely away from concurrency problems. I also wanted frameworks that were more lightweight that J2EE ('nuff said). In addition, I wanted something new that made me enjoy programming again. I ended up choosing erlang...yes, it has everything for developing web apps...and then some. It is very scalable and the code is provable to be correct for concurrency issues. Security is top notch and performce is very good. In addition, HTTP server, a good object/relation db, Jabber server, HTML script engine...everything is all written in erlang. No need for mixing code to get a complete solution!!!. Venture out a little...try something new...you might be very surprised.

Mod this guy into orbit please.

...issues with language semantics, which is not very important in real life.

I keep seeing this assertion, but never any evidence. A functional programming is no more or less descriptive than C++.

Check out e.g. "Four-fold Increase in Productivity and Quality" (pdf link). Erlang is freely available. Regarding C++ vs. functional programming being 'less descriptive' there's Haskell vs. Ada vs. C++ vs. Awk vs. ..., An Experiment in Software Prototyping Productivity(PS link). Now that doesn't directly address your question about what the compiler can do, there's about a metric ton of stuff about the higher level optimisations you can do with a declarative language compared to a messy one such as C++; riddled with aliasing problems etc. I haven't got any links handy, but some googling should turn them up (you could start by checking out Urban Boquist's, now quite old, PhD thesis). Plese note though that the Erlang references demonstrate that even while they may be slower on micro benchmarks, they always win in the end. Much like C beat out assembler in the eighties.

Your argument basically boils down to "the languages under discussion are all turing complete". While that's true, that's not really what we're saying. We're saying that given a declarative language the potential (and nowadays practice) for optimisation is much improved compared to e.g. Fortran or C.

It seems to me that this is going to impose a pretty big limitation on the capabilities of entry-level developers. Until somebody develops some sort of fire-and-forget race condition prevention tool, it's going to pay to have skills as a multi-threaded app developer.

Maybe the Erlang language is the thing you're looking for. I'm not sure about this one but I think it prevents multithreading/multiprocessing bug just like Java prevents buffer overflow bugs.

This is mainly because Erlang is a purely functional language. This is a problem if you're used to imperative programming languages but as you said. A new way of programming is needed anyway.

Erlang is under a licence similar to Mozilla.

The Cell is the thing for number crunching and pro applications where they are willing to spend the time optimizing for every single CPU, but for normal developers it is a step back.

The Cell is the thing for number crunching and pro applications where they are willing to spend the time optimizing for every single CPU, but for normal developers it is a step back.

Really? Which functional language has macros?

Template Haskell is an extension to Haskell 98 that allows you to do type-safe compile-time meta-programming, with Haskell both as the manipulating language and the language being manipulated.

Intuitively Template Haskell provides new language features that allow us to convert back and forth between concrete syntax, i.e. what you would type when you write normal Haskell code, and abstract syntax trees. These abstract syntax trees are represented using Haskell datatypes and, at compile time, they can be manipulated by Haskell code. This allows you to reify (convert from concrete syntax to an abstract syntax tree) some code, transform it and splice it back in (convert back again), or even to produce completely new code and splice that in, while the compiler is compiling your module.

Which functional language lets you redefine stuff in a running image?

12.3 Code Replacement

Erlang supports change of code in a running system. Code replacement is done on module level.

The code of a module can exist in two variants in a system: current and old. When a module is loaded into the system for the first time, the code becomes 'current'. If then a new instance of the module is loaded, the code of the previous instance becomes 'old' and the new instance becomes 'current'.

Both old and current code is valid, and may be evaluated concurrently. Fully qualified function calls always refer to current code. Old code may still be evaluated because of processes lingering in the old code...

- C++ is more readable than assembler
- C# and Java are more readable than C++ ...
- At the end of this list are functional programming languages.

If you can read source more easily, then maintainability will be better. Most projects maintain code, they write new code less often.

This article will tell you why you should be interested in functional programming languages (this link is about Lisp). If you're smart and open minded, you will be convinced.

The best functional languages are Haskell and Erlang (click "next" at the bottom of the page). But like the review and link indicate, there's actual value to learning Lisp.

However, the book review is much too in-depth and has jargon.

A simpler example: with Java you prevent bugs by static typing variables, example:

int numberOfTries = 3;

If you later try to fill "numberOfTries" with a string, the compiler will warn you of a bug and you'll have prevented it. The Java compiler makes it a rule that you have to give a type to your variable so your code quality will be higher (fewer bugs).

With Haskell, you don't have to type int. Haskell will figure out the type for you, you get the benefit of preventing bugs with the convenience of not having to type variables. There are other good features like that in functional programming languages.

You could say that every language puts restrictions on what the programmer can do. I mean writing the source code is bottlenecked by the rules of the language (every variable should have a type. You can't do this/that etc.) so that the resulting code AUTOMATICALLY has fewer bugs. Well the amount of source "laws" in functional languages is much lower than in C++ and Java. This means that there is less to remember for a programmer and there is less chance for rules to conflict/interact with each other (in Java you can't use certain variable types in static classes = another meta rule to remember).

Besides having less rules to remember and take into consideration. The functional languages have also chosen the best "laws" to follow. I mean that if you follow the source laws of Java, it's still relatively easy to produce buggy programs, with functional languages it's harder to produce implementation bugs (thinking bugs are always possible but that's your problem).

The only problems with functional programming languages is that the rules which govern source code are very good, but also very different from the rules in traditional programming languages. It might seem like thinking upside down/backwards for people already familiar with procedural languages. Another problem is that because of humans sticking to what they know, the libraries of the functional languages aren't as extensive as those of Java for example. This means that you'll have to program more parts of your program yourself instead of just using a ready made library which fits the task. This problem is limited by the fact that you can program 10 times faster than in Java and, as I said, maintenance takes up most of the time anyway.

The reason I chose Erlang is because with functional purely functional programming languages like Erlang, you can automatically multitask your program over several CPU's (or this will take minimal effort). Nice feature to have in the future because every CPU manufacturer is going multi-core chip now. The future is in multiprocessor machines, not higher clockspeeds (unless diamond wafers become viable) (Lisp is not purely functional by the way).

Also, you can easily make a server that never goes down with Erlang because your server is automatically clustered. Just plonk down a couple networked PC's and if one dies, the server cluster will just keep on going (a bit slower) until you replaced the power supply of the broken PC.

There are tons of other advantages but, as I said,

"As far as threading is concerned, one of the few languages I've dealt with that makes mutexes, semaphores, etc. easy to deal with is Java."

So can Erlang.

Wings3D is written in Erlang.

The real issue is how large each thread can be (in the matter of memory) before it has to access data that is external to the thread. It may mean a lot for gamers running close to reality games and also for those that are doing massive calculations.

The important thing is that developers has to be aware of the possibilities and limitations around this technology. Otherwise it would be like throwing a V8 into a T-Ford. It is possible, but you would never be able to utilize the full power.

Another thing is that todays programming languages are limited. C (and C++) are advanced macro assemblers (not really bad, but it requires a lot of the programmer). Java has thread support, but it's still the programmer (in most cases) that has to decide. Java is not very efficient either, which of course is depending on which platform it's running on in combination with general optimizations. C# is Microsoft's bastard of Java and C++ with the same drawbacks as Java.

There are other languages, but most of them are either too obscure (like Erlang or Prolog) or too unknown.

The point is that a compiler shall be able to break out separate threads and/or processes whenever possible to improve performance. It is of course necessary for the programmer to hint the compiler where it may do this and where it shouldn't, but in any way try to keep the programmer luckily unknowing about the details. The details may depend on the actual system where the application is running. i.e. if the system is busy with serving a bunch of users then the splitting of the application into a bunch of threads is ot really what you want, but if you are running alone (or almost alone) then the application should be permitted to allocate more resources. The key is that the allocation has to be dynamic.

Anybody knowing of any better languages?

YXA is another open source sip server. This one's written in Erlang which strikes me as a very good fit for this purpose (Erlang was originally developed by Ericsson for the specific purpose of developing high availability telephony applications). There are I believe some plans to integrate this with ejabberd.

Er-lang.

Er-lang.

- C++ is more readable than assembler
- C# and Java are more readable than C++ ...
- At the end of this list are functional programming languages.

If you can read source more easily, then maintainability will be better.

This article will tell you why you should be interested in functional programming languages. If you're smart and open minded, you will be convinced.

The best functional languages are Haskell and Erlang (click "next" at the bottom of the page).

For example, with Java you prevent bugs by static typing variables, example:

int numberOfTries = 3;

If you later try to fill "numberOfTries" with a string, the compiler will warn you of a bug and you'll have prevented it.

With Haskell, you don't have to type int. Haskell will figure out the type for you, you get the benefit of preventing bugs with the convenience of not having to type variables.

The reason I chose Erlang is because with functional purely functional programming languages like Erlang, you can automatically multitask your program over several CPU's (or this will take minimal effort). Nice feature to have in the future because every CPU manufacturere is going multi-core chip now. Also, you can easily make a server that never goes down with Erlang because your server is automatically clustered. Just plonk down a couple networked PC's and if one dies, the server cluster will just keep on going (a bit slower) until you replaced the power supply of the broken PC.

There are tons of other advantages but, as I said, the above links will convince you if you're smart. Haskell is a bit more academic in nature, they're figuring out the best possible language and Erlang is more polished and ready to go. It was invented by Ericsson to create ultra reliable realtime servers.

Erlang was developed, starting in the late '80s. It was influenced by Prolog (in which the first interpreter was written), Parlog and LISP. This page shows a concise history.

Erlang was developed, starting in the late '80s. It was influenced by Prolog (in which the first interpreter was written), Parlog and LISP. This page shows a concise history.

• Concurrency
• Distribution
• Robustness
• Soft real-time
• Hot code upgrade
• Incremental code loading
• External interfaces

I read the arguments about Isolation - but sorry, isolation isn't enough.

To make things that never fail you need more than one computer!

The minimal configuration is TWO computers (sorry for shouting) and even that won't work if both computers fail.

This means you need to do distributed computing - whether you like it or not.

Stuff that never stops => more than one computer => distributed computing.

It also implies NO SHARED DATA STRUCTURES (imagine me hitting the keyboard here) - why? - think about it. Computer A has a pointer to a data structuire on computer B - computer B now crashes - ooops.

So how far have we come? - you need two or more computers, and no shared data structure (oh, and by the way, no sharing implies EVERYTHING MUST BE COPIED) - so you have to copy everything you need to do crash recovery to both machines involved.

This is very definately NOT how java was designed. Threads SHARE resources - so you have to use one style of programming when using two threads on the same machine but a completely different style of porgramming when using two threads on two different machines - some people might like this - I don't.

Oh and what more? - stable storage - what's that? Stable storage is storage which survives a crash! You need that as well.

I think (I'm not really sure) That there are actually 6 different things you need to do to make a fault tolerent system (see pages 27-28) of [1] - isolation in one of them.

If you want to make fault-tolerent system I'd suggest to read [1] (it's free) - then download [2] and off you go - it's easy.

Using [2] We have made some pretty reliable systems - as far as I know some of them have never stopped :-)

Cheers

/Joe

• [1] Making relaible systems in the presence of Software errors
• [2] www.erlang.org

>It seems that the problem of information management from conventional programming languages has not been tackled yet.

The problem has been handled by Erlang.
--
Mickaël Rémond
http://www.erlang-projects.org

Shouldn't be an issue, I have had Solaris boxes with 1200 days of uptime and they could handle bursts of load just fine. Lots of other OSs have obscene uptimes and even hardware fault tolerance, too - VMS, FreeBSD, IBM VM MVS, NEC, Stratus, Tandem (now HP NonStop), etc so 400 days shouldn't be a problem for a critical system like that. erlang, a language that supports hot code replacement/upgrades allows for code upgrades without even bringing down the application.

So adequate tools/hardware exists for them to create a system that shouldn't go down except for programming errors or complete connectivity failures.

Go to Erlang. It is intended for robust and concurrent (as in webserver) applications. Use yaws as your webserver.
Erlang is free as in beer and in speech. It comes with a distributed database, CORBA and many other goodies.
Everyone I know that tried it, liked it and prefered it over Java and PHP. The participants on the Erlang mailing lists are very supportive, too.

I'm sorry, it's a myth? Apparently many millions of people, many far better programmers than you, have completely been deceived! Please back up this wonderfully baseless statement with some substance.

One of the core ideas behind the design of C++ is "if you don't use it, you don't pay for it". Do a quick look around at talk of the impending C++0x standard, and you'll see this mantra is alive and well to this very day... and the lack of some "language features", like forced garbage collection, don't exist it for this very reason.

Being old enough to have been around the introduction of 'C' to the masses (i.e. the PC) and the abandonment of assembler it's amusing to see the same arguments recycled all over. Only this time it's 'C' that's leet:small, fast, not bloated etc, instead of assembler. And higher level languages such as 'Python' that are 'slow/bloated/have a lot of stuff you have to pay for even if you don't use it' instead of 'C'.

Last time around the debate was settled squarely in favour of 'C', that while it was killed dead in micro benchmarks compared to assembler, when it came to projects of any size, the added ease of development actually meant that programmers weren't bogged down in detail and could actually concentrate on doing the right thing (instead of merely doing things right). With huge savings in development time and even efficiency of the developed application. Since you hadn't spent all your time getting it to work, and you could express yourself using more abstractions you could actually tune and throw away code you had written replacing it with something that implemented a better algorithm.

A few companies did stick to their guns and continued with assembly for everything ("because it was faster, God damn it!"), and perished as a result. The original company behind WordPerfect comes to mind. They folded had to sell WP (which had to be rewritten in something higher level, and that rewrite made it slip behind its competitors).

Within Ericsson we've seen that particular light and developped our own system (Erlang) which enables us to produce world class systems faster than the competition. Systems which also have better performance than our competitors. (See AXD301 and our GSN line). This despite Erlang being killed by 'C/C++' in micro benchmarks. System level it rules the roost. (That's not to say we don't use 'C', we do, just like assembler wasn't abolished by 'C'. But we use it where it belongs for device drivers and the like, not code that actually does anything. Our experiences with C++ gives us pause though, so no C++ if it can be helped.) Lots of nice papers on the Erlang site above. And note that when it comes to performance claims these are verifiable claims.

So if you're a competitor of Ericsson, please continue using C/C++, our continued success depends on it. If you're not, then you better prepare to wake up and smell the roses. History looks set to repeat itself and you don't want to be stubbornly stuck in your old ways and go the way of the WP team when the wind shifts.

I glanced at ejabberd recently and was initially spooked by the choice of the language - Erlang. Thought it was some obscure toaster programming language. Turns out its from Erricsson, opensourced, and designed for fault tolerance and things like routers and servers.

Can someone point to a good review of the most common, free Jabber servers? (Possibly for Windows: Jabberd 1.4.x; Erlang; some Java ones, now including the Jive)

The Jabber.org's server features page is a good start, but says nothing of reliability and general feel.

That'd be Erlang.

The FA missed the point rather badly, IMO - what makes Java 'uncool' is its lack of support for abstraction. When a programmer finds himself doing the same thing again and again, his first thought is "can I abstract this pattern?". In Java, the answer is all too frequently "no", and the programmer is forced to type in several lines of code to express one conceptual construct.

Sun's big mistake was in not separating the ideas of Java and the JVM more cleanly when marketing it - there are some very cool, hacker-friendly JVM languages (most notably Scala), all of which share Java's virtue of "compile once, run anywhere", but which have got practically no mindshare.

I'm like you, a old fortran hand, driven through C++ and Java, murdered by Perl who thought he had found true love in Ruby.

Then I met Erlang - a distributed functional language where the language is designed to work with hardware failure. Robustness and error handling is entirely seperate from the program logic, so you do no defensive programming (pass a negative number into a routine that expects a positive parameter the process will and should explode and your programme will continue to function - magic!) Erlang is Open Source, it has a fantastic toolkit with real-time stepwise n-physical-tier debugger where you step from a line of code on one machine to another line on a different machine... You can trace all your machine-to-machine comms in real time. It is trivial to programme a state diagram, and guess what most dynamic web sites contain only processes that are state machines... Erlang is simply the muts nuts...

You do realize that distributed databases are nothing new? Look into Erlang and the (a)Mnesia database; the language (functional) has built-in support for distributed applications and a mailbox model for IPC. Sending messages over the network (or locally, whatever it needs to do) is as easy as saying "pid ! msg.".

• one module interface, many module implementations
• any functionality not given in a module interface is inaccessible to other modules
• no inheritance of module interfaces
• no inheritance of implementations, either. (As far as I saw.)

But I don't agree that it's superior to Java's way. Namely, that you can optionally implement an interface or share a superclass. public members of a class can be called without one, at the cost of tying yourself to a particular implementation. I like inheritance; I disagree that it complicates things.

There's also a "quote" function in the tk module, so:

tk->cmd(t, "button .b -text "+tk->quote(_("hello world")));

would work fine too.

My concern is that people will forget to do this (or your first way, which I omitted for brevity). They already regularly forget to do so when sending things to the shell, to an XML processor, to a web browser's HTML engine, to a SQL database, etc. It causes huge problems. So when you have to be continually careful, I get uneasy.

So your new Button(...) example is vastly incomplete. In the Tk interface, for a new button, one can specify background colour, foreground colour, justification, font, etc, etc. One would have to invent language-level objects for all these things (instead of using "red", you'd perhaps have to create a new Colour object, initialised in an appropriate way that you could then pass to the Button's "setcolour" method (excuse brit spelling).

There is indeed a balance to be struck. Colors don't need to be first-class objects; they could be strings:

b = new Button(_("hello world"), color: "red")

Where I use keyword arguments for the optional stuff. The color is simply another string. More static than your way, less than Java's. From my perspective of a user of the language, this is about as simple as it gets. One place to look for a description of the API. One syntax to learn. Yet simple.

But in my understanding, the Erlang message passing is intended to transport messages transparently between machines. Limbo's channels don't try to do any such thing. Sending a value down a Limbo channel is exactly the same as passing it to a function, except that the value goes to another process on the same machine. No marshalling, no distributed objects.

Erlang's message-passing is also the only way to send messages between Erlang processes. And when it is on the same machine, I do not believe any marshalling happens. It's certainly fast. And there's no worry about distributed objects, either: Erlang is a pure functional language, so you can't send a mutable value. No need to keep two copies in sync as they change, since they won't.

You can actually build up quite sophisticated protocol descriptions this way - an example of an area where perhaps more static type checking is used in Limbo than in other languages (but maybe it's trivial to do these things in Erlang too, I dunno).

Erlang lets you send arbitrary messages to a process. It has a receive that matches one or more patterns and takes the associated action. So yes, Limbo does seem to be more static. But I think you'd lose something if you specified an allowed pattern beforehand; you'd end up keeping the receive patterns and that one in sync, which would be a pain. So here you are doing things more statically, and I still don't like it. You can't win. ;)

Check out Concurrent Programming in Erlang, PDF page 100 / written page number 89. It has a good example.

Maybe the article author has been laid off from Ericsson, I believe they used (use?) Eiffel a lot in-house

No, what you mean is Erlang.

Oz, Mercury...used both. Oz is quite expressive and interesting; Mercury is easier to learn and more efficient. Both are from a family of languages (concurrent logic programming languages) that has some interesting potential, but not much of a user base. Strand had a brief heyday, and is much like the KL1 FGHC language from the Japanese FGCP that I did my master's work on. Erlang is fairly popular in certain circles, but has evolved away from CLP.

I guess I'm not a "real hardcore nerd"...

Written like someone who has never used a functional language before. And I know a lot of functional programmers that would argue that OOP is not the way.

Give Haskell or Erlang a try. If you've never done functional programming it'll take a while to get used to it but it's worth it. I wouldn't bother with O'Caml straight away because it's kinda convoluted and the default syntax sucks.

Personally I feel future better languages will combine OOP and functional programming. Some languages are already doing it but I haven't seen any really tasty combinations yet.

The reason why functional programming languages (not just Haskell) aren't popular is a bit of a Catch-22 situation. Most people try to learn a new language because it adds value to their resume or because something they're working on demands it. In the former case they always lean towards the so called mainstream languages - C/C++/C#/Java/... In the latter case, they probably don't care which language they're forced to learn and abandon it once their work is done. So a language doesn't get adopted unless it goes mainstream. But for a language like Haskell, it's difficult to go mainstream unless it gets adopted.

This does not in any way mean that an implementation of an idea in a functional language is necessarily slower than one in a say C/C++. See for e.g. Yaws . Phil Wadler has some information on functional language use in industry here. Galois Connections uses functional languages like Haskell/ML and there are several companies which use Erlang.

What about Erlang and Ericsson?

I'm not suggesting that we do away with basic arithmetic or variable assignment. You can't do that and still have a programming language.

I've written sizable programs in LISP and Prolog. I've used formal specification languages. That era is over.

We love it when you think it is. It enables us to beat the pants of the competition. (Yes I also work for the Ericsson GSN division.)

I long for Ruby bindings instead. Singleton methods are great for customizing widgets without creating tons of subclasses, so it could be very handy as a RAD language, IMO. Not as much as Erlang, though! :)

If concurrency and running your software on multiple hosts in parallel are very important and you don't mind picking up another language, you could try Erlang. Recent conference proceedings can be found here and here.

You don't even have to write your code in Erlang. You could wrap C code with a wrapper which uses sockets to communicate with the rest of the Erlang environment. Erlang runs on *nix, Windows, BSD, VxWorks and Mac OS X.

Another difficult task will be to design the software that allows all of the radars to communicate. For example, several radars might all get a different image of a part of a storm, from different angles. The software needs to decide what the storm really looks like.

Erlang is the perfect language to use to address this problem. It has built-in support for resource discovery and network communications among an arbitrary number of nodes. IPC is handled by giving every node a mailbox to which messages can be delivered from/to so long as you have the nodes PID; It's as simple as "Node ! doSomething."

Also, OTP (Open Telco Platform) is included with the Erlang release and includes goodies like the distributed database Mnesia. Check it out.

For in-memory distributed database, please have a look at Mnesia (http://www.erlang.org and http://www.erlang.org/doc/r9c/lib/mnesia-4.1.4/doc /html/index.html)

--
Mickael Remond

For in-memory distributed database, please have a look at Mnesia (http://www.erlang.org and http://www.erlang.org/doc/r9c/lib/mnesia-4.1.4/doc /html/index.html)

--
Mickael Remond

Having a programming contest in which only OO languages are permitted is like having a cabinet-making contest in which all work must be done with screwdrivers.

I agree. That's why I posted the previous comment and suggested some scripting languages. I am not too familiar with ML, OCAML or Haskell, but there are some problems for which I would use Erlang. It's a pity that this fine language does not get the attention that it deserves.

A good programmer, just like a good physician or a good carpenter, becomes fluent in the tools of the trade and selects them according to the problem domain.

And the tools of the trade include not only the languages, but also the toolkits and libraries available for those languages. Although I have done it a number of times for specific tasks that required highly optimized code, I would not implement the sockets code for a client-server or some sorting algorithms, etc. Instead, I would install the appropriate libraries and use them. There is no need to re-invent the wheel every time.

<rant>And now a minor rant: my original comment was moderated twice as redundant (down to -1) only because I posted it just a bit after a similar comment that got modded up to +5. A bit more than one minute made the difference. Maybe I should not use to preview button and fix the typos? Or maybe I should not take care of formatting my message in HTML for better readability? The interesting thing is that several other redundant messages that have been posted one hour later did not get moderated down. So the conclusion is that one has to post very fast or post late. But posting just a bit too late (e.g., spending one minute previewing and correcting the comment) can kill a comment that would otherwise be as good (or bad) as another one that gets moderated up very quickly. Ah well, this is Slashdot, after all...</rant> ;-)

Check Mnesia DB from Erlang package. It's not relational, but has high-availablility replication, conflict management, etc. It's reliable and tested. By Ericsson.
Good license.

In my life I've downowded and installed hundreds (if not thousands) of Emacs distributions for at least a dozen of platforms. And I had never had a chance to find BeanShell there. Where do hide it? Or is it possible that you have just mistaken Emacs with vi? How dare you! Oh, by the way, what is the model of the wireless phone that has Emacs in it - I want that phone now!

On a serious note, Java is specially designed to be not scripted - statically typed, eager evaluation, run-time only after a compiler. Every attempt to bring scriptability to Java is making it even slower and even requiring more memory. I've tried BeanShell, Jacl, Jython, Kawa - none of them are good for mobile aplications. All by exactly the same reason: Java itself is the worst case of scenario for embedded applications. Of cource due to its resource requirements.

What's wrong to use scripting language directly, without Java? If you are addicted to imperative semantic (let's say you worked too long with C/C++, and Java and "program" for you is a sequence of commands) then use Python: compact, fast (enough for scripting, at least much faster than any scripting exte4nsion for Java), OOP, widely distributed (not with Emacs, but with many operating systems... just kidding). If you don't have such "imperative" addiction then try Erlang: that langauge has been specially designed for being used in mobile (at first in wireless, but now it's not limited to) applications, it's compact (more compact than JVME), fast (faster than JVME, often as fast as C++), high-level scripting (aka functional-logical) language for disctributed and mobile applications. IMHO ideal choice.

Yet another language where it's possible to do high speed development is Erlang (and here ). (The sites seem to be down temporarily. Is the Slashdot effect that that powerful ?) It's the kind of stuff that you can use to quickly put together a working prototype - ideal for testing "proof of concept". The language + support libs also support distributed applications. So, if your prototype is good, you can try scaling it to multiple CPUs with minimum effort. Don't be fooled by the "telecom" tag that the language comes with - there's more to it than meets the eye.

* concurrent like Erlang
* distributed like Erlang
* functional like Erlang

and point to some comments by the Erlang crowd

Regards,
Marc

* concurrent like Erlang
* distributed like Erlang
* functional like Erlang

and point to some comments by the Erlang crowd

Regards,
Marc

* concurrent like Erlang
* distributed like Erlang
* functional like Erlang

and point to some comments by the Erlang crowd

Regards,
Marc

* concurrent like Erlang
* distributed like Erlang
* functional like Erlang

and point to some comments by the Erlang crowd

Regards,
Marc

I usually hate posting fanboy comments, but must compliment you on your post. Insightful and definitely helpful for me.

Just curious, but you must be either in KTH or Uppsala? :-)

You should take a look at Erlang .

It's much in the style of ML, but with ideas from many other languages thrown in.
And it definitely isn't an "academic" language... it's developed and used by Ericsson
to drive telecommunications systems which have to handle a huge load, and cant be allowed to crash.

Luckily, it's now open source (sorta), and the basic Erlang OTP package
contains about as many side features as Python does :)

It's inherently parallel (a single program can easily distribute itself across multiple computers),
with concurrencies, and all kinds of other fun 'academic' features...
don't get me started on it's vm's model... it brings tears to my eyes in a way only LISP ever could (that's a good thing).

At the moment, I prefer Python, but only because it's got better C integration...
Erlang works best when only the lowlevel drivers are written in C...

-slackergod