Hacker News new | ask | show | jobs
by gnaritas 3327 days ago
> That's not how Lisp works. Macros are not simple code generators, where the workflow would be write macro code, expand that, and use the expanded code.

You're putting words in my mouth, and yes macros are just code generators. I didn't imply or say they're expanded and then devs use the expanded code. The whole point of them is you're not supposed to think about or see the generated code, the macro becomes the abstraction the dev works with.

> In this case the Lisp developer sees the generated objects: the getter, setter slot definitions. What the Lisp developer usually does not look at is the code generated by the macros. There are many macros, where there are no generated objects and the resulting code is extremely complex and large. Thus it would not make sense at all to present this code or edit this code...

Exactly the point I was making. You're actually agreeing with me though the tone doesn't come off that way.

> Actually that's the default mode. If you develop Lisp code with SLIME / GNU Emacs, it talks to a live Lisp system.

I said multiple times Lisp "can" work that way, stop being so defensive. But the point in fact is most Lisp developers don't work that they, they don't live in the REPL full time like Smalltalk devs do, you load from source quite often in comparison to the 0 times Smalltalk'ers do.

Look this isn't a competition; Lisp is technically superior to Smalltalk in features both due to macros and due to CLOS and its multiple dispatch OO system. Lisp was the inspiration for Smalltalk, Alan Kay goes so far as to call eval/apply the Maxwell's equations of computer science. However, I any many others having tried both Lisp and Smalltalk, prefer Smalltalk largely due to the syntax and dev environment. Emacs and Slime just don't cut it for us. Generic functions don't feel like object orientation, the way Smalltalk does OO just feels better and the dev environment feels better than anything else out there.

2 comments

> I said multiple times Lisp "can" work that way, stop being so defensive. But the point in fact is most Lisp developers don't work that they, they don't live in the REPL full time like Smalltalk devs do, you load from source quite often in comparison to the 0 times Smalltalk'ers do.

That Lisp developers load source does not mean that the image gets restarted. Lisp usually is designed such that you can incrementally update/manipulate the running image. As I said that's the dominant development style for Lisp, AFAIK.

> the dev environment feels better than anything else out there.

That's what my friends who still use Symbolics Open Genera tell me all the time. ;-)

On living in the REPL full time and having a better environment, is there something you wish Smalltalk could do to become a better environment that it doesn't?

What would feel better?

Yes, several, it's slightly too dependent on the mouse for focus; I'd rather never touch a mouse. I wish it used native windows (this is specific to Squeak/Pharo) so my editor felt like any other editor rather than a window within a window that it currently is (some other Smalltalk's do this but they're windows based and I'm on Linux). I wish the code browser had a back button so I could go dig into the source of something and then come back rather than popping a new browser to investigate that thing. Even better I'd like bookmarks like you get from more modern IDE's where you can mark a few key spots you want to constantly be jumping between rather than having a different browser open on each one.