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

191–200 of 309 posts

Re: The Future of Clojure

#191

Post by fhsm »

mbil wrote: post #174
bIAW7hAhDO wrote: post #153

Earlier quoted context omitted.

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

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’s the latter.

Re: The Future of Clojure

#192

Post by beders »

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?

Re: The Future of Clojure

#193

Post by [deleted] »

discreteevent wrote: post #149
fractionalhare wrote: post #134

Earlier quoted context omitted.

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

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

[deleted]

Re: The Future of Clojure

#194

Post by ballpark »

adamkl wrote: post #114
ashtonkem wrote: post #82

Earlier quoted context omitted.

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".

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

A good post on the Expression Problem, and the benefits of Clojure's solution to it: https://eli.thegreenplace.net/2016/the-expression-problem-an...

Also, I agree, it's interesting to hear his experience report.

Re: The Future of Clojure

#195

Post by kingdomcome50 »

wolfadex wrote: post #80
bird_monster wrote: post #50

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

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

Any statically typed language allows for a compiler to detect breaking changes like you describe. That’s the point!

Re: The Future of Clojure

#196

Post by ballpark »

mumblemumble wrote: post #119
gorjusborg wrote: post #113

Earlier quoted context omitted.

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.

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…

I think I would find it great fun to take a Clojure codebase like this one that you inherited and refactor it to something workable and maintainable! I agree it's probably not a job for a Clojure newbie.

Re: The Future of Clojure

#197

Post by rtpg »

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…

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 dictionary intact" (Clojure has dissoc for this) also makes it a bit fidgety compared to Clojure.

"You can write all of this" maybe, but at one point you're really going upstream from the base language.

Re: The Future of Clojure

#198

Post by rtpg »

hailwren wrote: post #70
bambataa wrote: post #55

Earlier quoted context omitted.

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?

I argue that Clojure née 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 bo…

I have something to tell you about CS researchers and whether they are actually good software engineers......

Seriously though, there are loads of papers out there that use ML variant programming languages (and not _about the language_) that I really wonder what papers you have been reading.

Let's not even get to all the older expert-system papers with stuff written in Prolog.

And yeah, loads of seminal CS papers are effectively just math.

Re: The Future of Clojure

#199

Post by techdragon »

rtpg wrote: post #197
sankyo wrote: post #180

Earlier quoted context omitted.

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…

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)

Re: The Future of Clojure

#200

Post by taeric »

jimbokun wrote: post #154
taeric wrote: post #19

Earlier quoted context omitted.

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

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

That and just over "abstracted" code that honestly feels like a strawman that someone made to argue against abstractions. :(
Post reply on HN