It's not true that static typing always makes languages weaker. It makes map more powerful, for example: the desired type of output sequence can be inferred rather than having to supply a first argument of the same type like in Arc.

I used to agree with you, by the way -- static typing in most languages feels like a straight-jacket. ML wasn't enough to change my mind. It took Haskell.

Interestingly, heterogenous lists are the only example I ever hear cited for how ML-family type systems can cramp your style. It leads me to wonder if the situation is not unlike Fibbonacci sequences and naive recursion.

Anyway, I find that usually when I want a heterogenous list in Lisp, all I really need is a tuple. I want an ad-hoc way to group some values together (i.e., I don't want to bother creating a named structure), but I generally know the type I want in each position.

In the rare situations where I really do want a heterogenous list, Haskell does make it possible. The standard library has a Dynamic type that stores an arbitrary object along with a first-class manifest type identifier. These type identifiers have to be generated at compile time, but GHC has built-in syntax for this, and if it didn't it could still be implemented as a Template Haskell macro, or failing even that, just done by hand once for each user-defined type. That's all the support that's necessary from the core language -- the rest of the dynamic typing system is just an ordinary library.

Now, granted, if you wanted to use manifest typing for everything in Haskell, it would be ridiculously cumbersome and you'd be much better off just using a dynamic language[1]. But if you use it only where it's needed, then the dynamic casts will bloat your program by a couple symbols per thousand lines, and in return you get programs that damn near always work the first time they compile, along with a few other nicities like the one I mentioned above with map.

[1] There are plenty of cases where the converse is true. To name an obvious one, you could write a set of Lisp macros to implement lazy evaluation. But if you wanted to use them everywhere, you'd be much better off in Haskell.

I rarely need to calculate Fibonacci numbers, but I use lists of varied types of objects constantly.

So do I -- when I'm working in Lisp. Lisp gives you a Swiss army knife and lets you build specialized tools when you want them. Haskell gives you specialized tools and lets you build a Swiss army knife if you want it.

To be clear, this is what ML's variant types are all about. You can easily create a list that contains e.g. both ints and chars:

  let mylist = [`Int 5; `Char '5']

Technically the elements have the same compile-time type, but the question is, what practical difference does that make? In what cases are variants an inadequate solution?

I don't understand why CSS or HTML are being mentioned during the design of Arc. These seem like library issues and your announcement of Arc was spoiled IMHO by the "rant" about HTML and tables. This is only made worse by the Arc Challenge which seems to be more about the design of libraries for HTML/HTTP etc. than the language.

What am I missing?

If your language doesn't support anything but toy apps it quickly evolves to be optimized for building toys.

If the first Arc apps had not been full-featured Web apps, but had instead looked like examples from SICP, everyone would be complaining that the language was only good for computing Fibonacci sequences and writing interpreters for itself.

OTOH, you can't expect a new language to immediately offer the library resources of, say, Perl.

So the plan for Arc's early days seems to be similar to what the Pragmatic Programmer guys called the "tracer bullet" approach:

Tracer code is not disposable: you write it for keeps. It contains all the error checking, structuring, documentation, and self-checking that any piece of production code has. It simply is not fully functional. However, once you have achieved an end-to-end connection among the components of your system, you can check how close to the target you are, adjusting if necessary. Once you're on target, adding functionality is easy.

On day zero, Arc let you construct and deploy every aspect of a useful software system (a web app)... but it took a very narrow and direct path to that goal: emphasis on tables, no Unicode support, borrowing some functionality from an existing Scheme environment, etc., etc. That is what PG was trying to convey in his announcement: the strategic plan for Arc's early days is to work on designing a complete skeleton, but not add a lot of flesh.

I could tell from all the people already dissing Arc before it was released that whatever I released was going to be attacked on any possible pretense. So, like someone bracing himself to be hit, that was what I was thinking about as I was about to release it: what are people going to seize upon as a way of attacking it? Which meant that was what much of the initial announcement ended up being about.

It was a pretty odd situation to be in. If I'd been releasing Arc into a neutral environment, I probably would have said what I wrote in http://paulgraham.com/core.html. But maybe it's just as well I gave all the flames something to expend themselves on before talking about subtler questions.

I thought you handled it pretty well. Basically, you wrote a big sign saying "here is the bike shed", to make sure bike-shed commenters had something to occupy them. :)

Actually, it's probably beneficial to encourage flames. Your users are hackers, and flamewars are the only form of public dialogue among hackers. Ergo...

Fair enough, and after all: "Real programmers ship"

I doubt anyone would have commented on the tables thing if pg hadn't made a big deal out of it.

people did view source on hacker news, saw tables, and brought it up. pg didn't make a big deal out of it first.

Bringing it up about the website is a separate issue from bringing it up about the language.

By "Classic static typing", do you mean C++/Java-style static typing, or does it include Haskell/ML-style type inference as well?

I mean the kind that will not let you create a list whose elements could be of any type.

Java will happily let you fill a list or hash with objects that could be of any type yet it is generally the quintessential blub language.

No, it doesn't. Elements of a Java collection must all be of the same type. The elements may be implicitly coerced to a common supertype, but if you want to get the original types back you have to downcast--which is basically explicit dynamic typing.

You can always downcast in the presence of an instanceof case statement:

   ArrayList myList = new ArrayList(new Object[] { "foo", 42, new Bar() });
   for(Object elem : myList) {
      if(elem instanceof String) doStringThing((String) elem);
      else if(elem instanceof Number) doNumberThing((Number) elem);
      else if(elem instanceof Bar) doBarThing((Bar) elem);
      else doObjectThing(elem);
   }

Or you could keep elements as Objects until you needed to perform a specific operation on them, then cast at the site and perform the operation, letting the ClassCastException propagate if you're wrong. This is basically what Arc does.

Have you looked into optional static typing (e.g. EC4 style)? The default Array type for EC4 takes types of all kinds as well. It is a satisfying middle ground.

Thanks for the serious reply. I'm not sure I deserved it :) I appreciate your clarification of the distinction which is not clear from the "manifesto" (http://arclanguage.com/).

I suspected you deliberately mentioned ASCII-only and presentational markup because you knew it would tick off (and hopefully scare away) a certain type of perfectionist which you consider non-productive for explorative hacking.