Prev: net.html.generator indented code
Next: Hey RACIST and INcompetent FBI/CIA Bustards where is the ANTHRAX MAILER ??? Where are the 4 blackboxes, where are the 5 dancing israelis and what is the status of FORENSIC evidence and trace of NANO THERMITE in WTC dust ?
From: Alessio Stalla on 21 Jul 2010 09:55
On Jul 21, 3:14 pm, Kenneth Tilton <kentil...(a)gmail.com> wrote:
[snip]
>
> > Incidentally, if Firefox users have the "Search for text when I start
> > typing" preference checked, it plays havoc with your interface because
> > Firefox doesn't see it as an editable area and starts capturing
> > keystrokes.
>
> You see that happening? Ah, I limited calling preventDefault to
> backspace for some reason. Putting it back to all keystrokes until I
> remember the reason.
>
> Firefox needs to lose that option, btw.

Too bad you don't control Firefox development... it's the web,
baby! ;)

>
> >> if you noticed a word I have
> >> written. Check out the qooxlisp wiki pages:
>
> >>    http://wiki.github.com/kennytilton/qooxlisp/
>
> > So you are happy about writing in Lisp to generate javascript, good
> > for you. Maybe someone in a Lisp group cares, but the relevant part
> > here is the generated javascript - how it came into being is almost
> > entirely irrelevant.
>
> > Your use of qooxdoo is essentially as crutch to generate the client
> > UI. There are many alternatives, a more popular one is to do the work
> > on the server and send generated HTML to the client. It tends to be
> > much faster and more robust.
>
> It seems fast enough. Robust? qooxdoo is an active and steadily
> advancing library worked on by better web developers than I, how am I
> going to do better work than them?
>
>
>
> >> I know I have to linked to those before, what I do not know is how well
> >> you can read. The idea is to program in one language in one IDE and
> >> almost forget the driven libray (be it Tcl/Tk, GTk, or qooxdoo) even exists.
>
> > That's been tried many, many times before and strangely those IDEs
> > haven't taken over the world. They likely fail for much the same
> > reasons general purpose javascript libraries fail - one is that if you
> > try to please everyone, you end up pleasing no one.
>
> They are doing fine, actually, tho the desktop per se not so much.
>
>
>
> > Their main use seems to be programmers who know one language well but
> > need to write programs in another (in your case, Lisp -> HTML and
> > CSS). However the generated code is not as good as that written in the
> > target language to start with - natural selection takes care of the
> > rest of the story.
>
> Right, and I should be programming in assembler instead of Lisp. Except
> compilers eventually started writing better assembler.
>
>
>
> > All the time and effort you've spend learning qooxdoo might well have
> > been much better spent learning a bit of HTML and CSS - the actual
> > javascript part seems to be minimal.
>
> And later you suggest I rewrite the whole thing in JS.
>
> I am sure I would have done better with Mr. Mark's library than with
> Dojo or anything else other than qooxdoo, but I have done an in-depth
> survey of these things (which usually includes raw HTML/CSS) and I
> actually understand pretty well how much faster I can develop a web app
> using qooxdoo vs raw HTML/CSS.
>

Oh, I think we finally nailed down the problem/misconception. I don't
think anybody is saying that raw HTML/CSS/JavaScript is faster to
develop than qooxdoo; rather that the end result is generally poorer
with qooxdoo than with the "lower-level" approach.

>
> >> That said, I could reduce the size of each round-trip by taking an hour
> >> or two to create some pre-fab qooxdoo classes expressing the boilerplate
> >> I am shipping over, but the thing is so fast now I'll get to that after
> >> I get the "leveling-up thru Algebra" thing going.
>
> > I don't think the amount of data being transmitted is the issue, it's
> > the number of requests. There's a certain overhead that you can never
> > reduce so the speed of the application is limited to the speed of an
> > XHR request, and you have very little control over that.
>
> Sounds like a theoretical objection not supported by experience. I would
> not still be going down this path if performance did not look so good,
> and I have not even focused much on performance yet.
>
>
>
> > 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?

JS is much less of a toy language than most people think (and I'm a
Lisper, too). And you'd not need to port the whole application; just
move to the client stuff that pertains there, like formula editing,
while leaving other stuff on the server (e.g. the problem solving
logic).

> To solve what problem? Remember, this group defines "Using a library" as
> a problem, but only this group.

Not any library, but a certain class of libraries.

Alessio
From: Kenneth Tilton on 21 Jul 2010 10:50
Alessio Stalla wrote:
> Kenny, screw qooxdoo! Lispers have had the Parenscript library - a
> Lisp-to-js compiler - for a long time.

Writing the JS glue hardly calls for Parenscript, and with the glue we
Just Write Lisp. P/s is not all that hot, anyway.

> If it were extended with a
> built-in, XHR-based server callback mechanism and maybe a minimally
> intrusive widget set, it would really rock! It would be a library in
> the vein of GWT, but with much less boilerplate. If only I had the
> time... :(

Now it is time to ask a Lisper: what problem are you trying to solve?
Qooxlisp is the ideal solution for RIAs: a great HLL (Common Lisp) and a
great JS framework.

I'll team up with Mr Mark on a lighter weight Cells/HTML solution for
simpler web pages down the road.

kt

--
http://www.stuckonalgebra.com
"The best Algebra tutorial program I have seen... in a class by itself."
Macworld
From: Alessio Stalla on 21 Jul 2010 11:28
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 :)

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.

Alessio
From: Kenneth Tilton on 21 Jul 2010 12:24
Tim Streater wrote:
> In article
> <f7253284-7fc1-47d8-bca3-b3aeca686ec7(a)k39g2000yqb.googlegroups.com>,
> Alessio Stalla <alessiostalla(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?

Many a Lisper makes the mistake of using macros where functions would
suffice, ie, yes, macros and fucntions both hide details and often a
macro hides no more than could a function hence should be eschewed.

Mr. Graham explains it better than anyone:
http://www.paulgraham.com/onlisp.html


> 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.
>

I did OK with the C preprocessor, I just used a lot of parentheses and
braces and stuff. One great five-day bug, tho.

C macros and Lisp macros have in common the word "macro". Nuff said.

kt

--
http://www.stuckonalgebra.com
"The best Algebra tutorial program I have seen... in a class by itself."
Macworld
From: Matt Kruse on 21 Jul 2010 12:55
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 ;)

For those who still contend with IE6, writing js for webapps is still
a messy proposition, made easier with prudent use of libraries.

Matt Kruse
First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4 5 6
Prev: net.html.generator indented code
Next: Hey RACIST and INcompetent FBI/CIA Bustards where is the ANTHRAX MAILER ??? Where are the 4 blackboxes, where are the 5 dancing israelis and what is the status of FORENSIC evidence and trace of NANO THERMITE in WTC dust ?