My Increasing Frustration with Clojure • Hacker News Board

Re: My Increasing Frustration with Clojure

#91

Post by chriswarbo » Sat, Jun 11, 2016, 6:36 PM UTC

catnaroek wrote: post #45

lkrubner wrote: post #13

I 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…

I'm not a Ruby user, but its dynamic OO nature reminds me of the Smalltalk and Self tradition, and those languages certainly do stick to a "beautiful philosophy", something like 'it's method calls all the way down'.

Other beautiful philosophies include:

- Logic programming. Although Prolog strayed from the path in the name of efficiency, approaches like minikanren seem more "philosophically pure".

- Term rewriting. I've only used it in the form of Maude, but Pure looks like a more practical implementation.

- Proof assistants. The (tongue in cheek) philosophy is something like "once it compiles, we don't even need to run it". Agda is probably the most "pure" example which is still maintained. Less elegant examples are Coq, which uses imperative metaprogramming, and Idris which has no qualms with switching off checks in the name of pragmatism.

Re: My Increasing Frustration with Clojure

#92

Post by mcguire » Sat, Jun 11, 2016, 6:36 PM UTC

zacharypinter wrote: post #56

rurban wrote: post #12

The underlying issue to me seems to be that Clojure is still not developed by a team, but by a single developer, who cannot think out of the box. union and intersect not doing the same thing as in common lisp (accepting lists and vectors), and returning buggy values instead is just a bug, even if the developer didn't have that in mind originally, and doesn't like to support that.

Of all the people in the world I can think of with the inability to think outside the box, Rich Hickey has to be at the bottom of the list :)

Different people have different boxes.

Re: My Increasing Frustration with Clojure

#93

Post by catnaroek » Sat, Jun 11, 2016, 6:41 PM UTC

chriswarbo wrote: post #91

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'm not a Ruby user, but its dynamic OO nature reminds me of the Smalltalk and Self tradition, and those languages certainly do stick to a "beautiful philosophy", something like 'it's method calls all the way down'. Other beautiful philosophies include: - Logic programming. Although Prolog strayed from the path in the name of efficiency, approaches like minikanren seem more "philosophically pure". - Term rewriting. I…

Agreed about Prolog. I missed that one.

I know neither Maude nor Pure, so I can't comment.

Coq is ridiculously powerful, but hardly beautiful.

Re: My Increasing Frustration with Clojure

#94

Post by hugdru » Sat, Jun 11, 2016, 6:43 PM UTC

qaq wrote: post #86

hugdru wrote: post #71

Earlier quoted context omitted.

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.

My bad, that cool really meant something different from what I am used to. Like functional programming, homoiconicity, different paradigms for concurrency, etc. I don't really have any requirements it is just for fun :). Thanks for the info.

Re: My Increasing Frustration with Clojure

#95

Post by kevinwang » Sat, Jun 11, 2016, 6:44 PM UTC

slantedview wrote: post #80

_halgari wrote: post #35

Something that is often very hard to understand (it took me years to do so). Is that maintaining a language is insanely hard. Everything has a cost. Let me give a good example: A few years back someone submitted a patch that improved the error messages in Clojure. Worked great, just a single extra "if" and a message. It was committed to master. Then people's code got way slower. Why? Well this was a often used functi…

You seem to be sidestepping some of the points made by the OP, particularly where certain bugs defy conventions laid down in other parts of the language. Garbage-in-garbage-out is fine so long as it's done in a consistent, well-understood way across the language (ie: throwing IllegalArgumentException). It seems to me that instead of being a strategic approach for dealing with such issues in a consistent way across th…

But it seems to me that throwing an exception would be the opposite of a garbage-in-garbage-out philosophy.

Re: My Increasing Frustration with Clojure

#96

Post by jrcii » Sat, Jun 11, 2016, 6:49 PM UTC

yawaramin wrote: post #75

jrcii wrote: post #51

Earlier quoted context omitted.

Thanks for pointing me to that article. I've been mulling over for years how to architect apps to remove the server, that layer never sat well with me. I've also found I couldn't discuss the problem with anyone because "clients can't access the database directly!" is such a knee-jerk reaction.

If clients access the database directly, then the database is now the server. You haven't removed the server, you've just moved it.

By removing the server-side layer I mean, for example, moving the "model" logic in MVC to the client. The database is still there, but it doesn't perform any application logic, so the server-side layer is moved to the client, not the database. The challenge then becomes authorization. Ideally even the database would be ad-hoc distributed yet would maintain authorization functions or at least the practical result of them, so there's no server-side whatsoever.

