5 ms·

> it's nice to see more and more code being written that doesn't assume programmers are superhuman beings I would say that most compilers don't even assume the

> it's nice to see more and more code being written that doesn't assume programmers are superhuman beings I would say that most compilers don't even assume the programmer is human. The root cause of bad errors is that they emanate from the compiler, and are reported from the perspective of the compiler. That's why you get errors like "can't access method undefined of undefined", or the hell that is C++ template errors. Sure, the errors make perfect logical sense from the perspective of a compiler, but they make my human eyes bleed. My favorite is a single missing semicolon that causes a cascade of unrelated errors, none of which indicate there's a missing semicolon. grammars, parsers, compilers, and languages as a whole should be designed for humans first. Even if it makes the language implementation a little more complex, human users will benefit greatly and thank you for it.

boznz 10y ago
I think that is why ADA became popular for mission critical stuff as you can inform the compiler a lot more about the constraints and so in effect make the compiler more user friendly. (Disclaimer happy to be corrected as I have never used ADA but I just finished listening to the podcast on embedded.com and thought it relevant)
- msbarnett 10y ago
  The biggest correction I have is that it's not an acronym -- Ada, not ADA.
  - eatbitseveryday 10y ago
    "ADA" as an acronym is more easily know as "Assistant District Attorney".
    - nommm-nommm 10y ago
      I read ADA first as Americans with Disabilities Act (https://www.ada.gov https://www.ada.gov). In all seriousness, Ada the programming language is named after a person - the English mathematician Ada, Countess of Lovelace known as "the first computer programmer" ( https://en.m.wikipedia.org/wiki/Ada_Lovelace https://en.m.wikipedia.org/wiki/Ada_Lovelace)
- nickpsecurity 10y ago
  Check these out for specific benefits: http://libre.adacore.com/developers/technical-papers-single/Ada-2012-safe-and-secure-booklet http://libre.adacore.com/developers/technical-papers-single/... http://www.adacore.com/press/spark-skein/ http://www.adacore.com/press/spark-skein/
hinkley 10y ago
I have tried about 5 times in my career to sit down to write a programming language. But then I see how little resemblance there is between how a compiler represents your code and how you think about it when trying to debug, fix a typo, split a file, combine two files, delete dead code. I get in a funk and my brain refuses to push past it. I feel like Neo when they tell him about the Matrix and he pukes and passes out.
- infinite8s 10y ago
  Now cue all the LISP guys talking about how the code as the compiler represents it and the way they think about it is the same...
  - taeric 10y ago
    To be fair, the easy way to learn LISP is to learn to think about it the way the compiler represents it. :) That is, there is a bit of a forcing function.
  - qwertyuiop924 10y ago
    No, not if they know ANYTHING about Lisp compiler internals. In any lisp compiler/interpreter suited for the Real World, the sexpr tree you see in your code isn't the datastructure the compiler uses. Why? Because that sexpr tree doesn't account for information like line numbers, which are needed by the compiler for error messages, and other data. The sexpr tree that macros are given is an abstraction. As for error messages, macros make it hard to give good ones C programmers who think their preprocessor macros cause bad problems with error messages, get this: If there's an error inside a macro expansion, the compiler/interpreter is getting errors in code that litterally didn't exist in the source code in any form. Furthermore, there are the standard problems of line numbering and giving the programmer information about where the error was in the actual source, all caused by macros. And Lisp macros are far more pervasive in Lisp than preprocessor macros are in C. Racket tries to solve this with syntax-case, but syntax-case is awkward and breaks the standard macro abstraction in a lot of ways. So the problem remains, and is fairly nasty. Although Lisps and Schemes HAVE gotten better about macro errors over the years...
digi_owl 10y ago
Iirc, there are multiple languages out there that were designed for the humans first. But none of them caught on because they were either too removed from the hardware for its time, or not "macho" enough for the guys in the computer labs.
- jerf 10y ago
  My feeling is that none of them caught on because they implemented a good idea, badly. The way to human friendly languages is not to take the phenomenal power and precision of computer programming languages and slather on a wafer-thin English layer that fuzzes and obscures the underlying complexity. Just because you've fuzzed and obscured the underlying complexity doesn't mean you've made it go away, but in practice you generally have removed huge swathes of the power. I'd say the sort of thing we see Rust doing here is a better path. It is one of the most demanding, detail-oriented languages there is, but this sort of error details and explanation helps the programmer through that, and what comes out the other side is someone who still has the full power of programming, but far more accessibly.
TeMPOraL 10y ago
I'd say its hard because sometimes the errors human make would require a solution comparable to embedding a human-level AI in the compiler. That missing semicolon causing cascade of errors - sometimes it's easy to tell you missed one, sometimes it isn't. Consider following C++ code: int foo = 2 bar = 3; Am I missing a semicolon there? Or maybe a comma? You could probably guess it based on whether or not "bar" exists in the lexical scope during compilation, but then again, maybe I want to shadow it with a "more local" definition? The point is - you can make suggestions based on probabilities, and maybe it is a good idea to integrate a compiler with a linter. But to actually get error messages that make sense, your compiler would have to understand what you mean.
catnaroek 10y ago
C++ wasn't particularly designed for compilers either. :-p
InclinedPlane 10y ago
Are you aware of the C++ error explosion competition? http://tgceec.tumblr.com/post/74534916370/results-of-the-grand-c-error-explosion http://tgceec.tumblr.com/post/74534916370/results-of-the-gra...

