28 ms·

Clojure: A Lisp that wants to spread

386 points by simonpure 7y ago

anmonteiro90 7y ago
It'd be interesting to back the claim that "Clojure is (slowly) eating the world.". Interestingly, that's absolutely not my perspective and I don't see any sources for that statement in the post.
- simongray 7y ago
  I was talking about its ever expanding reach. It was more of an intertextual reference to the Andreessen Horowitz classic than an ideological statement about the popularity of Clojure, that is why I also added the (slowly).
  - anmonteiro90 7y ago
    That makes sense but it's not what comes across. The sentence immediately after says that "the language continues to grow". That's what I'm questioning.
    - simongray 7y ago
      That is my impression, especially 2019 seems to have been a turning point after 1-2 years of relative stagnation, but I get that you feel differently. That's why you switched to OCaml ;-)
      - anmonteiro90 7y ago
        I don't wanna nitpick too much (I realize that's all I'm doing). I just wanted to caution against stating what you perceive as a fact without any backing references.
      - Scarbutt 7y ago
        Looks like its peak was in 2014[0] and since then it has been declining. https://trends.google.com/trends/explore?date=all&geo=US&q=clojure https://trends.google.com/trends/explore?date=all&geo=US&q=c...
        iLemming 7y ago
        How is it declining? Every single year we're adding 3-5 new conferences, last year alone - Ukraine, Russia, Brazil, India, Canada. New books being published. There are number of active podcasts (more than for any other FP lang). Latest JVM survey shown - Clojure has become more popular than Scala (largely due to Kotlin), but still surprisingly so. There's a Clojure related post on HN top, almost every week, sometimes multiple times a week. Sure, it ain't Typescript or whatever, but it's definitely not declining.
        piokoch 7y ago
        Maybe it just means that there is a small and vocal community around Clojure - being on HN means that something is interesting for HN community, but it does not translate to wider adoption necessarily. When Clojure was started it didn't have much competition in JVM languages space. There was Scala only. Right now we have also Kotlin, which seems to be hitting the sweet spot between being a better Java and being difficult to grasp (like Scala or Clojure). In addition Java alone is getting better, so it is harder and harder to eat its cake.
        iLemming 7y ago
        > Maybe it just means that there is a small and vocal community around Clojure There's relatively small but vocal Emacs community. There are no books being published; almost no podcasts; it took forever to organize a conference, but they still couldn't find a venue, so it was a video-conference. Every few years there's a new "Emacs killer" but the ecosystem (after over 40 years) is very much alive and thriving. Same thing can be said about Clojure. It's a very vibrant ecosystem and there's a lot happening in Clojuresphere, but of course, with almost every post about Clojure, there would be at least one person to claim - "Clojure is dying." Well, if that's true, then buckle-up folks. It's going to be a very long, steady ride.
  - deleted 7y ago
    [deleted]
lbj 7y ago
Thats last few sentences make no sense. The argument is that uptake is stunted by the JVM's slow startup time, making it unsuitable for commandline utils or desktop apps. However thats easily fixed which was never more hillariously stated than when Rich Hickey did it a decade ago. A blogpost went viral and it was a thunderous critique of Clojure, focused on this single point of slow start up. In the comment section was only 1 reply from Rich: time java -client -jar clojure.jar helloworld.clj > system time 0.0001s The -client param makes all the difference :)
- simongray 7y ago
  This is what I am referring to: http://clojure-goes-fast.com/blog/clojures-slow-start/ http://clojure-goes-fast.com/blog/clojures-slow-start/ > As it turns out, Clojure start time is a complicated and multi-dimensional topic. Clojure projects are slow to start not only because of JVM — JVM itself starts in ~50 ms — but because of JVM specifics the classes are loaded slowly. Clojure projects are slow to start not only because of Clojure — Clojure itself starts in ~1 second — but because of Clojure specifics, the namespaces, especially not AOT-compiled one, are loaded slowly. And so on.
- michaelmrose 7y ago
  Running a simple cli application written in clojure with the help switch ensuring it doesn't do much beyond print text. With and without -client 1 second Built with graal 22 ms
- finalfantasia 7y ago
  According to the latest status update from a member of the Clojure core team [1], we may see improvements in startup time with the next version of Clojure (1.11). [1] https://insideclojure.org/2020/02/28/journal/ https://insideclojure.org/2020/02/28/journal/
- rubyn00bie 7y ago
  For anyone else wondering, "holy crap, WTF does -client do?" here you go: https://stackoverflow.com/a/198651/931209 https://stackoverflow.com/a/198651/931209 And to save folks a click: > The Client VM compiler does not try to execute many of the more complex optimizations performed by the compiler in the Server VM, but in exchange, it requires less time to analyze and compile a piece of code. This means the Client VM can start up faster and requires a smaller memory footprint. There's literally so many just insane things about the JVM and its variants, I totally get why some folks are like "JAVA OR DEATH." I just wish I had started learning it 20 years ago, like a lot of 'em, so it wasn't such a gigantic wall of pedantic knowledge to acquire.
zerr 7y ago
While we are at it - how do you refactor a mid-sized/large Clojure project?
- pjmlp 7y ago
  By making use of nice tooling like Cursive.
  - throw03172019 7y ago
    The Cursive keyword rename feature is nice!
- crispinb 7y ago
  To add to your question: does spec help here?
  - iLemming 7y ago
    Short answer: "sometimes it does." More accurate short answer: "it depends."
- slifin 7y ago
  TDD? Testing in Clojure has such a nice feedback loop in Cursive, clj-kondo is a nice sanity checker, and most editors have rename functionality Long term I can see a more intelligent feedback system powered by codeq helping with static analysis and refactor feedback, like unison but better (using a real DB and open for extension)
- didibus 7y ago
  So, my first answer is that you shouldn't have too, and if you do, you might not be writing proper Clojure code. The most fundamental concept in Clojure, from the famous Rich Hickey talk Simple Made Easy (https://www.infoq.com/presentations/Simple-Made-Easy/ https://www.infoq.com/presentations/Simple-Made-Easy/) is that your code should strive to be decomplected. That means that your program should be made of parts that when modified do not break anything else. This, in turn, means you don't really ever need to refactor anything major. In practice, this has held true for most of my code bases. Now, my second answer, because sometimes there are some small refactors that may still be needed, or you might deal with a Clojure code base that wasn't properly decomplected, you would do it the same way you do in any dynamic language. The two things that are trickier to refactor in Clojure are removing/renaming keys on maps/records, and changes to a function signature. For the latter, just going through the call-sites often suffice. The former doesn't have that great solutions for now. Unit tests and specs can help catch breakage quickly. Trying out things in the REPL can as well. I tend to perform a text search of the key to find everywhere it is used, and refactor those places. That's normally what worked best for me. It helps a lot if you write your Clojure code in a way that limits how deep you pass maps around. Prefer functions which take their input as separate parameters. Prefer using destructuring without the `:as` directive. Most importantly, design your logic within itself, and so keep your entities top level.
gentleman11 7y ago
Why don’t lisp fans use older lisp implementations like Common Lisp or scheme? Is it just a lack of libraries and frameworks?
- bgorman 7y ago
  Clojure lets you leverage all libraries of the host language e.g. Java, Javascript or C#.
- agumonkey 7y ago
  Who knows what the lisp crowd is ? I'd like to have a broad view of how many lispers working with one. the few I know: - scheme had a coma period due to specs issues (scheme small and large standard) - commonlisp .. no idea but it seems quicklisp is enough for anybody to work, and there are many libs. Maybe not java/python levels .. but many. It's just out of the radar.
- simongray 7y ago
  Clojure is functional to the core and innovates a lot of areas, while other Lisps are more multi-paradigm and slant towards an OOP style. If you want to work universally with persistent data structures in your code and the libraries you use, Clojure is really the only option. Clojure also modernises Lisp syntax slightly (and a bit controversially) by getting rid of lots of parentheses and introducing new styles of parens for the core built-in data structures: ( ) [ ] { } #{ }. There's a bunch of other stuff, but really, Clojure is significantly different from other lisps. The Rationale page on clojure.org has a pretty good rundown: https://clojure.org/about/rationale https://clojure.org/about/rationale
  - innocentoldguy 7y ago
    Personally, I like what Clojure has done for Lisp syntax. I don’t have the greatest eyesight anymore and Clojure makes it easier to read my code.
    - peatmoss 7y ago
      I agree. Greg Hendershott apparently also agreed as he ported some Clojurisms to racket in the form of a language / loadable library: https://docs.racket-lang.org/rackjure/index.html https://docs.racket-lang.org/rackjure/index.html
btcinfo 7y ago
Clojure wants to spread all right, like the disease it is.
- dang 7y ago
  Could you please stop posting unsubstantive comments to Hacker News? We're trying for something a bit different here. https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html
Random_ernest 7y ago
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.
- innocentoldguy 7y ago
  I like Clojure too but its less-than-useful error messages are what got me interested in Elixir. I still get Lisp-style macros with a better syntax (for me) and outstanding error messages (generally speaking).
