3 ms·

Non-human-readable primary representation may be not the best idea though. Would create a lot of friction when trying to process the data. Text is largely simpl

by smsm42 2y ago

Non-human-readable primary representation may be not the best idea though. Would create a lot of friction when trying to process the data. Text is largely simple and obvious (yes I know there are complications but in 99% of cases you can ignore them without too much trouble) but DBs and ASTs are not. People read texts, but they can't read ASTs, at least not without assistance. So it'd be hard to use.

skissane 2y ago
> Non-human-readable primary representation may be not the best idea though. What if the AST is persisted as S-expressions, but then you have a different syntax to edit it? Algol-ish, Pascal-ish, C-ish, Python-ish: choose your poison (or even support multiple poisons and let the developer pick the one they prefer?) This was actually the original plan with Lisp. Lisp was originally supposed to have two syntaxes, S-expressions and M-expressions, with M-expressions being Algol-like. However, the implementation of M-expressions was delayed, and people got so used to using S-expressions directly, they decided M-expressions were unnecessary and they were never implemented in mainstream Lisp. They were implemented in the Lisp 2 project, but that ended up being an evolutionary dead-end; various attempts at the idea have happened since but none of them really took off. Lisp purists will argue M-expressions are unnecessary and S-expressions are all you need. However, S-expressions can make the language more foreboding to complete beginners, and even among experienced programmers, a decent percentage find them seriously off-putting. Maybe if the M-expression idea had been pursued more seriously, Lisp might be more popular today.
- lispm 2y ago
  > Lisp purists will argue M-expressions are unnecessary and S-expressions are all you need. I would argue that S-Expressions turned out to be extremely practical for developing Lisp software. A layer with different syntax makes it more complex to use. > Maybe if the M-expression idea had been pursued more seriously, Lisp might be more popular today. Maybe, maybe not. People have discussed it endlessly, but there is no conclusion. Currently some people in the Racket community try to make Racket more "popular" (widely used, ...) by providing a new syntax.
  - perrygeo 2y ago
    Not just practical, S-Expressions are a big part of Lisp's superpowers from a UI perspective. You can manipulate code as forms, not text. It's hard to overstate how much of an advantage that brings to a well-configured editor. When you start thinking of your program as a nested data structure instead of a text document, you start thinking more clearly - you can manipulate this tree representation directly. This makes molding your program significantly faster, closer to the speed of thought. Wholesale refactoring a function might only take a dozen keystrokes to move the forms (not the chars) around. I have a hard time going back to the syntactic busywork of manually placing ascii characters like a caveman.
- smsm42 2y ago
  S-exp is an interesting idea. Technically they are human readable, and certainly would be processable by text tools, with some effort. Lisp maps to S-exps very well obviously but I wonder if the same amount of synergy can be achieved in the language that is not aimed at that at the start, or it will just become a binary dump with extra steps instead. Definitely would be interesting for somebody to try.
  - masklinn 2y ago
    > Lisp maps to S-exps very well obviously but I wonder if the same amount of synergy can be achieved in the language that is not aimed at that at the start But lisp did not aim for that from the start, as the GP hinted McCarthy intended S-expressions as a data description form, m-expressions were supposed to be the executable language.
  - deleted 2y ago
    [deleted]
maccard 2y ago
It’s all still bytes under the hood, albeit standard bytes. Personally I’ve not found the ability to open my css files in Word beneficial! Many editors are already altering what is stored on disc before presenting it to you - type annotations, code folding, git info. I think we could do a lot if our default storage was the semantic representation of the code.
- smsm42 2y ago
  > Personally I’ve not found the ability to open my css files in Word beneficial! Imagine writing a blog about your favorite CSS features. I mean, if you use Word at all for writing, wouldn't that come handy? But Word actually is not the primary goal here. grep or awk may be more important - I've created ad-hoc tools for ad-hoc quick-and-dirty tasks on code a number of times, and the fact that code is just text helped a lot. Taking that away would make me spend time on figuring out how to hook up text tools to that format. > Many editors are already altering what is stored on disc before presenting it to you True, but the difference is between being able to enrich commonly understood format, and not having a common format between different tools at all.
  - maccard 2y ago
    Yeah, I was definitely kidding when I was referring to Word. I do feel sad that we're still restricted to tools like grep and awk that treat everything as dumb text, and I think it holds us back hugely. I much prefer the powershell model of everything is an object. You can easily extend it with C#. I appreciate that the unix philosophy has gotten us to incredible places, but I do wish we could rip off some of the training wheels and take advantage of the computing power that we have available to us that was just unthinkable. My mobile phone is more powerful than could possibly have been imagined when we make restricted itself to tab as a delimiter, and I'm currently using it as a coaster to save my table from water marks.
    - smsm42 2y ago
      The problem of powershell model it's a closed system. If it does X, it's awesome. If it doesn't X, but there's a tool that does X and doesn't speak the same language powershell speaks - you are out of luck. That's where simple exchange formats win - they can combine tools from different domains. If I have a system that can do X using SuperDuperObjectProtocol and then another one doing Y which uses EvenBetterDifferentObjectProtocol - doing X+Y is a project that could take months if not years. If they both input and output some common easy format - like text or JSON or CSV - I can likely hooks them up in a lazy afternoon. It's not the question of processing power - all the super-comupters in the world would not make the task of hooking up SuperDuperObjectProtocol with EvenBetterDifferentObjectProtocol easier. It's the question of complexity, which always appears on the edges of domains.

