false premises, false conclusions, and bad good ideas in-between.
False constructive criticism (since you've spammed your stuff 5 times), and bad (hostile) behavior which, I found, it's way more common in the Common Lisp community than in other languages.
I just gave my experience of testing the creation of a Common Lisp web app using different libraries, and instead of a guide of >20 pages, I condensed a bit of code in a single article. I could not find a quick tutorial for Caveman so I decided to write a short one. Is it such an issue?
Burn this article with fire ;)
You probably got triggered for my conclusions but I still stand for it. I really like Common Lisp and I'm a Lisp fan in general, but to write generic modern web app I think there are languages that fit better. Most of the web app they would not benefit from having such a powerful language as Common Lisp in the back-ent, I would even think it can be harmful in some cases when you need to hire, and I say this having worked with Lisp dialect in production.
oh, hello. Yes, you write "I was surprised by the absence of a quickstart page to help me set up a simple server", that's spreading FUD. Many such tutorials have been written.
I could not find a quick tutorial for Caveman
But what about Caveman's own README? It's a tutorial.
You would phrase differently I could not discuss it (like your first sentences on CL's documentation state in general). The "absence", I can. Words are important.
triggered
yeah obviously, and by the fact that I put efforts to improve CL's (web) documentation situation.
hostile
abrupt and impatient, yet relevant? I make some points.
The criticism and response both feel a bit too sensitive, but I do want to support having your own opinion/conclusion on CL probably not being the best language for the job when it comes to web stuff, or as I would phrase it CL not being the most defensible choice for web back-ends. I think it can be defensible, even just on the grounds of direct web application concerns, independent of what the actual purpose of the application is, and I'll continue trying to write everything in CL, but I sympathize with the opposition and recognize a strong argument has to be made for CL. Other options enjoy popularity and default-choice status.
My primary reason is like: there's a lot of complexity in the modern web, and it really is quite convenient if you can lean on some ecosystem that pushes things under the rug for you and is trustworthy enough to keep doing so for years to come as things change. All the basic table stakes stuff like CSRF protection, sending custom CORS/CSP headers, database interfaces, logging, metrics, bcrypt hashing, selenium webdriver automation, etc. etc. all have their core pieces available in CL, but you still have to know about them and opt-in to them and occasionally roll up your sleeves to do things your own way from scratch. They also don't all have great documentation, maintenance, or integration with each other. (There's even some dumb github drama I happened to notice being mentioned on discord the other day around a breaking change related to websocket code. Even if it doesn't affect me it's discouraging.) I don't mind rolling up my sleeves (and it can be a way to keep up to date), my own blog I haven't gotten around to rewriting in CL is still just raw PHP I wrote the majority of in 2009, with its own custom micro-framework and template system. Back then I was pretty anti-framework (I still am to an extent) but frameworks are pretty convenient, whether they're micro ones like Flask, slightly larger (if now outdated) ones like Yii, or the big boys. (I liked how for a CRUD project I did for a client in 2012, Yii had the ability through a developer mode web page to generate a bunch of code for you, rather than a separate command line tool or just shrugging and telling you to write your own macros: https://www.yiiframework.com/extension/yiisoft/yii2-gii/doc/...) All that to say that the framework options for Lisp aren't really there if you have expectations from other ecosystems like PHP, Python, Ruby, or Java, and when it comes to ever changing web stuff, ecosystem has more impact than the core language.
A secondary reason is even more my own perspective and perhaps isn't entirely fair, but it seems a lot of people doing web stuff in Lisp are doing it mostly because we love Lisp and find its workflow and feature set the best, the language is a great fit for any actual purpose/problem the application aims to solve regardless of the web bits. (I don't think it matters much if your "needs" are just modest or generic CRUD level, like a certain defunct license contract subscription and renewal tracker, or something more complex or long-lived like google flights or grammarly.) To put it another way, you don't tend to see a lot of super passionate people for the web platform itself. Like check out this Rails keynote from last year https://www.youtube.com/watch?v=-cEn_83zRFw dhh is if anything passionate and has been doing this for 20 years. Even if one might disagree with his solutions (I don't particularly like Ruby itself) there's clearly a lot of value there and real problems being solved for people at a level prior to their actual application's main concern.
Comments
False constructive criticism (since you've spammed your stuff 5 times), and bad (hostile) behavior which, I found, it's way more common in the Common Lisp community than in other languages.
I just gave my experience of testing the creation of a Common Lisp web app using different libraries, and instead of a guide of >20 pages, I condensed a bit of code in a single article. I could not find a quick tutorial for Caveman so I decided to write a short one. Is it such an issue?
You probably got triggered for my conclusions but I still stand for it. I really like Common Lisp and I'm a Lisp fan in general, but to write generic modern web app I think there are languages that fit better. Most of the web app they would not benefit from having such a powerful language as Common Lisp in the back-ent, I would even think it can be harmful in some cases when you need to hire, and I say this having worked with Lisp dialect in production.
oh, hello. Yes, you write "I was surprised by the absence of a quickstart page to help me set up a simple server", that's spreading FUD. Many such tutorials have been written.
But what about Caveman's own README? It's a tutorial.
You would phrase differently I could not discuss it (like your first sentences on CL's documentation state in general). The "absence", I can. Words are important.
yeah obviously, and by the fact that I put efforts to improve CL's (web) documentation situation.
abrupt and impatient, yet relevant? I make some points.
The criticism and response both feel a bit too sensitive, but I do want to support having your own opinion/conclusion on CL probably not being the best language for the job when it comes to web stuff, or as I would phrase it CL not being the most defensible choice for web back-ends. I think it can be defensible, even just on the grounds of direct web application concerns, independent of what the actual purpose of the application is, and I'll continue trying to write everything in CL, but I sympathize with the opposition and recognize a strong argument has to be made for CL. Other options enjoy popularity and default-choice status.
My primary reason is like: there's a lot of complexity in the modern web, and it really is quite convenient if you can lean on some ecosystem that pushes things under the rug for you and is trustworthy enough to keep doing so for years to come as things change. All the basic table stakes stuff like CSRF protection, sending custom CORS/CSP headers, database interfaces, logging, metrics, bcrypt hashing, selenium webdriver automation, etc. etc. all have their core pieces available in CL, but you still have to know about them and opt-in to them and occasionally roll up your sleeves to do things your own way from scratch. They also don't all have great documentation, maintenance, or integration with each other. (There's even some dumb github drama I happened to notice being mentioned on discord the other day around a breaking change related to websocket code. Even if it doesn't affect me it's discouraging.) I don't mind rolling up my sleeves (and it can be a way to keep up to date), my own blog I haven't gotten around to rewriting in CL is still just raw PHP I wrote the majority of in 2009, with its own custom micro-framework and template system. Back then I was pretty anti-framework (I still am to an extent) but frameworks are pretty convenient, whether they're micro ones like Flask, slightly larger (if now outdated) ones like Yii, or the big boys. (I liked how for a CRUD project I did for a client in 2012, Yii had the ability through a developer mode web page to generate a bunch of code for you, rather than a separate command line tool or just shrugging and telling you to write your own macros: https://www.yiiframework.com/extension/yiisoft/yii2-gii/doc/...) All that to say that the framework options for Lisp aren't really there if you have expectations from other ecosystems like PHP, Python, Ruby, or Java, and when it comes to ever changing web stuff, ecosystem has more impact than the core language.
A secondary reason is even more my own perspective and perhaps isn't entirely fair, but it seems a lot of people doing web stuff in Lisp are doing it mostly because we love Lisp and find its workflow and feature set the best, the language is a great fit for any actual purpose/problem the application aims to solve regardless of the web bits. (I don't think it matters much if your "needs" are just modest or generic CRUD level, like a certain defunct license contract subscription and renewal tracker, or something more complex or long-lived like google flights or grammarly.) To put it another way, you don't tend to see a lot of super passionate people for the web platform itself. Like check out this Rails keynote from last year https://www.youtube.com/watch?v=-cEn_83zRFw dhh is if anything passionate and has been doing this for 20 years. Even if one might disagree with his solutions (I don't particularly like Ruby itself) there's clearly a lot of value there and real problems being solved for people at a level prior to their actual application's main concern.