- slifin 7y ago
  Yeah learning those first errors is a bit annoying learning what IFn is can be a bit cryptic but ClojureScript with shadow or figwheel gives really good errors
- deleted 7y ago
  [deleted]
- grierson 7y ago
  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 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-stacktrace-required http://blog.cognitect.com/blog/2017/6/5/repl-debugging-no-st...)
pron 7y ago
Can we please stop using the verb transpile? Compile is fine, thank you. When it was used only for certain kinds of "shallow" compilation it was bad enough (and it was really horrible even then), but this article uses it when describing compilation with whole-program analysis and optimization and machine code as the target.
- simongray 7y ago
  I do apologise. This was written mostly as a stream of consciousness, only stopping to google the github repos.
  - pron 7y ago
    Thank you. Also, "referential transparency" doesn't mean what some FP people think it means [1]. Even though no language with macros is referentially transparent [2], Clojure, like all Lisps, is a poster child of referential opacity (opaqueness?), deriving much of its power from it. If you can quote code terms, you can't possibly be transparent with respect to reference (denotation). Saying "pure" or "without side-effects" -- that, while not entirely precise, at least expresses the intended meaning -- is both simpler and better than saying "referentially transparent", which is often just wrong. Anyway, Clojure is great! [1]: https://stackoverflow.com/a/9859966/750563 https://stackoverflow.com/a/9859966/750563 [2]: Sorry Template Haskell, Java is more referentially transparent than you, although the consequences of that are not what those same FP people think, either.
    - kreetx 7y ago
      Could you elaborate on the part on "no language with macros is referentially transparent", specifically, do you mean that if macros can do IO, then the transparency isn't there anymore?
      - pron 7y ago
        IO and side effects have aboslutely nothing to do with referential transparency. A referentially transparent expression is one whose subterms can be replaced with other subterms having the same meaning (reference) without changing the meaning of the expression. Hence, the expression -- a piece of syntax -- is transparent to its reference (denotation, or meaning). Change any piece with another with the same meaning, and the overall meaning is the same. For example, Java is a referentially transparent language. Suppose we have: int x; int f() { x++; return 3; } int g() { x++; return 3; } Then g and f have the same meaning, and in any Java expression, they are interchangeable (the fact they have side-effects is totally irrelevant). This is not true for Clojure and Haskell (template Haskell), which are not referentially transparent, because, e.g. (defn f [] 3) (defn f [] 3) (defmacro foo [x] (str x)) Then (foo f) and (foo g) mean something very different, even though f and g have the same reference, hence the expression (foo ...) is not transparent to its subterms' references, but rather their syntax obscures them. When some FP people say "referential transparency" they actually mean something else altogether. They mean that the meaning of a subroutine application that yields the value 3 is indistinguishable from the value 3. This is, indeed, not true in imperative languages like Java and Clojure, but this is called "value semantics" -- i.e. the meaning of any expression is just a value in the language -- or simply, being pure functional. Then why do they call it "referential transparency"? This has to do with social dynamics in the FP community that is eager to use mathematical-sounding terms but the people don't usually have the requisite mathematical understanding, so like in a game of telephone those terms are quickly used incorrectly and drift away from their correct meaning. Natural language (see example in the link I posted in my previous comment), programming languages with macros and modal logics are not referentially transparent, because referential opacity adds more power to a language (Lisp can express computations that the lambda calculus cannot, thanks to macros). That FP people (who often rely on referential opacity) say referential transparency is a good thing is also a result of a compulsion in that community to take neutral mathematical definitions and assign them moral values. Referential trasnparency has some properties, some of them can be helpful in some circumstances and some can be harmful in other circumstances. In general, however, it is not a particularly important property one way or the other.
tensor 7y ago
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 many unintuitive consequences. Clojure tends to attract people who enjoy doing new things, or excelling in their craft. But mass adoption also means catering to people who need to do "boring" things where people just want to get their job done. For boring code, which is the reality for many developers, they just want a clear best practice to get the stuff done. This could be a clear standard library or framework for a task, a clear architectural pattern, and it certainly means easy to access code snippets. There have been some attempts at these things, e.g. Luminous for the web, but the community hasn't rallied around them with enough weight to make newcomers comfortable. So when faced with choosing: a testing library, any number of libraries compose into a web service, any number of approaches to client side, then in the end still having 100 equally good ways to architect a given piece of code that requires thinking mathematically, well, it's daunting. Especially when you are new to the language and just want to get your boring CRUD app working. Maybe this is best summed up as saying that Clojure caters to the creative, but to gain widespread adoption it also needs to cater to those stuck writing boring code and just want to be done with it as fast as possible.
- Goladus 7y ago
  > Startup time isn't what is holding the language back. For what it's worth, I am a system administrator (or DevOps engineer or infrastructure architect or whatever the trendy name is now). I've written several non-trivial automation tools where I had the option to use pretty much any language I wanted. The startup time and overall awkwardness of deploying the JVM for scripting was the undeniable deal-breaker. (I used Python instead). > For boring code, which is the reality for many developers, they just want a clear best practice to get the stuff done. More likely they just need a solution with the least-necessary added complexity or observable downsides, and that rules out the bulky JVM with its slow start-up time and the fact that Java has been under the jurisdiction of Mordor since 2010.
- 7y ago
zelly 7y ago
I tried Clojure but ended up hating it for reasons all stemming from its hosted implementation. Whenever I didn't know how to do something, I (and most other Clojure users) would go use some JDK class (or worse, an external Java library) instead of figuring out how to write the Lisp. For some reason this doesn't often happen with regular Lisp even though CFFI is available. There's a tendency to just reimplement it directly in Lisp, which is the more maintainable option.
- simongray 7y ago
  I have to say that I don't really recognise that thing about using JDK classes. I've worked with Clojure for 2 years on a big government project (maybe 50 Clojure devs) and it was full-stack Clojure all the way down. We never used any Java libraries either, but of course basic Java/JS interop is a pretty normal occurrence in Clojure when doing a certain type of code (like reading and writing certain binary files to disk, you'd probably reach for the Java Standard Library). For 99% you need no interop in Clojure. ClojureScript is a bit different as you often do need to access HTML elements or various singleton objects like js/window or js/document and have to use JS interop.
  - oulu2006 7y ago
    I have to concur with you mate, I've used Clojure now for 6 years in 2 startups and I can almost count on 2 hands the number of times I've had to interop directly with Java classes to get something to work.
- didibus 7y ago
  Hum, that's one of my favorite things. Some JDK APIs/libs are quite well designed, and when they are, Clojure doesn't bother re-inventing the wheel, which is a great thing in my opinion.
- DannyB2 7y ago
  While I am an experienced Java developer, and took immediately to clojure, I don't think you deserved to be downvoted for expressing that experience. I can imagine if I were to learn a new lisp, that was hosted on a language I did not know, and various difficult things leaked through the abstraction making it more difficult for me to work. I might feel similarly.
rubyn00bie 7y ago
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 backend differ mostly just in the way that the different implementations access the host platform. The functional aspects of Clojure, especially the immutability and focus on referential transparency, ensure that source code is mostly split into chunks of highly portable code, with the host-interop conveniently put aside in its own sections. You can move code between frontend and backend at your leisure. Is it really that good using Clojure across environments and runtimes? I ask because I tried all of this with Scala years ago (I loved the language) and Ruby to an extent, but it was pretty miserable or rather there was really no reward but more effort on my part. I.e. I'd spend more time annotating, bridging, and learning how to interact with the different runtime than I would writing actual feature code[1]. Or like what are the killer libraries everyone loves? Do they (libs/frameworks) support different clojure runtimes ("hosts?") outta the box? Is it easy to write "pure clojure" projects that work for any clojure project? The one I know about or have heard most about was Datatomic, which always sounded freakin' brilliant, but I don't fucks with non-free databases. Arcadia I just saw and it looks cool but, it also seems like a dumb mountain to climb, if that's how I wanted to start screwing around with Clojure. [1] Tools like Scala/ScalaJS and RubyMotion (back in the day, heh), were the reasons I ended up a polyglot. They're great tools, if you know the platform, if you don't, you're pretty much still fucked... but once you know the platform it's kind of hard to want to use them.
- throw03172019 7y ago
  I have been writing helper libs with our shared logic in Clojure (CLJC). It is pretty nice to have the same core on the frontend and backend. It is easy enough to use the conditionals to call a Java fn vs. Javascript for certain logic (I.e Dates, etc)
- scarredwaits 7y ago
  I can attest that full stack (server-browser) Clojure code sharing works very-very smoothly. I've been developing web applications like that for some time now, and apart from less context swithing (because it's the same language on both sides), sizeable parts of the code are cross-compiled to run both on the browser and the JVM with very little or no extra effort. Example 1: I'm using Clojure's Spec library for validation. There is code that is used on the browser to validate the input that users enter into forms, and the same exact code is used on the HTTP endpoints that are called when the user attempts to submit the form. Example 2: I'm using the Tongue library to provide client-side translations of the whole UI, but the same data files and library are used in some cases on the server to generate files that contain translated strings. Example 3: The web UI logic is written using pure data manipulation (thank the Re-frame library for that) and because of that we are able to unit test it on the JVM without having to go through the complecity of launching and driving a browser on our CI server.
