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

Clojure is cool

ahungry.com

Post reply on HN
Print view View original

131–133 of 133 posts

Re: Clojure is cool

#131

Post by dustingetz »

threatofrain wrote: post #130
dustingetz wrote: post #128

Earlier quoted context omitted.

I think that is a mistake, because data is universal but types and methods are not. Consider a value {"a": [42, 43]} - it could be mutable, immutable, persistent, optimized for ordered traversal, optimized for random access lookups, optimized for insertions.

From one perspective types and methods aren't universal, but data is, because once information arrives over the wire you aren't even initially sure if it is what you think it is. However, when backend and frontend code exists in the same context for analysis, aren't there enough certainties to know the space of possibilities for what you're going to receive? How much uncertainty precludes the useful sharing of types…

Well if I have EDN or JSON on the wire, and have the same portable Clojure library running on both sides, doesn't that pretty much accomplish the same thing as serializing actual object instances? Or is that what you meant all along?

Re: Clojure is cool

#132

Post by fulafel »

threatofrain wrote: post #92
dustingetz wrote: post #42

Earlier quoted context omitted.

Code-sharing between ClojureScript and Clojure is a killer app

Is code sharing actually a thing between the front-end and back-end? I find that almost all interesting code "re-use" comes from libraries.

You can have the shared source files in the same project with the CLJS front-end and Clojure back-end. This way, at development time, there is no friction related to updating different projects or release artifacts, you just live-reload the updated namespace in frontend & backend.

A common use case for the shared code is manipulating the application's domain data structures. Sharing the code for these manipulations is routine. In SPA apps you frequently do more than just render views for the backend, and then you typically want to have the backend's internal representation of the data at hand even at the frontend.

You can call it a library use-case of course, depending what unit of modularity you choose to call a library. But this way you don't have to update 3 projects for each change (app-backend, app-frontend, app-shared) and you can very flexibly refactor stuff into the shared namespace without breaking the normal flow of development.

Re: Clojure is cool

#133

Post by gnl »

squaredpants wrote: post #127
gnl wrote: post #120

Earlier quoted context omitted.

clojure.spec+generative testing help a lot, but yeah.

I love the clojure community efforts, but clojure.spec is so confusing and bloat-y to me. :( It reminds me of Frama-C and specification of C programs, which isn't exactly what I would want to do all the time to have some safety guarantees on my program. I feel that a strong type system would provide way more benefits.

Much as I love Clojure, I agree that clojure.spec, while very powerful, has a mess of a UX. That's why – shameless plug – I wrote Ghostwheel [1], which, to me, turns it into a whole other thing, especially when gen-testing, spec-instrumentation and tracing are used together.

Having inferred types in addition to this would be even better, but types are no replacement for generative testing or vice versa.

They really complement each other quite nicely, but also have a large overlap in terms of how much they can reduce the need to do manual debugging and enable clean changes/refactorings with minimal effort.

[1] https://github.com/gnl/ghostwheel

Post reply on HN