From: Kenneth Tilton on
Tim Streater wrote:
> In article <4c471da1$0$5009$607ed4bc(a)cv.net>,
> Kenneth Tilton <kentilton(a)gmail.com> wrote:
>
>> Tim Streater wrote:

>> > I've just finished writing an e-mail client > using JS (13k lines)
>> for the front-end, PHP (7k lines) for the backend. > No JS libraries
>> in sight and my ajax routine is just 20 lines long.
>>
>> Nice. What did the 13k lines translate to in download size?
>
> Well its not all downloaded at once, but 5.7k lines translates to
> 215kbytes.

Yikes. These yobbos will kill me if I port ten times that to JS, which
could be fifty times that by the time all the Lisp macros get expanded.
And my investor (me) will kill me if I spend three months on a port. I
think the math editor better stay in Lisp on the server.

Naysayers in re that need to remember that Algebra students are
generally not entering equations at 60 wpm.

We'll see, but so far it looks like a no-brainer. As I said, I have not
yet begun to optimize.

So are the buttons appearing OK now that each typing example gets loaded
separately? http://teamalgebra.com/

Hmmh, I have to figure out how to give diff tabs their own url. Anyone
here know how to do that with qooxdoo? :)

kt


--
http://www.stuckonalgebra.com
"The best Algebra tutorial program I have seen... in a class by itself."
Macworld
From: David Mark on
On Jul 21, 12:55 pm, Matt Kruse <m...(a)thekrusefamily.com> wrote:
> On Jul 21, 11:22 am, Tim Streater <timstrea...(a)waitrose.com> wrote:
>
> > If you write standard code there *is* no variability, not these days. My
> > app works pretty identically in five browsers (except IE, fortunately I
> > have no access to a copy of that, neither do I want one).
>
> Problems are easier to solve when you ignore the trouble-makers ;)

Users (and their agents) cannot be considered "trouble-makers" by
professionals. You have to play the hand you are dealt. The recent
trend of "not caring" about whatever browsers you can't handle is
ridiculous as end-users don't care what you don't care about.

>
> For those who still contend with IE6, writing js for webapps is still
> a messy proposition,

No it isn't. IE6 is very much like IE7 (and IE8 can mimic IE7 fairly
closely). And as IE6 has been out since the turn of the century,
professional developers should know how to deal with it by now.

> made easier with prudent use of libraries.

Unless you are referring to my library, how backwards can you get?
The "major" libraries are notorious for their failures in IE6, so how
can they possibly help? Why do you think most library authors have
given up on trying to "solve" that browser? They tried for years and
never got close, so now they want to wish it out of existence. :(
From: Alessio Stalla on
On 21 Lug, 17:48, Tim Streater <timstrea...(a)waitrose.com> wrote:
> In article
> <f7253284-7fc1-47d8-bca3-b3aeca686...(a)k39g2000yqb.googlegroups.com>,
>  Alessio Stalla <alessiosta...(a)gmail.com> wrote:
>
>
>
> > On Jul 21, 4:42 pm, Tim Streater <timstrea...(a)waitrose.com> wrote:
> > > In article <4c46f2e3$0$31286$607ed...(a)cv.net>,
> > >  Kenneth Tilton <kentil...(a)gmail.com> wrote:
>
> > > > RobG wrote:
> > > > > The fix for that is to run your algebra program on the client. If you
> > > > > care to rewrite it in javascript, it may be of interest.
>
> > > > You want me to port 80kloc of a high-level language like Lisp to a toy
> > > > language like JS? How big will the client be then? And how many motnhs
> > > > would that take?
>
> > > Now now, no need to sneer. I've just finished writing an e-mail client
> > > using JS (13k lines) for the front-end, PHP (7k lines) for the backend.
> > > No JS libraries in sight and my ajax routine is just 20 lines long.
>
> > > I looked at Lisp in 1968 and decided I didn't like it - it didn't appear
> > > to relate to anything.
>
> > Kenny was very wrong in calling JS a toy language, but you're also
> > wrong if you consider Lisp today as it was in 1968. It would be like
> > comparing Ruby with Pascal :)
>
> Oh quite possibly. But then I didn't like Pascal with its SESE model
> either.
>
>
>
> > Lisp generating JS could bring very high-level constructs to JS
> > without the need of a huge library like qooxdoo. For example, you
> > could use macros to define functions which automagically invoke remote
> > services with XHR, without coding them by hand.
>
> > (defun-remote foo (args))
>
> > function foo(args, callback) {
> >    ... xhr(args, callback) ...
> > }
>
> > (defun bar ()
> >   (do-stuff)
> >   (foo 1 2 3)
> >   (do-other-stuff))
>
> > function bar() {
> >   doStuff();
> >   foo(1, 2, 3, function() { doOtherStuff(); });
> > }
>
> > you can get the idea.
>
> Hmmm I must be missing something. Isn't this what functions are supposed
> to be for?

