5 ms·
I don't think the hypothesis is that language designers have no experience programming, I think it's quite the opposite, that they have experience with poorly d
by lotyrin 11y ago
I don't think the hypothesis is that language designers have no experience programming, I think it's quite the opposite, that they have experience with poorly designed languages and tools, and perpetuate a sort of stockholm syndrome for the current state of what it means to be a developer.
We need languages designed to be used by future generations of programmers in a world where usability and tools come first. The "Manipulate symbols in this arcane syntax and hit F5/Run until it does what you want" experience is fundamentally at fault. Sure we have debuggers and IDEs, but they're more or less tacked on top of core flaws, things that allow for whitespace formatting debates or semicolon religion. My IDE and my VCS should just edit and encode the AST of my language. The compiler and IDE should share the exact same code for indexing and finding symbols in that AST -- the language acting as a library to the IDE so new releases with new features are automatically understood instead of lots of duplicated language for highlighting/completing/searching every language for every IDE. These are just a couple examples of the ways we're currently living in a state of sin.
- DasIch 11y agoIndeed. It's beyond my understanding how one could even consider not providing a public API to the parser, when one develops an interpreter or a compiler. Given all the complexity of such programs, this is trivial. The standard library of a language should provide access to the parser, so that developers can easily create tools for the language they're using.
- NhanH 11y agoYou just sang the song of Lisp programmers all over the worlds.
- DasIch 11y agoIn Lisp basically everyone starts to develop their own languages. Given that most people can barely get a reasonable API together that's just a bad idea.
- mafribe 11y agoMost modern compilers do provide hooks into the compiler. But this does limit flexibility to evolve the compiler. You can turn the argument around. As writing a parser is near trivial with parser generator tools, parser APIs are not what is problematic with writing tools.
- chubot 11y agoTwo things: 1) It's not "trivial" -- it's actually a substantial amount of work, especially as the language evolves. How many parsers have you written? Do they have public APIs? Which public APIs to parsers have you used before? 2) It can actually constrain the evolution of the language. IIRC Python has had some non-trivial upgrades that "reinterpret" text with a different parse. If you have to provide parse tree compatibility in addition to text compatibility, that makes changing things harder. I've noticed that people who have taken a compiler class (often not in C) but haven't worked on "real world" parsers (nearly all written in C/C++) have a very idealized notion of how they behave. Parsers written in C are more often than not tightly coupled to both the lexer and compiler.
- sklogic 11y agoSome (most notably, gcc) are deliberately not providing any external access to the compiler entrails, out of some deranged ideological motives.
- chrisseaton 11y ago> My IDE and my VCS should just edit and encode the AST of my language. People have been saying this for generations. Nobody seems to really believes it enough to step up and try to make it work.
- mafribe 11y agoManipulate symbols in this arcane syntax People have been experimenting with alternatives to formal languages for decades. Some of the results might have been helpful for beginners, but as tool for expert programmers, formal syntax might not yet have been beaten.
- lotyrin 11y agoI don't advocate against formal languages, just against using tools that fail to truly comprehend them -- e.g. supporting high-level refactors. I guess I should have said "manipulate by hand" to be more clear.