Emmanuele Bassi
JordanEvery now and then people share languages with very minimal or very uniform syntax (think Lisp, or Haskell, or Forth) and go "look, all the noise is gone". And to each their own, and familiarity goes a long way, but I think I've pinned down my feelings about it, which is "that wasn't noise, that was signal; I was using as scaffolding when reading the code and now I have to wade through every token linearly".
"Jordan, you don't read code linearly?" You don't understand, I don't even read prose linearly. I'd have to sit down and try some real self-observation to figure out how my prose reading works, but it is very much not word-by-word. Which I know because various situations (like "bionic reading" formatting) can force me to go word-by-word, and it is a different (and generally slower) experience.
Fedor Indutny@jrose I actually read across lines when reading prose (and I suspect software too). I haven't understood that I was doing it for a long time, but eventually realized it was happening.
Gina Peter Banyard@jrose I'm fairly certain the majority of people don't actually read linearly word-by-word.
Why do I think this?
When I took drama lessons the amount of times our teacher told us "no that's not what's written" and multiple of us needed to go back and actually parse the words in a sentence to realise that we either added, omitted or straight up swapped a word compared to what's written is staggering.
Our brains try to optimise everything, including reading.
Lona Theartlav@jrose Mood. One reason why i prefer pascal like syntax is that the extra verbosity of it makes the code look more visually structured to me.
🇺🇦 haxadecimal 🚫👑@theartlav @jrose
Agreed.
Even C-like languages, used with braces at matched indentation, can do that, but K&R style can't, at least for me.
Agreed.
Even C-like languages, used with braces at matched indentation, can do that, but K&R style can't, at least for me.
Jan Schiefer@jrose I am surprised that anybody can read non-trivial code linearly! Especially in OO-languages, where I would be helpless without cross-referencing. "Remind me again what a FnorbFactoryFactory does?". Or, "who is calling this crap, and why?".
I have all related keystrokes firmly committed to motor memory.
@janschiefer Oh, I'm not even talking about that part! Certainly it is helpful to move around to find out what a block of code is referencing, but I'm saying even mentally parsing the block of code is easier when there's more syntactic structure (to a point, of course), and figuring out what it's doing comes after that.
pcbeard
Joe Groff (1M Context)
d@nny disc@ mc²@joe @pcbeard @jrose i assumed sigils were type specifiers for the symbol and not coercion operators for quite a while. one difficulty i have is with good ideas that don't support user extension without forking the language (scala's unapply operation for extensible case matching was an epiphany to me).
if you go far enough with this you may eventually arrive at a stable HIR which makes the choice of concrete syntax an explicit decision. curiously scala 3 has this and in private tooling devs say it is terrible to write against compared to odersky's former protege eugene burmako's semanticdb. it does indeed allow the scala compiler itself to support multiple forms of concrete syntax but if the compiler is to take upon the role of tooling, it would be wise to separate this phase.
in the same way, the compiler should not integrate linear path traversal for library search into the rest of compilation (and certainly not for interpreters), but instead make this its own distinct phase generating an explicit mapping, which tooling can override. this is a general mechanism that can be observed for any command-line tool, where cli parsing tends to produce a serializable configuration that could alternately be deserialized as an explicit preprocessing phase.
i used to think a macro API was the key to multiple concrete syntaxes, but a macro API is itself a syntax, and i don't actually like most macro APIs (elisp has a destructuring one developed by a haskeller maintainer i do quite like). generating source code is also a sort of macro API, which is what coffeescript does. so if the language wants to do better than generating source code, it may as well entirely decouple source code from input.
arguably, this would seem to disparage syntax, and the value of language designers in crafting syntax like wall does. i believe that the design and craft of syntax is harmed when it runs into petty squabbles, or (more commonly) when it stops users from immediately upgrading to new versions. i also don't think a change in semantics should be signalled through a parsing error.
серафими многоꙮчитїи@hipsterelectron @joe @pcbeard @jrose Algol 68 had an idea they called 'stropping', which was a way to have a certain section of the syntax be separately defined - the canonical 'publishing' version of the language used visual indicators (like bold vs non-bold) to eg determine keywords. The stropping was a way to convert from flat text to styled text, there were various standards, and they could be more or less customised.
@hipsterelectron @joe @pcbeard @jrose Basically, I find that there are various interesting and underexplored/underexamined points in designs in the history of plt and the history of programming as a craft more generally where you can decouple things within 'the language/runtime/compiler/development process/etc' if you are careful.
✧✦Catherine✦✧@jrose yeah same
Peter Hosey@jrose I've been thinking about this, or something related, in the context of SQL—a language that largely favors keywords over punctuation—which I habitually write in the classic SELECT foo FROM bar WHERE baz style, and which some of my colleagues write in all lowercase.
The difference, I think, is syntax highlighting, which they all learned with and take for granted. The uppercase keywords originally made up for the lack of that.
Chris Adams@boredzo @jrose “why are the old people always shouting at the database?”
I think you especially have a point for the multi-decade gap between syntax highlighting being available and it being something you could count on having on a remote terminal session, query tool not oriented at developers, etc.
Irenes (many)@acdha @boredzo @jrose haha yeah we actually went and mandated capitalized keywords for SQL in the style guide at work, and the young people have been willing to go along with it, for which we thank them (we must have established trust somehow....)
but we gave a lot of thought to whether it was the right thing to do
Willow at large@ireneista @acdha @boredzo @jrose this is part of why I put all my SQL strings in a Jinja module and access them like
await conn.execute(self.queries.user_sessions(), user_id)
or whatever
await conn.execute(self.queries.user_sessions(), user_id)
or whatever
Robert Kist 🇦🇹🇸🇬@jrose ohhhhhhh
right, okay. that makes sense
King Naga Calyo Lucere-Delphi@jrose Wow you... you pretty much just put a feeling into words that I could not.
gunstick@jrose I was thinking about this and now wonder if an AI can generate useable lisp. As it basically involves counting braces.
I encounter issues generating the most simple bash code because an LLM seems not to care on quoting or escaping quotes correctly. In bash it's probably worse because there is no difference between opening and closing quotes
I encounter issues generating the most simple bash code because an LLM seems not to care on quoting or escaping quotes correctly. In bash it's probably worse because there is no difference between opening and closing quotes