Re: My Increasing Frustration with Clojure

#97

Post by im_down_w_otp » Sat, Jun 11, 2016, 6:52 PM UTC

catnaroek wrote: post #93

chriswarbo wrote: post #91

Earlier quoted context omitted.

I'm not a Ruby user, but its dynamic OO nature reminds me of the Smalltalk and Self tradition, and those languages certainly do stick to a "beautiful philosophy", something like 'it's method calls all the way down'. Other beautiful philosophies include: - Logic programming. Although Prolog strayed from the path in the name of efficiency, approaches like minikanren seem more "philosophically pure". - Term rewriting. I…

Agreed about Prolog. I missed that one. I know neither Maude nor Pure, so I can't comment. Coq is ridiculously powerful, but hardly beautiful.

Are we not doing, "Phrasing." anymore? Guys? Guuuyyysss? .... Danger zone!

Re: My Increasing Frustration with Clojure

#98

Post by mcguire » Sat, Jun 11, 2016, 6:53 PM UTC

hyperpape wrote: post #10

vimota wrote: post #5

Earlier quoted context omitted.

I would say he backs up his claims quite well, unlike your comment. He gave ample evidence at his frustrations with the progress of the language - what did you find annoying about it?

I clicked through to the github exchange he links to, and I don't think you can call that shabby treatment. Perhaps a bit too terse (though I don't think so), but it's just saying "the docs say data must meet requirement X, and that's good enough". His other examples sound prima facie troubling (I don't know enough clojure to have a real opinion), but he's miss-characterizing that interaction.

Once upon a time, many years ago, I was taking a database implementation class at the same time as working as a sysadmin of the university. We started having a weird problem with our AIX 3.2.5 (...years ago...) machines: the NFS subsystem would deadlock and become a tar-baby; any process that touched the affected filesystem would block, including other users' processes, system processes, and (the important part) the automounter. As a result, the boxen were effectively unusable until rebooted. Considering that they were serving 8 x-terminals and remote users, that was a problem.

We eventually narrowed it down to students working on their DB implementation projects, and further to the use of mmap. If you mmap'ed a region larger than a physical file and wrote to the outside region, that NFS filesystem went belly-up. Yes, that's explicitly mentioned as a thing not to do in the mmap documentation. (On the other hand, it worked fine on a local AIX filesystem and in fact was how local file systems extended files; I'd spent the previous couple of years working with AIX filesystem developers.)

Anyway, after getting the professor to tell the students not to do that, I notified IBM tech support. The response I received was exactly, "the docs say data must meet requirement X, and that's good enough".

In a sudden fit of ethics (honestly, I have no idea what came over me), I completely failed to advertise the nifty denial-of-service attack widely. It would have been spectacularly amusing to embarrass my former employer on BUGTRAQ, say. Not to mention imagining the face of the tech support guys when they tried reading their "good enough" spiel to an IBM customer who had more than our handful of machines.

On the other hand, AIX 4 was a complete re-write and fixed the problem with the NFS filesystems. Yay.

Anyway, the bottom line is that using documentation to cover your ass for implementation infelicities is not a very good idea.

Re: My Increasing Frustration with Clojure

#99

Post by jgalt212 » Sat, Jun 11, 2016, 6:56 PM UTC

brandonbloom wrote: post #85

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 o…

> they work crazy hard to build and shepherd something awesome for free.

I'm not so sure about that. I'd say that Clojure now exists and thrives to help Cognitect make money. This is no way a bad thing, only a reminder that there is no such thing as a free lunch.

In a similar vein, Go exists to help make Google money. The original purpose of open sourcing it was different for Google (make the language more robust/better) than it was for Hickey (grow the language/community).

Re: My Increasing Frustration with Clojure

#100

Post by mcguire » Sat, Jun 11, 2016, 6:57 PM UTC

dragandj wrote: post #59

bpicolo wrote: post #8

Earlier quoted context omitted.

In what way is "garbage in garbage out" better than consistent handling and explicit failure, especially for something so well-defined mathematically? That's sort of a lazy argument, imo. I shouldn't need to pull in more libs for baseline language expectations, either. Core libraries are what languages really are, much more important than just syntax.

Because checks to avoid some kinds of garbage can incure significant performance penalty. There is always a tradeoff in that sense, and I think Clojure is pretty well balanced in that way. So, read the docs, try the functions out to see how they work, write tests, and sanitize the data at the appropriate place.

If it's good enough for ANSI C, it's good enough for you...