HN Explorer

Ask HN: What is the future of programming languages?

13 points by Jonovono ↗ HN
Hey HN. The recent post about "Programming Languages Are Simply Not Powerful Enough" got me thinking about what will be the next major change in programming language paradigms.

It seems JS is getting really big lately, since everything is going to the web. But there must be something next that is just a leap different than everything going on right now.

Everything moves to be of higher abstraction to where it's more natural for humans to think and perhaps eventually it will be like writing an essay to get what you want [1].

But what will be after the current languages we see now? With more things relying on computers and people hoping more will get into computers, are there languages that could be made to encourage that?

I have a bunch of random thoughts but I am curious to hear what people that have been involved with computers longer than me think (and ones newer to computers think as well). My little time with prolog made me wish there were more declarative languages.

Any thoughts would be great! I am also kind of looking to see if anyone knows of any open source current programming languages that are trying to 'disrupt' the current way of doing things.

Thanks.

[1] http://blog.wolfram.com/2010/11/16/programming-with-natural-language-is-actually-going-to-work/

16 comments

[ 3.1 ms ] story [ 43.0 ms ] thread
runT1ME
>Everything moves to be of higher abstraction to where it's more natural for humans to think and perhaps eventually it will be like writing an essay to get what you want

I hold the opposite view. Now that compilers are getting smart enough to do very good type inference, and the fact that tools are evolving, I believe strict, static typing will be the future.

The better the type system, the more runtime bugs you prevent from happening. While fighting against the compiler as a veteran programmer is a bit foreign (and makes you feel dumb), it's infinitely preferable than having to debug obscure production bugs.

Good compilers are like a massive suite of unit tests you get for free.