by smsm42 2y ago

skissane 2y ago

> Non-human-readable primary representation may be not the best idea though. What if the AST is persisted as S-expressions, but then you have a different syntax to edit it? Algol-ish, Pascal-ish, C-ish, Python-ish: choose your poison (or even support multiple poisons and let the developer pick the one they prefer?) This was actually the original plan with Lisp. Lisp was originally supposed to have two syntaxes, S-expressions and M-expressions, with M-expressions being Algol-like. However, the implementation of M-expressions was delayed, and people got so used to using S-expressions directly, they decided M-expressions were unnecessary and they were never implemented in mainstream Lisp. They were implemented in the Lisp 2 project, but that ended up being an evolutionary dead-end; various attempts at the idea have happened since but none of them really took off. Lisp purists will argue M-expressions are unnecessary and S-expressions are all you need. However, S-expressions can make the language more foreboding to complete beginners, and even among experienced programmers, a decent percentage find them seriously off-putting. Maybe if the M-expression idea had been pursued more seriously, Lisp might be more popular today.

lispm 2y ago
> Lisp purists will argue M-expressions are unnecessary and S-expressions are all you need. I would argue that S-Expressions turned out to be extremely practical for developing Lisp software. A layer with different syntax makes it more complex to use. > Maybe if the M-expression idea had been pursued more seriously, Lisp might be more popular today. Maybe, maybe not. People have discussed it endlessly, but there is no conclusion. Currently some people in the Racket community try to make Racket more "popular" (widely used, ...) by providing a new syntax.
- perrygeo 2y ago
  Not just practical, S-Expressions are a big part of Lisp's superpowers from a UI perspective. You can manipulate code as forms, not text. It's hard to overstate how much of an advantage that brings to a well-configured editor. When you start thinking of your program as a nested data structure instead of a text document, you start thinking more clearly - you can manipulate this tree representation directly. This makes molding your program significantly faster, closer to the speed of thought. Wholesale refactoring a function might only take a dozen keystrokes to move the forms (not the chars) around. I have a hard time going back to the syntactic busywork of manually placing ascii characters like a caveman.
smsm42 2y ago
S-exp is an interesting idea. Technically they are human readable, and certainly would be processable by text tools, with some effort. Lisp maps to S-exps very well obviously but I wonder if the same amount of synergy can be achieved in the language that is not aimed at that at the start, or it will just become a binary dump with extra steps instead. Definitely would be interesting for somebody to try.
- masklinn 2y ago
  > Lisp maps to S-exps very well obviously but I wonder if the same amount of synergy can be achieved in the language that is not aimed at that at the start But lisp did not aim for that from the start, as the GP hinted McCarthy intended S-expressions as a data description form, m-expressions were supposed to be the executable language.
- deleted 2y ago
  [deleted]

maccard 2y ago

It’s all still bytes under the hood, albeit standard bytes. Personally I’ve not found the ability to open my css files in Word beneficial! Many editors are already altering what is stored on disc before presenting it to you - type annotations, code folding, git info. I think we could do a lot if our default storage was the semantic representation of the code.

smsm42 2y ago
> Personally I’ve not found the ability to open my css files in Word beneficial! Imagine writing a blog about your favorite CSS features. I mean, if you use Word at all for writing, wouldn't that come handy? But Word actually is not the primary goal here. grep or awk may be more important - I've created ad-hoc tools for ad-hoc quick-and-dirty tasks on code a number of times, and the fact that code is just text helped a lot. Taking that away would make me spend time on figuring out how to hook up text tools to that format. > Many editors are already altering what is stored on disc before presenting it to you True, but the difference is between being able to enrich commonly understood format, and not having a common format between different tools at all.
- maccard 2y ago
  Yeah, I was definitely kidding when I was referring to Word. I do feel sad that we're still restricted to tools like grep and awk that treat everything as dumb text, and I think it holds us back hugely. I much prefer the powershell model of everything is an object. You can easily extend it with C#. I appreciate that the unix philosophy has gotten us to incredible places, but I do wish we could rip off some of the training wheels and take advantage of the computing power that we have available to us that was just unthinkable. My mobile phone is more powerful than could possibly have been imagined when we make restricted itself to tab as a delimiter, and I'm currently using it as a coaster to save my table from water marks.
  - smsm42 2y ago
    The problem of powershell model it's a closed system. If it does X, it's awesome. If it doesn't X, but there's a tool that does X and doesn't speak the same language powershell speaks - you are out of luck. That's where simple exchange formats win - they can combine tools from different domains. If I have a system that can do X using SuperDuperObjectProtocol and then another one doing Y which uses EvenBetterDifferentObjectProtocol - doing X+Y is a project that could take months if not years. If they both input and output some common easy format - like text or JSON or CSV - I can likely hooks them up in a lazy afternoon. It's not the question of processing power - all the super-comupters in the world would not make the task of hooking up SuperDuperObjectProtocol with EvenBetterDifferentObjectProtocol easier. It's the question of complexity, which always appears on the edges of domains.