Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Clojure: A Lisp that wants to spread

simongray.github.io

Post reply on HN
Print view View original

221–230 of 306 posts

Re: Clojure: A Lisp that wants to spread

#221

Post by dragandj »

stingraycharles wrote: post #200
dragandj wrote: post #195

Earlier quoted context omitted.

It's funny that you mentioned Python :) https://wiki.python.org/moin/ConfigurationAndBuildTools

Are you saying that just because there is a choice of configuration build tools and utilities for Python, the argument that there is a standard way of doing things is invalid? If I want to start a Python project, I `pip install -r requirements.txt` and I can start using it. In Clojure, I need to choose which tool I want to use to perform this simple task, in Python this is standardized. Leiningen, Boot, tools.deps an…

There is such de-facto standard in Clojure too. just do `lein`. + even if you choose another build tool, it is:

1) compatible 2) if you're a newcomer, you probably only need a few dependencies, which is configured in the same way as lein's `project.clj`

I mean, I agree that there definitely is a need for better guides for Clojure and defaults, but I don't think that is the reason Clojure is not more popular, and that Python is simpler there. If I encounter Python for the first time, I definitely won't know that I just "pip whatever".

I actually think that Clojure is very popular, given that there is no big Co that pushes it, and that it still doesn't have a widely known killer app. Most other popular(ish) languages are mainly popular due to huge push by a single big corporate sponsor.

Re: Clojure: A Lisp that wants to spread

#222

Post by grierson »

Random_ernest wrote: post #13

I really like Clojure, it's a well designed language and one can get quite productive, surprisingly fast. My core criticism that is not really mentioned in the article is the error messages. At the beginning I often felt lost and had no idea where to look if something went wrong.

So this is a common issue on the clojure sub-reddit the two good responses i've seen to this is the library expound (https://github.com/bhb/expound) so you get more 'human' read-able errors and my personal favourite is Stuart Hallows blog post REPL DEBUGGING: NO STACKTRACE REQUIRED (http://blog.cognitect.com/blog/2017/6/5/repl-debugging-no-st...)

Re: Clojure: A Lisp that wants to spread

#223

Post by peatmoss »

pron wrote: post #76
peatmoss wrote: post #68

Earlier quoted context omitted.

I haven’t figured out a way with the JVM / Clojure to compile and distribute a small self-contained bundle nearly as easily as I can with Racket. And Graal (the option I’m aware of for compiling JVM-based code into a redistributable binary) is definitely Oracle. If I wrote more long-running code, or I could redistribute a stripped down JVM as easily as with Racket’s build tool “raco” I might have a different view, an…

OpenJDK is also made (primarily) by Oracle [1]; in fact, OpenJDK is the name of Oracle's one and only Java implementation project, although Oracle builds both free and support subscription binaries from it. Both OpenJDK and Graal are open source, though. OpenJDK now includes a tool called jlink [2] that allows you to create a small, self-contained bundle that includes a custom runtime as well as your app. [1]: http:/…

I’d love to see a tutorial on how to do this with Clojure—especially integrated with the Clojure build tooling.

Re: Clojure: A Lisp that wants to spread

#224

Post by abrax3141 »

armitron wrote: post #190
abrax3141 wrote: post #86

I don’t actually get the big deal about enforced immutability. Of course, you need to constrain yourself in certain circumstances to do things immutably, but it seems like something that should be contextual (immutably ...), rather than enforcing it. In fact, sometimes it is necessary in high performance multi—threaded/multi-processor environments to use side effects judiciously. Moreover, most serious lisp programme…

Most serious Lisp programmers write mutable code. Common Lisp is multi-paradigm but most code written has side-effects. And that’s for a good reason: Clojure-style immutable programming doesn’t fit most problems very well. Which is why Clojure will never be a language with the lasting power of Common Lisp. It prematurely optimizes and constrains your thinking into a single paradigm.

I write CL production code all the time. Basically daily. I use hash tables a lot, and those are obviously mutable (I did mention that as an exception) but most of the rest of my code is pretty much functional, which is generally (though not uniquely) immutable. I can’t really see how it makes sense to do hash table immutably. It might just be me, but functional style tends toward immutability be default.

Re: Clojure: A Lisp that wants to spread

#225

Post by yogthos »

rubyn00bie wrote: post #32