svnpenn 7y ago
The situation with windows is weird. You have to run a powershell script to install. They should just offer a Zip or Exe like every other programming language. https://github.com/clojure/tools.deps.alpha/wiki/clj-on-Windows https://github.com/clojure/tools.deps.alpha/wiki/clj-on-Wind...
- reitzensteinm 7y ago
  tools.deps is in alpha - even as someone that uses Clojure on Windows, I think it's fair enough that they don't care about Windows just yet. Leiningen works great on Windows, and Boot is meant to as well (though I don't have first hand knowledge of that).
- didibus 7y ago
  You could try with: https://github.com/borkdude/deps.clj https://github.com/borkdude/deps.clj It replaces the powershell code with a Clojure based executable.
- iLemming 7y ago
  > The situation with windows is weird. Isn't it always? Basically anything that's not related to .NET has its warts in Windows. Erlang for example.
  - pjmlp 7y ago
    Delphi, Python, Ruby, C++, Qt, Perl, nodejs, Java, Pharo/Smalltalk, Eiffel, Common Lisp, Ada do pretty well on Windows, without being .NET related.
    - iLemming 7y ago
      Funny, I'm probably getting old, but I do remember times when every single one of these had issues in Windows. Besides, all of them are much older than Clojure.
vemv 7y ago
My personal perspective (after 8 years clojuring, half of that professionally) is that Clojure keeps progressing, with ever better tools and ideas for getting stuff done, optimally. I remain optimistic. At the same time, it still fails at my "golden test": can I gather 5 random freelance engineers and get them to ship a project within a few months, wasting almost no billable time? I can (and have) with Ruby, Typescript. People can learn those on the go, being productive on day 3 or so. Clojure is still bit of a journey on itself, involving quite a lot of stuff to learn, and plenty of choices to make. That's not necessarily a bad thing, nor Clojure's "fault", but it's a real cost/risk that is still there. I do envision a future where the mainstream is ideologically closer to Clojure, and Clojure offers an (even) more polished set of tools than today. With that mutual proximity, Clojure could indeed eat the world.
- ken 7y ago
  Maybe I’m just dense, but I certainly have not been productive with any language on day 3. (Not even Ruby, which feels comfortable faster than most languages.) I sometimes felt productive that soon but I always end up having to rewrite once I learn the language fully. I’ve learned enough languages that I can spot “a person’s first program in X” now pretty easily.
  - bcrosby95 7y ago
    Yeah, same. But it does help a lot having a professionally developed project with lots of high quality, real world examples of how to do things.
  - vemv 7y ago
    My background is freelancing/consulting where it's not uncommon to gather diverse individuals to work on a greenfield project. There's an implicit assumption that all participants know a thing or two about programming, and accordingly are apt learners. So yes, on day 3 the code won't be perfect, neither on day 6 but after a few code reviews one can get stuff done. Personally I wouldn't be comfortable prescribing Clojure for such a project, in contrast to other languages which I've never coded in, but that I know that socially, today, work better.
yarrel 7y ago
The dealbreakers with Clojure for me are: 1. Weirdly irregular syntax. 2. Java import statements and Java error backtraces anywhere you want to do real work. 3. Inexcusable renaming and name collisions on basic Lisp functions. It's much, much less of a Lisp than Scheme and neither "but it's properly functional" nor "we fixed the tooling now" make that any less true or the language any more interesting for the use cases of using a Lisp or targeting the JVM with a more expressive language.
- elwell 7y ago
  > Weirdly irregular syntax. "Irregular syntax", as in not consistent with itself? Or, with historical LISPs? Some examples would be interesting.
- iLemming 7y ago
  Well, if you are building your own thing for your own amusement you can find that perfect, more expressive language and use it. For those of us who work for someone else - Clojure is a godsend. What's the alternative? No Lisp at all, and truly weirdly irregular syntax. Show me a single pragmatic and more or less popular language that's being used in the industry for building business apps that has nicer syntax than Clojure.
- keymone 7y ago
  1. Elaborate please 2. If you’re writing a wrapper to existing java lib maybe 3. Tough to be a particular lisp fanatic I guess.. Clojure helped me to get into lisp big time and all other lisps now feel clunky and inelegant.
- akra 7y ago
  I do agree that initial impressions are important for a language and "perceived" learning curve does make a difference. Things that scare people away initially do hurt adoption; things like Clojure's syntax and that it is a dynamic language on the JVM (i.e. how does that affect interop/performance/etc) all raise questions. Even if there are answers to these questions and justified reasons just like most sales pitches you've already lost a lot of people who have doubts and are already productive as they are. As an example I remember a presentation done some time ago where the presenter was showing code in F# and many non-technical people understood the code thinking it was a pseudo code at first (i.e. business stakeholders/BA types/etc). That was a win for them. If I showed F# and Clojure code side by side to an ex-coder manager as an example syntax I'm sure would matter and they often have a say in this decision. Buy-in is an important criteria in language selection for sure, as well as current skilled developers. If the pool of devs is small how easy it is to train people and get people wanting to be trained in it thinking it may be dead end skill with no jobs? I don't have that opinion personally but some dev's definitely do. Especially because jobs in these languages are scarce; if learning curve is small then it could be used even then. My cynicism shows marketing and perception of a tech stack are equally if not more important than other factors in tech selection in many companies. No one got fired for picking IBM or in this day and age Java?
Zelphyr 7y ago
What I want to know is where to find a Clojure and/or ClojureScript job. I got a taste of Clojure on a project late last year and became enamored with it. So much so that I would love to find a job where I can use it at least part of the time.
- emmanueloga_ 7y ago
  Try the #jobs channel of https://clojurians.slack.com/ https://clojurians.slack.com/
abrax3141 7y ago
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 programmers almost write immutably by default. The only (common) exception being hash tables, but you just don’t use them if you need more control.
- _bxg1 7y ago
  > 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: https://clojure.org/reference/transients https://clojure.org/reference/transients But they are really intended to be the exception, not the rule. Enforced immutability is a conscious choice you make to trade some performance for increased robustness. Also, compared to "immutability by convention", enforced immutability allows certain optimizations to be made that greatly decrease the wasted memory and allocation/deallocation that would occur if you naively cloned everything.
  - abrax3141 7y ago
    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).
    - _bxg1 7y ago
abrax3141 7y ago
If you want fast startup times, just live in emacs, keeping multiple shells alive underneath. You can build yourself a whole clojure repl that just lives there all the time (startup once), and a bash or whatever you like as well.
justlexi93 7y ago
With GraalVM and a bit of exaggeration, it feels like the story only begins.
raz32dust 7y ago
I am not sure I buy into the argument that startup time is the hurdle to Clojure adoption. If that were the case, we would have at least seen more adoption for server use cases. Applying Occam's razor, I think Clojure is not popular for the same reason that common lisp is not popular - it is simply too hard. Functions and immutability are a more difficult abstraction to grasp compared to objects and procedures and mutable state. The overhead of finding quality talent is too high, and likely always will be because of this.
- iLemming 7y ago
  Clojure is not hard. It's just different. People immediately reject anything that's different. Just like when Fibonacci tried to convince people in 13th century to use indo-arabian numerals. I've seen people with no prior programming experience learning Clojure within a few days. And I've seen senior software developers struggling with it for months.
didibus 7y ago
For me, this article is spot on. I had been looking for a long time for my one language I can use for everything, and Clojure finally (just recently) got there. I can use it for scripting, writing command line apps, making backend services, writing web front-ends, making desktop applications with GUI, toying with generative art, doing data-science, making games, and more. It really has great reach, and its only getting better. Similarly, in terms of programming language, you can use it to explore many paradigms and innovative ideas, like CSP, logic, probabilistic, functional, meta, concurrent, dynamic, typed, contracts, data-flow, OOP, condition systems, monads, etc. All this keeps me interested and constantly learning. Never having to wait for features you miss or wish you had. I can see myself sticking with Clojure for a long time.
deleted 7y ago
[deleted]
shivekkhurana 7y ago
I shifted to writing Clojure full time in November 2017 and feel that I've improved greatly as a developer. Other languages taught me how to solve problems their way, Clojure taught me how to solve problems. My biggest hurdle while getting started was lack of Newbie friendly resources. And the language is kinda scary at first, specially if you are like me and have spent 5 years working with Python or JS. Dr. Fynmann said that if you want to get better at something, teach it. Following his advice I've published multiple articles [1][2][3][4] and given a talk about Clojure at a js conf [5]. The tooling is steadily improving. I don't think it will be as widespread as JS but I doubt if it aims to be. Clojure seems to attract a certain kind of developers anyways. --- [1] What I learned after writing Clojure for 424 days, straight https://krimlabs.com/blog/clojure-424-days https://krimlabs.com/blog/clojure-424-days Learn Clojure by building a drug dealer api [2] https://krimlabs.com/blog/clojure-drug-dealer-part-1 https://krimlabs.com/blog/clojure-drug-dealer-part-1 [3] https://krimlabs.com/blog/clojure-drug-dealer-part-2 https://krimlabs.com/blog/clojure-drug-dealer-part-2 [4] https://krimlabs.com/blog/clojure-drug-dealer-part-3 https://krimlabs.com/blog/clojure-drug-dealer-part-3 [5] If you are going to transpile JS, why not use ClojureScript? https://www.youtube.com/watch?v=Bs44qdAX5yo https://www.youtube.com/watch?v=Bs44qdAX5yo
ertucetin 7y ago
I think Clojure is going to be a spec for Lisp family in the future.
- TurboHaskal 7y ago
  You probably have only scratched the surface of Lisp if you really think that.
