Live data from Hacker News

Why I Switched from Python to Clojure (2016)

bradcypert.com

181–190 of 200 posts

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

#181
If you allow me to compare my very limited experience with Python (hacking SublimeText plugins) to my rather extended experience writing Java or Ruby (i.e class-based languages that traditionally newline-&-deindent closing parens rather than aggregating them in a trailing tiger tail like in lisps) ...

... I would say writing programs in Clojure leads me to writing 10 to 20 times less code on average.

I recently rewrote 15000 lines of Java (several weeks worth of effort split in several dozen files) down to 500 Clojure lines (in one weekend and one single file).

Anyone else with that kind of experience ? To me this is a tremendous advantage and any argument for code readability is really just argumentation about reading code at a small scale (say one file) that unknowingly makes trade off about reading code at bigger scales (say the readability of a whole project).

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

#182
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…

When comparing programming languages / tech stacks, I am also more interested in the full picture (libraries, complexity, performance) than just differences in syntactic sugar. I use https://github.com/gengstrand/clojure-news-feed as a test bed for such evaluations. There, you will find almost feature identical microservices in clojure using ring with the jetty adaptor and python 3 on flask.

The clojure service was in 13 files with a total of 710 Lines of Code. The python service was in 33 files with a total of 1561 LoC.

I also have published load test results of these microservices at http://glennengstrand.info/software/performance/eks/gke where you will find the per minute average throughput for these two microservices to be about the same but the clojure version was about twice as slow as the python version.

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

#183

Earlier quoted context omitted.

I guess we would have to believe your empirical observations and ignore the facts: - Clojure has been noted as the most payed language in dev surveys of the past few years - Again, different surveys (e.g.: stackoverflow, state of javascript) shown that Clojurists overall are more experienced devs. This kinda makes sense - usually people try Clojure out of curiosity and not for dogmatic reasons and not for the points…

Pay for a language doesn't reflect skill, or even implied skill. Its simply a function of demand and supply At $financial-news company, someone decided that they should re-write a few critical parts of the system in closure, partly due to boredom, partly due incompetence. They swanned off, along with 90% of the other people who knew how to maintain closure. This left a bunch of junior java devs to maintain a ill thou…

> Pay for a language doesn't reflect skill, or even implied skill

In this case it sorta does:

a) Clojure is known for having a bit of learning curve and being a Lisp, it rarely attracts newbie programmers

b) it is famous for its concise syntax and for being able to build and maintain things with smaller teams. ROI of 3 Clojure devs is almost always can be predicted to be much higher than of 6-7 Java/Javascript/Python/ Ruby/etc. teams. Pick a few successful Clojure(script) projects and see how big the teams are, they are usually not that big

c) Flexibility of Lisp lets you bend your code for different paradigms: functional, OOP, logic, relational, CSP, reactive, declarative. In my experience, when most other (practical) language acolytes simply ignore academia Haskellers and Clojurists tend to be genuinely interested in CS papers. I think that is due to their experience - again these languages usually attract more seasoned developers

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

#184
post #121

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

I really don't understand this point about just using Java libraries in Clojure. Why not just use Java? Wouldn't the experience of writing Clojure that fits the Java library's model be horrible?

Yes, you are suddenly writing java with parentheses.

Don't get me wrong, Clojure is a great language in itself, but the lack of libs make you spent 90% of your time writing interop, you start to ask yourself if it's worth the trouble.

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

#185
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?

No, CL looks quite long in the tooth when compared on ergonomics and ecosystem. It may run faster but otoh the Clojure concurrency story is great. There's also good IDE support for more enterprisey tastes (Cursive) in addition to the phb-scaring Emacs/vi, and ClojureScript is a huge selling point in many fields. The JVM has a lot of technical plus sides aside from the library interop - a lot of tooling such as Newrelic and Maven can be directly leveraged.

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

#186
post #38

Earlier quoted context omitted.

Every person that I've talked to that seemed to have a strong negative opinion about parens never used it. They just think they won't like it but wouldn't take the minimal amount of time to give it a try with something like paredit. I was also in this camp for a long time until I figured I would give it a serious try instead of disparaging something I had not used. You might consider that creating and editing code wi…

I've been using Scheme as one of my languages for a decade. (Haskell, Python, Ruby, Bash are the main others.) I generally use a preprocessor for each language. The Haskell preprocessor treats indented as code, flush as comments, also supported by my syntax highlighting. Comment characters feel to me like a thousand Hitchcock birds shat on my car. They're so easy to avoid. It also introduces here docs; no language sh…

You would be interested in my old project using `$` as a way for reducing parentheses: http://text.cirru.org/ .

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

#187
post #164
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…

I feel like people who come to Clojure forget the lessons that were known from the time of SICP that just because you can program using data, does not excuse not building up an abstraction tower. If you have entities in your domain, presenting clean and encapsulated ways of interacting with them is a separate concern from navigating and modifying their underlying datastructure, which is an implementation detail. IMO…

While this approach did strike me as quite elegant in theory, what I found in practice was that a lot of those interfaces ended up just being boilerplate to give me access to the underlying elements of the data which I would have gotten for free in a more strongly typed language.

In other situations, this approach would work well as long as what I was working on was fresh in my mind. However, when I had to come back to some code and extend its behaviour it would be back to digging through it to either understand the structure of the data... or understand the structure of the fancy abstraction I had built up on top of the data. It just didn't seem to be very time efficient in practice for the things I was trying to build.

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

#188
post #121

Earlier quoted context omitted.

I really don't understand this point about just using Java libraries in Clojure. Why not just use Java? Wouldn't the experience of writing Clojure that fits the Java library's model be horrible?

Yes, you are suddenly writing java with parentheses. Don't get me wrong, Clojure is a great language in itself, but the lack of libs make you spent 90% of your time writing interop, you start to ask yourself if it's worth the trouble.

I actually find Clojure's `doto` notation to be the cleanest way to interact pure Java. It's like an improved syntax for Java that's native in Clojure.

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

#189
post #106

Earlier quoted context omitted.

rails/Django -> luminous Flask -> pedestal/clojupture Relay -> fulcro Pandas -> clojure.core, specter Keras -> mxnext/neanderthal

The only one I miss in Python that is not in any other package is matplotlib. Is there any clojure alternatives?

there is a "work in progress" thing named "REBL" REBL is "Read Eval Browse Loop". It's a kind of interactive view of any data.

Basead on it's shape, you can extend and create many views.

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

#190
post #187
post #164

Earlier quoted context omitted.

I feel like people who come to Clojure forget the lessons that were known from the time of SICP that just because you can program using data, does not excuse not building up an abstraction tower. If you have entities in your domain, presenting clean and encapsulated ways of interacting with them is a separate concern from navigating and modifying their underlying datastructure, which is an implementation detail. IMO…

While this approach did strike me as quite elegant in theory, what I found in practice was that a lot of those interfaces ended up just being boilerplate to give me access to the underlying elements of the data which I would have gotten for free in a more strongly typed language. In other situations, this approach would work well as long as what I was working on was fresh in my mind. However, when I had to come back…

That's an interesting insight - isn't the whole point of the indirection to free you from needing to understand the underlying data structure when extending things?

I feel the heart of the issue is surrounding a similar problem that message-passing set out to solve, perhaps encapsulation? You set up some boundaries to a thing and define some contracts for interacting with it, and in return you are free to separate the implementation of that from the consumer of that data.

I worry that when people program in Clojure, they forget all the discipline that was embedded in some of the better parts of the previous language/paradigms they came from and mistake that as liberation.

Post reply on HN