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

Clojure Turns 15 panel discussion video

youtube.com

Post reply on HN
Print view View original

201–210 of 226 posts

Re: Clojure Turns 15 panel discussion video

#201

Post by yladiz »

johannboehme wrote: post #185
hota_mazi wrote: post #149

Earlier quoted context omitted.

Clojure users fighting against static typing are on the wrong side of history. They are fighting a side for all the wrong reasons, and they will lose. There is a reason why all dynamically typed languages today are scrambling to add some form of static typing to their language, but never the other way around. Static typing does everything dynamic typing does, but better, faster, allow automatic refactoring, faster pr…

You are wrong. https://www.youtube.com/watch?v=YR5WdGrpoug Static typing only leads to devs trying to press the real world in stupid arbitrary categories.

Yeah and spec isn’t trying to press the real world into arbitrary categories? /s

The thing is, having some structure in terms of types or data shape constraints helps you model and understand your program. You can change them as your understand of your program changes or the need arises. You can be against static types because they force you to slow down and think about things before you can just get to coding, and it can be sometimes annoying to model your system using them (and sometimes not so useful), or other technical reasons like some type systems don’t allow you to model certain things, but to say it just leads to devs putting the real world into stupid, arbitrary categories when the real world (and your program!) primarily have data that can be trivially categorized because that’s what Rich Hickey said makes you sound like cargo-culting or parroting a point without diving deeper into the specific reasons and potential counterarguments.

Re: Clojure Turns 15 panel discussion video

#202

Post by ballpark »

ilkhan4 wrote: post #143
maxfurman wrote: post #97

Earlier quoted context omitted.

There is something about the language and/or community that leads folks to build their own X instead of collaborating on a common open-source version of X. Perhaps the lisp learning curve is high enough to dissuade those who want to contribute to a project but don't yet know Clojure?

I have a pet theory that it's because it's too easy to write code in. I think there needs to be just enough pain with a language or library that it becomes worthwhile to allow someone else to write X and just deal with it being imperfect if it still solves your problem.

too easy and too fun.

Also, to anyone interested in this problem, look for the Worse is Better paper

Re: Clojure Turns 15 panel discussion video

#203

Post by huahaiy »

kbuchanan wrote: post #69
BaculumMeumEst wrote: post #7

I love Clojure the language but I’ve never seen a more fragmented ecosystem. There seems to be a pattern in the language of “a problem emerges > a community solution gains traction > Cognitect develops their own solution but its weird and undocumented”, like deps.edn over leiningen, spec over malli, pedestal over ring, etc. Many prominent clojurists recommend deps.edn over leiningen and socket repl over nrepl, but I’…

I think the bottom line with Clojure is it's not an ecosystem well-suited for non-veteran programmers. For as simple as the language is, effectively using Paredit, navigating partially documented libraries, diving into source code to see how things interact—it's tough as a new developer. I don't believe Clojure is overtly hostile to newcomers; it's just crafted by veterans, for veterans. And this is the result.

Not really.

Our experience is that Clojure is a very good language for newcomers to programming as a profession.

In fact, we almost exclusively hire new computer science graduates. None of them had heard of Clojure before joining, and the vast majority of them became useful in 2 weeks, and become productive in a few months. What you described as barriers are the things that got sorted out in the first day when they join.

We do not hire veterans unless they already know Clojure. These people need to unlearn stuff, some of them are resistant to changes, so we don't bother with them.

Re: Clojure Turns 15 panel discussion video

#204

Post by goldrake »

yladiz wrote: post #201
johannboehme wrote: post #185

Earlier quoted context omitted.

You are wrong. https://www.youtube.com/watch?v=YR5WdGrpoug Static typing only leads to devs trying to press the real world in stupid arbitrary categories.

Yeah and spec isn’t trying to press the real world into arbitrary categories? /s The thing is, having some structure in terms of types or data shape constraints helps you model and understand your program. You can change them as your understand of your program changes or the need arises. You can be against static types because they force you to slow down and think about things before you can just get to coding, and i…

IMHO, external schema to validate structures at entry point is the way to go.

We have to have both: types and external schemas in oo languages.

Plus, types make working with maps cumbersome and force you to maybe unnecessary data cages called dto-s

Re: Clojure Turns 15 panel discussion video

#205

Post by yogthos »

__jem wrote: post #199
yogthos wrote: post #194

Earlier quoted context omitted.

Could you elaborate on that. Why do you find s-exp syntax more tedious to read than other types of syntax?

