Some entity, AKA Tim Bradshaw <t...@tfeb.org>, wrote this mindboggling stuff: (selectively-snipped-or-not-p)
> On 2010-09-02 17:31:36 +0100, Kenneth Tilton said:
>> The good news is they have gone green and all been converted to >> solar power. The bad news is they can no longer get off the ground.
> When will they learn that the only kind of power that's interesting is nuclear?
Why do you bother? If nuclear is merely your answer I really want my Radom hunter back before you try to C-x C-e on your nuclear solution.
Cor
-- Geavanceerde politieke correctheid is niet te onderscheiden van sarcasme If you hate to see my gun, consider a non criminal line of work The only good message from a spammer is a obituary I really do not give a damn about ANY mail
Cor Gest <c...@clsnet.nl> writes: > Some entity, AKA Tim Bradshaw <t...@tfeb.org>, > wrote this mindboggling stuff: > (selectively-snipped-or-not-p)
>> On 2010-09-02 17:31:36 +0100, Kenneth Tilton said:
>>> The good news is they have gone green and all been converted to >>> solar power. The bad news is they can no longer get off the ground.
>> When will they learn that the only kind of power that's interesting is nuclear?
> Why do you bother? > If nuclear is merely your answer I really want my Radom hunter back > before you try to C-x C-e on your nuclear solution.
You must realize that all the negative items you learned about nuclear power (thru "greens"), is disinformation that was propagated by the KGB to destroy occident. What's worse is that it keeps propagating now that the KGB has been out for 20 years...
Real ecologists (not the leftist ideologists) are for nuclear power, which is the safest and cleanest energy source available today and for the foreseable future.
??>> Last time I've checked, it was sub-standard, ??>> quick-and-dirty-and-barely working kind of webapp. Can you address ??>> criticism?
TB> Nice to see peopls being really positive about stuff being TB> done in Lisp, eh?
You're implying that everybody should sing praises just because it is done in Lisp. This is silly, sorry.
There are other stuff which is not as fucked up as Kenny's. And Kenny is clearly advertising his framework. When I say that I don't like his framework I'm at same propping up other frameworks. (It is the difference which matters.) So I don't see how you can consider anti-qooxlisp being same as anti-Lisp. If anything, it promotes healthy competition.
Now if Kenny can address issues I've mentioned (or, at least, mitigate them) it will make qooxlisp a stronger competitor. So it isn't even bad for qooxlisp.
Did you try to use this teamalgebra thing? I actually went to that site and started clicking around. I made a list with about a dozen of issues about qooxlisp's look&feel and I don't think people would want to use it until at least some of them are addressed. (Unless they want to be ridiculed.)
TB> Nice to see peopls being really positive about stuff being done in TB> Lisp, eh?
Just to show how positive I am I would mention parenscript. This is a right way to do it -- a compiler which compiles a lisp dialect to parenscript, so you can write code for the browser in lisp.
Moving everything to server like in qooxlisp is CL-centric escapism.
It is not just a subjective preference -- it is provable that 100% server-side solutions are inferior from user's perspective because they appear to be slow.
It is interesting that speed of light is the limiting factor. If you're in Europe and you open SSH connection to server in California you'll see that it is definitely not as responsive as server sitting in next room. You can literaly feel that response is slower.
Of course web application will always need to pull data from server side and some delays are inevitable. But if you need to pull data on each fraking click it is fraking retarded.
A solution is to do stuff on browser side. We cannot run CL code on browser side and pure JavaScript isn't particularly pleasant language to write code it. Hence the only solution is compiler which compiles something (Lisp-like) to JavaScript to run in browser.
Parenscript is exactly that, it is already usable. But it is a bit low-level -- it just addresses JavaScript generation problem. Now I think we need better high-level libraries on top of Parenscript -- so you have objects, widgets and stuff. I don't know any good ones. I've participated in one effort but it didn't go very well. But that doesn't mean it cannot be done.
Some entity, AKA p...@informatimago.com (Pascal J. Bourguignon), wrote this mindboggling stuff: (selectively-snipped-or-not-p)
>>>> The good news is they have gone green and all been converted to >>>> solar power. The bad news is they can no longer get off the ground.
>>> When will they learn that the only kind of power that's interesting is nuclear?
>> Why do you bother? >> If nuclear is merely your answer I really want my Radom hunter back >> before you try to C-x C-e on your nuclear solution. > Real ecologists (not the leftist ideologists) are for nuclear power, > which is the safest and cleanest energy source available today and for > the foreseable future.
I really could not care less about lefties, greens or veggies, for I like my greens lightly cooked and the fourlegged vegetarians medium-rare.
Oh, and for nuke-power, we buy it very cheap by the bucket from the french anyway.;-)
Cor
-- Geavanceerde politieke correctheid is niet te onderscheiden van sarcasme If you hate to see my gun, consider a non criminal line of work The only good message from a spammer is it's obituary I really do not give a damn about ANY mail
On 2010-09-03 11:39:11 +0100, Captain Obvious said:
> Did you try to use this teamalgebra thing? I actually went to that site > and started clicking around.
Yes. I didn't make an account but it looks like you can type maths at it and it's pretty good at that. I've not seen any other systems that let you type reasonable-looking algebraic stuff via a web GUI that are anything like as good. (I disagree with some of the decisions it's made like "c2" turning into c^2, but that's probably right for his target audience, who aren't me, of course).
> On 2010-09-03 11:39:11 +0100, Captain Obvious said:
>> Did you try to use this teamalgebra thing? I actually went to that >> site and started clicking around.
...with the mindset of someone who hates the author which I have learned is fantastic for testing a system so post those bug reports and have someone not in my killfile quote them. Feel free to include your negative opinions on things not bugs, I'll just ignore those. Any positive observations... PWUAHAHAHAHAHHAHHAHAHA!
> Yes. I didn't make an account ...
do what I do: pick two letters like qw and go qw tab qw tab qw tab until you get to the license terms and hit enter tab enter.
Yer in! You can now transfer billions freely.
> ...but it looks like you can type maths at it > and it's pretty good at that. I've not seen any other systems that let > you type reasonable-looking algebraic stuff via a web GUI that are > anything like as good. (I disagree with some of the decisions it's made > like "c2" turning into c^2, but that's probably right for his target > audience, who aren't me, of course).
Note that you are perfectly free to type c then ^ then 2 and then right-arrow to get c-squared the classic way.
On Sep 3, 12:01 pm, "Captain Obvious" <udode...@users.sourceforge.net> wrote:
> TB> Nice to see peopls being really positive about stuff being done in > TB> Lisp, eh?
> Just to show how positive I am I would mention parenscript. > This is a right way to do it -- a compiler which compiles a lisp dialect to > parenscript, so you can write code for the browser in lisp.
But if you've already got a working application, and want to quickly port it to the web, that approach means re-writing your app in the subset of lisp that parenscript can compile down to javascript.
> Moving everything to server like in qooxlisp is CL-centric escapism.
So is compiling Lisp down to java-bytecode but thank god someone just went ahead and did it anyway. This is c.l.l for crying out loud! If you can't indulge in a little CL-centric escapism here, then where can you?
> It is not just a subjective preference -- it is provable that 100% > server-side solutions are inferior from user's perspective because they > appear to be slow.
Even accepting the "proven" fact that 100% server-side solutions are inferior, qooxlisp isn't 100% server-side. It generates javascript objects and handlers (and automatically sends them to the browser in the correct order) that issue callbacks to the server when certain events happen. But callbacks are only issued when you register a handler for a given event on a given object. If you don't need to listen for every mouse move, you just don't register a handler for it.
> Of course web application will always need to pull data from server side and > some delays are inevitable. > But if you need to pull data on each fraking click it is fraking retarded.
qooxlisp does not mandate this
> Parenscript is exactly that, it is already usable. But it is a bit > low-level -- it just addresses JavaScript generation problem.
This is roughly the same problem that qooxlisp attempts to address. Whereas parenscript translates functions and simple classes to javascript, qooxlisp maps an object graph on the server to an equivalent object graph on the client. __qooxdoo__ (i.e. an actual javascript framework) has all the gui widgets, DOM manipulation, event triggering etc. __qooxlisp__ just lets you program those in lisp. Parenscript could be used to help define the javascript that gets sent across but in truth, it's just not complicated enough to warrant it.
> On Sep 3, 12:01 pm, "Captain Obvious"<udode...@users.sourceforge.net> > wrote: >> TB> Nice to see peopls being really positive about stuff being done in >> TB> Lisp, eh?
>> Just to show how positive I am I would mention parenscript. >> This is a right way to do it -- a compiler which compiles a lisp dialect to >> parenscript, so you can write code for the browser in lisp.
> But if you've already got a working application, and want to quickly > port it to the web,...
Right. There is/was a business constraint: (a) get to market fast (b) without dying of boredom from rewriting the whole thing a fifth time (in a godawful language for serious development).
September is here and today a teacher is making this site an optional Friday activity: http://teamalgebra.com/#
> subset of lisp that parenscript can compile down to javascript.
>> Moving everything to server like in qooxlisp is CL-centric escapism.
> So is compiling Lisp down to java-bytecode but thank god someone just > went ahead and did it anyway. This is c.l.l for crying out loud! If > you can't indulge in a little CL-centric escapism here, then where can > you?
>> It is not just a subjective preference -- it is provable that 100% >> server-side solutions are inferior from user's perspective because they >> appear to be slow.
> Even accepting the "proven" fact that 100% server-side solutions are > inferior, qooxlisp isn't 100% server-side. It generates javascript > objects and handlers (and automatically sends them to the browser in > the correct order) that issue callbacks to the server when certain > events happen.
Yep, a ton of widget geometry and handling is all on the client, as is jsMath (which itself memoizes expressions so it does not need to convert to HTML from scratch all the time).
> But callbacks are only issued when you register a > handler for a given event on a given object. If you don't need to > listen for every mouse move, you just don't register a handler for it.
>> Of course web application will always need to pull data from server side and >> some delays are inevitable. >> But if you need to pull data on each fraking click it is fraking retarded.
> qooxlisp does not mandate this
Right, One can write as much JS as one wants the old-fashioned way and then not make the round-trip. Clearly a candidate for that would be the math editor, but that is a lot of Lisp to port to JS.
What I will prolly do as a form of early but not too early optimization is take the ~fifteen-line chunks of JS returned and convert those to pre-defined functions. Not sure that is a factor (ie, is anything under 1K all the same in NetLand?) but it's a no-brainer.
>> Parenscript is exactly that, it is already usable. But it is a bit >> low-level -- it just addresses JavaScript generation problem.
> This is roughly the same problem that qooxlisp attempts to address. > Whereas parenscript translates functions and simple classes to > javascript, qooxlisp maps an object graph on the server to an > equivalent object graph on the client. __qooxdoo__ (i.e. an actual > javascript framework) has all the gui widgets, DOM manipulation, event > triggering etc. __qooxlisp__ just lets you program those in lisp. > Parenscript could be used to help define the javascript that gets sent > across but in truth, it's just not complicated enough to warrant it.
Nope. JS is not that hard, and the code one writes for glue is not the kind of code one writes for applications. Proof left as an exercise, proof satisfactory to someone who does not program applications left as an optional Friday activity in Hell.
??>> Just to show how positive I am I would mention parenscript. ??>> This is a right way to do it -- a compiler which compiles a lisp ??>> dialect to parenscript, so you can write code for the browser in lisp.
AC> But if you've already got a working application, and want to quickly AC> port it to the web, that approach means re-writing your app in the AC> subset of lisp that parenscript can compile down to javascript.
Emm... Usually application consists of model (or business logic) part and user interface (or presentation) part. If you're porting it to the web you want to keep model/business logic but new write web UI, right?
Presumable you can keep your model/bussiness logic at server side and write GUI using HTML/CSS/JS with help of Parenscript. Then you can bridge them with help of remote procedure calls.
With qooxlisp you still need to write UI code, so I don't see how it is better.
??>> Moving everything to server like in qooxlisp is CL-centric escapism.
AC> So is compiling Lisp down to java-bytecode but thank god someone just AC> went ahead and did it anyway.
It is a totally different thing.
AC> This is c.l.l for crying out loud! If you can't indulge in a little AC> CL-centric escapism here, then where can you?
I have nothing against indulging that CL-centric escapism, but Kenny advertises his new framework as the best and only. I just want to check if it works as advertised, that's all.
AC> Even accepting the "proven" fact that 100% server-side solutions are AC> inferior, qooxlisp isn't 100% server-side.
The question is where controlling logic resides.
AC> It generates javascript objects and handlers (and automatically sends AC> them to the browser in the correct order) that issue callbacks to the AC> server when certain events happen. But callbacks are only issued when AC> you register a handler for a given event on a given object. If you AC> don't need to listen for every mouse move, you just don't register a AC> handler for it.
The question is -- can it do at least something without calling server?
I'm judging qooxlisp by its flagship application (as far as I understand) -- Kenny's teamalgebra. It looks like it needs to consult the server on every move and that's why everything is slow as molasses.
Is it possible to write fast, normal applications with it? Are there examples?
I was asking Kenny but he have killfiled me somewhere in the middle of conversation so I did not had a chance to learn.
??>> Parenscript is exactly that, it is already usable. But it is a bit ??>> low-level -- it just addresses JavaScript generation problem.
AC> This is roughly the same problem that qooxlisp attempts to address. AC> Whereas parenscript translates functions and simple classes to AC> javascript, qooxlisp maps an object graph on the server to an AC> equivalent object graph on the client. __qooxdoo__ (i.e. an actual AC> javascript framework) has all the gui widgets, DOM manipulation, event AC> triggering etc. __qooxlisp__ just lets you program those in lisp. AC> Parenscript could be used to help define the javascript that gets sent AC> across but in truth, it's just not complicated enough to warrant it.
I don't quite get -- can you implement pieces of logic which are client-side with qooxlisp?
KT> Feel free to include your negative opinions on things not bugs, I'll KT> just ignore those.
Sure, why would you listen to feedback on your framework you're trying to advertise so hard...
??>> ...but it looks like you can type maths at it ??>> and it's pretty good at that. I've not seen any other systems that let ??>> you type reasonable-looking algebraic stuff via a web GUI that are ??>> anything like as good.
I haven't found this impressive because my co-worker have made a system like that in pure JS something like 4 years ago. It was called Expressionism, web site www.mathdonalds.com -- it is dead now, but still there are some references to it.
I'm only interested in general purpose web UI framework.
On Fri, 3 Sep 2010 14:01:01 +0300, "Captain Obvious"
<udode...@users.sourceforge.net> wrote: >It is interesting that speed of light is the limiting factor. If you're in >Europe and you open SSH connection to server in California you'll see that >it is definitely not as responsive as server sitting in next room. >You can literaly feel that response is slower.
It's not "speed of light" but speed of server(s), Internet connections and relays and your browser.
The speed of light in single mode fiber is roughly 9/10 the speed of light in a vacuum - the round trip from Prague to Los Angeles and back is about 70ms - just a little more than the average human visual perceptual threshold. (I chose Prague because it is more or less centrally located in the EU.)
Assuming fiber actually could be strung straight from Kenny's server to your computer, and assuming gigabit or better connections at both ends, it's likely that the entire website could have been transferred in the blink of an eye.
> The speed of light in single mode fiber is roughly 9/10 the speed of > light in a vacuum - the round trip from Prague to Los Angeles and back > is about 70ms - just a little more than the average human visual > perceptual threshold. (I chose Prague because it is more or less > centrally located in the EU.)
Which is why one should avoid satellite internet service if one is concerned with such things, as every round trip can involve going out to geostationary orbital altitude and back (i.e., about 44,000 miles round trip), which, even at light speed, is about a quarter second, and as a practical matter, adds about a half second per round trip, which is quite perceptible.
Maybe some of the people who find kenny's algebra tutor unbearably slow have satellite internet service?
GN> It's not "speed of light" but speed of server(s), Internet connections GN> and relays and your browser.
GN> The speed of light in single mode fiber is roughly 9/10 the speed of GN> light in a vacuum - the round trip from Prague to Los Angeles and back GN> is about 70ms
Worst case is "earth cirumference / (0.9 speed of light)". It is 150 ms roundtrip. Realistically, you'll never have straight line from your home to the server -- path will be worse than the straight path.
Now let's do an experiment:
3 10gigabitethernet2-1.core1.fmt1.he.net (64.71.129.69) 0.000 ms 0.000 ms 0.000 ms 4 10gigabitethernet1-1.core1.pao1.he.net (66.160.158.242) 8.000 ms 8.000 ms 8.000 ms 5 10gigabitethernet2-4.core1.ash1.he.net (72.52.92.30) 112.000 ms 10gigabitethernet1-1.core1.lax1.he.net (72.52.92.22) 8.000 ms 8.000 ms 6 10gigabitethernet4-3.core1.nyc4.he.net (72.52.92.225) 108.000 ms 104.000 ms 140.000 ms 7 10gigabitethernet1-2.core1.lon1.he.net (72.52.92.78) 148.000 ms 148.000 ms 148.000 ms 8 10gigabitethernet1-1.core1.par1.he.net (72.52.92.34) 156.000 ms 156.000 ms 152.000 ms 9 10gigabitethernet1-2.core1.fra1.he.net (72.52.92.90) 168.000 ms 168.000 ms 168.000 ms
As you see it is all inside hurricane electric's network, so I doubt it gets better than that. (Note that there is very little variation... I think you know what this means.)
GN> - just a little more than the average human visual perceptual GN> threshold.
It is actually closer to 200 ms and, believe me, it is very perceptible. Try SSH connection and you'll see yourself. I do this routinely and I can tell you how far is the server just after typing few commands. Round trip time of 70 ms is percieved as almost ok, 150 ms -- quite annoying, 200+ ms -- annoying as hell. (Ok, there are many varieties of hell, I've seen cases when packets need many seconds to travel because network is saturated... But you never work interactively in such conditions -- you prepare command beforehand and then type blindly.)
Also people who play 3D multiplayer shooters (Counter Strike, Quake, Half Life) will tell you that rountrip time of <20 ms is ok, 50 ms -- sucks, 100 ms -- unplayable. Hence nobody plays across the Atlantic ocean.
GN> Assuming fiber actually could be strung straight from Kenny's server GN> to your computer, and assuming gigabit or better connections at both GN> ends, it's likely that the entire website could have been transferred GN> in the blink of an eye.
Unfortunately there are many roundtrip requests so bandwidth is pretty irrelevant. Say I have 150 ms roundtrip to teamalgebra.com server. If it needs 10 roundtrips to do something that would be 1.5 seconds.
"Captain Obvious" <udode...@users.sourceforge.net> writes: > GN> It's not "speed of light" but speed of server(s), Internet connections > GN> and relays and your browser.
> GN> The speed of light in single mode fiber is roughly 9/10 the speed of > GN> light in a vacuum - the round trip from Prague to Los Angeles and back > GN> is about 70ms
> Worst case is "earth cirumference / (0.9 speed of light)". > It is 150 ms roundtrip.
No. The worst case is when you go thru a geostationnary satellite, which is 36e6 m above surface, and therefore between 36e6 m and 42e6 m from the ground stations.
Usually, satellites are positionned so that they cover 1/3 of the Earth circumference (it would be hard to communicate with them if they were right on the horizon), so the distance between the two base stations thru the geostationnary satellite can be in the worst case:
(round (* 2 (+ 36e6 (* 6.3e6 (- 1 (cos (/ pi 3))))))) --> 78300000 m
which corresponds approximately to:
(round (/ 78300000 3e8) 0.001) --> 261 ms
The minimum ping time (ie. network round trip time) would be of course twice that value, ie. 522 ms.
Plus of course, the time spent in the routers and the sattelite, and the time needed to go via optical fiber and ASDL between the base stations and your home, if you don't have your own satellite link.
<udode...@users.sourceforge.net> wrote: > GN> It's not "speed of light" but speed of server(s), Internet connections > GN> and relays and your browser.
> GN> The speed of light in single mode fiber is roughly 9/10 the speed of > GN> light in a vacuum - the round trip from Prague to Los Angeles and back > GN> is about 70ms
>Worst case is "earth cirumference / (0.9 speed of light)". >It is 150 ms roundtrip. >Realistically, you'll never have straight line from your home to the >server -- path will be worse than the straight path.
>Now let's do an experiment:
> 3 10gigabitethernet2-1.core1.fmt1.he.net (64.71.129.69) 0.000 ms 0.000 >ms 0.000 ms > 4 10gigabitethernet1-1.core1.pao1.he.net (66.160.158.242) 8.000 ms 8.000 >ms 8.000 ms > 5 10gigabitethernet2-4.core1.ash1.he.net (72.52.92.30) 112.000 ms > 10gigabitethernet1-1.core1.lax1.he.net (72.52.92.22) 8.000 ms 8.000 >ms > 6 10gigabitethernet4-3.core1.nyc4.he.net (72.52.92.225) 108.000 ms >104.000 ms 140.000 ms > 7 10gigabitethernet1-2.core1.lon1.he.net (72.52.92.78) 148.000 ms >148.000 ms 148.000 ms > 8 10gigabitethernet1-1.core1.par1.he.net (72.52.92.34) 156.000 ms >156.000 ms 152.000 ms > 9 10gigabitethernet1-2.core1.fra1.he.net (72.52.92.90) 168.000 ms >168.000 ms 168.000 ms
>As you see it is all inside hurricane electric's network, so I doubt it gets >better than that. >(Note that there is very little variation... I think you know what this >means.)
> GN> - just a little more than the average human visual perceptual > GN> threshold.
>It is actually closer to 200 ms and, believe me, it is very perceptible. >Try SSH connection and you'll see yourself. >I do this routinely and I can tell you how far is the server just after >typing few commands. >Round trip time of 70 ms is percieved as almost ok, 150 ms -- quite >annoying, 200+ ms -- annoying as hell. >(Ok, there are many varieties of hell, I've seen cases when packets need >many seconds to travel because network is saturated... But you never work >interactively in such conditions -- you prepare command beforehand and then >type blindly.)
>Also people who play 3D multiplayer shooters (Counter Strike, Quake, Half >Life) will tell you that rountrip time of <20 ms is ok, 50 ms -- sucks, 100 >ms -- unplayable. Hence nobody plays across the Atlantic ocean.
> GN> Assuming fiber actually could be strung straight from Kenny's server > GN> to your computer, and assuming gigabit or better connections at both > GN> ends, it's likely that the entire website could have been transferred > GN> in the blink of an eye.
>Unfortunately there are many roundtrip requests so bandwidth is pretty >irrelevant. >Say I have 150 ms roundtrip to teamalgebra.com server. If it needs 10 >roundtrips to do something that would be 1.5 seconds.
I don't disagree with any of this ... but you started by complaining about the speed of light, not the number of HTTP requests or the performance of servers or the bandwidth of internet relays. Now you're changing your arguments.
> From: "Captain Obvious" <udode...@users.sourceforge.net> > ... it is provable that 100% server-side solutions are inferior > from user's perspective because they appear to be slow.
Server-side solutions have these advantages: - They can be made to work on *all* Web browsers, even lynx and $20 cell-phones. - All the software remains under physical control of the programmer, hence can't be stolen and re-sold. - If there's a bug in the running of the application itself, it can be fixed once and for all, rather than bugs in client-side software needing to be written differently for each platform, some of which the programmer doesn't even have available to test fixes.
> A solution is to do stuff on browser side. We cannot run CL code > on browser side and pure JavaScript isn't particularly pleasant > language to write code it. Hence the only solution is compiler > which compiles something (Lisp-like) to JavaScript to run in > browser.
JavaScript isn't even available in lynx, and I don't think it's available in my cell-phone either, so that's not a solution at all.
Also, even where JavaScript is available, it's dangerous to enable it, thus be vulnerable to malware automatically installed from some random Web site you happen to be browsing.
If you are willing to give up the 1-billion market of cell-phones in the world, go ahead if you want, but if your JavaScript-only market is much smaller than mine, "I told you so".
P.S. My current opinion is that PHP with MySQL is the best language for me to implement server-side applications, but some tasks are too slow in PHP so using back-tick commands to invoke utilities written in C or Lisp are virtually necessary. (Currently I use a utility written in C to crop/resample images to fit cell-phones, and a utility written in Lisp to perform modular powers for the private end of public-key encryption.)
> From: Andy Chambers <achambers.h...@gmail.com> > But if you've already got a working application, and want to > quickly port it to the web, that approach means re-writing your app > in the subset of lisp that parenscript can compile down to > javascript.
But actually just re-organizing the main command loop to be a sequence of client-server interactions rather than a stdio loop, or likewise converting your event-driven GUI to be a sequence of client-server interactions and all your dialogs to be HTML instead of GUI widgets, is a considerable amount of work too.
But I agree that at least your "business logic" doesn't need to be translated, so I mostly agree with your main point.
In 1995-1999 I had a Macintosh Allegro Common Lisp application (teaching reading and spelling) which made heavy use of GUI events. I did successfully refactor all the events to be HTML/CGI transactions instead, except the sound generation to signal correct or wrong answers to questions, yielding a working Web application. Eventually I might translate it to PHP/MySQL so that I can run it on free hosting services, as part of http://TinyURL.Com/NewEco.
??>> ... it is provable that 100% server-side solutions are inferior ??>> from user's perspective because they appear to be slow.
RMh> Server-side solutions have these advantages: RMh> - They can be made to work on *all* Web browsers, even lynx and $20 RMh> cell-phones.
HTML-based -- yes. But Kenny's qooxlisp is JavaScript based, with logic residing on the server side. Kinda twisted combo.
RMh> - All the software remains under physical control of the RMh> programmer, hence can't be stolen and re-sold.
Another solution is to move only presentation to client side so it is not a huge problem -- business logic can be still on server only.
RMh> - If there's a bug in the running of the application itself, it can RMh> be fixed once and for all, rather than bugs in client-side RMh> software needing to be written differently for each platform, RMh> some of which the programmer doesn't even have available to test RMh> fixes.
Even if your clientside is pure HTML, you still have to test it...
RMh> Also, even where JavaScript is available, it's dangerous to enable RMh> it, thus be vulnerable to malware automatically installed from some RMh> random Web site you happen to be browsing.
Only if there is a bug in browser. But there are bugs in browser even if you disable JS...
RMh> P.S. My current opinion is that PHP with MySQL is the best language RMh> for me to implement server-side applications,
Why not Common Lisp?
Well, I understand the argument that it is easier to find cheap hosting for PHP+MySQL, but cheapest is not always the best. And CL-friendly hosting is not that expensive -- $20/mo for 512MB Linode VPS, $10/mo for prgmr.com VPS.
