Live data from Hacker News

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

prog21.dadgum.com

21–30 of 83 posts

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

#21
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 you're thinking that interfacing with C would be easier: No, the FFIs to C are usually as complex as they are for exactly the right reasons, namely that C's semantics don't match very well with $OTHER_LANGUAGE.)

... at which point you're practically implementing your own VM anyway, so, y'know...

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

#22
post #19
post #9

Earlier quoted context omitted.

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.

If you absolutely need a C library, almost all languages give you a way to do that. But why hobble your compilation strategy for all programs just to support this occasional use case better? You may well want to target a runtime (JVM, .net, Javascript) for which no good C compiler exists. Even if you're solely interested in building native executables, compiling to C would mean throwing away a lot of information (e.g. knowing which values are immutable) that an optimizer could use. Look at Haskell; performance-optimized Haskell performs a lot better than machine-generated C ever would (indeed, it often comes close to the performance of hand-tuned C).

(If you're worried about duplicating effort in optimizers, do what many languages do and offer an LLVM frontend. LLVM optimizations are (mostly) language-independent, and LLVM bytecode, while imperfect, often allows a better representation of language semantics than C source would)

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

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

>> But C, holy shit, C? You'd write a program in C?

Most of the worlds software rides on the back of C. Pick a language, the runtime is probably written in C. Any high performance libraries are either in C or C++ (QT anyone?) and for numerics you may still find Fortran. If performance is a requirement or running on a micro controller, you're going to have some C or you fail to get the best performance. That said, stuff like string processing sucks in C - some say that's why C++ was invented.

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

#24
post #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 ?

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 to end, say.

I go (Time.now + 3.hours).end_of_day whereas in Python I have to do "import datetime" (Or is it "import timedelta"? Let me Google) Then I need to do this: http://stackoverflow.com/questions/7985756/whats-the-most-el...

And it's like, how many times do I need to Google Datetime and timedelta. Let alone getting into the weeds with different time zones and daylight savings time changing its calendar day. I could show other examples: Why do I have to pass self into a method when that is the default thing I want to define in a class?

And you can call this all petty bickering but when you sometimes work in machine learning and your model takes 45 minutes to train and to be told by Python that you forgot to import the production configuration file, it's just such a drag. And I know I can type "import *" or include something in my __init__.py but then people will think I don't know what I'm doing. Also what is with "def __init__(self)"? Why isn't it def initialize? Like, the first thing we tell new programmers is that "__" means "warning, don't use me unless you really know what you are doing" then the next thing we say is "go ahead and change __init__ though, that is normal.

1. Type "import this" in a Python REPL to read the full thing.

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

#25
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 standards and guidelines for what you need to do in order to write reliable systems in C. These systems have hard realtime and hard memory requirements.

This is how it works at the extreme end of reliability requirements: you avoid Java and use C, because you'd have to validate the Java runtime anyway, much of which is written in C, and it's just plain easier to validate your C code under an otherwise crippling set of constraints.

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.

Yes, I agree that it is crazy to write your web app in C. But web apps are not the entire world.

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

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

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

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

>> But C, holy shit, C? You'd write a program in C? Most of the worlds software rides on the back of C. Pick a language, the runtime is probably written in C. Any high performance libraries are either in C or C++ (QT anyone?) and for numerics you may still find Fortran. If performance is a requirement or running on a micro controller, you're going to have some C or you fail to get the best performance. That said, stu…

> Most of the worlds software rides on the back of C. Pick a language, the runtime is probably written in C. Any high performance libraries are either in C or C++ (QT anyone?) and for numerics you may still find Fortran.

Maybe you can't eliminate C entirely. But you can avoid using anything in C that doesn't already have millions of users. Even then, I'd still be more worried about those small slivers of heavily tested C than about the rest of the code put together - working on my $100,000,000 project in Scala, the single biggest thing I'd be worried about would be hitting a bug in the JVM itself. The JVM is mostly Java these days, but there's some C/C++ in there and a disproportionate number of critical JVM bugs happen in the C/C++ code (who'd've thought?). And debugging those problems is Not Fun.

C is a hard requirement much less often than people seem to think. I've coded for microcontrollers in C, but I've also done so in Java. Better slow and reliable than fast and buggy.

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

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

>> But C, holy shit, C? You'd write a program in C? Most of the worlds software rides on the back of C. Pick a language, the runtime is probably written in C. Any high performance libraries are either in C or C++ (QT anyone?) and for numerics you may still find Fortran. If performance is a requirement or running on a micro controller, you're going to have some C or you fail to get the best performance. That said, stu…

That is an historical accident of UNIX widespread into the industry.

I am old enough to remember C wasn't even an option unless the customer was willing to shell out money for UNIX systems.

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

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

Which Haskell libraries interoperate with classical enterprise stacks, alongside existing code?

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

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

    
Post reply on HN