Live data from Hacker News

Near Future of Programming Languages [pdf]

dev.stephendiehl.com

171–180 of 306 posts

Re: Near Future of Programming Languages [pdf]

#171
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…

type safety is becoming a hugely desired feature for developers again

I don’t think anyone ever hated type safety, I think they hated verbose syntax and unfortunately conflated the two.

Now we’re finding a happy medium with compiler type inference and people are like, wait what?

Re: Near Future of Programming Languages [pdf]

#172
post #96

Looking at the 2010 Haskell report: most of the committee members come from 'Academia': https://www.haskell.org/onlinereport/haskell2010/haskellli2.... How is it an 'industrial' language? Haskell is the main 'academic' language for a branch of Functional Programming. 'industrial' is just another weasel word.

Haskell lends itself pretty well to "backend"[0] work, and there are more than a few organisations using it to write servers, trading systems, and so on. It definitely fits his metric, which is "> 1000 industrial users".

[0] (Unlike applying it to the frontend, which is a comparatively less mature situation with multiple proposed solutions.)

Re: Near Future of Programming Languages [pdf]

#173
post #107

Earlier quoted context omitted.

I have been thinking about that and there is an issue with it; Delphi (and VB) where written in a time when devs paid a lot for software tools. Besides some niches (embedded) that is not really the case anymore. You expect to pay a few $10 at most in total if that. And a lot of people (but that might be the HN/Reddit echo chamber) demand all to be OSS as well they work with. Making 'a modern Delphi' is a lot of work;…

There are companies trying it though, https://anvil.works/ https://www.outsystems.com/platform/ JetBrains is probably a good example of a "Borland" like company. Outside HN/Reddit bubble that are plenty of companies that are willing to pay for software, the supermarket cashier doesn't take pull requests. Also, the back to native focus on mobile platforms, including Google having to integrate Android apps on ChromeOS,…

JetBrains never did any rapid UI IDE like Delphi did. In fact, all their IDEs are in Swing, which is a mess. I'd totally love having CLion/PyCharm with Qt UI designer, but it's not going to happen.

Re: Near Future of Programming Languages [pdf]

#174
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…

About WYSIWYG, we are missing standards on our APIs. SOAP was going that way but it was way too much, way too early.

Either that, or an ASP.Net view where the backend is interacting with the user through a browser. But that doesn't work well. It's much better to standardize the backend API than the entire frontend.

Re: Near Future of Programming Languages [pdf]

#175

Earlier quoted context omitted.

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…

type safety is becoming a hugely desired feature for developers again I don’t think anyone ever hated type safety, I think they hated verbose syntax and unfortunately conflated the two. Now we’re finding a happy medium with compiler type inference and people are like, wait what?

The response to the recent Rich Hickey talk definitely points toward "dynamic typing as its own solution" (instead of a stop-gap until someone makes static typing less "verbose") being a popular view nowadays.

https://news.ycombinator.com/item?id=15464423

Re: Near Future of Programming Languages [pdf]

#176
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…

I am curious if you've tried IntelliJ with Java or Kotlin, with the various mod cons applied? Because it's quite similar to what you're asking for.

Kotlin does type inference. You can see what the inferred type is if you enable inline type hints. It's not a part of the source code, but it looks as if it is (modulo styling). As you work with the code you can see the inferred type change in real time.

OK, data structure selection, it won't help you pick between a linked list and an array. That said, I'm not sure that feature would bring much benefit to most programs. You almost always want arrays.

Code understanding: if you're unsure what's going on at a particular point, you can just add a breakpoint and run the program. You can then explore the contents of the program, evaluate arbitrary expressions, you can add "evaluation breakpoints" that print out the values of those expressions without stopping the app (on the fly ad hoc logging, in effect), you can investigate how the code you're looking at relates to other code, what the data flows are, what the location in the type hierarchies are, etc. There's a lot of ways to look at the program.

Refactoring; this is the point I went down this train of thought. Because a modern advanced IDE like IntelliJ can do this sort of thing already. It can do things like spot code duplication and fix it for you by extracting a method, in real time, with a single keypress triggered by subtle visual hints like a soft wavy underline. It can convert code between imperative for-loops and functional pipelines of map/filter/fold/etc, in both directions. It can identify and automatically delete unused variables, function parameters, object properties and so on. "Simple" is somewhat in the eye of the beholder, but it's a pretty close realisation of what you seem to be asking for.

The dialogue is not had through markup in the code but rather, through the IDE giving its suggestions using visual hints, and the user starting an interaction through a keypress that brings up a menu of suggestion options ("intentions"), which may in turn lead to more options and so on.

