37 ms·

Why Clojure?

248 points by jjgomo33 7y ago

ncmncm 7y ago
It just breaks my heart to see Uncle Bob seduced by a Java-family language right when C++ is getting increasingly fun. He suffered through the bad old days when C++ was only fast and powerful, and is now missing out on the good new days. I guess he's happy. At least he isn't touting Haskell. Bon Voyage, Bob! But somebody needs to break it to him that Lisp is not a functional language. Or, if it is, so is C++.
- avmich 7y ago
  > that Lisp is not a functional language. Or, if it is, so is C++ You're missing the point. Everybody can write Fortran in any language.
  - deleted 7y ago
    [deleted]
- deleted 7y ago
  [deleted]
- deleted 7y ago
  [deleted]
- 6thaccount2 7y ago
  Many lisps like Common Lisp are multi-paradigm (imperative, OO, functional). Some like Clojure are built on OO runtime and can call Java OO code, but in general heavily favor immutability and functional programming. So you're focusing on one sentence (that is arguably incorrect or only partly correct) and missing the intent of the article.
- puredanger 7y ago
  You can argue whether Lisp is a functional language, but Clojure certainly is. When written well, the bulk of your code will be pure functions taking and returning immutable data or passing around pure functions. https://clojure.org/about/functional_programming https://clojure.org/about/functional_programming
- kyberias 7y ago
  There is nothing "Java-family" about Clojure. Merely the run-time.
- dkersten 7y ago
  Clojure isn’t “Java family” any more than anything running on top if a C runtime is C family. Clojure is also a lot more if a functional programming language than Common Lisp is. I also disagree with you on C++. Cc+11 was a fantastic improvement, C++14 added some missing stuff — at this point I was sold and eagerly awaiting C++17 — but when 17 arrivd and when I saw what 20 adds... it has become so complex that I don’t understand it at all anymore. I used to scoff at the people who said C++ was too complex, but after ~18 years of using the language its now reached a point where I am no longer comfortable using it. I see code that uses C++17 and recently 20 and I have no idea what its doing anymore. I am no longer confident that I can write safe, non bug-ridden code in C++.
- iLemming 7y ago
  > But somebody needs to break it to him that Lisp is not a functional language Lisp is not a language at all. It's an idea. And if you grok the awesomeness of that idea you can make any kind of language using it: functional, OOP, relational, whatever. Bob is talking about Clojure. Clojure is a functional Lisp.
