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
The Future of Clojure
111–120 of 309 posts
Re: The Future of Clojure
#112Earlier quoted context omitted.
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 r…
This sounds like a good place to learn. Might I ask the company?
This is a pretty good talk about this (don't think it's the same company): https://www.youtube.com/watch?v=7E4gF3KEwZ0
Re: The Future of Clojure
#113Having 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…
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.
Re: The Future of Clojure
#114Earlier quoted context omitted.
Have you considered core.match ? I’ve used it to dispatch API calls based on just data shape.
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 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.
Re: The Future of Clojure
#115Earlier quoted context omitted.
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…
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.
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.
Re: The Future of Clojure
#116Earlier quoted context omitted.
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. Whe…
> 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…
> 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.
Re: The Future of Clojure
#117Earlier quoted context omitted.
What is your process of learning it? Did you take the Pharo MOOC?
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 th…
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.
Re: The Future of Clojure
#118are there people who used both clojure and scala. And decided to use Scala ? if so why ? I'm new to Scala that's why
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.
Re: The Future of Clojure
#119Having 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…
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 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.
Re: The Future of Clojure
#120I'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…
? 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…
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