Live data from Hacker News

Clojure Turns 15 panel discussion video

youtube.com

191–200 of 226 posts

Re: Clojure Turns 15 panel discussion video

#191
post #99

Earlier quoted context omitted.

Can you recommend a good YouTube video that demonstrates this? I'm used to writing code incrementally in Python via the IPython REPL. I've also used Twisted's Manhole to get a REPL inside an already-running Python server process. But I believe you're referring to something substantially richer than that.

For me, it's a combination of having a REPL and having a good interactive interface between the editor and the REPL. Typing forms into and evaluating them in the REPL is one thing, but typing them into your editor file and evaluating them from there in the REPL is much more useful. (I can't fairly say one way or the other whether that's possible/common in IPython.) Here's a short one to give a taste of that: https://…

There's a lot of idiosyncratic advice in those Halloway talks, and people shouldn't blindly adopt it wholesale without evaluating if it's right for them.

Learning to evaluate forms directly from the editor is great, but _never_ typing in the REPL forces you to clutter up a file with evaluations you may not want to save, and jump around a lot between your comment blocks and code.

Re: Clojure Turns 15 panel discussion video

#192
post #147
post #144

Earlier quoted context omitted.

How do you mean? You can specify local (fs) dependencies fine, which is presumably what you want in that scenario? (I regularly contribute to a monorepo like this, though admittedly the top-level components are relatively disjoint.)

I mean, you can hack something together with local dependencies, yes, but there's no out of the box way to build and test everything together, or to do things like pin dependency versions across projects, have projects inherit shared configuration, etc. We end up creating a bunch of pseudo-projects that contain things like single dependencies, but this blurs the line between build time concerns and actual source code…

I wonder if Polylith would be up your alley?

https://polylith.gitbook.io/polylith/

Re: Clojure Turns 15 panel discussion video

#193
post #71

Earlier quoted context omitted.

Every early ecosystem suffers from lack of mature libraries. It is a chicken and egg problem. I think your contribution would be very welcome, especially with a bit of docs or minimal examples.

I don't think it's an "early ecosystem" though... I was playing with Clojure before I had ever heard of Go, Elixir, Julia, Rust, or Typescript. All of these seem like mature ecosystems now. I really like Clojure as a language, but if it's still an "early ecosystem" at this point, that seems like a problem to me.

True, although I don't know which library the op is talking about, because all the libraries I use are alive and well, some get very rare updated simply because they are "done"

Re: Clojure Turns 15 panel discussion video

#194
post #137
post #89

Earlier quoted context omitted.

It's really hard for me to see any justifications for a syntax that's not based around s-expressions. The benefits of being able to trivially transform any code as data and have powerful structural editing facilities outweigh any perceived downsides in my experience. I also find that s-exps act as a visual diagramming tool making your code more scannable because you can visually see the relationships between statemen…

> I also find that s-exps act as a visual diagramming tool making your code more scannable because you can visually see the relationships between statements by looking at the nesting. I think this is where people disagree regarding syntax. I love Clojure and agree with all the benefits of s-exps, but find it basically impossible to scan and very tedious to read. While it tends to be easy to refactor do to the REPL, a…

Could you elaborate on that. Why do you find s-exp syntax more tedious to read than other types of syntax?

Re: Clojure Turns 15 panel discussion video

#195
post #99
post #48

Earlier quoted context omitted.

I've been working with Clojure for the past decade, and it's still the most enjoyable development experience I've had. Once you experience using an interactive workflow where you can see the results from the code you're writing live, it's really hard to go back.

Can you recommend a good YouTube video that demonstrates this? I'm used to writing code incrementally in Python via the IPython REPL. I've also used Twisted's Manhole to get a REPL inside an already-running Python server process. But I believe you're referring to something substantially richer than that.

You can see an example at the end of the talk here https://youtu.be/DFzukK5-rpU?t=1497

Re: Clojure Turns 15 panel discussion video

#196

