Comment by numlocked | Hacker News Reader

Comment by numlocked | Hacker News Reader

This is very similar to my experience. There's definitely some friction getting started; the odd using/require macros for importing (which switched sometime in the last 2 years, which means a lot of out-of-date SO answers); the fact that most docs recommend using emacs which, if you aren't already a user, is not going to be easy to deal with; the parens.

But it's amazing. I do really miss types, but found that unit tests + Schema[0] serves my needs; they provide some type-ish enforcement, and do a terrific job documenting my code so that when I return to it months later, I have some idea of what's in all these map structures.

Another unsung feature is that emacs + paredit + s-exprs + repl means the actual mechanics of writing Clojure is wildly better than any other dev environment. The ability to operate confidently and consistently on semantic units of code vs. text is really amazing and I immediately miss it when I switch back to JS or Python. I'm sure other Clojurists felt they had already experienced something like FB's Prune when it was discussed here a few days ago.

Not to mention learning a Lisp really does increase your understanding of what's possible. I've seen others recommend holding off on playing with macros until you've become quite familiar with the language, but I couldn't disagree more. Play with them right away! I have perhaps ~200 hours of Clojure under my belt -- barely anything -- but I've hacked together a few useful macros. Though I barely understand how they work when revisiting them, it definitely increased my understanding of what's possible, and what's missing, in other languages.

So yeah...learn some Clojure. Just do it.

[0] https://github.com/Prismatic/schema

I spend most of my time in emacs doing elisp and python, where everything is smooth, small and stupid. I just got back into Eclipse/Java. And the culture shock is so strong I had anger attacks for two days.

The Enterprise world is quite weird, they don't really care about the code, it's just an artefact, the IDEs reflect that, the 'UX' too. They don't really want you or understand how to manipulate code fast. It's loads of declarations that gets in the way of thinking, all inside ergonomically poor tools that are supposedly necessary to survive (Types are nice, but Generic OOP still feels like a burden compared to functions + HM). They want documentation, they want an asset, that's how they 'manage' complexity in the long run. All of this so you can mutate tiny bits of arrays... Crazy.

It also shows how language and standard library design matters. Python APIs are often tiny, everything is in this language, you rarely have to fight to remember, it falls down pretty nicely, and in case you have doubts you're one repl/dir/help away from finding out. Different culture.

Of course, in other paradigms, what is taking so much energy would be done in a 3rd or maybe less, so you don't need all the ceremony...

Nice comment, especially your second paragraph. It's nearly exactly how I feel as well. What made you get back into Eclipse/Java?

Guess what, reality, I have to find a job, IT consultancy hires as always, JEE is still the main thing in enterprises. If this fails or maybe later, I'll try to switch towards Scala, Clojure, F#.

What's your line of work ? how many other languages do you know ?

I use clojure for 4 years now and I think I had to write macros only twice. In general, I'd advise against them and be wary of libraries that try to solve a lot of things with macros, the main reason being they are not easily composable and make things implicit that should be explicit.

The parens become less of a problem the more you know about clojure. You will find ways to traverse a map with very few parentheses that will make you grasp the code very efficiently. To this end I would recommend anyone starting clojure to do a few clojure koans each day and check their solution against the best solutions. www.4clojure.com

Finally, the tests (assertions via assert, :pre and :post) are indeed THE thing to use for both documentation and type checking and it allows to have kind of static typing where you want it. Of course, exceptions will only occur during run-time but your tests check for errors during run-time anyway, so why force someone to do type checking at compile time?

> In general, I'd advise against them

Why? Macros are the single most important productivity feature in Lisps.

Macros allow to implement eDSLs trivially, in the most robust way possible. Yes, you need to follow a certain discipline, but once you get it, you won't ever want to touch a language without macros.

Most of the macros in libraries were saving a pair of parentheses at the cost of making code more obscure and, well, less explicit. A few co-workers also liked macros alot so they did stuff that could have been done in functions.

I suppose my experience is that clojure's core macros are sufficient and/or I never saw a good eDSL that would have been worse without macros. (Input is welcome)

