[HN Gopher] A case against syntax highlighting (2007)
___________________________________________________________________
A case against syntax highlighting (2007)
Author : svenfaw
Score : 23 points
Date : 2021-09-11 16:11 UTC (6 hours ago)
(HTM) web link (www.linusakesson.net)
(TXT) w3m dump (www.linusakesson.net)
| kazinator wrote:
| Case against indentation! Alice was
| not a bit hurt, and she jumped up
| on to her feet in a moment: she
| looked up, but it was all dark overhead;
| before her was another long passage, and the
| White Rabbit was still in sight,
| hurrying down it.
|
| I mean, just _look_ at it. Would you read a whole book like this?
| You can 't see the semantics for all the obsession with syntax.
|
| Case against multi-file projects! Would you read a book if you
| had to go back to a Makefile or other project artifact to figure
| out where the next chapter is? Come on, put the whole damn
| program in one file that reads from top to bottom!
|
| Case against local variables: but let P
| = "another long passage" it was all dark overhead;
| before her was P, and the White Rabbit
| was still in sight, hurrying down P
|
| This is now totally unnatural "STEM speak". Use the good old
| ambigous anaphoric pronouns, or GTFO!
| tetha wrote:
| Your first example might actually be really nice in something
| like a math paper. Something that follows a somewhat rigid
| premises-argument-conclusion format.
|
| For prose, it's obviously silly, because one point and one goal
| of prose is to keep the reader in the dark about many wonderful
| things - or even mislead them to suprise them. So techniques
| that allow for an easier skimming and back-and-forth (like I
| did to compare example #2 with example #1) are detrimental
| there.
| solmag wrote:
| I have semantic highlighting setup for Rust and I wouldn't give
| it up. Just way too comfy.
|
| "moves focus from content to form", if data drives your code
| structure, especially easy with functional langs, these two start
| to become isomorphic.
| monkeyfacebag wrote:
| I'm confused. This article is about syntax highlighting, not
| semantic highlighting. Do you have semantic highlighting set
| up.or syntax highlighting? If the former, what are are you
| using?
| m4r35n357 wrote:
| clickbait
| dang wrote:
| Some past threads:
|
| _A case against syntax highlighting (2007)_ -
| https://news.ycombinator.com/item?id=11857006 - June 2016 (77
| comments)
|
| _A case against syntax highlighting (2007)_ -
| https://news.ycombinator.com/item?id=8606065 - Nov 2014 (2
| comments)
|
| _A case against syntax highlighting_ -
| https://news.ycombinator.com/item?id=8262192 - Sept 2014 (3
| comments)
|
| _A case against syntax highlighting (2007)_ -
| https://news.ycombinator.com/item?id=7445455 - March 2014 (1
| comment)
|
| _A case against syntax highlighting_ -
| https://news.ycombinator.com/item?id=3717303 - March 2012 (24
| comments)
|
| _A case against syntax highlighting_ -
| https://news.ycombinator.com/item?id=253114 - July 2008 (1
| comment)
| simion314 wrote:
| Most of the help I get in my IDE for JS are
|
| 1 helps with typos , I will notice a weird color and probably
| underlines if the variable or function is undefined so I can fix
| the issue before it crashes somewhere in the future
|
| 2 also helps me when it highlights unused stuff, shows me that a
| refactor or a merge happened and it needs a closer look
|
| 3 we put JSDoc type documentation and colors will look different
| if say you used a method on an object that does not have such
| method or member defined
|
| I create my personalized color schemes that fit me and my
| disabilities so I don't care if maybe it does not work for
| someone else or if soem dude tested on some students and observer
| some small effect or even worse some designer decide how my stuff
| should look because he read some blog posts from his guru and now
| he thinks he is a UX master.
|
| I suggest people try a good IDE, tweak things, I always notice
| bugs in my colleagues code that a good IDE would have prevented
| them.
| xondono wrote:
| The comparison with prose is pure nonsense.
|
| Syntax highlighting is about understanding structure.
|
| I could blur out my editor to the point where I could not make
| out individual letters and still understand the code structure.
|
| When reading prose you don't care about structure, especially not
| in English (in latin languages structure is way more important).
|
| It's important to have a good highlighter though. STM32cube IDE
| has a very bad highlighter that gets confused sometimes.
|
| I've seen people chasing simple bugs for far too long just
| because the highlighter was broken.
| jonplackett wrote:
| Yeah the logic does not follow that highlighting prose means
| highlighting code is bad.
|
| I think the main benefit to highlighting code is it's one less
| task my brain has to do, freeing it up to think about the
| structure of the code in writing and the bigger picture.
|
| Searching your code for that our of place ' is no benefit to
| anyone.
| SkipperCat wrote:
| Agreed, but structure is prose is important too. Who wants to
| read something that is not broken into paragraphs, has not
| capital letters to indicate sentences, etc.
| caconym_ wrote:
| This actually has me wondering if some version of "syntax
| highlighting" could make prose easier to read.
| jonplackett wrote:
| When you're reading a book out loud to a child one thing
| that matters is who is talking (so you can do their voice)
| so colour-coding characters would be nice!
| dschuessler wrote:
| It might help identifying arguments. It's a huge cognitive
| load to identify the premises and the conclusion of an
| argument.[0] I've seen quite a few philosophers using text
| markers to help themselves navigate through arguments in
| prose.
|
| [0]: https://philpapers.org/archive/DAVCAM-8.pdf
| Jtsummers wrote:
| Some language teaching software does use syntax
| highlighting for specific lessons. Rosetta Stone at least
| does, where it specifically highlights things like
| noun/adjective agreement, verb conjugation agreement with
| pronouns and names ( _io_ pag _o_ , capell _o_ ross _o_
| [italics for highlighting since we can 't color text
| here]). And then we use various types of brackets, bold,
| italic, dashes and commas, and other things to isolate what
| we write. If I want to _emphasize_ something, on HN, I use
| a pair of asterisks around the text: *emphasize*.
|
| We use all sorts of typographical conventions to draw
| attention to the things we want emphasis drawn to or to
| encode some notion. In many novels, in English at least, a
| character's thoughts are italicized rather than quoted. The
| noir detective might be found at his desk thinking, _I knew
| I 'd seen her before, but no name came to mind._ In
| textbooks you have a mix of bold and italics used to
| identify specific kind of content. Bold for new keywords
| students of the book should keep in mind, usually adjacent
| to a definition. Italics might indicate a name assigned to
| something: Using the _pumping lemma_ we can...
|
| Perhaps in our code editors we've overdone highlighting, or
| coloring could be a poor (certainly for some colorblind
| readers) method of highlighting, but syntax highlighting
| itself can make a great deal of sense.
|
| It's worth considering that in the examples from prose, we
| usually don't draw attention to _syntax_ , but to
| _semantics_. What does the thing with different typography
| _mean_ , why is it given that special formatting or why is
| it surrounded by special brackets, dashes, or quotes. We
| don't highlight (as in the example in the article) nouns
| one way, verbs another, adjectives a third, and adverbs a
| fourth. Or verbs different ways depending on the tense or
| number. We highlight individual words in some manner to
| bring attention to them, or groups of words to indicate
| their logical separation in some sense from their
| surroundings.
| xondono wrote:
| Yeah, but that's not syntactical structure. When you read
| prose you aren't thinking about subject, verb, and predicate,
| because semantics are far more important.
| gumby wrote:
| Syntax highlighting was originally done with typography, not
| color. Just look at, say, Smalltalk code from the 70s, where
| italics and bold were used to distinguish syntactic elements.
| This was also common in academic papers of the late 70s and early
| 80s as laser printers became more common.
|
| This error helps make the author's point:
|
| > Maybe it was introduced in order to flatten the learning curve.
|
| The steeper the curve, the easier to learn, so I suppose by
| flattening it you are deliberately making learning the piano more
| difficult.
| WalterBright wrote:
| I like syntax highlighting, but prefer the colors to be more
| muted rather than garishly standing out.
| krylon wrote:
| One size does not fit all. If you are more productive without
| syntax highlighting, by all means, disable it.
|
| When I first started to program, I found syntax highlighting
| annoying and distracting, but I changed my mind within a year or
| so. So I have tried both sides and made my choice.
|
| I also think that the usefulness of syntax highlighting depends a
| lot on what language you are using. For example, I found it very
| helpful when working with Perl, but nearly pointless when writing
| SQL. Like I said, one size does not fit all.
| jpeloquin wrote:
| If your IDE didn't use color to indicate syntax, would you want
| different information conveyed through color-coding? Using color
| to indicate syntax, which is already directly visible in the code
| you're reading, does seem like sort of a waste if it could be
| used to convey more useful information.
|
| Using different colors for sync vs async calls could be helpful.
| Or pure vs. impure. Or how many times a function or variable
| definition is used elsewhere in the code base, exercised in
| tests, referenced in the documentation, etc. I think I would find
| this sort of non-local information more useful than syntax
| highlighting.
|
| There was a blog post linked here a couple weeks ago that used
| color shading to distinguish levels of nested parentheses, with
| color shift on mouseover, which was interesting.
|
| The article suggests marking "=" and "==" in different colors,
| which doesn't seem very useful unless the font shows adjacent =
| characters with no space between them.
| deltasixeight wrote:
| Look man. I'm not going to rationalize this.
|
| The main reason why I use syntax highlighting is because I'm use
| to it and it looks cool.
| monkeyfacebag wrote:
| Douglas Crockford has made a similar argument.
| https://www.crockford.com/contextcoloring.html
| xook wrote:
| I went to find the video where I first heard him say something
| about syntax highlighting is for kindergartners
| https://www.youtube.com/watch?v=b0EF0VTs9Dc&t=899
|
| It's an unfortunate comment since I struggle with word salad
| most days. Being able to skim and find certain blocks or
| aspects of a source file is preferable if I can't remember the
| name of something right away.
| approxim8ion wrote:
| I see past syntax highlighting for the most part- until I need it
| and then I don't. I don't understand a lot of this "convenience
| is a crutch" rhetoric around programming. Yes, it's a crutch, but
| for many of us, maybe even most, it enables us to work on the
| stuff that matters with more ease.
| ladberg wrote:
| I'd have to add coloring strings and language keywords to the
| list of exceptions before trying this. Strings are (imo) an
| obvious necessity, but I can't tell you how many times I've
| stopped myself from naming a variable a reserved keyword because
| it showed up visibly differently when typing it out.
| spfzero wrote:
| I'm generally favorable to giving up syntax coloring. I do
| agree with the OP that it distracts without adding much
| benefit. I want to recognize the intent, over the syntax. I do
| usually program in Lisp/Scheme/Racket, which are syntactically
| simple though, and use Solarized which is lower contrast than
| some. So both the distraction and benefits are less.
|
| I guess the main benefit I feel I'm getting now is string
| highlighting and comment dimming. Parens stand out to my brain
| anyway so I don't think I am benefitting from their being
| colorized.
| ape4 wrote:
| This has happened to me too.
| FpUser wrote:
| >"Syntax highlighting is a standard feature of most modern text
| editors"
|
| Sorry it was a standard feature in some IDE's like forever.
| Nothing is modern about it except the fact that the amount of
| what being recognized and made visually different did increase
| thanks in good part to language servers.
|
| As for giving it up - well for what I care they could still use
| punch card, their choice. For me - I would not give it up.
| AprilArcus wrote:
| I find that even the most vacuous syntax highlighting helps me
| read code by creating smaller chunks and calling attention to
| repeated patterns.
| claudiawerner wrote:
| I have a strange use case for syntax highlighting: If you ever
| forget to close a string or a function definition argument list,
| or anything along those lines, the following text will not be
| colored as usual. This is also why I have automatic indentation
| enabled, if the indent is put in the wrong place, I know I made a
| syntax error further up.
|
| In many (most?) languages, you can look at where your code stops
| being colored and see you forgot to close something like a
| comment or a paren.
| laumars wrote:
| That's basically the only thing I like coloured: strings and
| comments. Any more and it becomes distracting visual noise.
|
| I'd never lecture someone on whether they have syntax
| highlighting like the blog post does. It's dumb to argue
| personal preference as if it's fact.
| krylon wrote:
| I do not consider that strange. It might be a side effect, but
| it is _very_ useful, indeed.
| akkartik wrote:
| Where is a function body colored differently than its argument
| list?
|
| (I mostly agree with you. My preferred syntax highlighting is
| for just comments and string literals.)
| mseepgood wrote:
| > If you ever forget to close a string or a function definition
| argument list, or anything along those lines
|
| Wouldn't the compiler find this and the editor mark it as a
| compilation error?
| blendergeek wrote:
| > Wouldn't the compiler find this and the editor mark it as a
| compilation error?
|
| Syntax highlighting happens in real time. Compiling (at least
| in my editor), only happens when I say it should.
| klyrs wrote:
| Depends on the language, depends on the syntax highlighter.
| I've seen syntax highlighters that don't make un-terminated
| python strings look wrong, because the highlighter knows that
| strings can't span multiple lines (others will give a red
| squiggly). Some languages give really cryptic errors about
| the next line -- which gets you in the right neighborhood,
| good enough for me, but not so friendly for newbies.
| toast0 wrote:
| I don't know about the person you're replying to, but I'm
| still old school and don't integrate compiling with my
| editor; maybe some day it will use a language server and get
| that for free, but for now it's just language specific
| configuration that does an OK enough job. When I write a
| string and the rest of the screen is string colored, it
| quickly notifies me that I messed up something.
| yunohn wrote:
| Why wait for the compiler? You're basically saying linting is
| useless versus compiler errors...
| jonnycomputer wrote:
| Compiling isn't always fast. Besides, incorrect syntax will
| usually interfere with the IDE's code inspection; fix-fast,
| fix-early.
| 4ad wrote:
| I can't stand syntax highlighting. I mean literally -- I can't
| read code that is displayed using syntax highlighting, and when
| someone tries to force me to, I can't understand it. When someone
| ask for my help with a piece of code, I have to ask them to turn
| the highlighting off (which in some editors is harder than you
| think). I normally use acme, which doesn't even have syntax
| highlighting, but it bothers me to no end that on some (many?
| all?) Linux distributions vim comes by default with syntax
| highlighting on. Fortunately BSDs come with nvi, which also
| doesn't have syntax highlighting.
|
| Unfortunately, most blog posts and documentation on web sites
| spam syntax highlighting in my face. For those cases I copy the
| code in my editor to read it which also has the benefit of
| allowing me to see it with proportional fonts. I use proportional
| fonts for my programming.
| jonnycomputer wrote:
| Do you have abnormal color vision or anything like that?
| Similar issues outside of code?
| 4ad wrote:
| I don't know, I don't think so. I am very sensitive to the
| color and quality of light, for example I imediately see the
| metameric failure caused by crappy (99%) of LED lights and I
| spent months finding some good LED-based lightbulbs.
|
| One hypothesis that I came out with might be that advertising
| competes for my attention using lots of colors, and I have
| become very experienced in tuning out any kind of
| advertising. I don't consciously associate colored text with
| advertising, but for whatever reason the mechanism seems to
| be active in my brain.
|
| Sometimes color highlighting actually serves as an
| objectively beneficial function, for example colored grep
| output or colored diff output. Even in those cases I still
| have to turn colors off, otherwise I simply skip past the
| important bits of the text that are highlighted.
| david_allison wrote:
| (2007)
|
| I'm not convinced, but this is an interesting take.
|
| The selected examples are unfair as they use a badly contrasted
| foreground color against a white background which break all the
| WCAG Guidelines for contrast. IDEs should use colors with an
| accessible contrast ratio.
|
| #00dd00 (green) -> #ffffff: 1.85:1 - fail on all results
|
| #00dddd (cyan) -> #ffffff: 1.70:1 - fail on all results
|
| I feel another exception would be the differentiation of static,
| member and local variables as an additional IDE-based hint, on
| top of naming conventions.
| runaway wrote:
| This hardly makes a case at all. Only one section in the middle
| is actually dedicated to why syntax highlight is bad and it boils
| down to a baseless assertion about "biasing" the developer's mind
| toward syntax. I would counter that assisting developers in
| thinking about how code will be interpreted or compiled rather
| than bytes of text is closer to the semantic meaning than
| without.
|
| There's also a comparison to highlight syntax in fiction, which
| is absurd for many reasons. A simple one being that the _goal_ of
| fiction can often be to obscure meaning for the sake of
| ambiguity. I'm offended not by the thesis but by the presumptuous
| nature of the argument.
| [deleted]
| drenvuk wrote:
| I have a hunch that everyone who is against syntax highlighting
| is somewhat color blind.
| rbonvall wrote:
| I'd suspect it's the opposite, they may be too sensitive to
| color.
| henvic wrote:
| This is why https://play.golang.org/ has a simple layout with no
| highlight syntax :)
|
| * based on Acme http://acme.cat-v.org/
| mjw1007 wrote:
| Independently of anything else, I find the additional
| distinctiveness created by syntax highlighting helpful for
| keeping my place, or recognising where I am, if I scroll around a
| file quickly.
| thrower123 wrote:
| Extraordinary.
|
| I don't know what it is about programming that churns out these
| takes about not using effective tools and making things harder on
| yourself. There's this odd strain of ascetic masochism that
| breaks out from time to time that I can't say I've observed much
| in other subcultures.
| ziotom78 wrote:
| I started programming the C64, then moved to Turbo Pascal 3 for
| DOS, then Turbo Pascal 6. None of these environments provided
| syntax highlighting. Then came Borland Pascal 7, with syntax
| highlighting... And, boy, I was mesmerized!
|
| I really cannot think of going back to plain two-color editors
| like TP3. Syntax highlighting helps me to spot unterminated
| strings, mistaken variable names that clash with keywords, plus
| the general "feeling" of a page of code that I get when I quickly
| scroll a long source file in search of a specific place.
|
| I do not think that syntax highlighting has spread everywhere
| just because it looks cool. It is SOOO useful!
| alisonkisk wrote:
| Meanwhile, on Mac, we had beautiful THINK Pascal.
| nomaxx117 wrote:
| This is not a very convincing argument at all. Syntax
| highlighting takes away the mental burden of analyzing the syntax
| of a program, freeing the programmer to think about the structure
| and semantics of it. A good IDE (a good vim setup can count too)
| goes further, making the structure and semantics of a program
| more easily discerned.
| kevin_thibedeau wrote:
| The problem in the example is excessive contrast that interrupts
| the visual connectivity of related elements. Stop using party-
| colored themes and the highlighting is less objectionable
| jonnycomputer wrote:
| Good point: no-syntax highlighting is just syntax highlighting
| in one color, with no computation time spent to perform it.
| What the situation really is is that there are a variety of
| ways syntax highlighting can be done--not just the colors, but
| how fine-grained you want to be. Blanket statements like
| "syntax highlighting is bad" just don't make sense.
| rbanffy wrote:
| This is a very good point. Excessive highlighting can be
| distracting by itself. I try to keep it to a minimal - colors
| that are close enough, as well as using bold so that the flow
| of reading isn't broken.
|
| Also, avoid RGBi colors. They are horrible, period.
| zh3 wrote:
| Needs an old year in the title (2007?).
|
| In 2007, I might have agreed.
|
| In 2021, I've added syntax highlighting to my own editor (and
| things feel harder without it).
| [deleted]
| SkipperCat wrote:
| Why on earth would you give up one of the most powerful tools in
| your IDE? Syntax highlighting speeds up readability, helps write
| correct code and IMHO, it makes code look pretty.
|
| Color differentials are also a powerful human visual cue. This is
| why traffic lights are three distinct colors instead of just a
| top, middle and bottom light.
|
| As to the comparison to prose, well, we have tons of syntax
| highlighting there too. Capitals at the beginning of sentences.
| Indentation and spacing between paragraphs, etc.
| guiraldelli wrote:
| > Syntax highlighting speeds up readability, helps write
| correct code and IMHO, it makes code look pretty.
|
| This is a wild claim, and my own experience shows quite the
| opposite.
|
| For two years, I have been interacting with source code without
| syntax highlight.
|
| As a result, I _feel_ I am more focused on the content and less
| distracted. Particularly, that is very noticeable when reading
| foreign (i.e. other people 's) code.
|
| I actually feel that I read slower, but way more attentive. I
| actually give my brain the time to process the information, and
| as a result, I get a lot of overlooked bugs that other
| reviewers don't.
|
| I still find useful, at times, to make the comments in another
| color, but I noticed that doing so, my brain ignore the
| comments and a lot of incorrect comments, that could be
| corrected, went overlooked several times.
|
| Wishing or not, colours are tax your cognition, and for a
| visual person as I am, they were way bigger distractions than
| supports: I don't need colours to tell me "for" is a reserved
| word.
|
| I also find font ligatures very distracting, but it was way
| more obvious to me that they contribution was negative compared
| to syntax highlight.
|
| > Color differentials are also a powerful human visual cue.
| This is why traffic lights are three distinct colors instead of
| just a top, middle and bottom light.
|
| Well, semaphores have just three elements, which are never
| shown simultaneously and the colours are well based on
| semiotics.
|
| That is not the case for syntax highlight.
|
| Syntax highlight seems closer to Stroop test [1] than
| semaphores.
|
| > As to the comparison to prose, well, we have tons of syntax
| highlighting there too. Capitals at the beginning of sentences.
| Indentation and spacing between paragraphs, etc.
|
| Have you looked to a text written in German? That is... Tiring!
|
| In German, all nouns are capitalised. Reading a prose in German
| LOokS lIkE this TO mE.
|
| I think syntax highlight is the equivalent capitalisation of
| nouns in prose.
|
| [1]: https://en.wikipedia.org/wiki/Stroop_effect
| sqrt17 wrote:
| Skimming code is a legitimate task. At a large/FAANG company you
| will often have a 400k sloc code base and only a vague idea which
| bits of code you need to study more intensively to find out what
| you need.
| WalterBright wrote:
| This inspired me to:
|
| https://github.com/DigitalMars/med/commit/adcc084e2142723695...
| jonnycomputer wrote:
| Bold claims + no-evidence
|
| A point of counter-evidence. Developers seek out syntax
| highlighting. Perhaps they've all been duped by the hype.
| Orrrrrrr they actually find it helpful.
|
| Without more evidence, I'm going with #2.
| snicker7 wrote:
| For emacs, I recommend the 'almost-mono-themes' package [0]. It
| supports syntax highlighting without making your editor look like
| Mardi Gras.
|
| [0]: https://github.com/cryon/almost-mono-themes
| NiceWayToDoIT wrote:
| Syntax highlighting is more than the article is mentioning, it
| seems author comment is focused on old highlighters. Once when
| you get used to one theme brain is not even noticing, unless as
| shown in example colors are highly offending to aesthetic (the
| one in the article is hurting my brain). In modern editors as
| VSCode there is a huge range of adjustments. Nowadays we can do
| more than just see what are commands, keywords, increments ... we
| can see unused variables/import, mistyped variable, see bracket
| that are not closed, comments, etc.
|
| With syntax highlighters can be applied same rule as with UI,
| pleasing interface make it more usable.
| https://www.nngroup.com/articles/aesthetic-usability-effect/
| quocanh wrote:
| This article is very interesting. I recommend everyone who reads
| this to try and dissect what makes a wrong argument sound
| convincing.
|
| A ton of terrible arguments are made here: X is important so Y is
| not important. ABC is a sacred rule that must be followed without
| question and doing XYZ does not follow the sacred rule. Wrong
| thing is done to help dumb people so smart people shouldn't do
| wrong thing.
| jonnycomputer wrote:
| Based on the comments thus far, I'd say that it wasn't very
| convincing.
| lanecwagner wrote:
| maybe not anymore, now that we all use and love highlighting.
| but maybe back then?
| sfg wrote:
| Syntax highlighting helps reveal structure, so you can understand
| the whole at a glance, before then zooming in on a part to gain
| deep understanding. Without the revelation of structure,
| identifying the parts to go deep on would only be harder.
| pjmlp wrote:
| When I started into computers syntax highlight wasn't even a
| thing, hence why certain languages use uppercase keywords as way
| to marking them.
|
| For me syntax highlighting hate is nothing more than luddism.
| karatinversion wrote:
| I have also worked on a pre-syntax highlighting code base with
| strange conventions to make up for it.
|
| I think my favourite was surrounding each mutex lock/unlock
| operation with lines of %-characters.
| %%%%%%%%%%%%%%%%%%%%%%%%%% mutex_lock(&mutex);
| %%%%%%%%%%%%%%%%%%%%%%%%%%
|
| Lovely.
| setr wrote:
| Unless you have highlighting rules for specific function
| calls (and share them with your team), I don't see how it
| this problem has been solved.
|
| Your mutex_lock(&mutex) will be colored exactly the same as
| any arbitrary foo(&bar), so you'd still want to call it out
| somehow.
| klyrs wrote:
| I've been programming since before syntax highlighting was
| common, and I continue to program without it frequently enough
| that I'm happy to not rely on it. I'd rather spend my time
| programming than figure out how to get colors working in the
| terminal session in. What I like is to be able to get work done
| in any situation. Reliance on any given tool is an impediment
| to that.
|
| Not to say that I hate syntax highlighting. Likewise: I carry a
| lighter camping, but I also know how to make and use a bow
| drill. I think there's a big difference between learning to
| live without a technology, and hating that technology. And
| that's the generous read of this article.
|
| To rebut the author, I've seen an indisputably good use of
| syntax highlighting: rainbow-colored parentheses in emacs. In
| most languages, I've got a sixth sense for unmatched parens,
| braces and brackets -- but that isn't strong enough for lisp.
| jonnycomputer wrote:
| whatever you can do to match parens and brackets, the better,
| I say. Especially in Lisp.
|
| stupid whoever downvoted you.
| alisonkisk wrote:
| Luddism is concern about the dangers of technology. Ignore them
| at your peril.
| mseepgood wrote:
| How do I disable syntax highlighting in JetBrains IDEs? I can
| choose all kinds of color schemes, but there is no predefined
| "Plain" color scheme. I would have to create a new scheme and go
| through each syntax element and reset the color manually.
___________________________________________________________________
(page generated 2021-09-11 23:02 UTC)