lincpa 7y ago
Clojure is a FP (Lisp) language based on RMDB theory, which is very suitable for dataflow and data-driven programming, so it is suitable for large-scale industrialized pipeline software development using Warehouse/Workshop Model model. https://github.com/linpengcheng/PurefunctionPipelineDataflow https://github.com/linpengcheng/PurefunctionPipelineDataflow
- harperlee 7y ago
  In the last ~18 months you have been /very/ energetic in promoting your theory here, I have some alerts since about a year and you are always popping up with the same link. Looking into your posting and commenting activity, there not much more. By now I guess that you have had enough exposure, but most of your comments and links to github have not sparkled a lot of interest or comment, and reception has been skeptical / lukewarm. Take this as just one datapoint but for me your insistent reposting is more noise than any other thing. If you really care about your theory that is cool and all, but may I suggest that you create something like some practical application examples in blog form, edit them thoroughly, and then post them as new topics, intead of polluting "related" conversations? That way you can better gauge what interests this community, and what not. By the way interleaving english and chinese such as in your repo README.md makes for an unpleasant read - better to separate both in two distinct documents. Best luck!
  - lincpa 7y ago
    I noticed that you have not posted any useful technical comments in the last 100+ days. Sorry I didn't keep reading. In fact, this theory has been unprecedentedly hot recently. Star and traffic on github have risen sharply. On 2020-02-27, it was published by editor on reddit/devopsish, and other clojure communities. My theory is written for a few people who understand Chapter 2 of the "Code Complete" and can read it without reading other chapters, not for people who cannot understand Chapter 2 and focus on other chapters. So I have stated in the article: I will not write too many application examples or patterns. Because people who like to read such articles can't learn my theory.Because they lack imagination. ``` Imagination is more important than knowledge. The true sign of intelligence is not knowledge but imagination. Logic will get you from A to B, imagination will take you everywhere. ---- Albert Einstein ```
lincpa 7y ago
You need a well-organized linear pipeline system, this is "The Pure Function Pipeline Data Flow v3.0 with Warehouse / Workshop Model"
- dang 7y ago
  We detached this subthread from https://news.ycombinator.com/item?id=22462241 https://news.ycombinator.com/item?id=22462241.
- engineeringwoke 7y ago
  I hope you realize that this is complete nonsense to anyone that isn't part of your new "new" functional programming cult. It has almost no semantic meaning.
  - hellofunk 7y ago
    I definitely saw nothing but sarcasm in the comment you are replying to. But now after looking at their other comments, I see it was not sarcasm. What an understatement for how messy functional programming can actually be.
    - engineeringwoke 7y ago
      I thought he was joking at first too and googled it to find out that he was in fact serious.
      - hellofunk 7y ago
        The quoted part reminds me of the fizzbuzz enterprise edition.
        lincpa 7y ago
        Unfortunately, you treat the quote as a joke, and you have no ability to apply the quote at all.
ooooak 7y ago
1. In India, there are only ~100 jobs for a Clojure developer. That includes people just throwing in Clojure just to hire Java/Scala developer. 2. The learning curve for the Clojure. Clojure is simple but it's not easy by any means. 3. JVM interop if you are not a java developer it adds in more learning time. Most of the Clojure libraries use java heavily. It's a good thing but it adds in an extra layer of learning java's ecosystem. 4. Error messages. Even after years of Clojure. I still find it hard. 5. Documentation. Most of the packages I use don't have dedicated websites or good documentation. Even after all the issues. It's still worth the investment. I started working on a crawler for a freelance gig. we first built it using Golang. But due to its complexity and lots of bugs due to mutation. We ported it to Clojure and we are not looking back.
- abhijat 7y ago
  If you're in Pune or willing to shift, Helpshift uses clojure heavily.
- Heliosmaster 7y ago
  To be honest, I've done Clojure full-time (and exclusively) for 6 years now. I've almost never had to use Java interop. (With CLJS I did a little more JS interop). There were always wrappers written by somebody else that always did what I was looking for.
pgt 7y ago
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 https://github.com/carp-lang/Carp
- simongray 7y ago
  I thought about including this since I saw a talk about it once where the guy referenced Clojure, but they don't talk about Clojure at all in the README.md.
- hcarvalhoalves 7y ago
  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.
maehwasu 7y ago
As someone who uses Clojure a lot: It would be a lot better for language adoption if people would write more blog posts showing best practices for tooling, and less vague stuff about how awesome the language is. For example, the startup time thing is completely irrelevant if you use Emacs/VSCode with a standalone REPL that you connect to. It's non-trivial to set this up (more because of lack of consolidated info rather than time it takes), but it can easily be standardized across machines/envs (I Dockerize all projects in a simple way to allow team members to get started up with REPLs easily).
- dragandj 7y ago
  I totally agree, and that's why I am going to write a book about that: https://twitter.com/draganrocks/status/1226811229362147331 https://twitter.com/draganrocks/status/1226811229362147331 It has to wait until I wrap up the books that are currently in progress [1], but I expect to start this summer. [1] https://aiprobook.com https://aiprobook.com
  - reilly3000 7y ago
    Random fan here: you DO rock. Thanks for your incredible work on making ML a first-class citizen in Clojure!
  - maehwasu 7y ago
    Awesome. To put my own money when my mouth is, here is the bash script to start up a nREPL server in Docker: https://pastebin.com/PPmfDPyA https://pastebin.com/PPmfDPyA Here is the Dockerfile: https://pastebin.com/ymcUFdYT https://pastebin.com/ymcUFdYT And here is a sample deps.edn with the cider alias: https://pastebin.com/2a7vSFD7 https://pastebin.com/2a7vSFD7 To run this, you'd just put them all in one directory, run cider-up.sh, and then connect to the REPL with Cider in EMACS, or in Calva for VSCode with "Jack in to or Connect to REPL Server" and then "localhost" "4444"
sproketboy 7y ago
A Lisp that wants to spread cancer. FTFA
PaulRobinson 7y ago
I used to work at a large Clojure shop. I've moved on, and I've heard anecdotally that they are building most new stuff in Go. Barrier for entry and continued use in that limited experience was: - Learning curve for new developers is very high in comparison to other languages, so moving existing engineers over sucks. - Experienced Clojure developers want a job where they can "do Clojure", not necessarily because they're interested in the problems the business was created to solve, so hiring sucks. - Lots of conversations turn to "the Clojure way" to solve a problem rather than using industry accepted protocols, standards and tooling. I mean, OK, but this makes interacting with the rest of the World a bit sucky. - Most libraries never get to v1.0. Most people write 0.0.1 and may do some minor updates so you see it get to 0.0.5 and then it stays there. That's probably because it all 'just works', but it scares most devs when they see that and are about to bake it into their next release. - Deployment is a known quantity and the JVM is useful in this regard, but it doesn't have the pure simplicity that some other runtimes do. Clojure implementations in other runtimes (Joker, Clojerl, etc.), might help or hinder here. Startup time is a problem on CLI and desktop apps, sure. At my ex-employer, one server deployed app took several minutes to start and that had challenges. That was not - I think - the reason the team started to look elsewhere or the reason I'm more likely to pick up Ruby, Python, Go or Elixir for my next project. There are lots of rough edges like the ones I identify above - many of them cultural - that need to be smoothed out a little, I think. I look forward to functional methods becoming mainstream (again?), and Clojure could get there, so I wish the community luck.
- thu2111 7y ago
  Experienced Clojure developers want a job where they can "do Clojure" This seems like a common problem with functional languages in general. I've heard the same thing about Haskell, repeatedly. Such devs search out a place where a Haskeller/Clojurist got into a tech lead position and then all pile in, before you know it the team is spending half its time writing DSL compilers instead of adding features to the product. I look forward to functional methods becoming mainstream (again?) Has it ever been mainstream? AFAIK it's always been this basically strange offshoot of the family tree that split off a long time in the past. The core problems you highlight don't have any obvious solution, unfortunately. Learning materials can be improved but ultimately Lisp is very old and very unlike more modern languages. Libraries not getting to 1.0 is a symptom of a small community that derives more satisfaction from an intellectual exploration than having lots of users, combined with lack of commercially driven outcomes. Startup time I guess can be solved with technical solutions (and is being solved, as a side-effect of other projects elsewhere in the JVM ecosystem).
Jeaye 7y ago
For anyone struggling with dynamic typing in Clojure, thinking it's impossible to manage and even harder to build confidence in your code, please look at Spec and Orchestra. You can easily build predicative contracts for all of your data and know as soon as anything "goes wrong" in terms of your data shapes. I think everyone using Clojure JVM, ClojureScript, or Clojure CLR should be doing this.

