ANNC: qooxlisp 0.1: qooxdoo + Common Lisp

classic Classic list List threaded Threaded
33 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Re: ANNC: qooxlisp 0.1: qooxdoo + Common Lisp

Kenneth Tilton
I guess I won't bore everyone with my application justification after
all, because first we have...

 >> Besides, you only
>> have to drive the UI from it.

Oh, nothing much going on in the GUI? Lucky you. Then we have...

>> A different approach, which IMO allows for faster, less resource hungry applications, is to have the entire UI logic in Javascript

"Entire UI logic"? What happened to "just the GUI"? Anyway, then we have...

>> First, you only have to keep very slim session info on the server.

Cool, nothing going on on the server, either, it's all client-agnostic
lookups from PostGRES? I see, you are doing SlashDot! The perfect
application for the 30-day dice-roll start-up with $10k in capital. Go
Twitter, go Reddit, go FaceBook, go YouTube!...

Sorry, the subject is serious applications delivered via the Web. Those
social sites are worth billions when they hit it big, but they are not
rich applications -- their magic is elsewhere.

I have worked on exactly two intense Web apps, completely unalike, and
neither fit into your imagined Web app universe. One was datamining, the
current is Algebra tutoring, by a bot or by others. The datamining app
required the server to maintain huge data sets being formed, sorted,
sub-searched, re-grouped, etc by the user. Want to do that in
JavaScript, shuttling all the data out to the client only to have the
user look at it and decide to do a different search?

The Algebra app requires insanely difficult code even to WYSIWYG edit
the math, let alone analyze, correct, and hint intermediate steps of
Algebra problems. Want to write that in JS? And have it run at JS speeds?

As for the lecture on model vs. view, come on, we all know the issues. I
was old when SmallTalk introduced MVC. What seems not to be known is
that applications vary on how tightly GUIs need to be wed with their
models, and how much CPU horsepower is needed to manage the model.
Reddit just saves posts, links them, supports login/logout and 'mod
up/down' buttons. Other applications may not be so simple.

The moral is that you are absolutely right about some applications, but
not true RIAs. And qooxdoo does not exist to support Reddit.

kt

--
http://www.stuckonalgebra.com
"The best Algebra tutorial program I have seen... in a class by itself."
Macworld

------------------------------------------------------------------------------

_______________________________________________
qooxdoo-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
Reply | Threaded
Open this post in threaded view
|

Re: ANNC: qooxlisp 0.1: qooxdoo + Common Lisp

Kenneth Tilton
In reply to this post by Kenneth Tilton


Kenneth Tilton wrote:
>
> [hidden email] wrote:
>> Idunno. I like Javascript. It may not be the richest language in the
>> world, but it is built in such a way that you can easily do anything to
>> it in javascript code, except enriching its syntax.

Just beginning to define the cost of "except enriching its syntax" here:

    http://wiki.github.com/kennytilton/qooxlisp/the-lisp-in-qooxlisp

I have code to write and a motorcar race to watch so not sure how far I
will get, but I'll do my best. And I'll post again when I am not going
to add any more if you want to wait till then. I will also add a link to
Paul Graham's book "On Lisp" available on-line/free.

kt


--
http://www.stuckonalgebra.com
"The best Algebra tutorial program I have seen... in a class by itself."
Macworld

------------------------------------------------------------------------------

_______________________________________________
qooxdoo-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
Reply | Threaded
Open this post in threaded view
|

Re: ANNC: qooxlisp 0.1: qooxdoo + Common Lisp

Kenneth Tilton


Kenneth Tilton wrote:

>
> Kenneth Tilton wrote:
>> [hidden email] wrote:
>>> Idunno. I like Javascript. It may not be the richest language in the
>>> world, but it is built in such a way that you can easily do anything to
>>> it in javascript code, except enriching its syntax.
>
> Just beginning to define the cost of "except enriching its syntax" here:
>
>     http://wiki.github.com/kennytilton/qooxlisp/the-lisp-in-qooxlisp
>
> I have code to write and a motorcar race to watch so not sure how far I
> will get, but I'll do my best. And I'll post again when I am not going
> to add any more if you want to wait till then.

OK, that's enough for a start:

   http://wiki.github.com/kennytilton/qooxlisp/

kt

--
http://www.stuckonalgebra.com
"The best Algebra tutorial program I have seen... in a class by itself."
Macworld

