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

131–140 of 306 posts

Re: Near Future of Programming Languages [pdf]

#131

Post by bryanph_ »

s4vi0r wrote: post #115
TeMPOraL wrote: post #103

Earlier quoted context omitted.

Great points, but I have a question about one of them in particular: > - Functional is OK. Imperative is OK. Both in the same program are a mess. What do you mean by that? My experience is that functional alone is impossible, since the only useful thing a program can do is through state changes; imperative is a-OK, and functional+imperative in the same program is the best way to do things (i.e. well-defined stateful…

Once you get over the initial learning curve of the functional/pure approach to state/IO, its far superior to imperative imo. You don't need to reason about global state - because everything is explicit, including passing around your state, you never have to worry about "what if someone else or some other code somewhere is touching this" again.

Imperative programming is fine imo, as long as it is done in a relatively small scope.

Re: Near Future of Programming Languages [pdf]

#132

Post by [deleted] »

35bge57dtjku wrote: post #65
tomelders wrote: post #26

Earlier quoted context omitted.

I don’t do coding tests. I talk to the candidate about programming and I only require one interview. I haven’t made a hiring mistake in 6 years.

I'd love to know how you do that, but the answer is always, "I just ask them the right questions and can tell by their answers," which is so vague it's useless.

[deleted]

Re: Near Future of Programming Languages [pdf]

#133

Post by d13 »

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…

Unforuntately JavaScript is the present and, yes, we're screwed.

Re: Near Future of Programming Languages [pdf]

#134

Post by lhnz »

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.

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 one language on the back-end and front-end.
    You can even use the same language to write desktop,
    embedded, command-line and curses applications.
  - `babel` drives the adoption of new features into the
    language with greater vigor than many other languages.
  - The VM is very fast due to lots of work by Google,
    Mozilla, etc. There's also methods of interacting with
    modules written in WebAssembly or if you're on the
    back-end native modules written in Rust/C++.    
  - JavaScript is driving a lot of momentum for
    new programming languages (Reason, Elm, PureScript, etc)
    since as a transpilation target it gives you access
    to many environments and libraries at the get-go.
In my opinion JavaScript in 2017 is a much better language than JavaScript in 2012. I wouldn't call it objectively good but I certainly wouldn't call it 'objectively bad'. There are many reasons to choose it beyond the syntax and semantics of the language itself, and there are effective treatments available for most of the warts it was once known for.

It's dominating because of the sheer drive within the community, and if there were award ceremonies it'd be winning 'Most Improved' year-upon-year.

Re: Near Future of Programming Languages [pdf]

#135

Post by d13 »

blipblop wrote: post #118
PaulRobinson wrote: post #89

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…

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

Re: Near Future of Programming Languages [pdf]

#136

Post by machiaweliczny »

kowdermeister wrote: post #83
stmw wrote: post #45

Earlier quoted context omitted.

I don't really see where you get that. Is dynamic typing demonstrating a lot of sustainable success?

I've seen a comparison lately with static vs. dynamic languages and it compared bugs/open issues and there was not really an advantage there IIRC.

It's just my opinion, but there definitely is difference in favor of optional static typing. It simply adds more expressivness to language - you get free documentation standard (input,output,structures) backed in. You don't have annoying typos and you leave data manipulation computation to computer lowering programmer cognitive load. Also you can change code in editor(fastest feedback loop) without even running it(very important if there is high price for running code - ex. complicated system bootstrap, deployment, hardware).

Re: Near Future of Programming Languages [pdf]

#137

Post by SiVal »

aaron-lebo wrote: post #129
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.

What are their objective measures?

I can think of one: the fraction of design decisions that the language's creator, standardizers, and serious developers wish they could change but can't.

Re: Near Future of Programming Languages [pdf]

#138

Post by vanderZwan »

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…

I find the jab at Bret Victor especially undeserved. He's an interaction designer (a really good one who sees through all the fads[0], which is kind of the opposite of what this one-liner implies). His focus is on better interface design, not formal language design; why criticize someone for something they're not trying to do?

And it's not useless; we probably wouldn't have had Elm without Bret Victor's Inventing on Principle[1][2]. And there has been some progress in that direction of interface design of, for a lack of a better term, "programmable environments": look at Apparatus, for example[3]. Where would you even fit that on these slides?

[0] http://worrydream.com/ABriefRantOnTheFutureOfInteractionDesi...

[1] http://elm-lang.org/

[2] https://vimeo.com/36579366

[3] http://aprt.us/

Re: Near Future of Programming Languages [pdf]

#139

Post by chrisseaton »

TeMPOraL wrote: post #103
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…

Great points, but I have a question about one of them in particular: > - Functional is OK. Imperative is OK. Both in the same program are a mess. What do you mean by that? My experience is that functional alone is impossible, since the only useful thing a program can do is through state changes; imperative is a-OK, and functional+imperative in the same program is the best way to do things (i.e. well-defined stateful…

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

Re: Near Future of Programming Languages [pdf]

#140

Post by lmm »

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/reduce/filter are standard in all new languages these days (they weren't 10-20 years ago), some kind of lightweight record feature is standard in all new languages, some level of type inference is standard in all languages. Yes, it's taken longer than you might imagine it should, but progress is happening. Likewise formal methods - they may not be practical in 2016, but there's a lot more awareness, a lot more work being done, and people are starting to try to take the useful parts and apply them in more and more industrial settings. Likewise graphical representation of code - not the LabView nonsense that's exciting to talk about at cocktail parties, but the little touches that today's IDEs do almost invisibly - highlighting, mouseover information, outline views, smart code folding.

I wish we were better at communicating about programming languages. I wish we were moving faster. But despair is unwarranted. We really are in a much better place than 10-20 years ago, and the next 10-20 years look set to bring more improvements.

Post reply on HN