

Would You Bet $100,000,000 on Your Pet Programming Language? (2007) - dschoon
http://prog21.dadgum.com/13.html

======
markessien
That's the great thing about a mix of C++ and Python - you can scale up, scale
down, port as you wish, program quickly, program detailed, etc. Such questions
are not even relevant, because it's clear that the languages will not limit
you.

------
stonemetal
I know this is an old article but Jane street Capital makes that bet on
O'Caml.

------
silentbicycle
Lua actually fits his criteria quite well, IMHO. It's fast, written in fully
compliant ANSI C for portability, and very explicitly designed to be embedded
in C / C++. It's also been in use in industry (such as at Petrobras, a big
Brazilian oil company) for over a decade, as well as numerous games
(<http://www.lua.org/history.html>). While the language isn't hard real-time,
you can control (and just pause, or completely replace) the garbage collector.

As per the OCaml example, you could either change what C type Lua uses for its
primary numeric type (it uses doubles by default) or use C userdata (a
garbage-collector-managed pointer to a C struct), since the collection of
numbers probably has some algorithmically relevant characteristics beyond just
being a huge set of numbers.

------
Zak
Actually, if I was concerned about scaling to a 20-core CPU[0], I probably
wouldn't use anything mainstream. It depends on the exact problem, of course,
but that sort of thing is generally easier in functional languages.

Many of the author's questions can be reduced to "does it have a good C FFI?",
but I'm not sure what the overall point is, or if these are just generalized
suggestions to think about before starting a project. I'd like to know what
the author would use in this situation.

[0] AMD has announced a 12-core Opteron for next year, so this isn't far-
fetched at all.

~~~
markessien
In my opinion, that would be a pretty poor decision. Most functional languages
have not actually been tested on a 20 CPUs. You have no idea how optmized it
will run there. You have no idea how it will scale.

You can't have strange hardware, and then decide to go with experimental
software. Stateless programming can be done in any imperative language, and
there are lots of languages that allow you to scale to 20 CPUs, but are very
mainstream.

Parallel-Processing is not much easier in functional languages. But optimizing
to place specific tasks on specific processors is much easier in low level
languages. I'd say your design decision is wrong.

------
jacoblyles
Doesn't the recent port of many languages to the JVM somewhat nullify his
concerns?

I am curious, because I don't know much about programming language
implementations yet, just enough to know what I don't know.

~~~
silentbicycle
Not entirely. While I haven't done much with the JVM-based languages, I've
spent a lot of time dabbling in obscure programming languages (it's a fun and
often very educational way to procrastinate), and many language problems are
fundamentally _social_ : spotty-to-nonexistent documentation, tutorials or
references that are three versions out of date, important libraries on
websites that look like ghost towns ("last updated jan 17, 2004"), etc. can
kill a language, or at the very least encourage the idea that it's abandoned.
A language without a community of people to answer questions, etc. is going to
be very hard to use.

