Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why I like Clojure

sulami.github.io

Post reply on HN
Print view View original

101–110 of 155 posts

Re: Why I like Clojure

#101

Post by ddragon »

dmix wrote: post #95
zcid wrote: post #73

Earlier quoted context omitted.

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…

I haven't done much metaprogramming stuff, is this just the nature of using macros or can it be solved with careful coding?

Macros are really powerful constructs that allows you to even change the syntax of the language, which means when they are used you can't trust your previous knowledge of how the language should behave. If you do it correctly you can make a Domain Specific Language that makes your code as readable as the documentation in domains the language was not designed to directly solve (or just generate code for you to avoid boilerplate that would be more unreadable by itself). If you do it incorrectly, you can end up with code you cannot trust or even understand (and language design is a skill that not everyone has in the first place).

About debugging, it is somewhat different from normal debugging since macros are a second layer of abstraction. You have a compile-time phase in which the macros are resolved (receiving code and returning code until there is no macro left) and a runtime in which the final generated code is run. If you only consider the runtime, then you're looking at code that is not the same as you wrote, which makes it indeed hard to see mistakes. But if you separate the concerns of compile and run time you can evaluate both separately most of the time.

Also, Ruby does not have macros. It has a very simple syntax in which everything is an object and all function calls are actually messages that can be interpreted in runtime which allows you to extend the syntax very easily by controlling the dispatch rules. What causes trouble is that classes are open and can be extended freely during runtime, so you cannot know that an object you're calling is not modified by any part of the code (including any library), a practice called monkey patching and usually considered bad practice since it makes code hard to reason about.

Re: Why I like Clojure

#102

Post by rcarmo »

peatmoss wrote: post #60

I love the language. I’ve never found a language where I found the learning curve so shallow for being able to do so much. That said, I do find myself pining for the ability to easily compile a static executable (maybe with a small embedded runtime). Some time ago there was an attempt to port Clojure to Gambit Scheme, but that appears to have fizzled. More recently, I’ve seen Ferret, which compiles a subset of Clojur…

I went down the “small standalone executable rabbit hole” a while back, with multiple flavors of Scheme.

Here are my notes on that: https://taoofmac.com/space/blog/2019/06/20/2310

Re: Why I like Clojure

#103

Post by harperlee »

Kalium wrote: post #76
dmix wrote: post #72

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…

Several purported cons of clojure according to this conversation, including yours, are more a critique of using a niche language with a small community than really about the language. Addressing that explicitly can clarify the debate. Also, clojure is a special beast in the sense that can leverage a big community easily (java). This is not covered in your web framework example, but you can use clojure in frameworks (e.g. you use unity through arcadia, as a framework)

Re: Why I like Clojure

#104

Post by amelius »

dmix wrote: post #94
amelius wrote: post #90

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.

That seems like an unusual first project. Any reason you chose it? Were you more interested in the language semantics?

It was because (1) a project I was thinking of would lean heavily on memoized calls, and (2) it would allow me to learn about less basic features like introspection and (3) to quickly see how cleanly the language was designed to not be disappointed later on.

Re: Why I like Clojure

#105

Post by harperlee »

amelius wrote: post #90

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.

Can you give more details? Shouldn’t that be a matter of a macro redifining defn (o create a defn variant a la schema’s defn-spec, or tufte’s defnp ) to capture the call?

Re: Why I like Clojure

#106

Post by potta_coffee »

elamje wrote: post #55
rrosen326 wrote: post #43

Clojure Help: This is super apropos since I am JUST learning Clojure via the Clojure Koans. Any tips from clojurists on getting the repl (and readline) working fluently? I'm using Leiningen but it's not responding as I'd expect. I would think this would all set up more effortlessly. Tips on getting a new Clojure setup working would be appreciated.

Chapter 2 of Clojure for the Brave and True will get you an Emacs environment set up with minimal effort!

I just went through this chapter. Some of the packages are out of date and the environment does not work correctly. I'm still trying to figure out how to get emacs to connect to the repl.

Re: Why I like Clojure

#107

Post by amelius »

marmaduke wrote: post #2

> homoiconicity, meaning code can be represented as a data structure inside the same language > generating strings and passing them into eval like for example in Python Python has become a pinata for language enthusiasts? Python lets you pin a decorator on a function, get the AST (a data structure AFAIK), manipulate it in a sane fashion in Python, compile it, return the result. No string munching eval require I'm all…

Python's biggest problem wrt functional programming: multiline inline lambdas are not possible.

Re: Why I like Clojure

#108

Post by bobbyi_settv »

serpix wrote: post #58
joneholland wrote: post #41

Earlier quoted context omitted.

Scala also has a live repl.

Please provide link as I need one. Ammonite is not it though.

I use jupyter notebook for Scala. I like having the same repl software for multiple languages.

The kernel I use (almond) is based on Ammonite, but I believe there are others out there.

Re: Why I like Clojure

#109

Post by hombre_fatal »

Scarbutt wrote: post #78
Kalium wrote: post #68

Earlier quoted context omitted.

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…

Really though, Clojure web apps are at the php-no-framework level security days, not joking. The most used HTML templater(hiccup) doesn't do any secure output escaping, bad password/session management, auth*, sql injection, bad encryption methods, its all there.

You're right about Hiccup, but I don't understand the rest of your post.

What common SQL solution in Clojure are people using that introduces SQL injection, for example?

Post reply on HN