ITA, move over!
Kenneth Tilton
If you are wondering why this software is so great, I explained it here:
http://www.stuckonalgebra.com/advantages.html
Hey, Google! Over here!
:)
kt
--
http://www.stuckonalgebra.com
"The best Algebra tutorial program I have seen... in a class by itself."
Macworld
Captain Obvious
here:
KT> http://www.stuckonalgebra.com/advantages.html
Last time I've checked, it was sub-standard, quick-and-dirty-and-barely
working kind of webapp.
Can you address criticism?
Or do you think that look&feel are totally irrelevant and you can throw any
sort of crap at people if it works for you?
Tim Bradshaw
> Last time I've checked, it was sub-standard, quick-and-dirty-and-barely
> working kind of webapp.
> Can you address criticism?
Nice to see peopls being really positive about stuff being done in Lisp, eh?
Kenny: do we still have budget for the helicopters, or did we burn it
all bailing out some useless bank?
Kenneth Tilton
> On 2010-09-02 15:18:21 +0100, Captain Obvious said:
>
>> Last time I've checked, it was sub-standard,
>> quick-and-dirty-and-barely working kind of webapp.
>> Can you address criticism?
Did he mean "Can I handle criticism?"? He's in my killfile so I lack the
context.
This is the only kind of criticism I can handle:
http://www.stuckonalgebra.com/fan_mail.html
>
> Nice to see peopls being really positive about stuff being done in Lisp,
> eh?
>
> Kenny: do we still have budget for the helicopters, or did we burn it
> all bailing out some useless bank?
>
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.
Tim Bradshaw
> 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?
Cor Gest
wrote this mindboggling stuff:
(selectively-snipped-or-not-p)
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
Pascal J. Bourguignon
> 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.
--
__Pascal Bourguignon__ http://www.informatimago.com/
Captain Obvious
??>> 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.)
Captain Obvious
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.
Cor Gest
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
Tim Bradshaw
> 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).
Kenneth Tilton
> 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.
cheers, kenneth
Andy Chambers
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.
--
Andy
Kenneth Tilton
> 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
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/#
I am headed to NYC to do this: http://thelaughingstockatpngs.com/
QfED.
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.
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.
Captain Obvious
??>> 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?
Captain Obvious
??>>> site and started clicking around.
KT> ...with the mindset of someone who hates the author
Why would I hate you?
You were just advertising qooxlisp as the best lisp framework ever, so I
gave it a test, judging it by teamalgebra.com site.
KT> which I have learned is fantastic for testing a system
I did not test the system, for the record. I do not really care about
algebra, only about qooxlisp as a web GUI framework.
KT> so post those bug reports and have someone not in my killfile quote
KT> them.
http://groups.google.com/group/comp.lang.lisp/msg/847eaf36ea5085cd
You know what, I'll even mail it you you.
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.
Tim Bradshaw
> 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.
It was laziness not privacy that stopped me (need to write the details
somewhere, blah).
> Note that you are perfectly free to type c then ^ then 2 and then
> right-arrow to get c-squared the classic way.
Cool. Also note that I was not actually complaining, since your
audience is unlikely to be people who have TeX wired into their fingers.
George Neuner
<udod...@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.
George
Raffael Cavallaro
> 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?
warmest regards,
Ralph
--
Raffael Cavallaro
Captain Obvious
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.
Pascal J. Bourguignon
> 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.
George Neuner
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.
George
Robert Maas, http://tinyurl.com/uh3t
> ... 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.)
Robert Maas, http://tinyurl.com/uh3t
> 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.
Captain Obvious
??>> 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.
Kenneth Tilton
>> 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.
Nope, because the event-handling before is the event-handling now, and
client-server does not have anything to do with even-handling per se.
What the client-server code does is simply glue events in the client
whether it be HTML, qooxdoo, LTk, or Gtk to event-handlers in my lisp
code running on the server. And I mean "simply". URLs for "callback"
include an "opcode" parameter which might be "onkeydown" and that just
gets funcalled on the Lisp object associated with parameter "oid" in the
session associated with "sessionID".
So with just thirty lines of JS I am handling qooxdoo events with Lisp
handlers as if the Web were not there. qooxdoo adds to that illusion aka
reality by making html/css optional (by generating it all from qooxdoo
objects and properties).
Captain Obvious
GN> about the speed of light, not the number of HTTP requests or the
GN> performance of servers or the bandwidth of internet relays. Now
GN> you're changing your arguments.
No, there are just two of them.
My primary argument is that if application processes GUI events on server,
then roundtrip time of 200+ ms means that application will appear noticeably
slow.
Not to the point when one cannot use it, but it can be percieved as slightly
annoying and irritating.
There will be 200+ ms latency if application in ideal case -- when
processing event requires just one roundtrip.
But particular site might require more than one rountrips (and it is the
case with teamalgebra.com), and so this problem is even more pronounced.
Captain Obvious
KT> Right, One can write as much JS as one wants the old-fashioned way and
KT> then not make the round-trip. Clearly a candidate for that would be the
KT> math editor, but that is a lot of Lisp to port to JS.
So your qooxlisp is all about making fast and sucky version first, and then
painfully rewriting pieces in JS.
Instead of writing things in Parenscript from scratch -- a Lispy language
with full support for metaprogramming and macros -- and not having to deal
with JS at all.