4 ms·

Misspelling a keyword is a low-cost issue. The compiler will point it out to you immediately, and compilers are very fast these days. Nothing happening here is

by nv-vn 10y ago

Misspelling a keyword is a low-cost issue. The compiler will point it out to you immediately, and compilers are very fast these days. Nothing happening here is very catastrophic.

sp332 10y ago
Not all languages are compiled.
pyre 10y ago
What happens when your compile step takes a full minute to complete? Sure it's only a minute lost, but it also breaks your flow.
dahart 10y ago
Having a compile fail is catastrophic, not in the sense of the amount of effort it takes to fix, but in the sense that the computer has completely rejected your input. Your compile or execution failed. It won't work without change. Misspelling English doesn't usually cause a complete failure, or force you to try again, that's my point. The example in the essay was a cute comparison that I think actually is worth considering, but is ultimately comparing apples to oranges. But, no matter how fast your compiler is, the cost of finding and fixing a mis-spelling in your editor with syntax highlighting is much less expensive than finding them and fixing them with a compiler or by executing the program. Could be a few seconds per typo less expensive, but my professional experience has generally involved builds that take 1-10 minutes. I'll take the syntax highlighting crutch over waiting for my compiler to fail.
- nv-vn 10y ago
  Compiler errors are much better than the alternative: a run-time bug that won't manifest itself until you put the program under the correct conditions for failure. Compile-time errors are something that programmers have added to compilers to make programming easier/safer because the alternative is truly catastrophic (accidentally shipping broken software and having to isolate more bugs by hand). I'm not really arguing against syntax highlighting, just saying that this argument for it isn't so black-and-white. Keep in mind that there are many issues syntax-highlighting can't catch that your compiler can (unresolved identifiers, using the wrong function, or accidentally choosing the wrong keyword).
woodman 10y ago
The fastest I've ever seen clang compiled, with ccache and in memory fs, was 7 minutes - which is a long time for a syntax check. Just browse any buildbot dashboard. You could use libclang for interactive evaluation - but boy does it suck when the file that you're working on pulls in a page of headers. What you're suggesting is fine for anything that results in an executable named a.out, but it doesn't work for non-trivial software projects.
- nv-vn 10y ago
  Misspelling the keyword happens relatively early in the compiler pipeline (during parsing). If your build hasn't changed very significantly (i.e. something along the magnitude of <1000 lines changed that aren't scattered across tons of files) it should warn you within a few seconds. Anything else is a failure in the design of the compiler or build system. (In fact, outside of C or C++ compilation is usually much, much faster than what you cite). Non-trivial projects in better-designed languages can easily take a tiny fraction of that time.
  - woodman 10y ago
    > If your build hasn't changed very significantly... Change one character in one file that gets linked at the end of the build, the syntax check would go from 7 minutes to 3.5 on average - still too slow. You're also overlooking conditional compilation, your change might break the build on another platform - the syntax won't be checked until it hits the buildbot that flips the right flags. > Non-trivial projects in better-designed languages... Ah, the lets redo-everything-in-x school of thought - good luck with that.

by nv-vn 10y ago

Misspelling a keyword is a low-cost issue. The compiler will point it out to you immediately, and compilers are very fast these days. Nothing happening here is very catastrophic.

sp332 10y ago

Not all languages are compiled.

pyre 10y ago

What happens when your compile step takes a full minute to complete? Sure it's only a minute lost, but it also breaks your flow.

dahart 10y ago

Having a compile fail is catastrophic, not in the sense of the amount of effort it takes to fix, but in the sense that the computer has completely rejected your input. Your compile or execution failed. It won't work without change. Misspelling English doesn't usually cause a complete failure, or force you to try again, that's my point. The example in the essay was a cute comparison that I think actually is worth considering, but is ultimately comparing apples to oranges. But, no matter how fast your compiler is, the cost of finding and fixing a mis-spelling in your editor with syntax highlighting is much less expensive than finding them and fixing them with a compiler or by executing the program. Could be a few seconds per typo less expensive, but my professional experience has generally involved builds that take 1-10 minutes. I'll take the syntax highlighting crutch over waiting for my compiler to fail.

nv-vn 10y ago
Compiler errors are much better than the alternative: a run-time bug that won't manifest itself until you put the program under the correct conditions for failure. Compile-time errors are something that programmers have added to compilers to make programming easier/safer because the alternative is truly catastrophic (accidentally shipping broken software and having to isolate more bugs by hand). I'm not really arguing against syntax highlighting, just saying that this argument for it isn't so black-and-white. Keep in mind that there are many issues syntax-highlighting can't catch that your compiler can (unresolved identifiers, using the wrong function, or accidentally choosing the wrong keyword).

woodman 10y ago

The fastest I've ever seen clang compiled, with ccache and in memory fs, was 7 minutes - which is a long time for a syntax check. Just browse any buildbot dashboard. You could use libclang for interactive evaluation - but boy does it suck when the file that you're working on pulls in a page of headers. What you're suggesting is fine for anything that results in an executable named a.out, but it doesn't work for non-trivial software projects.

nv-vn 10y ago
Misspelling the keyword happens relatively early in the compiler pipeline (during parsing). If your build hasn't changed very significantly (i.e. something along the magnitude of <1000 lines changed that aren't scattered across tons of files) it should warn you within a few seconds. Anything else is a failure in the design of the compiler or build system. (In fact, outside of C or C++ compilation is usually much, much faster than what you cite). Non-trivial projects in better-designed languages can easily take a tiny fraction of that time.
- woodman 10y ago
  > If your build hasn't changed very significantly... Change one character in one file that gets linked at the end of the build, the syntax check would go from 7 minutes to 3.5 on average - still too slow. You're also overlooking conditional compilation, your change might break the build on another platform - the syntax won't be checked until it hits the buildbot that flips the right flags. > Non-trivial projects in better-designed languages... Ah, the lets redo-everything-in-x school of thought - good luck with that.