Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

My Increasing Frustration with Clojure

ashtonkemerling.com

Post reply on HN
Print view View original

81–90 of 240 posts

Re: My Increasing Frustration with Clojure

#81

Post by mcguire »

lgrapenthin wrote: post #69

As a dev programming in Clojure professionally day to day this complaint (core team not fixing/prioritizing bugs) seems absurd to me. The only example given for a bug is not even a bug but undefined behavior triggered by undocumented API usage. If the author means clojure.spec by "greenfield development" (I don't see what else he could mean) he should really reconsider his complaint since clojure.spec is going to do…

"The only example given for a bug is not even a bug but undefined behavior triggered by undocumented API usage."

C gets a lot of grief about that sort of thing. It's interesting to see current languages taking the same approach.

Re: My Increasing Frustration with Clojure

#82

Post by hugdru »

reitanqild wrote: post #68
hugdru wrote: post #55

Earlier quoted context omitted.

I was thinking of learning a modern language for the web back end. After analysing elixir, go and clojure I decided to go for clojure. Uhmmm, maybe go? I don't know :X. Stick with php? Meehhh

You could do worse than learning modern php. Esp. if you have some experience with it and as long as you are ready to leave bad habits behind. (Going for a full stack framework might help here by more or less forcing you to do things the right way.)

Thanks, I will have that in mind.

Re: My Increasing Frustration with Clojure

#83

Post by sanderjd »

masklinn wrote: post #50
dilap wrote: post #38

Earlier quoted context omitted.

Avoiding madness like this is why I have come to really prefer statically typed languages.

The issue doesn't have much to do with dynamic typing, any subtyping support can trigger it. Take Java, if Set had a `Set union(Collection)` method a SortedSet could return a new SortedSet (cast as a set, but still with the actual behaviour of a sorted set).

But you would not be able to pass it to a method that takes a SortedSet, which means you can't rely on the sorted behavior. Incorrectly using behavior that your implementation doesn't support is where the confusion comes from, it doesn't come from your implantation having extra behavior that you can't use.

Re: My Increasing Frustration with Clojure

#84

Post by catnaroek »

rauljara wrote: post #65
catnaroek wrote: post #45

Earlier quoted context omitted.

I don't see what Ruby's “beautiful philosophy” is. Here are some examples of philosophies I actually consider beautiful, regardless of the result they led to: (0) Lisp, Scheme, Forth: “A small extensible core language beats a fixed large language.” (While Common Lisp is actually pretty large, there's a rather small subset of it from which the rest can be built.) (1) ML, Haskell: “Let's see how much we can do using ty…

I'll bite. Ruby has a beautiful and consistent object / module system, a beautiful integration of functional and object oriented programming paradigms, and extreme powerful metaprogramming. All of those things are pretty wrapped up in its design philosophy which contains a whole bunch more than developer happiness. Yes, Ruby has warts. So do all the other languages you listed. It is helpful to be able to see both the…

> Ruby has a beautiful and consistent object / module system,

I don't program much with objects, so I don't know what to expect from them, but after programming in a language that treats modules seriously (Standard ML), I can't accept anything less than the following from anything that calls itself a “module system”:

(0) Implementor-side abstraction: Fine-grained control over which implementation details are exposed to different parts of a program.

(1) Client-side abstraction: The ability to define a module as a function of another, yet to be supplied, module.

Ruby's “module system” doesn't quite cut it.

> a beautiful integration of functional and object oriented programming paradigms

Functional programming in Ruby is possible, but a gigantic pain:

(0) Partially applied functions are mildly inconvenient.

(1) Higher-order functions that recursively pass themselves a modified version of their function argument(s) are not so mildly inconvenient.

(2) Now imagine actually debugging such beasts when you make a mistake. Unit tests don't help because they overemphasize the concrete cases, when higher-order functions are all about abstracting as much as possible.

At a more fundamental level, functional programming is value-oriented, and programming with compound values (not the same thing as compound objects) in Ruby isn't the path of least resistance, to put it mildly.

> Yes, Ruby has warts. So do all the other languages you listed.

I wasn't commenting on the languages themselves, but rather the philosophy of their designers. C++ has more than “warts” - the language as a whole is a monstrous abomination, but the philosophy of not accepting unneeded performance overheads is aesthetically pleasing IMO.

Re: My Increasing Frustration with Clojure

#85

Post by brandonbloom »

Clojure is a language for people who know what they are doing by people who know what they are doing.

If you're giving sequences to the set functions, you either (A) don't know what you're doing or (B) have yet to discover that clojure.set is not what you want.

Set union can't be done efficiently on arbitrarily sized sequences. At least one of the two arguments needs to offer fast set membership; ideally the larger one, hence the requirement that all arguments be actual sets. If you have sequences, you need to make an explicit decision to pay the cost of indexing (eg. via set or into functions) or you need custom code for your use case.

Sure, static or dynamic enforcement could help catch silly errors here, but then the author goes and poo poos on "greenfield" development of things like spec, despite the fact that would "fix the bug" exactly as requested by throwing when you gave non-sets to the set functions.

I've followed a lot of the discussion around the supposedly horrible way the Clojure community is run. So far, the absolutely only complaint that I can sympathize with is that communication could be faster, clearer, and softer. Alex Miller has made dramatic strides in improving this, but he's just one man. Cut these guys some slack, they work crazy hard to build and shepherd something awesome for free.

Re: My Increasing Frustration with Clojure

#86

Post by qaq »

hugdru wrote: post #71
qaq wrote: post #62

Earlier quoted context omitted.

Depends on features you need for the web backend.

I was looking for a cool new language to learn in the holidays and hopefully do something with it web related. Like a back-end. Nothing serious though. Elixir seems way different from the languages I am used to maybe that is good.

Erlang/OTP has a lot of unique features not available in any other environment and Elixir gives you the power of Erlang/OTP with much easier syntax. It's different not because they are trying to be cool, but because it's driven by the unique requirements that allow all those unique features.

Re: My Increasing Frustration with Clojure

#87

Post by pvinis »

jonnybgood wrote: post #6

Clojure is not a community-driven language. It belongs to Rich Hickey and by extension Cognitect. The bugs that will be fixed and the features that will be added are the ones Hickey cares about. Not saying this is good or bad. It's just how Clojure development is ran.

A Clojure with the Rust politics would be interesting..

Re: My Increasing Frustration with Clojure

#88

Post by mcguire »

willvarfar wrote: post #4

I'm not a clojure user but I am a fan of Rich's talks so I am kinda taken aback by this - this is just not the kind of Clojure I was expecting from what I know of the principles Rich preaches. I really was expecting belt and braces defensive error checking and never ever giving a dud result.

It's a somewhat common problem with Lisps specifically and dynamically typed languages in general.

Because the bottom-level operations won't let you do things that are completely idiotic, everything is "safe", so maintaining the sanctity[1] of higher level abstractions sometimes gets lost in the shuffle.

I once wrote a blog post about related issues.[2]

[1] Ok, so there are lots of terms with just slightly the wrong meanings. I came up with a new one. Sue me.

[2] http://maniagnosis.crsr.net/2011/06/some-lisp-suggestions.ht...

Re: My Increasing Frustration with Clojure

#89

Post by lgrapenthin »

mcguire wrote: post #81
lgrapenthin wrote: post #69

As a dev programming in Clojure professionally day to day this complaint (core team not fixing/prioritizing bugs) seems absurd to me. The only example given for a bug is not even a bug but undefined behavior triggered by undocumented API usage. If the author means clojure.spec by "greenfield development" (I don't see what else he could mean) he should really reconsider his complaint since clojure.spec is going to do…

" The only example given for a bug is not even a bug but undefined behavior triggered by undocumented API usage. " C gets a lot of grief about that sort of thing. It's interesting to see current languages taking the same approach.

Could you elaborate why? (Haven't done much C) - Is the point of view that it is the languages job to prevent the programmer from relying on uncertainties?

Re: My Increasing Frustration with Clojure

#90

Post by yawaramin »

masklinn wrote: post #50
dilap wrote: post #38

Earlier quoted context omitted.

Avoiding madness like this is why I have come to really prefer statically typed languages.

The issue doesn't have much to do with dynamic typing, any subtyping support can trigger it. Take Java, if Set had a `Set union(Collection)` method a SortedSet could return a new SortedSet (cast as a set, but still with the actual behaviour of a sorted set).

In Java, you can have:

    class Set { public Set union(Collection c) { ... } }

    class SortedSet extends Set {
      @Override public SortedSet union(Collection c) { ... }
    }
In other words, the more specific type overrides the operations of the more general type into more specialised operations.
Post reply on HN