386 points by simonpure 7y ago

It'd be interesting to back the claim that "Clojure is (slowly) eating the world.". Interestingly, that's absolutely not my perspective and I don't see any sources for that statement in the post.

simongray 7y ago
I was talking about its ever expanding reach. It was more of an intertextual reference to the Andreessen Horowitz classic than an ideological statement about the popularity of Clojure, that is why I also added the (slowly).
- anmonteiro90 7y ago
  That makes sense but it's not what comes across. The sentence immediately after says that "the language continues to grow". That's what I'm questioning.
  - simongray 7y ago
    That is my impression, especially 2019 seems to have been a turning point after 1-2 years of relative stagnation, but I get that you feel differently. That's why you switched to OCaml ;-)
    - anmonteiro90 7y ago
      I don't wanna nitpick too much (I realize that's all I'm doing). I just wanted to caution against stating what you perceive as a fact without any backing references.
    - Scarbutt 7y ago
      Looks like its peak was in 2014[0] and since then it has been declining. https://trends.google.com/trends/explore?date=all&geo=US&q=clojure https://trends.google.com/trends/explore?date=all&geo=US&q=c...
      - iLemming 7y ago
        How is it declining? Every single year we're adding 3-5 new conferences, last year alone - Ukraine, Russia, Brazil, India, Canada. New books being published. There are number of active podcasts (more than for any other FP lang). Latest JVM survey shown - Clojure has become more popular than Scala (largely due to Kotlin), but still surprisingly so. There's a Clojure related post on HN top, almost every week, sometimes multiple times a week. Sure, it ain't Typescript or whatever, but it's definitely not declining.
        piokoch 7y ago
        Maybe it just means that there is a small and vocal community around Clojure - being on HN means that something is interesting for HN community, but it does not translate to wider adoption necessarily. When Clojure was started it didn't have much competition in JVM languages space. There was Scala only. Right now we have also Kotlin, which seems to be hitting the sweet spot between being a better Java and being difficult to grasp (like Scala or Clojure). In addition Java alone is getting better, so it is harder and harder to eat its cake.
        iLemming 7y ago
        > Maybe it just means that there is a small and vocal community around Clojure There's relatively small but vocal Emacs community. There are no books being published; almost no podcasts; it took forever to organize a conference, but they still couldn't find a venue, so it was a video-conference. Every few years there's a new "Emacs killer" but the ecosystem (after over 40 years) is very much alive and thriving. Same thing can be said about Clojure. It's a very vibrant ecosystem and there's a lot happening in Clojuresphere, but of course, with almost every post about Clojure, there would be at least one person to claim - "Clojure is dying." Well, if that's true, then buckle-up folks. It's going to be a very long, steady ride.
- deleted 7y ago
  [deleted]

lbj 7y ago

Thats last few sentences make no sense. The argument is that uptake is stunted by the JVM's slow startup time, making it unsuitable for commandline utils or desktop apps. However thats easily fixed which was never more hillariously stated than when Rich Hickey did it a decade ago. A blogpost went viral and it was a thunderous critique of Clojure, focused on this single point of slow start up. In the comment section was only 1 reply from Rich: time java -client -jar clojure.jar helloworld.clj > system time 0.0001s The -client param makes all the difference :)

simongray 7y ago
This is what I am referring to: http://clojure-goes-fast.com/blog/clojures-slow-start/ http://clojure-goes-fast.com/blog/clojures-slow-start/ > As it turns out, Clojure start time is a complicated and multi-dimensional topic. Clojure projects are slow to start not only because of JVM — JVM itself starts in ~50 ms — but because of JVM specifics the classes are loaded slowly. Clojure projects are slow to start not only because of Clojure — Clojure itself starts in ~1 second — but because of Clojure specifics, the namespaces, especially not AOT-compiled one, are loaded slowly. And so on.
michaelmrose 7y ago
Running a simple cli application written in clojure with the help switch ensuring it doesn't do much beyond print text. With and without -client 1 second Built with graal 22 ms
finalfantasia 7y ago
According to the latest status update from a member of the Clojure core team [1], we may see improvements in startup time with the next version of Clojure (1.11). [1] https://insideclojure.org/2020/02/28/journal/ https://insideclojure.org/2020/02/28/journal/
rubyn00bie 7y ago
For anyone else wondering, "holy crap, WTF does -client do?" here you go: https://stackoverflow.com/a/198651/931209 https://stackoverflow.com/a/198651/931209 And to save folks a click: > The Client VM compiler does not try to execute many of the more complex optimizations performed by the compiler in the Server VM, but in exchange, it requires less time to analyze and compile a piece of code. This means the Client VM can start up faster and requires a smaller memory footprint. There's literally so many just insane things about the JVM and its variants, I totally get why some folks are like "JAVA OR DEATH." I just wish I had started learning it 20 years ago, like a lot of 'em, so it wasn't such a gigantic wall of pedantic knowledge to acquire.

zerr 7y ago

While we are at it - how do you refactor a mid-sized/large Clojure project?

pjmlp 7y ago
By making use of nice tooling like Cursive.
- throw03172019 7y ago
  The Cursive keyword rename feature is nice!
crispinb 7y ago
To add to your question: does spec help here?
- iLemming 7y ago
  Short answer: "sometimes it does." More accurate short answer: "it depends."
slifin 7y ago
TDD? Testing in Clojure has such a nice feedback loop in Cursive, clj-kondo is a nice sanity checker, and most editors have rename functionality Long term I can see a more intelligent feedback system powered by codeq helping with static analysis and refactor feedback, like unison but better (using a real DB and open for extension)
didibus 7y ago
So, my first answer is that you shouldn't have too, and if you do, you might not be writing proper Clojure code. The most fundamental concept in Clojure, from the famous Rich Hickey talk Simple Made Easy (https://www.infoq.com/presentations/Simple-Made-Easy/ https://www.infoq.com/presentations/Simple-Made-Easy/) is that your code should strive to be decomplected. That means that your program should be made of parts that when modified do not break anything else. This, in turn, means you don't really ever need to refactor anything major. In practice, this has held true for most of my code bases. Now, my second answer, because sometimes there are some small refactors that may still be needed, or you might deal with a Clojure code base that wasn't properly decomplected, you would do it the same way you do in any dynamic language. The two things that are trickier to refactor in Clojure are removing/renaming keys on maps/records, and changes to a function signature. For the latter, just going through the call-sites often suffice. The former doesn't have that great solutions for now. Unit tests and specs can help catch breakage quickly. Trying out things in the REPL can as well. I tend to perform a text search of the key to find everywhere it is used, and refactor those places. That's normally what worked best for me. It helps a lot if you write your Clojure code in a way that limits how deep you pass maps around. Prefer functions which take their input as separate parameters. Prefer using destructuring without the `:as` directive. Most importantly, design your logic within itself, and so keep your entities top level.

gentleman11 7y ago

Why don’t lisp fans use older lisp implementations like Common Lisp or scheme? Is it just a lack of libraries and frameworks?

bgorman 7y ago
Clojure lets you leverage all libraries of the host language e.g. Java, Javascript or C#.
agumonkey 7y ago
Who knows what the lisp crowd is ? I'd like to have a broad view of how many lispers working with one. the few I know: - scheme had a coma period due to specs issues (scheme small and large standard) - commonlisp .. no idea but it seems quicklisp is enough for anybody to work, and there are many libs. Maybe not java/python levels .. but many. It's just out of the radar.
simongray 7y ago
Clojure is functional to the core and innovates a lot of areas, while other Lisps are more multi-paradigm and slant towards an OOP style. If you want to work universally with persistent data structures in your code and the libraries you use, Clojure is really the only option. Clojure also modernises Lisp syntax slightly (and a bit controversially) by getting rid of lots of parentheses and introducing new styles of parens for the core built-in data structures: ( ) [ ] { } #{ }. There's a bunch of other stuff, but really, Clojure is significantly different from other lisps. The Rationale page on clojure.org has a pretty good rundown: https://clojure.org/about/rationale https://clojure.org/about/rationale
- innocentoldguy 7y ago
  Personally, I like what Clojure has done for Lisp syntax. I don’t have the greatest eyesight anymore and Clojure makes it easier to read my code.
  - peatmoss 7y ago
    I agree. Greg Hendershott apparently also agreed as he ported some Clojurisms to racket in the form of a language / loadable library: https://docs.racket-lang.org/rackjure/index.html https://docs.racket-lang.org/rackjure/index.html

btcinfo 7y ago

Clojure wants to spread all right, like the disease it is.

dang 7y ago
Could you please stop posting unsubstantive comments to Hacker News? We're trying for something a bit different here. https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html

Random_ernest 7y ago

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.

