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

161–170 of 226 posts

Re: Clojure Turns 15 panel discussion video

#161

Post by kccqzy »

lenkite wrote: post #52
kelseyfrog wrote: post #37

Earlier quoted context omitted.

Clojure user here since 2010(my earliest Clojure project on Github), and while I agree with the fun point, the iceberg wart for me at this point is the inelegance of the interface hierarchy and its structure behind the scenes. Clojure's forward-facing interface (a hundred functions that operate on one data structure) ended up breaking down for me at some point and became 10 functions on 10 data structures and those d…

Lets say that someone wants to improve on Clojure and make a better functional, immutable LISP! What should they start with ? Some things I miss is type support (for easy refactoring, auto documentation and performance), (small) native compilation, support for mobile platforms and their UI's, first-class web-assembly support, real structs and misc things like performant implementations for `first`, `last` and other c…

Are you really suggesting type support? I don't mind types but I think spec is more in the spirit of Clojure. Have you taken a look at it? https://clojure.org/about/spec

Re: Clojure Turns 15 panel discussion video

#162

Post by cutler »

dgb23 wrote: post #29
ndr wrote: post #12

Earlier quoted context omitted.

For you and anyone else with experience, is that the most common/battle-tested cljs stack? What about servers-side, any equivalent Django or FastAPI?

If you want a complete, integrated "stack" that stitches some of the most common libraries together in a uniform structure you might have a look at kit: https://kit-clj.github.io/

If you're coming to Kit from Luminus make sure you understand Kit's use of Integrant which involves passing `query-fn` down from the route to every function which accesses SQL. It was a deal-breaker for me.

Re: Clojure Turns 15 panel discussion video

#163

Post by nocman »

revskill wrote: post #8

I tried Clojure, but when i look for a good ORM, what i see is a paid library.

Rich Hickey said it best:

"ORM's provide 'OH MY GOD' complexity"

(from his "Simple Made Easy" talk - I might have the quote only 90% correct, but it's pretty darn close to that).

Re: Clojure Turns 15 panel discussion video

#164

Post by cutler »

munro wrote: post #127

I could be reading the energy wrong, but damn it looks corporate bullshit sucked the life out of Rich

He certainly looks and sounds older. Rich seemed to ride the wave of Clojure's early success with a succession of brilliant presentations. Then .... nothing.

Re: Clojure Turns 15 panel discussion video

#165

Post by nocman »

puredanger wrote: post #117
runevault wrote: post #98

Earlier quoted context omitted.

How is Clojure for dotNet? I haven't touched Clojure in general for years (honestly I think it's been at least a decade) but I remember a lot of libraries making calls expecting the Java standard library so seems like things would have broken, but maybe it is gotten a lot better in recent years.

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

Re: Clojure Turns 15 panel discussion video

#167

Post by cutler »

dgb23 wrote: post #18
revskill wrote: post #8

I tried Clojure, but when i look for a good ORM, what i see is a paid library.

Typical ORM's are a mismatch for Clojure. Two pretty good options to generate SQL are honeysql and hugsql. They both attack the problem from two different directions.

HugSQL is great if you like to deal with your SQL directly.

Re: Clojure Turns 15 panel discussion video

#168

Post by cutler »

patrickthebold wrote: post #65
revskill wrote: post #8

I tried Clojure, but when i look for a good ORM, what i see is a paid library.

https://www.hugsql.org/ seems pretty nice. Not exactly an ORM, but probably does what you need.

I'd go further and say it's nothing like an ORM. It's just a library for passing values to an SQL query.

Re: Clojure Turns 15 panel discussion video

#169

Post by lenkite »

__jem wrote: post #135
kelseyfrog wrote: post #79

Earlier quoted context omitted.

> But what is your take on what needs fixing ? I appreciate that it's a bit frustrating to have someone vaguely identify an area of concern and clarification and actionable suggestions are much more valuable. There's two things. One is that the data structure ontology[1] is difficult to internalize because of its complexity. When I write Clojure code, I consider the capabilities of the data structures being passed to…

I don't want this to sound hostile because I have a similar love/hate relationship to Clojure, I truly don't understand what you're arguing. Or, it seems like your issue is with lack of static types rather than an issue with the implementation? I've written a lot of Clojure and have an okay to pretty good understanding of the implementation, but it's just hardly ever relevant to the code I write, so I still don't tot…

I think he is arguing for more protocols than simply sequence. That is a sequence can be attributed fine-granular capabilities represented by protocols and that allows generic functions to be tailored towards those capabilities for improved performance.

Re: Clojure Turns 15 panel discussion video

#170

Post by chitowneats »

hota_mazi wrote: post #149
bcrosby95 wrote: post #77

Earlier quoted context omitted.

If you want an easy win, one thing Rich mentioned in a talk is - if he had to do Clojure all over again today - he would put transducers at the 'bottom'. For data transformation this makes the underlying collection type largely immaterial. > real structs I'm not even sure if value types are conducive towards immutable, persistent data structures. I'm certainly excited for project Valhalla but I'm not sure if Clojure,…

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…

I understand the point you're making, and that you wanted to make it dramatically. I got a nice belly laugh thinking about my future grandchildren chastising me for forsaking static types:

"All your life's work for naught, Pepaw. If only you had been on the right side of history".

I do have a substantive disagreement with this statement: "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".

Languages like C#, Java, Scala, and Typescript have all adopted some degree of type inference. Their users wanted it for a long time. To begin with, none of these languages are anywhere near as strictly-typed as a language like Haskell. Clearly even developers on "the right side of history" don't want to maximize static type checking in all cases, so the issue is not as cut and dry as you make it sound.

Post reply on HN