Live data from Hacker News

Why I Switched from Python to Clojure (2016)

bradcypert.com

151–160 of 200 posts

Re: Why I Switched from Python to Clojure (2016)

#151
post #32
post #28

Earlier quoted context omitted.

Not only is it not inherently hard to learn, it's arguably one of the easiest syntaxes to learn. ( fn-name param1 param2 ... ) is the syntax. Once the brain grasps this, a whole layer of complexity just vanishes. Furthermore, not having to use punctuation between items is just heavenly. There's so much less noise compared to Python, and Python isn't even a particularly noisy language.

Only if you don't consider a forest of parens to be noise. I do. I'm sure I could get used to it after a while, but at first glance, Python code is definitely cleaner than Lisp.

Maybe. As someone with a Lisp background moving to Python (day job), all the semantics hidden behind whitespace makes me just a bit nervous. The parens, for me, make structural editing easier and also give a means of keeping the syntax around even when the whitespace gets damaged by whatever editing operations are happening.

(But whitespace sensitivity has always struck me more as a way to enforce specific whitespace conventions than anything else, and even as far back as Pascal I've been religious about maintaining indention in code. It's easy to do with a decent editor (or not) and helps the readability immeasurably.)

Re: Why I Switched from Python to Clojure (2016)

#152
post #90

Earlier quoted context omitted.

That’s not true. When you’re passing functions to functions inside functions that return functions... it’s a nested mess. I studied Lisp and Scheme at university and that’s where it had to remain for me: academically entertaining mind puzzles in data structures and algorithms. It’s just not productive or easily graspable from one coder to another.

Tasteful macros can alleviate this, and Clojure's std lib has a few which are just delightful. The following does exactly what you'd expect, and there are even cooler ones like `some->` or `as->`. (->> some-nums (map square-root) (filter even?) set count) This is what lisp buys you, dead simple rules for syntax, with the option to add syntax with macros. If you made a mistake in syntax design, deprecate the lib and m…

And then you use a threading macro to assemble a middleware stack, only to find out that the middleware is applied in reverse order of what's listed as an inbound request comes in... (The outermost middleware being listed last in a threading form).

There's a reason for it, for sure, but it's surely a part of the learning curve.

Re: Why I Switched from Python to Clojure (2016)

#155
post #94

It's interesting that the very things that attracted the author to Clojure was what kept me from moving to it from Python. I enjoyed the syntax. Loved the immutability. However, I wasn't able to understand the structure of program data at a glance even when reading my own code. The reliance on lists and maps everywhere meant that the structure of data was encoded in the code of the functions that created it and somet…

The fundamental problem with S-expressions is that they are intended for (1950s) machine readability and human ergonomics takes a back seat.

Ah, the good old S-expression flamewar again! Every few years it comes up.

This is, of course, mostly a matter of opinion and experience, but I find S-expressions highly readable and LISP syntax superior in readability to every other syntax I've seen, as long as different parentheses are allowed like in all modern LISP dialects.

There are two other problems with LISP. First, it's so powerful that the semantics gets too rich, every author creates a DSL of its own with tons of macros and functions for every data structure. That makes code unreadable and difficult to maintain in the long run. At some point, every LISP program starts to look like a hack and you start spending most of your time transforming one data structure to another to interface with various packages.

The second problem is the focus on dynamic typing. I've found strictly static compilation better for debugging. Racket is particularly bad in that respect, as it tends to use ad hoc symbols with contracts everywhere. Static enumeration types are just way better for that purpose. Ideally, they should even be tied to the functions they are used in (e.g. a "function parameter type" with appropriate scoping).

These are the main drawbacks of LISP, maintainability and readability of code written by others is too low, because of a tendency to encourage hacks and DSLs.

Re: Why I Switched from Python to Clojure (2016)

#156
post #129

Earlier quoted context omitted.

sure, because Sure, because this (taken from React's JSX example page): Scores ; is more readable than this: [dashboard-unit {:data-index 2} [:h1 "Scores"] [scoreboard {:class-name "results" :scores game-scores]] Please tell me more about Lisp readability.

For someone familiar with HTML/XML, so any developer in the last 30 years, yes it is. Your point being? I like the ideas behind clojure, I really do. I even wrote a non-trivial personal project with it. However, coming back to that code after two months was basically like the plot of Memento. I ended up rewriting it in JavaScript instead.

Almost anything (if not all) requires one to put in years of practice before one is adept. "a" non-trivial "personal" project probably won't cut it.

Comparing that to your 30 years practice of XML is not at all useful.

Re: Why I Switched from Python to Clojure (2016)

#157

Earlier quoted context omitted.

The fundamental problem with S-expressions is that they are intended for (1950s) machine readability and human ergonomics takes a back seat.

sure, because Sure, because this (taken from React's JSX example page): Scores ; is more readable than this: [dashboard-unit {:data-index 2} [:h1 "Scores"] [scoreboard {:class-name "results" :scores game-scores]] Please tell me more about Lisp readability.

Basically damnation with faint praise?

Re: Why I Switched from Python to Clojure (2016)

#158
post #129

Earlier quoted context omitted.

sure, because Sure, because this (taken from React's JSX example page): Scores ; is more readable than this: [dashboard-unit {:data-index 2} [:h1 "Scores"] [scoreboard {:class-name "results" :scores game-scores]] Please tell me more about Lisp readability.

For someone familiar with HTML/XML, so any developer in the last 30 years, yes it is. Your point being? I like the ideas behind clojure, I really do. I even wrote a non-trivial personal project with it. However, coming back to that code after two months was basically like the plot of Memento. I ended up rewriting it in JavaScript instead.

Why rewriting it in js help with maintenance?

This is not a snarky question, I'm genuinely curious since I personally have no problem coming back to old clojure code.

Re: Why I Switched from Python to Clojure (2016)

#159

Earlier quoted context omitted.

The fundamental problem with S-expressions is that they are intended for (1950s) machine readability and human ergonomics takes a back seat.

Just about every innovative idea from Lisp, and there were quite a few of them, has been incorporated into modern programming languages. Except for sexpr syntax. Draw your own conclusions.

sexpr syntax has incorporated into 'modern' programming languages like Clojure, LFE, Hy, ...

Re: Why I Switched from Python to Clojure (2016)

#160

Earlier quoted context omitted.

The fundamental problem with S-expressions is that they are intended for (1950s) machine readability and human ergonomics takes a back seat.

Ah, the good old S-expression flamewar again! Every few years it comes up. This is, of course, mostly a matter of opinion and experience, but I find S-expressions highly readable and LISP syntax superior in readability to every other syntax I've seen, as long as different parentheses are allowed like in all modern LISP dialects. There are two other problems with LISP. First, it's so powerful that the semantics gets t…

One could say the same for almost all language. One can abuse java reflection and do all kinds of unreadable magic and code generation.

If I can get one thing, I'd probably say practice in immutability. This simplifies a lot of things, even in java. In Clojure, immutability is first-class.

Post reply on HN