Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Exposure to Go and Clojure brings the opposite effect:

"I don't really want this glitzy thing. Functions, plain data and a bit of polymorphism is all it takes to solve the problem"



uh... clojure is a lisp and supports full blown macros. Surem 95% of the time, Functions, plain data and a bit of polymorphism is all you need. those higher abstractions are for flattening the curve on making easy to use libraries. They are sharp tools. Go decides to hand you safety scissors, clojure gives you a high end razor sharp knife and expects you to be educated on its proper usage.


And that "proper usage" is basically "never".

I remember a lot of macros-based libraries early, however it turned out they are not composable, so they grew a plain functions-and-data interface. New libraries don't use macros much.

AFAICT the role of macros in modern Clojure is limited to new control constructs.


Early clojure reflected a bit early macro-enabled compiled lisps where macros were heavily used due to (perceived) cost of function call.


But in that case what is the benefit of Clojure being a Lisp?


“And solving the problem in the simplest way possible is what I’m paid to do.”




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: