Live data from Hacker News

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

prog21.dadgum.com

31–40 of 83 posts

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

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

You can write reliable programs in C. How about a successful $2.5 billion mission to Mars with 500,000 lines of C? http://programmers.stackexchange.com/questions/159637/what-i... There are a lot of tools available for the design of reliable systems in C. Valgrind is just the beginning. A lot of smart people have put an enormous amount of effort into static and dynamic checkers and theorem provers, as well as standard…

At the point where you're using a theorem prover you're not really writing C any more (I mean, do you count ATS as writing C?). It's a perfectly good way to produce reliable code, sure. But I'm pretty sure it's not what the article is advocating.

> And then, as ill as you speak of C, you turn around and plug your Java systems into C systems, such as Varnish, Nginx, Apache, PostgreSQL, or thousands others that you use every day, not to mention the OS itself.

I do my best to minimize the C surface, and I worry about what I am exposing. E.g. I don't put Apache/Nginx/etc. anywhere in my stack (I either route directly to the JVM or use an Erlang load balancer), which means I wasn't running around patching them in the wake of Heartbleed. I'd use e.g. Riak over PostgreSQL wherever possible.

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

#32
post #15

Earlier quoted context omitted.

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

Part of Python's mantra is "Explicit is better than implicit"[1] which I fully, and wholly disagree with. You end up with a file that has 10 import statements and on larger codebases this just get worse and worse. Furthermore, this leads to less DSLs and other helpers that Ruby is just better at. In Ruby (or possibly just Rails?) say I want to get the start of the day 3 hours from now, when a sports game is supposed…

But, and I am a Ruby neophyte, someone, not the language designer, wrote a library / DSL that somewhere has "end_of_day" defined.

Now I would never ever trust that this nice person got end of day right for my 100M project. Because they cannot. Is that end of day as in close of business or as in midnight? Is that end of day as in the time some we start that process in ? Or end of day as some arbitrary cut off for a global company (frequently in my experience it's a New York day whereas every library starts using UTC). Don't start on leap seconds, leap days, process allocates that can kick off your code on a machine in HK or NY.

Really this stuff needs to be written as a stdlib in the organisation using it. Datetime might be verbose but I can read that code and see what it does in any python program - "end of day" is something I need to go and find the underlying library for.

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

#33
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…

> and also their interface is rarely idiomatic in the new language

This. If you just want C interop, SWIG[1] has been around forever, and is pretty good at generating bindings from a C/C++ header with minimal effort. But if you've ever tried it, you'll know that you still have to do most of the work by hand to create an idiomatic interface in your language of choice.

[1] http://www.swig.org/

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

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

None of the primitive data structures will match up. JVM languages, CLR languages, Rust, Go, et al all have array bound checking, so their arrays won't be compatible with C libraries without a wrapper.

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

#35
post #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-sour…

Well, you're not tied into using strictly F#. The C# MVC framework, or really any web framework, will play nice. The majority of an application like the one the article suggests will sit on a server, anyways. Once you're in server-land, things like web frameworks matter less because .NET already takes care of what you need. F# already has well-supported testing frameworks which integrate into Visual Studio, distributed computing frameworks, database interactivity, graphics libraries, and a slew of others. You can find plenty of testimonails of using F# for large-scale and enterprise systems.

F# and C# are really just your tooling for .NET, which is sufficient for a massive-scale project. Whether or not .NET is appropriate for the project is a different story altogether - I wouldn't use it for anything that's close to the metal, for example.

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

#36
post #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.

... and if the baby isn't born in one month, hire nine women! A lot of the development of mature software can't be parallelized. Paying Simon Peyton-Jones twice as much, or even cloning him, won't make Haskell improve twice as fast.

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

#37
Massive jobs like this tend to require a lot of inter-team dependency. The best language is also one that everyone on the current team understands, and that everyone supporting it will understand. And that will grow in the direction of such a massive project.

My 2 cents... Companies have to selectively pick where they are on the bleeding edge. Extra large projects aren't the best spot to play with the bleeding edge of new programming languages. (This is why COBOL stuck on so long for billing systems)

The place for experimenting with new technologies are smaller self-contained projects where the risk is less, and the benefit can be more clearly explained.

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

#38
post #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, bu…

>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 No it isn't. It is very bad at it. It just uses the most primitive event loop and foists all the complexity of that onto you as the developer using it.

K. From my personal experience it has held up quite well.

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

#39
post #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, bu…

>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 No it isn't. It is very bad at it. It just uses the most primitive event loop and foists all the complexity of that onto you as the developer using it.

You're being downvoted but you're right.

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

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

One potential objection I see (aside from the ones raised by others in this thread) is that C isn't actually that great as a compile target. Aliasing analysis is extremely hard in C (thus preventing obvious optimizations), you'd still have to implement your own GC on top of C, C doesn't do tail-call optimization so you'd have to do your own CPS transform anyway... at which point most of the advantages evaporate. (If…

> C isn't actually that great as a compile target.

That's not the point. C is a great common tongue, as its function call and name lookup semantics are simple, and it doesn't insist on being in control of memory, scheduling, etc. Perl and Python are pretty similar, and both talk to C, but calling between Perl and Python is enough of an unholy mess that it's usually easier to just print text over a pipe.

Post reply on HN