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

11–20 of 306 posts

Re: Near Future of Programming Languages [pdf]

#11

Post by GuiA »

drefanzor wrote: post #7

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 Social", a cooking startup, whose name in French would mean "gregarious cuckold".

Re: Near Future of Programming Languages [pdf]

#16

Post by YZF »

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 points for tests right as I'm writing the code in a way that doesn't affect the production code and contributes to its readability. Perhaps this is pieces of server and client code or various services all tested together. When I refactor the code I want the tests to "refactor" with the code. I don't want to need to rewrite my tests... Automatic test generation is another interesting area (beyond the basic table or algorithm stuff we might do in tests today).

It's almost like the "problem" isn't the languages themselves, it's the tooling around the languages. I want to be able to do a lot more than "compile", "run", with my code... I can imagine machine learning driven tooling being able to automate a lot of the mechanical aspects of code writing beyond the simple generate a closing bracket that an IDE can do...

Re: Near Future of Programming Languages [pdf]

#18

Post by kbutler »

GuiA wrote: post #11
drefanzor wrote: post #7

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…

...and transliterations into new languages are a fine time for some mispronunciation, like the famous Coca-Cola search for a good Chinese transliteration ("let the mouth rejoice" doesn't sound exactly like English "Coca-Cola", but it's a better brand than "bite the wax tadpole" https://www.snopes.com/cokelore/tadpole.asp )

Re: Near Future of Programming Languages [pdf]

#20

Post by dr-manhattan »

drefanzor wrote: post #7

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.

do they code coq on uranus?
Post reply on HN