Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Ask HN: The future of programming languages?

news.ycombinator.com

Post reply on HN
Print view View original

31–40 of 57 posts

Re: Ask HN: The future of programming languages?

#31

Post by swannodette »

contextfree wrote: post #25
swannodette wrote: post #12

Topics that I think will be important: - Functional Programming - Logic Programming - Managing asynchronicity - Managing concurrency / Managing state - Pruning bad directions in OO (see the first two) - Type Systems - Virtual Machines Languages/technologies that I would look at more closely given these are Haskell, Scheme, Prolog, Clojure, Qi, LLVM. I love JS but as far languages go, I would not look there for new id…

I very much hope you turn out to be right. Unfortunately I'm afraid the momentum of the web client platform will be so strong, the impedance mismatch between client and server such a pain, and the progress of JS as a better compiler target so slow (the pressure to interoperate with existing JS libraries may also be a factor here) - that the dominant trend will be towards using JS as a source language everywhere. So t…

JS doesn't solve the client/server impedance mismatch at all. The JS community is struggling with designing libraries that work as well on the server as well as the client.

As Ryan (Node.js) has said, I see JS going the way of PHP. That's great and that it will attract certain kinds of coders and certain kinds of projects.

But setting programming back by a decade? Personally I find JS a much better foundation for learning FP principles than PHP - there's enough in there to guide people to the topics I've outlined above. In fact my interest in these topics arose from being a JS coder for 5 years!

JS is the gateway drug to the new future.

Re: Ask HN: The future of programming languages?

#32

Post by rbranson »

tom_b wrote: post #29
rbranson wrote: post #21

Earlier quoted context omitted.

I'm surprised you included Rails in that list. While there are quite a few Rails jobs, it pales in comparison to what's available for .NET and J2EE. Even PHP blows it away by pure number of jobs.

You know, you're right. Probably a sign of spending more time on HN and peeking around my local community of devs that reflection of a larger trend. A quick look around found that Java, C++, C#, javascript, and perl (?) are big in job listing at Dice.com right now. http://duartes.org/gustavo/blog/post/programming-language-jo... And the always friendly tiobe index at http://www.tiobe.com/index.php/content/paperinfo/tp…

Unfortunately those search queries are worse than "ballpark" figures as they're mostly based on keyword matching, not the amount of code the developer is writing in that language for that job.

There are certain search queries that will always hit high. Of course, JavaScript is going to be in almost any job posting that's web-related, even if it's not true hardcore JS coding. Perl is used heavily for development automation, so it's also going to have a big showing, even if it isn't the core language. You'll also tend to see lines like "Previous scripting experience with Perl, Python, Ruby a plus" for Java postings.

If it could be monetized, doing more sophisticated data mining into job postings for actual popularity trends would be awesome, especially with a decent granularity. It wouldn't be difficult to train a supervised ML algorithm with a set of keyword-tagged job postings with weights as to how significant a certain set of skills would be used at a job for a certain job posting.

Re: Ask HN: The future of programming languages?

#33

Post by chriseidhof »

swannodette wrote: post #12

Topics that I think will be important: - Functional Programming - Logic Programming - Managing asynchronicity - Managing concurrency / Managing state - Pruning bad directions in OO (see the first two) - Type Systems - Virtual Machines Languages/technologies that I would look at more closely given these are Haskell, Scheme, Prolog, Clojure, Qi, LLVM. I love JS but as far languages go, I would not look there for new id…

You can look at Agda, Idris or Epigram for some ideas about what's possible if you go beyond Haskell's type system: dependent types. It allows for even more expressive code. Instead of tests, you write your types, and your program is an executable proof that your type holds. Quite mind-boggling, and very awesome. Of course, these languages are currently only suited for academic use, but I suspect they will inspire other languages.

Re: Ask HN: The future of programming languages?

#34

Post by nkassis »

Aside from programming paradigms, my frankensteinian view of the future is as follow: Javascript VMs become so good, other languages start being built on top of it. The future V8/Rhino... instead of JVM for new languages.

I can certainly see Clojure in JS pretty soon. This might be wishful thinking on my part (see bellow for why).

