5 ms·
Last time I checked Weblocks it had an outdated documentation (as the original author left the project) and new developers were adding new super-cool stuff in s
by kunley 17y ago
Last time I checked Weblocks it had an outdated documentation (as the original author left the project) and new developers were adding new super-cool stuff in such way that using it actually involved becoming a dev on the project.
Few years later I experienced the same with UCW (beign another continuation-based web framework). And the same with Lisp-on-Lines (mr author, do you have something working outside of your own lisp image yet, after 5 years or so?)
Then I came to conclusion that there's some reason in the CL world that many projects become write-only vacuums with NIH syndrome, and their dev communities don't care of creating a _user_ base as they favor having _dev_ base. Also the term 'change management' or 'release management' seems to be incomprehensible by CL people. That causes almost impossible to deliver a product to the customer based on such software and stay sane.
- kunley 17y agoIn the second sentence I meant: Few years before.
- sedachv 17y agoUCW, Weblocks, and LoL were all started by people who did not understand web programming. If you're using continuations to "abstract" away browser-server interaction, you pretty much don't get web programming, period. Instead of focusing on the browser, these people want to focus on the server and pretend everything synchronously flows from there. This is a brittle and expensive (esp if you don't have first-class continuations!) illusion. That explains why the frameworks were not high-quality in the first place (note: I personally don't believe that any web framework is worth using), and more importantly why the people who started the projects left: they just don't care about web programming (or actually any programming that has to deal with asynchronous human input) and just wish it would go away. Release management is a catch-22 in the Lisp community: until people who maintain Free Software Lisp projects stop believing they don't have any users, they won't invest in it, but until they start investing in it, they'll continue to believe they have no users because people will just give up instead of complaining about it.
- kunley 17y agoSmart conclusions. I'd add to the Lisp-vs-release-management problem: The "I live inside the image" approach discourages delivering stable tested code changes, as it's quite hard to isolate them. I agree using a REPL is great for prototyping, but if one never builds from scratch, he can create the unmaintable code which doesn't work outside of a few specially crafted and hacked Lisp images. Luckily Clojure doesn't seem to hold this legacy. People usually seem to inject code into the repl when they code but then switch to builds using ant, maven or by some layer above them (see Leiningen). I do it as well, compile inside a repl as it's quicker, then compile from scratch before a commit. It seems to be a sane compromise. It's also good you can't save current "jvm image" so there's no temptation to never leave it. I have a sad observation that sticking to "live inside the image" actually produces lone-ego-superstar programmers not willing to cooperate.
- gruseom 17y agoI sadly agree that "lone-ego-superstar programmers not willing to cooperate" are more prominent in the CL world than in some others. (Edit: "semi-autistic pricks" is the term that comes to my mind. Still, many of us are not like that.) I'm also willing to believe that the Clojure community is refreshingly different in this respect. But I don't buy that "living inside the image" has anything to do with this, or at least anything to do with causing it, and I especially don't buy that a technical limitation of Clojure/JVM constitutes some sort of virtue.
- kunley 17y agoOTOH you can measure the technical limitation and then go around it in hours. That's a lot easier than struggling against social limitation for years (as w/ CL).