Hacker News Reader

Comment by smsm42 | Hacker News Reader

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.

View on HN

> 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.

> 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.

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.

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.

> 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.

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.

> 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.

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.

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.

I think that falling back to the lowest common denominator is an immense cause of complexity in software, and holds us back back. I think we'd be much better off if we didn't optimise for "person who wants to write a CLI in haskell who is using an 18 year old version of bash that only runs on Plan9"

Reply on news.ycombinator.com