Live data from Hacker News

Why I Switched from Python to Clojure (2016)

bradcypert.com

61–70 of 200 posts

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

#61
post #8

I notice this was written in 2016, but I wonder if the author's opinion has changed since dataclasses have been implemented in Python.

Python's async support also seems to be getting better. There's a flask clone called Quart ( http://pgjones.gitlab.io/quart/ ) and an async postgres client ( https://github.com/MagicStack/asyncpg ). It works very similar to JavaScript, with async and await keywords. I think it should provide speed and comfort especially if you're a regular JavaScript user.

Python is even better since it has http://trio.rtfd.org which provides structured concurrency.

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

#62
post #43

I can, and do, appreciate opinions on languages themselves. But my decision to continue using Python over Clojure is much less about the language's syntax and more about the available libraries. How do Clojure web frameworks compare to Django/Flask? What would I use instead of Pandas for data analysis? Are there keras-like deep learning tools? Switching languages based on a comparison of idiosyncrasies between the tw…

Clojure works on the JVM so you have native access to all of the Java ecosystem. With that in mind I'd say the libraries are actually better for Clojure with the exception of data analysis. I don't think there's a language out there that has as many data libraries as Python (like Pandas).

Aren't there a lot of data libraries for scala?

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

#63
post #48

Earlier quoted context omitted.

What are those regrets? ;)

Oh, so many things. The parallelism isn't actually that powerful, and in 2019 there's very little to set it apart. The building blocks are great, e.g. immutability everywhere, but few of the built-in primitives are actually usable (hidden unconfigurable thread pools etc). Stack traces still regularly horrible. Libraries are regularly abandoned. ClojureScript integrating with npm etc is more stress than you'd like. Co…

I had lots of pain dealing with CLJS but, since switching to http://shadow-cljs.org as my compiler, I've generally found that things "just work": instead of complicated messing with externs, you just npm install the package and then add `["vega" :as vega]` to your namespace's list of requires.

As far as the stack traces go, I have a hard time understanding why tooling like Cider's stacktrace filtering isn't wider spread: in Cider, when a stack trace pops up, it's one or two clicks to hide most of the things I don't care about and, yet, that information is still available for people working on the compiler or with Java interop.

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

#64
post #62

Earlier quoted context omitted.

Clojure works on the JVM so you have native access to all of the Java ecosystem. With that in mind I'd say the libraries are actually better for Clojure with the exception of data analysis. I don't think there's a language out there that has as many data libraries as Python (like Pandas).

Aren't there a lot of data libraries for scala?

Yeah, at the very least, there's Spark, which is reasonably nice to use from Clojure via the Java API:

https://github.com/finalfantasia/apache-spark-examples-in-cl...

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

#65

> ...the “implied self parameter” on python methods turned me off. If I had a nickel for every time I got the "TypeError: random_function() takes 1 positional argument but 2 were given" because I forget the "self" parameter I could buy myself a coffee. Probably a fancy one from the Starbucks even!

There are linters for these kinds of things that work with most editors. E.g. VSCode with pylint marks the method immediately, if you forget `self` or `cls`.

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

#66
post #62

Earlier quoted context omitted.

Clojure works on the JVM so you have native access to all of the Java ecosystem. With that in mind I'd say the libraries are actually better for Clojure with the exception of data analysis. I don't think there's a language out there that has as many data libraries as Python (like Pandas).

Aren't there a lot of data libraries for scala?

Yes but more data engineering than data science (someone else mentioned Spark).

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

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

Yes, Python looks cleaner, Lisp thinks cleaner.

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

#68
post #40

Earlier quoted context omitted.

"The worst injuries I've ever seen were in big factories with large, powerful tools -- not in home garages where people just use hammers and hand-saws." Powerful abstractions are... powerful. They're more difficult to use correctly, and take longer to learn. The conclusion shouldn't (always) be to avoid them entirely.

A good rule of thumb is the more powerful the language the stronger your justification needs to be for using it: https://en.m.wikipedia.org/wiki/Rule_of_least_power LISP is, of course, way more powerful than most languages so it is more susceptible to technical debt.

I've used that quote from Berners-Lee in a presentation before; it's one that I tend to agree with. However, I think you've drawn the wrong conclusion from it.

We want to choose the least powerful language for the job, but the least powerful language is frequently domain specific. Ideally you'd want to develop within a framework that makes it easy to develop restrictive, domain-specific languages.

I'd suggest that Lisp is actually a good basis for this, as S-expressions make it easier to build smaller languages. Clojure in particular seems to be heading in this direction. Cognitect has spec and datomic, and there's been some interesting ideas from Christophe Grand (IIRC) about using relational programming outside the database.

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

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

Editor tooling matters. Formatting, traversing, matching, and highlighting parenthesis made all the difference for me.

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

#70
post #31
post #27

Earlier quoted context omitted.

I work with clojure, and love it, but believe the problem is caused by java or equivalent paradigms applied to clojure. The high probability that clojure was someone's first functional language could also contribute to the problem. Your thoughts?

This is just blaming people for using Clojure's features though. If deep JVM integration wasn't a selling point, you'd use a vastly more mature Lisp, right?

The parent post did not say JVM, they said Java paradigms. Vastly different things.

Writing Javaonic Clojure vs Clojuronic Clojure. So, trying to replicate the style/structure/paradigms of Java rather than learning and using the Clojure styles, structures and paradigms.

Post reply on HN