ANNC: qooxlisp 0.1: Driving Miss qooxdoo (from Common Lisp)

[Kenneth Tilton]

qooxdoo + Common Lisp (+ Cells, a common lisp dataflow hack):
http://wiki.github.com/kennytilton/qooxlisp/

Just a proof of concept so far, but includes a substantial starter example:
http://github.com/downloads/kennytilton/qooxlisp/apropos-kt.jpg

Discussion of the Lisp advantage here:
http://wiki.github.com/kennytilton/qooxlisp/the-lisp-in-qooxlisp

Discussion of the Cells advantage is being written next and will appear
here:
http://wiki.github.com/kennytilton/qooxlisp/the-cells-insidetm-qooxlisp


kt

 

[David Mark]

qooxdoo + Common Lisp (+ Cells, a common lisp dataflow hack):
   http://wiki.github.com/kennytilton/qooxlisp/

Qooxdoo + anything < 0; // true

 

[Roby Sadeli]

qooxdoo + Common Lisp (+ Cells, a common lisp dataflow hack):
   http://wiki.github.com/kennytilton/qooxlisp/

Just a proof of concept so far, but includes a substantial starter example:
   http://github.com/downloads/kennytilton/qooxlisp/apropos-kt.jpg

Discussion of the Lisp advantage here:
 http://wiki.github.com/kennytilton/qooxlisp/the-lisp-in-qooxlisp

Discussion of the Cells advantage is being written next and will appear
here:
 http://wiki.github.com/kennytilton/qooxlisp/the-cells-insidetm-qooxlisp

kt

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

Really cool stuff Mr. Tilton!
I have been reading your blog and noticed your interest in qooxdoo +
lisp.
I really hope your interest in qooxlisp doesn't wane anytime soon
since I
really want to see a complete framework that people can use. (+ great
docs
)

Btw, my Lisp knowledge is minimal and I have just learned how to
use cl-weblocks.

 

[Kenneth Tilton]

Qooxdoo + anything < 0; // true

Dave! Whassup?!

I considered building a framework atop your stuff to make for much
lighter initial loads but needed a quick win. (and qooxdoo rocks for RIAs).

Maybe for my next effort, if you 'll do an LGPL license for it.

kt

 

[David Mark]

Dave! Whassup?!

Oh, that's right. It's "Kenny" from a ways back. I should have made
the connection as AFAIK you were/are the only person on earth using
Qooxdoo.

I considered building a framework atop your stuff to make for much
lighter initial loads but needed a quick win.

Or perhaps the fleeting illusion of such? We went over this ad
nauseam. Qooxdoo is a bloated, outdated, over-engineered pile of
browser sniffing crap-ola (see also Dojo).

(and qooxdoo rocks for RIAs).

Sucks, Kenny. Sucks for RIA's. Perhaps there was a breakdown in
communication?

Maybe for my next effort, if you 'll do an LGPL license for it.

Last I checked it had an MIT license. That was the consensus choice.
I have no idea how that differs from an LGPL license and don't care to
find out. Use it or don't.

 

[Kenny]

Oh, that's right. It's "Kenny" from a ways back. I should have made
the connection as AFAIK you were/are the only person on earth using
Qooxdoo.


Or perhaps the fleeting illusion of such? We went over this ad
nauseam. Qooxdoo is a bloated, outdated, over-engineered pile of
browser sniffing crap-ola (see also Dojo).


Sucks, Kenny. Sucks for RIA's. Perhaps there was a breakdown in
communication?

I think it was a breakdown in parallel universes. In mine qooxdoo works
brilliantly.

Last I checked it had an MIT license. That was the consensus choice.
I have no idea how that differs from an LGPL license and don't care to
find out. Use it or don't.

Oh, great, I do MIT, too. Last /I/ checked your stuff was licensed "ask me".

Well, see if you like this:

http://wiki.github.com/kennytilton/qooxlisp/the-cells-insidetm-qooxlisp

We could do the same with raw HTML/js

kt

 

[Kenny]

Really cool stuff Mr. Tilton!
Thanks!

I have been reading your blog and noticed your interest in qooxdoo +
lisp.
I really hope your interest in qooxlisp doesn't wane anytime soon
since I
really want to see a complete framework that people can use. (+ great
docs
)