deleted 7y ago
[deleted]
cutler 7y ago
Clojure is by far the best programming language I've ever used. Rich Hickey's Sermons On The Mount changed the game of programming once and for all. With Clojure you could finally have your Lisp cake and eat it. Witness the sheer chutzpah of the guy when he basically told Ruby devs they were doing it wrong at Rails Conf in 2012 (https://www.youtube.com/watch?v=rI8tNMsozo0 https://www.youtube.com/watch?v=rI8tNMsozo0).
- noncoml 7y ago
  > by far the best programming language I've ever used Would love to hear why? What is that make Clojure such a good experience for you?
  - invalidOrTaken 7y ago
    Not the grandparent, but I realized the other day that I'm at nine years of clojure, so... What's made clojure so great, imo, is its unicorn status as a principled-yet-practical language. That "principled" part is not worthless---it means that a lot of great minds are drawn to it. Before react took over the world, clojure folks were already taking steps in that direction. A lot of other things. The "sequence" as a core abstraction is very powerful. Immutable data structures by default make functional programming perfomant and efficient. Speaking of data structures, data structure literals have spoiled me for other languages. After Java, especially. And none of this mentions clojure's lispiness. The ease of metaprogramming has allowed the community to build some of the best tooling out there, between CIDER for emacs, and Figwheel for the browser---oh, did I forget to mention clojurescript? Being able to reuse code on the front and backend is great for web applications. Clojure isn't "everything." I think I'd still benefit from learning Haskell, APL, and Forth, and I wouldn't mind knowing Ruby and js a bit better. And I'll probably be dragged back to Python and R if I keep doing maths. But if someone asked me which single language would probably do the most for them professionally, I'd say clojure. It's the language people start startups so they can use it.
    - amelius 7y ago
      What is GUI programming like in Clojure? What libraries exist, and what paradigms are used? E.g. is it more like React or is it more like Gtk/Qt?
cultofmetatron 7y ago
been jumping into clojure lately myself. after years of js fatigue I've been dying for a functional pairing to elixir on the backend. clojure is growing on me with its nice hot code reloading and macros. (babel is basicly an overgrown macro)
- Royalaid 7y ago
  Are you using Clojure or Clojurescript?
  - simongray 7y ago
    Sounds like ClojureScript since they're also saying they use Elixir on the backend.
avmich 7y ago
Having disagreed with Uncle Bob for years, now I'm starting to see some reasoning in his thoughts :) .
- tincholio 7y ago
  I still disagree with most of what he says. It worries me that he might try to impose "Uncle Bob's one true way" of doing Clojure on newcomers (and he has very good reach into the OO community)
- Jach 7y ago
  His book Clean Code is pretty good. Not in the sense that everything is agreeable in it (though some not so great programmers would benefit themselves and those around them from following it religiously) and a decent chunk of it is covered much more briefly with one chapter of The Practice of Programming but you can actually see the book as the artifact of a reasoning mind taking certain principles and articulating them. It lacks the usual polite qualifiers like "I think..." or "In my opinion..." or "Obviously not in all but in many cases generally speaking..." before every assertion which annoys some people. A fair number of his blog posts are like that too. Where Uncle Bob gets an unfair reputation is when people take things out of context from the larger works and (sometimes willfully) misinterpret them -- he doesn't say you should never ever have comments, for instance. Of course some of it is his own doing from occasional tweets that are by necessity of the medium less well thought out or conveyed.
mbrodersen 7y ago
I played around with Closure for a while to learn its cost/benefits. It is basically the love child of Lisp, Haskell and Java. So it introduces nothing new to the world. However it is certainly an interesting mix that some developers like. And Rich Hickey is an entertaining speaker/presenter/seller of Clojure. Even if you don't care about Closure, watch his talks on YouTube.
- sooheon 7y ago
  A good remix is something new.
- yakshaving_jgt 7y ago
  Clojure has nothing at all to do with Haskell. I can't think of two more opposed camps in programming.
  - vnorilo 7y ago
    Well, they have immutable data and persistent collections in common. Otherwise, agreed.
    - badsavage 7y ago
      yes, immutable data is a core value of Clojure. OP said no wrong, but think about it: Bitcoin also just stole the good parts from other software projects. Really practical inventions usually gather the best ideas from a field.
  - nimih 7y ago
    You're right, one is a language with a data-structure-centric approach to problem solving and an emphasis on pure transformations of immutable nested trees and lazy sequences, and the other one forces you to learn the word Monad. Edit: Joking aside, I do think you're right in terms of the ideological foundations and organizational structures of the two languages (clojure's emphasis on practicality, curation and evolution of the core library+language by a single BDFL, compared to haskell's origins in PL research and democratic design/maintainence), but in practice I think a lot of that comes out in the wash--dynamicism vs. static typing is definitely a huge difference, but there's a lot more to language design and the material practice of building software than whether your compiler reads type signatures, and I think that along those axes, especially when compared to other mainstream programing languages/ecosystems, clojure and haskell end up being pretty close.
SeriousM 7y ago
The most annoying phrase was "less code, less time, less...". Uncle Bob thought us to be explicit, help the reader understand the code and be verbose with the variables etc. Now he loves a Syntax that says #(25 % %)... Aaaalright, try to get a new company member understand a big code base with this massive oneliners. I doubt that this is the right language for enterprise projects.
- Cpoll 7y ago
  But that's not a contradiction. He wants you to be explicit with using the language, but if we speak the same language, the standard bits can be concise. So it's ok to say #(25 % %) because we both speak the same language and we know what it means, the intent is clear. But it's not okay to call your variables a, b, c, because that's meaning, not syntax, and I can't understand your intent from those variables. Massive one-liners probably fall into the latter, but I don't think he's advocating those.
- beders 7y ago
  Here's the fundamental thing to understand. Especially if you are new to Lisp: The lines are more concise. That also means you will need more time per line to read the code. Especially in Java, you can skip over so much boiler plate code, you kinda feel you are reading code fast. Not so with Lisp. You need some familiarity with it and you will need to adapt to a line just having more stuff to understand in it. Also, you can tune this using libraries as many things are a la carte.
fsloth 7y ago
Can anyone give a pro/cons analysis of a ML variant versus of a Lisp variant. Let's say F# versus Clojure? One of the general arguments in Lisp vs the world is that lisp is more concise. F# is really concise. It has datastructures as intrinsic part of the language syntax (just like Clojure, i.e in F# [|,,,|] is an array and in Clojure [...] is a vector, so more or less the same thing). Furthermore, the type inferences concierges the developer through the regular bureaucracy involved with strong type systems so effortlessly that you seldom notice it ... unless your code does not compile, in which case it's wrong somewhere and you need to fix it (which you needed to do anyway). Ok, so for the sake of the argument, let's say the syntax is equally light for F# and Clojure, and their support for immutability is in the same ballpark. And let's remove the argument "a type system is an encumbrance" because that will only lead to situation specific debates - one side will say that massive refactorings are a pita without types, and the other side responds that in Clojure you can use data schemas and should have unit tests anyway. And those discussions never lead anywhere conclusive. So, besides the above mentioned topics, is there anything general one can say of the distinctive advantages of these two languages in specific situations, including how their two different ecosystems and runtimes affect the calculus? I suppose it's extremely rare to have experts who have participated in any large scale industrial developments with both of the languages, but if there are, it would be really nice to hear their opinion. And the things I listed as "outside of the discussion" might actually be critical, who knows...
- 6thaccount2 7y ago
  Great question as I'm trying to make that decision myself. I love Lisp in general and the JVM is great and ubiquitous, so Clojure seems good. The reality is that every time I try to learn it, I get stuck learning leinegen, Emacs...etc, which is more than I have to deal with when using Python, so I skip it. Also, it seems like you get a .jar file and have to run it in conjunction with something like "Java -jar clojurefile.clj". I know that isn't too bad, but once I installed F#, I just put the compiler "fsc.exe" and the REPL/interpreter "fsi.exe" in my path and it is pretty simple now. I normally have an fsi window open for testing and write my full code in Notepad++ and then feed that to fsc.exe when I'm done and I get a little executable that is ~5kb. As long as a coworker has the .net runtime on their computer I can give that to them no problem. I'm sure Clojure can do something similar, but as I'm not a Java/JVM person I have no clue how.
jmnicolas 7y ago
Can someone explain me why they always (OK let's say almost always) use math formulas to show what you can do with a programming language ? I'm a desktop application programmer, not a mathematician. I don't need to print the first 25 squares of integers or Fibonacci whatever. In fact I think the hardest math I did at work was using modulo to get even and odd numbers ... Show me how you parse a csv file, how do you connect to webservices or retrieve data from a database, show me how to do a simple GUI, show me something useful for the common dev. I'll judge your ultimate programming language on these menial tasks that comprise 99.9% of my programming time.
- beders 7y ago
  Extracting two columns out of a excel sheet: (->> (d/load-workbook file "Questionnaire.xlsx") (d/select-sheet "Sheet1") (d/select-columns {:A :item :B :price}))
  - kgwxd 7y ago
    What is 'd'?
    - lastofus 7y ago
      It's an alias given to an imported module name. In Python it might be: import really_long_name as rln rln.foo()
      - kgwxd 7y ago
        I know that part :) What module is it referencing?
        sushimako 7y ago
        docjure https://github.com/mjul/docjure https://github.com/mjul/docjure
cannabis_sam 7y ago
Now we just need to wait 40 years for him to come around to the usefulness of static types..
- badsavage 7y ago
  Maybe stop smoking pot and try isomorphic DSLs instead.
kazinator 7y ago
> I saw the CARs and CDRs and CADDADDRs and thought it was all just academic baloney; interesting but not truly useful. car and cdr are accessors for the fields of a basic data-structure; nothing academic about that. The very origin of the names is rooted in systems work, not academics. (caddr x) provides a shorthand for (car (cdr (cdr x))), which is a pragmatic thing. You know, like #(* % %) instead of (lambda (x) (* x x)).
- jjtheblunt 7y ago
  i thought CAR and CDR were named after IBM (?) assembly language on an old machine. https://en.wikipedia.org/wiki/CAR_and_CDR https://en.wikipedia.org/wiki/CAR_and_CDR
  - kazinator 7y ago
    That's right; and that's a systems programming origin, not academics.
- kyberias 7y ago
  He didn't say they are academic, he said he thought they were academic.
jjtheblunt 7y ago
Amusingly, in an article about a lisp, he's got an unbalanced right parenthesis.
cakoose 7y ago
> Now let’s compare that to the equivalent Java program: public class SquaresOfIntegers { public static void main(String[] args) { for (int i=0; i<25; i++) System.out.println(i*i); } } > This is considerably more wordy, even if you don’t count the enclosing class. First of all, Java is famously verbose. Nobody is impressed when a language is more concise than Java. But even ignoring that, the comparison isn't representative. The enclosing class and 'main' function aren't needed for every additional fragment of code, so it probably shouldn't be counted here.
Bahamut 7y ago
My team owns a Clojure app, amongst a lot of other apps - my understanding is the current DRI (who inherited this app once the original one left for another org) doesn't like working in it though, and that has been the experience of other developers who have been recruited to the project over the past two years. Most developers I work with on a day to day basis don't have any interest in learning Clojure, and would rather work with Scala, the JVM language most heavily used within my org. One of my teammates also has production ClojureScript experience, and called it the worst of both worlds (Clojure and JavaScript). The primary problem is it doesn't try to abstract away the DOM, the most typically problematic part of working with JS. Just my own encounter with it so far - I haven't had the experience of writing production Clojure myself, but from what I've seen with the syntax, I'm still happily primarily writing JS so far when I'm not writing Python/Scala/etc.
- dkersten 7y ago
  > The primary problem is it doesn't try to abstract away the DOM Clojurescript has heavily bought into React. No cljs programmer I know deals with the DOM, but rather uses a React-based library to do it. Personally, I use re-frame and reagent and haven’t needed to interact with the DOM myself in years. I find working in cljs a LOT more productive and pleasant than working in Javascript (which I also use a lot, although if given the chouce I’d use cljs instead).
- kgwxd 7y ago
  Ive been doing various methods of js dev with tons of different framworks and traspilers for 20 years, nothing is more pleasant to work with than ClojureScript and re-frame once you learn it. It's the best of all the worlds, and the DOM is very abstracted away via React. State transition is a breeze with immutable data structs. Theres only 1 language to write, no JSX ugliness.
  - vga805 7y ago
    I have had a similar experience over the past 15 years. re-frame is absolutely wonderful.
deleted 7y ago
[deleted]
hsaliak 7y ago
This is all nice and exciting until you start to 1) Debug code, the high density of clojure code means that this is really painful. 2) Read code you wrote a while back. The high density of clojure code means that this is really painful.
- BWStearns 7y ago
  I find the high density makes debugging easier (up to a point) when combined with immutability. Being able to quickly stub/swap out a referentially transparent branch of the code while knowing you haven't more broadly changed behavior can be really useful. Also code density means you're more likely to be pointed to the line (or within a few lines) of where the actual problem is. This may be personal preference but I'd rather debug 1-5 dense line than 20-50 sparse lines given the equivalent code quality and functionality.
