All the Perl that's Practical to Extract and Report

Arc Is Taking Over the World

Ovid on 2008-05-08T11:36:54

Er, no it's not. This brief (and snarky) blog post pretty much sums up my feelings.

I've already been pretty critical of Arc, but pretty much ignored it after that. I've taken another peek and, once again, I'm still terribly impressed. Paul Graham has made arc code smaller for those projects he wants to focus on. He does this with decent libraries (well, decent if you don't mind 'ASCII-only' and layout controlled via HTML tables).

Welcome to the Intarweb, circa 1999.

I probably wouldn't be this harsh, but Graham has spent so long talking about "superior" programming languages that he pretty much had to knock this out of the park or tone his rhetoric down.

Agreed, sort of

jrockway on 2008-05-08T13:17:49

The linked blog post is stupid. You can't judge a language based on its most popular web framework. (Rails is *not* Ruby!) HTML tables have nothing to do with programming. They work, so who cares!?

The real problem with Arc (and a lot of other new lisps; Clojure for example) is that it tries to be not Lisp by forcing syntax onto the user. The point of Lisp is that syntax is words and lists. When you start adding a bunch of weird-ass constructs to the language, you end up with a really shitty version of Perl. Except Arc doesn't have any regex library.

Anyway, don't get too upset about Arc. pg's points about Blub still hold... if you want to laugh hysterically sometime, remember that there is a whole world of people that think PHP is the perfect programming language. (See this discussion on pg's own site, the results are ... hilarious: http://news.ycombinator.com/item?id=181993. Note that PHP programmers consider OO, regular expressions, and libries "academic" and "not necessary for the real world". Give me my cut-n-paste!!111!)

Anyway, my point is that although Arc isn't really that exciting, your post doesn't really add much to the discussion. You don't like Arc. Great.

Re:Agreed, sort of

Ovid on 2008-05-08T13:33:23

It's not that I don't like Arc. I really don't know enough about it and two of the things that I would need to use it seriously simply aren't there. I also agree completely with Graham about 'blub'. My issue is that he spent a lot of time getting people excited about, well, nothing much. If you're going to whip people into a lather about something and it's not vapourware, you're going to look pretty silly when it fails to live up to its hype.

Seaside - the next web framework

merlyn on 2008-05-08T13:55:18

It's far more likely that the growing interest in Seaside will make Arc simply a blip.

Re:Seaside - the next web framework

Ovid on 2008-05-08T16:12:15

I've noticed you've been blogging about that in your Smalltalk blog, but I confess that while I love the programming language inherent in Smalltalk, the whole idea of an "image" is a bit much to swallow. (It sounds like a fantastic idea, but something I'd have to wrap my head around).

That being said, it rather sounds like much of the power of Smalltalk would be gutted by switching over to a file-based system.

Re:Seaside - the next web framework

merlyn on 2008-05-08T16:20:24

If you want a file-based approach, there's always the GNU Smalltalk, which is being actively maintained and just recently got the ability to run Seaside.

However, I still don't understand why people object to images. Think of it as "your application, with an embedded great IDE, library, and debugger". Very simple. You don't object to the debugger being part of the Perl application when you say "perl -d", do you?

Re:Seaside - the next web framework

jplindstrom on 2008-05-08T17:48:24

I guess it's the play-well-with-others aspect, when a file is not the primary unit of source code any more.

So it's impossible or difficult to use existing knowledge and infrastructure for e.g. source control. (or is it?) (I've heard there are vcs specifically for Smalltalk code.)

But a project is never just the source code, there are always other artefacts; SQL files, web pages, images, requirements documents, text files, diagrams, whatever, that needs to be managed somehow.

What's the normal way of dealing with all that extra stuff in a Smalltalk project?

Re:Seaside - the next web framework

chromatic on 2008-05-08T18:06:45

However, I still don't understand why people object to images.

Images and $5000 per seat licenses are two reasons Smalltalk nearly died in the early 90s.