Well, I will be using it to move my Algebra software to the web and it
has a pretty intense interface so its gonna happen and happen fast. I
also think as an open-source project it will get enough support to move
even faster. The Cells component is especially awesome for GUI
development so I think we may even convert more than a few developers
using other stacks to qooxlisp.

Btw, my Lisp knowledge is minimal and I have just learned how to
use cl-weblocks.

That is definitely one of the neater libraries out there for web
programming in Lisp.

kt

 

[David Mark]

I think it was a breakdown in parallel universes. In mine qooxdoo works
brilliantly.

Based on what evidence? I'm guessing you tried it in a handful of
browsers you had handy and figured if it appeared to work in those, it
must be "brilliant". Did it ever occur to you that the authors of
qooxdoo tried the same browsers before you and inserted lots of hacks
and sniffs to make them appear to work? What do you think will happen
in anything older, newer or unknown to the authors?

Oh, great, I do MIT, too. Last /I/ checked your stuff was licensed "ask me".

Yeah, and lots did. Most of those got a free license. People who
didn't ask got nothing. Go figure.

Well, see if you like this:

http://wiki.github.com/kennytilton/qooxlisp/the-cells-insidetm-qooxlisp

What about it?

We could do the same with raw HTML/js

Raw HTML?

 

[Kenneth Tilton]

Based on what evidence? I'm guessing you tried it in a handful of
browsers you had handy and figured if it appeared to work in those, it
must be "brilliant". Did it ever occur to you that the authors of
qooxdoo tried the same browsers before you and inserted lots of hacks
and sniffs to make them appear to work? What do you think will happen
in anything older, newer or unknown to the authors?

I'll lose 0.01% of my market for a week until the ten full-time
engineers paid to work on qooxdoo patch it?

Yeah, and lots did. Most of those got a free license. People who
didn't ask got nothing. Go figure.

Oh, you just wanted to have us come grovelling to your door hat in hand?
Great!

What about it?

Wow, you learned nothing, eh? That is the price of knowing everything, I
guess. But at least you know everything.

Raw HTML?

Keep up the good fight! Still programming in assembly language?



kt

 

[Thomas 'PointedEars' Lahn]

I'll lose 0.01% of my market for a week until the ten full-time
engineers paid to work on qooxdoo patch it?

,-[qooxdoo-1.1-sdk/framework/source/class/qx/Bootstrap.js:554]
|
| getClass : function(value)
| {
| var classString = Object.prototype.toString.call(value);
| return (
| qx.Bootstrap.__classToTypeMap[classString] ||
| classString.slice(8, -1)
| );
| },

,-[ibid.:554]
|
| isString : function(value)
| {
| // Added "value !== null" because IE throws an exception "Object
| // expected"
| // by executing "value instanceof Array" if value is a DOM element that
| // doesn't exist. It seems that there is a internal different between a
| // JavaScript null and a null returned from calling DOM.
| // e.q. by document.getElementById("ReturnedNull").
| return (
| value !== null && (
| typeof value === "string" ||
| qx.Bootstrap.getClass(value) == "String" ||
| value instanceof String ||
| (!!value && !!value.$$isString))
| );
| },

This alone proves that qooxdoo is junk as its authors are completely
clueless. Get over it.


PointedEars

 

[David Mark]

I'll lose 0.01% of my market for a week until the ten full-time
engineers paid to work on qooxdoo patch it?

You don't understand at all. For one, these "engineers" are the ones
who are screwing up in the first place. They are selling you the
problem and a lifetime subscription to their future (temporary)
solutions.

Like similar libraries/frameworks, qooxdoo forks based on browser
sniffs. So when a new version of IE (for example) comes out and
invalidates their ill-advised inferences, they have two choices:-

1. Add more forks based on the sniffed version of IE

2. Declare the older versions of IE "dead"

The first choice obviously makes the code longer, messier and harder
to maintain with each iteration. To see the long-term effects of such
a strategy, take a gander at the Dojo source.

The second, despite its recent popularity, is insane as the end-users
don't know their browsers are deceased. There are plenty of users
stuck with IE6/7 with no recourse (e.g. corporate users). XP users
will never see IE9, so are forever stuck with IE8 (which they can
change to work like IE7 with a single button push). And no, you can't
just tell them to download FF. Some users aren't allowed to install
alternate browsers and others don't know what a browser is.

