Live data from Hacker News

Clojure is cool

ahungry.com

101–110 of 133 posts

Re: Clojure is cool

#101
post #4
post #2

Similarly, I would whole heartedly recommend the Common Lisp macro system (having myself discovering how to use it a few days back). The power it gives to the programmer is unmatched by any other system I have ever used (except maybe forth)

The Clojure macro system is very similar to the Common Lisp one, arguably with some improvements- The Lisp languages in the Scheme/Racket family, on the other hand, have a different (more safety-oriented) approach to macros.

> very similar to the Common Lisp one, arguably with some improvements

Quite the opposite. Common Lisp macros are totally unrestricted, they don't auto-qualify names with the package. Also, there are user-defined reader macros in CL, unlike Clojure.

Re: Clojure is cool

#102

Anyone who writes Lisp without taking a moment to add a docstring to every definition would never get a job offer from me. (Not to mention comments as appropriate.)

If you have to write a comment to explain every definition, you've failed to make the code sufficiently readable and simple to understand IMHO. Code-level comments can become outdated without eagle-eyed code-reviewers. The code itself can never lie.

Comments are a useful for explaining the implementation logic of a function or method, for instance. Or for generating API documentation. And file-level comments explaining the purpose of the class or module are always handy.

Re: Clojure is cool

#103
post #4

Earlier quoted context omitted.

The Clojure macro system is very similar to the Common Lisp one, arguably with some improvements- The Lisp languages in the Scheme/Racket family, on the other hand, have a different (more safety-oriented) approach to macros.

> very similar to the Common Lisp one, arguably with some improvements Quite the opposite. Common Lisp macros are totally unrestricted, they don't auto-qualify names with the package. Also, there are user-defined reader macros in CL, unlike Clojure.

Well, auto-qualified names are a matter of taste. I agree 100% though that the CL reader macro system is a dream.

Re: Clojure is cool

#104
post #45

Clojurescript has been the real hero for me coming from a heavy Javascript background. The UI patterns are basically 1:1 with the functional standards in Javascript land, but you're working with a language that has immutable data structures by default (I can ditch Immutable.js) and the core library has all those goody functional helpers I'd include ramda or lodash for. But in addition to that, shadow-cljs is truly in…

BTW I've been using the new figwheel-main testing features that were released a week ago and love them: https://figwheel.org/docs/testing.html

Re: Clojure is cool

#105

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.

It's pretty awesome now that graph query languages (graphQL, etc) are so popular: Lots of reuse possibilities when you use the same query language for updating the browser state and also updating server side actions.

Re: Clojure is cool

#106

Earlier quoted context omitted.

Code-sharing between ClojureScript and Clojure is a killer app

Not really. Although Clojure and Clojurescript are both dynamically typed, Clojure is strongly typed while Clojurescript is weakly typed. Clojure: (+ "1" 1) ClassCastException java.lang.String cannot be cast to java.lang.Number clojure.lang.Numbers.add (Numbers.java:128) Clojurescript: (+ "1" 1) "11" They may be close, but that is all the reason for concern. There are a million ways that small semantic differences li…

I see your point, but I've never once run into any issues with these minor syntax differences when building libraries shared between clj & cljs.

Re: Clojure is cool

#107
post #45

Clojurescript has been the real hero for me coming from a heavy Javascript background. The UI patterns are basically 1:1 with the functional standards in Javascript land, but you're working with a language that has immutable data structures by default (I can ditch Immutable.js) and the core library has all those goody functional helpers I'd include ramda or lodash for. But in addition to that, shadow-cljs is truly in…

ClojureScript is basically an s-expression version of the good parts of JavaScript with lodash built in. It’s pretty cool. That said, if you don’t mind losing the benefits of s-expressions and macros, you can get mostly the same experience in vanilla JS. And even then there’s sweet.js which can get you part way there.

Re: Clojure is cool

#108

Earlier quoted context omitted.

And studies show that the number of lines of code a developer puts out in a day is basically constant across all languages. This is usually cited as an argument for more expressive languages. But if bug count is proportional to LOC and LOC per day are constant across all languages, then bug per day will also be constant across all languages. You can write shit code in any language. I used to think Java made it harder…

If bug count is proportional to LOC and LOC per day are constant across languages, then bugs per day might be the same. But you'd still expect features to be getting implemented at a higher rate, and you'd expect a lower bug count per feature. That's ultimately the metric that's most interesting from a business perspective. IME, the bugs are also easier to deal with in the more expressive language. They tend to be th…

> But you'd still expect features to be getting implemented at a higher rate

Yes, I'm inclined to agree, but I actually haven't ever seen a study which compares the same project implemented in different languages to establish in toto the variance in SLOC. It could be the case that in the main for the same project the differences between languages wash out, as different languages may have different advantages and disadvantages that are more likely to tell on a substantive project.

What you suggest seems reasonable, but I simply don't know it to actually be the case.

Re: Clojure is cool

#109

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.

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 of the language barrier, and other barriers – for example teams are structured around this artificial divide of frontend and backend. You need a new architecture to take advantage of the parallel structure. GraphQL is just the beginning.

Re: Clojure is cool

#110
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.

that's 3x freaky... sounds serious!
Post reply on HN