When I look at Clojure code, it just looks like noise, all the forms look the same. For example, a let and a doseq at first glance might look almost identical in terms of their "shape." In something like Java, a for-loop "looks" like a for-loop, there's nothing else in the language that looks quite like it. If I see a series of chained lambdas, there's an extremely high chance I'm looking at a stream, etc. The syntax…

I agree that it's possible to write dense code that's hard to read with Clojure, but that is true in any language. I've seen plenty of Java codebases that I couldn't make heads or tails of. As you point out, well written Clojure often reads like plain English. So, in my view it's just a matter of making the effort to write readable code on the part of the developer.

Re: Clojure Turns 15 panel discussion video

#206

Post by vfclists »

ivanb wrote: post #174

The ultimate failing of Clojure as a tool is its inefficiency measured in $ per feature. The language is not very approachable for junior programmers. You can grab a Python programmer and graft them on a Java or TS project and the same week they will deliver features and bugfixes. Reading other's people code in Clojure is much harder especially when coming from imperative world. The language is terse. The documentati…

Clojure is not Go or Python

Re: Clojure Turns 15 panel discussion video

#207

Post by gsinclair »

hota_mazi wrote: post #153
gemstones wrote: post #45

Earlier quoted context omitted.

Clojure is really good at self-selecting for people that really care about innovation in programming languages. The other jobs in a tech company care about innovation in their domain. They rarely align. So for every weird, cool innovation you see, the productivity is immediately lost because people equally care about how you deal with state on app startup, or routing, or database interaction. And since none of those…

> Clojure is really good at self-selecting for people that really care about innovation in programming languages. This is a very pompous, pretentious, self-serving, statement. How about Rust? C++? Kotlin? F#? You find people interested in these things in all languages, and people not interested in these things in all languages.

Perhaps it’s pompous etc. but it could still be true.

Bringing Rust or C++ or anything else into it doesn’t shed light on the truth or otherwise of the original statement.

Re: Clojure Turns 15 panel discussion video

#208

Post by KingMob »

zcam wrote: post #179
logistark wrote: post #59

I have the feeling that after Nubank bought Cognitech, Clojure has gone to stagnation. I mean, i feel that promoting and improving Clojure is no longer a priority. And another think that stinks me everytime Cognitech talks about Clojure they have to bring to the table Datomic. They tried to push Datomic on my company long time ago when they do some consultancy job at my company. You can skip all the talk, because is…

All the things you are mentioning would be nice to haves but frankly nothing prevents us to use these today already, either directly or via a bit of wrapping. Communication "style" and slow pace is frustrating sometimes but that's a small price to pay for all the positive facets of the language/community. I used to be more critical of these but I don't care anymore, the community is wonderful, the language is very us…

Which of the datalog alternatives do you think is closest? And how much of an improvement do you think a datalog db is over boring Postgres or SQLite? I’ve been weighing what db to adopt.

Re: Clojure Turns 15 panel discussion video

#209

Post by KingMob »

nocman wrote: post #165
puredanger wrote: post #117

Earlier quoted context omitted.

It's been kept up to parity but a complete rewrite is currently under way - watch https://dmiller.github.io/clojure-clr-next/

I thought about doing some work on Clojure itself, but, alas, my last name isn't Miller. :-( jk

The Clojure development process is notoriously closed to outsiders.

Even in the early years, some people contributed time and code, and weren’t thanked. I would view attempts to contribute as very high risk for newcomers.

I personally maintained a fork for a couple years just for an unmerged patch I needed, rather than try to get the core team to merge it.

Re: Clojure Turns 15 panel discussion video

#210

Post by KingMob »

jgoodhcg wrote: post #119
college_physics wrote: post #95

Clojure fans seem quite taken to hyperbole. If the language is such a "joy", "ultra-productive" etc I would have expected after such a long period of existence some major open source project to be showing off what the language attributes allow you to do. Happy to stand corrected if there is such a slam-dunk showcase that I've missed, I am actually interested to dig into clojure, if nothing else as a way to deepen my…

I think the Roam Research style backlinked knowledge management apps are directly enabled by datascript. Two "copy cats" (not meant to be derogatory) of Roam that are open source are: https://github.com/logseq/logseq https://github.com/athensresearch/athens The underlying in memory datalog style database that can run in the browser that enables these apps https://github.com/tonsky/datascript

Athens is dead btw. Logseq ate their lunch.
Post reply on HN