boznz 10y ago

I think that is why ADA became popular for mission critical stuff as you can inform the compiler a lot more about the constraints and so in effect make the compiler more user friendly. (Disclaimer happy to be corrected as I have never used ADA but I just finished listening to the podcast on embedded.com and thought it relevant)

msbarnett 10y ago
The biggest correction I have is that it's not an acronym -- Ada, not ADA.
- eatbitseveryday 10y ago
  "ADA" as an acronym is more easily know as "Assistant District Attorney".
  - nommm-nommm 10y ago
    I read ADA first as Americans with Disabilities Act (https://www.ada.gov https://www.ada.gov). In all seriousness, Ada the programming language is named after a person - the English mathematician Ada, Countess of Lovelace known as "the first computer programmer" ( https://en.m.wikipedia.org/wiki/Ada_Lovelace https://en.m.wikipedia.org/wiki/Ada_Lovelace)
nickpsecurity 10y ago
Check these out for specific benefits: http://libre.adacore.com/developers/technical-papers-single/Ada-2012-safe-and-secure-booklet http://libre.adacore.com/developers/technical-papers-single/... http://www.adacore.com/press/spark-skein/ http://www.adacore.com/press/spark-skein/

hinkley 10y ago

I have tried about 5 times in my career to sit down to write a programming language. But then I see how little resemblance there is between how a compiler represents your code and how you think about it when trying to debug, fix a typo, split a file, combine two files, delete dead code. I get in a funk and my brain refuses to push past it. I feel like Neo when they tell him about the Matrix and he pukes and passes out.

infinite8s 10y ago
Now cue all the LISP guys talking about how the code as the compiler represents it and the way they think about it is the same...
- taeric 10y ago
  To be fair, the easy way to learn LISP is to learn to think about it the way the compiler represents it. :) That is, there is a bit of a forcing function.
- qwertyuiop924 10y ago
  No, not if they know ANYTHING about Lisp compiler internals. In any lisp compiler/interpreter suited for the Real World, the sexpr tree you see in your code isn't the datastructure the compiler uses. Why? Because that sexpr tree doesn't account for information like line numbers, which are needed by the compiler for error messages, and other data. The sexpr tree that macros are given is an abstraction. As for error messages, macros make it hard to give good ones C programmers who think their preprocessor macros cause bad problems with error messages, get this: If there's an error inside a macro expansion, the compiler/interpreter is getting errors in code that litterally didn't exist in the source code in any form. Furthermore, there are the standard problems of line numbering and giving the programmer information about where the error was in the actual source, all caused by macros. And Lisp macros are far more pervasive in Lisp than preprocessor macros are in C. Racket tries to solve this with syntax-case, but syntax-case is awkward and breaks the standard macro abstraction in a lot of ways. So the problem remains, and is fairly nasty. Although Lisps and Schemes HAVE gotten better about macro errors over the years...

digi_owl 10y ago

Iirc, there are multiple languages out there that were designed for the humans first. But none of them caught on because they were either too removed from the hardware for its time, or not "macho" enough for the guys in the computer labs.

jerf 10y ago
My feeling is that none of them caught on because they implemented a good idea, badly. The way to human friendly languages is not to take the phenomenal power and precision of computer programming languages and slather on a wafer-thin English layer that fuzzes and obscures the underlying complexity. Just because you've fuzzed and obscured the underlying complexity doesn't mean you've made it go away, but in practice you generally have removed huge swathes of the power. I'd say the sort of thing we see Rust doing here is a better path. It is one of the most demanding, detail-oriented languages there is, but this sort of error details and explanation helps the programmer through that, and what comes out the other side is someone who still has the full power of programming, but far more accessibly.

TeMPOraL 10y ago

I'd say its hard because sometimes the errors human make would require a solution comparable to embedding a human-level AI in the compiler. That missing semicolon causing cascade of errors - sometimes it's easy to tell you missed one, sometimes it isn't. Consider following C++ code: int foo = 2 bar = 3; Am I missing a semicolon there? Or maybe a comma? You could probably guess it based on whether or not "bar" exists in the lexical scope during compilation, but then again, maybe I want to shadow it with a "more local" definition? The point is - you can make suggestions based on probabilities, and maybe it is a good idea to integrate a compiler with a linter. But to actually get error messages that make sense, your compiler would have to understand what you mean.

catnaroek 10y ago

C++ wasn't particularly designed for compilers either. :-p

InclinedPlane 10y ago

Are you aware of the C++ error explosion competition? http://tgceec.tumblr.com/post/74534916370/results-of-the-grand-c-error-explosion http://tgceec.tumblr.com/post/74534916370/results-of-the-gra...