[HN Gopher] The Future of Clojure
___________________________________________________________________
The Future of Clojure
Author : simonpure
Score : 151 points
Date : 2020-12-10 14:09 UTC (8 hours ago)
(HTM) web link (www.thoughtworks.com)
(TXT) w3m dump (www.thoughtworks.com)
| keithasaurus wrote:
| Having worked at a company with a large Clojure codebase, I just
| don't see Clojure growing. It's not well-suited to large
| projects. The dynamic-ness of it and awkward parts of the
| language (macros, protocols, ambiguity of laziness, etc) end up
| inevitably getting used in ways they aren't intended.
|
| The idea that you need "wise programmers" is a really big
| problem. People leave, institutional knowledge is lost, and then
| the code archaeology is just more difficult than it would be
| where types exist as guard rails.
|
| I think Clojure looks favorable in comparison to Java still
| (though perhaps less so). But with Kotlin and Scala as mature
| alternatives -- and Clojure without a real niche -- it's not what
| I would reach for.
| gorjusborg wrote:
| Kotlin and Scala are closer to Java, so it makes sense it would
| be an easier sell to Java shops.
|
| I don't use Clojure professionally, and have often wondered how
| well it holds up in companies where avg tenure of an engineer
| is 2-3 years.
|
| I guess that assumes that a tenure of 2-3 years is not a
| problem in itself.
| mumblemumble wrote:
| I recently inherited a Clojure codebase whose original
| developers are all long gone. I'm finding the experience to
| be a bit like trying to learn how to navigate a city where
| none of the streets have names.
|
| When I was working my way through _Clojure for the Brave and
| True_ , I really liked all the clever techniques around data-
| level programming and informal interfaces. Not having to stop
| to define and name formal types lets you slap things together
| quickly. But I'm now seeing the where that approach leads to:
| A codebase where nothing is formally defined, and nothing has
| a name.
|
| I see where there were some efforts to do it by the book, and
| formalize this stuff by using functions to define an
| interface. The problem, though, is that we live in an orderly
| cosmos, and some laws are universal. One of those laws is
| that people will always take the shortest practical path to
| get from point A to point B. No matter how politely you ask
| them not to. So, if a map _can_ be manually hacked to shreds
| in an ad-hoc manner, it _will_ be manually hacked to shreds
| in an ad-hoc manner.
| Xenoamorphous wrote:
| At the company I work for we've found it hard to find Clojure
| devs. Not sure if this applies everywhere else, but it's
| definitely seen as a disadvantage of the language here.
| puredanger wrote:
| Many Clojure companies find it easy to hire smart non-Clojure
| developers and teach them Clojure. You can learn the basics
| in a week or two and be a pretty effective Clojure developer
| (especially if supported in a team) pretty easily.
| ertucetin wrote:
| No, you can't (in that timeframe).
| jwatte wrote:
| Depends on where they're coming from. If all they know is
| Java, then surely not! If they've done Python and C and
| Erlang before, the switch doesn't seem as hard.
| hangonhn wrote:
| +1 on that. I've learned Clojure in the past and keep
| wanting to go back to it but Clojure has been the hardest
| language for me to become fairly comfortable with. I
| think it may have to do with its dynamic-ness. There's
| basically no problem Clojure experts can't find a
| solution for. Its basic constructs are very powerful but
| all those solutions are not codified in the language
| itself. So Clojure has this extra layer of "culture"
| around it and as a beginner that's very hard to learn
| without a lot of doing and running into a wall quite a
| few times. Just when I think I have a grasp on the
| language, I see a new construct or new way of doing
| something that's completely alien to me and wasn't in the
| Clojure book I just read. I've not saying one can't
| become good at it but it takes a bit and might help to
| have an expert or two guiding you.
| puredanger wrote:
| Just as one example, Nubank did not hire 600 Clojure
| developers. They hired 600 developers who learned Clojure.
| dwwoelfel wrote:
| This is what we did at CircleCI. In fact, most of our best
| hires were people who did not know Clojure before joining
| the company.
|
| People who already knew Clojure had a tendency to
| overcomplicate things with solutions that used every bit of
| their Clojure knowledge.
| eigenhombre wrote:
| I have helped do this at two companies that used Clojure
| heavily, and agree it is definitely doable (and possibly
| easier the smarter and more junior they are).
|
| What can be more challenging is to find more senior people
| who are decent Clojurians (it is hard to take a junior
| developer and make them as, or more, senior than you, for
| example :-) ). Hiring experienced Clojure devs is also
| doable, but takes time, flexibility (e.g., open to
| remote... easier in 2020 than in 2019), and real effort.
| didibus wrote:
| I can coroborate this in our case. But to be fair to OP, it
| requires having a very good onboarding process. We have
| weekly Clojure lessons where we teach the language, and
| good CR protocol so for a while all CRs go to people who
| know the language very well so they can give good advice
| about Clojure. And this works if you add new developers
| slowly, but can get challenging if you hire quickly. So I
| would say it still requires some extra effort and the
| motivation to do so.
| hotcrossbunny wrote:
| This sounds like a good place to learn. Might I ask the
| company?
| puredanger wrote:
| This is a pretty good talk about this (don't think it's
| the same company):
| https://www.youtube.com/watch?v=7E4gF3KEwZ0
| paultopia wrote:
| Maybe a broader version of this point: clojure tries to be
| something suited both for industry use at scale and for
| hobbyists wanting to do freaky-deaky stuff at the same time,
| but those are fundamentally incompatible.
|
| I say this as someone squarely in the latter category who has
| exactly the opposite problem from you: I love clojure the
| language and its features, but all the major libraries seem to
| be written by refugees from Java working at big companies who
| have a will to massively overengineer everything.
|
| I'm thinking of libraries like mount and such which everyone
| uses for everything, and which I experience as, like, "did you
| want to inject your dependencies in your injected dependencies?
| Well first you have to do a quadruple axel inversion of control
| at the fifth abstraction layer out and use the fooflarb design
| pattern to delegate your inheritance and you thought you could
| even _find_ the place in the code where it talks to the
| database? Good luck, sucker. " Like, I always thought the point
| of a functional language was to not have to do any of that
| stuff...
|
| Like, I vividly remember the first time I used a clojure web
| framework that brought in all that stuff, and I literally, I'm
| serious here, could not find where in the code it was actually
| talking to the database. Just indirection on top of indirection
| on top of indirection. And when the application I was building
| on top of that, which was supposed to be quick and dirty,
| started mysteriously losing data, the only thing I could do was
| just tear it down and rewrite with Python and flask.
| burnthrow wrote:
| It's not fair to point to specific overengineered libraries
| and say this is the language idiom. Clojure is a small,
| stable language (few changes over the years) that encourages
| creation of DSLs through macros. It provides solid ground on
| which to build the abstraction you want, so it's possible to
| build these EE-ish indirection nightmares if that's what you
| need.
|
| Clojure's design allows it to serve the needs of both
| hobbyists and enterprise, but the latter requires strong,
| disciplined developers who understand to avoid loose,
| hobbyist code that the language allows, and who will agree on
| which patterns to use in the codebase (something the hobbyist
| gets for free mostly). It's a punishing language for a
| project with high developer turnover.
| paultopia wrote:
| Fair enough---I guess part of my dissonance is that's also
| a lisp, and I feel like 99% of the people attracted to
| lisps are us wild-eyed hobbyist types who really just want
| to build an individualized DSL for every project.
| blunte wrote:
| The s-expressions in lisps and clojure are one of my
| favorite attractions. There's so much less cognitive load
| when the syntax is so simple. Elixir, another great
| language, has a painfully complicated syntax (plus a lot
| of syntactic sugar and cases of there's more than one way
| to do something).
|
| Clojure is a bit noisier than lisp in terms of syntax,
| but it's also more expressive. I find the balance and
| design choices pretty reasonable.
| puredanger wrote:
| If anything, I'd say that Clojure _discourages_ the
| creation of DSLs through macros compared to most other
| Lisps, and encourages the use of plain data and functions
| first.
| raspasov wrote:
| Using a functional language doesn't make reality and the
| complexity of state go away (unless you are writing a
| compiler or a program/system that fully and purely
| mathematically controls its inputs and outputs).
| jwatte wrote:
| A good functional language lets you clearly define, manage,
| and trace where your code meets reality, though. That kind-
| of needs strict static type systems, rather than loosey-
| goosey dynamic tag checking, though. That's IMO the main
| reason statically type checked languages like C++/Java/etc
| work much better at large scale than runtime tag checked
| languages like Python/Clojure/etc.
| puredanger wrote:
| I think "needs strict static type systems" is a
| hypothesis but one with certainly many anecdotal examples
| to refute it. Most of the studies that have been done
| (and admittedly these studies are extremely difficult to
| do well) show lower or similar bug counts in dynamic
| languages vs static languages.
|
| If you've built large scale system with statically type
| checked languages that solve all these problems, I assume
| you never had any bugs right? Never needed to write any
| unit tests?
| newcrobuzon wrote:
| Many people don't know this, but you can still commit
| code that does not compile :D
| didibus wrote:
| I think it works well in a micro-service world, because in that
| world, no single component is large, as the large system is
| built of smaller services. So each service can be a small to
| medium sized Clojure code base. (At least it does for us at my
| work).
|
| Apart from that, I think one thing that's missing for larger
| scale Clojure is best practices and common tools, IDEs,
| frameworks and libraries. When I compare it to Java, Java has
| so much ingrained best practice and information out there, even
| junior devs will quickly pick up a book about its design
| patterns, and all that. And basically everyone uses the same
| tools and frameworks, its always Spring or Guava, IntelliJ or
| Eclipse, Jetty or Netty, Log4J or Logback, Jackson, Hibernate,
| etc.
|
| I might agree with you slightly on some of the ackward bits. If
| transducers had been there from the get go instead of lazy
| sequences. If named arguments were first class and the compiler
| could check that the mandatory arguments were passed in. If
| exceptions were functional, and pattern matching was added to
| compose them. And if a few more core functions/macros were
| added for convenience. I think it would facilitate a bit
| adoption on larger projects.
| [deleted]
| moomin wrote:
| The Future of Clojure is 39 minutes and 11 seconds.
|
| Sounds about right.
| tharne wrote:
| I'd love to see clojure take a bigger role in the financial
| services sector. The fact that it runs on the JVM, gives it a
| nice foot in the door.
|
| Ideally, it would be great if clojure replaced Python and Scala
| as the defacto language used to interact with Apache Spark.
| That's probably not likely, though. It's hard enough to get a lot
| of folks past spark's weirdness without throwing a lisp into the
| mix. But it does seem like a functional JVM language that's not
| Scala would be the optimal way to use spark.
| naringas wrote:
| Nubank (a Brazilian based startup-style fintech company) does
| everything with clojure (on AWS). They bought Plataformatec
| makers of the Elxir lang.
| Scarbutt wrote:
| Yep,and they were forced to buy Cognitect too to deal's with
| their Clojure/Datomic mess.
| dgb23 wrote:
| Can you substantiate that claim?
| mst wrote:
| The entire interview is with a Nubank employee, who talked
| about more clojure in finance as a result. I think OP was
| riffing on that.
| ashtonkem wrote:
| I used Clojure in financial services, specifically at a trading
| firm. When I left we'd stopped writing new Clojure services,
| and had started to replace existing ones with Java. Finance, at
| least in our area, turned out to be a pretty tough place for
| Clojure's style of dynamic typing.
|
| For those that don't know, Rich Hickey (and by extension,
| Clojure) is really big on data-first dynamic typing. So
| idiomatically you're supposed to do most of your work in
| Clojure using their first-rate immutable collections library,
| primarily maps and their sequence abstraction. Clojure provides
| some mechanisms for specialized domain objects, but it's fair
| to say that this is typically considered non-idiomatic.
|
| This works great if one of the following conditions are true:
|
| 1) All data flows through your system on separate tracks. Foo's
| come in from foo endpoints and go to the foo database, and very
| rarely do data sets cross paths. Differences in business logic
| can be separated by API endpoint, kafka topic, or some other
| difference that lets you separate the call paths thoroughly.
|
| 2) Every type of data in your system _looks different_ , so
| that you can easily determine whether or not a given piece of
| data is a foo or a bar once and send it down the right call
| path in one place.
|
| 3) In any case where similar types of data must be treated
| differently, it's possible to organize your code in such a way
| that you only have to build up the cond-tree once, and you can
| use different call paths to treat the data differently.
|
| All of these were often false for us. We ended up in situations
| where we had lots of data that looked _very_ similar entering
| from common endpoints that required different business logic at
| multiple points in the pipeline. If you're writing idiomatic
| Clojure this is the toughest case possible, as you end up
| littering your code with extremely similar cond-trees, which
| makes extension and verification unnecessarily hard.
|
| In most other languages, even dynamic ones, you'd solve this
| via sub-classing to both group common behavior and allow
| specialization. Clojure provided some tools to make this work,
| but they were both maintenance nightmares in their own separate
| ways. My favorite is how the results of defrecord (which makes
| class-like maps in Clojure) could be treated like a map, except
| certain map operations could accidentally turn it back from a
| record to a regular map. That's _quite_ the foot gun, trust me.
|
| For our team, we decided that pure Java was the way to go. Java
| by that point had started adding a lot of boilerplate
| eliminating niceness, including lambdas and streams, and the
| ability to make honest-to-god subclasses really helped out in
| our specific domain.
| raspasov wrote:
| Did you ever consider using Clojure spec or one of the
| alternatives before it? Runtime data shape/type inference is
| quite capable.
| didibus wrote:
| You've actually hit the real crux. Beyond the functional,
| beyond the Lisp, what is special and unique to Clojure is its
| style of data modeling. Using plain immutable data-structures
| creates a very unique style, and I think there isn't enough
| conversation about that. So it lacks best practices, and
| possibly support around it as well, in tooling and in style.
|
| It's hard to discuss your particular case, but what I wonder
| is if there wasn't a different way to model things that would
| fit in the Clojure data-droven model. And if not, would there
| be new patterns or even some extension constructs to it that
| could allow it to fit?
| adamkl wrote:
| _> We ended up in situations where we had lots of data that
| looked very similar entering from common endpoints that
| required different business logic at multiple points in the
| pipeline. If you're writing idiomatic Clojure this is the
| toughest case possible, as you end up littering your code
| with extremely similar cond-trees, which makes extension and
| verification unnecessarily hard._
|
| Isn't this where you would use multi-methods? If you can
| determine what the "type" of data is via `cond` (sounds like
| home-grown pattern matching?), couldn't you replace these
| situations with multi-methods that switch on the same
| conditions?
| ashtonkem wrote:
| Multi-methods suffer the same drawback as repeated conds.
| You end up having to maintain multiple multi-methods in
| multiple locations that all need to cover all the same
| cases. If anything else, multi-methods are marginally worse
| than conds, because the actual implementation can be spread
| out and harder to visually check.
|
| If you can get away with _one_ multi-method, that 's fine.
| The moment you start needing multiple multi-methods in
| different points in your pipeline then things begin to
| suck.
|
| > sounds like home-grown pattern matching
|
| Yup! And if you find yourself constantly writing pattern
| matches in Clojure, then you probably actually want
| classes, since that's a much better way to bind both data
| and behavior together.
| raspasov wrote:
| Have you considered core.match ? I've used it to dispatch
| API calls based on just data shape.
| ashtonkem wrote:
| I know that this isn't your intent, but suggesting that a
| bunch of professional Clojure programmers just didn't
| think to use core.match is borderline insulting. The
| problem wasn't "doing the matching is hard", the problem
| was "doing the matching in multiple places and making
| sure that we cover all cases in all places is starting to
| look like a maintenance nightmare".
| adamkl wrote:
| _> "doing the matching in multiple places and making sure
| that we cover all cases in all places is starting to look
| like a maintenance nightmare"_
|
| That sounds more like an indictment of functional
| programming rather than Clojure specifically. I'm not a
| seasoned functional programmer but I often read glowing
| praise from others about the use of pattern matching in
| their code.
|
| I'm also not a professional Clojure programmer, but I
| thought that multi-methods were supposed to be the
| solution to the expression problem [0] that both class-
| based inheritance and pattern matching suffer from.
|
| It was my understanding that multi-methods are supposed
| to allow open extension of behaviour without having to do
| what you just described; track down every instance, and
| cover every case.
|
| In the case of multi-methods, couldn't you just co-locate
| the method implementations next to the data they are
| supposed to operate on? You should be able to add/modify
| behaviours without worrying about what the other data
| types are doing.
|
| Honest questions here. Just trying to learn more about
| the real world pros/cons of these approaches.
|
| [0] http://wiki.c2.com/?ExpressionProblem
| mring33621 wrote:
| So just add some triage middleware (maybe Java based) between
| the data sources and your Clojure code, which separates the
| coarse-grained data into more granular flows for consumption
| by your Clojure code.
| dgb23 wrote:
| > 1) All data flows through your system on separate tracks.
| Foo's come in from foo endpoints and go to the foo database,
| and very rarely do data sets cross paths. Differences in
| business logic can be separated by API endpoint, kafka topic,
| or some other difference that lets you separate the call
| paths thoroughly.
|
| My instinct is that you could solve general "where does this
| come from" and "where does this go" questions with metadata.
| I believe that was one of the driving reasons for metadata in
| the first place.
|
| > 2) Every type of data in your system looks different, so
| that you can easily determine whether or not a given piece of
| data is a foo or a bar once and send it down the right call
| path in one place.
|
| Clojure spec, malli, schema are libraries that deal with this
| kind of problem. They are very expressive.
|
| > 3) In any case where similar types of data must be treated
| differently, it's possible to organize your code in such a
| way that you only have to build up the cond-tree once, and
| you can use different call paths to treat the data
| differently.
|
| A combination of spec (or others) and multimethods (arbitrary
| dynamic dispatch) would come to mind here as a solution.
|
| I assume these things are known and were discussed. Are there
| specific trade-offs that didn't work out?
| ashtonkem wrote:
| It's kind of interesting that you're responding as if all
| of those three points are something _against_ Clojure, when
| in fact they were cases in which Clojure would work really
| well. I made that clear.
|
| > I assume these things are known and were discussed. Are
| there specific trade-offs that didn't work out?
|
| As is always the case when a team switches programming
| language, the problem I described was the straw that broke
| the camels back for us. But fundamentally the issue in this
| case was "it sure as heck looks like we're trying to
| approximate class based dispatch inside of Clojure, this
| sure as heck is silly. Let's just use a language that
| actually wants to be used this way".
| dgb23 wrote:
| Makes sense. I approached this from a curious point of
| view, not from a combative one, to get a sense of where
| the problems were.
|
| The general problem you describe was also mentioned in
| the podcast. Trying to write like language X in language
| Y. This can also be observed within the Go community;
| people writing Java or JS style programs in Go,
| especially early on.
| lmilcin wrote:
| See... I work for one of the largest banks in the world and in
| vicinity of me there is a Clojure project. The guys are trying
| to figure out how to get rid of it. Original developers left
| the company or advanced to management roles and now nobody is
| able to figure out what this convoluted, obfuscated, undefined,
| unstructured mass of code does or how to modify it so that it
| doesn't blow up more that it already is.
|
| As much as I love Clojure I see the problem is you need really
| good (not just intelligent but also wise) developers to reap
| benefits. Otherwise you can run into huge problems.
|
| "With great power..."
|
| Clojure has so bad rep here that even I think I made a mistake
| that I let on that I use it for my projects.
| didibus wrote:
| > and now nobody is able to figure out
|
| Ok, but how much of that is just them not knowing Clojure?
| I've found people that get handed down a code base in a
| different language tend to hack their way around it, instead
| of like, pausing for a minute, take some time to learn the
| language, and then come back to it.
|
| Maybe in your case it was a terrible code base of low
| quality, but I'm just curious.
| lmilcin wrote:
| The problem isn't knowing or not knowing Clojure.
|
| The worst codebases (and that is true of other languages
| just as for Clojure) that I have seen are ones done by
| people who are intelligent enough to learn every feature of
| their language and any little trick available on the
| internet but haven't yet had the chance to acquire the
| wisdom on when to use them or what to use them for.
| clusterhacks wrote:
| I am also a long-time Clojure user and have production
| projects built in Clojure.
|
| I think your observation that you need really good developers
| is the key insight to problems that come about from using
| Clojure. Stu Halloway even mentions it in the interview:
|
| "And what we would quite often see is that people would write
| a Java app in Clojure, or people would write a Ruby on Rails
| app in Clojure. And not surprisingly, it would have
| weaknesses that you associate with idiomatic Java apps or
| idiomatic Ruby on Rails apps"
|
| Clojure, as a language, makes it very easy to do stuff and
| sometimes that stuff means making code look like code that
| only makes sense in other languages. This is a _terrible_
| mistake but one that is easy to understand. Very few
| developers have any real background in functional programming
| and it is too easy to start hacking things together.
|
| As a longtime Clojure user (dating back to attending the very
| first Clojure conference in Durham, North Carolina), I think
| there has been a little bit of "ego-driven" developer
| syndrome with projects in the language. There is definitely a
| tendency for new Clojure programmers to get too fancy.
|
| This is _not_ a problem with Clojure the language though. I
| made the mistake myself in early projects. The more I have
| used Clojure, the more I have realized that when I am doing
| it right, I am spending significantly more time understanding
| the problem I am solving than throwing code together . . .
| pinchhit wrote:
| This absolutely matches my experience as a full time Clojure
| dev at multiple companies. Leadership is desperate to replace
| the code with something more maintainable. It's gotten bad
| enough that I will switch languages for my next job, the
| headaches are not worth it.
| [deleted]
| burnthrow wrote:
| Clojure is quite maintainable, a well-written Clojure
| program is small and clear, easy to modify. Pervasive
| immutability is a huge win; Clojure programs are big on
| referential integrity.
|
| There's some doublespeak going on here.
|
| When "leadership" says "maintainable" what they mean is
| that the project is recoverable after they frog march the
| project lead out the door, or lay off the team, or the team
| quits because the job blows. Their view of maintainability
| is dominated by Bus Factor and similar existential
| concerns, rather than agility experienced by the project's
| authors. They actually want the opposite of maintainable:
| Rigid and heavily specified.
| pinchhit wrote:
| This is not what I meant by maintainable. The companies
| I've programmed clojure in were sizable and bet on it for
| their entire stack, and hired very sharp senior people to
| work on them.
|
| Even there, the projects suffered so much to hit release
| dates and stay understandable as the system grew that
| velocity suffered relative to peers doing experiments in
| traditional OO languages. In fact, the maintenance burden
| (for code composed by smart senior people!) is so high
| that it's actually convinced me on the virtue of regular
| OO/procedural languages over lisp.
| kazinator wrote:
| > _it 's actually convinced me on the virtue of regular
| OO/procedural languages over lisp._
|
| This is an example of the problem of Clojure being
| promoted as Lisp. There are now people whose idea of what
| is "Lisp" is represented by Clojure.
|
| You might like coding in a normal, procedural Lisp with
| OOP, but due to a bias induced by Clojure, you don't
| suspect that's even a thing.
| dustingetz wrote:
| What % of Java projects fail again? With Java, your
| convoluted mess is 100k to millions LOC. With Clojure, the
| same devs make the same convoluted mess but in 10k to 100k
| LOC, and you've left the door open for an inspired "true
| Scotsman" to come in and do the whole thing in 5k. But
| management has to understand that, and of course the
| principle agent problem, peter principle, politics, conways
| law ... Java is great for middle managers, it makes their
| department headcount grow, and they get to pretend the
| project is succeeding because nobody can tell otherwise.
| ashtonkem wrote:
| It's _really_ hard to argue that Java projects fail at
| unusual rates, given how much stuff runs on Java.
| rienbdj wrote:
| Maybe not at unusual rates, but I wouldn't be surprised
| if the rates are high.
| pbourke wrote:
| When you measure the failure rates of Java projects
| against the failure rates of Clojure projects, you're not
| measuring the failure rates of a language, but rather the
| general failure rate of software in industry vs the
| failure rate for a (likely) small, motivated team.
| dustingetz wrote:
| you cannot measure anything at all about failure rates by
| looking at successes
| jimbokun wrote:
| But are the rates for Clojure failures more or less than
| Java?
| lmilcin wrote:
| With Java, your convoluted mess can be parsed by IDE and
| you can figure out what it is doing. Also, most of it looks
| the same and is Ctrl+c, Ctrl+v of something else.
|
| With Clojure the mess is still 100k to millions LOC because
| the guys did not know how to make worthwhile abstractions,
| but now it can't be parsed by IDE and you are screwed
| trying to figure out what happens at runtime.
|
| ALso, if you think if there is less code then it is easier
| to understand, go and read any advanced Common Lisp book
| (like Let over Lambda) and try to really understand what
| some of the more advanced macros do, exactly. It is
| definitely not the same as reading pages upon pages of
| redundant code.
| jdminhbg wrote:
| > With Java, your convoluted mess can be parsed by IDE
| and you can figure out what it is doing.
|
| This is not my experience whatsoever.
| taeric wrote:
| This doesn't match my experience. I've had to deal with
| some Java code that the ide was useless to help figure
| out. Usually made worse by some over optimized build
| system that was non Google friendly to see what was
| supposed to happen.
|
| Worse, the abstractions made it so that even a simple
| feature would require about six files. Not counting the
| tests.
|
| Not to say that clojure has been a breeze. Worst I see
| there is developers refusing to use libraries it external
| programs and instead taking a ridiculous "first
| principals" approach. Even if they get it working, it is
| typically not search friendly, as everyone else is using
| some other tool. Basically, the same trap I see in build
| systems,
| jimbokun wrote:
| > I've had to deal with some Java code that the ide was
| useless to help figure out.
|
| Spring annotations, maybe?
| dustingetz wrote:
| Millions of LOC of Clojure project is unheard of; from
| the article: Nubank has "2.7 million lines of Clojure
| code [encompassing] _several hundred microservices_
| written in Clojure " - the 2.7M is across the _entire
| enterprise_.
|
| I have an enterprise client right now sitting on 1.5M
| java 1M SQL 1.5M XML for a single government system that
| _mostly does not function at all_ , it just gets passed
| from contractor to contractor, each one sucking down a
| _hundred million dollars_ before tossing the hot potato.
| Thanks for the money, Java!
| aprdm wrote:
| A fintech that I am aware of chose Elixir and is a
| complete shitshow, they're trying to move away from it
| after being established with it.
|
| Can't hire for it, can't refactor the code at scale, etc.
|
| Be careful with what you read, newer languages are
| usually trying to sell themselves where established
| languages have happy people not trying to sell it, or,
| resume driven developers trying to sell it as bad.
| hotcrossbunny wrote:
| Maybe if you make it known that you have some Clojure
| projects and that it might have even a possibility of a
| future with you, you might be able to attract and hire some
| good devs
| lmilcin wrote:
| But we do. There are publicly advertised open Clojure
| positions and I have been cold called or contacted on
| LinkedIn because I let on that I know Clojure. To which I
| must politely say I am already working for this company.
| hotcrossbunny wrote:
| Yep, I guess that is pretty ironic. If your roles are
| open to London/remote, I would be happy to take a look
| deckeraa wrote:
| Same here. I've got current availability to do contract
| work and could take on some Clojure dev if that's what
| they need.
| tharne wrote:
| That's unfortunate, but I see your point. It's a real
| catch-22. If you build everything in Java it's harder to
| attract good devs, but if you use something like Clojure you
| _need_ to attract those good devs.
| Pet_Ant wrote:
| > Clojure you need to [keep] attract[ing] those good devs.
|
| This isn't one and don, people move on even from the best
| jobs. You know need to keep replacing them, explain to HR
| why this "req" (requisition - aka job opening) needs them
| to look at resumes differently. Why they can't pull from
| their Java pool of resumes, explain to your director why
| you aren't like all the other teams. It's a lot of
| friction.
| jjtheblunt wrote:
| perfectly said
| nnp7000 wrote:
| Citi?
| sambe wrote:
| I have noticed that people often use such criticisms against
| anything they aren't familiar with. If you can find an
| enthusiastic polyglot who says the same then it becomes a bit
| more believable. And - of course - the fact that it is so
| unfamiliar to most is probably a valid criticism anyway.
| lmilcin wrote:
| The truth is that the candidates we are receiving are
| barely able to code in Java. Not all know differences
| between linked lists and arrays and if they know what a
| breakpoint is they are hired.
|
| Now, imagine giving the people environment that imposes no
| structure on your project and gives hyper powerful tools
| like macros and you are in a big problem.
|
| At least with Java you get Spring and this is how you do
| endpoint, this is how you connect to the database, and so
| on. The structure is suboptimal and redundant but at least
| they are getting _some_ guidance which are most likely
| already familiar with.
|
| In Clojure, as a lead of the project, you would have to do
| the same but now it would be up to you to define all of
| that guidance. The question is, are you better at this than
| entire organization that supports Spring?
|
| The only situation I see where Clojure would realistically
| be beneficial is when you only get like world class
| developers who know what they are doing and can work
| together.
|
| I can't work on a Clojure project with a person that is
| unable to go through something like Let over Lambda with
| full understanding of the code examples and trust they will
| be able to make good decisions when building abstractions
| with macros.
| jimbokun wrote:
| > Not all know differences between linked lists and
| arrays and if they know what a breakpoint is they are
| hired.
|
| Found your problem.
| dgb23 wrote:
| I'm possibly being naive with this question:
|
| Isn't this a cultural, organizational problem? You said
| your original developers left or moved on to management
| and your new hires are rather inexperienced. Wouldn't it
| be a wiser long term strategy to facilitate learning and
| knowledge retention through mentoring, documentation,
| teaching and attractive technical career tracks?
|
| For example there are several popular open source
| libs/solutions to manage application state and structure
| declaratively. And it is well known in the Clojure
| community that macros are a double-edged sword and should
| be used to solve specific problems.
|
| I agree that Clojure is kind of a second (plus) language.
| But I also think there is a reasonable path from writing
| simple Clojure to wielding the more powerful features.
| [deleted]
| Bootvis wrote:
| I don't understand why you can't get better candidates. I
| understand that things go wrong with bad developers but
| how is it that you can't get those folks that can write
| somewhat good Clojure independently?
| lgessler wrote:
| I don't know what sector GP is in but there are plenty of
| programming jobs (maybe even most?) where the company
| (usually one where tech generally is incidental to their
| operations) really isn't in a position to offer a salary
| that's competitive enough to hire this way. I'd say most
| programming jobs at US hospitals are this way, for
| instance.
| jimbokun wrote:
| Which is why hospitals really shouldn't be writing
| software.
|
| And why, as a developer, you want to be working for a
| software company where your work is generating revenue,
| not somewhere where you are a cost to be cut.
| didibus wrote:
| I guess I'm fortunate enough to have only worked in
| places with high hiring filter and that can attract good
| talent. In an environment like yours, I'm not sure what
| language should be used, I'd say an old version of Java
| like 1.6, newer versions have become less rigid and less
| explicit so might make them harder.
| dustingetz wrote:
| Re any large Clojure projects needing modernization or
| migration to new stack - I would be happy to take care of
| projects like this, tech debt is not a problem for us, email
| me dustin@hyperfiddle.net
| wokwokwok wrote:
| ? You can already use clojure with spark[1].
|
| ...but just as pyspark is not "pythonic", clojure spark is
| super unidomatic to use. ...which is why its languished unused.
|
| I mean, an idiomatic library isn't impossible; see how
| databricks has wrapped the pandas api up with its koalas
| project; you just have invest the time and effort and actually
| make it.... for what, fundamentally, is a total absence of
| demand.
|
| or do you mean like first party support for clojure? Thats
| never going to happen...
|
| [1] https://github.com/gorillalabs/sparkling/
| hotcrossbunny wrote:
| Does this framework speak to the mismatch in idiomatics?
| https://github.com/zero-one-group/geni Not asking from any
| point of expertise mind you, having only stumbled across this
| literally this morning
| mumblemumble wrote:
| Tangentially:
|
| I recently decided to give Pharo a try. I'm still pretty early on
| in it, but, so far, I've really been having fun. If you look at
| it the right way, Smalltalk can almost be seen as more Clojure
| than Clojure. It's even more dynamic, and the live programming
| environment gives even tighter, more integrated feedback loops
| than REPL-driven development. Smalltalkers aren't exaggerating
| when they say you can literally program from inside the debugger.
|
| A lot of familiar programming idioms from Clojure (and other
| functional languages) are present in Smalltalk, and have been for
| years. And, while objects in Smalltalk are nearly as dynamic as
| maps in Clojure, the fact that they're discrete, named entities
| makes it a _lot_ easier to inspect and grok someone else 's code.
|
| It's not all perfect, of course. Some of the usual criticisms of
| Smalltalk are legitimate (though Pharo is making progress on
| addressing many of them), and I would like to see more of a
| culture of discipline around mutability. But, all in all, it's
| largely been a joy to learn.
| truculent wrote:
| What are you writing with it? I've been wanting to give it a
| try too, but I'm unsure what kind of project is best suited.
| [deleted]
| bmitc wrote:
| What is your process of learning it? Did you take the Pharo
| MOOC?
| mumblemumble wrote:
| Yep, I'm still working my way through the MOOC. It's quite
| well done.
|
| I would recommend even taking the time to listen to the parts
| that seem basic. The Smalltalk way of thinking about objects
| is different from how OOP is usually done in some subtle but
| important ways, so I'm finding it useful to take a "forget
| everything you know" approach.
|
| Somewhat amusingly, the process of learning Smalltalk in the
| evenings and then going back to Java during the day is going
| a long way toward helping me understand why Yegor Bugayenko
| seems so chronically exasperated.
| bmitc wrote:
| That's great to hear. It's been on my radar for a while,
| but I've not dove into yet.
|
| > I would recommend even taking the time to listen to the
| parts that seem basic.
|
| Thanks for that recommendation! This is my default style,
| although it's enabled by not knowing much anyway. Lol.
|
| Regarding your last point, this is my exact feeling knowing
| F# and Racket before being forced to use Python in some
| capacities.
| moocowtruck wrote:
| gimme smalltalk or gimme death
| submeta wrote:
| Reading the comments I get the impression that Clojure is
| competing with Java, and it seems that it cannot win against
| Java, for various reasons, and I am saddened by that.
|
| What does it mean to see a rather promising Lisp-like language
| not getting traction, for the the future of Lisp(s)?
| puredanger wrote:
| Clojure was designed to be applicable where Java is applicable.
| Fortunately that space of programs is enormous and the market
| is enormous. Clojure does not need to "win" against Java (or
| anything). It is unlikely (for many reasons that have nothing
| to do with its value as a language) to ever be more than a
| fraction as popular as Java, but that's irrelevant. It has a
| thriving sustainable ecosystem with 10k's of devs in 100's of
| companies. That is sufficient to call it a success.
| dzonga wrote:
| are there people who used both clojure and scala. And decided to
| use Scala ? if so why ? I'm new to Scala that's why
| keithasaurus wrote:
| Yes. In general, I would choose Scala. Better tooling, (pretty
| good) type system; not without its warts. Main concern I'd see
| ahead is the 2 -> 3 transition, which has the potential to be
| as difficult as the Python 2 -> 3 transition. That said, Scala
| 3 looks nicer to me as a language, with top-level functions,
| significant whitespace (more concise code), and better ADTs.
| eeperson wrote:
| I've used both and end up writing much more Scala. There are a
| few reasons why this was the case for me: -
| Scala is much closer to Java making it an easier sell to other
| Java programmers. - I think static typing makes a lot
| more sense for larger projects - I found a rich static
| type system easier to use and more generally applicable than
| macros.
| dyadic wrote:
| There are people that used both including me. But I fell
| squarely on the Clojure side and haven't written Scala for 7-8
| years now.
| dustingetz wrote:
| Same, 2010-era FP in Scala was a disaster and also very
| angry, but I'd say in about 1-2 years FP Scala will be about
| at the maturity that they imagined they were at in 2010.
| Still kind of angry though.
| atdixon wrote:
| A common point is being made in the threads here: "The downside
| of Clojure is that you need good, wise developers..."
|
| The converse of this is that good, wise developers are going to
| (ultimately) _demand_ Clojure.
|
| What I mean by this:
|
| I was a Java programmer for years and increasingly started
| writing code in a more functional, immutable, dynamic style with
| the _occasional_ need for meta-programming -- for the sheer need
| of being more productive and writing more robust code.
|
| Yes, you _can_ write functional, immutable, dynamic, code in Java
| _and_ do meta-programming in Java!
|
| It's just somewhat cumbersome and prickly.
|
| Enter: Clojure.
|
| I've seen many an 'unwise' programmer make just as much a mess of
| Java systems as people are suggesting they've seen in Clojure
| projects. It may be simply that Java _slows you /your team down_
| enough so that the messes of unwise programmers are just made
| more slowly.
|
| But one wonders if this is really a win: you're probably also
| delivering your business value more slowly, as well.
|
| :thinking-face:
| maharajatever wrote:
| > A common point is being made in the threads here: "The
| downside of Clojure is that you need good, wise developers..."
|
| A common situation is that a mediocre Java programmers reads
| the first page of a clojure tutorial, finds out about list
| comprehensions and map and filter (probably not even fold) and
| decides he (yes almost always he) is a genius. A "good, wise"
| "engineer".
|
| Reality usually disagrees.
|
| The reality of actually having to write a complete working
| system in a language in which your knowledge is limited to the
| first page of a tutorial is even harsher.
|
| When your "wisdom" and "goodness" are up against a hard
| deadline, or even an interview, you get the confused messages
| in this thread that blame companies for not hiring you, people
| for it understanding you, everyone else for being stupid, and
| the world for your unemployment.
|
| May be learn what you started with first, but well, and thence
| to expand your knowledge in various directions.
|
| But of this fancy stuff is available in almost every language.
| If you think clojure is special you're in a bad place. Hickey
| wrote clojure in java.
|
| For the record, I don't write java or clojure anymore, and if
| you think clojure gives you an advantage without knowing at
| least five other languages to a professional level, then you're
| not getting hired anywhere near me...
| clusterhacks wrote:
| I think that the bigger problem is that developers just don't
| get taught any way to think about coding other than the object-
| oriented, use-Java-for-everything approach.
|
| I sometimes think I could have massively accelerated my ability
| to produce decent code in _any_ language if I had been forced
| to work through "The Little Schemer" and "How to Design
| Programs" before I saw anything else.
|
| But that is probably just hindsight or personal bias. I found
| functional programming in Lisp and Clojure to simply click for
| me in a way that enterprise Java class hierarchies never did .
| . .
| [deleted]
| kazinator wrote:
| When I'm coding in Lisp, I want objects with methods and
| mutable state.
|
| I made myself a Lisp dialect with a nice little object
| system.
|
| More precisely, I made it without that object system, but I
| eventually couldn't stand the situation.
|
| I use objects even in small, throwaway programs used once.
| Sometimes it turns out that they aren't just used once, and
| the use of objects makes them easier to read later.
| Scarbutt wrote:
| _I was a Java programmer_
|
| Most Java programmers get enlightened and feel relieved as you
| did when they switched to language X from Java. Is a recurring
| theme, not specific to Clojure.
| majormajor wrote:
| > The converse of this is that good, wise developers are going
| to (ultimately) _demand_ Clojure.
|
| Maybe the _really_ wise developer is aware that not everyone
| thinks the same, even themselves now vs six months from now,
| and is very wary of dynamic behavior and cleverness...
|
| I don't want Java _or_ Clojure in a team environment, now that
| I 've got Kotlin.
|
| Or maybe I'm just not wise enough. ;)
| throwaway92938 wrote:
| > The converse of this is that good, wise developers are going
| to (ultimately) _demand_ Clojure.
|
| HN seems to blindly accept the idea that developers using niche
| languages are good but I certainly haven't seen any proof of
| that and I haven't seen anything to even remotely suggest that
| good developers gravitate towards Clojure.
|
| Great developers have to be working on hard problems and almost
| all of the hard problems in our industry, outside of
| language/chip design and correctness proofs, are being worked
| on in relatively boring languages (C, C++, Java etc.). Most of
| the niche language users I've met are working on basic CRUD web
| applications.
| keymone wrote:
| > I certainly haven't seen any proof of that and I haven't
| seen anything to even remotely suggest that good developers
| gravitate towards Clojure
|
| What about stackoverflow survey? Clojure is the most paid
| language (evidence that businesses value Clojure programmers)
| and Clojure has the most mature user base (evidence that
| users stay or flock to Clojure after many years in the
| industry).
|
| Sure, not the best kind of evidence and depending on your
| biases you can read it in many different ways, but it's a
| datapoint.
| indymike wrote:
| There was a time when Java was a niche language for web
| applets. There was a time when Python was a niche language
| you tossed into your "real" program so users could extend it.
| There was a time when C was a niche language for Unix
| development. Likewise C++ was this niche object oriented
| thing that didn't even compile to object code... it compled
| to C.
|
| And developers would look at the niche language devs and go,
| why write in C? I have my COBOL and most production code is
| written with it. Java? Why? I have Powerbuilder and Delphi.
| Most of the developers with any new language are creating
| CRUD apps, because well, that's what most computer programs
| do.
| oftenwrong wrote:
| I prefer functional programming, and have a background in
| functional programming, but I still primarily work with Java,
| and it is currently my go-to for any project. In my opinion,
| Java as a language is gross and unlovable, but the runtime,
| the development tooling, and selection of libraries and other
| integrations is about as good as it gets.
|
| I feel like I am continuously looking for a better
| alternative, but it's hard to overcome the practicality of
| using something with such immense buy-in. For example, nearly
| all major SaaS offer a Java SDK, or have Java-specific docs.
| They want the big companies to be their customers, and they
| know they use Java. I am all too happy to benefit from that.
|
| It should also be noted that Java the language is rapidly
| being enhanced with features inspired by functional
| programming. For example, sum types (in the form of sealed
| classes) have been added to the language, and ML-style
| pattern matching with compile-time exhaustiveness checking is
| in the pipeline.
|
| Of course, Java codebases you encounter in the wild are very
| likely to make you want to cry. The world of Java development
| has a lot of bad taste and questionable practices enshrined
| as best practices. That said, the Java community is slowly
| shifting toward a better style.
| bambataa wrote:
| I suppose the argument would be that only developers with a
| modicum of interest in their craft will gravitate towards
| niche languages such as Clojure. But you are correct that
| doing so doesn't necessarily mean they are good.
|
| However, I don't think it follows that great developers work
| on hard problems. Why can't you be a great developer working
| on CRUD apps and occasionally finding ways to do them better?
| Barrin92 wrote:
| >However, I don't think it follows that great developers
| work on hard problems.
|
| Isn't that just the definition of what a great developer
| is? Mind you working on a boring CRUD app may very well
| surface hard problems, but it's difficult to see how one
| could be said to excel at their craft without doing hard
| and difficult work to prove it.
|
| It's very easy to tell yourself that you're a great
| developer because you do some arcane thing that nobody else
| understands in an arcane language, but it's very easy to
| mistake esoteric behaviour for skill. Hard, real-world
| problems are a reality check. You either can tackle them or
| you don't, and if you can't do it in a fancy language it's
| no good to anyone.
| hailwren wrote:
| I argue that Clojure nee the functional programming
| community writ large capture a peculiar local maximum. I
| used to subscribe to the "functional = better" camp until
| going to MIT. I challenge anyone to find a cutting edge CS
| paper* that is written in their favorite functional
| language. If it were so effective -- wouldn't one academic
| have exploited this efficiency to catapult themselves ahead
| of their imperatively bound brethren?
|
| Maybe there's something peculiar about academic work that
| requires an imperative mind. This is why we see the highest
| paid practitioners programming exclusively in functional
| languages ... oh wait, the opposite is true.
|
| My theory is that FP hits a nice sweet spot for someone who
| would like to casually improve their craft. Something akin
| to breaking out Popular Mechanics after work.
|
| * - excluding, of course, papers about programming
| languages themselves
| didibus wrote:
| > This is why we see the highest paid practitioners
| programming exclusively in functional languages
|
| Well I don't know how accurate this is, but in 2019
| Stackoverflow survey, Clojure practitioners averaged the
| highest pay of any languages. (in 2020 they removed
| Clojure from the options so the data is missing).
|
| > I challenge anyone to find a cutting edge CS paper*
| that is written in their favorite functional language
|
| I rarely see papers written in any particular programming
| language to be honest, they tend to be pseudo-code and
| math like. And when you write a paper, you don't really
| need to be more productive or more reliable, since you
| write so little code. Plus any paper focused of low level
| or raw performance will obviously need something with
| semantics closer to the hardware.
|
| > * - excluding, of course, papers about programming
| languages themselves
|
| What about papers studying functional algorithms, type
| theory, automatic differentiation, parallel computing,
| and all that? Do you exclude those as well? Cause they're
| often written in a functional language.
| fractionalhare wrote:
| _> Well I don 't know how accurate this is, but in 2019
| Stackoverflow survey, Clojure practitioners averaged the
| highest pay of any languages._
|
| Well I didn't believe it, but wow:
| https://insights.stackoverflow.com/survey/2019#top-
| paying-te...
|
| I'm not sure if I should conclude that I'm incredibly
| ignorant of the engineering market, or that Stack
| Overflow's survey is not representative.
|
| It makes me suspicious that Clojure is shown as the most
| highly paid language at $90k. Basically any non-new grad
| developer in a high cost of living area earns more than
| that, regardless of the language. I'm also suspicious
| that only 1.4% of survey respondents use Clojure, which
| may show a bit of a base rate fallacy here.
|
| What would be the explanatory thesis for Clojure
| programmers being the most highly paid? None of the most
| highly paid roles I'm personally familiar with in big
| tech or finance use Clojure, and people who work in those
| roles earn well into the six (and sometimes seven)
| figures.
| discreteevent wrote:
| >Basically any non-new grad developer in a high cost of
| living area earns more than that, regardless of the
| language.
|
| SO is used by developers all over the world, not just in
| the US.
| throwaway92938 wrote:
| > I suppose the argument would be that only developers with
| a modicum of interest in their craft will gravitate towards
| niche languages such as Clojure.
|
| There is an opportunity cost and there are plenty of
| motivated developers that instead of learning yet another
| niche language decide to work on algorithms, applications
| and generally more difficult problems. Few languages offer
| enough advantages to overcome the fact that the latter is
| almost always a far better use of your time. As someone
| that knows Clojure relatively well, I'd argue that it's
| certainly not one of those few languages. Also, the trade
| off continuously gets worse as the popular languages adopt
| the good ideas from the niche languages and as problems
| continue to get more difficult and rely on teams of
| developers with library support in a wide variety of
| domains.
| juskrey wrote:
| Not that developers using niche languages are good, but
| rather it is very easy to figure out if they are good.
| aprdm wrote:
| > wise developers are going to (ultimately) _demand_ Clojure.
|
| Lol. I guess your definition of wise developers is very
| different from mine.
| juskrey wrote:
| In short, Clojure is far the best professionalism filter I have
| stumbled upon, in all of my 20 years of coding for money.
|
| It takes around 5 minutes to figure out whom you are talking
| to, when you are talking about Clojure.
|
| This worked perfectly for me on both sides: as a contractor on
| hire and as an employer for some project.
| Kalium wrote:
| I worked in a partially Clojure shop for a while. I found the
| Ruby on Rails developers to be more professional, overall.
| The Rails devs certainly did not have the habit of trying to
| compose together 75% of a framework anew for each project.
| juskrey wrote:
| I was talking about Clojure as a filter, not about
| unconditional superiority of Clojure devs. Indeed, any
| particular company usually attracts either all very good or
| all mediocre Clojure coders. My point it is easy to
| establish who is who.
| Kalium wrote:
| I follow. My experience was that Clojure was a strong
| filter, but not for professionalism. It served mostly as
| a filter for interest in functional programming and Lisp-
| informed ideology.
| puredanger wrote:
| I use Clojure because I am not a particularly wise programmer
| (I have been fortunate to work with many actually wise
| programmers).
|
| I like to write dumb, obvious code. Most Clojure code is about
| taking your data, representing it a sequence of maps, and
| transforming them into different sequences of maps. The maps
| are open (easy to change over time), immutable (impossible to
| encounter data races, weird equality semantics, or concurrency
| issues), dynamic (no pre-definition or ceremony required),
| concise (thanks to a literal representation that does not even
| require commas between elements), and have a generic access api
| (no custom functions/accessors/etc).
|
| Because I use the exact same transformation functions on EVERY
| PROBLEM, there is an enormous amount of reuse of generic
| operations both within and across Clojure code (even Clojure
| code that manipulates Clojure code, which is after all, just
| data).
|
| Because the center of our code is open data, coupled with
| generic functions open to later extension (multimethods,
| protocols), Clojure is notably good at handling information
| systems that evolve over time in requirements (a feature of
| essentially all of them).
|
| The core constructs are not hard, certainly they are easier to
| learn and use than complicated things like mutable classes and
| locking. The unlearning from other languages is often bigger
| than the learning. Nubank for example is certainly not hiring
| 100s of Clojure developers - in most cases they are hiring good
| people and teaching them Clojure. There are other successful
| companies doing the same.
|
| Large Clojure programs can be hard to reason about because
| large programs are hard to reason about. One benefit of Clojure
| programs is that they are often 100x smaller than the
| equivalent program in a popular OO language. They are also
| trivial to interact with live in your REPL so that you can
| inspect the data flowing through them. I will happily take live
| data and interactive function execution over 1000 classes with
| custom methods. Both require time to learn but I'm much happier
| changing the smaller, simpler one.
|
| The idea that "Clojure requires wise developers" is completely
| backwards. Enormous modern class/annotation based OO programs
| are the ones that require the smartest developers because
| that's what it takes to understand them. Clojure is accessible
| to all.
| ithrow wrote:
| All that is only true until you have to reach to Java interop
| because of Clojure's lack of ecosystem of libraries. Since
| this is a necessity and fairly common, now you are back to
| this enormous OOP world of over-engineered libraries,
| eradicating all the benefits and joy a doing a project in
| Clojure, it's unfortunate.
|
| Clojure is also not making this easier(interop) by not
| keeping up with Java advancements. Ex: functional interfaces
| puredanger wrote:
| Using Java libraries from Clojure is often easier than
| using them from Java. You say this as a negative but the
| ability to tap that ecosystem easily when needed is a huge
| benefit. Having worked in many Clojure projects, needing to
| do so is not that common in my experience.
| randompwd wrote:
| I'm still salty about Specter[0] not being ~officially
| recognised as a necessity when using Clojure.
|
| [0] https://github.com/redplanetlabs/specter
|
| Data driven languages need simple & powerful transformation
| libraries. `get-in` is repetitive and tiresome to use.
|
| Specter and it's ilk make transformations clear and simple.
|
| No amount of planning or foresight negates the need for data
| transformation libraries.
| [deleted]
| nanomonkey wrote:
| It's interesting to see so many people complain that it's hard to
| _hire_ Clojure engineers, when I 've had the exact opposite
| problem...trying to find a Clojure shop to join. They are few and
| far between, and the few that are hiring say that they will take
| folks that are new to Clojure, but then are baffled when you
| don't know how to idiomatically solve whiteboard problems.
|
| Clojure remedies all of my problems with previously used
| languages (Basic, C, Java, ObjC, Javascript, Python), in that it
| allows me to remove boilerplate and create layers of abstraction
| that are appropriate for problem solving. It's also a fairly
| opinionated language, preferring functional programming methods
| that work with how I like to solve problems. This is refreshing,
| as it feels like I can bypass all of the style wars that I
| encountered with Python., and the verbosity of C/Java/Obj-C. No
| longer being told to rewrite functional code as an object, by an
| engineering manager that only ever writes imperative scripts.
|
| Lastly I now love writing front end code in
| Clojurescript...something I never would have expected. Reagent
| and Re-frame are a dream for large complex SPAs, which while I
| dislike in principle, seem to be the trend in cross-platform
| GUIs.
|
| And it makes programming fun again!
| puredanger wrote:
| Both devs and jobs exist but they are mismatched in terms of
| geography and experience expectations. I don't think it's
| specific to Clojure, it's common to any narrow technology.
| Certainly things have gotten far better over the last 10 years
| and there are more companies hiring in Clojure more actively
| now than I've ever seen. Fixing it requires a feedback cycle
| that takes a long time to grow into an active market.
|
| When I first started in Java in 1997, there were few companies
| doing Java and few devs who knew it and it was much the same.
| Sun spent like a billion dollars marketing Java to create that
| ecosystem.
| newcrobuzon wrote:
| > Sun spent like a billion dollars marketing Java
|
| I guess now the question is if Nubank could/will also promote
| Clojure and to what extent (or if they will support Cognitect
| enough to do that). I would wonder if they went through that
| thought process and what RoIs for that are from their
| perspective.
|
| It might even take much lesser investment than equivalent of
| $1bil from 90s... The Java/JVM market is huge so it might
| need just a little nudge :)
|
| Within the JVM ecosystems it seems that basically Kotlin (as
| nice as it is) has been stealing some market share that might
| have belonged to Clojure. And all that just by selling some
| cheap cut syntax sugar on the corner.
|
| There definitely is a huge desire within Java/JVM community
| to innovate and if approached correctly Clojure could
| actually shine - there are just few misconceptions and fears
| that could be put to sleep by some smart marketing strategy.
| Nubank is great first step in that direction, because it
| gives an example of a mature large yet innovative company
| relying on Clojure in production.
| mumblemumble wrote:
| > And all that just by selling some cheap cut syntax sugar
| on the corner.
|
| I suppose you could dismiss a lot of what Kotlin adds as
| mere syntactic sugar. But it also makes some much more
| fundamental improvements. It provides a much cleaner,
| unified, _object-oriented_ type system. It provides about
| as sane an approach to null safety as is possible on the
| JVM. (Clojure 's is arguably better, but I'll concede that
| nil punning is not for everyone.) And it provides a clean
| set of core libraries that doesn't have nearly as many
| friction points and inconsistencies as the core JDK does.
| st3fan wrote:
| Clojure has no null safety. You may encounter it less
| because of the foundational building blocks you use in
| the language, but NPEs are most certainly there.
| mumblemumble wrote:
| Same for Kotlin, really.
| talkingtab wrote:
| This will probably earn me lots of negative points, but I used
| Java for eight years and after much initial enthusiasm came to
| despise it. It was the least productive language I have ever
| used. I have twice tried to learn Clojure and each time I have to
| install the JVM, I simply quit, despite being intrigued by
| Clojure itself. Sigh.
| st3fan wrote:
| "each time I have to install the JVM, I simply quit, despite
| being intrigued by Clojure itself"
|
| Weird - what is so problematic about installing a JVM? That is
| literally an apt-get or install away. If you are learning
| Clojure then installing the JVM should be the least of your
| problems.
|
| Note that there are a bunch of really nice Clojure starter kits
| available. And now many options for editors. For learning you
| don't need anything fancy, even a REPL will do to get you
| excited.
|
| If the JVM turns you off then yeah maybe not try out languages
| built on top of it.
| nanomonkey wrote:
| I found the best way to learn Clojure was to play around with
| Clojurescript. I have an allergy against javascript, so being
| able to write front end code in Clojurescript was a dream.
| There are a few differences, mostly due to the fact that your
| code is single threaded, but otherwise, what you learn will be
| applicable to later using with Clojure. I have to say I envy
| you, already knowing Java, as the hardest part of learning
| Clojure(script) has been interopt with the host language.
| aprdm wrote:
| Which one was the least productive language, Java or Clojure ?
| dgb23 wrote:
| Java, which is why they grew an aversion towards the JVM.
| aprdm wrote:
| I thought Clojure also required a JVM! Maybe to both haha
| dgb23 wrote:
| Yes, that was the point. They don't want to use Clojure
| because Java made them hate the JVM.
| aprdm wrote:
| Gotcha, thanks! bad reading from my part
| talkingtab wrote:
| It was Java. I was intrigued by some of the things with
| Clojure, especially transducers as described in the post by
| Rich Hickey https://cognitect.com/blog/2014/8/6/transducers-
| are-coming.
| nojito wrote:
| Reverse engineering a Clojure codebase after the devs maintaining
| it leave is an experience I wouldn't wish on anyone.
|
| Because of the difficulties of sharing knowledge, Clojure will
| have an extremely difficult time growing.
| bird_monster wrote:
| > The downside of Clojure is that you need good, wise
| developers...
|
| Is there a language that, for a sufficiently large application,
| you don't need wise developers? What is it? How?
| hangonhn wrote:
| Until recently, I would have said Java because it has so many
| guard rails and good frameworks. But then I've recently
| encountered bugs caused by code that basically disabled all
| those guard rails. Had any one of them been left in place, the
| bug wouldn't have happened. It's kind of amazing how clever
| some unwise bad engineers can be. There's just no replacement
| for good, wise engineers.
| bird_monster wrote:
| That's interesting. In my experience, Java is one of the
| easiest languages to turn the best of intentions into actual
| unusable code. I personally have never seen or heard about a
| large Java application being easy to work with or having good
| guard rails. It all kinda just becomes a big mess.
|
| I think that Java might have benefited the most from the
| industry hellbent on making microservices, in that Java
| applications are less frequently built as gigantic
| unmaintainable messes, but instead much smaller more easily
| digestible messes.
|
| I am clearly biased against Java, but having worked with it
| at several jobs I just don't think it's a good idea.
| bcrosby95 wrote:
| Java is OK if you don't drink the enterprise kool-aid. But
| you're definitely going against the culture surrounding the
| language if you don't.
| The_Colonel wrote:
| Interesting but I have the opposite experience.
|
| Java is weak in small scope and gets stronger with larger
| applications as it scales quite well in maintainability.
|
| In that sense adoption of microservice has hurt Java since
| you still need to do a lot of Java ceremony, tomcat +
| spring boot still starts up slow, you can't leverage
| superior IDEs to refactor interfaces across services etc.
|
| For thin microservices I would probably tend to use
| something like node.js, for traditional monoliths (IMHO
| still have their place) with a lot of complex logic I would
| use Java (or Kotlin, C#).
| hotcrossbunny wrote:
| Even better, think how much quicker you can achieve a
| sufficiently large application if you can source some really
| unwise developers?
| wolfadex wrote:
| In my 10 years of paid development, Elm. Because it's the only
| language of the 13+ I've used in production code where the
| compiler actually helps you.
|
| I've written C, C++, C#, Java, JS ES5+, ActionScript, HTML5 and
| CSS since IE6, many various compile-toJS languages, many
| different frameworks and more. Elm is the only language where I
| can jump into a foreign code base or my own months later and
| feel confident that I can change something, push to production,
| and not break things.
|
| edit: I've also written Perl and Ruby in production too.
|
| edit2: How does it help? When you make a change that isn't
| valid, like adding a new argument to a function, the compiler
| can tell you everywhere you need to make a fix and sometimes
| even suggest how to fix things. Add on top of that the editor
| tooling in Intellij or with the elm-langauge-server in VSCode
| and other editors and it's just super smooth. Build times are
| also crazy fast. There's no waiting for the compiler. The whole
| notion of "If it compiles, it works" I find to be true 99% of
| the time.
| jakebasile wrote:
| I've said it before, and I'll say it again. I will continue to
| write Clojure for a living as long as I am able to find a job
| willing to pay me to do so. I have never encountered a more
| pleasant environment to do my work. I think Clojure isn't going
| to "go away" any time soon as long as there are other people like
| me still around.
|
| I do think that Clojure shops (like all software shops) need to
| dial back the torture interviews / homework / tests, but that's
| really a bigger thing that just Clojure. I think more could be
| done to market Clojure to the non-believers, but I don't have
| specific ideas on how that could be done.
|
| You can take my parentheses from my cold, unemployed hands.
| bit_logic wrote:
| I'm a bit surprised to hear this, I thought Clojure shops would
| be better than this. It was must hard to find any candidates
| and they're still doing the stupid leetcode interview style?
| Are these companies putting any thought into their hiring
| process?
|
| That process was created by FANG because they can abuse their
| candidates and still get a lot of applicants (although I think
| this is less true than it used to be)
|
| But to use that same hazing ritual at a smaller company with
| the hiring funnel further reduced by a niche language? Really
| stupid.
| thrt23049away wrote:
| based on discussions i've had, i don't think Clojure is
| rare/unknown anymore, and the number of engineers vying for
| Clojure roles far outnumbers the roles available these days
| Scarbutt wrote:
| Did Clojure made you unemployed?
| jakebasile wrote:
| No, I am currently employed. It's a play on the "from my
| cold, dead hands" phrase.
|
| https://en.wikipedia.org/wiki/From_my_cold,_dead_hands
| bIAW7hAhDO wrote:
| Honest question: Why is clojure so much better than the rest?
___________________________________________________________________
(page generated 2020-12-10 23:01 UTC)