innocentoldguy 7y ago
I like Clojure too but its less-than-useful error messages are what got me interested in Elixir. I still get Lisp-style macros with a better syntax (for me) and outstanding error messages (generally speaking).
slifin 7y ago
Yeah learning those first errors is a bit annoying learning what IFn is can be a bit cryptic but ClojureScript with shadow or figwheel gives really good errors
deleted 7y ago
[deleted]
grierson 7y ago
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 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-stacktrace-required http://blog.cognitect.com/blog/2017/6/5/repl-debugging-no-st...)

pron 7y ago

Can we please stop using the verb transpile? Compile is fine, thank you. When it was used only for certain kinds of "shallow" compilation it was bad enough (and it was really horrible even then), but this article uses it when describing compilation with whole-program analysis and optimization and machine code as the target.

simongray 7y ago
I do apologise. This was written mostly as a stream of consciousness, only stopping to google the github repos.
- pron 7y ago
  Thank you. Also, "referential transparency" doesn't mean what some FP people think it means [1]. Even though no language with macros is referentially transparent [2], Clojure, like all Lisps, is a poster child of referential opacity (opaqueness?), deriving much of its power from it. If you can quote code terms, you can't possibly be transparent with respect to reference (denotation). Saying "pure" or "without side-effects" -- that, while not entirely precise, at least expresses the intended meaning -- is both simpler and better than saying "referentially transparent", which is often just wrong. Anyway, Clojure is great! [1]: https://stackoverflow.com/a/9859966/750563 https://stackoverflow.com/a/9859966/750563 [2]: Sorry Template Haskell, Java is more referentially transparent than you, although the consequences of that are not what those same FP people think, either.
  - kreetx 7y ago
    Could you elaborate on the part on "no language with macros is referentially transparent", specifically, do you mean that if macros can do IO, then the transparency isn't there anymore?
    - pron 7y ago
      IO and side effects have aboslutely nothing to do with referential transparency. A referentially transparent expression is one whose subterms can be replaced with other subterms having the same meaning (reference) without changing the meaning of the expression. Hence, the expression -- a piece of syntax -- is transparent to its reference (denotation, or meaning). Change any piece with another with the same meaning, and the overall meaning is the same. For example, Java is a referentially transparent language. Suppose we have: int x; int f() { x++; return 3; } int g() { x++; return 3; } Then g and f have the same meaning, and in any Java expression, they are interchangeable (the fact they have side-effects is totally irrelevant). This is not true for Clojure and Haskell (template Haskell), which are not referentially transparent, because, e.g. (defn f [] 3) (defn f [] 3) (defmacro foo [x] (str x)) Then (foo f) and (foo g) mean something very different, even though f and g have the same reference, hence the expression (foo ...) is not transparent to its subterms' references, but rather their syntax obscures them. When some FP people say "referential transparency" they actually mean something else altogether. They mean that the meaning of a subroutine application that yields the value 3 is indistinguishable from the value 3. This is, indeed, not true in imperative languages like Java and Clojure, but this is called "value semantics" -- i.e. the meaning of any expression is just a value in the language -- or simply, being pure functional. Then why do they call it "referential transparency"? This has to do with social dynamics in the FP community that is eager to use mathematical-sounding terms but the people don't usually have the requisite mathematical understanding, so like in a game of telephone those terms are quickly used incorrectly and drift away from their correct meaning. Natural language (see example in the link I posted in my previous comment), programming languages with macros and modal logics are not referentially transparent, because referential opacity adds more power to a language (Lisp can express computations that the lambda calculus cannot, thanks to macros). That FP people (who often rely on referential opacity) say referential transparency is a good thing is also a result of a compulsion in that community to take neutral mathematical definitions and assign them moral values. Referential trasnparency has some properties, some of them can be helpful in some circumstances and some can be harmful in other circumstances. In general, however, it is not a particularly important property one way or the other.

tensor 7y ago

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 many unintuitive consequences. Clojure tends to attract people who enjoy doing new things, or excelling in their craft. But mass adoption also means catering to people who need to do "boring" things where people just want to get their job done. For boring code, which is the reality for many developers, they just want a clear best practice to get the stuff done. This could be a clear standard library or framework for a task, a clear architectural pattern, and it certainly means easy to access code snippets. There have been some attempts at these things, e.g. Luminous for the web, but the community hasn't rallied around them with enough weight to make newcomers comfortable. So when faced with choosing: a testing library, any number of libraries compose into a web service, any number of approaches to client side, then in the end still having 100 equally good ways to architect a given piece of code that requires thinking mathematically, well, it's daunting. Especially when you are new to the language and just want to get your boring CRUD app working. Maybe this is best summed up as saying that Clojure caters to the creative, but to gain widespread adoption it also needs to cater to those stuck writing boring code and just want to be done with it as fast as possible.

Goladus 7y ago
> Startup time isn't what is holding the language back. For what it's worth, I am a system administrator (or DevOps engineer or infrastructure architect or whatever the trendy name is now). I've written several non-trivial automation tools where I had the option to use pretty much any language I wanted. The startup time and overall awkwardness of deploying the JVM for scripting was the undeniable deal-breaker. (I used Python instead). > For boring code, which is the reality for many developers, they just want a clear best practice to get the stuff done. More likely they just need a solution with the least-necessary added complexity or observable downsides, and that rules out the bulky JVM with its slow start-up time and the fact that Java has been under the jurisdiction of Mordor since 2010.
7y ago

zelly 7y ago

I tried Clojure but ended up hating it for reasons all stemming from its hosted implementation. Whenever I didn't know how to do something, I (and most other Clojure users) would go use some JDK class (or worse, an external Java library) instead of figuring out how to write the Lisp. For some reason this doesn't often happen with regular Lisp even though CFFI is available. There's a tendency to just reimplement it directly in Lisp, which is the more maintainable option.

simongray 7y ago
I have to say that I don't really recognise that thing about using JDK classes. I've worked with Clojure for 2 years on a big government project (maybe 50 Clojure devs) and it was full-stack Clojure all the way down. We never used any Java libraries either, but of course basic Java/JS interop is a pretty normal occurrence in Clojure when doing a certain type of code (like reading and writing certain binary files to disk, you'd probably reach for the Java Standard Library). For 99% you need no interop in Clojure. ClojureScript is a bit different as you often do need to access HTML elements or various singleton objects like js/window or js/document and have to use JS interop.
- oulu2006 7y ago
  I have to concur with you mate, I've used Clojure now for 6 years in 2 startups and I can almost count on 2 hands the number of times I've had to interop directly with Java classes to get something to work.
didibus 7y ago
Hum, that's one of my favorite things. Some JDK APIs/libs are quite well designed, and when they are, Clojure doesn't bother re-inventing the wheel, which is a great thing in my opinion.
DannyB2 7y ago
While I am an experienced Java developer, and took immediately to clojure, I don't think you deserved to be downvoted for expressing that experience. I can imagine if I were to learn a new lisp, that was hosted on a language I did not know, and various difficult things leaked through the abstraction making it more difficult for me to work. I might feel similarly.

rubyn00bie 7y ago

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 backend differ mostly just in the way that the different implementations access the host platform. The functional aspects of Clojure, especially the immutability and focus on referential transparency, ensure that source code is mostly split into chunks of highly portable code, with the host-interop conveniently put aside in its own sections. You can move code between frontend and backend at your leisure. Is it really that good using Clojure across environments and runtimes? I ask because I tried all of this with Scala years ago (I loved the language) and Ruby to an extent, but it was pretty miserable or rather there was really no reward but more effort on my part. I.e. I'd spend more time annotating, bridging, and learning how to interact with the different runtime than I would writing actual feature code[1]. Or like what are the killer libraries everyone loves? Do they (libs/frameworks) support different clojure runtimes ("hosts?") outta the box? Is it easy to write "pure clojure" projects that work for any clojure project? The one I know about or have heard most about was Datatomic, which always sounded freakin' brilliant, but I don't fucks with non-free databases. Arcadia I just saw and it looks cool but, it also seems like a dumb mountain to climb, if that's how I wanted to start screwing around with Clojure. [1] Tools like Scala/ScalaJS and RubyMotion (back in the day, heh), were the reasons I ended up a polyglot. They're great tools, if you know the platform, if you don't, you're pretty much still fucked... but once you know the platform it's kind of hard to want to use them.

throw03172019 7y ago
I have been writing helper libs with our shared logic in Clojure (CLJC). It is pretty nice to have the same core on the frontend and backend. It is easy enough to use the conditionals to call a Java fn vs. Javascript for certain logic (I.e Dates, etc)
scarredwaits 7y ago
I can attest that full stack (server-browser) Clojure code sharing works very-very smoothly. I've been developing web applications like that for some time now, and apart from less context swithing (because it's the same language on both sides), sizeable parts of the code are cross-compiled to run both on the browser and the JVM with very little or no extra effort. Example 1: I'm using Clojure's Spec library for validation. There is code that is used on the browser to validate the input that users enter into forms, and the same exact code is used on the HTTP endpoints that are called when the user attempts to submit the form. Example 2: I'm using the Tongue library to provide client-side translations of the whole UI, but the same data files and library are used in some cases on the server to generate files that contain translated strings. Example 3: The web UI logic is written using pure data manipulation (thank the Re-frame library for that) and because of that we are able to unit test it on the JVM without having to go through the complecity of launching and driving a browser on our CI server.

