Live data from Hacker News

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

prog21.dadgum.com

11–20 of 83 posts

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

#11
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.

Portable C significantly restricts the machine primitives available, e.g. no explicit SIMD, no explicit control over struct/memory layout, no obviously efficient way to represent type information (say, for implementation of a moving GC), no ability to access machine registers (again GC), ...

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

#12
A hundred million dollars would change my decisions, but it also changes the nature of the problem I'll be working on. The contracts I get are on a much smaller scale which means the problem I'm solving is also of a different scale. The language I chose is based on the fact that my client wants their project done on time and on budget along with the ability to change direction when new requests come in.

If my client wants something as robust as a hundred million dollar budget; they will need a 100 million dollar budget. More often then not they just want something that works.

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

#13
I have trouble accepting the general premise of the question. Not the $100m part... even a $100k job or a $10k job... doesn't matter. It implies that the program being developed has a definitive "done" moment. But software (at least software in constant use) doesn't really get finished. So you build, and you expand, and you rebuild, and new things happen that change your approach and new tech gets developed and your software changes. I can (technically) start coding in Language X and ultimately port the entire codebase to Language Y (or take bits of Language A, B, and C). It's not so much about choosing the right language as reacting to the ever-changing world in which your software is being deployed.

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

#14
post #11
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.

Portable C significantly restricts the machine primitives available, e.g. no explicit SIMD, no explicit control over struct/memory layout, no obviously efficient way to represent type information (say, for implementation of a moving GC), no ability to access machine registers (again GC), ...

You don't have to write extra code in a portable manner, that's the point. You write it how you need it in a real world. But still benefit from refcounting, nice safe strings, higher-order functions, etc. in main part of your program.

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

#15
post #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 +…

"needlessly verbose Python"... For me Python and Ruby are right on par. Could you elaborate further ?

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

#16
I feel like the corollary to this is how quickly one could solve the problems in a pet programming language if $100M was on the line. If the compiler doesn't scale well, hire one of the authors for a bit as a consultant. C with Classes was once someone's pet programming language.

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

#17
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.

If what you want is to use the C library, shoehorning the library APIs into your language is guaranteed to be nastier than just writing in C.

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

#18
post #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…

I think zzzcpan is suggesting to compile from the new toy language to C and then use a C compiler to get native code. This doesn't preclude only using libraries written in the new language. CHICKEN is a Scheme compiler that takes this approach.[0]

The submitted essay addresses the problems that can result from this sort of compilation style with the question "Will native compilation of a big project result in so much code that there's a global slowdown (something actually true of mid-1990s Erlang to C translators)?"

[0]http://www.call-cc.org/

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

#19
post #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…

That's why you would compile it into C instead of having hand-written C when safety is important and for most part of your program it probably is. But sometimes you absolutely need to be able to write assembly and use existing unsafe C libraries.

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

#20
A project this huge is likely to be a distributed system. I can't think of any single binary that could provide $100m in value to one customer. Maybe some really important financial database, but even then...distributed? Right? That being said, we're going to have to use way more than one language, right? Like most projects, right?

No. This question is a red-herring. I think a semi-decent point is being attempted, but I think most Software Engineers ARE good at deciding when it's appropriate to use the right tool.

Quick example: I'm a fan of NodeJS, but I would never use it to try to solve a computation heavy problem, it's good at IO multiplexing, but very little should happen in between connections. My experience has been that most of the Node community is aware of this.

Post reply on HN