- nimih 7y ago
  Anecdotally, clojure seems to have a very nice subset of the language which is easy to debug and expressive enough to solve most problems effectively and naturally. What makes clojure exciting [for me] isn't the ability to build efficient transducers or create powerful custom syntax or build complicated value-level dispatch hierarchies (and in my experience, although they are cool and fun to use, all of these things certainly do make for code which is hard to understand and harder to debug), it's the comprehensive and easily-composable functional programming primitives, excellent built-in immutable data structures with intuitive shared interfaces, practical and (for the most part) straightforward approach to polymorphism, and sane approach to concurrency.
- kgwxd 7y ago
  High density?
  - hsaliak 7y ago
    you can accomplish a lot in a few lines of clojure
- vnorilo 7y ago
yakshaving_jgt 7y ago
Clojure is one of the better dynamic languages. The rub however is that GHC can check the consistency of my software faster than I or my colleagues will ever be able to, and programmer time is expensive. So that's why not Clojure.
- jaredklewis 7y ago
  I don’t think the only alternative to Haskell types is manually checking your program for consistency. For one thing, Clojure has type analysis: spec. Also, as pointed out in the article, you can also write tests.
  - yakshaving_jgt 7y ago
    Haskellers can and do write tests. +----------+-------+-------+ | Language | Tests | Types | +----------+-------+-------+ | Haskell | Yes | Yes | | Clojure | Yes | No | +----------+-------+-------+
    - jaredklewis 7y ago
      As I said above, clojure also has a type system. So your chart is yes for both features for both languages.
      - yakshaving_jgt 7y ago
        I had taken it for granted that when someone says a language "has types", they mean it is statically typed as opposed to dynamically typed. This is also made obvious by the idiomatic use of each technology. So, no. My little chart is correct.
    - badsavage 7y ago
      Clojure has something like an extendable type system called Spec. We can create our own types lol
ertucetin 7y ago
Here is my "Why Clojure?" blog post: https://medium.com/@ertu.ctn/why-clojure-seriously-why-9f5e6f24dc29 https://medium.com/@ertu.ctn/why-clojure-seriously-why-9f5e6...
kllrnohj 7y ago
The response to "but is it slow" is pretty disappointingly bad. > No. Clojure is not slow. Oh, look, it’s not C. It’s not assembler. If nanoseconds are your concern than you probably don’t want Clojure in your innermost loops. You also probably don’t want Java, or C#. But 99.9% of the software we write nowadays has no need of nanosecond performance. I’ve built a real time, GUI based, animated space war game using Clojure. I could keep the frame rates up in the high 20s even with hundreds of objects on the screen. Clojure is not slow. If you're going to respond to this question at least provide some comparison maybe. But otherwise that anecdote of "I could keep the frame rates up in the high 20s even with hundreds of objects on the screen." absolutely screams extremely slow. High 20s FPS with hundreds of objects is incredibly bad on the surface of things. Maybe it's closures fault, maybe it isn't and is instead the fault of whatever was doing the drawing. But it's not a good look either way if that's the only data point that can be provided. Similarly the IDE/dynamic type question seems to have missed the main downside of dynamic languages - lack of good IDE & other tooling support. How well are things auto-completed for me? How well does the IDE warn I've made a type error before I've gone through a long compile & test iteration loop? How well do linters or other things work, or is there some aspect of LISP that means this is just not an issue like it is in other languages?
- badsavage 7y ago
  Clojure's startup time is very slow compared to other languages, but we balance it with fully reloadable systems both on the backend or frontend. Otherwise the speed is almost identical to the speed of native Java and native Javascript. Except when you experience the power of lazy structures, then Clojure is faster than native code.
- kbd 7y ago
  The biggest thing keeping me from ever seriously learning Clojure is the JVM. Slow startup time means I'd never use Clojure for "scripts", and I certainly don't want to have to manage the JVM in production scenarios, so when would I use Clojure? If there was a native version that could produce static binaries like Go/Nim/Rust I'd be much more interested to learn it.
  - 7y ago
Qerub 7y ago
I might be damaged from years of Java, but my main imagined issue with Clojure is the lack of a component system. Call it OCaml functors or OOP classes, but instantiating a component with replaceable components as input is what I personally need for large scale programming. To make things more concrete, let's say you are writing an integration to another system using HTTP. On the surface you'll have functions like `fetch-album-information` and they will internally use a HTTP client. How do you handle TLS configuration, HTTP connection pooling, etc. and make the function testable and lifecycle-managed to allow clean shutdown? The easy answer is to parameterise the function with another function that takes care of all of that. But that function will need to come from somewhere and I imagine threading these kind of functions explicitly through your entire program will make it less than palatable. The alternative of using globals that can be replaced in testing carry all the usual problems that global variables have but seems to be what many settle with judging from Clojure code on GitHub. It seems like others are feeling this pain and have invented band-aid solutions like https://github.com/stuartsierra/component https://github.com/stuartsierra/component but this is something I think needs a first-class solution to encourage this kind of programming.
- hcarvalhoalves 7y ago
  Why is a library a "band-aid", and why is it necessary to have such feature in the core language?
  - yakshaving_jgt 7y ago
    I think it’s an argument about ergonomics. Threading state throughout your control flow is bad. Implicits like in Scala are bad. Global variables are worse. Something like a Reader monad is less bad.
- iLemming 7y ago
  What do you mean "the lack of a component system"? There's Mount, Component, Integrant. The last thing any language needs is to "encourage" some kind of programming. And Clojure is just that - it has small, stable core. The rest can be done with libraries.
