Live data from Hacker News

Clojure is cool

ahungry.com

81–90 of 133 posts

Re: Clojure is cool

#82

Earlier quoted context omitted.

Literally interviewed at a company that is doing the same thing. B series, clojure/scala codebase, moving away to Elixir Phoenix.

Seems pretty weird to suggest that if juniors are struggling with one niche language, moving to another would ever be the solution.

I believe that if a company wants to do software by throwing as much bodies at it as possible, they need to embrace it fully and openly. Going back to pure Java might be a good idea, as the language enables progress to be made in a "factory coding" environment pretty much by design.

(Not a judgement; this is a legit use case, even though not an environment I like to work in.)

Re: Clojure is cool

#83

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.)

Clear and descriptive function names, concise and non-clever code, and a judicious use of well-named and concise helper functions are all way more valuable than docstrings. IMHO docstrings should be used as a last resort if the problem domain is truly complex enough to warrant it.

Docstrings for trivial, well-named functions just get in the way, and if you feel the need to add a docstring to a complex function just after you've defined it, then I think that might be a hint that you should refactor the code to make it more clear and readable instead.

An ns docstring that describes the intent of the api and docstrings for the major public interface functions are a good idea, but a blanket "docstring for every function" rule is a crutch to make up for unreadable, poorly-written code.

Re: Clojure is cool

#84

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…

Here is just one example of what client/server code-sharing makes possible: Hyperfiddle apps are fully CLJC which means literally the same code runs in the browser for view things, the JVM for web service things, inside Datomic Peer for database things, also Node and soon lambdas. Since they all share the same code, they can coordinate I/O automatically and transparently. Never code network side effect ever again! http://www.hyperfiddle.net/

Re: Clojure is cool

#85
post #44

Earlier quoted context omitted.

Yep, like Java 1.4 running on Red-Hat Linux 5 deployments, where no one is allowed to touch beyond bug fixes and security updates.

I thought RHEL5 security updates were over right?

Yep, but I know of a few servers still running it.

Re: Clojure is cool

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

I agree, but it’s the best you can get if for some reason you’re stuck with Clojure.

Re: Clojure is cool

#87

Earlier quoted context omitted.

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…

Here is just one example of what client/server code-sharing makes possible: Hyperfiddle apps are fully CLJC which means literally the same code runs in the browser for view things, the JVM for web service things, inside Datomic Peer for database things, also Node and soon lambdas. Since they all share the same code, they can coordinate I/O automatically and transparently. Never code network side effect ever again! ht…

> literally the same code runs in the browser for view things, the JVM for web service things

No, it does not. The same Clojure code may be the source for both execution environments, but that doesn't mean that the code that runs (JVM bytecode or JavaScript in the browser) is remotely similar, follows the same rules, errors under the same conditions, or otherwise behaves similarly.

That's not an argument against code sharing. But please read the post you're responding to thoroughly before you post "I can write it once and run it anywhere" without a whole lot of asterisks after "anywhere".

Re: Clojure is cool

#88
post #79

Earlier quoted context omitted.

No, core.spec does not address the main issues with dynamic typing. It offers some neat stuff, but it is not a replacement for static typing.

Dude, Clojure is a dynamically typed language and always will be. If you don't like it use something else.

> Clojure is a dynamically typed language and always will be

I don't entirely agree with the "always will be," as Clojure is a very creative language that inspires a wide variety of experimentation, and core.typed is currently being actively worked on (as a PhD dissertation no less by the original author of core.typed), so there is ample room to think the future will offer good static typing abilities for Clojure.

Also, I find your response unnecessarily curt.

Re: Clojure is cool

#89

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…

That clojurescript snippet will issue a warning, is that way because of compiler performance reasons if I'm not mistaken.

Still, you get immutability by default and a nice std lib of functions, think of lodash/fp and immutablejs together but better since lodash and immutablejs can't be use together anyway.

than a language that claims to be cross platform but with semantics that change depending on the platform.

This is not true, on the contrary, Clojure[script] claims to embrace the host semantics and platform, is just that there is this capability to share some code between Clojure and Clojurescript that might be useful for some parts of your application, I don't think this is a killer feature of Clojure btw.

Re: Clojure is cool

#90

Earlier quoted context omitted.

Here is just one example of what client/server code-sharing makes possible: Hyperfiddle apps are fully CLJC which means literally the same code runs in the browser for view things, the JVM for web service things, inside Datomic Peer for database things, also Node and soon lambdas. Since they all share the same code, they can coordinate I/O automatically and transparently. Never code network side effect ever again! ht…

> literally the same code runs in the browser for view things, the JVM for web service things No, it does not. The same Clojure code may be the source for both execution environments, but that doesn't mean that the code that runs (JVM bytecode or JavaScript in the browser) is remotely similar, follows the same rules, errors under the same conditions, or otherwise behaves similarly. That's not an argument against code…

[deleted]
Post reply on HN