Also, I don't feel I missed out on something because the biggest productivity features for me are being functional, maps-as-objects + dynamic typing, destructuring, emacs (yeah I know), immutability, threaded execution via pmap, Java libs.

However, I suppose these productivity features depend strongly on where you come from (for me: Java)

> Most of the macros in libraries were saving a pair of parentheses

This is an epic misuse of macros.

> and/or I never saw a good eDSL that would have been worse without macros

eDSLs should almost never be implemented without macros (unless they're message DSLs).

Macro, essentially, is a compiler. The only alternative is to implement an ad hoc interpreter. And compilers are much, much easier to write, debug and maintain than interpreters - for some very trivial reasons. Compilers can be split into sequences of very simple stages, each doing something simple and comprehensible. It's easy to debug, easy to insert additional steps in between, easy to cut off at any point and replace the backend with something totally different. Interpreters are deeply tangled, naturally, there is no way to modularise them.

> the biggest productivity features for me are being functional

Using macros and eDSLs is another huge step forward in productivity that will dwarf everything you liked so far in FP.

> The only alternative is to implement an ad hoc interpreter.

You could also have your eDSL calls act as data constructors for an AST and then implement an `eval` function which invokes a run-time compiler.

This is not any different from a macro. You still translate your DSL into your host language AST, with the only final step different - runtime eval instead of a compile-time macro.

All my macros look like (defmacro something (dsl) (compile-dsl-whatever dsl)). You can always pass the same (compile-dsl-whatever dsl) to (eval ...).

I've been very successfully applying the data > functions > macros guideline. Yes, this makes eDSL's look very clojurey, but in practice I've not seen this to be a problem.

That is: prefer a data-structure based DSL (eg Datomic queries) if possible. If not, prefer function composition. Failing that, macros to the rescue.

My understanding is that the Clojure community discourages the use of macro. The preference is to use data over functions, and functions over macro. The reason is that macros do not compose well.

Yes, macros are good for developing DSLs, so they are mostly used in developing libraries, but most application developers do not need to use macro. The wide spread macro usage probably contributed to the fragmentation of CL community. Taking such lessons to heart, Clojure library authors tend to reuse commonly accepted DSL forms, e.g. hiccup is the DSL for writing HTML, and most authors have adopted it when developing their own libraries. I think this is a good thing.

Then the entire community got it all wrong. DSLs are much, much more composable than functions. You can easily compose just parts of DSLs, building new DSLs on top by combining semantic properties from the existing DSLs.

It's just a very different way of thinking about programming in general, and many people just don't get it.

Macros look like the single most important productivity feature in Lisps only when we are comparing to languages that have borrowed almost everything else, so that we are discounting those other things, consciously or not.

I'd trade any language without macros to the same language, but with the proper macros added. And then I'll get all the features I want - lambdas, garbage collection, numeric tower, lazy evaluation, any imaginable type system, whatever else (of course, there are some limits, I would not be able to get an image-based system and a REPL if the host language runtime does not allow it).

It's a nearly infinite flexibility, no other single feature or a combination of language features can do this.

Note: you don't need to commit to Emacs to get the productivity benefits of Clojure.

Eclipse with the Counterclockwise plugin (and I believe IntelliJ with Cursive too) also give you comprehensive REPL, s-expr manipulation and paredit features.

vim with fireplace.vim and paredit.vim plugins are pretty nice as well.

The benefit of CIDER (the Clojure Emacs development environment) is that it now has a s-expr based debugger, whereas Cursive's debugger is still call stack based. So you can traverse the AST like in any other Lisp debugger and evaluate and manipulate s-exprs as you go.

> Another unsung feature is that emacs + paredit + s-exprs + repl means the actual mechanics of writing Clojure is wildly better than any other dev environment.

Not if you take commercial Common Lisps devenvs into account.

Beside Franz who else is out there ?

There is LispWorks.

And I dare to say that even Macintosh Common Lisp had a better developer experience than current Emacs based tooling, but lispm can correct me on that.

Ha, for a reason I always thought Franz and LW were the same u_u;

Dare, dare, my friend, but give me some details :)

Reply on news.ycombinator.com