------------------------------------------------------------------------------

_______________________________________________
qooxdoo-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
Reply | Threaded
Open this post in threaded view
|

Re: ANNC: qooxlisp 0.1: qooxdoo + Common Lisp

panyasan
In reply to this post by Kenneth Tilton
Hi Kenneth,

thank you for your interesting example that allows to get some insights into how lisp works. However, isn't the point you are making more generally valid for all kinds of declarative and macro-based syntax that is "compiled" to javascript? For example, in QxTransformer, we use a HTML-like markup which gets transformed in javascript, and with the templating capabilities of this system, I could easily draw up examples where a few lines of xml compile to 3 or more times as much procedural javascript code. However, the drawback is always the same - the further you get away from the code that does the "actual stuff", the more code duplication you will have at the end... I prefer writing my GUI in declarative XML because it is immediated obvious what it is meant to do - just like in HTML - and thus in my opionion better maintainable. But to have an additional layer is always a disadvantage, too.

Just my 2 cents.

Christian
Reply | Threaded
Open this post in threaded view
|

Re: ANNC: qooxlisp 0.1: qooxdoo + Common Lisp

Kenneth Tilton


panyasan wrote:
> Hi Kenneth,
>
> thank you for your interesting example that allows to get some insights into
> how lisp works. However, isn't the point you are making more generally valid
> for all kinds of declarative and macro-based syntax that is "compiled" to
> javascript?

Sure. I was addressing the remark (paraphrasing) "JS is fine except for
the absence of syntax extension". QxTransformer is another way to escape
procedural JS, so good for it.

> For example, in QxTransformer, we use a HTML-like markup which
> gets transformed in javascript, and with the templating capabilities of this
> system, I could easily draw up examples where a few lines of xml compile to
> 3 or more times as much procedural javascript code. However, the drawback is
> always the same - the further you get away from the code that does the
> "actual stuff", the more code duplication you will have at the end... I
> prefer writing my GUI in declarative XML because it is immediated obvious
> what it is meant to do - just like in HTML - and thus in my opionion better
> maintainable. But to have an additional layer is always a disadvantage, too.

Wow. My mileage: it is /never/ a disadvantage as long as the end-user
can bypass the mechanism, and one of the Prime Directives of qooxlisp is
that it must allow full programmability of qooxdoo. I am stunned by the
idea of macros leading to code duplication since that is the main
problem they solve! Do you have an example?

kt



--
http://www.stuckonalgebra.com
"The best Algebra tutorial program I have seen... in a class by itself."
Macworld

------------------------------------------------------------------------------

_______________________________________________
qooxdoo-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
Reply | Threaded
Open this post in threaded view
|

Re: ANNC: qooxlisp 0.1: qooxdoo + Common Lisp

panyasan
Kenneth Tilton wrote
I am stunned by the
idea of macros leading to code duplication since that is the main
problem they solve! Do you have an example?
Hi Kenneth,

code "duplication" wasn't the right word for what I was trying to say. What I mean is that any tool that translates one language that has a certain logic to another one with a different logic will --- I think but you can prove me wrong --- not produce code optimized for the target language. Thus, if you write "native" javascript qooxdoo code, you will use all the strengths that the architecture and logic of the language/library offers you, resulting in translated target code that is suboptimal compared to the code you would write in your declarative/templating language. Maybe that's different for qooxlisp. For me, that is a "disadvantage" that I will accept for xml'izing the GUI because I find it, as I have said before, much easier to maintain and write. But that is a matter of taste and habit rather than a question that can be decided in some way "objectively".

Cheers,
Christian
Reply | Threaded
Open this post in threaded view
|

Re: ANNC: qooxlisp 0.1: qooxdoo + Common Lisp

panyasan
Duh, I should read what I write before sending the "post" button, and have more coffee. Sorry for the gibberish. What I meant was:

"... if you write "native" javascript qooxdoo code, you will use all the strengths that the architecture and logic of the language/library offers you, resulting in compact and concise code, whereas the code resulting from the translation of declarative/templating code will be suboptimal compared to that. ..."

Anyways, with javascript engines ever-increasing speed, this factor might loose significance and we will see more compilers that translate into javascript.

C.
Reply | Threaded
Open this post in threaded view
|

Re: ANNC: qooxlisp 0.1: qooxdoo + Common Lisp