And the last thing you should want is to have to swap out a complex
blob of JS, just to "keep up" with new browsers. Invariably, there
will be compatibility problems as rearranging their browser sniffing
will not be all those "engineers" are up to in the interim. You'll
inherit lots of "nice-to-have" features suggested by other users
(assuming qooxdoo has any other users at this point).

Also, how did you come up with 0.01%? It sounds arbitrary and self-
serving (or perhaps self-deluding). Remember that qooxdoo is going to
be much too bloated and slow for most mobile devices (and you can't
patch that). Did you factor that into your equation?

These concepts are not difficult to understand. I rarely have trouble
explaining them to non-programmers.

Oh, you just wanted to have us come grovelling to your door hat in hand?
Great!

You seem to have amnesia as we went over this some time back. The
point was that I would grant licenses on a case-by-case basis.

Wow, you learned nothing, eh? That is the price of knowing everything, I
guess. But at least you know everything.

You sound drunk. What was I supposed to learn from that? You posted
a link to an article with no context. Again, what about it?

Keep up the good fight! Still programming in assembly language?

That doesn't make any sense either. I am programming in the same
language as you and your "engineer" friends. HTH.

 

[Ry Nohryb]

That doesn't make any sense either.  I am programming in the same
language as you and your "engineer" friends.  HTH.

Yes, the same language, not, the same API. The browsers provide an
(awful) lower-level API that you love to love. But people are moving
towards more powerful, higher level, much less awful APIs, by
extending the language. That's what the -many- libraries (attempt to)
provide. But you seem not to get it.

 

[David Mark]

Yes, time to check up on those wily (and paid!) "engineers".

,-[qooxdoo-1.1-sdk/framework/source/class/qx/Bootstrap.js:554]
|
| getClass : function(value)
| {
|   var classString = Object.prototype.toString.call(value);
|   return (
|     qx.Bootstrap.__classToTypeMap[classString] ||
|     classString.slice(8, -1)
|   );
| },

That's a completely worthless and ill-conceived function that could
only have been designed by a neophyte. My guess is the whole mess
hinges on it. Hope they disallowed host objects.

,-[ibid.:554]
|
| isString : function(value)
| {
|   // Added "value !== null" because IE throws an exception "Object
| // expected"
|   // by executing "value instanceof Array" if value is a DOM element that
|   // doesn't exist.

This looks like the sort of confused-as-all-hell comments I saw all
over Dojo. Skipping ahead a bit, I don't see any value instanceof
Array either.

And obviously they have not disallowed host objects for this one.

It seems that there is a internal different between a
|   // JavaScript null and a null returned from calling DOM.
|   // e.q. by document.getElementById("ReturnedNull").

And there you have it. What is "a internal different" anyway? There
may be twelve of them, they may be paid and may well work full-time,
but these are not engineers (in any sense of the word). Worse still,
they clearly have no experience with JS or browser scripting and
apparently can't even explain their confusion in a coherent fashion.
You could have twelve-hundred such developers working double-time, on
weekends, holidays, etc. and you'd still have no hope (for anything
but a disastrous result).

|   return (
|     value !== null && (
|     typeof value === "string" ||
|     qx.Bootstrap.getClass(value) == "String" ||

Didn't disallow host objects for the other one either, which certainly
contributed to their confusion and subsequent attempt to patch the
"imaginary DOM element" problem.

|     value instanceof String ||
|     (!!value && !!value.$$isString))
|   );
| },

This illustrates the often-wide gap between the perceptions of an
impressionable neophyte and the realities of their chosen code.
Twelve full-time engineers working around the clock sounds impressive
until you look at their output.

And I bet if you tried to explain the issues to them, the response
would be "show me where it fails!"

Show me where this fails:-

var isIE = !!document.all;

function magic(a, b) {
return 0;
}

/* This might look funny, but it must be
done this way to work in all browsers
Trust us, we are engineers. */

function addTwoNumbers(a, b) {
return a + b + 8 + 10 - 8 - 10 - magic(a, b) + magic(b, a) * (isIE ?
2.5 : 3);
}

Passes the unit tests. Can't be bad.

