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

The Future of Clojure

thoughtworks.com

Post reply on HN
Print view View original

201–210 of 309 posts

Re: The Future of Clojure

#201

Post by rtpg »

techdragon wrote: post #199
rtpg wrote: post #197

Earlier quoted context omitted.

I think the libraries/standard collections having the functions they have is a _huge deal_. Some other example, Python and JS are both similar languages in many respects. But even something as simple as not having list comprehensions makes JS more fidgety when you're writing simple code. Python not having great utils for stuff like "give me this dictionary, but without these three keys, but keep the original dictiona…

What do you mean python doesn’t have good tools to select what you need from a dictionary and keep the original intact, you just use a dictionary comprehension and boom you’re done... new_dictionary = {__k: __v for __k, __v in original_dictionary.items() if __k not in {‘key1’, ‘key2’, ‘key3’}} (written on my phone without a repl to double check but the technique is sound and i use it all the time)

I disagree about this being good. I think this is ugly as sin. This is an aesthetics point but isn't most of this aesthetics anyways?

I want `select` and `dissoc`. I also would like for those to be performant (instead of requiring a bunch of copies). I don't want to have to choose between expressiveness and performance.

I don't write Clojure in the day-to-day but I think it hits those beats very well.

Re: The Future of Clojure

#202

Post by silly-silly »

fhsm wrote: post #191
mbil wrote: post #174

Earlier quoted context omitted.

Compared to other languages, I've found Clojure makes it much easier to iteratively turn an idea into code. Say you're writing a pure function... You start with just data and a sense of how the output might look. Let's say I have APIs providing me with a user record and a list of transactions, and I want to get that person's balance... Maybe you start with some canned data (let [person {:name "Matt" :id 12345 :curren…

How do I know if I’m really trying the repl/editor cycle? I mess with Clojure with some regularity and each time ultimately back away in a combination of frustration and nerd sniping self awareness as the ratio of editor setup blog reading meta work to actual work hits infinity. Either I am terrible at finding good setup guides or it’s pearls before swine and I just don’t get the aha moment. I’m starting to think it’…

Nah mate, Stay positive.

You're not the 'swine' here, you shouldn't feel that way. I've learned that sometimes paradigms require the programmer to be in the correct 'frame of mind' before it even begins to make sense, its not you.

In my limited experience, keeping an open mind to tools will get you much further and have more enjoyment in your career and life. Trying to force that square peg into the round hole will just make you hate new things. If the time comes and your mindset is right, the tech will still be there.

Re: The Future of Clojure

#203

Post by randompwd »

bcrosby95 wrote: post #177
jimbokun wrote: post #154

Earlier quoted context omitted.

> I've had to deal with some Java code that the ide was useless to help figure out. Spring annotations, maybe?

God I hate them. With annotations Java pulls off the rather unique trick of being both verbose and magical at the same time.

tbf, annotations aren't the blame. It's Spring's runtime magic with close to zero friendly figure-out-ability.

Re: The Future of Clojure

#204

Post by beders »

nojito wrote: post #44

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.

A bad codebase is a bad codebase. I can show you quite a few bad Java ones.

I just started to work on a quite large Clojure codebase and I had no trouble making meaningful contributions within a couple weeks.

Having mostly pure functions makes it especially easy to understand what is going on. I had similar concerns, and this myth is hard to kill - for any dynamically typed language - but the REPL is your secret weapon.

Re: The Future of Clojure

#205

Post by jjav »

throwaway92938 wrote: post #48
atdixon wrote: post #27

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…

> 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…

Agreed. I went through my phase of geeking out on Lisp and playing with programming languages for the sake of the language itself. But in the end it wasn't very satisfactory. I prefer building things.

At a later job my views got reinforced by a team who were so excited about Scala (many years ago when it was particularly bad, not sure if it is better now) and all the language tricks they could do in it. So we spent tons of time on "stupid programmer tricks" (Letterman-style) and debugging obscure language constructs, less time on the actual working product.

So I don't want clever programmers on my teams nor clever languages. Give me mature ecosystem, great tooling and simple code. Java and C remain the gold standard for getting things done.

Re: The Future of Clojure

#206

Post by Scarbutt »

beders wrote: post #192
pinchhit wrote: post #181

As a person who has and currently does work professionally in clojure (at multiple all-clojure shops): The smart engineer effect is extremely overblown. You will hire smarter-than-average engineers, but with a caveat that no one talks about: they are all self-selected for being people who enjoy tinkering on computer science problems to a fault, and not necessarily your business. So the breakdown is that you get 10 su…

> poorly-maintained clojure-ish libraries to paper over the java/javascript bits, which get out of date quickly. Care to elaborate? For example, re-frame, reagent have been stable, reliable libraries for years. In contrast to many JS libraries. JS interop has been virtually unchanged for years. What am I not seeing here?

Clojurescript relies on the closure compiler which doesn't play well with the Javascript ecosystem. Too much "busy work" https://dev.solita.fi/2020/06/25/taming-cljs-advanced-compil...

Re: The Future of Clojure

#207

Post by bitwize »

atdixon wrote: post #27

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…

Hot take: Lisp (including Clojure) is for shitty programmers.

Great programmers can be great in any language, including C, COBOL, or BANCStar. Their brainpower alone can compensate for the language's lack of abstractive power.

Lisp is a mind prosthesis for the programmer; it extends the programmer's reach. Unless you are working in a complicated, abstruse line of work, you stand most to benefit from this if you are bad at programming.

Hence, the most clamorous Lisp zealots tend to be terrible programmers in their own right. The "wise" programmers jeep plugging along in Java, because it's well-supported by a bigcorp and has a HUGE candidate pool when you need to hire developers who work in it.

Re: The Future of Clojure

#208

Post by [deleted] »

bIAW7hAhDO wrote: post #153
jakebasile wrote: post #130

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 in…

Honest question: Why is clojure so much better than the rest?

[deleted]

Re: The Future of Clojure

#209

Post by appletrotter »

lmilcin wrote: post #3
tharne wrote: post #2

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 see…

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 m…

I also work at a large bank, I can see why clojure wouldn't work for a bank. I would blame the bank for being incompatible with clojure more than the other way around though.

Re: The Future of Clojure

#210

Post by [deleted] »

sankyo wrote: post #180
bIAW7hAhDO wrote: post #153

Earlier quoted context omitted.

Honest question: Why is clojure so much better than the rest?

Everything is a function, functions are first class. REPL based development gives you instant feedback. lets you write a function in your editor and then run it, change it, run it again. If your idea of REPL is python or ruby, then you are not getting the entire picture. https://stackoverflow.com/questions/5671214/is-lisp-the-only... Immutable by default. This helps with debugging and solves thread safety. Feel free…

[deleted]
Post reply on HN