4 ms·
Pfff... The Lisp syntax is one of the simplest, comprehensible, readable, no-BS sugar things. People with shallow experience often say it looks weird, but with
by iLemming 2y ago
Pfff... The Lisp syntax is one of the simplest, comprehensible, readable, no-BS sugar things. People with shallow experience often say it looks weird, but with some hands-on experience, you soon appreciate its elegance and power. The consistent, minimalist syntax becomes second nature and reveals its true beauty and functionality.
You can easily read Lisp code off your phone screen - it wraps around, but retains the structure. Try that trick with pretty much any non-lispy language - even "the most elegant Python" fails there, face flat.
EDN & Transit is far better than JSON - EDN is more flexible and expressive than JSON, making it a superior choice for data serialization. It's also more than two times smaller and cleaner, commas are completely optional.
Hiccup is better than JSX & HTML - far more easier, cleaner, shorter and nicer to work with.
similarly,
s-expressions are better that XML & Yaml;
CL's PLISTs and ALISTs & Clojure maps are better than Dicts/Hashes in other languages.
Basically, you can leverage the expressiveness and simplicity of Lisp-like syntax to offer structured, readable, and powerful data representations. Add to that the ability to evaluate any given form on the fly through a connected REPL, basically "trying things while you read them," and that changes everything you thought you knew about the readability of code.
Those who call Lisp "non-readable" I suppose, in fact, never tried to actually read it. Of course, if you never learn a language, it would remain incomprehensible.
- vsuperpower2020 2y ago"Pfff..."? You're getting a little too defensive over someone not liking your language. You're just asserting that the language is easy to read and saying that anyone who disagrees just hasn't read it. This is some sad fanboy behavior that I don't like to see.
- iLemming 2y agoI've got your attention though, haven't I? :) Defensive? No. I don't think Lisp needs defending. Lisp is an idea. Good ideas need no defending. The invention of Lisp is one of the greatest events in the recent history of symbolic communication. It can be put in the same category as cave drawings, cuneiform, Egyptian hieroglyphs, and mathematical notation in the sense that they all represent systems of symbolic communication. My "Pfff..." really comes from not understanding why people would say things like "Lisp is hard to read" when, in truth, it's probably the best tool we humans have for its designated purpose. Lisp emphasizes simplicity and uniformity, which can enhance readability and ease of understanding programs. With a big caveat, though, Lisp's readability improves with practice and familiarity. Many people find Lisp structures to be clear and expressive for symbolic manipulation and functional programming tasks. Okay, I mean I get it. Let's say I can, for example, look inside "Principia Mathematica" and completely find it unreadable. Yeah, I would. But wouldn't it be weird of me to go to a forum for mathematics and tell them that their math is unreadable? They'd probably decide that I'm trolling.
- vsuperpower2020 2y agoYou got my attention that one time, sure. That's all you get.
- iLemming 2y agoAwwww. I thought we were becoming friends. I used a smiley face and shit... :[
- deleted 2y ago[deleted]
- fire_lake 2y agoIs there a spec for S-expressions as a data transfer format? I’d love to try it as an alternative to JSON.
- spauldo 2y agoThere's SXML, which is equivalent to XML but in S-expression form. Seems to have only caught on in the Scheme community, though. There are a couple standard ways to do dictionaries (a-lists and p-lists). Object systems like CLOS and GOOPS have standard text representations, but they're tied to their respective Lisps.
- lupire 2y agoYes, it's called XML.:-)
- iLemming 2y agoThere isn't a single, universally accepted specification for s-expressions specifically as a data transfer format. But like I said: there's EDN - primarily used for configuration files, data serialization/deserialization between systems, inter-process communication And there's Transit - Ideal for scenarios requiring fast data transport over networks, such as web services and APIs, it supports both JSON and MessagePack encodings.