Kenneth Tilton
In reply to this post by panyasan


panyasan wrote:

>
> Kenneth Tilton wrote:
>> I am stunned by the
>> idea of macros leading to code duplication since that is the main
>> problem they solve! Do you have an example?
>>
>
> Hi Kenneth,
>
> code "duplication" wasn't the right word for what I was trying to say. What
> I mean is that any tool that translates one language that has a certain
> logic to another one with a different logic will --- I think but you can
> prove me wrong --- not produce code optimized for the target language. Thus,
> if you write "native" javascript qooxdoo code, you will use all the
> strengths that the architecture and logic of the language/library offers
> you, resulting in translated target code that is suboptimal compared to the
> code you would write in your declarative/templating language.

I see: like when in-line assembler was faster than anything a compiler
could produce. But even there one still used the compiler, one just
wrote assembler for certain key chunks of code.

> Maybe that's
> different for qooxlisp.

I think qooxlisp will be the same.

> For me, that is a "disadvantage" that I will accept
> for xml'izing the GUI because I find it, as I have said before, much easier
> to maintain and write.

Yep.

> But that is a matter of taste and habit rather than a
> question that can be decided in some way "objectively".

I think it is not so hard to analyze, but as I said to the mysterious
"flj", it comes down to the application. In my case, the total UI load
will include an awful lot of jsMath translation of TeX strings, and of
course qooxdoo internal code does a lot of the work at run-time. Suppose
that is 90% of the load? And suppose hand-crafting my application JS
makes it 10% faster, and that the client has 98% excess CPU capacity.

Let's get back to work! :)

kt


--
http://www.stuckonalgebra.com
"The best Algebra tutorial program I have seen... in a class by itself."
Macworld

------------------------------------------------------------------------------

_______________________________________________
qooxdoo-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
Reply | Threaded
Open this post in threaded view
|

Re: ANNC: qooxlisp 0.1: qooxdoo + Common Lisp

Kenneth Tilton
In reply to this post by panyasan


panyasan wrote:
> Duh, I should read what I write before sending the "post" button, and have
> more coffee. Sorry for the gibberish. What I meant was:
>
> "... if you write "native" javascript qooxdoo code, you will use all the
> strengths that the architecture and logic of the language/library offers
> you, resulting in compact and concise code, whereas the code resulting from
> the translation of declarative/templating code will be suboptimal compared
> to that. ..."

heh-heh, thx, the original did throw me but I had the context so I was
able to unravel the intended meaning.

>
> Anyways, with javascript engines ever-increasing speed, this factor might
> loose significance and we will see more compilers that translate into
> javascript.

I still think that compared to the load carried by qooxdoo internals and
network latency and maybe things like jsMath we might use, we just are
not writing a large enough fraction of the overall runtime code path to
worry about this. And as with compilers, JS-generating hacks can get
smarter and possibly end up generating superior code to hand-crafted.
jsMath, for example, keeps a dictionary of TeX strings seen and re-uses
translations where possible.

Final thought: if we want handcrafted code, we should not be using
qooxdoo. Have you ever navigated down into the DOM generated? But it
works great and fast and makes us more productive overall.

Let's get back to work! :)

kt

--
http://www.stuckonalgebra.com
"The best Algebra tutorial program I have seen... in a class by itself."
Macworld

------------------------------------------------------------------------------

_______________________________________________
qooxdoo-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
Reply | Threaded
Open this post in threaded view
|

Re: ANNC: qooxlisp 0.1: qooxdoo + Common Lisp

fritz
On Mon, 31 May 2010, Kenneth Tilton wrote:

> Final thought: if we want handcrafted code, we should not be using
> qooxdoo. Have you ever navigated down into the DOM generated? But it
> works great and fast and makes us more productive overall.

Not even to talk about abstracting all the browser differences ... ;-)

> Let's get back to work! :)

Yes, Sir!

Cheers,
Fritz

--
Oetiker+Partner AG tel: +41 62 775 9903 (direct)
Fritz Zaucker                        +41 62 775 9900 (switch board)
Aarweg 15                            +41 79 675 0630 (mobile)
CH-4600 Olten                   fax: +41 62 775 9905
Schweiz                         web: www.oetiker.ch

------------------------------------------------------------------------------

_______________________________________________
qooxdoo-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
flj
Reply | Threaded
Open this post in threaded view
|

