[1]: http://number-none.com/blow/john_carmack_on_inlined_code.htm...
[1]: http://number-none.com/blow/john_carmack_on_inlined_code.htm...
If I had a dollar for every time I asked someone "Okay, look for other uses of this variable" and they grab the mouse and stare at the screen because THEY'RE READING THE ENTIRE FILE LOOKING FOR A PIECE OF TEXT, instead of using any of the dozens of search mechanisms at their disposal, I could retire and write self-help books for programmers.
Stop trying to white-knuckle everything all the time, you masochistic people. Use tools like a sentient creature is supposed to.
Mostly I think the exploratory phase of debugging is a battle between your limited short term memory and your imagination. It's a think you need to do alone and without someone stopping you to ask why every fifteen seconds. I think that's why people are so big on repro steps, so they can go off and start the process of elimination without having to dump state while defending checking possibility A before checking possibility B.
I think the only reason (besides tenacity) that I fix bugs that others gave up on is that I have tricks that let me walk the code faster, which lets me make forward progress on deduction before I forget WHY I was looking under this rock in the first place. My debugging practices look not unlike a guy looking for his missing keys. You have to be careful about when to hit him for questions, and most of the time it's better to just start your own parallel search if you want to help.
There's nothing quite as deflating as finally getting to the end of diagnosing a particularly pernicious bug just to have the understanding trigger the realization that you've encountered this bug before a year or two prior, spent just as much time originally figuring it out, and had somehow forgotten about it the interim. Yay for wasted days of our lives.
I think I need to make a concerted effort to get more sleep.
// time spent = 30
Personally, when I find out / solve something tricky I note down the details in a notes file exactly for cases like this. I'm yet to use it though, because I usually remember the weirder bugs I've seen.
Already in late 90's I couldn't believe what UNIX coders considered state of art, versus what we had on Mac/Windows/Amiga environments (the ones I knew before UNIX).
Having paired quite a bit, it's rather amazing how many programmers just don't know the full utility of their existing tooling. Not because they are stupid, but just because they never made that particular connection.
I have been on the receiving end of this dozens of times, and it is one of my favorite things about pairing as a programmer: where my pair shares a neat trick that saves me a notable amount of time and/or aggravation.
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.
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)
http://libre.adacore.com/developers/technical-papers-single/...
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.
That is, there is a bit of a forcing function.
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...
Want to see that in action? Look at e.g. the intermediate language between Erlang source and BEAM bytecode - it reads like macroexpanded Lisp code with square brackets instead of parentheses.
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.
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.
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.