svnpenn 7y ago

The situation with windows is weird. You have to run a powershell script to install. They should just offer a Zip or Exe like every other programming language. https://github.com/clojure/tools.deps.alpha/wiki/clj-on-Windows https://github.com/clojure/tools.deps.alpha/wiki/clj-on-Wind...

reitzensteinm 7y ago
tools.deps is in alpha - even as someone that uses Clojure on Windows, I think it's fair enough that they don't care about Windows just yet. Leiningen works great on Windows, and Boot is meant to as well (though I don't have first hand knowledge of that).
didibus 7y ago
You could try with: https://github.com/borkdude/deps.clj https://github.com/borkdude/deps.clj It replaces the powershell code with a Clojure based executable.
iLemming 7y ago
> The situation with windows is weird. Isn't it always? Basically anything that's not related to .NET has its warts in Windows. Erlang for example.
- pjmlp 7y ago
  Delphi, Python, Ruby, C++, Qt, Perl, nodejs, Java, Pharo/Smalltalk, Eiffel, Common Lisp, Ada do pretty well on Windows, without being .NET related.
  - iLemming 7y ago
    Funny, I'm probably getting old, but I do remember times when every single one of these had issues in Windows. Besides, all of them are much older than Clojure.

vemv 7y ago

My personal perspective (after 8 years clojuring, half of that professionally) is that Clojure keeps progressing, with ever better tools and ideas for getting stuff done, optimally. I remain optimistic. At the same time, it still fails at my "golden test": can I gather 5 random freelance engineers and get them to ship a project within a few months, wasting almost no billable time? I can (and have) with Ruby, Typescript. People can learn those on the go, being productive on day 3 or so. Clojure is still bit of a journey on itself, involving quite a lot of stuff to learn, and plenty of choices to make. That's not necessarily a bad thing, nor Clojure's "fault", but it's a real cost/risk that is still there. I do envision a future where the mainstream is ideologically closer to Clojure, and Clojure offers an (even) more polished set of tools than today. With that mutual proximity, Clojure could indeed eat the world.

ken 7y ago
Maybe I’m just dense, but I certainly have not been productive with any language on day 3. (Not even Ruby, which feels comfortable faster than most languages.) I sometimes felt productive that soon but I always end up having to rewrite once I learn the language fully. I’ve learned enough languages that I can spot “a person’s first program in X” now pretty easily.
- bcrosby95 7y ago
  Yeah, same. But it does help a lot having a professionally developed project with lots of high quality, real world examples of how to do things.
- vemv 7y ago
  My background is freelancing/consulting where it's not uncommon to gather diverse individuals to work on a greenfield project. There's an implicit assumption that all participants know a thing or two about programming, and accordingly are apt learners. So yes, on day 3 the code won't be perfect, neither on day 6 but after a few code reviews one can get stuff done. Personally I wouldn't be comfortable prescribing Clojure for such a project, in contrast to other languages which I've never coded in, but that I know that socially, today, work better.

yarrel 7y ago

The dealbreakers with Clojure for me are: 1. Weirdly irregular syntax. 2. Java import statements and Java error backtraces anywhere you want to do real work. 3. Inexcusable renaming and name collisions on basic Lisp functions. It's much, much less of a Lisp than Scheme and neither "but it's properly functional" nor "we fixed the tooling now" make that any less true or the language any more interesting for the use cases of using a Lisp or targeting the JVM with a more expressive language.

elwell 7y ago
> Weirdly irregular syntax. "Irregular syntax", as in not consistent with itself? Or, with historical LISPs? Some examples would be interesting.
iLemming 7y ago
Well, if you are building your own thing for your own amusement you can find that perfect, more expressive language and use it. For those of us who work for someone else - Clojure is a godsend. What's the alternative? No Lisp at all, and truly weirdly irregular syntax. Show me a single pragmatic and more or less popular language that's being used in the industry for building business apps that has nicer syntax than Clojure.
keymone 7y ago
1. Elaborate please 2. If you’re writing a wrapper to existing java lib maybe 3. Tough to be a particular lisp fanatic I guess.. Clojure helped me to get into lisp big time and all other lisps now feel clunky and inelegant.
akra 7y ago
I do agree that initial impressions are important for a language and "perceived" learning curve does make a difference. Things that scare people away initially do hurt adoption; things like Clojure's syntax and that it is a dynamic language on the JVM (i.e. how does that affect interop/performance/etc) all raise questions. Even if there are answers to these questions and justified reasons just like most sales pitches you've already lost a lot of people who have doubts and are already productive as they are. As an example I remember a presentation done some time ago where the presenter was showing code in F# and many non-technical people understood the code thinking it was a pseudo code at first (i.e. business stakeholders/BA types/etc). That was a win for them. If I showed F# and Clojure code side by side to an ex-coder manager as an example syntax I'm sure would matter and they often have a say in this decision. Buy-in is an important criteria in language selection for sure, as well as current skilled developers. If the pool of devs is small how easy it is to train people and get people wanting to be trained in it thinking it may be dead end skill with no jobs? I don't have that opinion personally but some dev's definitely do. Especially because jobs in these languages are scarce; if learning curve is small then it could be used even then. My cynicism shows marketing and perception of a tech stack are equally if not more important than other factors in tech selection in many companies. No one got fired for picking IBM or in this day and age Java?

Zelphyr 7y ago

What I want to know is where to find a Clojure and/or ClojureScript job. I got a taste of Clojure on a project late last year and became enamored with it. So much so that I would love to find a job where I can use it at least part of the time.

emmanueloga_ 7y ago
Try the #jobs channel of https://clojurians.slack.com/ https://clojurians.slack.com/

abrax3141 7y ago

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 programmers almost write immutably by default. The only (common) exception being hash tables, but you just don’t use them if you need more control.

_bxg1 7y ago
> 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: https://clojure.org/reference/transients https://clojure.org/reference/transients But they are really intended to be the exception, not the rule. Enforced immutability is a conscious choice you make to trade some performance for increased robustness. Also, compared to "immutability by convention", enforced immutability allows certain optimizations to be made that greatly decrease the wasted memory and allocation/deallocation that would occur if you naively cloned everything.
- abrax3141 7y ago
  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).
  - _bxg1 7y ago

abrax3141 7y ago

If you want fast startup times, just live in emacs, keeping multiple shells alive underneath. You can build yourself a whole clojure repl that just lives there all the time (startup once), and a bash or whatever you like as well.

justlexi93 7y ago

With GraalVM and a bit of exaggeration, it feels like the story only begins.

raz32dust 7y ago

I am not sure I buy into the argument that startup time is the hurdle to Clojure adoption. If that were the case, we would have at least seen more adoption for server use cases. Applying Occam's razor, I think Clojure is not popular for the same reason that common lisp is not popular - it is simply too hard. Functions and immutability are a more difficult abstraction to grasp compared to objects and procedures and mutable state. The overhead of finding quality talent is too high, and likely always will be because of this.

iLemming 7y ago
Clojure is not hard. It's just different. People immediately reject anything that's different. Just like when Fibonacci tried to convince people in 13th century to use indo-arabian numerals. I've seen people with no prior programming experience learning Clojure within a few days. And I've seen senior software developers struggling with it for months.

didibus 7y ago

For me, this article is spot on. I had been looking for a long time for my one language I can use for everything, and Clojure finally (just recently) got there. I can use it for scripting, writing command line apps, making backend services, writing web front-ends, making desktop applications with GUI, toying with generative art, doing data-science, making games, and more. It really has great reach, and its only getting better. Similarly, in terms of programming language, you can use it to explore many paradigms and innovative ideas, like CSP, logic, probabilistic, functional, meta, concurrent, dynamic, typed, contracts, data-flow, OOP, condition systems, monads, etc. All this keeps me interested and constantly learning. Never having to wait for features you miss or wish you had. I can see myself sticking with Clojure for a long time.

deleted 7y ago

[deleted]

shivekkhurana 7y ago

I shifted to writing Clojure full time in November 2017 and feel that I've improved greatly as a developer. Other languages taught me how to solve problems their way, Clojure taught me how to solve problems. My biggest hurdle while getting started was lack of Newbie friendly resources. And the language is kinda scary at first, specially if you are like me and have spent 5 years working with Python or JS. Dr. Fynmann said that if you want to get better at something, teach it. Following his advice I've published multiple articles [1][2][3][4] and given a talk about Clojure at a js conf [5]. The tooling is steadily improving. I don't think it will be as widespread as JS but I doubt if it aims to be. Clojure seems to attract a certain kind of developers anyways. --- [1] What I learned after writing Clojure for 424 days, straight https://krimlabs.com/blog/clojure-424-days https://krimlabs.com/blog/clojure-424-days Learn Clojure by building a drug dealer api [2] https://krimlabs.com/blog/clojure-drug-dealer-part-1 https://krimlabs.com/blog/clojure-drug-dealer-part-1 [3] https://krimlabs.com/blog/clojure-drug-dealer-part-2 https://krimlabs.com/blog/clojure-drug-dealer-part-2 [4] https://krimlabs.com/blog/clojure-drug-dealer-part-3 https://krimlabs.com/blog/clojure-drug-dealer-part-3 [5] If you are going to transpile JS, why not use ClojureScript? https://www.youtube.com/watch?v=Bs44qdAX5yo https://www.youtube.com/watch?v=Bs44qdAX5yo

