The very mindset that "typical business applications that could be found in any enterprise" require some very special tools is one of the consequences.

Seriously, nowadays tools are so good, that you could really write in any popular language you like (in fact - in a few at once, depending of which one fits better for a sub-task).

The internet services, for some reasons, are not (mostly not) implemented in Java. This site, for example, is powered by author's very own dialect of Lisp. Slashdot has been written in Perl, Reddit is mostly Python.

The real problem is still software complexity and lack of programming/engineering (not coding) skills. Problem is with modeling and [de]composition, not with coding. Coders are cheap.

The business of [outsourced] Java sweatshops of unskilled coders "getting shit done" by quickly picking up methods out of IDE's context help without any understanding of underlying principles is like a whole sector of economy. Products they made in the most cases are exactly what they themselves call it - "shit done in exchange of salary".

But this subject is irrelevant here.

I've had a consultancy staff a large project with "senior Java developers" that we threw out the day they arrived on site because they couldn't pass a trivial coding test. This went on for a while until the consultancy became irate. While it might be nice to blame this on Java, I'm certain that if the leading enterprise language was ADA, we'd see ton's of marginally talented ADA developers being staffed. Whatever the dominant language is, you'll see a stark talent bell curve emerge around it.Think about it, if you can get a six figure salary by saying you know something, folks will say they know whatever it takes to get the job.

On the other hand, a lot of the stuff at Google is Java. Also, I can't imagine writing a reliable 1m lines of code system (say for a bank) in Lisp (or any other dynamic language for that matter).

Perhaps this is why the have "invested" in Go.

They also do some Common Lisp on the airline search division.

btw, Common Lisp is a "strong typed" language, and many large enough code-bases were here. Lisp machine ecosystem is a good example.

A lot of banking software has been written in 4GL and stored procedures (SQL). When Oracle stuffed its products with Java it was not necessarily an improvement, rather things became more difficult and messy than before.

> Perhaps this is why the have "invested" in Go.

I'm not sure how widely Go is being chosen (over say Java) for new projects inside Google. Maybe some Googler could clue us in?

> btw, Common Lisp is a "strong typed" language,

Can you point me to a code example? The ones I did find didn't have any type information in them.

> A lot of banking software has been written in 4GL and stored procedures (SQL). When Oracle stuffed its products with Java it was not necessarily an improvement, rather things became more difficult and messy than before.

Banking was just an example, and I'm sure they are plenty horror stories there involving Java (esp. when used in some awkward way). What I wanted to say is that IMO the effort to build and maintain large code base in for example Python would typically be much greater than in Java. For small code bases, I'm not sure who wins - the development phase will obviously be faster in Python (which is the only thing that matters for startups - hence python/ruby/... popularity here), but maintenance will still be a pain - after the initial devs leave, hires will need to learn that Python codebase, and lack of type information will make it harder.

Not sure if I've understood the question about types in CL.

  * (type-of 1)

  BIT
  * (type-of 123)

  (INTEGER 0 4611686018427387903)
  * (type-of "hi")

  (SIMPLE-ARRAY CHARACTER (2))
  * (type-of 'hi)

  SYMBOL
  *

And there is also typecase macro which is basically cond on type-of - the way to do dispatch on a type.

This technique of extending a language with new special forms using macros is the essence of Lisps.

I understand that, internally, everything is of some type.

What Lisp is lacking though is type declarations for variables, method parameters and returned values. These make codebases immensely more readable.

Common Lisp added type declarations in 1984.

A usual type declaration looks like this:

    (defun month-name (month)
      (declare (type (integer 1 12) month))
      (the string
           (ecase month
             (1 "Jan") (2 "Feb") (3 "Mar") (4 "Apr") (5 "May") (6 "Jun")
             (7 "Jul") (8 "Aug") (9 "Sep") (10 "Oct") (11 "Nov") (12 "Dez"))))

You can also declare the type of the function, outside of the function:

    (declaim (ftype (function ((integer 1 12))    ; the parameter list
                              string)             ; the return value
                    month-name))                  ; the function name

CLOS (the Common Lisp Object System) was added a few years later.

    CL-USER 1 > (defmethod add ((a integer) (s string))
                  (+ a (parse-integer s)))
    #<STANDARD-METHOD ADD NIL (INTEGER STRING) 402005B1C3>

    CL-USER 2 > (add 12 "23")
    35

What do you think the words 'integer' and 'string" are about?

I love it how we can have lisp code in just about any thread here :)

I didn't know you could do that in CL, thanks!

> I'm not sure how widely Go is being chosen (over say Java) for new projects inside Google. Maybe some Googler could clue us in?

Quite widely, for new projects.

A lot of those applications are the "bullshit jobs" of software, ie they are not actually needed. Many only exist because of insisting on only minor changes to existing processes. Many should be contracted out as services as they do not add value and differentiation. There is some stuff left of course.