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

121–130 of 133 posts

Re: Clojure is cool

#121

Post by dustingetz »

dustingetz wrote: post #109
threatofrain wrote: post #92

Earlier quoted context omitted.

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.

The question is motivated by the observation that a set of REST webservices, and a set of React views that consume them, are so different that there isn't any code reuse. I'd ask you to note the parallel structure between them. They are two sides of the same data sync problem. Yes, of course there are common bits that can be factored out. The problem is that most people have never so much as thought about it, because…

React.js, if you squint, is also a step in this direction – React.js on the client can bind to a DOM, or run in Node and stream strings to a socket. In other words React decoupled HTML rendering from platform APIs by making it data driven. Data is universal and can be manipulated on any platform, even pencil and paper. What other platform APIs can be replaced by something data driven? I know from my study of Haskell that the answer is probably: all of them.

Re: Clojure is cool

#122

Post by sidcool »

lostcolony wrote: post #57
sidcool wrote: post #46

Clojure is something I have been wanting to experiment with, but not having types makes it very difficult for me to reason while coding. It's just me. I am used to thinking in types.

So speaking as someone who has been on both sides of that fence (and, honestly, prefers static or optional typing; Dialyzer for Erlang is probably my favorite approach there), I think a large part of that comes down to how types are used. In a very OO language, where you're encouraged to create a complex type for every function/method contract (i.e., I have a type of RoomMeasurement, that internally contains a list o…

Thanks for the detailed explanation.

Re: Clojure is cool

#123

Post by sergiotapia »

hnbroseph wrote: post #110
sergiotapia wrote: post #94

Earlier quoted context omitted.

You would think but they measured what they need and they are sure that Elixir is the right fit for their use case. They aren't a CRUD company, like 99% of others. They are doing freaky things with multiple freaky orchestrations with multiple freaky OLD-WORLD institutions. Rails aint gonna cut it.

that's 3x freaky... sounds serious!

it sounds freaky!!!

Re: Clojure is cool

#124

Post by ivan_gammel »

3rdAccount wrote: post #22
ivan_gammel wrote: post #12

Earlier quoted context omitted.

Exactly. Java code looks artificially bloated (who uses 8 spaces for tabulation anyway?!). Class CookieMap is completely unnecessary, for example - it extends the j.u.Map with couple operations, which could be easily done with Java 8 streams (looks like it's older version of language - diamond operator is not used).

There could be a counterpart here that Java as a language is so complicated that people often come up with these design patterns because they THINK they are necessary.

The comparison of programming languages must be done on equal levels of competence: it simply doesn't make sense to compare a code written by a junior after completing some online course with a code written by an experienced and well-educated engineer, because no conclusions can be made of that.

The fact, that people come up with such code very often is the general characteristic of modern IT job market, where demand is so high, that it eliminates all possible qualification barriers. This particular code is written so not because Java is too complicated, but because the author did not know the minimum required for professional software development on this language or have written it this way on purpose.

Re: Clojure is cool

#125

Post by vindarel »

dancek wrote: post #58
yogthos wrote: post #33

Earlier quoted context omitted.

The claims regarding JVM bloat are largely exaggerated, especially now that the JVM introduced modules. However, if it's not your thing it's worth noting that ClojureScript happily runs on Node. Here's an example of how easy it is to get up and running with https://github.com/yogthos/mastodon-bot

I'm working on my first Clojure project and find JVM to be painful (it starts very slowly and eats lots of RAM). I'd appreciate any tips on making JVM non-bloated.

Hey go with Common Lisp :D

Re: Clojure is cool

#126

Post by threatofrain »

dustingetz wrote: post #121
dustingetz wrote: post #109

Earlier quoted context omitted.

The question is motivated by the observation that a set of REST webservices, and a set of React views that consume them, are so different that there isn't any code reuse. I'd ask you to note the parallel structure between them. They are two sides of the same data sync problem. Yes, of course there are common bits that can be factored out. The problem is that most people have never so much as thought about it, because…

React.js, if you squint, is also a step in this direction – React.js on the client can bind to a DOM, or run in Node and stream strings to a socket. In other words React decoupled HTML rendering from platform APIs by making it data driven. Data is universal and can be manipulated on any platform, even pencil and paper. What other platform APIs can be replaced by something data driven? I know from my study of Haskell…

I'm quite curious as to when types and methods are going to be shared across boundaries.

Re: Clojure is cool

#127

Post by squaredpants »

gnl wrote: post #120
squaredpants wrote: post #3

nil is not. nil punning is a band-aid. Otherwise, I love the lang.

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.

Re: Clojure is cool

#128

Post by dustingetz »

threatofrain wrote: post #126
dustingetz wrote: post #121

Earlier quoted context omitted.

React.js, if you squint, is also a step in this direction – React.js on the client can bind to a DOM, or run in Node and stream strings to a socket. In other words React decoupled HTML rendering from platform APIs by making it data driven. Data is universal and can be manipulated on any platform, even pencil and paper. What other platform APIs can be replaced by something data driven? I know from my study of Haskell…

I'm quite curious as to when types and methods are going to be shared across boundaries.

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.

Re: Clojure is cool

#129

Post by dancek »

markc wrote: post #114
dancek wrote: post #58

Earlier quoted context omitted.

I'm working on my first Clojure project and find JVM to be painful (it starts very slowly and eats lots of RAM). I'd appreciate any tips on making JVM non-bloated.

Don't know about bloat fixes, but what does your workflow look like that JVM starts are annoying? My Emacs CIDER REPL comes up in 4 seconds (MB Pro 16G) and it's often many hours (even days sometimes) between restarts. But yes, slow starts are annoying if you're starting a JVM frequently. Can you change your workflow so that's not needed? Check out Component, Mount or Integrant.

This is a relevant answer. Thank you.

We're using Integrant already so yes, I can mostly work in a REPL without restarting. But the restarts are more like 15 seconds. I'll have to measure and see what's so slow. My rdev platform is Cursive on a 16G MBP.

And while I'm commenting, yes, we have a reason to run on JVM (a lot of legacy Java code we probably want to interface with later on). So thanks to other commenters for suggesting Node.js and Common Lisp, but not possible. :)

Re: Clojure is cool

#130

Post by threatofrain »

dustingetz wrote: post #128
threatofrain wrote: post #126

Earlier quoted context omitted.

I'm quite curious as to when types and methods are going to be shared across boundaries.

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

Post reply on HN