ertucetin 7y ago

I think Clojure is going to be a spec for Lisp family in the future.

TurboHaskal 7y ago
You probably have only scratched the surface of Lisp if you really think that.

lincpa 7y ago

Clojure is a FP (Lisp) language based on RMDB theory, which is very suitable for dataflow and data-driven programming, so it is suitable for large-scale industrialized pipeline software development using Warehouse/Workshop Model model. https://github.com/linpengcheng/PurefunctionPipelineDataflow https://github.com/linpengcheng/PurefunctionPipelineDataflow

harperlee 7y ago
In the last ~18 months you have been /very/ energetic in promoting your theory here, I have some alerts since about a year and you are always popping up with the same link. Looking into your posting and commenting activity, there not much more. By now I guess that you have had enough exposure, but most of your comments and links to github have not sparkled a lot of interest or comment, and reception has been skeptical / lukewarm. Take this as just one datapoint but for me your insistent reposting is more noise than any other thing. If you really care about your theory that is cool and all, but may I suggest that you create something like some practical application examples in blog form, edit them thoroughly, and then post them as new topics, intead of polluting "related" conversations? That way you can better gauge what interests this community, and what not. By the way interleaving english and chinese such as in your repo README.md makes for an unpleasant read - better to separate both in two distinct documents. Best luck!
- lincpa 7y ago
  I noticed that you have not posted any useful technical comments in the last 100+ days. Sorry I didn't keep reading. In fact, this theory has been unprecedentedly hot recently. Star and traffic on github have risen sharply. On 2020-02-27, it was published by editor on reddit/devopsish, and other clojure communities. My theory is written for a few people who understand Chapter 2 of the "Code Complete" and can read it without reading other chapters, not for people who cannot understand Chapter 2 and focus on other chapters. So I have stated in the article: I will not write too many application examples or patterns. Because people who like to read such articles can't learn my theory.Because they lack imagination. ``` Imagination is more important than knowledge. The true sign of intelligence is not knowledge but imagination. Logic will get you from A to B, imagination will take you everywhere. ---- Albert Einstein ```

lincpa 7y ago

You need a well-organized linear pipeline system, this is "The Pure Function Pipeline Data Flow v3.0 with Warehouse / Workshop Model"

dang 7y ago
We detached this subthread from https://news.ycombinator.com/item?id=22462241 https://news.ycombinator.com/item?id=22462241.
engineeringwoke 7y ago
I hope you realize that this is complete nonsense to anyone that isn't part of your new "new" functional programming cult. It has almost no semantic meaning.
- hellofunk 7y ago
  I definitely saw nothing but sarcasm in the comment you are replying to. But now after looking at their other comments, I see it was not sarcasm. What an understatement for how messy functional programming can actually be.
  - engineeringwoke 7y ago
    I thought he was joking at first too and googled it to find out that he was in fact serious.
    - hellofunk 7y ago
      The quoted part reminds me of the fizzbuzz enterprise edition.
      - lincpa 7y ago
        Unfortunately, you treat the quote as a joke, and you have no ability to apply the quote at all.

ooooak 7y ago

1. In India, there are only ~100 jobs for a Clojure developer. That includes people just throwing in Clojure just to hire Java/Scala developer. 2. The learning curve for the Clojure. Clojure is simple but it's not easy by any means. 3. JVM interop if you are not a java developer it adds in more learning time. Most of the Clojure libraries use java heavily. It's a good thing but it adds in an extra layer of learning java's ecosystem. 4. Error messages. Even after years of Clojure. I still find it hard. 5. Documentation. Most of the packages I use don't have dedicated websites or good documentation. Even after all the issues. It's still worth the investment. I started working on a crawler for a freelance gig. we first built it using Golang. But due to its complexity and lots of bugs due to mutation. We ported it to Clojure and we are not looking back.

abhijat 7y ago
If you're in Pune or willing to shift, Helpshift uses clojure heavily.
Heliosmaster 7y ago
To be honest, I've done Clojure full-time (and exclusively) for 6 years now. I've almost never had to use Java interop. (With CLJS I did a little more JS interop). There were always wrappers written by somebody else that always did what I was looking for.

pgt 7y ago

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 https://github.com/carp-lang/Carp

simongray 7y ago
I thought about including this since I saw a talk about it once where the guy referenced Clojure, but they don't talk about Clojure at all in the README.md.
hcarvalhoalves 7y ago
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.

maehwasu 7y ago

As someone who uses Clojure a lot: It would be a lot better for language adoption if people would write more blog posts showing best practices for tooling, and less vague stuff about how awesome the language is. For example, the startup time thing is completely irrelevant if you use Emacs/VSCode with a standalone REPL that you connect to. It's non-trivial to set this up (more because of lack of consolidated info rather than time it takes), but it can easily be standardized across machines/envs (I Dockerize all projects in a simple way to allow team members to get started up with REPLs easily).

dragandj 7y ago
I totally agree, and that's why I am going to write a book about that: https://twitter.com/draganrocks/status/1226811229362147331 https://twitter.com/draganrocks/status/1226811229362147331 It has to wait until I wrap up the books that are currently in progress [1], but I expect to start this summer. [1] https://aiprobook.com https://aiprobook.com
- reilly3000 7y ago
  Random fan here: you DO rock. Thanks for your incredible work on making ML a first-class citizen in Clojure!
- maehwasu 7y ago
  Awesome. To put my own money when my mouth is, here is the bash script to start up a nREPL server in Docker: https://pastebin.com/PPmfDPyA https://pastebin.com/PPmfDPyA Here is the Dockerfile: https://pastebin.com/ymcUFdYT https://pastebin.com/ymcUFdYT And here is a sample deps.edn with the cider alias: https://pastebin.com/2a7vSFD7 https://pastebin.com/2a7vSFD7 To run this, you'd just put them all in one directory, run cider-up.sh, and then connect to the REPL with Cider in EMACS, or in Calva for VSCode with "Jack in to or Connect to REPL Server" and then "localhost" "4444"

sproketboy 7y ago

A Lisp that wants to spread cancer. FTFA

PaulRobinson 7y ago

I used to work at a large Clojure shop. I've moved on, and I've heard anecdotally that they are building most new stuff in Go. Barrier for entry and continued use in that limited experience was: - Learning curve for new developers is very high in comparison to other languages, so moving existing engineers over sucks. - Experienced Clojure developers want a job where they can "do Clojure", not necessarily because they're interested in the problems the business was created to solve, so hiring sucks. - Lots of conversations turn to "the Clojure way" to solve a problem rather than using industry accepted protocols, standards and tooling. I mean, OK, but this makes interacting with the rest of the World a bit sucky. - Most libraries never get to v1.0. Most people write 0.0.1 and may do some minor updates so you see it get to 0.0.5 and then it stays there. That's probably because it all 'just works', but it scares most devs when they see that and are about to bake it into their next release. - Deployment is a known quantity and the JVM is useful in this regard, but it doesn't have the pure simplicity that some other runtimes do. Clojure implementations in other runtimes (Joker, Clojerl, etc.), might help or hinder here. Startup time is a problem on CLI and desktop apps, sure. At my ex-employer, one server deployed app took several minutes to start and that had challenges. That was not - I think - the reason the team started to look elsewhere or the reason I'm more likely to pick up Ruby, Python, Go or Elixir for my next project. There are lots of rough edges like the ones I identify above - many of them cultural - that need to be smoothed out a little, I think. I look forward to functional methods becoming mainstream (again?), and Clojure could get there, so I wish the community luck.

thu2111 7y ago
Experienced Clojure developers want a job where they can "do Clojure" This seems like a common problem with functional languages in general. I've heard the same thing about Haskell, repeatedly. Such devs search out a place where a Haskeller/Clojurist got into a tech lead position and then all pile in, before you know it the team is spending half its time writing DSL compilers instead of adding features to the product. I look forward to functional methods becoming mainstream (again?) Has it ever been mainstream? AFAIK it's always been this basically strange offshoot of the family tree that split off a long time in the past. The core problems you highlight don't have any obvious solution, unfortunately. Learning materials can be improved but ultimately Lisp is very old and very unlike more modern languages. Libraries not getting to 1.0 is a symptom of a small community that derives more satisfaction from an intellectual exploration than having lots of users, combined with lack of commercially driven outcomes. Startup time I guess can be solved with technical solutions (and is being solved, as a side-effect of other projects elsewhere in the JVM ecosystem).

Jeaye 7y ago

For anyone struggling with dynamic typing in Clojure, thinking it's impossible to manage and even harder to build confidence in your code, please look at Spec and Orchestra. You can easily build predicative contracts for all of your data and know as soon as anything "goes wrong" in terms of your data shapes. I think everyone using Clojure JVM, ClojureScript, or Clojure CLR should be doing this.