Obviously, that's a made-up example, but some of the code in Dojo,
Prototype, etc. has ended up in a similar state after years of
community guesswork. One guy screws up in one module, another module
is adjusted to compensate, then a new browser comes out that breaks
the patches, a browser sniff is added, etc. Eventually you get a god-
awful mess of a patchwork that nobody understands (and most are
hesitant to touch) and comments, documentation, blog posts, etc. that
try to make sense of the senseless.

 

[David Mark]

Yes, the same language, not, the same API.

Uh, no. His "engineer" friends are in fact using the same API. He's
using their botched attempt to abstract something they don't
understand in the slightest. Nothing good will come of that.

The browsers provide an
(awful) lower-level API that you love to love.

Don't be a clod. It is what it is.

But people are moving
towards more powerful, higher level, much less awful APIs, by
extending the language.

The trouble is they are doing it with such incompetence that the
results are often laughably inept. Did you read the rest of this
thread?

That's what the -many- libraries (attempt to)
provide. But you seem not to get it.

Of course I get it. I wrote one, remember?

Get better, Jorge!

 

[Kenneth Tilton]

Yes, time to check up on those wily (and paid!) "engineers".

,-[qooxdoo-1.1-sdk/framework/source/class/qx/Bootstrap.js:554]
|
| getClass : function(value)
| {
| var classString = Object.prototype.toString.call(value);
| return (
| qx.Bootstrap.__classToTypeMap[classString] ||
| classString.slice(8, -1)
| );
| },

That's a completely worthless and ill-conceived function that could
only have been designed by a neophyte. My guess is the whole mess
hinges on it. Hope they disallowed host objects.

,-[ibid.:554]
|
| isString : function(value)
| {
| // Added "value !== null" because IE throws an exception "Object
| // expected"
| // by executing "value instanceof Array" if value is a DOM element that
| // doesn't exist.

This looks like the sort of confused-as-all-hell comments I saw all
over Dojo. Skipping ahead a bit, I don't see any value instanceof
Array either.

And obviously they have not disallowed host objects for this one.

It seems that there is a internal different between a
| // JavaScript null and a null returned from calling DOM.
| // e.q. by document.getElementById("ReturnedNull").

And there you have it. What is "a internal different" anyway?

Why you old xenophobe, you! English is not their native tongue.

There
may be twelve of them, they may be paid and may well work full-time,
but these are not engineers (in any sense of the word). Worse still,
they clearly have no experience with JS or browser scripting and
apparently can't even explain their confusion in a coherent fashion.
You could have twelve-hundred such developers working double-time, on
weekends, holidays, etc. and you'd still have no hope (for anything
but a disastrous result).


Didn't disallow host objects for the other one either, which certainly
contributed to their confusion and subsequent attempt to patch the
"imaginary DOM element" problem.


This illustrates the often-wide gap between the perceptions of an
impressionable neophyte and the realities of their chosen code.
Twelve full-time engineers working around the clock sounds impressive
until you look at their output.

And I bet if you tried to explain the issues to them, the response
would be "show me where it fails!"

Show me where this fails:-

var isIE = !!document.all;

function magic(a, b) {
return 0;
}

/* This might look funny, but it must be
done this way to work in all browsers
Trust us, we are engineers. */

function addTwoNumbers(a, b) {
return a + b + 8 + 10 - 8 - 10 - magic(a, b) + magic(b, a) * (isIE ?
2.5 : 3);
}

Passes the unit tests. Can't be bad.

Obviously, that's a made-up example, but some of the code in Dojo,
Prototype, etc. has ended up in a similar state after years of
community guesswork. One guy screws up in one module, another module
is adjusted to compensate, then a new browser comes out that breaks
the patches, a browser sniff is added, etc. Eventually you get a god-
awful mess of a patchwork that nobody understands (and most are
hesitant to touch) and comments, documentation, blog posts, etc. that
try to make sense of the senseless.

Thx for the tech review! I forwarded it to the qooxdoo list in case they
are not reading here. Meanwhile, there is a difference between being a
good engineer and a God of Javascript. You may know more Javascript, but
that does not make them bad engineers. I have been into the internals,
once to get more performance out of the remote data model class, other
times just to understand how things work. The code is great, which tells
me that some day they'll catch up with you on Javascript. I also ended
up in Dojo and YUI code. Well, Dojo was such a nightmare I do not recall
digging in all that far. But YUI? Simple things simply did not work, and
when I investigated and saw the code I was horrified.