Last week some nice folks assured me tooling was good in Clojure; and not a total time suck, and so I'm getting ready to take the jump I think... but, one thing I'm still really skeptical about... is embodied in this paragraph: > The way the languages are integrated today, Clojure developers doing full-stack development don’t really have to think about data serialisation/deserialisation. Writing code for frontend and…

My team is developing full stack apps with Clojure, and using Clojure on the backend with ClojureScript on the frontend is completely seamless.

I copresented a talk on the platform my team develops and how we leverage Clojure features there, specifically the ability to cross-compile between Clojure and ClojureScript that might be of interest https://www.youtube.com/watch?v=IekPZpfbdaI

Re: Clojure: A Lisp that wants to spread

#226

Post by hcarvalhoalves »

pgt wrote: post #188

The most interesting Clojure-like language around is, IMO, Carp[^1]. Carp is a Lisp written in Haskell that compiles down to C with Rust ownership semantics and looks like Clojure. So you get a GC-less Lisp with fast startup time that is suitable for game development with the safety guarantees of Rust. [^1]: https://github.com/carp-lang/Carp

It doesn't seem to have immutable data structures by default and concurrency primitives. That changes greatly how you write algorithms and structure your program.

It's cool, but it's like the complete opposite of the main ideas behind Clojure.

Re: Clojure: A Lisp that wants to spread

#227

Post by _xt8z »

lincpa wrote: post #216
_xt8z wrote: post #199

Earlier quoted context omitted.

The quoted part reminds me of the fizzbuzz enterprise edition.

Unfortunately, you treat the quote as a joke, and you have no ability to apply the quote at all.

You are making unfair and uninformed assumptions about me, someone you do not know. I've worked professionally as a full-time Clojure developer for many, many years.

> you have no ability to apply the quote at all.

You don't know what my abilities are.

Re: Clojure: A Lisp that wants to spread

#228

Post by abrax3141 »

_bxg1 wrote: post #88
abrax3141 wrote: post #86

I don’t actually get the big deal about enforced immutability. Of course, you need to constrain yourself in certain circumstances to do things immutably, but it seems like something that should be contextual (immutably ...), rather than enforcing it. In fact, sometimes it is necessary in high performance multi—threaded/multi-processor environments to use side effects judiciously. Moreover, most serious lisp programme…

> sometimes it is necessary in high performance multi—threaded/multi-processor environments to use side effects judiciously The short answer is: Clojure (and other languages/frameworks that emphasize immutability) is not intended for those use-cases. The long answer is, Clojure added something called "transient data structures" as a trap-door for cases where you really absolutely need mutability for performance: http…

I haven’t really thought this through, but at the OS level we used to have the concept of reentrancy, which separated code from variables for multi-tasking. I haven’t seen this exact concept in a programming language level, although I don’t know every language, and it may exist by another name. I didn’t really think about this until now, but I naturally write reentrantly, separating the hash tables and globals For cross thread data, and writing everything else functionally, and/or using the thread system to manage all other mutables as locals (like the transient construct, I guess).

Re: Clojure: A Lisp that wants to spread

#229

Post by lincpa »

_xt8z wrote: post #227
lincpa wrote: post #216

Earlier quoted context omitted.

Unfortunately, you treat the quote as a joke, and you have no ability to apply the quote at all.

You are making unfair and uninformed assumptions about me, someone you do not know. I've worked professionally as a full-time Clojure developer for many, many years. > you have no ability to apply the quote at all. You don't know what my abilities are.

show you github or blog, Time is not ability.

Re: Clojure: A Lisp that wants to spread

#230

Post by wry_discontent »

doglooksgood wrote: post #212
tensor wrote: post #26

Startup time isn't what is holding the language back. In my opinion it's: 1. Tooling. You end up spending way more time getting your tooling setup than it should be. 2. Difficulty in learning. 3. Clear best practices and frameworks. The philosophy of composing libraries is extremely powerful, but to gain broader adoption you still need straight forward frameworks and opinionated best practices. The last point has man…

If you tried Clojure a few years ago, the Tooling could be a problem. But now, the tools-deps(official Clojure cli) is awesome.

How do you find it compares to Leiningen? I'm using lein for all of my side projects (and shadow-cljs) and I like it. What does tools-deps offer me?
Post reply on HN