Near Future of Programming Languages [pdf] • Hacker News Board

Re: Near Future of Programming Languages [pdf]

#151

Post by chrisseaton » Mon, Oct 30, 2017, 11:50 AM UTC

fnord123 wrote: post #150

chrisseaton wrote: post #139

Earlier quoted context omitted.

> My experience is that functional alone is impossible, since the only useful thing a program can do is through state changes Some programs are simply pure functions. If your program entry point accepts a string and returns a string, then you can write useful things, such as compilers, image processing, grep, etc, entirely as pure functions.

Unless you want logging with timestamps.

My point was that it is not impossible to write useful programs as pure functions.

You can't counter that with an example of a program that you can't write as a pure function.

Re: Near Future of Programming Languages [pdf]

#152

Post by [deleted] » Mon, Oct 30, 2017, 11:51 AM UTC

arianvanp wrote: post #111

aryehof wrote: post #72

Earlier quoted context omitted.

I'm curious which languages have resulted in which new design paradigms?

Two good examples: Erlang led to Microservices and the Reactive Manifesto. the Open Telecom Platform is still a very modern Microservice library (in my opinion) after more than three! decades ML led to programming against generic interfaces ( http://www.cs.cornell.edu/courses/cs312/2006fa/recitations/r... )

[deleted]

Re: Near Future of Programming Languages [pdf]

#153

Post by giantsloth » Mon, Oct 30, 2017, 11:51 AM UTC

d13 wrote: post #135

blipblop wrote: post #118

Earlier quoted context omitted.

> but almost everybody agrees it is flawed as a language. If that's the future, we are screwed as an industry. What language is not flawed? And why are we "screwed"? I don't get this FUD...there are more important things than language-choice such as dependency management system + community + ecosystem. JS lets you get on with the job and get things done quickly. You need performance - use C/C++ bindings. Its been cle…

It's flawed because 99.999% of the time your code will work just fine. Job done. Then one day, "undefined is not a function" and your airplane falls out of the air.

This happens in all languages... look at the Toyota acceleration bug for a real world of example of your hyperbole. They were using MISRA C. Languages dont fix spaghetti, laziness, tight deadlines, bad engineers, etc.

Re: Near Future of Programming Languages [pdf]

#154

Post by saas_co_de » Mon, Oct 30, 2017, 11:56 AM UTC

stmw wrote: post #44

This is a great presentation, I wish I could hear the talk track. While we can all differ on the right "winner" for the next programming language (I don't think Clojure is the right answer, someone else might), we are all stuck with the same set of facts - and this covers the state of things very well. Most importantly, it explains certain truths of the social/economic ecosystem for programming languages - which is w…

On twitter he says:

"The thesis was that programming in 2030 will have very advanced research languages but mainstream languages will effectively stop advancing and we'll be last [sic - left?] with a vast insurmountable gap between the two."

That provides some context for what the slides are about.

Re: Near Future of Programming Languages [pdf]

#155

Post by harimau777 » Mon, Oct 30, 2017, 12:00 PM UTC

PaulRobinson wrote: post #89

Animats wrote: post #78

Things to think about for the near future of programming languages: - The borrow checker in Rust is a great innovation. Previously the options were reference counts, garbage collection, or bugs. Now there's a new option. Expect to see a borrow checker in future languages other than Rust. - Formal methods are still a pain. The technology tends to come from people in love with the theory, resulting in systems that are…

I disagree with a few of your thoughts, but they're good thoughts! * Javascript everywhere is a function of low barrier-to-entry for it, but almost everybody agrees it is flawed as a language. If that's the future, we are screwed as an industry. One thing I've noticed (and I say this as a guy who wrote Ruby for 10+ years), is that type safety is becoming a hugely desired feature for developers again. * WYSIWYG web de…

What causes you to say that JavaScript is a flawed language? Not trying to be snarky or saying you're wrong, just want to better understand your reasoning.

It seems to me that at one point JavaScript had a lot of confusing/bad design decisions but that more recent changes have largely eliminated them. For example, I almost never have to worry about "this" anymore.

I recently worked on a project using TypeScript and I really appreciated how it changed a lot of the bugs from being runtime to compile time. I could definitely see how that is a big flaw, but it seems like the community is developing solutions.

Re: Near Future of Programming Languages [pdf]

#156

Post by fnord123 » Mon, Oct 30, 2017, 12:02 PM UTC

TuringTest wrote: post #121

> Lots of people are reinventing Smalltalk on a Mac. (See Bret Victor and Eve). At last, someone noticed! ;-) Though from that expression, what the author doesn't seem to grok is why having a Smalltalk-like environment is desirable; maybe not as the primary way to program computers but certainly as a tool alongside. It's a shame that a family of programming languages that build on and expanded that model hasn't gaine…

Notebook environments have a lot of traction in industry. Is that not in line with what you're hoping for?

Re: Near Future of Programming Languages [pdf]

#157

Post by saas_co_de » Mon, Oct 30, 2017, 12:04 PM UTC

mlazos wrote: post #86

jlward4th wrote: post #4

"Where will the next great programming language come from?" Interestingly Scala has come from Academia, Industry, and Hobbyists. And for me it's already the next great programming language. Yeah, it has some warts and is hard to learn but that's true of all great things. :)

