Lisp as a Vehicle for Rapid Prototyping (1997) | Hacker News Reader

Lisp as a Vehicle for Rapid Prototyping (1997)

nhplace.com

78 pointsoumua_don1722 comments

I've starting building my personal backends in Clojure and I am amazed at how easy and fast it is to get things going. The difference is even more remarkable for frontend code. I get my program into a state that displays some unfinished component and iterate until it's done. ZERO reloading is a huge time saver.

Now if I could only get my React Native programs running with Clojurescript...

Have you seen/tried https://github.com/drapanjanas/re-natal ?

There's been a lot of work around this lately. Here's an article: https://clojureverse.org/t/react-native-expo-with-shadow-clj...

tldr: npm install something fast hot reloads data-oriented clojurey goodness

re-natal does this and it works as advertised. Zero reloading, full repl connection to running program. There is no competition, and won't be.

I know what I'm doing tonight....rewriting my RN project

While I love lisp and use it for my projects, one should note that a lot has changed in the past 22 years. Python was far more primitive when this was written and ruby didn't exist.

The tooling around lisp is still a distinguishing factor though. I haven't found a free development environment for python that has even a small fraction of the power of SLIME (I don't use python quite enough to investigate commercial offerings, though the one time I used pycharm it was fairly nice, it didn't feel as dynamic as SLIME), and it still has a fairly strong edge against most dynamic languages in terms of optimizing compilers. For some reason, outside of smalltalk/lisp, AOT compilation never caught on with dynamic languages, where you see either an interpreter or a JIT.

Which part relevant to this article has changed? Python/Ruby still don't have a condition system. They don't have macros. Python added optional declarations recently but the compiler doesn't use them for optimization (or anything else). Generic functions are available as an add-on library, but aren't terribly well integrated. They both have separate debuggers which don't use their own language for debugging.

Python/Ruby do have dynamic redefinition and higher-order functions and a couple other nifty features, but most of the features I see on this page are still unique to Lisp.

- It is comprehensive.

- It supports modular design.

- It supports interactive development, debugging, and update.

These things are true of Ruby and Python in a way that they are not for C, C++, or to a lesser extent TCL.

I started learning a bit of Common Lisp a few weeks ago. It seems quite nice in many areas, but for rapid prototyping I feel like it cannot compete with Python. Maybe it's just because I'm more used to Python and imperative code in general, but so far I used no other language where I managed to get something working just as quickly and painlessly.

I switched from Python to Clojure. And I used handful of other PLs before that. I can say the same thing: "so far I used no other language [but Clojure] where I managed to get something working just as quickly and painlessly". I liked Python. But I love Clojure.

I have an on again off again relationship with LISP. I _loved_ scheme in college. I went to a college where java was predominately taught, but after my second year I rolled my dice with every professor to let me do assignments in scheme. A few went for it. It just clicked, and I felt like I could build anything.

After college, I didn't use any Lisps for a long time. I tried to get back to it. I tried installing common lisp. I remember the installation process being kind of insane. It felt like I was installing an operating system. The dev ergonomics were weird. I couldn't get it to click again like it did in college.

I messed with (fluxus) for a while. I LOVE live coding stuff, and it treating oGL as a first class standard library is so cool. It seemed like a single guy's passion project. It lacked some facilities that made it click as a daily driver. Also, installing it on my mac was a colossal pain in the ass due to pulse audio issues.

Not too long ago I installed racket. The installation process was painless, and I wrote enough with it that I started to feel that magic again... but then.. I .. wrote too much?

DrRacket was nice when I started, I like images appearing in the REPL. It quickly revealed itself to be hot steaming garbage. SCROLLING is so slow and flickery in a 225~ line source I wrote that it's beyond distracting.

I tried to play around with perlin noise, and generating an image of regular sizes required me to click this alert doubling Dr.Racket's ram allowance like 3 times. I'm sure that's my code's fault, but I'm probably not sticking with it long enough to find out..

I'll try again in a few years I guess.

Have you given Clojure a try?

I am a heavy Emacs user, so I need to occasionally write emacs-lisp. The other lisp I use from time to time is Fennel. Clojure I use at work. I have to say: having to use other lisps makes you appreciate how incredibly nice Clojure is. I think every programmer at least should try Clojure.

I've been obsessed with Clojure for a while, but seriously struggle finding a job where I can use it professionally. How'd you manage that? Any tips?

When was the last time you've tried? There's plenty of Clojure jobs today. Many Clojure companies (if not the most) are willing to hire remote. Clojure is steadily growing. Clojure conferences popping around the globe - Clojure/South, Clojure/North, Heart Of Clojure, ClojureTRE, Dutch Clojure Days, ClojureX (it feels like every European country has its own Clojure conf now).

I've been using Clojure for almost four years - switched three different jobs, never had a problem with finding a Clojure gig.

There are #jobs and #jobs-discuss channels on Clojurians Slack, watch those, some good job postings happen there.

Yes.

https://clojure.org/community/success_stories

https://clojure.org/community/companies

Hope that helps!

If your manager trusts you, and the organization is structured to support it, you occasionally get the chance to write a project in your language of choice. Be sure that you’re thoroughly proficient with the language, runtime, and tooling before trying to introduce it though.

I haven't. I've been prejudiced against the jvm for most of my career (mostly because of how heinously Oracle has treated Sun's corpse). I'm over it now.

Thanks for reminding me to consider it.

I'll look at it today.

It reminds me of a real world Scheme. Not identical, but similar.

I vaguely recall DrRacket had a scrolling repaint performance bug on OS X within the last year or so. If whatever problem you saw is not already fixed, you might file a bug report on it.

Anyway, DrRacket is mainly an educational IDE, for students who've possibly never written a line of code before. You could see its defaulting to memory-limiting sandboxing as a good thing for intro programming students. (I usually use Emacs, though I do sometimes use DrRacket, for quick tasks, and when I want to use the Macro Stepper.)

I don't know whether the new-ish Jupyter kernel for Racket supports images, but that might be something to look at.

There are also several other good Scheme implementations/variants. Racket has been my favorite, but I'm moving back to building atop RnRS, as unpaid time permits.

Any interpreted and most weakly typed langauges are great for prototyping.

lisp, clojure, python, php, ruby, javascript, prolog, smalltalk, basic, lua. I would say clojure & javascript lead the pack due to their support for concurrency.

Lisp is not interpreted or weakly typed. It is dynamically typed, but also strongly typed. And Common Lisp is typically compiled.

Reply on news.ycombinator.com