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

Near Future of Programming Languages [pdf]

dev.stephendiehl.com

Post reply on HN
Print view View original

191–200 of 306 posts

Re: Near Future of Programming Languages [pdf]

#191

Post by pron »

mrkgnao wrote: post #169
pron wrote: post #98

> Will we just be stuck in a local maxima of Java for next 50 years? 1. Yes, if the extent of the imagination is languages like Idris and ideas like effect systems, that follow a gradient descent from Java, and always in the same direction: being able to express more constraints. What you get "for free" from such languages may not be significant enough to justify the cost of adoption, and the valuable stuff you can g…

> What you get "for free" from such languages may not be significant enough to justify the cost of adoption Idris can often infer entire functions from their types if the domain is amenable to accurate type-based specification. For instance, taking the common "sized vector" example, where `Vec n a` refers to a length-n vector of values of type a, functions like zip : Vec n a -> Vec n b -> Vec n (a, b) can be automati…

> Idris can often infer entire functions from their types if the domain is amenable to accurate type-based specification.

This is a great example of what I'm talking about. The kind of functions Idris can generate is that of functions that you could manually write with only marginally more effort -- if that -- than the effort required to write the precise type. I don't think those functions ever form a significant portion of a significant program, if at all (those functions must be so generic, or else there would be a search problem that Idris can't solve, that they would already likely be in the standard libraries). When Idris is able to generate an efficient sorting function given some constraints, then I'd be impressed.

> can be automatically generated via the interactive "proof search" mechanism

If you've spent a significant amount of time with such proof assistants, you'd see that the proof search is rather pitiful.

Re: Near Future of Programming Languages [pdf]

#192

Post by pjmlp »

bitL wrote: post #173
pjmlp wrote: post #107

Earlier quoted context omitted.

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.

They have a GUI designer for Swing.

https://www.jetbrains.com/help/idea/components-of-the-gui-de...

And integrate with Scene Builder for JavaFX.

JavaBeans are the Java version of VCL components.

Qt doesn't have a component eco-system like Java or even .NET enjoy.

The company behind Qt is still trying to sell QML to C++ developers, looking from the set of talks at Qt World Summit.

Re: Near Future of Programming Languages [pdf]

#193

Post by trollopTheJope »

lhnz wrote: post #134
PaulRobinson wrote: post #116

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…

Javascript """engineer"""

Re: Near Future of Programming Languages [pdf]

#194

Post by lispm »

throwaway7645 wrote: post #126
lispm wrote: 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.

If you keep your head to the ground, there are quite a few companies like Facebook that use Haskell for important things in production, but it isn't the language even 50% of the company is using. I'm sure there is a lot more lisp in production, but you typically hear about the same ratio from both camps in the blogosphere.

I would guess that in a company like Facebook, 99.5% of the code they wrote is not Haskell. If they have, say, 200MLOC of code written (just a number), this would be 1MLOC...

Re: Near Future of Programming Languages [pdf]

#195

Post by marcosdumay »

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…

The types line is what some people do with Haskell, Idris. I do personally favor writing the large-scale types beforehand, because that gives the compiler a chance of saying "look, you program is wrong", what is way more useful than "hey, your program has this type". Besides, abstract-type driven programming is an incredibly good methodology where it's applicable.

On code understanding, what makes it better than the programmer inserting the debug statements themselves? It saves some misunderstanding from the computer's part.

On refactoring, some IDEs do that. I'm on the fence about its usefulness.

Re: Near Future of Programming Languages [pdf]

#196

Post by dom96 »

Regarding the effect systems slide. One of my favourite features of the Nim programming language is its effect system,[1] it tracks IO effects, but more importantly it also tracks the exceptions that are raised by each procedure. This allows for a very nice implementation of checked exceptions and docs which contain the possible raised exceptions of each procedure.

1 - https://nim-lang.org/docs/manual.html#effect-system

Re: Near Future of Programming Languages [pdf]

#197

Post by aryehof »

Myrmornis wrote: post #128
aryehof wrote: post #61

My thoughts are that we don't really need more languages. Arguably we don't need better ones either, because they aren't the problem in general computing. Instead we need better design paradigms that better let us model complex requirements and systems into code. Let's have new languages that then support those paradigms. We continue to struggle abstracting complex problems using functional decomposition, structured…

I was going to say something which I think may be similar to what you’re saying. Software and business systems are diagrammed with totally ad-hoc “flow charts”, bubble and arrow diagrams, and less ad-hoc sequence diagrams and UML diagrams. We need advances in formal ways to model concurrent processes, from the level of threads to concurrent business processes.

In a sense yes, although I suggest that a "business process" is too broad and difficult an abstraction. Better for most [1] systems in industry and commerce to elicit and model sequences of recorded events [2] involving interactions with things, people and places in different contexts, with support for constraints [3].

Modeling the above in a business sense, with support in existing paradigms and languages is already a solved problem, just a little known one.

---

[1] The other type of system in industry and commerce being the continuous system that isn't based on recorded events, but instead on logging errors and abnormal circumstances, e.g. an elevator control system or an automated warehouse delivery system, or the engine monitoring software in your car.

[2] Recorded for business or legal reasons.

[3] It's those constraints that prevent an elevator from moving with its doors open, or billing for that product not shipped, or allowing someone to vote twice.

Re: Near Future of Programming Languages [pdf]

#198

Post by pron »

lmm wrote: post #168
pron wrote: post #98

> Will we just be stuck in a local maxima of Java for next 50 years? 1. Yes, if the extent of the imagination is languages like Idris and ideas like effect systems, that follow a gradient descent from Java, and always in the same direction: being able to express more constraints. What you get "for free" from such languages may not be significant enough to justify the cost of adoption, and the valuable stuff you can g…

> if the extent of the imagination is languages like Idris and ideas like effect systems, that follow a gradient descent from Java, and always in the same direction: being able to express more constraints. I don't think that's a fair reflection of what these languages feel like. When your constraints mean that only the right thing can be done, you can make the thing implicit. The things that are tacit when humans tal…

> When your constraints mean that only the right thing can be done, you can make the thing implicit.

Except that sometimes, when you think about the practical issue long and hard enough, you can find that some constraints need not be stated at all, and can be completely factored out of the language, at least in most cases. For example, GC removes resource management out of the equation (it's not always the right solution, but it is the right one in a large enough portion of software). Or, while FP people pore over effect systems and how to constrain effect, languages like Eve that adopt synchronous programming (which is based on ideas from temporal logic), get a mathematical framework in which effects and computation are one and the same, and effects don't pose a challenge to begin with.

> I actually think that gradient ascent from Java will happen, and will move the industry forward

Perhaps, but I doubt it's in the direction pointed to by Idris. We have much better ideas around. The author of the slides mentioned only the segment of PL research that he find appealing. Other segments may have some more promising ideas.

> I think we can go at least one or two substantial steps better than Idris: I want Noether's levels of stratification (beyond just total/not-provably-total), and I want Rust-style linearity, not as a specialised capability but as something integrated into the regular type system. But even if Idris is the limit, it's still a big step ahead of Java, and it's going to take the industry a while to make that step.

I think you have fallen in love with a specific formalism (I've fallen in love with others) and can only see progress within it. If you take a step back, ignore formalism altogether and ask yourself -- or better yet, conduct research -- on what are the actual problems in programming, you may find solutions in completely different directions.

> it's still a big step ahead of Java

I don't think so, and I don't know why you'd think that. I'm not even sure that Java isn't the limit (modulo small improvements). Of course, when I say something is a big step ahead I don't mean that I enjoy it more or that it can pull some more technical tricks, but rather that it reduces development costs by 30%. If Idris is a big step ahead of Java, by how much do you think costs at, say, Google or Amazon or Citibank would drop if they decided they would all switch to Idris tomorrow? I'm fairly certain that it wouldn't be anywhere near 30%, and I'm not even sure costs wouldn't actually rise.

> it feels like most of the industry is only just adopting the things that OCaml offered, and not yet familiar enough with them to appreciate what Haskell offers above that.

I see it not as progress but as change in fashion. Tastes change, and so people adopt some ideas. Have productivity levels risen in the past three decades? Significantly less so than even Brooks's prediction, which was considered overly pessimistic.

Re: Near Future of Programming Languages [pdf]

#199

Post by mrkgnao »

wsxiaoys wrote: post #25

In case of anyone interested a reasonable engineered language that supports Closure Serialization (mentioned as "hard" in last slide), checkout: Gambit Scheme: A fast scheme implementation. http://github.com/gambit/gambit Gerbil Scheme: Provides full module and syntactic tower on top of Gambit Scheme. https://github.com/vyzo/gerbil

Does Guile (or even Chicken) do anything similar?

(My only exposure to it is from Andy Wingo's blog, and I don't know much about Scheme.)

Re: Near Future of Programming Languages [pdf]

#200

Post by mrkgnao »

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…

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

This is possible today, at least in Haskell. (and I'd guess in OCaml too ... surely also Scala?)

Your proposal for adaptive data structure selection based on benchmarking is intriguing!

Post reply on HN