Re: Near Future of Programming Languages [pdf]

#177
post #166
post #140

The "Language Gap" slide seems massively overstated, or maybe I'm misunderstanding. We really have seen a lot of progress in the last 10-20 years, both in industrial languages and in academic ideas that could become the industrial languages of the next 10-20 years (e.g. Idris on the short end, Noether on the longer end). The author laments that pattern-matching is still not standard, but we're getting there; map/redu…

10-20 years ago some of us could use Smalltalk, do systems programming with strong type safe languages, use RAD environments like Delphi, release applications in Prolog, for example. To me it seems we are catching up with the past, and as someone already programming on those environments, it looks we have spent 10-20 years loosing our tools, educating the masses, only to get a taste of things used to be.

I've certainly seen cases where we take one step back in one area to take two steps forward in another; where it takes 5-10 years to get language C that can do something that language A we were using 5-10 years before that could do - but only if we forget that we also wanted some capability in the language B that we couldn't do in A, and C is the first language that manages to synthesise both. And industry is always going to be a long way behind the cutting edge - most of the features we're excited about today are things that were present in ML. But on the whole it feels to me like both a) the mainstream industrial programming experience today is better than it was 10 years ago and b) the academic cutting edge of programming language design today is better than it was 10 years ago, and I expect both those things to continue to be true.

Re: Near Future of Programming Languages [pdf]

#178
post #141

This is a brilliant synopsis of the state of the art -- truly fantastic -- and yet the presentation concludes with, "The innovation won't happen because I can't see where it will come from," and that's not entirely fair. Some areas he covers aren't exhaustively covered and what's missing is quite interesting. In other words, cheer up, there's more hope than what's shown here.

I think this is just a fustration with how little direct incentive there is from our economic system to fix the problem. The only chance of this paradigm existing is as a long shot project that is gifted to society, and the person that makes this gift has the slim chance that it doesn't succeed and all the effort is wasted.

I found that the weakest part of the presentation.

Kotlin and Ceylon both came out of corporate/industrial development. C#, JavaScript and Java continue to evolve entirely due to industrial funding.

I agree that academia is not a great place to do PL research as all the other non-idea aspects of a successful PL don't get enough attention. But industry is doing OK at launching new languages. Perhaps he feels that's "incrementalism" but there's nothing wrong with making solid upgrades that aren't attempts at unicorn style magic cure-alls.

It'd also help if we collectively got over our demand for our tools to always be open source. This has solid justifications behind it but it ensures that programming languages will always be spinoffs of other endeavours rather than having truly focused attention in their own right. When you take away the profit motive, you get stagnation, and that seems to be the main point of the presentation.

Re: Near Future of Programming Languages [pdf]

#179
post #134

Earlier quoted context omitted.

I said 'almost everybody'. Even the most ardent JS fans I work with call it objectively bad.

It's hard to be objective on this. A modern JavaScript engineer would point out that: - The community is very accepting of new engineers. - The ecosystem is huge and there are great solutions available to many problems. - It's easy to write consistent code while avoiding many problems with the language if you use `eslint`, `prettier` and `flowtype`. Tooling on the web is excellent and rapidly improving. - You can use…

How much of that is just solving a problem created by Javascript?

A community accepting of new engineers isn't. But it isn't something to brag about either, because it never means its literal sense. Instead, people say a community accepts new engineers when it has low enough standards that newbies feel empowered without learning anything new. The one language to rule them all mentality is also about low standards.

The ecosystem is just compensating the lack of native features and bad overall design; so is the tooling. Babel is a great tool, but it's just compensating for the lack of a good VM at the browsers; ditto for all the transpiled languages.

Besides, no JS VMs aren't very fast. They are faster than the slowest popular languages (Python, Ruby), but can't get anywhere near the moderately fast ones like Java and .Net.

Re: Near Future of Programming Languages [pdf]

#180
post #142

Earlier quoted context omitted.

> Functional is OK. Imperative is OK. Both in the same program are a mess. I guess you're referring to languages that are not-quite-without-side-effects, but I'd say the biggest influence the functional paradigm has had on other (imperative) programming languages is actually the addition of higher-level data manipulation operations. The functional utility libraries you see for languages such as Python and JavaScript…

Presumably animats is talking about things like "do notation" in Haskell, not innocuous cases of function composition or first-class functions in imperative languages.

I don't know, it's far from perfect, but is there a better way to do sequencing in a pure functional language? You have to be able to specify order of execution to tackle real world tasks unless you do callback/continuation passing style right? I find that a lot less intuitive for most applications.
Post reply on HN