Live data from Hacker News

Why Clojure?

blog.cleancoder.com

191–200 of 202 posts

Re: Why Clojure?

#191
post #190
post #53

Earlier quoted context omitted.

My previous startup (CircleCI) was written in Clojure, my current one (Darklang) is written in OCaml. I decided not to use Clojure again because it's not statically typed, and my number one frustration when I coded in the CircleCI codebase was that it was very very hard to know what shape a value had, and whether it could be null. OCaml certainly has a lot of flaws, and is not nearly as "nice" a language as clojure,…

Ghostwheel to the rescue (>defn my-fun [a b] [int? -> int?])

I haven't seen anything to like in Clojure spec. Maybe I don't get it, but i really dont get it.

Re: Why Clojure?

#192

Earlier quoted context omitted.

I have no idea what darklang is (your site has zero information), but what made you opt into OCaml out of all of the options out there? Any previous experience with it prior to this?

Ah, sorry about that. The blog is better at the moment ( https://medium.com/darklang ) but we're updating the site in the very near future. OCaml was because I had experience with Haskell and didn't like it, and with Elm, which I did like. We tried it for a while as an experiment and it worked really well.

This whole subhread and this Elm mention are really interesting, thanks. Elm is a frontend language where I really understand the benefits of static more, because you're in a fairly controlled environment and your program isn't talking to a christmas tree of type system defying external services.

But for backend, the benefits of static sound attractive to me only on a program/product that is dominated by its internal business logic and has less interfaces to the unpredictable and constantly changing outside world. I think Darklang may be like this, from looking at the medium.com link?

Re: Why Clojure?

#193
post #57

Earlier quoted context omitted.

Not original poster, but my take is: - Immutable data-structures with concise literals for lists, vectors, maps, and sets. Having pure functions and immutable data-structures makes code easier to reason about, easier to test, and thread-safe. (But clojure doesn't "force" you to be pure. The idea is that you write as much of your code in pure functions as you can, and push the IO and impure parts to the extremities. I…

The above posters point on Homoiconicity is a big one, here is a quick (and silly) example for anyone unfamiliar with the term. Take the following clojure: (+ 1 2) => 3 Here the ( ) delimits, a list, and as the blog post says most lists are function calls. In this case the function is + and it's params are 1 and 2. It means if we do this (1 + 2) We get an exception that 1 isn't a function... However, we can tell Cloj…

Is there a way to simplify the `swap` function? E.g. in JavaScript it is just

    swap = (x,y,...rest) => [y,x,...rest]

Re: Why Clojure?

#194

Earlier quoted context omitted.

Why not just do that as a function though? Why use a macro?

Because function arguments are evaluated before the function itself. In this case, that evaluation would fail because numbers do not implement IFn, and hence cannot be called. Macro arguments are not evaluated, and so this works. You could make it a function, and pass the arguments quoted, but it'd be more cumbersome.

I have just tried it in REPL and got this cryptic error:

    cljs.user=> (defmacro swap [x] (list (second x) (first x) (last x)))
    #'cljs.user/swap
    cljs.user=> (swap (1 + 2))
    Execution error (Error) at (:1).
    1.call is not a function

Re: Why Clojure?

#195
I've been programming in Lisps on and off since the mid 80's, and I like Clojure the language, but in recent times as mostly as .Net programmer, I find the JVM and the surrounding Clojure tooling rather baroque. I find tutorials often cover Clojure/Lisp basics, but assume that you're coming from the Java world, so I had some difficulty getting what I consider basic workflows working as expected. If homoiconicity/macros/eval isn't an issue, I'm happy with F#/C# for the most part, but wouldn't mind having Clojure in the toolchest as well, but I'm not sure of the state and maintenance of Clojure.net.

Re: Why Clojure?

#196
>> Robert C. Martin: Smalltalk was also an image based language. Very few programmers have ever wrapped their minds around what that really meant. So, unfortunately, the language languished compared to all the text-file based languages. Where is the evidence?

Back in the 1990's IBM taught many of their consultants Smalltalk, and researched what made learning Smalltalk difficult —

Smalltalk, although recognized as a good platform for rapid prototyping and software reuse, is widely regarded as difficult to learn. Unlike learning a procedural language like Pascal or C, learning Smalltalk is dominated by browsing and code comprehension. Learners of Smalltalk typically experience a long, slow start-up phase in which they become familiar with the class hierarchy and object-oriented computational model but do little meaningful work (our colleague Dave Smith calls this "climbing the Smalltalk mountain").

Programmers having to wrap their minds around the class hierarchy and OO was seen to be the problem.

Re: Why Clojure?

#197
post #173

Earlier quoted context omitted.

That's interesting do you have any idea why the mental load jumped? would a static analysis tool working with your type hints help? Or is there many things to consider at once in the system instead of many individual things?

The biggest issue I keep running into is just the concept of data "shape". I love that clojure gives you so much freedom but it can be quite the footgun in a large system because you see that a function expects a map with keys :foo, :bar, and :baz but what are the values for those keys? Spec helps a little bit here for primitive values but for complex nested structures (e.g. {:a [{:b [1 2]} {:c "bar"}]}), it doesn't…

Totally not saying "you're holding it wrong", but maybe once you're more than a few couple levels deep into a nested map it's time to look at an in memory db like [Datascript](https://github.com/tonsky/datascript)? Actual Datalog queries can replace get-in vectors growing out of hand, and you also get better mutations with transactions.

Re: Why Clojure?

#198
post #22

Earlier quoted context omitted.

I know that part :) What module is it referencing?

docjure https://github.com/mjul/docjure

I like the suggestion in namespace aliasing in https://stuartsierra.com/2015/05/10/clojure-namespace-aliase...:

As a general first rule, make the alias the same as the namespace name with the leading parts removed.

  (ns com.example.application
    (:require
     [clojure.java.io :as io]
     [clojure.string :as string]))
Keep enough trailing parts to make each alias unique. Did you know that namespace aliases can have dots in them?

  [clojure.data.xml :as data.xml]
  [clojure.xml :as xml]
Eliminate redundant words such as “core” and “clj” in aliases.

  [clj-http :as http]
  [clj-time.core :as time]
  [clj-time.format :as time.format]
Then you can see immediately what `d` is...

Namely:

  (require '[dk.ative.docjure.spreadsheet :as spreadsheet])
(You would still not know the library and might have to ask the same question, but it makes more sense.)

About `d`:

There are always exceptions. For example, some namespaces have established conventions for aliases:

  [datomic.api :as d]

Re: Why Clojure?

#199

I've been programming in Lisps on and off since the mid 80's, and I like Clojure the language, but in recent times as mostly as .Net programmer, I find the JVM and the surrounding Clojure tooling rather baroque. I find tutorials often cover Clojure/Lisp basics, but assume that you're coming from the Java world, so I had some difficulty getting what I consider basic workflows working as expected. If homoiconicity/macr…

You also have ClojureCLJ, although the tooling and libraries around aren't as nice as on the JVM (many libraries and even clojure.core functions directly interoperate with Java).

Re: Why Clojure?

#200
post #71
post #63

Earlier quoted context omitted.

Ive been doing various methods of js dev with tons of different framworks and traspilers for 20 years, nothing is more pleasant to work with than ClojureScript and re-frame once you learn it. It's the best of all the worlds, and the DOM is very abstracted away via React. State transition is a breeze with immutable data structs. Theres only 1 language to write, no JSX ugliness.

I have had a similar experience over the past 15 years. re-frame is absolutely wonderful.

+1
Post reply on HN