[bbcbasic]

If your startup is dependent on solving chicken and egg marketing problems the choice of Lisp vs. something else is fairly irrelevant as you said. This is the case in most startups that take a traditional business (e.g. Taxi) and modernise it (e.g. uber). The level of tech required to do that is not going to be cutting edge. It is quite rote to solve these things in RoR or PHP.

On the other hand there may be some startups where the choice of language really matters. One thing I can think of is how a lot of Enterprise software is a big feature fest with massive complicatedness coming from a mixture of the real-world muckiness of the problem, and poor architectural choices. Such shops require armies of programmers to maintain their bloated wares. Maybe a startup with a much more thoughtful approach, using a Lisp/Haskell/etc. type language and a small number of developers can have a big competitive advantage.

Customer "we need a new feature". Startup "sure we'll add a rule and you'll have that tomorrow". Old business "that will take 3 months and cost $1m"

[dkarapetyan]

I think you're making the case for language irrelevance even more. The reason big corp. can't move fast isn't because of their technology choices. It is because of all the bloatware and bureaucracy. You can be bureaucratic and bloated in any language.

[backlava]

But in some languages bloat is a best practice.

[bbcbasic]

It's all about how many adjectives you can get into your class name. e.g.

   SingletonFactoryAdaptorFacadeProviderEnumerator<BridgeAbstractFactory2_Hack> myClass;

With Haskell it is about how big your monad stack is

    StateT ReaderT WriterT LensifierT MaybeT BeerT (IO Int).

[eru]

Monad stacks are so last decade.

[bulte-rs]

So this is why the golang community prefers:

    for c := range(ns) {
        // some blah
    }

[rakoo]

The golang community likes being safe:

  a, err := doFirstThing()
  if err != nil {
    return err
  }

  b, err := doSecondThing(a)
  if err != nil {
    return err
  }

  c, err := doThirdThing(b)
  if err != nil {
    return err
  }

until your keyboard keys go off.

(and I'm a happy gopher myself)

[eru]

Oh, small typo (I think): no parens around (IO Int).

[tl]

I'm not sure that matters either.

Let's say you're talking about Java. A "bad" team will have mountains of code. A "good" team will apply Greenspun's Tenth Rule and use a lisp to compress down the mountain to the extent that "lisp" can compress it over Java.

You may protest that the lisp has angle brackets and that it's inferior to say Clojure, but the machine does not care.

[bbcbasic]

Yes because the causation goes the other way.

The kind of org that cares about how it writes software will choose the right tool for the job, which may be Lisp. However they may be able to achieve their aims in Java. Whatever they choose it would have been carefully considered.

The kind of org that doesn't care how it writes software is unlikely to choose an outlier language and will use C#, PHP, Java etc. because it is easier to hire devs and you won't get fired for choosing it.