Competition is not ALWAYS good
in [Lisp]
|
From: Slobodan Blazeski on 5 May 2008 04:05 On May 3, 11:03 pm, "Alex Mizrahi" <udode...(a)users.sourceforge.net> wrote: > SB> Competition is not always good. There is some economic goods that > SB> doesn't work with laisse fare market , because they're natural > SB> monopolies. > > web frameworks are not natural monopolies! > > SB> avoid them. So lisp has a lot of toy web framework, but none a serious > SB> one. > > you think that web framework has to be very complex. > believe me, it's not. > it's something that a experienced person can hack in couple of weeks -- and > it will be of quality that is *enough* for making useful commercial web > sites. > it's not a rocket science > > actually that becomes a problem if web framework becomes too complex -- that > means that it's over-engineered, and needs to be simplified. > > SB> So I think we should have 1-2 web frameworks that doesn't > SB> suck, than a gadzilion of toy ones > > if there are gadzilion of them, that just means building one is easy. > as there are many different applications, it's quite natural to have many > different web frameworks that naturally fit applications (or are supposed > to). You're arguments sound like amateur cook award constest winner telling people that should drop premade food and hot dogs and cook their own healthy and tasty meal. Well most of the people don't give a damn about cooking or creating web frameworks, they want just to glue things and get done their job. Something that's interesthing for them. Creating web framework is not easy, if you take as web framework: 1. Core 2. Premade widgets / controls whatever 3. Documentation 4. Learning material (tutorials , books etc) 5. Community 6. MANY of sites up and running The only things that is relatively easy (and fun for some people) s making 1, with some of 2, and next to nothing of the rest. Or with other words I could make lisp implemenatation (interpreter for a subset of lisp)over the weekend but making something like allegro or sbcl takes a lot of time. > > SB> I started working with weblocks instead of UCW because UCW was a total > SB> unportable sbcl/linux specific mess. > > and you have reasons to use something else than sbcl/linux? I use whatever I want to use, one os/lisp framework is bad idea in my eyes you mileage may vary.
From: Alex Mizrahi on 5 May 2008 06:05 ??>> if there are gadzilion of them, that just means building one is easy. ??>> as there are many different applications, it's quite natural to have ??>> many different web frameworks that naturally fit applications (or are ??>> supposed to). SB> You're arguments sound like amateur cook award constest winner telling SB> people i'm not giving advices here -- i just point to a fact that it is possible to make successful projects both with self-made and third-party toolkits. which way is feasible certainly depends on project's need. you seem to have preconceptions that web toolkits are very complex things. they are not -- just do an experiment, i'm pretty sure you'll be able to hack something working in a day or so. SB> that should drop premade food and hot dogs and cook their own healthy SB> and tasty meal. you don't need to be a "contest winner" to cook things. SB> Well most of the people don't give a damn about cooking or creating SB> web frameworks, they want just to glue things and get done their job. i don't mind, there are open source frameworks available, aren't they? SB> Something that's interesthing for them. Creating web framework is not SB> easy, if you take as web framework: SB> 1. Core SB> 2. Premade widgets / controls whatever actually only this is essential for successfully using a web framework SB> 3. Documentation SB> 4. Learning material (tutorials , books etc) i do not see anything problematic here -- if we are speaking about a simple toolkit, it will require relatively small amounts of documentation and learning materials, and they will be quite easy to do. many sane programmers document their code no matter what they are doing. also, if we are speaking about in-house framework, used by a person who wrote it, it doesn't need much documentation, since that person already know it. if there is a bunch of developers working on a project, they can teach each other verbally. certainly some larger development team would require documentation -- but often such larger teams already have documentation policies, so it's not a problem. SB> 5. Community growing community requires good product and some time. but if product is actively maintained, it's maintainer(s) can provide "community help" -- this works fine until product becomes very complex. and again, for in-house development there are no problems with community. SB> 6. MANY of sites up and running huh? let's also include fancy logo, site, slogan and whatever else is required to satisfy you SB> Or with other words I could make lisp implemenatation (interpreter for SB> a subset of lisp)over the weekend but making something like allegro or SB> sbcl takes a lot of time. the difference is that Allegro and SBCL have to implement full Common Lisp standard and other things like FFI, while toolkit just needs to satisfy needs of one application. SB>>> I started working with weblocks instead of UCW because UCW was a SB>>> total unportable sbcl/linux specific mess. ??>> and you have reasons to use something else than sbcl/linux? SB> I use whatever I want to use, one os/lisp framework is bad idea in my SB> eyes you mileage may vary. in other words, you have some "religious" preconceptions about different operating systems and Lisp implementations, and you care more about following your preconceptions rather than getting things done in most effective way.
From: Slobodan Blazeski on 5 May 2008 06:48 On May 5, 12:05 pm, "Alex Mizrahi" <udode...(a)users.sourceforge.net> wrote: > ??>> if there are gadzilion of them, that just means building one is easy. > ??>> as there are many different applications, it's quite natural to have > ??>> many different web frameworks that naturally fit applications (or are > ??>> supposed to). > > SB> You're arguments sound like amateur cook award constest winner telling > SB> people > > i'm not giving advices here -- i just point to a fact that it is possible to > make successful projects both with self-made and third-party toolkits. > which way is feasible certainly depends on project's need. > > you seem to have preconceptions that web toolkits are very complex things. > they are not -- just do an experiment, i'm pretty sure you'll be able to > hack something working in a day or so. > > SB> that should drop premade food and hot dogs and cook their own healthy > SB> and tasty meal. > > you don't need to be a "contest winner" to cook things. > > SB> Well most of the people don't give a damn about cooking or creating > SB> web frameworks, they want just to glue things and get done their job. > > i don't mind, there are open source frameworks available, aren't they? > > SB> Something that's interesthing for them. Creating web framework is not > SB> easy, if you take as web framework: > SB> 1. Core > SB> 2. Premade widgets / controls whatever > > actually only this is essential for successfully using a web framework > > SB> 3. Documentation > SB> 4. Learning material (tutorials , books etc) > > i do not see anything problematic here -- if we are speaking about a simple > toolkit, > it will require relatively small amounts of documentation and learning > materials, and they will be quite easy to do. > many sane programmers document their code no matter what they are doing. > > also, if we are speaking about in-house framework, used by a person who > wrote it, it doesn't need much documentation, since that person already know > it. > if there is a bunch of developers working on a project, they can teach each > other verbally. > certainly some larger development team would require documentation -- but > often such larger teams already have documentation policies, so it's not a > problem. > > SB> 5. Community > > growing community requires good product and some time. > but if product is actively maintained, it's maintainer(s) can provide > "community help" -- this works fine until product becomes very complex. > > and again, for in-house development there are no problems with community. > > SB> 6. MANY of sites up and running > > huh? let's also include fancy logo, site, slogan and whatever else is > required to satisfy you > > SB> Or with other words I could make lisp implemenatation (interpreter for > SB> a subset of lisp)over the weekend but making something like allegro or > SB> sbcl takes a lot of time. > > the difference is that Allegro and SBCL have to implement full Common Lisp > standard and other things like FFI, > while toolkit just needs to satisfy needs of one application. We have misunderstanding of the view. There is a nice book called crossing the chasm, Erick Sink wrote about it at http://www.ericsink.com/Act_Your_Age.html . Paraphrasing the basic idea fallows a short explanation. Basically there are 5 types of peoploe in in technology acception. Innovators, Early adapters, pragmatists, conservatives & laggards. Innovators like Lars Rune start something new - Symbolic Web in our case. So he has to *sell-it*(for lack of better word, if he wants to be something that othe people beside he and his team will use it. So there will go with curve of adaptation. There is different types of people: 1. Early Adopters don't need much convincing. Some of them will try your product just because it's new. They don't wait for anybody else's endorsement. They are leaders who prefer to be on the bleeding edge of technology. 3. Pragmatists will only buy your product when they see other Pragmatists doing it. If this sounds like a chicken-and-egg paradox, it is. 4. Conservatives will buy your product only after they see that the Pragmatists are happy with it. 5. There is no way to predict the behavior of the Laggards. They may never buy your product. You can safely ignore them. So Symbolic web, will quickly gather early adapters, but they will leave it as soon as something newer emerges. In order to succeed it needs pragmatists. And they are hardest to get, because they're *buying* only when they see other pragmatists buying. These people are nothing like you. You're a geek and you enjoy technology for its own sake. ***They just want their problems solved***, and they don't care in the slightest about the religious wars we fight amongst ourselves. Don't assume you know anything about the problems they're facing. So you Alex, Lars Rune and Slava are the innovators. Your communities are the early adapters. The people who are screaming for one quality web framework are pragmatists. Maybe someday one web framework will win the war, but untill then pragmatists will not make their sites in lisp. > > SB>>> I started working with weblocks instead of UCW because UCW was a > SB>>> total unportable sbcl/linux specific mess. > ??>> and you have reasons to use something else than sbcl/linux? > SB> I use whatever I want to use, one os/lisp framework is bad idea in my > SB> eyes you mileage may vary. > > in other words, you have some "religious" preconceptions about different > operating systems and Lisp implementations, > and you care more about following your preconceptions rather than getting > things done in most effective way. That you are wrong I like sbcl and use it with Ubuntu.But if expecting code to be portable across at least allegro/lw/sbcl and windows/linux (I don't have access to Mac) is a religion then yes I am religious.
From: Alex Mizrahi on 5 May 2008 08:02 SB> We have misunderstanding of the view. There is a nice book called SB> crossing the chasm, Erick Sink wrote about it at http://www.ericsink.com/Act_Your_Age.html . SB> Paraphrasing the basic idea fallows a short explanation. Basically SB> there are 5 types of peoploe in in technology acception. SB> Innovators, Early adapters, pragmatists, conservatives & laggards. you see web framework as a must-use product. but many [web] applications simply do not need any sophisticated web frameworks at all -- they can just be built on top of very basic libraries, e.g. mod_lisp, or even without them. for example, consider PHP. standard PHP package does not include any framework -- it just supports integration with Apache, that is roughly equivalent to mod_lisp. yet ordinary people (not some uber-cool hackers or innovators) can implement their applications in bare PHP -- and be quite successful with this. moreover, ones who use frameworks often end up with over-engineered solutions and are damn hard to maintain. of course, if you build application that is very similar to other applications you've written, it's better to abstract common things, and create so-called framework. but often these applications are too different, and abstracting things from them leads to overly-complex solutions. ??>> in other words, you have some "religious" preconceptions about ??>> different operating systems and Lisp implementations, and you care ??>> more about following your preconceptions rather than getting things ??>> done in most effective way. SB> That you are wrong I like sbcl and use it with Ubuntu.But if expecting SB> code to be portable across at least allegro/lw/sbcl and windows/linux SB> (I don't have access to Mac) is a religion then yes I am religious. even religious people have some reasoning behind their beliefs. but what's your reason to require portability for webapp? unlike desktop application, web applications are typically deployed in controlled fashion -- people pick a server for application and configure it according to application demands. so for people who actually want application up and running portability has very little value. and it's quite adequate decision to sacrifice portability for, say, features, or just cut development time on it. it's another question if you're developing tools rather than application itself -- tools might be required to play with other tools.
From: Slobodan Blazeski on 6 May 2008 07:32 On May 5, 2:02 pm, "Alex Mizrahi" <udode...(a)users.sourceforge.net> wrote: > SB> We have misunderstanding of the view. There is a nice book called > SB> crossing the chasm, Erick Sink wrote about it athttp://www.ericsink..com/Act_Your_Age.html. > SB> Paraphrasing the basic idea fallows a short explanation. Basically > SB> there are 5 types of peoploe in in technology acception. > SB> Innovators, Early adapters, pragmatists, conservatives & laggards. > > you see web framework as a must-use product. > but many [web] applications simply do not need any sophisticated web > frameworks at all -- they can just be built on top of very basic libraries, > e.g. mod_lisp, or even without them. > > for example, consider PHP. standard PHP package does not include any > framework -- it just supports integration with Apache, that is roughly > equivalent to mod_lisp. > yet ordinary people (not some uber-cool hackers or innovators) can implement > their applications in bare PHP -- and be quite successful with this. > > moreover, ones who use frameworks often end up with over-engineered > solutions and are damn hard to maintain. > > of course, if you build application that is very similar to other > applications you've written, it's better to abstract common things, and > create so-called framework. > but often these applications are too different, and abstracting things from > them leads to overly-complex solutions. And people prefer overly-complex solutions than bare metal things, Strategy Letter IV: Bloatware and the 80/20 Myth http://www.joelonsoftware.com/articles/fog0000000020.html it's people like YOU who are fluent in the field who like tweak and build with barebones, the rest of us just wan't get things done. People use php because there is god damn script for everything, you need a calendar here it is, credit card page with luhn formula balidator here it is, connection with mysql embedded ... I tried once php and managed to without learning much of it make a pretty good site by picking up the staff on the internet. In lisp I would have to write manually. I *suspect* that's the way people especially layman build apps in php. So when I say web app for lisp I expect something that could be done by GLUING not PROGRAMMING, because I hate to program in things that doesn't interest me. Once we have a project in php and client especially that all controls should be prefabricated. And if your framework (including community and firms) doesn't offer control that I need I'm not going to write it myself, I'll use another one that has it, and I don't give a f*ch about managebility, your code needs to grow a lot in size to become unmanageable. So there is no good enough web framework for pragmatists in lisp. There is a proven web server, html generating lib, databings but still no framework FOR THE PRAGMATISTS. I think cl-weblocks has the best shot to become one but we shall see. > > ??>> in other words, you have some "religious" preconceptions about > ??>> different operating systems and Lisp implementations, and you care > ??>> more about following your preconceptions rather than getting things > ??>> done in most effective way. > > SB> That you are wrong I like sbcl and use it with Ubuntu.But if expecting > SB> code to be portable across at least allegro/lw/sbcl and windows/linux > SB> (I don't have access to Mac) is a religion then yes I am religious. > > even religious people have some reasoning behind their beliefs. No faith is pure when it's unquestioned > > but what's your reason to require portability for webapp? 1. I prefer developing on windows and with IDE than on Linux with Emacs/slime 2. I prefer to keep deployment options open 3. I hate lock ins for single implementation and OS 4. Quality of the code is very often correlated with portability, once upon a time I made a patch for weblocks under sbcl/linux, testing it with allegro, lw under both win and linux revealed a lot of low quality and implementation specific code. So same as I test with opera/ safari/mozilla and ie 6/7 I like to test different oses and implementations, and it always proved worthy my time leading to better code and squashing bugs > > unlike desktop application, web applications are typically deployed in > controlled fashion -- people pick a server for application and configure it > according to application demands. > so for people who actually want application up and running portability has > very little value. > and it's quite adequate decision to sacrifice portability for, say, > features, or just cut development time on it. > > it's another question if you're developing tools rather than application > itself -- tools might be required to play with other tools.
|
Pages: 1 Prev: Ready Lisp version 20080428 now available Next: hierarchical data in clips |