Live data from Hacker News

Would You Bet $100M on Your Pet Programming Language? (2007)

prog21.dadgum.com

1–10 of 83 posts

Re: Would You Bet $100M on Your Pet Programming Language? (2007)

#2
(Note: This article, while good, is from 2007 so perhaps its advice is slightly out of date.)

Personally, if I were going in completely blind I'd choose Python (with C as a backup). Numpy and Scipy are fast enough for most of the things that you need to do. It's the "it does pretty much everything" language. Is it great at very high performance games? No. But you can drop into C pretty easily (although I find Ruby + C to be easier) and most of the code you'd be writing isn't going to be core game logic.

Now as to why I'm not coding it now: Because I know what I'm building: Dynamic web apps. Ember (with EmberUI) + a pure Rails JSON backend (with xdomain) will get me there much faster than the needlessly verbose Python. It will also let me hire people that won't have to figure out my stack. It is simpler and less risky. I'd never write this in C.

Re: Would You Bet $100M on Your Pet Programming Language? (2007)

#3
The need for reliable and extensible libraries is a huge one, and that is largely why I am a huge fan of F#. Not that .NET is some silver bullet to solve all your problems, but one could use F# to develop a $100,000,000 system largely because it shares the same framework C# does.

Re: Would You Bet $100M on Your Pet Programming Language? (2007)

#5
I was nodding along until I realized that the author has a very different notion of esoteric from mine.

The last month of Fridays I've been tinkering with Idris, trying to get it to... well, do anything useful. I'd heard it was a dependently typed JVM language, which it is... kinda. Turns out you need to install a full Haskell toolchain to do anything with it. With the right esoteric option incantation, you can make it build an executable that turns out to be a shell script concatenated with a jar file. Nice. But you can't build a library with it, even within the library. You can't invoke it to build some classes to use later. You can't even call the build tool from anything remotely standard in JVM-land, and when I asked about making the compiler selfhosting the response was a kind of lukewarm "yeah, sometime". The current toolchain is in Haskell but there's not even an FFI from Idris into Haskell, so porting it would be... challenging. I tried to join the two together via their C FFI, but in between undocumented linker options and the fact that the Idris runtime is already linked to part of the Haskell runtime, I eventually gave up. If nothing else, it gave me a real appreciation for how much work went into making Scala a serious, commercially usable language, something I'd previously rather taken for granted.

But C, holy shit, C? You'd write a program in C? And expect it to work? I've seen programs go wrong in a lot of languages, but most of them can be eventually fixed. In C you get irreproducible voodoo random crashing that, sure, you can usually track down with a static analyzer, valgrind, debugging, intelligence and luck. But what if you couldn't? What if the program was just broken, and you couldn't fix it? With $100,000,000 on the line, there is no way on earth I would risk letting C (or any other unmanaged language) anywhere near my codebase. It might mean more work, and less features, if I were to use e.g. that pure-OCaml SSL library, or a JVM-native multimedia library. But I'd do it in a heartbeat, all the same. "The final say on overall data sizes" is such a tiny, trivial concern compared to using a language where failure is understandable, reliably diagnosable.

(In fact I'd say the scenarios where a measly factor of 2x memory consumption makes the difference between "working" and "not working" are just vanishingly narrow. If you need to scale horizontally in OCaml, you're going to need to scale horizontally in C a couple of weeks later. Particularly with $100,000,000 on the line, sod it, buy a bigger server with more RAM if using 32GB rather than 64GB really makes the all-important difference).

Would I use a "pet language" I tinker with, like Idris? No, but I wouldn't use that for any kind of serious commercial work. With $100,000,000 on the line, I'd use the same language I use for almost all my work: Scala. And I would stay the hell away from JNI, because I don't want C anywhere near this system, lest it bring it all crashing down.

Re: Would You Bet $100M on Your Pet Programming Language? (2007)

#6

The need for reliable and extensible libraries is a huge one, and that is largely why I am a huge fan of F#. Not that .NET is some silver bullet to solve all your problems, but one could use F# to develop a $100,000,000 system largely because it shares the same framework C# does.

If the target will run it, .NET would probably prove pretty good. You've got a good selection of languages, and even the de facto standard of C# is actually pretty decent (well, I think so anyway - has all the things I liked about Java, and mostly fixes most of the things I didn't). And if you need to write bits in C/C++, that's not a big problem, because the FFI is very easy to use.

(MS's long-term plans for .NET always seem a bit of a mystery, though, and Mono never seemed to get much mindshare. Probably nothing that a bit of your $100,000,000 budget couldn't help with...)

Re: Would You Bet $100M on Your Pet Programming Language? (2007)

#8

The need for reliable and extensible libraries is a huge one, and that is largely why I am a huge fan of F#. Not that .NET is some silver bullet to solve all your problems, but one could use F# to develop a $100,000,000 system largely because it shares the same framework C# does.

I don't know why people always say that. How many full-stack web frameworks are there that use idiomatic F#? Haskell has at least three that were mature three years ago and still under active development. In general the .NET open-source ecosystem is weak; enterprise just waits for Microsoft to reveal the One True Way or spends thousands per seat on clunky tool-kits. That same enterprise will use hundreds of open-source Java libraries. Maybe its changed in the last few years and certainly there is enough there to work with, but I don't think it can rival Python or the JVM and I don't think F# has any edge over Haskell at all when it comes to libraries and community. You get a large, solid core to start with which is more coherent than the de facto Haskell standards but as soon as you start looking for nice idiomatic test frameworks, distributed application frameworks, embedded databases, FRP libraries or many other examples Haskell really leaves it far behind.

Re: Would You Bet $100M on Your Pet Programming Language? (2007)

#9
post #4

Here's one idea: why don't we compile every new language into a pretty C code? This way we will be able to use every available C library with a compiler of our choice and any extra C code, necessary for our real world application.

Because if you use C libraries you will inherit their problems (and also their interface is rarely idiomatic in the new language). Usually if you want to use a different language it's because you think that language has advantages over C. E.g. a large part of the point of using OCaml is to avoid the safety problems of C, but that only applies if your libraries aren't written in C. See https://github.com/mirleft/ocaml-tls#why-a-new-tls-implement...

(Almost all languages do offer some "FFI" to call C. But in languages that don't naturally fit, there will often be significant overhead to e.g. aligning memory management so that the same memory doesn't get freed twice, as might happen when a garbage-collected language called a C library)

Post reply on HN