Live data from Hacker News

Near Future of Programming Languages [pdf]

dev.stephendiehl.com

121–130 of 306 posts

Re: Near Future of Programming Languages [pdf]

#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 gained more traction in the industry (not necessarily for people who dedicate their lives to build complex software with a highly general programming language, but for the rest of us).

Re: Near Future of Programming Languages [pdf]

#122

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 doesn't bother you that huge portions of our tech stack are sitting on top of layers of terrible language design that our ancestors will have to deal with? Perhaps the parent post is looking more to the future. Of course it all still works, but when you think we could be doing the same job with Lisp, Smalltalk, (insert any non perfect, but much better than JS technology), it does make me cringe a little.

Re: Near Future of Programming Languages [pdf]

#123
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 agree, and from a different perspective, I would compare this to literature. In English literature we have many different paradigms: Victorian literature, Modernism, Post modernism, Post colonial ect. The language has to be expressive, and in being expressive, it can express any of these different paradigms. The fact that the vocabulary is shared between the "eras" of literature is only a bonus which makes authors more flexible and more able to experiment with actually new concepts, rather than simply reinventing the same old vocabulary.

We then have Chinese literature and Indian literature, and these have very different paradigms. Perhaps it is even hard to effectively translate from Chinese to English. But the actual variance within a given language is still greater than the variance between the languages.

And like human languages, the vocabulary is often arbitrary. In human languages a dog is called a dog not because it makes the sound "dog" and not because it looks like the letters 'd', 'o', and 'g' but for entirely arbitrary reasons of phonetic shift and arbitrary initial designation.

And in lisp you take the 'car' of a tuple and in Haskell you take the 'head' of a list. But the two concepts are very much the same. However, the distinction between continuation passing style (CPS) concurrency and the actor model can be expressed in either langauge just as well. And the distinction between CPS and the actors is FAR grater than the distinction between calling the basic function "head" or "car".

Re: Near Future of Programming Languages [pdf]

#124
post #86

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

If anything, almost too many of them. In the esoteric language area, every new language takes away from libraries for other ones as the communities get spread out. I do think the spread of ideas from that setup is good though.

Re: Near Future of Programming Languages [pdf]

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

It's really not that bad. Modern JS isn't ideal but it has many parts of it that are as good as or better than Ruby or Python, but most people don't act like they are horrible languages. I'd gladly use it over either.

Re: Near Future of Programming Languages [pdf]

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

Re: Near Future of Programming Languages [pdf]

#127

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 doesn't bother you that huge portions of our tech stack are sitting on top of layers of terrible language design that our ancestors will have to deal with? Perhaps the parent post is looking more to the future. Of course it all still works, but when you think we could be doing the same job with Lisp, Smalltalk, (insert any non perfect, but much better than JS technology), it does make me cringe a little.

[deleted]

Re: Near Future of Programming Languages [pdf]

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

Re: Near Future of Programming Languages [pdf]

#129

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.

What are their objective measures?
Post reply on HN