"Will game development ever diversify or will it go from C++ to C# to ..."

Yes, WebGL is in my view a game changer (pun intended). I'm pretty bias considering I use it currently a lot. But I'm replacing scientific application in C++ with WebGL version online.

Finally, I don't see a slow down in new languages popping up any time soon. I think it's important that they can run on some generic VMs to allow for multi language apps to be possible.

Re: Ask HN: The future of programming languages?

#35

Post by javanix »

grayrest wrote: post #30
javanix wrote: post #13

Earlier quoted context omitted.

Very true. Syntax doesn't really matter in terms of performance - what matters is compiler optimizations. Theoretically someone, if they had a mind, could optimize a Python compiler to run just as fast as C (or at least as fast as a non-statically typed language can run). With that in mind, perhaps some sort of modification to the JVM (or a competing VM that isn't controlled by Oracle) that provides an aggressively r…

> Syntax doesn't really matter in terms of performance - what matters is compiler optimizations. Yes and no. Slight semantic differences can close off optimizations. There was a great discussion on LtU that pulled in a lot of JIT developers. Mike Pall (LuaJIT) tossed out some optimizations the Tracemonkey developers could exploit, but Brendan Eich pointed out that js can't use them: http://lambda-the-ultimate.org/nod…

Huh, cool - I never really looked into what goes into doing compiler optimizations.

What sort of gains would we be looking at with syntactic language differences taken into account?

For instance, suppose I wrote some program in C, compiled, and ran it with the latest GCC/LLVM. If I wrote a program in Python (or Lua) and compiled it down to bare bytecode with a comparably optimized compiler - no interpreter or JIT happenings - would there be a large number of optimizations that just couldn't happen for one language or the other?

Re: Ask HN: The future of programming languages?

#36

Post by Stasyan »

RodgerTheGreat wrote: post #7
javanix wrote: post #4

I really hope that game and other performance-dependent development moves to Go or something like it, rather than being stuck in C/C++ land. The advantages of modern syntax design coupled with a fast native compiler would be a potent and exciting mix.

The good news is that computers seem to be fast enough to allow game developers to work in less than speed-optimal languages, so long as they are willing to accept some stylization. Consider Minecraft, easily the hottest indie title in years, and it's written in straight-up Java. (As far as pure numerical computation is concerned, Java is actually a pretty good match for C++ these days, but 3d graphics remain a fairl…

Regarding "3d graphics remaining serious bottleneck" : any serious 3d graphics is done on GPU. C++ does not have that much advantage over Python or Java, as long as 3d computations are done on GPU

Re: Ask HN: The future of programming languages?

#37

Post by silentbicycle »

javanix wrote: post #35
grayrest wrote: post #30

Earlier quoted context omitted.

> Syntax doesn't really matter in terms of performance - what matters is compiler optimizations. Yes and no. Slight semantic differences can close off optimizations. There was a great discussion on LtU that pulled in a lot of JIT developers. Mike Pall (LuaJIT) tossed out some optimizations the Tracemonkey developers could exploit, but Brendan Eich pointed out that js can't use them: http://lambda-the-ultimate.org/nod…

Huh, cool - I never really looked into what goes into doing compiler optimizations. What sort of gains would we be looking at with syntactic language differences taken into account? For instance, suppose I wrote some program in C, compiled, and ran it with the latest GCC/LLVM. If I wrote a program in Python (or Lua) and compiled it down to bare bytecode with a comparably optimized compiler - no interpreter or JIT hap…

You have to think about what invariants the compiler is capable of recognizing in your code, and can prove are valid: "If I guarantee X, it can do optimization Y behind the curtain, but will still run as if things were compiled normally."

For example, if all variables are immutable by default, they can be inlined at point of use, skipping a lookup. Functions whose arguments are all known can potentially be run once at compile time (partial evaluation). Collections can potentially be handled in parallel if each cell's processing is independent. Etc. This sort of thing is why languages with strong invariants (such as Haskell or Erlang) can do really interesting optimizations.

