Live data from Hacker News

Near Future of Programming Languages [pdf]

dev.stephendiehl.com

51–60 of 306 posts

Re: Near Future of Programming Languages [pdf]

#51
post #45
post #42

This could be titled "Static typing is not going to save you"? There's nothing but static typing languages and related theorem provers from the timeline slide onwards and the conclusion is that it's too hard. This is a good companion piece for the recent Rich Hickey Clojure/Conj talk :)

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

I edited in the Clojure part after you replied.

Languages that have forgone static typing aren't necessarily trying to solve everything using language types at runtime. See eg Clojure's approach. Or SQL's.

But at the base popularity-contest level the answer is clearly yes: Dynamic languages have been on a roll for the last 30 years - Perl, Python, Ruby, Erlang, Clojure, even JS.

Re: Near Future of Programming Languages [pdf]

#52

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

> Scala has come from Academia, Industry, and Hobbyists.

That's an interesting point. The slide implies there will be no next great programming language because academia nor industry nor hobbyists can deliver it, but overlooks the possibility of a combination working together. For example, Rust started as Graydon Hoare's hobbyist language and then development was sponsored by Mozilla.

Re: Near Future of Programming Languages [pdf]

#53
post #43
post #9

Earlier quoted context omitted.

I would just pronounce it like "coke" and it would just sidestep the whole pronunciation issue. I'm not sure how most people pronounce it but that's what I would do to talk to my boss about it.

This is the precise reason why "route" is pronouced "root" but "router" is mysteriously pronounced "raow-ter". No-one's gonna stand in front of a room full of people and talk about the "rooter".

Huh, TIL. As a non-native English speaker, I have always pronounced "route" as "raowt", probably influenced by the pronunciation of "router".

Btw, why is it "pronUnciation", but "pronOUced". English is hard.

Re: Near Future of Programming Languages [pdf]

#54
post #43

Earlier quoted context omitted.

This is the precise reason why "route" is pronouced "root" but "router" is mysteriously pronounced "raow-ter". No-one's gonna stand in front of a room full of people and talk about the "rooter".

Huh, TIL. As a non-native English speaker, I have always pronounced "route" as "raowt", probably influenced by the pronunciation of "router". Btw, why is it "pronUnciation", but "pronOUced". English is hard.

> Btw, why is it "pronUnciation", but "pronOUced"

In Australian English, it is "pronOUNCiation"

Re: Near Future of Programming Languages [pdf]

#55

“It just feels readable”. -> “It looks like this other language I know.” But: that language might be English (or other natural language). Which is to say maybe computer languages are leveraging the human "language faculty" and rightly so. Which may mean that some languages are always going to feel more foreign.

Considering how many programmers will tell you that C style semicolons and curly braces are more readable than using keywords, I think they've got a point

Re: Near Future of Programming Languages [pdf]

#57
post #43
post #9

Earlier quoted context omitted.

I would just pronounce it like "coke" and it would just sidestep the whole pronunciation issue. I'm not sure how most people pronounce it but that's what I would do to talk to my boss about it.

This is the precise reason why "route" is pronouced "root" but "router" is mysteriously pronounced "raow-ter". No-one's gonna stand in front of a room full of people and talk about the "rooter".

> "This is the precise reason why "route" is pronouced "root"

Actually, this varies with dialect. Route can be pronounced either way: |ˈrüt| or |ˈrau̇t|

https://www.merriam-webster.com/dictionary/route

https://www4.uwm.edu/FLL/linguistics/dialect/staticmaps/q_26...

Re: Near Future of Programming Languages [pdf]

#58
post #37
post #16

One area I haven't seen any good solutions for is the interleaving of tests with production code. I think we need better ways to express tests without cluttering the production code and excessive mocking. What I'd like to do, and really can't in any language/tooling that I know of, is to extract some arbitrary subset of the code and surround it with tests or a test harness. I'd also like to specify various injection…

I recommend taking a look at Clojure Spec https://clojure.org/about/spec or Racket Contracts https://docs.racket-lang.org/guide/contracts.html

I get clojure.spec is primary a way to define a schema and validate against it, and that you can use it for automatic test generation, too. But I feel I fail to grok the whole extent of the possibilities it offers. Does it address any of the other things YZF mentions? Specially, the "prevent excessive mocking" part?

Re: Near Future of Programming Languages [pdf]

#59

TLDR The future of programming languages should involve not naming your language "Coq". I know I am going through the lowest common denominator, but how do you explain to your boss that you're proficient with using Coq. Ugh. Or professor, since apparently it's a proofing language for academia.

Wait, it isn’t pronounced ‘cog’?

No, /kɔk/

https://youtu.be/bIraCzL3dtI?t=4

https://en.wiktionary.org/wiki/coq

Re: Near Future of Programming Languages [pdf]

#60
post #16

One area I haven't seen any good solutions for is the interleaving of tests with production code. I think we need better ways to express tests without cluttering the production code and excessive mocking. What I'd like to do, and really can't in any language/tooling that I know of, is to extract some arbitrary subset of the code and surround it with tests or a test harness. I'd also like to specify various injection…

Forgive me, this is going to sound snarky but I promise I am earnest:

> I'd also like to specify various injection points for tests right as I'm writing the code

You mean, like methods/functions?

> extract some arbitrary subset of the code and surround it with tests

You mean, like modules/classes?

Post reply on HN