Re: ANNC: qooxlisp 0.1: qooxdoo + Common Lisp

flj
In reply to this post by Kenneth Tilton
@Kenneth Tilton:

Don't get me wrong, I didn't mean to be offensive in any way. Only, as far as my experience goes, there is a generic problem with applications or frameworks trying to move much or all of the logic to the server. It's not qooxdlisp I'm not convinced about, it's all frameworks which execute application logic exclusively or mainly server-side.

I can see a benefit of  having the possibility to create web applications from your (and your team's) language of choice. But this doesn't eliminate the problems of having all logic executed server-side and having huge state information stored on the server. In general, the more complex the user interface, the more logic has to be  built into it, and the more state information has to be maintained. If you execute all of this logic server-side, no matter what language you use, you will have a chatty web application which has to manage huge sessions. Which is heavy on the server even when used concurrently by a smaller number of users. It's not a matter of qooxdlisp. There are tons of Java frameworks which execute logic and keep state server-side, and just drive the UI. And they are widely used. I just can't see the advantages of such an approach, as long as there is a reasonable alternative.

About data mining and algebra: of all the web applications you know of (and I'm not talking social networks), how many are similar to these two? Other than that, I don't really know enough about these two apps to judge whether there could have more logic been moved to the browser.

We have just started a much less complex but quite large application than the two you  mention, which I think is quite typical for web development: an application where tens of thousands or hundreds of thousands of users have to  be trained online. They get courses, exams and the like online. The editors and the tutors do their activity also online. Users communicate with trainers online, via the application. The application is meant for intranets of large companies, whow have to be able to prove in court, if necessary, that they have provided adequate training to their employees. I wouldn't say this app has a trivial user interface, neither that its logic is trivial. Just a few  years ago, such an application was the typical rich client application. A few less years ago, you would have done it using a framework which _does_ execute all logic on the server and which _does_ store huge server-side state. However, I can't see a single reason today to place much of the  logic on the server. Essentially, the server is only responsible for adapting the relational database to the object-oriented user interface and enforcing access restrictions. And doesn't keep anything in the session info besides the user identity associated with the session. Of course, there will be some maintenance jobs running on the server in the end, written entirely for the server, but there's no way we will have logic on the server deciding what control to enable and or what value to put in what field. We will abstract such operations in higher-level operations, and call the server to obtain data the javascript application needs. Time and again we have found this to be faster and providing better scalablility. If we had to maintain the user interface state on the server, while twenty thousand users would access the application, we'd need to run the application off a server having maybe 10 TB memory, serving up several thousands of requests each second, most of which would need to access a database - or else memory consumption would go up, due to caching requirements.  Having all the logic related to the user interface on the client, memory requirements are of only a few GB, and a lot less than a thousand requests a second - although more complex ones - only the ones related to access to the database or to the file system. Even if the qooxdoo application will need to keep several megabytes of state and code in the browser, this doesn't seem to be a problem. Most workstations nowadays have huge unused quantities of memory and processor cycles.

Before that, we have worked on a somewhat similar application, although the backend was ASP.Net. We used exactly the same architectural ideas, and the outcome was quite nice.

We did test frameworks doing the logic almost entirely server-side some time ago. Our conclusion was that there's no way you can build an UI as smart and responsive using server-side logic as you can when you move much of the logic to the browser. Besides, working with such frameworks is a lot less pleasant than using qooxdoo for the most of the application, not just for the user interface.

One more final note: you keep nagging that clear separation of layers in an application is not always possible. It is indeed a bad idea for some applications. However, many programmers who have worked on many different projects have found that this separation is useful in many cases. Either you are constantly doing very special applications, in which case you are a lucky person, but which's experience isn't really relevant to the most of us, programmers who toil away at database interfaces, workflow applications, or other more or less typical business applications, or there must be something wrong in how you use (or think you should use) a layered architecture for your applications.

best regards,

flj


------------------------------------------------------------------------------
ThinkGeek and WIRED's GeekDad team up for the Ultimate
GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the
lucky parental unit.  See the prize list and enter to win:
http://p.sf.net/sfu/thinkgeek-promo
_______________________________________________
qooxdoo-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
Reply | Threaded
Open this post in threaded view
|

Re: ANNC: qooxlisp 0.1: qooxdoo + Common Lisp

Nextime
On Fri, Jun 04, 2010 at 06:27:26AM +0200, [hidden email] wrote:
> I can see a benefit of  having the possibility to create web applications from your (and your team's) language of choice. But this doesn't eliminate the problems of having all logic executed server-side and having huge state information stored on the server. In general, the more complex the user interface, the more logic has to be  built into it, and the more state information has to be maintained. If you execute all of this logic server-side, no matter what language you use, you will have a chatty web application which has to manage huge sessions. Which is heavy on the server even when used concurrently by a smaller number of users. It's not a matter of qooxdlisp. There are tons of Java frameworks which execute logic and keep state server-side, and just drive the UI. And they are widely used. I just can't see the advantages of such an approach, as long as there is a reasonable alternative.

Another cons in this approach is that the communication between
the server and the ui when the logic is managed by the server
has to be very intensive, and, possibily, this introduce
more bandwidth used and also bad resposivity of the ui.

PS: if you break lines every 70 circa chars your posts will be a LOT more
readable!


--

Franco (nextime) Lanza
Busto Arsizio - Italy
SIP://[hidden email]

NO TCPA: http://www.no1984.org
you can download my public key at:
http://danex.nexlab.it/nextime.asc || Key Servers
Key ID = D6132D50
Key fingerprint = 66ED 5211 9D59 DA53 1DF7  4189 DFED F580 D613 2D50
-----------------------------------
echo 16i[q]sa[ln0=aln100%Pln100/snlbx]sbA0D212153574F444E49572045535520454D20454B414D204F54204847554F4E452059415020544F4E4E4143205345544147204C4C4942snlbxq | dc
-----------------------------------


------------------------------------------------------------------------------
ThinkGeek and WIRED's GeekDad team up for the Ultimate
GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the
lucky parental unit.  See the prize list and enter to win:
http://p.sf.net/sfu/thinkgeek-promo
_______________________________________________
qooxdoo-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel

signature.asc (205 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: ANNC: qooxlisp 0.1: qooxdoo + Common Lisp

Kenneth Tilton


nextime wrote:
> On Fri, Jun 04, 2010 at 06:27:26AM +0200, [hidden email] wrote:
>> I can see a benefit of  having the possibility to create web applications from your (and your team's) language of choice. But this doesn't eliminate the problems of having all logic executed server-side and having huge state information stored on the server. In general, the more complex the user interface, the more logic has to be  built into it, and the more state information has to be maintained. If you execute all of this logic server-side, no matter what language you use, you will have a chatty web application which has to manage huge sessions. Which is heavy on the server even when used concurrently by a smaller number of users. It's not a matter of qooxdlisp. There are tons of Java frameworks which execute logic and keep state server-side, and just drive the UI. And they are widely used. I just can't see the advantages of such an approach, as long as there is a reasonable alternative.
>
> Another cons in this approach is that the communication between
> the server and the ui when the logic is managed by the server
> has to be very intensive, and, possibily, this introduce
> more bandwidth used and also bad resposivity of the ui.

"has to be very intensive"? /Has to be?/ Is this anything like the flj's
repeated incantation of "huge client state"?  Prithee, precisely how
huge is the hugeness of /my/ application's client state? And how intense
is its client-server interaction? You don't know? Precisely.

This is a qooxdoo list, not a Theory of Web 2.0 list, so I will end by
pointing out you both fail to consider that applications vary. And
neither of you seem to understand that we are free with qooxlisp and I
presume other such frameworks to move logic to the client (by coding JS)
whenever that would help.

btw, that there are other such frameworks suggests your insistence that
this approach is prima facie wrong is, um, de facto wrong. Love that Latin.

The meta-answer is precisely not to have rules such as "X will never
work" and "Y is the only way". We are never writing all applications, we
are only ever writing /this/ application. It might call for X, Y, or a
mix of X and Y. Sarte said we are not free to be not free, Kenny says we
are not free not to engineer our applications in all their specificity.

btw, JS is neat but not a heavy-duty language so your side needs to stop
pretending that programming applications in JS is as easy as merely
deciding to do so. Clearly your model of an application is one in which
the logic is trivial and the data interesting. That's not always how it
goes.

kt



------------------------------------------------------------------------------
ThinkGeek and WIRED's GeekDad team up for the Ultimate
GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the
lucky parental unit.  See the prize list and enter to win:
http://p.sf.net/sfu/thinkgeek-promo
_______________________________________________
qooxdoo-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
12