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

121–130 of 240 posts

Re: My Increasing Frustration with Clojure

#121

Post by brandonbloom »

coldtea wrote: post #102
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…

> Clojure is a language for people who know what they are doing by people who know what they are doing. That can also be said for C, assembly and almost any language, even Brainfuck. And when there's not a speed/memory tradeoff for not having the language do the right thing (like e.g. is the case for some decisions in C), this just amounts to having the programmer do "busywork" -- manually do the work that the compil…

C absolutely is a language by/for people who know what they are doing. The fact that so many people are using it for so many things where modern safer languages now exist is not a failing of C or its designers...

Regarding misusing the set functions: There is no busy work. Instead of (set/intersect some-set some-list) you just need to do (set/intersect some-set (set some-list)) to explicitly opt in to the speed tradeoff of performing set operations on lists.

> is a bad idea and those that propagate it should feel bad.

I don't feel bad about it at all.

If Clojure hadn't followed the garbage-in/garbage-out strategy, it would have been too slow for production use. If they had added strong types early or Racket-style (read: slow) contracts, then we'd never have had the years of experience that led to the design of spec, which is new take on the problem space.

In the case of the set functions, the right thing _can not_ be inferred automatically without a speed tradeoff.

Re: My Increasing Frustration with Clojure

#122

Post by jgalt212 »

brandonbloom wrote: post #118
jgalt212 wrote: post #99

Earlier quoted context omitted.

> 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/bet…

I anticipated this response to the word "free", but I stand by my statement. Clojure is _free_. If you don't want Cognitect stuff, don't use it. If you don't like how Rich/Cognitect et al are running the project, take your EPL licensed ball and go home. Similarly, in the case of Go: Substitute Rob/Google and BSD-ish license. Just because these languages serve the interests of their respective maintainers does not mak…

> does not make them any less free to you

Of course not, but it does make them unencumbered. And I'm not complaining. I'm just saying that's cost (i.e. not free) of doing business with a sponsored open source language.

Re: My Increasing Frustration with Clojure

#123

Post by chriswarbo »

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.

> Coq is ridiculously powerful, but hardly beautiful.

I agree, hence my qualification that it relies on an imperative layer (Ltac) to do anything useful, like dependent pattern-matching. I've edited my potentially ambiguous phrasing.

Re: My Increasing Frustration with Clojure

#124

Post by Scarbutt »

wmccullough wrote: post #33
dustingetz wrote: post #20

I think this article is spot on. But. I think the root cause here is that many of the tools are build by the community. Great tools cost a lot of money to build, and you need to build the right thing at the right time, the cost needs to be spread across the comminuty. The community is growing and tools are improving. The first generation tools with all their rough edges are being replaced by simpler tools that have i…

I couldn't agree with you more. I've been wanting to learn Clojure for years now, but I'm not going to fight with an IDE for hours to do so.

You don't need an IDE for Clojure, IMO, huge IDEs like intellij/cursive are anti-clojure, Clojure culture encourages to write programs composed of small, modular components that can be tested individually, so mostly you keep things in your head, and if you haven't work with it in a while, is easy pick up again, Clojure doesn't need a "dot operator" to autocomplete to million of different API classes/methods. Rich Hickey makes a comparison here: https://youtu.be/VSdnJDO-xdg?t=2943

The thing is that most Clojure users are/were heavy Java users and they feel awkward without their IDEs and also some have a big java project that hey mix with clojure.

Re: My Increasing Frustration with Clojure

#125

Post by [deleted] »

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…

[deleted]

Re: My Increasing Frustration with Clojure

#126

Post by twoodfin »

pmarreck wrote: post #108
ianopolous wrote: post #79

Earlier quoted context omitted.

It is with -XX:MaxInlineSize=35 (that's the default number of bytecodes to consider inlining)

So why couldn't they simply include the extra debug code and use that config for Clojure compiles?

HotSpot is a JIT, so that's a runtime option. You'd be asking anyone deploying a .jar containing some Clojure to add fiddly configuration.

Not impossible, but one of the heavily advertised virtues of Clojure is that it can be deployed alongside Java code without anyone having to be the wiser.

Re: My Increasing Frustration with Clojure

#127

Post by brandonbloom »

jgalt212 wrote: post #122
brandonbloom wrote: post #118

Earlier quoted context omitted.

I anticipated this response to the word "free", but I stand by my statement. Clojure is _free_. If you don't want Cognitect stuff, don't use it. If you don't like how Rich/Cognitect et al are running the project, take your EPL licensed ball and go home. Similarly, in the case of Go: Substitute Rob/Google and BSD-ish license. Just because these languages serve the interests of their respective maintainers does not mak…

> does not make them any less free to you Of course not, but it does make them unencumbered. And I'm not complaining. I'm just saying that's cost (i.e. not free) of doing business with a sponsored open source language.

If you take the stance of "nothing is free", then the word "free" isn't particularly useful.

Re: My Increasing Frustration with Clojure

#128

Post by weavejester »

pdimitar wrote: post #109
calibraxis wrote: post #58

Earlier quoted context omitted.

Critiques from Clojure users should really try tradeoff analysis, as Hickey advocates. Which means I should analyze the costs of what I advocate, not just the benefits. For clojure.set/intersection (CLJ-1682?), Alex Miller clearly mentioned the speed consideration — one all users would have to bear. Not to mention spending time on this versus other things. Also, it was ironic to read elsewhere in the article, "Even m…

You're right and make a very good point. But that doesn't change the fact that there are bugs from 2009 which barely have comments or even a reasonable explanation. Me being a pretty average typer (~95 WPM) I could type 2-3 paragraphs detailing why I am against fixing anything, in no more than 6-8 minutes. So for 7 years such bugs to never even get a proper explanation is showing the maintainers as douchebags, not vi…

You'd be maybe be right, if that was the only thing that the maintainers were doing. Speaking as a maintainer of several projects myself, it's all too easy for some issues to slip through the cracks.

Re: My Increasing Frustration with Clojure

#129

Post by HillRat »

jrcii wrote: post #96
yawaramin wrote: post #75

Earlier quoted context omitted.

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

But if your server doesn't enforce data consistency -- that is, the business logic resides on the client -- you can't rely on the quality of your input. And if your authorization sanitizes the data to ensure consistency, then you've just built your middle tier for logic.

Re: My Increasing Frustration with Clojure

#130

Post by toasterlovin »

jrcii wrote: post #96
yawaramin wrote: post #75

Earlier quoted context omitted.

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

You still need to do all the same things as before. Some things you move to the client, other things you move to the dbms. There isn't some functionality that magically disappears when you no longer have, for example, a PHP/Ruby/Python/JS/whatever server mediating between your client and your database.
Post reply on HN