qooxdoo is the fastest, most extensive, easiest to learn, and best
functioning JS library out there with the excellent code inside and
documentation outside -- methinks they know what they are doing.

kt

 

[Kenneth Tilton]

You don't understand at all. For one, these "engineers" are the ones
who are screwing up in the first place. They are selling you the
problem and a lifetime subscription to their future (temporary)
solutions.

I explained elsewhere that I know from examining their code (and from
seeing the result) how good they are, so this argument just begs the
question to which you have the incorrect answer.

Like similar libraries/frameworks, qooxdoo forks based on browser
sniffs. So when a new version of IE (for example) comes out and
invalidates their ill-advised inferences, they have two choices:-

1. Add more forks based on the sniffed version of IE

2. Declare the older versions of IE "dead"

The first choice obviously makes the code longer, messier and harder
to maintain with each iteration. To see the long-term effects of such
a strategy, take a gander at the Dojo source.

The second, despite its recent popularity, is insane as the end-users
don't know their browsers are deceased. There are plenty of users
stuck with IE6/7 with no recourse (e.g. corporate users). XP users
will never see IE9, so are forever stuck with IE8 (which they can
change to work like IE7 with a single button push). And no, you can't
just tell them to download FF. Some users aren't allowed to install
alternate browsers and others don't know what a browser is.

And the last thing you should want is to have to swap out a complex
blob of JS, just to "keep up" with new browsers. Invariably, there
will be compatibility problems as rearranging their browser sniffing
will not be all those "engineers" are up to in the interim. You'll
inherit lots of "nice-to-have" features suggested by other users
(assuming qooxdoo has any other users at this point).

Also, how did you come up with 0.01%? It sounds arbitrary and self-
serving (or perhaps self-deluding).

You stipulated undiscovered browser or new version of a popular browser
during its first week, the longest it would take for qooxdoo to
adopt...OK, 0.01% might be high.

Remember that qooxdoo is going to
be much too bloated and slow for most mobile devices (and you can't
patch that). Did you factor that into your equation?

Not my market, fortunately. I am also fotunate in that I am doing a rixh
web app where someone would likely work for 30min at a minimum, so pages
can take 5s to load.

These concepts are not difficult to understand. I rarely have trouble
explaining them to non-programmers.


You seem to have amnesia as we went over this some time back. The
point was that I would grant licenses on a case-by-case basis.


You sound drunk. What was I supposed to learn from that? You posted
a link to an article with no context. Again, what about it?


That doesn't make any sense either. I am programming in the same
language as you and your "engineer" friends. HTH.

Sorry, are you autistic? It was analogy.

 

[David Mark]

Yes, time to check up on those wily (and paid!) "engineers".

,-[qooxdoo-1.1-sdk/framework/source/class/qx/Bootstrap.js:554]
|
| getClass : function(value)
| {
|   var classString = Object.prototype.toString.call(value);
|   return (
|     qx.Bootstrap.__classToTypeMap[classString] ||
|     classString.slice(8, -1)
|   );
| },

That's a completely worthless and ill-conceived function that could
only have been designed by a neophyte.  My guess is the whole mess
hinges on it.  Hope they disallowed host objects.

