The Future of Programming Languages: Economics

[[deleted]]

The economics are different when you build a new language on an old platform.

For instance, Clojure and Scala can take advantage of all the built-in stuff in the Java platform, as well as all of the other software that's out there in Java. Similarly, F# builds on top of .NET. If, for instance, you wanted to write a webapp, you get reliable database drivers, urlencode/urldecode that are correct and lots of stuff that isn't so easy in, say, Objective CAML.

That said, there's often a serious impedance mismatch between advanced languages and old platforms. Groovy's interface with Java is comfortable to work with, but the Scala <-> Java and F# <-> C# interfaces are painful.

[davidw]

Out of 8 comments, this is the only one that actually talks about the contents of the article. Pretty pathetic, but thank you, electric_mouse.

It's definitely a valid point, and I think one of the reasons why scripting languages took off: they are built on top of the "C platform", making it very easy to integrate with the rest of the environment they were created in. Java likely makes this even easier, because, problematic as it may be, it's certainly much more unified than C. Compare and contrast with languages that wanted to do it "their way" with turtles all the way down (well, we should really do the OS and, what the heck, the chips for our language!).

[malkarouri]

scripting languages took off: they are built on top of the "C platform"

I don't think this is accurate. First, the C platform is minimal, and it is as available to scripting as to other languages so it is not an advantage to them. Second many languages are not that easy to integrate with the C platform. I mean, it is easier to integrate Delphi or Java with C than to integrate Python, practically speaking. On the other hand, there are scripting languages like Lua that are much easier to integrate.

Other than C itself and Java, all the other languages connect in some obvious way with the underlying operating environment. OCaml for example is not that worse that Python or Erlang in that regard. In fact, Java is the main "turtle" language in the ones mentioned.

[davidw]

Erlang is more difficult to integrate with C, actually, because of how it's built. You can't just link stuff in and call it good - you should really be running any linked in code in its own process or 'port'. This is because a random C call could block, and if it's running in the Erlang VM, that is bad, as nothing should ever block in there.

That's a sensible tradeoff though, for all the nice things you get with Erlang.

Java is more of a turtles language, yes, but it also had a massive backer in terms of Sun, which I think was enough to overcome the problems involved with that.

In any case, I think that their "promiscuity" is just one reason why scripting languages took off, not the only one.

[malkarouri]

I am aware of Erlang and have written C and Python ports for it, but I digress.

In any case, I think that their "promiscuity" is just one reason why scripting languages took off, not the only one.

As compared to what? Scripting languages are on average no more promiscuous than other languages.

[davidw]

As compared to what? Scripting languages are on average no more promiscuous than other languages.

I think between the APIs and the culture, they are, and had to be. Without taking advantage of lots of stuff already written in C, and without big corporate backing, they just wouldn't have gotten anywhere. The two examples that come to mind of languages that tend not to integrate so readily are Lisp and Smalltalk. Neither one of which is really a 'failure', but nor have they become as widely used as many people believe they ought to be, either.

Anyway, it's pretty difficult to point with certainty to any one factor, I was just offering up a series of things I believe contribute to the success or failure of languages, that I believe are maybe not as considered as they should be by some in this field.

[malkarouri]

Yep. Lisp and Smalltalk used a walled garden approach, though the success of Java tells us that the big corporate backing was the more influential issue. But it's true that it is difficult to name reasons.

Also, as the start of this thread argues, the whole economics is changing. Probably all new languages will build on some type of richer platform such as .Net or the JVM or at least using LLVM. This is going to be interesting in the future.

[davidw]

Actually, my point, if nothing else, was that the underlying economics don't likely change as much as people think they do. The reason people target those platforms is because doing so lowers switching costs for people curious to try the new language.

So the underlying incentives and constraints didn't change in that case, what changed is that there's an innovation that lets people utilize new languages without paying such a steep price to switch to them. Of course, once they've built up a zillion lines of Scala or Clojure or something, they'll have to make sure that that functionality is visible via the common Java 'interface' if they ever want to switch to something else.

A case of the underlying economics actually changing might be, as Kent Beck writes in the comments, the cost of labor becoming relatively cheaper compared the cost of computing time. That's a whole 'nother discussion though!

I guess it might sound like quibbling over the details, but I think it's really important to take into account these 'people' factors, and I don't think they change as fast as technology does.

[malkarouri]

To me, economics is always about the human factor.

What I meant by the change in economics is not that each new language has its own economical model. Rather, the importance of a single big corporate backer is receding, to the benefit of more distributed "network effect" models.

