
Ask HN: What is the future of programming languages? - Jonovono
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.<p>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.<p>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].<p>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?<p>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.<p>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.<p>Thanks.<p>[1] http://blog.wolfram.com/2010/11/16/programming-with-natural-language-is-actually-going-to-work/
======
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.

------
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!

~~~
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.

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

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

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

