91–100 of 155 posts
> While the primary platform is the JVM, superbly uncool but stable and relatively performant My impression was that java has the reputation of being "uncool" but JVM is highly regarded as modern marvel. I am wrong about this ?
Earlier quoted context omitted.
Which libraries are people expected to plug together the security parts? I'm not pushing for clojure but a lot of other languages and frameworks are taking this approach too including Node and Go. Wouldn't the security stuff be a part of the individual packages? Ie authentication package handles sessions and tokens, an http server/middleware with built in csp and ssl, orm, the data stuff handling serialization and da…
You're right. Many things can be handled by packages, abstracting them away from the developer. Of course, that's assuming the developer thinks far enough ahead to remember that they need authentication, decide how they want to handle it, figure out what they want for a CSP, and so on. Other things cannot be so readily handled. Authorization, for example, isn't a concern that can be bundled into a pre-fab function. I…
Umm, is there any all in one web framework that protects against this to any level of guarantee?
Earlier quoted context omitted.
Which libraries are people expected to plug together the security parts? I'm not pushing for clojure but a lot of other languages and frameworks are taking this approach too including Node and Go. Wouldn't the security stuff be a part of the individual packages? Ie authentication package handles sessions and tokens, an http server/middleware with built in csp and ssl, orm, the data stuff handling serialization and da…
The situation in Node and Go is better by the fact that these ecosystems have extensive documentation related to web security.
Node only got to that point through plenty of failure and last time I used Go it didn't seem much different than Clojure.
The only reason I'm not using Clojure is the lack of types but that's another issue.
I tried to learn (get to know) Clojure by writing a library for cacheing (memoizing) function calls. I thought it would be a simple exercise, but it turned out to be not so easy at all, with lots of special cases.
Earlier quoted context omitted.
While you can manipulate Python's AST, you can't do it in a way that looks like adding new syntax. In Clojure you can write a list comprehension as `(for [x (range 10)] x)`. In Python you can write it as `[x for x in range(10)]`. Imagine these didn't exist, and you wanted to implement them yourself. In Clojure this is possible. Its list comprehensions are implemented as a Clojure macro: https://github.com/clojure/clo…
I heard somebody make a similar argument one time in regards to Common Lisp. He said that with Java you would have to wait several years sometimes to get a feature (assuming the language developers actually cared about the feature), but with Lisp, you could just implement the feature yourself. I've always felt this is one of the strongest arguments for using a lisp-style language. Edit: this is possible too in langua…
Need someone to explain why I should use clojure over scala because typelevel seems pretty well developed
Clojure: live repl into running code Scala: Clojure: Explore the problem you are facing with quick prototyping in the repl and see the blind spots, the unknowns, the shape of data received from flaky integrations. Mold and shape your functions as the problem becomes clearer. Scala: Best it can do is write unit tests and the debugger to look at what exactly is happening, devise a bunch of classes to handle them, rinse…
This is a great way to end up with undocumented code with no tests. The repl definitely encourages this process, but you should be doing this via quick running unit tests rather than the repl so that when you are done you already have a set of tests. Otherwise tests are an after thought and usually after thoughts are either not done or done poorly.
edit: you can always run your unit tests via the repl too, if you'd rather not use a fast test runner.
My favorite thing about Clojure: You compose libraries, instead of totally buy into framework A or B. Some people prefer the opposite. However, Composition works in Clojure because everyone is using the staples: functions, maps and seqs. Pretty much everything in the language can work as one (or all!) of them. While I also like static types, this is my argument for a well designed dynanic language like Clojure or its…
That said Hickey gave a tiny argument to lessen the pain, the cost of freedom is often lesser than the cost of being jailed by a framework that cannot evolve
Earlier quoted context omitted.
Thank you for the viewpoint. It certainly has merit, but there is also the possibility of "metapackages" like luminus [1], a curated package of libraries that work well together. It's easier to make a framework in the land of libraries than vice versa. Some of what you perceive as immature may be that the community is small, and a lot remains to be done. [1] http://www.luminusweb.net/
You're absolutely right, it's easier to make a framework in the land of libraries. With that said, it may be more difficult to get one used when the culture of library-land abhors frameworks. The Clojure developers I've worked with so far mostly seem repulsed by the idea of using a framework. This leads me to fear that the ecosystem is likely to remain in the hole it has dug for itself. Possibility is wonderful, as y…
I think this is one of the memes in the community which is starting to be reconsidered. You're not alone in seeing these downsides, and people are starting to write about it more (code and words). Things like Fulcro or even Datomic Cloud are very interesting developments in this regard.
[1]: https://jacobobryant.com/post/2019/grow/ [2]: http://flyingmachinestudios.com/programming/why-programmers-... [3]: https://github.com/fulcrologic/fulcro
My favorite thing about Clojure: You compose libraries, instead of totally buy into framework A or B. Some people prefer the opposite. However, Composition works in Clojure because everyone is using the staples: functions, maps and seqs. Pretty much everything in the language can work as one (or all!) of them. While I also like static types, this is my argument for a well designed dynanic language like Clojure or its…
Composing libraries instead of buying into a framework is a wonderful thing. It allows a developer to use just the parts they want, integrate them with just what the developer needs, and get on with whatever they're doing. It's a beautiful idea, and it can enable amazing levels of productivity. With that said, might it also be possible that there could be some drawbacks? Having worked in and with Clojure, I found the…
This does not match my experience at all.
There is a thing called sane defaults. You solve a problem by decomposing it to simple elements, and then combine them to sane defaults, while still giving full power to your users. Examples of sane defaults in areas you mention:
- authorization/authentication: buddy (https://github.com/funcool/buddy) has both core library with crypto stuff and complimentary libraries for auth etc. For example, if you want to securely hash a password, you don't have to come up with salting yourself, just use buddy-hashers: http://funcool.github.io/buddy-hashers/latest/#quickstart
- sql: clojure.java.jdbc and it's successor next-jdbc for sql queries use vector with query string containing question marks for arguments and then arguments that get escaped, see select example here https://cljdoc.org/d/seancorfield/next.jdbc/1.0.6/doc/gettin...
- "other security things": ring site defaults, see https://github.com/ring-clojure/ring-defaults/blob/master/sr...
Earlier quoted context omitted.
HTML templater has nothing to do with password/session management, auth, sql and encription, if your does, it does the wrong things.
I think you spliced that sentence wrong. It's bad templating, /along with/ bad session management, auth, sql, and encryption tools.