Live data from Hacker News

Clojure is cool

ahungry.com

111–120 of 133 posts

Re: Clojure is cool

#111
post #53

Earlier quoted context omitted.

Looks like a big waste of time and resources. They're probably just trying to use the "coolest" thing without worrying about delivering things.

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.

Fair enough. I personally think that companies for which the choice of technology is gonna be the primary factor to success are as common as unicorns. I have never seen a company fail because they picked the wrong language/tech stack. But hey, if they've measured, they probably know what they are doing.

Re: Clojure is cool

#112

Earlier quoted context omitted.

In my experience ease of reading code is not a function of verbosity, but a function of familiarity. And in the general case verbosity and cleverness are orthogonal properties.

> In my experience ease of reading code is not a function of verbosity, but a function of familiarity. You would think so, sure. I used to write Perl code and I was extremely familiar with it and it used to be pretty easy for me to hack a script. Going back after couple of months and trying to understand it though, was a totally different animal. You can argue that it was my fault for writing bad Perl code, but ask a…

Perl is an elegant, artfully designed language based on linguistic context. If you don't grok it don't use it.

Re: Clojure is cool

#113
post #64
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.

Logically, don't use Clojure & the JVM if you want to avoid bloat. Try LFE, Lisp Flavored Erlang: http://lfe.io/ or SBCL: http://sbcl.org/ Just a recommendation if you want to avoid the JVM bloat issues, which are real and have existed since the JVM was developed peace

Don't underestimate Erlang's capacity for eating-up all the RAM on a machine in very quick time. Those lightweight processes start to add up if left unchecked. At least the JVM establishes an upper limit on memory use from the outset.

Re: Clojure is cool

#114
post #58
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.

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.

Re: Clojure is cool

#115
post #6

So... awful and bloated Java code (with javadocs, why?!) compared to short counter-examples from Clojure. IMHO quite terrible way to compare the two…

Ah, ill will or using Java as a punching bag was not my intent at all. I was working on this task, and the Java code I referenced was based on a popular Gist to accomplish the same task that I needed to accomplish, with many comments of users adapting (copy/paste programming) the same code for their usage. I felt an 'in the wild' solution was comparable to my novice-level Clojure solution (those more well versed in Clojure would likely write a much better implementation of what I did). This was meant to be a real world use case where I found my problem solved in Clojure turned out much better than it would have been solved in another language running my choice environment (JavaFX), instead of some arbitrary contrived examples (see Rosetta Code for tons of that).

Re: Clojure is cool

#116

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…

[deleted]

Re: Clojure is cool

#117
"Clear, readable, and concise code"??

I recommend everyone to once in a while try to debug Clojure code written by somebody else. Afterwards you will understand that this is a write once, read never language. It is an unmaintainable mess of overly clever recursive subroutines. It has some nice experimental ideas for concurrency. But basically all useful ideas are also available in Java nowadays. I wouldn't waste my time on it.

Re: Clojure is cool

#118
post #55

Earlier quoted context omitted.

For Clojure, check out Ghostwheel [1] - a lightweight DSL for writing specs. If you want proper static typing though, ReasonML might be a good choice. Static, compiles to js and native, super easy to learn, and there’s an experimental Lisp frontend with Clojure-like syntax if you can’t live without paredit. [1] https://github.com/gnl/ghostwheel

To me, core.spec has valid uses, but not as a replacement for static tying.

Author of Ghostwheel here – clojure.spec is certainly not a replacement for static typing, but it goes a long way to covering many of the same use cases, in fact longer than one might think at a cursory glance.

With Ghostwheel you write your function specs similar to how you'd write a type signature and you get automatic generative testing (including higher order function support) and side effect detection which – when combined with spec instrumentation (+ the upcoming evaluation tracing for the test execution) – can often tell you quite precisely where you screwed up in a much more immediate and granular manner than a simple unit test or mucking about in the REPL could. It really is a quite different experience from plain Clojure.

That being said, I'd love types in addition to this and I'm keeping a keen eye on ReasonML.

Re: Clojure is cool

#119

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

On the contrary, nil punning seems exceptionally well suited to a dynamic language. In general, I'm only burned by nil propagating into Java, almost all Clojure code seems to handle nil appropriately. I'm unsure of a good way to represent optionality in a dynamic language without a static type system. Or rather, doing so with the tools available -- core.match vs real pattern matching -- seems rather un-ergonomic. I'm…

Have some monads and stuff: http://funcool.github.io/cats/latest/#maybe
Post reply on HN