Yeah this comment stuck out to me in the presentation. Industry has a great record of creating + supporting languages. C#, F#, Dart, Swift, Rust, D are all languages that are actively supported by industry, and some were even created by industry too. Just seemed like a weird statement for the slides to say that new languages just aren’t going to appear.

But how many of those languages include substantial innovation? To me they seem to be mostly rehashing existing technology with slight cosmetic tweaks in order to serve the profit interests and ego of their creators.

Now, whatever innovation this proliferation of languages may bring, it also brings fragmentation which acts as a counter-weight on the value created for the industry as a whole.

Whether the net effect is positive or negative is very difficult to tell.

Re: Near Future of Programming Languages [pdf]

#158

Post by bjz_ » Mon, Oct 30, 2017, 12:05 PM UTC

js8 wrote: post #104

I would love to see programming as a dialogue between user and computer (programmer and compiler). For example: Compiler would infer the types, and the programmer would read it and say, oh, I agree with this type, but I disagree with this type, that's perhaps wrong, this should be rather that type. Then the compiler would infer types again, based on programmer's incremental input. Data structure selection. Programmer…

Programming in Lean, Agda, and Idris have been quite a revelation in terms of interactive type system exploration. Granted, they can be flakey at times (Lean especially), but it's a tantalizing glimpse at what could be around the corner. Hazel[1] is also a pretty exciting look at advancing the idea of 'programming with holes', as is Isomorph[2]. Lots of exciting things around the corner!

[1]: http://hazelgrove.org/

[2]: https://isomorf.io/

Re: Near Future of Programming Languages [pdf]

#159

Post by notacoward » Mon, Oct 30, 2017, 12:07 PM UTC

Animats wrote: post #78

Things to think about for the near future of programming languages: - The borrow checker in Rust is a great innovation. Previously the options were reference counts, garbage collection, or bugs. Now there's a new option. Expect to see a borrow checker in future languages other than Rust. - Formal methods are still a pain. The technology tends to come from people in love with the theory, resulting in systems that are…

> Interprocess communication could use language support.

+100

There have been a few attempts in this direction, but they have mostly been couched in the form of a whole new language that also embodies at least a half dozen other novel (i.e. unfamiliar) ideas as well. Contra the OP, I think this is an area where incrementalism does work. Extending a language people already know with a few constructs for IPC, much like fork/join or async/await have done for concurrency, is much more appealing. I've been thinking about this for a few years now. Maybe I should write some of that down and let people pick at it.

Re: Near Future of Programming Languages [pdf]

#160

Post by bjz_ » Mon, Oct 30, 2017, 12:14 PM UTC

josefrichter wrote: post #91

Just curious where does Elixir fall in this scheme of things? Any experienced devs who could give a qualified answer, please?

Elixir doesn't really push much of the state of the art forward. It's pretty much Erlang with new clothes (and some nice cleanups). I worked with it for over a year and while I loved the 'fail fast' model of programming, most of the errors that were caught were stupid programming errors that would have been trivial to catch by a type system.

What I really want is a type system for reasoning about distributed, stateful, programs. Has to deal with mixing strongly consistent eventually consistent (CRDT) data with synchronisation points (see Bloom/Lasp), hot code reloads, migrations, messaging across nodes, possibly some sort of row polymorphism combined with clojure's namespaced symbols... Like sort-of like Cloud Haskell but with zero-downtime deployments. Or like Pony but with a better distribution story.