On the other hand, if the language semantics require that everything is polymorphic and has to be looked up at runtime, that adds extra overhead, and it's not always provable what those values will be at compile-time. A JIT-compiler can compile at runtime, when the information is available, but since they're usually not able to pause execution for long, they can't do extensive analysis. JIT compilers can also make optimizations not statically available because they can revert to the non JIT'd code and recompile differently, whereas static compilation is permanent. (Method lookups can also be cached, of course.)

Incidentally, normal Lua (i.e., not LuaJIT)'s compiler doesn't do much analysis - it's tuned for vacuuming up huge dumps of structured data, rather than trying to generate optimal bytecode. Lua usually still runs significantly faster than Python or Javascript, but that has more to do with the the clean language semantics and high-quality implementation.

Also, a good comment by Mike Pall (the LuaJIT implementer): http://www.reddit.com/r/programming/comments/badl2/luajit_2_...

Re: Ask HN: The future of programming languages?

#38

Post by ggchappell »

swannodette wrote: post #12

Topics that I think will be important: - Functional Programming - Logic Programming - Managing asynchronicity - Managing concurrency / Managing state - Pruning bad directions in OO (see the first two) - Type Systems - Virtual Machines Languages/technologies that I would look at more closely given these are Haskell, Scheme, Prolog, Clojure, Qi, LLVM. I love JS but as far languages go, I would not look there for new id…

Both your list and your comments look good, generally, but I have to wonder about your mention of logic programming.

I think logic programming has a lot to offer the world, in theory, but in practice it seems to be pretty much dead. True, there is probably more going on with Prolog now than, say, a decade ago. But widespread use is not happening, nor is inclusion of logic-programming features into other languages. Further, I don't see this changing in any truly significant way in the near future.

Apparently, you do see it changing. Would you care to comment on that?

Re: Ask HN: The future of programming languages?

#39

Post by silentbicycle »

ggchappell wrote: post #38
swannodette wrote: post #12

Topics that I think will be important: - Functional Programming - Logic Programming - Managing asynchronicity - Managing concurrency / Managing state - Pruning bad directions in OO (see the first two) - Type Systems - Virtual Machines Languages/technologies that I would look at more closely given these are Haskell, Scheme, Prolog, Clojure, Qi, LLVM. I love JS but as far languages go, I would not look there for new id…

Both your list and your comments look good, generally, but I have to wonder about your mention of logic programming. I think logic programming has a lot to offer the world, in theory, but in practice it seems to be pretty much dead. True, there is probably more going on with Prolog now than, say, a decade ago. But widespread use is not happening, nor is inclusion of logic-programming features into other languages. Fu…

Two visible things to come out of logic programming are Erlang and constraint programming. Both are very significant, in their own niches.

I don't think Prolog is dead yet, either.

Re: Ask HN: The future of programming languages?

#40

Post by dkersten »

javanix wrote: post #35
grayrest wrote: post #30

Earlier quoted context omitted.

> Syntax doesn't really matter in terms of performance - what matters is compiler optimizations. Yes and no. Slight semantic differences can close off optimizations. There was a great discussion on LtU that pulled in a lot of JIT developers. Mike Pall (LuaJIT) tossed out some optimizations the Tracemonkey developers could exploit, but Brendan Eich pointed out that js can't use them: http://lambda-the-ultimate.org/nod…

Huh, cool - I never really looked into what goes into doing compiler optimizations. What sort of gains would we be looking at with syntactic language differences taken into account? For instance, suppose I wrote some program in C, compiled, and ran it with the latest GCC/LLVM. If I wrote a program in Python (or Lua) and compiled it down to bare bytecode with a comparably optimized compiler - no interpreter or JIT hap…

Well, for one thing, Python guarantees that objects can be dynamically modified (methods can be rebound, new methods can be added, methods can be removed.. same goes for data members. Python can do this because the methods are stored in a dictionary which gets looked up by method name at runtime). This will never be as fast as a static function call in C or even an indirect vtable-based call (indirect pointer access vs hash table lookup).

That is a single reason why Python can never be compiled to run as fast as C. I'm sure there are plenty of other features that help or hinder performance optimisations. Its all about tradeoffs. (Of course, a suficiently advanced language may allow you to choose these tradeoffs at a finer grain than the language level)

Post reply on HN