Hacker News Reader

Comment by btilly | Hacker News Reader

Speaking personally, I don't want to work with an image based language. That's an argument against both Lisp and Smalltalk.

The problem with image based languages is that you've thrown away your file-based tool system. You're so used to your favorite text editor, source control system, etc? So sorry, we're building better tools! And when your code is ready, you just deploy the image!

It sounds great in theory, once those tools are delivered, but in practice you've lost more than you gained. No matter how good your environment, you do not beat the collective effort and productivity of file-system based tools.

What I say about image based tools also applies to code deployed in a database. Good luck keeping source control in sync with stored procedures...

View on HN

>The problem with image based languages is that you've thrown away your file-based tool system. You're so used to your favorite text editor, source control system, etc? So sorry, we're building better tools! And when your code is ready, you just deploy the image!

First, what's bad about that? Our text editors and source control systems are indeed crap compared to what we could get with image based systems with inherent (not text-level) knowledge of code. The only real argument is that we still need to work with legacy crap text-based languages also, which can't share those tools. But that's not really an argument against those tools being good in themselves.

Second, there's nothing about an "image based language" that says you can't also have a textual representation, and thus work with your editor (or the image based editor) and "regular" SCM tools.

Third, LISPs are generally not image based.

You are right that in principle an image based system should be able to produce a better tool for dealing with that environment than is possible with a text based system.

However no image based system is poised to take over the world. And I'm willing to bet my salary that none will ever have sufficient mind share to do so. Programmers switch languages, environments and operating systems. When you add switching tooling to the learning curve, you've just created a barrier to entry to the environment, and programmers are going to spend time learning something that is not applicable to whatever else they do next.

So you wind up with using "awesome tool if you just understood it" where your hires don't. And the "awesome tool" probably isn't quite what those people find most productive. So it becomes a constant frustration.

Move back to a text based language, and this problem goes away. People use the tools that they know. I'm probably going to write code in 4 different languages this week, and have to look at what is going on on a half-dozen machines..and won't need to switch tools.

On having a textual representation, yes you can do that. And then you've changed your image based language into just being yet another VM for another language. Whether you write code in Java, JavaScript or Python in the end it runs in a VM, and that doesn't matter.

As for LISPs in general, it depends. What I've seen with Lisp has mostly been image based, but I don't use Lisp very often.

> No matter how good your environment, you do not beat the collective effort and productivity of file-system based tools.

I bet people said the same about trains and ships. There was a lot of work put into horse-powered infrastructure and first cars and trains were very slow and bad. Same with boats: at the time steam-powered ships were created wind-powered clippers were 5 times faster and much more reliable.

The difference here is that image based languages have been making the argument that their better will beat every one else's larger community for decades. The one that came closest to realizing the dream was Smalltalk.

But somehow it never happened.

Fair enough, but not all Lisps are image based. Clojure is file based. That's the one I use.

Reply on news.ycombinator.com