I have been using Clojure for a solo project for a while now and find it shockingly productive. I initially planned to limit how much of the language "surface area" I explored to keep focused on solving the problem but was able to productively use much more of Clojure than I expected: -core.async for concurrency that led me speed up some tasks from ~1000ms to ~40ms (well, core.async got me to about 100ms, or closer t…

I have also been using CLJS/Clojure for a solo project. I debated between CL and Clojure for the backend, but CL’s package ecosystem is too weak to be justified. What other languages did you consider for your stack and what did you think were the tradeoffs?

This is sort of a next generation successor to a personal project written years ago in Perl (evolving from a form fit tool to something much more general and flexible). I originally was going to do it in Ruby but after learning Clojure and doing a bunch of book exercises (toy coding tasks) I thought Clojure would be a better fit. (When I learned Python I considered that but it did not seem any better of a fit than Ruby and since my use case was web oriented it seemed like Rails could eventually be useful.) It remains a personal project but one I (unlike the predecessor) think is good enough to eventually open source.

I think my motivators to do in Clojure were edn (dsl files are a key part of what I'm building), the concurrency story being strong, Java interop for libraries (Ruby wasn't necessarily missing anything but without the Java libs Clojure would not be an option), and a general belief that Clojure's overall approach (data oriented, LISP, functional) would prove generally more productive (I believe this is true but have no evidence since I never tried building it in another language). Spec has been an unexpected benefit as it saved me from writing a lot of validation code and because it can be used as a parser for the DSL (it does most of the heavy lifting).

How has your experience with CLJS? I have been using vanilla CLJ but curious to some day try CLJS.

Re: Clojure Turns 15 panel discussion video

#197
Clojure changed my life. It made me realize how fun it is to code and switch back to being a programmer. This makes me a much happier person and thus a better husband and father. Never looking back. The Clojure Way just fits me perfectly.

Re: Clojure Turns 15 panel discussion video

#198
post #181
post #174

The ultimate failing of Clojure as a tool is its inefficiency measured in $ per feature. The language is not very approachable for junior programmers. You can grab a Python programmer and graft them on a Java or TS project and the same week they will deliver features and bugfixes. Reading other's people code in Clojure is much harder especially when coming from imperative world. The language is terse. The documentati…

I do agree. While I made all my projects in mostly Clojure, I absolutely cannot imagine hiring & onboarding other drvs. And if I had a tough day, my clj code will look like rubbish, while my typescript code will still look decent. It's really not a language for big team.

> It's really not a language for big team.

Not my experience, but you do need senior devs who are good at Clojure to be reviewing and helping the juniors

> if I had a tough day, my clj code will look like rubbish

This may not be a reflection of the language

Re: Clojure Turns 15 panel discussion video

#199
post #137

Earlier quoted context omitted.

> I also find that s-exps act as a visual diagramming tool making your code more scannable because you can visually see the relationships between statements by looking at the nesting. I think this is where people disagree regarding syntax. I love Clojure and agree with all the benefits of s-exps, but find it basically impossible to scan and very tedious to read. While it tends to be easy to refactor do to the REPL, a…

Could you elaborate on that. Why do you find s-exp syntax more tedious to read than other types of syntax?

When I look at Clojure code, it just looks like noise, all the forms look the same. For example, a let and a doseq at first glance might look almost identical in terms of their "shape." In something like Java, a for-loop "looks" like a for-loop, there's nothing else in the language that looks quite like it. If I see a series of chained lambdas, there's an extremely high chance I'm looking at a stream, etc. The syntax helps me here by adding more obvious visual markers.

The argument I'd make in favor of Clojure and s-epxs is that, when you write good functional code that composes lots of small functions, it can literally read just like English. If foo and bar do baz else qux. But bad Clojure code doesn't have this property to me, it just looks like a lot of noise.

Re: Clojure Turns 15 panel discussion video

#200
Excellent and very productive language. Personally, I did 15 years of straight Java (before that C and C++), then 5 years of Clojure. For me, the most telling dynamic is when I recently returned to a Java project and realized how much better Clojure is - even for large projects ;)

The lack of static typing, which is so often used as an argument against Clojure, is actually what makes Clojure better. The Java projects become a morass of types scattered into a myriad of packages; no matter how experienced you are with Java. Clojure's dynamic underpinnings and its paradigm of hundreds of functions for a few data structures allows for very lean designs that are easier to wrap your head around and keep in your mental models.

The other features are just gravy: immutability built in, REPL interactivity, Transducers, Protocols etc.

I felt the pain going back to a Java project.

Post reply on HN