3 ms·
The obvious middle ground is syntax that is clear to the compiler, easy for a user to write but harder for a reader to parse at a glance, aided by syntax colori
by Syzygies 6y ago
The obvious middle ground is syntax that is clear to the compiler, easy for a user to write but harder for a reader to parse at a glance, aided by syntax coloring to make all obvious.
Many programming languages use indentation-based parsing, yet no language adopts the convention that left-justified is a comment, indented is code. I've used preprocessors for years that provide this for me, in languages such as Haskell. I only gave up to more quickly use other people's tools as I switched editors.
Despite using dozens of languages since, the bulk of my lifetime has been C. There's an increasingly lame argument justifying its awful use of punctuation to avoid whitespace significance: Code can be sent through pipes that poorly respect whitespace. My memories of C punctuation are ground glass in my eyes, yet many new languages try to look like C to better attract programmers suspicious of the unfamiliar.
Comment characters in any language are ground glass in my eyes. Syntax coloring can mute these characters, but they're still there. They don't need to be there; syntax coloring can instead emphasize what's a comment, what's not, after inferring from more subtle programmer cues.
I also removed parentheses from Lisp. I tried everything to wean myself from this, believing the experienced Lisp programmer's creed that "you'll get used to how the water tastes in this city!" Fonts where the parentheses are lighter, syntax highlighting where the parentheses largely disappear. Then I'd look back at my parenthesis-light Lisp code, and I'd realize I love reading it more than code in any other language I've ever seen. The truth is that parentheses are just the dumbest, most dated way to indicate trees to the compiler. Editor tools do just fine with far more subtle cues. Lisps have been on the wane for decades, and this is a profound intellectual loss. Lisp programmers insisting on talking an Algherese dialect of Catalan is one factor.
We need to recognize that our norms for programming language syntax predate the prevalence of modern editors, language servers, syntax highlighting. I'm 64, and it's profoundly embarrassing that we're not further along than I dreamed we'd be as a grad student in 1980. We all thought the future would come a lot faster. Tree editors that only create grammatically correct code, aided with machine learning prediction? We're creeping up on this, it should have been the norm decades ago.
Joke or not, designing languages with syntax coloring in mind is a great idea.
- hhas01 6y agoI expect you’re familiar with Knuth’s literate programming and notebook-style programming interfaces of Jupyter and Mathematica. https://en.wikipedia.org/wiki/Literate_programming https://en.wikipedia.org/wiki/Literate_programming https://jupyter.org/ https://jupyter.org/ Re. Lispy langs, agree about improving readability of the actual words by visually deemphasising punctuation. So many key presses to say so little; only traditional C syntax beats it out. (Alas, nothing can ameliorate C’s swathes of needless line noise, except to stop making languages with C-style syntax. Baby steps.) I don’t quite agree about structure editors—if there’s one thing 10,000 years of the written word should tell us it’s that the writing part needs to be flexible. Better to beg forgiveness than ask permission. It makes more sense for a code authoring tool to accept (and execute, within limits) the initial imperfectly constructed text, and from there negotiate edits and corrections with the author—a literal editor, if you like. Another thing I’d like to see syntax highlighting do: provide multiple semantic views onto code beyond just crude grammatical categorization of words. Why can’t I have a view that colors words according to the library they came from, or any other high-level categorization? e.g. Show me all the words that have side-effects or perform “dangerous” operations. Or distinguish all the words relating to string manipulation, or accounting, or UI. Embarrassing? Honestly, it’s painful the lack of innovation going on. While I’m gradually exploring some of this stuff in my own work, I really wish others would step up to the plate. I’m lazy and very slow, and would far rather smarter people do all the work so I can just enjoy the results.
- hjek 6y ago> Why can’t I have a view that colors words according to the library they came from, or any other high-level categorization? e.g. Show me all the words that have side-effects or perform “dangerous” operations. This. Highlighting side-effects would be especially helpful in language where this isn't clear, like JavaScript. »`sort()` is red so it must be destructive.«
- uryga 6y ago> Tree editors that only create grammatically correct code [...] should have been the norm decades ago. idk... i like the idea in principle. but consider a task like turning a big list-of-pairs literal into a dict literal¹ – the code spends quite a while² being completely syntactically invalid. if the edits can only be AST -> AST transformations, the editor would need a super-powerful way of describing them, or a mind-reading autosuggest... because you're pretty much interactively writing a lisp macro --- ¹ or anything where most of the line stays the same, but you need to reparenthesize things a bit ² even if you're using something like multiple cursors to batch-edit
- hhas01 6y agoMore importantly, being syntactically invalid isn’t wrong, just incomplete; a work in progress. Any editor that fights the user over that won’t be used for long before it’s kicked to the kerb in disgust.