Earlier quoted context omitted.
I don’t think the only alternative to Haskell types is manually checking your program for consistency. For one thing, Clojure has type analysis: spec. Also, as pointed out in the article, you can also write tests.
Haskellers can and do write tests. +----------+-------+-------+ | Language | Tests | Types | +----------+-------+-------+ | Haskell | Yes | Yes | | Clojure | Yes | No | +----------+-------+-------+
Why Clojure?
81–90 of 202 posts
Re: Why Clojure?
#82Earlier quoted context omitted.
Clojure has nothing at all to do with Haskell. I can't think of two more opposed camps in programming.
Well, they have immutable data and persistent collections in common. Otherwise, agreed.
OP said no wrong, but think about it: Bitcoin also just stole the good parts from other software projects.
Really practical inventions usually gather the best ideas from a field.
Re: Why Clojure?
#83Re: Why Clojure?
#84Earlier quoted context omitted.
I don’t think the only alternative to Haskell types is manually checking your program for consistency. For one thing, Clojure has type analysis: spec. Also, as pointed out in the article, you can also write tests.
Haskellers can and do write tests. +----------+-------+-------+ | Language | Tests | Types | +----------+-------+-------+ | Haskell | Yes | Yes | | Clojure | Yes | No | +----------+-------+-------+
Re: Why Clojure?
#85Earlier quoted context omitted.
Haskellers can and do write tests. +----------+-------+-------+ | Language | Tests | Types | +----------+-------+-------+ | Haskell | Yes | Yes | | Clojure | Yes | No | +----------+-------+-------+
Clojure has something like an extendable type system called Spec. We can create our own types lol
Re: Why Clojure?
#86Clojure is by far the best programming language I've ever used. Rich Hickey's Sermons On The Mount changed the game of programming once and for all. With Clojure you could finally have your Lisp cake and eat it. Witness the sheer chutzpah of the guy when he basically told Ruby devs they were doing it wrong at Rails Conf in 2012 ( https://www.youtube.com/watch?v=rI8tNMsozo0 ).
In Erlang/Elixir, you have patterns, and interfaces which are fairly low level, but provide meaningful abstractions over common goals... I.e. we have OTP. OTP is fairly simple, and that doesn't mean it's easy, it's really not, but it can be simple once you're familiar with it.
Rust, on the other hand, is easy to get started with, the core of the language is fairly small (and relatively simple) but that's where the complexity starts to creep in.
It's so small, I have to constantly reach for a crate for common goals... There are tons, and they're fucking awesome, BUT they're easy, not simple, and my application's complexity grows exponentially relative to my familiarity each time I grab another crate.
I think it's easy ;) to say the Rust ecosystem has to contain the complexity it does, and making it easy is the best we can do, but with great challenges comes great reward... Batteries not included, yes, but at least you could know the size (spec) required for the ones you need? That's probably a shitty metaphor but I tried...
...
One more thought on this tirade, when Rich Hickey casually says that engineers should be working to remove complexity from the business... That hit me right in the feels. Too often do we get complex business decisions/goals and just accept them. We need to push back and help them simplify their goals... too often I've gotten some crazy request, where instead of implementing it, I pushed back to get to the root of the problem and ended up with something wildly simpler and better for both parties. When we push back, it shouldn't be to make something easy, it should be to make something simple. You can scale simplicity almost infinitely, but complexity will eventually come crashing down.
More on topic... Thanks for posting this talk, it and the article have inspired me, I'm gonna go try to write a bit of Clojure today. You should write some Elixir, or maybe LFE (Lisp Flavored Erlang), I think you'd quite like BEAM :)
Re: Why Clojure?
#87> No. Clojure is not slow. Oh, look, it’s not C. It’s not assembler. If nanoseconds are your concern than you probably don’t want Clojure in your innermost loops. You also probably don’t want Java, or C#. But 99.9% of the software we write nowadays has no need of nanosecond performance. I’ve built a real time, GUI based, animated space war game using Clojure. I could keep the frame rates up in the high 20s even with hundreds of objects on the screen. Clojure is not slow.
If you're going to respond to this question at least provide some comparison maybe.
But otherwise that anecdote of "I could keep the frame rates up in the high 20s even with hundreds of objects on the screen." absolutely screams extremely slow. High 20s FPS with hundreds of objects is incredibly bad on the surface of things. Maybe it's closures fault, maybe it isn't and is instead the fault of whatever was doing the drawing. But it's not a good look either way if that's the only data point that can be provided.
Similarly the IDE/dynamic type question seems to have missed the main downside of dynamic languages - lack of good IDE & other tooling support. How well are things auto-completed for me? How well does the IDE warn I've made a type error before I've gone through a long compile & test iteration loop? How well do linters or other things work, or is there some aspect of LISP that means this is just not an issue like it is in other languages?
Re: Why Clojure?
#88The response to "but is it slow" is pretty disappointingly bad. > No. Clojure is not slow. Oh, look, it’s not C. It’s not assembler. If nanoseconds are your concern than you probably don’t want Clojure in your innermost loops. You also probably don’t want Java, or C#. But 99.9% of the software we write nowadays has no need of nanosecond performance. I’ve built a real time, GUI based, animated space war game using Clo…
Otherwise the speed is almost identical to the speed of native Java and native Javascript. Except when you experience the power of lazy structures, then Clojure is faster than native code.
Re: Why Clojure?
#89Earlier quoted context omitted.
Haskellers can and do write tests. +----------+-------+-------+ | Language | Tests | Types | +----------+-------+-------+ | Haskell | Yes | Yes | | Clojure | Yes | No | +----------+-------+-------+
As I said above, clojure also has a type system. So your chart is yes for both features for both languages.
This is also made obvious by the idiomatic use of each technology.
So, no. My little chart is correct.
Re: Why Clojure?
#90Earlier quoted context omitted.
Haskellers can and do write tests. +----------+-------+-------+ | Language | Tests | Types | +----------+-------+-------+ | Haskell | Yes | Yes | | Clojure | Yes | No | +----------+-------+-------+
Clojure has something like an extendable type system called Spec. We can create our own types lol
I understand the idealist world view is seductive — we'll be discipined, we'll write the tests, we'll make good use of Spec, etc etc.
In reality, I have never seen this happen. Humans are lazy and undisciplined, so that's what I optimise for.