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

281–290 of 306 posts

Re: Near Future of Programming Languages [pdf]

#281

Post by pron »

noam87 wrote: post #262
pron wrote: post #250

Earlier quoted context omitted.

I think they're better largely because I'm more aesthetically drawn to them (so I will be biased, but no more so than the author, who also only mentions techniques he's aesthetically drawn to), but also because I think they have shown more success in practical industry use. For programming interactive systems, a very interesting approach which has been quite successful in realtime software and hardware systems, is sy…

Eve looks interesting, thanks I'll try it out. (And the detailed response.) Most of my programming is in the domain of "take some data, do stuff to it, produce an output" and my experience with Idris so far is very positive -- more so than Haskell (which I admittedly gave up on early on), the language does feel ergonomic, and like the type system is "guiding me" rather than getting in the way. I also find its approac…

BTW, to get a sense of how meticulous Eve's design process is (although I don't know if they'll ultimately be successful in their goal), take a look at this short post, explaining how they've recently decided to change the Eve UI after writing Eve's compiler in Eve (in the previous iteration it was written in Rust): https://groups.google.com/forum/#!msg/eve-talk/tLgrw4zlc5U/V...

Re: Near Future of Programming Languages [pdf]

#282

Post by lhnz »

flavio81 wrote: post #266
lhnz wrote: post #245

Earlier quoted context omitted.

I don't think that comment requires more substantiation than yours that there are "low enough standards that newbies feel empowered without learning anything new". The more people that learn your language, the more likely it is that you will find some that can contribute to its state-of-the-art. A low bar doesn't effect people that would surpass a higher bar with ease: they still wish to learn and sate their natural…

> You can transpile ClojureScript, Elm, Reason, PureScript and many other languages to it. Yet -- surprise! It is still in use. Do you honestly think this is just inertia? No, it isn't inertia -- one important reason is that creating a transpiler to JS invariably ends up with a crippled (feature-restricted), slower version of the original language (Clojure, etc.) Thus the hope placed in Webassembly.

People aren't choosing between those languages based on performance or avoiding any due to missing features. I've never heard of anybody doing that.

People generally choose languages due to assumptions about their hiring pool.

Re: Near Future of Programming Languages [pdf]

#283

Post by lmm »

pron wrote: post #234
lmm wrote: post #228

Earlier quoted context omitted.

> That is a very powerful statement, and I'd like to know why you'd think that. I would even like to know what makes you think that any language (never mind which) can make such an impact, even though we've seen nothing of this sort. I think we have; I think we've seen dramatically accelerating programmer productivity. I think language improvements compound heavily: if a language is slightly more efficient in the sma…

> I think we've seen dramatically accelerating programmer productivity. Really? I think that the change that has contributed to the lion's share of that boost has nothing to do with language features, and has everything to do with the availability of open-source libraries. The other major contributions have been the widespread adoption of automated unit tests -- also not a language feature, and the practicality of GC…

> Do you think that writing, say, an ERP, a power-station control and management software or an air-traffic control system from scratch (without off-the-shelf/open-source libraries) today would be 10x less costly than it was using C++ in 1987, or even 3x less costly than using Java in 2002 (I'm taking 30 and 15 years respectively as milestones)? Remeber that 10x within a decade was seen as pessimistic.

I'd want to amend that to no domain-specific libraries - I think part of the language advantage is making very general libraries possible. But yes, I do think writing such a system to the same standard would be better than 3x cheaper than in 2002. (I don't think that's what would be done - our implicit expectations around software usability are very different today to what they were in 2002. But I do think we'd get more than 3x better value for the same money than in 2002, certainly risk-adjusted - I think in 2002 there would have been a substantial chance that the project would fail outright)

For smaller programs I'd agree that we haven't improved that much, although it's very difficult to talk about how hard it would be to write small programs without libraries because small programs are mostly just using libraries.

Re: Near Future of Programming Languages [pdf]

#284

Post by hood_syntax »

theoh wrote: post #202
hood_syntax wrote: post #180

Earlier quoted context omitted.

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.

Do notation isn't about sequencing, it's syntactic sugar for the monadic 'bind' operator. Sequencing happens because of data dependencies. This is part of the confusing story about monads -- the fact that every monad is a monoid doesn't imply a straightforward linear sequencing, as something like the tardis monad illustrates. https://wiki.haskell.org/Do_notation_considered_harmful More constructively, it could be arg…

Fair enough; I knew do notation was sugar for bind, but I didn't realize/forgot about the time traveling monad.

Follow up questions bc I'm still a Haskell noob:

Do you know if async/wait from Control.Concurrent.Async ensure linear sequencing?

Could the sequencing problem be solved if linear types make their way into Haskell? (They seem to mainly be about memory management, but I'm not sure about other potential applications)

Re: Near Future of Programming Languages [pdf]

#285

Post by dragonwriter »

aryehof wrote: post #197
Myrmornis wrote: post #128

Earlier quoted context omitted.

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…

The distinction you draw is unnecessary; both types of systems deal with planned responses to events, and both have to deal with out-of-spec inputs.

And while them recognition of planned response to events as the unifying abstraction for system analysis is not new (it's at the heart of the structured analysis/design approaches of the 1960s and 1970s which, while displaced somewhat by object-oriented analysis and design, are echoed in more recent tools and technologies like BPMN and Flow-Based Programming, though the analytical methods haven't come back as much as the tools have.)

But, no, modelling for both validation by domain experts who are not computing experts and implementation by developers who are not domain experts is not a solved problem in the general case.

I do agree that a lot that has been learned that is useful in finding adequate solutions to that in specific cases is not as widely known as it should be.

Re: Near Future of Programming Languages [pdf]

#286

Post by smaddox »

tom_mellior wrote: post #256
smaddox wrote: post #244

Earlier quoted context omitted.

Dynamic typing is objectively much more flexible and easier to prototype in. Static typing is much easier to build large and robust systems in. Eventually we'll get to the point where everything you can do in dynamicly languages can be done in staticly typed languages (more verbosely), but we're not there yet. For example, functions that return a different type depending on the values passed in are a useful pattern,…

> For example, functions that return a different type depending on the values passed in are a useful pattern, but not allowed in staticly typed languages, except those with dependent types (Idris) or runtime downcasting (Go). There's always a way to acheive the same thing, but usually at the cost of safety or much more verbosity. Look at this verbose OCaml: type my_return_type = AFloat of float | AnInt of int | AStri…

Yes, you can always generate a new union type for your return type and then pattern match on it. That is certainely better than C where you must use unsafe tagged unions or void pointers. It is more verbose than in dynamic duck-typed languages, though I'll give you that it's quite compact in OCaml.

In a dependently typed language, you could reduce verbosity at the use site as well as avoid the extra runtime branch.

Re: Near Future of Programming Languages [pdf]

#287

Post by marcosdumay »

lhnz wrote: post #282
flavio81 wrote: post #266

Earlier quoted context omitted.

> You can transpile ClojureScript, Elm, Reason, PureScript and many other languages to it. Yet -- surprise! It is still in use. Do you honestly think this is just inertia? No, it isn't inertia -- one important reason is that creating a transpiler to JS invariably ends up with a crippled (feature-restricted), slower version of the original language (Clojure, etc.) Thus the hope placed in Webassembly.

People aren't choosing between those languages based on performance or avoiding any due to missing features. I've never heard of anybody doing that. People generally choose languages due to assumptions about their hiring pool.

If people only choose languages based on popularity, how do you imagine any language ever becomes popular?

Re: Near Future of Programming Languages [pdf]

#288

Post by tom_mellior »

smaddox wrote: post #286
tom_mellior wrote: post #256

Earlier quoted context omitted.

> For example, functions that return a different type depending on the values passed in are a useful pattern, but not allowed in staticly typed languages, except those with dependent types (Idris) or runtime downcasting (Go). There's always a way to acheive the same thing, but usually at the cost of safety or much more verbosity. Look at this verbose OCaml: type my_return_type = AFloat of float | AnInt of int | AStri…

Yes, you can always generate a new union type for your return type and then pattern match on it. That is certainely better than C where you must use unsafe tagged unions or void pointers. It is more verbose than in dynamic duck-typed languages, though I'll give you that it's quite compact in OCaml. In a dependently typed language, you could reduce verbosity at the use site as well as avoid the extra runtime branch.

So how exactly would you write the above five lines of OCaml in fewer than five lines in Idris?

Re: Near Future of Programming Languages [pdf]

#289

Post by lhnz »

marcosdumay wrote: post #287
lhnz wrote: post #282

Earlier quoted context omitted.

People aren't choosing between those languages based on performance or avoiding any due to missing features. I've never heard of anybody doing that. People generally choose languages due to assumptions about their hiring pool.

If people only choose languages based on popularity, how do you imagine any language ever becomes popular?

My point is that those transpiled languages aren't that stymied. You can use them without a lot of problems, and they're being left on the bench for reasons other than their feature set.

Companies generally choose JavaScript because there are lots of developers to choose from, it runs everywhere and the ecosystem is huge.

Engineers choose something like PureScript as it's not a 'blub' language and people think that by choosing it they will be able to hire (or be seen as) "math geniuses". I'm sure the feature set is important, but it's not enough to unseat a language with the previously described properties.

Re: Near Future of Programming Languages [pdf]

#290

Post by wolfgke »

PaulRobinson wrote: post #116
tluyben2 wrote: post #95

Earlier quoted context omitted.

> Javascript everywhere is a function of low barrier-to-entry for it, but almost everybody agrees it is flawed as a language Everybody is everybody who has used other languages intensively or is into programming languages or, the most negative parties against JS, people who are into formal methods. But 'everybody'; I get often downvoted to hell for being negative on JS on Reddit. And i'm not using a baseball bat; i'm…

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

> Even the most ardent JS fans I work with call it objectively bad.

Counterargument: Read

Douglas Crockford - JavaScript: The Good Parts

Even though this book is somewhat "aged" (it is from 2008), I know no better book where it is presented so well what is so interesting about JavaScript and how this language is so often misunderstood.

If after reading this book you still consider JavaScript as "objectively bad", so be it. But first read the arguments that are presented in this book.

Post reply on HN