I also see the future of programming languages being functional in nature. Not because of the oft-repeated 'good for concurrency' misnomer (it's an orthogonal issue), but simply because it forces you to think a different way that ends up being more correct than imperative styles.

It takes me much longer (somewhat ashamed to admit) to write a functional library than an imperative one, however, I've been amazed at how well they've turned out and the reuse is much greater.

rartichoke
JS is still pretty sub-optimal, it's not as fast as people make it out to be. Ever try rendering like 30kb of json with node? It's not very fast compared to compiled languages or anything on the JVM.

I think there's tremendous value in having server and client code being in the same language though. I think the future will have things like GWT for other languages as long as JS is what's being ran in the browser.

Meai
I believe the next big thing will be time based programming, it's hard to explain because it's something that you only experience for the first few days when you start to learn programming. It feels like a "goto" for the mind: When you first learn to program, you often think to yourself "why can't I just jump to that block of execution now, jump back to that block with that new info then jump back again into the past where I left off and continue with the new /modified data?" I still experience this frustration sometimes when I have a hard algorithm to solve and I really believe that all current programming languages are just insufficient to model how the mind would work and wants to work.
dragonwriter
> When you first learn to program, you often think to yourself "why can't I just jump to that block of execution now, jump back to that block with that new info then jump back again into the past where I left off and continue with the new /modified data?"

I'm not 100% certain what you are describing, but it sounds like using continuations.

Meai
Maybe a very dumb example: Suppose I get a pointer to an empty byte array. At the very start of the program I had a full byte array. I want to fill my empty array with the stuff I had at the start. But now I have to rewrite my program so that I still have a reference to the "start" (=which is sort of a time, isn't it?), so that I am able to assign that pointer that data. Right now I'm in some function somewhere far far away in the source code. Basically: Jump back in time where I have all my data, references, whatever, work with that state and layout of the program and then jump back out to where I was. So it is sort of like not only modifying the state of the program that I'm going to create, but also modifying the state of the code that I'm creating. Basically the code itself is a program as well.

I have made a gist which should illustrate it maybe a little better: https://gist.github.com/anonymous/24a43cd81843e79df52d

Smudge
The way you describe it as "time" and "history" is confusing. In your gist, essentially you want to roll backwards, fetch the value you had in the previous layer of the stack, and then jump forward to your current execution, but with that reference in tow. So I think I get where you're going, but it doesn't seem very useful to me. The whole point of passing the reference when you need it is that you're giving your code some meaningful context. If any reference were accessible from any method, you'd essentially be dealing with a giant global context of everything. (Isn't that what singletons are for?)
Meai
You are thinking way too much in terms of programming. What's wrong with global context? Your mind is one huge global context, and it seems to work fine. You fetch stuff all the time from one big pool. Sure, there's hierarchy in there. Just like in my example: Different times, different functions, they all provide hierarchy and structure to the times you can fetch data from.
catharsis
This sounds like state based programming. IIRC this was a moderately popular way of programming games in the past. The resulting code is somewhat monolithic however, hard to maintain.
dragonwriter
It doesn't seem to be about time, you seem (by a conservative interpretation) to want to be able to access a the context from which a function was called from within the function: some languages allow you to do that nowm though quite often, even those in which it is possible don't have a direct and convenient mechanism in the language core or standard libraries, though the mechanism is implementable in the language, as in Ruby where Binding.of_caller doesn't exist, but can be implemented (http://extensions.rubyforge.org/rdoc/classes/Binding.html.)

Perhaps you want even more access to environments elsewhere in the call stack; ISTR that there are languages now that allow that.

Of course, doing stuff like that makes it much harder to reason about your programs than treating functions as sealed boxes that communicate via arguments and return values, which is one (but not the only!) reason why most languages deliberately don't make it easy to do.

kedean
Pythons generators are similar to that idea, although it's not their official use. Using 'yield' instead of 'return' in python lets you return to that function at the same point of execution later on (using .next()), at which time you could have changed member variables of the class wrapping that function, effectively modifying the environment of the function, yet the local variables are exactly as they were and so execution still proceeds as it should.

Normally this is used for producing very large lists in an on-demand manner, rather than precomputing, but it can be abused for some very unique things.

zaptheimpaler
Functional programming. At the very least, systems where all logic heavy code is handed off to a functional language and the imperative language serves as the glue (with something like Scala, we won't need even that much). Seriously, that post reminded me of the same thing.

Also, by functional, I DONT mean just map/reduce/filter. The advantage of FP is really in being able to define types and mini DSLs very easily, the kinds of patterns higher order functions allow you to capture, the simplifications afforded by immutable types add up to make functional code the cleanest representation of the problem itself, without any of the cruft.

Try learning Scala, Clojure, or another functional language, and write some serious code in it. Go through a book or a course though, because if you try to pick it up by google and blog posts, you might end up writing basically imperative code in the language, which defeats the purpose.

Personally, writing functional code for the first time opened my eyes to how many problems that I thought were more or less fundamental were just artifacts of the level of abstraction being too low.

31reasons
(())()()(()) Parentheses in FP makes me dizzy, is there an IDE based solution to that ? FP almost feels like speaking a very long statement while running out of breath!
tsm
Parens are a Lisp thing, not an FP thing. Languages like SML and Haskell (especially point-free Haskell) are very light on them.
tikhonj
There is an IDE-based solution! It's called Paredit and can be combined with something like SLIME. (All this for Emacs, of course, but Emacs has all the capabilities of an IDE, especially for Lisp.)

After a while of using paredit, I actually grew to rather like the parentheses. At the very least, it lets me edit in a slightly more semantic fashion: I can navigate, select and modify code based on its structure because the structure is defined by the parentheses.

That said, I actually do prefer not having nearly as many parentheses, which is why I like ML-style syntaxes. Especially Haskell. Idiomatic Haskell is very light on parentheses and braces and brackets--it's a surprisingly minimalistic syntax. I love it.

zaptheimpaler
I used rainbow parentheses for vim (https://github.com/kien/rainbow_parentheses.vim) when working with Clojure, I don't know about IDEs.

Also, only LISPs are parens heavy. Try something like SML or Scala if that turns you off.

Side note: I'm writing some Java code to practice for interviews.. I miss sum types so much. Another thing that FP got right.

logn
"It seems JS is getting really big lately, since everything is going to the web. But there must be something next that is just a leap different than everything going on right now."

I doubt it. You'll just be compiling JS (or a JS descendant) down to a quantum machine or DNA or who knows what. Change is incremental. People talk about the rapid pace of change in technology, but if you learned C in 1985 and no other language for 25 years, you'd not be very far behind right now.