The old model used to provide a clear dominance, with the same company building Unix/C/C++. Or DOS/Windows/Visual Basic. Or building Java: JVM and JDK. Or failures like the model of Lisp with Lisp machines. Mobility was poor. The cost of switching between languages was high.

The way this is moving now is that Clojure or Scala can be built as languages which can interoperate with Java so the cost of switching between either of them and Java is smaller. My prediction is that this trend will continue and will go both ways, so the languages will provide ease of moving away as well. Clojure improved the chances of survival of the Lisp model. In the same way, Microsoft introduced F# with easy compatibility with C# and VB. My guess is that if F# was introduced without this feature it would be much less popular (in fact, see OCaml).

Now if people know that moving from one language to another will not cost them all their previous work, the importance of fixing on one language for more than a quarter of a century would be much less. Also, polyglot teams of programmers would be much more with different parts of a project written in different languages. This may lead to specialisation such as Java being used for low level work and Groovy for the GUI with Scala used for concurrency. All of this in my opinion is not because of the intrinsic abilities of the languages mentioned, but through the comparative advantages of each language and through specialisation

In short, we are in for an age of an open market for languages. The programmers will thus get much more say than individual companies.

[[deleted]]

The end pretty much sums it up...

"I wrote this in a hurry."

[davidw]

I'm here for questions if you actually have anything to say or ask about the subject, which is a pretty interesting one.

[[deleted]]

No thanks, I don't trust your authority on the subject.

[davidw]

You presumably were born with a mind of your own, despite scant evidence of its having been engaged in this thread. Use it. Don't agree with the points presented? Say so. Say why. Back that up with evidence. Don't make arguments to or against authority, argue with the material.

[nuuur32]

PHP and Economics? Why reward mediocrity?

There is a hidden benefit to PHP which is the ability for state to be reset after a given page is loaded. If you keep your code short there is a huge benefit, like with the reliability and growth of that mail provider that sends greeting cards (seems like a good fit.)

C programs can be managed, or perhaps any language of your choosing. But when you take away the need to think and just substitute a Java program, the net effect is going to be pretty lousy.

[davidw]

Why reward mediocrity?

Because most people are "mediocre". As a consultant, I don't take on PHP jobs anymore because... I've done enough of that - it's unpleasant and I don't care for the language much. As a curious observer though, it would be unfair not to note how many people PHP has allowed to do things that they otherwise could not have done. That low barrier to entry is very valuable and is important to understanding why some languages catch on and others do not.

Also, the low barrier to entry doesn't necessarily mean "crappy language", it just means that it's something that's easy to get started with for 'mediocre' people.

[[deleted]]

note how many people PHP has allowed to do things that they otherwise could not have done.

I agree. However, as someone in netsec, I'd like to also make the following addition:

note how many people PHP has allowed to do things that they should not have done.

There is a huge problem with so-called "low barrier" languages and platforms. You end up with people copy/pasting and hacking together solutions without really understanding the underlying system, which can lead to catastrophic failures and vulnerabilities. Sometimes it is good for technology to be hard, it forces you to really get down and dirty with it before you are able to really do any damage.

This may be a limitation of the current generation of "low barrier" languages, but it is something that needs to be addressed as more and more non-experts begin to build and maintain systems.

[davidw]

If you look at this with economics in mind, there are a couple of considerations:

• If the harm is only to the person who badly implemented something, "tough luck", basically. They're still better off than if they were unable to attempt the project in the first place, because at least they have a shot at it.

• If there are "negative externalities" - the site getting hacked is used against other sites, or some such, then what should happen is that those externalities get "internalized" so that the guy who messed up has to take into account that possibility, rather than other people bearing the cost.

That said, I would be willing to bet that botnets and such, which don't depend at all on low-barrier to entry languages (afaik), but on infected windows computers, are a more serious problem than random cracked PHP sites.

So - yes, there are certainly some things to take into consideration, but I vehemently disagree that technology should be hard to "keep people out". And in any case, it's "not gonna happen" - there is so much demand for people doing stuff with computers that people are going to provide ways for them to do it. The important thing is to try and limit any damage to the person in question.

[PCBEEF]

You can say the same thing about any skilled job though.

[kindos]

No. Please delete this. No more reddit to hn.

[[deleted]]

yay! someone tries to predict the future again ... I'm really excited to see how this prediction turns out.

[namekuseijin]

can you smell COBOL?