Why not? It seems interesting to me. I've always called scheme/racket a lisp, and I never knew that anyone felt differently. Does this mean that clojure is also not a lisp?
That discussion is about as pedantic as a discussion can be.
The main point against seems to be "they didn't name it Lisp". From there it goes into weird accusations like that people call Scheme a Lisp to defame Common Lisp (WTF?). They also say stuff like "Lisp and Scheme parted ways" which is just ignorant of the fact that "Lisp" in that context means "Common Lisp" and most people saying "Scheme is a Lisp" are basically talking about languages inspired by McCarthy's Lisp. But instead of making this reasonable counterargument, people start arguing that Scheme has a lot of similarities to Lisp (meaning Common Lisp).
And that link is one of the more intelligent debates on the subject. It's a long-running debate and most places I've seen it discussed are even more confused.
I just can't be arsed to give a fuck. Usually when I'm talking about Common Lisp I say "Common Lisp" because I value actual clear communication over saving six characters. And when I say "Lisp" I usually mean "languages inspired by McCarthy's Lisp" (which includes Scheme), but it's pretty rare I have anything useful to say about such a broad group of languages.
If scheme isn't a lisp, then clojure almost certainly isn't.
To use more widely known languages: Is C++ a C? What about Java? Javascript? Those languages share a lot of syntax and keywords between them, but they are clearly distinct languages.
On the other hand, most people feel comfortable classifying both FORTRAN and C as "in the algol family" while nobody would call either of them an algol.
Actually, if you're at all familiar with the history of FORTRAN, you can see how much it has changed, while nobody denies that FORTRAN 2003 is still as much FORTRAN as FORTRAN IV.
There are a couple misspellings that I've noticed, plus some awkward phrasing. Maybe get someone else to look over the copy on your site? This looks really helpful otherwise.
Sorry for that. We're some french guys and we try to do our best, but for now we did not have the chance to hire someone to correct that.
There's a "red thumb" on the left of each tip, you can warn us about misspellings with it, it will be widely appreciated :)
> Except that it incentivises a company to build a product that requires continuing support.
People say this a lot, but in our case we really haven't seen this incentive for a couple of reasons.
Large organizations are more than happy to pay for training and development support to accelerate their time to market. It doesn't matter how polished your product is -- databases are complex enough that people are willing to pay for best practices, training, and support.
Similarly, databases are pretty critical pieces of the infrastructure. If anything goes wrong, it can significantly impact the business, so people always want operational/production support.
There are many enterprise services that can be built on top of the product that can be very valuable. You don't have to build a crappy product -- there are plenty of ways to monetize with a great product.
Finally, a bad product will significantly limit growth of the company in the long term. There are lots of options now -- you can't get away with building a crappy product and an artificial monopoly.
If you see a crappy product from a company that offers subscription support, it's probably not because of misaligned incentives. Building databases is really hard, I don't think the business model has much to do with it.
I really would have benefitted from this when I was learning Clojure. There were a lot of "Getting Started" tutorials, but I could never find any that quite scratched the "experienced dev trying clojure for the first time" itch.
