221–230 of 240 posts
Earlier quoted context omitted.
As an aside, I don't think this thread turned into a flamewar, there's some good discussion. Also, s/he started it ;)
I take both points but the combination of snark and genericness is still an explosives-handling violation. Thanks for the friendly responses.
Haha, what a fantastic way to word it. Duly noted.
Earlier quoted context omitted.
No, I'm saying you should stop and think about what you're doing.
i have recently been excited about clojure, but your behavior and responses of other clojure people in this topic has honestly put me off of it. i understand that things are difficult and cljure people apparently work very hard, but the tone and attitude being used is in stark contrast to what i have seen from communities like those of F# and racket. whether you're right or not, it doesn't seem to be a great approach…
For context, these arguments made by the original poster have been around for _years_ in the Clojure community and, frankly, those of us who have also been around for years are tired of hearing the same old complaints. It's particularly annoying because: the core team has made multiple announcements in past days/weeks about improvements to exactly what he's complaining about!
Earlier quoted context omitted.
> Is it really so wrong ... No, that would be _wonderful_. Unfortunately, "easy" is only one dimension along which we must make tradeoffs. Clojure has chosen one point in the design space for input validation vs performance. You're free to have a different preference.
Thank you. The only problem here would probaby only be the lack of clear and strong statements about the Clojure philosophy. The C standard for example clearly shows the areas where there is an undefined behaviour and when you can expect the "garbage in, garbage out" behaviour. Is Clojure doing the same? As a relatively mature man and a programmer for me the way a project is maintained is just as important as the abi…
Earlier quoted context omitted.
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.
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).
e.g., in your example, because your returned type is Set, you presumably would not be relying on the result to be a sorted set! -- so there would be no problem. if you WERE relying on it being a sorted set, you would have to explicitly downcast -- i.e. would pointing a gun and at your foot and pulling the trigger. maybe you know it's unloaded, but the danger is clear from the type system. ;)
Earlier quoted context omitted.
> Clojure is a language for people who know what they are doing by people who know what they are doing. Oh, goodie. I'm part of an elite club with high barriers to entry.
Experience actually matters in software development. I'm not sure why you deride it as elitism.
Earlier quoted context omitted.
This is one architecture that is made possible by clojure: http://tonsky.me/blog/the-web-after-tomorrow To build it outside of clojure ecosystem, you would need to first build all the pieces of the clojure ecosystem
Has this been implemented yet?
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…
Earlier quoted context omitted.
i have recently been excited about clojure, but your behavior and responses of other clojure people in this topic has honestly put me off of it. i understand that things are difficult and cljure people apparently work very hard, but the tone and attitude being used is in stark contrast to what i have seen from communities like those of F# and racket. whether you're right or not, it doesn't seem to be a great approach…
My apologies. The community is actually quite welcoming to beginners. For context, these arguments made by the original poster have been around for _years_ in the Clojure community and, frankly, those of us who have also been around for years are tired of hearing the same old complaints. It's particularly annoying because: the core team has made multiple announcements in past days/weeks about improvements to exactly…