And that he is a well known troll.
My Increasing Frustration with Clojure
141–150 of 240 posts
Re: My Increasing Frustration with Clojure
#142This particular complaint feels like a typing issue. If functions can accept anything and use lots of partial duck typing then they might partially accept anything and not quite work.
There's just an unstated precondition: the arguments are sets.
Re: My Increasing Frustration with Clojure
#143Earlier quoted context omitted.
" 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?
Programmers are still humans at this point. Humans make mistakes. It is helpful to have software executing on computers prevent us from making mistakes rather than making it easier for us to make mistakes.
Re: My Increasing Frustration with Clojure
#144I'm having trouble finding much value in this post. It seems to be a combination of the author picking apart very specific aspects of Clojure (clojure.set? clojure.test fixtures?) in a highly opinionated fashion to represent issues with overall project focus, combined with not acknowledging the project's history (maybe that can explain the inconsistency with Protocol usage--as far as I know Protocols only got added i…
Let me get this straight, you agree with every single gripe I have, have some more of your own, agree that writing a post on this would be reasonable, but I'm wrong?
Re: My Increasing Frustration with Clojure
#145> The thing I am trying to build is not possible in any other ecosystem today Umm... what? I'm afraid I don't understand how the "grand vision" behind Clojure adds pixie dust that makes it capable of something another Turing complete language isn't. Care to elaborate?
Anything you can do in Clojure, I can do in Blub.
Re: My Increasing Frustration with Clojure
#146Alex Miller is the person primarily responsible for triaging Clojure tickets. For a thoughtful, balanced assessment of the issues Ashton raises, read Alex's detailed comment on the original post: http://ashtonkemerling.com/blog/2016/06/11/my-increasing-fru...
Re: My Increasing Frustration with Clojure
#147> And the namespace is completely riddled with bugs. union returns duplicates if some of the inputs are lists instead of sets depending on their length. to be clear I assume he is taking about this: ``` try-spec.core=> (clojure.set/union [1,2] [1,2]) [1 2 1 2] ``` Though im not sure what "depending on their length means". > for the above bugs there are two possible fixes: raise an IllegalArgumentException if anything…
I'm a bit confused by your example. Python has different design goals than Clojure. Clojure competes with rather high performance languages, Java and Scala, on the JVM and it appears from the OP that its implementors have decided that it can't afford to spend too much time at run-time checking.
Python on the other hand at least attempts to adhere to a principle of least surprise and enforces strong type requirements at run-time. It does this because consistency is generally more important than performance considerations in Python, one of the reasons that Python is much slower than Clojure.
The API for the set constructor in Python accepts any iterable as an argument. Furthermore the elements of a set must be objects that are hashable.
Consequentially, Python sets rule out mutable members, such as Lists, Maps, and other Sets. Sets of Set Objects aren't allowed since Set Objects can be modified. Strings are immutable so Sets of strings are allowed and even frozensets (an immutable kind of set object) and tuples (which happen to be immutable in Python) can be members of sets in Python. I believe that this is all spelled out in the documentation pretty clearly, and the language's built ins and standard library enforce this simple model at the cost of run-time type checking.
Thus,
set([1,2,3,2]) == {1,2,3}
# the tuple (10,20) is immutable and hashable
set([1,2,"abc",(10,20)]) == {1,2,"abc",(10,20)}
# strings are iterables
set("abc") == {"a", "b", "c"}
# lists are iterable and strings immutable and hashable
set(["abc"]) == {"abc"}
# comprehensions and generators are iterable
set(i*2 for i in range(5)) == {0,2,4,6,8}
# sets are iterable
set({2,4,6}) == {2,4,6}
# int 14 is not an iterable
set(14) set([1,2,3]).union(["a", "bc"]) == {1,2,3,"bc","a"}
set({1,2,3}).union({3,4,5}) == {1,2,3,4,5}Re: My Increasing Frustration with Clojure
#148Earlier quoted context omitted.
I think you may have misread it - he's pretty clear that he considers these bugs that clojure core chooses to ignore because they either a) don't understand them b) want to do cool new stuff
> he's pretty clear that he considers these bugs Design bugs, not implementation ones. In other words, the author of the post acknowledges that the existing implementation does what Hickey wants, but the author would prefer that it did something else.
If that's true this blog post is just whining. He knows that Clojure core made a decision he disagrees with and he's just really upset that after 7 years they still haven't changed their opinion to match his.
Re: My Increasing Frustration with Clojure
#149Earlier 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 essentially has no module system, and it only offers awkward tacked on support for small bits of functional programming. Hardly an integration of FP and OOP at all, much less a beautiful one.
Re: My Increasing Frustration with Clojure
#150I love Clojure, and I use it in every project where I have control over the technology, but I do agree with the points raised by Ashton Kemerling. Clojure is beautiful, and backed by beautiful theories, but its implementation needs to be clean or it will eventually develop enough special cases that its beauty will be ruined. In some sense, you could say this is what happened to Ruby, though there the allowance of "sp…
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…
That is not the philosophy underlying ML or haskell. What you gave for lisp would be more appropriate for both SML and haskell than what you gave for ML/haskell.