The language is irrelevant at that price. Given an architect of sub-average skill they'll pick an acceptable one.
Would You Bet $100M on Your Pet Programming Language? (2007)
51–60 of 83 posts
Re: Would You Bet $100M on Your Pet Programming Language? (2007)
#52Earlier quoted context omitted.
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?
There are lots of libraries for building and consuming web services or using messaging products, which is the same as how any heterogeneous environment is integrated. Big companies integrate .NET, Python and Java like this all the time. There ARE also tools and libraries [1] for generating all the JNI code necessary to call directly into JVM libraries but I don't think it has seen much adoption. I'm not really arguing that Haskell is suitable for enterprise applications - it is not. For greenfield SAAS product companies though I think its as viable as F#.
Re: Would You Bet $100M on Your Pet Programming Language? (2007)
#53Earlier quoted context omitted.
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…
I don't think it is so rare, that you could call it occasional. That's the author's point and mine as well. Sometimes I need sqlite, other times libjpeg, giflib, libpng and some simple image processing with at least some low-level code. And it takes a lot of effort to make these things work with other languages on different platforms. Golang tried to make it easier and it still isn't.
Optimizers is also one thing I was worried about, LLVM is not the only compiler out there. And also there is friction. Most of the systems already have C compiler installed, if you target it, there is no friction in setting up building environment and so on.
Re: Would You Bet $100M on Your Pet Programming Language? (2007)
#54Earlier quoted context omitted.
>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.
It's par for the course as far as event-loop I/O goes.
Re: Would You Bet $100M on Your Pet Programming Language? (2007)
#55Well healthcare.gov went with Java [0], but that was about 20x this budget [1], so I think I'll have to go with Forth.
[0] - http://www.randalolson.com/2014/05/22/programming-language-b...
[1] - http://www.bloomberg.com/news/2014-09-24/obamacare-website-c...
Re: Would You Bet $100M on Your Pet Programming Language? (2007)
#56Earlier quoted context omitted.
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…
I'm just taking two lines from the article: "Reliability and proven tools are even more important than libraries"... in this case, there are a lot of proven tools for writing C programs, including the theorem provers. And "You're more dependent on the decisions made by the language implementers than you think"... there have been a lot of flaws in the JRE over time, most of them from the parts of the JRE that are writ…
What is such a theorem prover? I'm interested in it for trying to prove properties of my own programs...
Re: Would You Bet $100M on Your Pet Programming Language? (2007)
#57If $100M were on the line you'd get a mess that met your requirements.
If I wanted good code, I'd take guys who worked on a project for free.
Re: Would You Bet $100M on Your Pet Programming Language? (2007)
#58Earlier quoted context omitted.
> 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.
> That's not the point. Maybe not, but did you miss the bit in my post about FFI and GC? Have you actually tried to implement a non-trivial extension to a GC'ed language which needed to interface with C code? EDIT: The point is not so much that it cannot be done -- the point is that it needs a human ("programmer") to do it. Which kind of defeats the point of "C-as-lingua-franca". Which, if you think about it C alread…
> did you miss the bit in my post about FFI and GC?
No. It's a huge pain, but much less of a pain than calling between two GC'd languages. (I haven't tried calling directly between e.g. Perl and Haskell, but I'd rather gouge my eyes out with a spoon. The handles alone would bury me.) If there were one obvious GC solution, then all GC'd languages would use it, and C would not be as useful. But we've had the JVM and countless other abstractions, yet none has managed to be a higher common denominator than C, so it looks like human labor for the foreseeable future.
Re: Would You Bet $100M on Your Pet Programming Language? (2007)
#59Here'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.
Rust arrays are perfectly compatible with C arrays, they're both just contiguous segments of memory with elements at fixed offsets. You can pass Rust arrays to C functions trivially, and bounds checking has nothing to do with it.
I should also note that all correct C code does bounds checking somewhere. The difference with languages that are bounds-checked by default is that they pessimistically assume that you haven't checked the bound manually, and so can potentially do more bounds checking than is strictly necessary if their optimizers aren't capable of hoisting out the checks.
Re: Would You Bet $100M on Your Pet Programming Language? (2007)
#60Earlier 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…
The bit where you don't know for sure what's in Ruby and what's Rails-specific, argues against your own point for me. I can't help but feel that that sort of attitude is why the more work I take that involves maintaining Rails applications, the less I want to write a new application in Rails... I'd consider using just plain Rails, though my experiences with the code quality of even some aspects of that aren't super great, but most 3rd party Gems for Rails scare the crap out of me at this point in terms of future support burdens. And people throw so many of those into their gemfiles.
2.1.0 :002 > Time.now + 3.hours
NoMethodError: undefined method `hours' for 3:Fixnum
2.1.0 :003 > Time.now.end_of_day
NoMethodError: undefined method `end_of_day' for 2014-12-27 20:52:11 -0600:Time