mabbo 7y ago
> 1. Economy of expression Funny, this list is the same one I use as to why I'm so annoyed with Clojure right now. I inherited a mission-critical Clojure ML library my team uses for it's primary business goals. It was written 4 years ago by a research scientist- who quit 3 years ago. We know what it's supposed to do. We know that it seems to do the job well. We just can't understand the code well enough to be certain of what it's doing or how it's doing it. If this thing breaks or stops working, we're screwed. The problem is that the author, like most of us, found great joy in writing very few characters to express very big ideas. Clojure let him do that to an extreme degree. And I'm sure if you were sitting beside the author, with him explaining these dense expressions, you would be enlightened at the elegance and beauty of this language. Sadly, I was not. I'm sure Clojure is a lovely language. But it lets you write a Voynich manuscript that compiles.
- hcarvalhoalves 7y ago
  > ML library (...) It was written 4 years ago by a research scientist (...) Do you believe the language is the issue, been written by someone not trained on software engineering practices? Would you find untested (I'm betting this code you inherited lacks tests, from experience working w/ ML research code artifacts) verbose Algol-family code any easier to understand?
  - mabbo 7y ago
    You're not wrong, there are so many sins in the creation of this beast. A test would at least give me some purchase to grip the logic from. But we own lots of legacy stuff. It's only this one that gives me a headache. Honestly, I wish it had bugs or failed occasionally so I could justify replacing it!
  - jgalt212 7y ago
    Yes, agreed. That being said, there are languages (without naming names) that lend themselves to readability by others and those that don't.
- rlander 7y ago
  You should be annoyed with the less than ideal coding practices of your former colleague not the language.
acangiano 7y ago
Clojure is impressive. It's likely what I'd be focusing on if Elixir didn't exist.
LandR 7y ago
Has anyone done both elm and clojure script for Web work? Which did you prefer, which had the best tooling etc? I need to learn Web, as mucj as I don't want to, and love clojure and fp. Also figwheel looks awesome, but how hard is it to setup. I also think maybe to really get the best out of clojure script you also need to learn react?? I'm not sure this is the case with elm. Any other non js alternatives?
- iLemming 7y ago
  Elm's FFI is a bit painful compared to Clojurescript's. With Clojurescript you can target Node, browser or mobile (with something like Re-natal), but it truly shines when you have Clojure on the back-end. Clojure runs on JVM and many people (for all the wrong reasons) don't like that. You don't need to learn React to start using Re-agent or Re-frame. IMO among all alt-js languages, Clojurescript is the most practical and production-ready.
- yakshaving_jgt 7y ago
  I have about two years of professional experience working with ClojureScript, and about three years professional experience working with Elm. There’s almost no comparison. Elm compiles much more quickly. Elm produces much more performant code. Elm enables you to write software that works reliably much more quickly because type errors happen at compile time, rather than at runtime like in ClojureScript. ClojureScript’s error messages are at times incomprehensible. Elm’s error messages are best in class. Elm is far easier to learn than ClojureScript, and you’re right — you do need to know React if you’re writing a non-trivial ClojureScript application. Elm is criticised for not allowing a synchronous IO escape hatch. This is a pretty bad criticism I think. Being able to guarantee where effects won’t happen is a pretty great thing. Any effects work and/or JS interop can be done with ports. Ports work just fine. Elm is also criticised for denying the user a lot of “power features” like typeclasses. I find it mildly annoying sometimes that I don’t have everything I want, but I understand the trade-off. This is to make the language more accessible to your average JavaScript developer who has never tried anything from this family of languages. And I sure as hell don’t find it annoying enough to want to drop the type-checking compiler.
jodrellblank 7y ago
"Economy of Expression. [..] It requires fewer lines. It require fewer characters. It require fewer hours. It requires fewer mental gymnastics. So, here, for your entertainment, is the program that prints the first 25 squares of integers." (println (take 25 (map #(* % %) (range)))) And in APL[1], iota 25 is the first 25 integers, and feeding the same list into both sides of multiply squares the list, then turning it from a row to a column is tabling it. "Table the multiply-commute of the first 25 integers": ⍪×⍨⍳25 It's fewer lines, fewer characters, fewer hours, less syntax, less grammar, fewer symbols, fewer functions, less nesting, fewer mental gymnastics. Yet .. worse? Because those things you say both lead you towards codegolf, and implicitly have "fewer mental gymnastics" mean "I'm familiar with it already". [1] https://tryapl.org/?a=%u236A%D7%u2368%u237325&run https://tryapl.org/?a=%u236A%D7%u2368%u237325&run
namelosw 7y ago
A little bit off-topic, but I'm really confused that, why people on HN like Clojure and hate JavaScript? I didn't have any analytical data but it's very obvious already to anyone who read HN often. Are they possibly be the same crowd or just independent groups of people? For me, Clojure and JavaScript (at least for modern React community) are similar when it comes to usage: Dynamic typing with Hash-map centric modeling, use functions to compose thing but mostly without monadic patterns. The methodology in the Clojure community has an official name: "It's just data". This methodology works, and have it's own pros and cons. The obvious pro is people can write generic functions without poking hundreds of nominal types, interfaces and type classes. The only big difference I see is macro, but Clojure community also doesn't recommend writing macros unless you have to. There are also protocols and types, but they're not encouraged to poke around, it's still map-first recommended across the community. There are very few language communities follow the "It's just data patterns". From Java to Python to ML, people mostly modeling things with fixed-property model, instead of just untyped maps, unless they have to. For Lisps, I don't see map-centric approach is that stressed. Scheme might be still list-centric, Common Lisp is more diversed when it comes to approaches. Why people hate JavaScript so much? And why people speak highly of Clojure? It's just about inconsistent details, or about the whole design itself? Is there any important point I missed?
- beders 7y ago
  I don't think there's a lot of hate. It's just a quirky language that is at the heart of web application development. Based on its history, it has a lot of compromises. And not good ones. It could be vastly improved with a proper REPL-based development (i.e. think developing within the browser dev tools, kinda, sorta), but instead we are now going the other way: Adding types and a compiler and making it harder to mis-type things, but also harder to work as productively. I guess overall it has a few more ways on how you can shoot yourself in the foot compared to cljs ;)
- sbmassey 7y ago
  I don't hate any language myself, only the codebases I have to deal with, but Clojure is very different from Javascript in its support for immutability, such that if you want to update values you have to use atoms, agents etc. This goes a long way towards making up for the lack of typing when trying to understand peoples code. Some people also find the lack of random syntactical noise in Lisp style syntax preferable.
effnorwood 7y ago
Because you don’t know java
thelazydogsback 7y ago
I've been programming in Lisps on and off since the mid 80's, and I like Clojure the language, but in recent times as mostly as .Net programmer, I find the JVM and the surrounding Clojure tooling rather baroque. I find tutorials often cover Clojure/Lisp basics, but assume that you're coming from the Java world, so I had some difficulty getting what I consider basic workflows working as expected. If homoiconicity/macros/eval isn't an issue, I'm happy with F#/C# for the most part, but wouldn't mind having Clojure in the toolchest as well, but I'm not sure of the state and maintenance of Clojure.net.
- etatidem 7y ago
  You also have ClojureCLJ, although the tooling and libraries around aren't as nice as on the JVM (many libraries and even clojure.core functions directly interoperate with Java).
igouy 7y ago
>> Robert C. Martin: Smalltalk was also an image based language. Very few programmers have ever wrapped their minds around what that really meant. So, unfortunately, the language languished compared to all the text-file based languages. << Where is the evidence? Back in the 1990's IBM taught many of their consultants Smalltalk, and researched what made learning Smalltalk difficult — Smalltalk, although recognized as a good platform for rapid prototyping and software reuse, is widely regarded as difficult to learn. Unlike learning a procedural language like Pascal or C, learning Smalltalk is dominated by browsing and code comprehension. Learners of Smalltalk typically experience a long, slow start-up phase in which they become familiar with the class hierarchy and object-oriented computational model but do little meaningful work (our colleague Dave Smith calls this "climbing the Smalltalk mountain"). Programmers having to wrap their minds around the class hierarchy and OO was seen to be the problem.

248 points by jjgomo33 7y ago

It just breaks my heart to see Uncle Bob seduced by a Java-family language right when C++ is getting increasingly fun. He suffered through the bad old days when C++ was only fast and powerful, and is now missing out on the good new days. I guess he's happy. At least he isn't touting Haskell. Bon Voyage, Bob! But somebody needs to break it to him that Lisp is not a functional language. Or, if it is, so is C++.

avmich 7y ago
> that Lisp is not a functional language. Or, if it is, so is C++ You're missing the point. Everybody can write Fortran in any language.
- deleted 7y ago
  [deleted]
deleted 7y ago
[deleted]
deleted 7y ago
[deleted]
6thaccount2 7y ago
Many lisps like Common Lisp are multi-paradigm (imperative, OO, functional). Some like Clojure are built on OO runtime and can call Java OO code, but in general heavily favor immutability and functional programming. So you're focusing on one sentence (that is arguably incorrect or only partly correct) and missing the intent of the article.
puredanger 7y ago
You can argue whether Lisp is a functional language, but Clojure certainly is. When written well, the bulk of your code will be pure functions taking and returning immutable data or passing around pure functions. https://clojure.org/about/functional_programming https://clojure.org/about/functional_programming
kyberias 7y ago
There is nothing "Java-family" about Clojure. Merely the run-time.
dkersten 7y ago
Clojure isn’t “Java family” any more than anything running on top if a C runtime is C family. Clojure is also a lot more if a functional programming language than Common Lisp is. I also disagree with you on C++. Cc+11 was a fantastic improvement, C++14 added some missing stuff — at this point I was sold and eagerly awaiting C++17 — but when 17 arrivd and when I saw what 20 adds... it has become so complex that I don’t understand it at all anymore. I used to scoff at the people who said C++ was too complex, but after ~18 years of using the language its now reached a point where I am no longer comfortable using it. I see code that uses C++17 and recently 20 and I have no idea what its doing anymore. I am no longer confident that I can write safe, non bug-ridden code in C++.
iLemming 7y ago
> But somebody needs to break it to him that Lisp is not a functional language Lisp is not a language at all. It's an idea. And if you grok the awesomeness of that idea you can make any kind of language using it: functional, OOP, relational, whatever. Bob is talking about Clojure. Clojure is a functional Lisp.

deleted 7y ago

[deleted]

cutler 7y ago

Clojure is by far the best programming language I've ever used. Rich Hickey's Sermons On The Mount changed the game of programming once and for all. With Clojure you could finally have your Lisp cake and eat it. Witness the sheer chutzpah of the guy when he basically told Ruby devs they were doing it wrong at Rails Conf in 2012 (https://www.youtube.com/watch?v=rI8tNMsozo0 https://www.youtube.com/watch?v=rI8tNMsozo0).

noncoml 7y ago
> by far the best programming language I've ever used Would love to hear why? What is that make Clojure such a good experience for you?
- invalidOrTaken 7y ago
  Not the grandparent, but I realized the other day that I'm at nine years of clojure, so... What's made clojure so great, imo, is its unicorn status as a principled-yet-practical language. That "principled" part is not worthless---it means that a lot of great minds are drawn to it. Before react took over the world, clojure folks were already taking steps in that direction. A lot of other things. The "sequence" as a core abstraction is very powerful. Immutable data structures by default make functional programming perfomant and efficient. Speaking of data structures, data structure literals have spoiled me for other languages. After Java, especially. And none of this mentions clojure's lispiness. The ease of metaprogramming has allowed the community to build some of the best tooling out there, between CIDER for emacs, and Figwheel for the browser---oh, did I forget to mention clojurescript? Being able to reuse code on the front and backend is great for web applications. Clojure isn't "everything." I think I'd still benefit from learning Haskell, APL, and Forth, and I wouldn't mind knowing Ruby and js a bit better. And I'll probably be dragged back to Python and R if I keep doing maths. But if someone asked me which single language would probably do the most for them professionally, I'd say clojure. It's the language people start startups so they can use it.
  - amelius 7y ago
    What is GUI programming like in Clojure? What libraries exist, and what paradigms are used? E.g. is it more like React or is it more like Gtk/Qt?

cultofmetatron 7y ago

been jumping into clojure lately myself. after years of js fatigue I've been dying for a functional pairing to elixir on the backend. clojure is growing on me with its nice hot code reloading and macros. (babel is basicly an overgrown macro)

Royalaid 7y ago
Are you using Clojure or Clojurescript?
- simongray 7y ago
  Sounds like ClojureScript since they're also saying they use Elixir on the backend.

avmich 7y ago

Having disagreed with Uncle Bob for years, now I'm starting to see some reasoning in his thoughts :) .

tincholio 7y ago
I still disagree with most of what he says. It worries me that he might try to impose "Uncle Bob's one true way" of doing Clojure on newcomers (and he has very good reach into the OO community)
Jach 7y ago
His book Clean Code is pretty good. Not in the sense that everything is agreeable in it (though some not so great programmers would benefit themselves and those around them from following it religiously) and a decent chunk of it is covered much more briefly with one chapter of The Practice of Programming but you can actually see the book as the artifact of a reasoning mind taking certain principles and articulating them. It lacks the usual polite qualifiers like "I think..." or "In my opinion..." or "Obviously not in all but in many cases generally speaking..." before every assertion which annoys some people. A fair number of his blog posts are like that too. Where Uncle Bob gets an unfair reputation is when people take things out of context from the larger works and (sometimes willfully) misinterpret them -- he doesn't say you should never ever have comments, for instance. Of course some of it is his own doing from occasional tweets that are by necessity of the medium less well thought out or conveyed.

mbrodersen 7y ago

I played around with Closure for a while to learn its cost/benefits. It is basically the love child of Lisp, Haskell and Java. So it introduces nothing new to the world. However it is certainly an interesting mix that some developers like. And Rich Hickey is an entertaining speaker/presenter/seller of Clojure. Even if you don't care about Closure, watch his talks on YouTube.

sooheon 7y ago
A good remix is something new.
yakshaving_jgt 7y ago
Clojure has nothing at all to do with Haskell. I can't think of two more opposed camps in programming.
- vnorilo 7y ago
  Well, they have immutable data and persistent collections in common. Otherwise, agreed.
  - badsavage 7y ago
    yes, immutable data is a core value of Clojure. OP said no wrong, but think about it: Bitcoin also just stole the good parts from other software projects. Really practical inventions usually gather the best ideas from a field.
- nimih 7y ago
  You're right, one is a language with a data-structure-centric approach to problem solving and an emphasis on pure transformations of immutable nested trees and lazy sequences, and the other one forces you to learn the word Monad. Edit: Joking aside, I do think you're right in terms of the ideological foundations and organizational structures of the two languages (clojure's emphasis on practicality, curation and evolution of the core library+language by a single BDFL, compared to haskell's origins in PL research and democratic design/maintainence), but in practice I think a lot of that comes out in the wash--dynamicism vs. static typing is definitely a huge difference, but there's a lot more to language design and the material practice of building software than whether your compiler reads type signatures, and I think that along those axes, especially when compared to other mainstream programing languages/ecosystems, clojure and haskell end up being pretty close.

SeriousM 7y ago

The most annoying phrase was "less code, less time, less...". Uncle Bob thought us to be explicit, help the reader understand the code and be verbose with the variables etc. Now he loves a Syntax that says #(25 % %)... Aaaalright, try to get a new company member understand a big code base with this massive oneliners. I doubt that this is the right language for enterprise projects.

Cpoll 7y ago
But that's not a contradiction. He wants you to be explicit with using the language, but if we speak the same language, the standard bits can be concise. So it's ok to say #(25 % %) because we both speak the same language and we know what it means, the intent is clear. But it's not okay to call your variables a, b, c, because that's meaning, not syntax, and I can't understand your intent from those variables. Massive one-liners probably fall into the latter, but I don't think he's advocating those.
beders 7y ago
Here's the fundamental thing to understand. Especially if you are new to Lisp: The lines are more concise. That also means you will need more time per line to read the code. Especially in Java, you can skip over so much boiler plate code, you kinda feel you are reading code fast. Not so with Lisp. You need some familiarity with it and you will need to adapt to a line just having more stuff to understand in it. Also, you can tune this using libraries as many things are a la carte.

fsloth 7y ago

Can anyone give a pro/cons analysis of a ML variant versus of a Lisp variant. Let's say F# versus Clojure? One of the general arguments in Lisp vs the world is that lisp is more concise. F# is really concise. It has datastructures as intrinsic part of the language syntax (just like Clojure, i.e in F# [|,,,|] is an array and in Clojure [...] is a vector, so more or less the same thing). Furthermore, the type inferences concierges the developer through the regular bureaucracy involved with strong type systems so effortlessly that you seldom notice it ... unless your code does not compile, in which case it's wrong somewhere and you need to fix it (which you needed to do anyway). Ok, so for the sake of the argument, let's say the syntax is equally light for F# and Clojure, and their support for immutability is in the same ballpark. And let's remove the argument "a type system is an encumbrance" because that will only lead to situation specific debates - one side will say that massive refactorings are a pita without types, and the other side responds that in Clojure you can use data schemas and should have unit tests anyway. And those discussions never lead anywhere conclusive. So, besides the above mentioned topics, is there anything general one can say of the distinctive advantages of these two languages in specific situations, including how their two different ecosystems and runtimes affect the calculus? I suppose it's extremely rare to have experts who have participated in any large scale industrial developments with both of the languages, but if there are, it would be really nice to hear their opinion. And the things I listed as "outside of the discussion" might actually be critical, who knows...

6thaccount2 7y ago
Great question as I'm trying to make that decision myself. I love Lisp in general and the JVM is great and ubiquitous, so Clojure seems good. The reality is that every time I try to learn it, I get stuck learning leinegen, Emacs...etc, which is more than I have to deal with when using Python, so I skip it. Also, it seems like you get a .jar file and have to run it in conjunction with something like "Java -jar clojurefile.clj". I know that isn't too bad, but once I installed F#, I just put the compiler "fsc.exe" and the REPL/interpreter "fsi.exe" in my path and it is pretty simple now. I normally have an fsi window open for testing and write my full code in Notepad++ and then feed that to fsc.exe when I'm done and I get a little executable that is ~5kb. As long as a coworker has the .net runtime on their computer I can give that to them no problem. I'm sure Clojure can do something similar, but as I'm not a Java/JVM person I have no clue how.

jmnicolas 7y ago

Can someone explain me why they always (OK let's say almost always) use math formulas to show what you can do with a programming language ? I'm a desktop application programmer, not a mathematician. I don't need to print the first 25 squares of integers or Fibonacci whatever. In fact I think the hardest math I did at work was using modulo to get even and odd numbers ... Show me how you parse a csv file, how do you connect to webservices or retrieve data from a database, show me how to do a simple GUI, show me something useful for the common dev. I'll judge your ultimate programming language on these menial tasks that comprise 99.9% of my programming time.

beders 7y ago
Extracting two columns out of a excel sheet: (->> (d/load-workbook file "Questionnaire.xlsx") (d/select-sheet "Sheet1") (d/select-columns {:A :item :B :price}))
- kgwxd 7y ago
  What is 'd'?
  - lastofus 7y ago
    It's an alias given to an imported module name. In Python it might be: import really_long_name as rln rln.foo()
    - kgwxd 7y ago
      I know that part :) What module is it referencing?
      - sushimako 7y ago
        docjure https://github.com/mjul/docjure https://github.com/mjul/docjure

cannabis_sam 7y ago

Now we just need to wait 40 years for him to come around to the usefulness of static types..

badsavage 7y ago
Maybe stop smoking pot and try isomorphic DSLs instead.

kazinator 7y ago

> I saw the CARs and CDRs and CADDADDRs and thought it was all just academic baloney; interesting but not truly useful. car and cdr are accessors for the fields of a basic data-structure; nothing academic about that. The very origin of the names is rooted in systems work, not academics. (caddr x) provides a shorthand for (car (cdr (cdr x))), which is a pragmatic thing. You know, like #(* % %) instead of (lambda (x) (* x x)).

jjtheblunt 7y ago
i thought CAR and CDR were named after IBM (?) assembly language on an old machine. https://en.wikipedia.org/wiki/CAR_and_CDR https://en.wikipedia.org/wiki/CAR_and_CDR
- kazinator 7y ago
  That's right; and that's a systems programming origin, not academics.
kyberias 7y ago
He didn't say they are academic, he said he thought they were academic.

jjtheblunt 7y ago

Amusingly, in an article about a lisp, he's got an unbalanced right parenthesis.

cakoose 7y ago

> Now let’s compare that to the equivalent Java program: public class SquaresOfIntegers { public static void main(String[] args) { for (int i=0; i<25; i++) System.out.println(i*i); } } > This is considerably more wordy, even if you don’t count the enclosing class. First of all, Java is famously verbose. Nobody is impressed when a language is more concise than Java. But even ignoring that, the comparison isn't representative. The enclosing class and 'main' function aren't needed for every additional fragment of code, so it probably shouldn't be counted here.

Bahamut 7y ago

My team owns a Clojure app, amongst a lot of other apps - my understanding is the current DRI (who inherited this app once the original one left for another org) doesn't like working in it though, and that has been the experience of other developers who have been recruited to the project over the past two years. Most developers I work with on a day to day basis don't have any interest in learning Clojure, and would rather work with Scala, the JVM language most heavily used within my org. One of my teammates also has production ClojureScript experience, and called it the worst of both worlds (Clojure and JavaScript). The primary problem is it doesn't try to abstract away the DOM, the most typically problematic part of working with JS. Just my own encounter with it so far - I haven't had the experience of writing production Clojure myself, but from what I've seen with the syntax, I'm still happily primarily writing JS so far when I'm not writing Python/Scala/etc.

dkersten 7y ago
> The primary problem is it doesn't try to abstract away the DOM Clojurescript has heavily bought into React. No cljs programmer I know deals with the DOM, but rather uses a React-based library to do it. Personally, I use re-frame and reagent and haven’t needed to interact with the DOM myself in years. I find working in cljs a LOT more productive and pleasant than working in Javascript (which I also use a lot, although if given the chouce I’d use cljs instead).
kgwxd 7y ago
Ive been doing various methods of js dev with tons of different framworks and traspilers for 20 years, nothing is more pleasant to work with than ClojureScript and re-frame once you learn it. It's the best of all the worlds, and the DOM is very abstracted away via React. State transition is a breeze with immutable data structs. Theres only 1 language to write, no JSX ugliness.
- vga805 7y ago
  I have had a similar experience over the past 15 years. re-frame is absolutely wonderful.

deleted 7y ago

[deleted]

hsaliak 7y ago

This is all nice and exciting until you start to 1) Debug code, the high density of clojure code means that this is really painful. 2) Read code you wrote a while back. The high density of clojure code means that this is really painful.

BWStearns 7y ago
I find the high density makes debugging easier (up to a point) when combined with immutability. Being able to quickly stub/swap out a referentially transparent branch of the code while knowing you haven't more broadly changed behavior can be really useful. Also code density means you're more likely to be pointed to the line (or within a few lines) of where the actual problem is. This may be personal preference but I'd rather debug 1-5 dense line than 20-50 sparse lines given the equivalent code quality and functionality.
nimih 7y ago
Anecdotally, clojure seems to have a very nice subset of the language which is easy to debug and expressive enough to solve most problems effectively and naturally. What makes clojure exciting [for me] isn't the ability to build efficient transducers or create powerful custom syntax or build complicated value-level dispatch hierarchies (and in my experience, although they are cool and fun to use, all of these things certainly do make for code which is hard to understand and harder to debug), it's the comprehensive and easily-composable functional programming primitives, excellent built-in immutable data structures with intuitive shared interfaces, practical and (for the most part) straightforward approach to polymorphism, and sane approach to concurrency.
kgwxd 7y ago
High density?
- hsaliak 7y ago
  you can accomplish a lot in a few lines of clojure
vnorilo 7y ago

yakshaving_jgt 7y ago

Clojure is one of the better dynamic languages. The rub however is that GHC can check the consistency of my software faster than I or my colleagues will ever be able to, and programmer time is expensive. So that's why not Clojure.

jaredklewis 7y ago
I don’t think the only alternative to Haskell types is manually checking your program for consistency. For one thing, Clojure has type analysis: spec. Also, as pointed out in the article, you can also write tests.
- yakshaving_jgt 7y ago
  Haskellers can and do write tests. +----------+-------+-------+ | Language | Tests | Types | +----------+-------+-------+ | Haskell | Yes | Yes | | Clojure | Yes | No | +----------+-------+-------+
  - jaredklewis 7y ago
    As I said above, clojure also has a type system. So your chart is yes for both features for both languages.
    - yakshaving_jgt 7y ago
      I had taken it for granted that when someone says a language "has types", they mean it is statically typed as opposed to dynamically typed. This is also made obvious by the idiomatic use of each technology. So, no. My little chart is correct.
  - badsavage 7y ago
    Clojure has something like an extendable type system called Spec. We can create our own types lol

ertucetin 7y ago

Here is my "Why Clojure?" blog post: https://medium.com/@ertu.ctn/why-clojure-seriously-why-9f5e6f24dc29 https://medium.com/@ertu.ctn/why-clojure-seriously-why-9f5e6...

kllrnohj 7y ago

The response to "but is it slow" is pretty disappointingly bad. > No. Clojure is not slow. Oh, look, it’s not C. It’s not assembler. If nanoseconds are your concern than you probably don’t want Clojure in your innermost loops. You also probably don’t want Java, or C#. But 99.9% of the software we write nowadays has no need of nanosecond performance. I’ve built a real time, GUI based, animated space war game using Clojure. I could keep the frame rates up in the high 20s even with hundreds of objects on the screen. Clojure is not slow. If you're going to respond to this question at least provide some comparison maybe. But otherwise that anecdote of "I could keep the frame rates up in the high 20s even with hundreds of objects on the screen." absolutely screams extremely slow. High 20s FPS with hundreds of objects is incredibly bad on the surface of things. Maybe it's closures fault, maybe it isn't and is instead the fault of whatever was doing the drawing. But it's not a good look either way if that's the only data point that can be provided. Similarly the IDE/dynamic type question seems to have missed the main downside of dynamic languages - lack of good IDE & other tooling support. How well are things auto-completed for me? How well does the IDE warn I've made a type error before I've gone through a long compile & test iteration loop? How well do linters or other things work, or is there some aspect of LISP that means this is just not an issue like it is in other languages?

badsavage 7y ago
Clojure's startup time is very slow compared to other languages, but we balance it with fully reloadable systems both on the backend or frontend. Otherwise the speed is almost identical to the speed of native Java and native Javascript. Except when you experience the power of lazy structures, then Clojure is faster than native code.
kbd 7y ago
The biggest thing keeping me from ever seriously learning Clojure is the JVM. Slow startup time means I'd never use Clojure for "scripts", and I certainly don't want to have to manage the JVM in production scenarios, so when would I use Clojure? If there was a native version that could produce static binaries like Go/Nim/Rust I'd be much more interested to learn it.
- 7y ago

Qerub 7y ago

I might be damaged from years of Java, but my main imagined issue with Clojure is the lack of a component system. Call it OCaml functors or OOP classes, but instantiating a component with replaceable components as input is what I personally need for large scale programming. To make things more concrete, let's say you are writing an integration to another system using HTTP. On the surface you'll have functions like `fetch-album-information` and they will internally use a HTTP client. How do you handle TLS configuration, HTTP connection pooling, etc. and make the function testable and lifecycle-managed to allow clean shutdown? The easy answer is to parameterise the function with another function that takes care of all of that. But that function will need to come from somewhere and I imagine threading these kind of functions explicitly through your entire program will make it less than palatable. The alternative of using globals that can be replaced in testing carry all the usual problems that global variables have but seems to be what many settle with judging from Clojure code on GitHub. It seems like others are feeling this pain and have invented band-aid solutions like https://github.com/stuartsierra/component https://github.com/stuartsierra/component but this is something I think needs a first-class solution to encourage this kind of programming.

hcarvalhoalves 7y ago
Why is a library a "band-aid", and why is it necessary to have such feature in the core language?
- yakshaving_jgt 7y ago
  I think it’s an argument about ergonomics. Threading state throughout your control flow is bad. Implicits like in Scala are bad. Global variables are worse. Something like a Reader monad is less bad.
iLemming 7y ago
What do you mean "the lack of a component system"? There's Mount, Component, Integrant. The last thing any language needs is to "encourage" some kind of programming. And Clojure is just that - it has small, stable core. The rest can be done with libraries.

mabbo 7y ago

> 1. Economy of expression Funny, this list is the same one I use as to why I'm so annoyed with Clojure right now. I inherited a mission-critical Clojure ML library my team uses for it's primary business goals. It was written 4 years ago by a research scientist- who quit 3 years ago. We know what it's supposed to do. We know that it seems to do the job well. We just can't understand the code well enough to be certain of what it's doing or how it's doing it. If this thing breaks or stops working, we're screwed. The problem is that the author, like most of us, found great joy in writing very few characters to express very big ideas. Clojure let him do that to an extreme degree. And I'm sure if you were sitting beside the author, with him explaining these dense expressions, you would be enlightened at the elegance and beauty of this language. Sadly, I was not. I'm sure Clojure is a lovely language. But it lets you write a Voynich manuscript that compiles.

hcarvalhoalves 7y ago
> ML library (...) It was written 4 years ago by a research scientist (...) Do you believe the language is the issue, been written by someone not trained on software engineering practices? Would you find untested (I'm betting this code you inherited lacks tests, from experience working w/ ML research code artifacts) verbose Algol-family code any easier to understand?
- mabbo 7y ago
  You're not wrong, there are so many sins in the creation of this beast. A test would at least give me some purchase to grip the logic from. But we own lots of legacy stuff. It's only this one that gives me a headache. Honestly, I wish it had bugs or failed occasionally so I could justify replacing it!
- jgalt212 7y ago
  Yes, agreed. That being said, there are languages (without naming names) that lend themselves to readability by others and those that don't.
rlander 7y ago
You should be annoyed with the less than ideal coding practices of your former colleague not the language.

acangiano 7y ago

Clojure is impressive. It's likely what I'd be focusing on if Elixir didn't exist.

LandR 7y ago

Has anyone done both elm and clojure script for Web work? Which did you prefer, which had the best tooling etc? I need to learn Web, as mucj as I don't want to, and love clojure and fp. Also figwheel looks awesome, but how hard is it to setup. I also think maybe to really get the best out of clojure script you also need to learn react?? I'm not sure this is the case with elm. Any other non js alternatives?

iLemming 7y ago
Elm's FFI is a bit painful compared to Clojurescript's. With Clojurescript you can target Node, browser or mobile (with something like Re-natal), but it truly shines when you have Clojure on the back-end. Clojure runs on JVM and many people (for all the wrong reasons) don't like that. You don't need to learn React to start using Re-agent or Re-frame. IMO among all alt-js languages, Clojurescript is the most practical and production-ready.
yakshaving_jgt 7y ago
I have about two years of professional experience working with ClojureScript, and about three years professional experience working with Elm. There’s almost no comparison. Elm compiles much more quickly. Elm produces much more performant code. Elm enables you to write software that works reliably much more quickly because type errors happen at compile time, rather than at runtime like in ClojureScript. ClojureScript’s error messages are at times incomprehensible. Elm’s error messages are best in class. Elm is far easier to learn than ClojureScript, and you’re right — you do need to know React if you’re writing a non-trivial ClojureScript application. Elm is criticised for not allowing a synchronous IO escape hatch. This is a pretty bad criticism I think. Being able to guarantee where effects won’t happen is a pretty great thing. Any effects work and/or JS interop can be done with ports. Ports work just fine. Elm is also criticised for denying the user a lot of “power features” like typeclasses. I find it mildly annoying sometimes that I don’t have everything I want, but I understand the trade-off. This is to make the language more accessible to your average JavaScript developer who has never tried anything from this family of languages. And I sure as hell don’t find it annoying enough to want to drop the type-checking compiler.

jodrellblank 7y ago

"Economy of Expression. [..] It requires fewer lines. It require fewer characters. It require fewer hours. It requires fewer mental gymnastics. So, here, for your entertainment, is the program that prints the first 25 squares of integers." (println (take 25 (map #(* % %) (range)))) And in APL[1], iota 25 is the first 25 integers, and feeding the same list into both sides of multiply squares the list, then turning it from a row to a column is tabling it. "Table the multiply-commute of the first 25 integers": ⍪×⍨⍳25 It's fewer lines, fewer characters, fewer hours, less syntax, less grammar, fewer symbols, fewer functions, less nesting, fewer mental gymnastics. Yet .. worse? Because those things you say both lead you towards codegolf, and implicitly have "fewer mental gymnastics" mean "I'm familiar with it already". [1] https://tryapl.org/?a=%u236A%D7%u2368%u237325&run https://tryapl.org/?a=%u236A%D7%u2368%u237325&run

namelosw 7y ago

A little bit off-topic, but I'm really confused that, why people on HN like Clojure and hate JavaScript? I didn't have any analytical data but it's very obvious already to anyone who read HN often. Are they possibly be the same crowd or just independent groups of people? For me, Clojure and JavaScript (at least for modern React community) are similar when it comes to usage: Dynamic typing with Hash-map centric modeling, use functions to compose thing but mostly without monadic patterns. The methodology in the Clojure community has an official name: "It's just data". This methodology works, and have it's own pros and cons. The obvious pro is people can write generic functions without poking hundreds of nominal types, interfaces and type classes. The only big difference I see is macro, but Clojure community also doesn't recommend writing macros unless you have to. There are also protocols and types, but they're not encouraged to poke around, it's still map-first recommended across the community. There are very few language communities follow the "It's just data patterns". From Java to Python to ML, people mostly modeling things with fixed-property model, instead of just untyped maps, unless they have to. For Lisps, I don't see map-centric approach is that stressed. Scheme might be still list-centric, Common Lisp is more diversed when it comes to approaches. Why people hate JavaScript so much? And why people speak highly of Clojure? It's just about inconsistent details, or about the whole design itself? Is there any important point I missed?

beders 7y ago
I don't think there's a lot of hate. It's just a quirky language that is at the heart of web application development. Based on its history, it has a lot of compromises. And not good ones. It could be vastly improved with a proper REPL-based development (i.e. think developing within the browser dev tools, kinda, sorta), but instead we are now going the other way: Adding types and a compiler and making it harder to mis-type things, but also harder to work as productively. I guess overall it has a few more ways on how you can shoot yourself in the foot compared to cljs ;)
sbmassey 7y ago
I don't hate any language myself, only the codebases I have to deal with, but Clojure is very different from Javascript in its support for immutability, such that if you want to update values you have to use atoms, agents etc. This goes a long way towards making up for the lack of typing when trying to understand peoples code. Some people also find the lack of random syntactical noise in Lisp style syntax preferable.

effnorwood 7y ago

Because you don’t know java

thelazydogsback 7y ago

I've been programming in Lisps on and off since the mid 80's, and I like Clojure the language, but in recent times as mostly as .Net programmer, I find the JVM and the surrounding Clojure tooling rather baroque. I find tutorials often cover Clojure/Lisp basics, but assume that you're coming from the Java world, so I had some difficulty getting what I consider basic workflows working as expected. If homoiconicity/macros/eval isn't an issue, I'm happy with F#/C# for the most part, but wouldn't mind having Clojure in the toolchest as well, but I'm not sure of the state and maintenance of Clojure.net.

etatidem 7y ago
You also have ClojureCLJ, although the tooling and libraries around aren't as nice as on the JVM (many libraries and even clojure.core functions directly interoperate with Java).

igouy 7y ago

>> Robert C. Martin: Smalltalk was also an image based language. Very few programmers have ever wrapped their minds around what that really meant. So, unfortunately, the language languished compared to all the text-file based languages. << Where is the evidence? Back in the 1990's IBM taught many of their consultants Smalltalk, and researched what made learning Smalltalk difficult — Smalltalk, although recognized as a good platform for rapid prototyping and software reuse, is widely regarded as difficult to learn. Unlike learning a procedural language like Pascal or C, learning Smalltalk is dominated by browsing and code comprehension. Learners of Smalltalk typically experience a long, slow start-up phase in which they become familiar with the class hierarchy and object-oriented computational model but do little meaningful work (our colleague Dave Smith calls this "climbing the Smalltalk mountain"). Programmers having to wrap their minds around the class hierarchy and OO was seen to be the problem.