,-[ibid.:554]
|
| isString : function(value)
| {
|   // Added "value !== null" because IE throws an exception "Object
| // expected"
|   // by executing "value instanceof Array" if value is a DOM element that
|   // doesn't exist.

This looks like the sort of confused-as-all-hell comments I saw all
over Dojo.  Skipping ahead a bit, I don't see any value instanceof
Array either.

And obviously they have not disallowed host objects for this one.

And there you have it.  What is "a internal different" anyway?

Why you old xenophobe, you! English is not their native tongue.

You have me confused with someone else. And I've seen such slovenly
comments made by native English speakers. Usually it is an indicator
of haste.

Thx for the tech review! I forwarded it to the qooxdoo list in case they
are not reading here.

They are almost certainly not reading here. None of the "major"
library developers do AFAIK. If any of them do, they are a curiously
silent bunch (which should tell you something). Of course, these
posts get syndicated all over the place, so eventually bits and pieces
get through. I've heard they like to gripe and whine about the
rumblings from this "antiquated" newsgroup in the cozy (and ostensibly
more modern) confines of their respective IRC channels.

More likely they are programming with blinders on to keep reality from
messing with their fantasies.

And I predict your attempt at cross-pollination will be less than
productive. You either know this stuff or your don't. Generally
those who don't are laboring under the delusion that they do, so it is
typically hard to get through to them.

Meanwhile, there is a difference between being a
good engineer and a God of Javascript.

If you are a good engineer, then you take the time to learn the
language and *basic* browser scripting concepts before setting out to
write a framework. And you sure don't have to be a god to see that
the cited code is gobbledygook.

You may know more Javascript, but
that does not make them bad engineers.

You really don't know what you are talking about. That's why you are
stuck using qooxdoo. That wouldn't be so bad if the authors of that
framework knew what they were doing. But alas, like the authors of
Dojo, YUI, Prototype, jQuery, etc. they don't.

I have been into the internals,
once to get more performance out of the remote data model class, other
times just to understand how things work. The code is great, which tells
me that some day they'll catch up with you on Javascript.

So you looked at the "internals", concluded they were "great" and that
tells you that some day they will "catch up" with me. On the other
hand, I've looked at their code, concluded it was rubbish. Perhaps
one day they will gain a minimal clue about this stuff, but how does
that help you today? And I wouldn't hold your breath as browser
scripting has a very steep learning curve.

I also ended
up in Dojo and YUI code. Well, Dojo was such a nightmare I do not recall
digging in all that far.

It doesn't take long to diagnose that one.

But YUI? Simple things simply did not work, and
when I investigated and saw the code I was horrified.

You want horror? Try reading their change logs.

qooxdoo is the fastest, most extensive, easiest to learn, and best
functioning JS library out there with the excellent code inside and
documentation outside

And what leads you to that delusion?

-- methinks they know what they are doing.

Obviously, youthinks wrong.

 

[Thomas 'PointedEars' Lahn]

I explained elsewhere that I know from examining their code (and from
seeing the result) how good they are, so this argument just begs the
question to which you have the incorrect answer.

Why I am suddenly thinking of that line from MIB?
“Imagine what you'll ‘know’ tomorrow.â€


F'up2 cljs

PointedEars

 

[David Mark]

I explained elsewhere that I know from examining their code (and from
seeing the result) how good they are, so this argument just begs the
question to which you have the incorrect answer.

That only serves to illustrate how bad your judgment is. Since when
do you have a clue about JS and/or browser scripting?

And how did you miss the bits we went over here? That's obviously low-
level code, which means they've piled a ton of other abstractions on
top of a completely asinine design. Changing the bad low-level
design(s) will likely entail rewriting much of what sits atop it. In
other words, they got way too far ahead of themselves and are now
screwed (as are you).

You stipulated undiscovered browser or new version of a popular browser
during its first week, the longest it would take for qooxdoo to
adopt...

I recognize the words, but that sentence makes no sense.

OK, 0.01% might be high.

I think you are high.

Not my market, fortunately. I am also fotunate in that I am doing a rixh
web app where someone would likely work for 30min at a minimum, so pages
can take 5s to load.

But I thought you said qooxdoo was the "fastest". (?)

Sorry, are you autistic?

Ah, don't apologize (except perhaps to those afflicted with autism).

It was analogy.

Nope.

 

[Kenneth Tilton]

That only serves to illustrate how bad your judgment is. Since when
do you have a clue about JS and/or browser scripting?

You seem not to be a very good programmer: quality exists at a higher
level than a particular language's syntax, and any good programmer knows
that.

And how did you miss the bits we went over here?

The good news is I am using qooxdoo and will never have to waste my time
on that crap.

That's obviously low-
level code, which means they've piled a ton of other abstractions on
top of a completely asinine design. Changing the bad low-level
design(s) will likely entail rewriting much of what sits atop it. In
other words, they got way too far ahead of themselves and are now
screwed (as are you).


I recognize the words, but that sentence makes no sense.


I think you are high.


But I thought you said qooxdoo was the "fastest". (?)

Once it is loaded, yep. Sure, I'd love it to load instantly, but my
application is for folks who will be spending 20-60min trying to learn
Algebra. They have 4 seconds.

Ah, don't apologize (except perhaps to those afflicted with autism).


Nope.

Yup. Maybe you are too young to get it.

kt