Live data from Hacker News

Near Future of Programming Languages [pdf]

dev.stephendiehl.com

31–40 of 306 posts

Re: Near Future of Programming Languages [pdf]

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

okay. care to give any other info? Usually when someone says I haven't failed in 'some impressive challenge in a long time' it means your challenge wasn't that impressive. How much interviewing have you done, what were the hard calls you were asked to me, whats your scheme?

When I was at google, one of the hardest thing I did was look at the marginal intern review scores and tried to pick out the ones from the big pile whom we should look at again and who should not be looked at. There were all kinds of crazy ass stupid interview questions that in my opinion were not very useful to classify capability.

Re: Near Future of Programming Languages [pdf]

#32
post #9

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.

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.

I refer to it as "the See Oh Queue theorem proover" at work, which seems to get the idea across.

Re: Near Future of Programming Languages [pdf]

#33

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.

[deleted]

Re: Near Future of Programming Languages [pdf]

#34

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.

I don't think the parent comment deserves all the downvotes.

For programming languages, popularity is crucial. Making them easy to implement, having the compilers as widely available as possible, having the most number of developers pick up the language, etc. That's effectively the thesis of the famous "Worse is Better" essay [1].

As trivial as a name may seem, you're really shooting yourself in the foot if it's something that's awkward to say out loud in a lot of contexts. Workarounds, like pronouncing it differently (as suggested elsehwere in this thread) aren't good solutions, as they hamper communication. Unless the language is already very popular, how do you ensure that everyone else is familiar with the non-standard pronounciation?

[1] https://en.wikipedia.org/wiki/Worse_is_better

Re: Near Future of Programming Languages [pdf]

#35
post #11

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.

"Coq" means "Rooster" in French. Coq (the software) started development at INRIA (France) in 1984 as a small R&D project. I am not particularly shocked that the original developers did not realize the possible double meaning in another language, and being as dismissive as you are seems uncalled for. There are countless startups whose names in English mean something else entirely in another language. For example "Cocu…

> I am not particularly shocked that the original developers did not realize the possible double meaning in another language

Most French people seem to know English quite well, so I would expect they'd be aware of it. Not saying I know this is true for sure, though.

Re: Near Future of Programming Languages [pdf]

#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

Re: Near Future of Programming Languages [pdf]

#38
post #11

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.

"Coq" means "Rooster" in French. Coq (the software) started development at INRIA (France) in 1984 as a small R&D project. I am not particularly shocked that the original developers did not realize the possible double meaning in another language, and being as dismissive as you are seems uncalled for. There are countless startups whose names in English mean something else entirely in another language. For example "Cocu…

The original developers include Thierry Coquand. Also there's a tradition of naming theorem provers after birds (that might have started with Coq though).

But they definitely knew that this pun was there.

Re: Near Future of Programming Languages [pdf]

#39
This talk is right that effect systems aren't popular yet, except the way Haskell does them. But it's wrong about the trajectory of languages. Right now is the best time to be interested in using cutting edge languages in practice. Also right now has seen an explosion of new languages with interesting ideas, from Rust to Purescript to Elm (in the authors preferred realm of typed languages). Also industry is backing major post-Java languages like F# and Rust.

In short, the near future of PL is great, and exciting stuff keeps happening. Don't believe the naysayers.

Re: Near Future of Programming Languages [pdf]

#40
This is a brilliant synopsis of the state of the art -- truly fantastic -- and yet the presentation concludes with, "The innovation won't happen because I can't see where it will come from," and that's not entirely fair. Some areas he covers aren't exhaustively covered and what's missing is quite interesting. In other words, cheer up, there's more hope than what's shown here.
Post reply on HN