Macros are about source code transformations at compile-time. You
can't do that with functions.
In the fictional example I posted, a piece of code like:

doStuff();
callSomeFunctionOnTheServer(1, 2, 3);
doOtherStuff();

got translated to:

doStuff();
callSomeFunctionOnTheServer(1, 2, 3, function() { doOtherStuff(); });

i.e. from plain imperative style to asynch XHR callback-driven style.
Only a macro can do that.

> And I'm not keen on macros (except when using assembler - see
> Metasym). After I discovered that C macros knew nothing about C, I stuck
> to using the C preprocessor for simple substitutions of the:
>
> #define wiggy 3
>
> variety.

Lisp macros know Lisp, and are written in Lisp. C macros are little
more than text substitutions.

Alessio
From: Alessio Stalla on
On 21 Lug, 21:47, Tim Streater <timstrea...(a)waitrose.com> wrote:
> In article
> <67d9e6e5-0640-437a-ada3-26598707c...(a)c10g2000yqi.googlegroups.com>,
>  Alessio Stalla <alessiosta...(a)gmail.com> wrote:
>
> > > Hmmm I must be missing something. Isn't this what functions are supposed
> > > to be for?
>
> > Macros are about source code transformations at compile-time.
>
> I'm really not sure I want to do that.

As Kenny said, Lispers sometimes want *too much* to do that ;)

> > You can't do that with functions.
> > In the fictional example I posted, a piece of code like:
>
> > doStuff();
> > callSomeFunctionOnTheServer(1, 2, 3);
> > doOtherStuff();
>
> > got translated to:
>
> > doStuff();
> > callSomeFunctionOnTheServer(1, 2, 3, function() { doOtherStuff(); });
>
> In my JS, a call to my 20-line ajax function looks like:
>
> ajax ("some-script.php", data-string-for-script, someCallbackFunction);
>
> arg 1 is a PHP script to do some work for my app and return results
> arg 2 is an argument string of values for the script in the form:
> arg1=value&arg2=value
> arg3 is a JS function that will be given the script's results later and
> will process them.
>
> So I'm already doing that in JS.

You're doing it manually. You could program the compiler to translate
imperative code to callback-driven code, making it appear as if XHR
calls were regular synchronous function calls when they're really not.
E.g.

withSynchrXHR {
stuff();
ajax(...);
moreStuff();
ajax(...);
evenMoreStuff();
}

gets translated to

ajax(..., function() {
moreStuff();
ajax(..., function() {
evenMoreStuff(); });
});

just a rough sketch, not taking into account return values, error
conditions, ...

> Hmmm, perhaps a different fictional example might show the point better.

Another, simpler example, again in JS syntax rather than Lisp syntax:

ajaxFunction foo(args) { code }

translated to

function foo(phpScript, args) {
ajax(phpScript, args, function() { code });
}

and macros for defining classes if you want to turn JavaScript into a
class-based OO language, macros for representing DOM subtrees
literally in source code, there are many examples.

Cheers,
Alessio
From: Matt Kruse on
On Jul 21, 12:55 pm, David Mark <dmark.cins...(a)gmail.com> wrote:
> > made easier with prudent use of libraries.
> Unless you are referring to my library, how backwards can you get?
> The "major" libraries are notorious for their failures in IE6, so how
> can they possibly help?

All these years, and you still haven't grasped the simple point...

A library may work well in IE6 for, let's say, 80% of problems that
the library may try to solve. It may work only partially on 15%, and
fail miserably on the remaining 5%.

Take advantage of the 80% of features that work just fine, and use the
library. Don't try to use the library on the remaining 20% of features
that they have coded incorrectly or that, for whatever reason, don't
work.

Any reasonable person would understand that strategy, IMO. Because we
do it all the time with other things. Almost no tool gets everything
right. Successful people know how to identify which parts of which
tools should be used, and then use them. Not throw them out because
they fail to solve 100% of all conceivable problems that they may
encounter.

Matt Kruse