19 Jan, 2012, JohnnyStarr wrote in the 1st comment:
Votes: 0
I've been reading up on how javascript can be used as an intermediary language. CoffeeScript comes to
mind. The disadvantage though, is that you must compile to javascript first. I love jQuery as a good
javascript library, but I'm starting to think that it would be cool to create a new language in javascript
itself that would run in the browser.

I'm not too sure about speed, but I don't think that it would be too much of an issue if the language was
compiled directly into javascript.

First of all, I would like to offer a more logical approach to DOM object access:

Raw
var txt = document.getElementById("thing").value;


jQuery
var txt = $("#thing").val();


New Language
txt = doc.thing


The point being that dom.thing would automatically access the value of the "thing" element. If "thing"
happened to be a <div> then typing dom.thing would be equal to document.getElementById("thing").innerHTML

The only way to include the new language scripts that I can see, would be to use a div with an id that has a style set
by calling the language library.

<script type="text/javascript" src="new_language.js" /> 
// set's the style of new_language to: 'display: none;'

<div id="new_language">
alert doc.thing
</div>


Then, on load you could execute the script:

<body onload="new_lang_execute()">


Which looks for the id's innerHTML and does the rest for you.

This might be a dumb idea, but I think it would be fun to write. If anyone has any reasons why this is a good idea please
share. If it's a dumb idea, please explain.
19 Jan, 2012, Idealiad wrote in the 2nd comment:
Votes: 0
JohnnyStarr said:
I've been reading up on how javascript can be used as an intermediary language. CoffeeScript comes to
mind. The disadvantage though, is that you must compile to javascript first. I love jQuery as a good
javascript library, but I'm starting to think that it would be cool to create a new language in javascript
itself that would run in the browser.

I'm not too sure about speed, but I don't think that it would be too much of an issue if the language was
compiled directly into javascript
.


Bolded for emphasis…you lost me there.
19 Jan, 2012, JohnnyStarr wrote in the 3rd comment:
Votes: 0
Ahh.

What I meant to say, is that the CoffeeScript compiler is a desktop application that does not run in the browser.
20 Jan, 2012, plamzi wrote in the 4th comment:
Votes: 0
JohnnyStarr said:
The point being that dom.thing would automatically access the value of the "thing" element. If "thing"
happened to be a <div> then typing dom.thing would be equal to document.getElementById("thing").innerHTML


Since you have written "doc.thing" and not "doc.thing()" or "doc.get('thing')", my comments assume that you'll be building a library of node references everytime the page loads.

In your example, how would you get a reference to a div object itself instead of its innerHTML?

Of course, you can store raw references to objects in another placeholder object, say obj.thing. But what if someone wants to get a div object by class name? Yet another placeholder object? For these placeholder objects to be available, you'd have to build them after the page loads fully but before any js needs them. That's a narrow window. And are you certain that the benefits from having these shortcuts would outweigh the permanent footprint on performance?

If you're confident that for your particular app, you'll always want the innerHTML whenever a div is referenced, then write your own one-line helper function to shorten things a bit more. But I don't think it's easy to outdo something like jQuery in terms of universal applicability. Some very sharp folks have been honing these libraries for many years now…
20 Jan, 2012, Deimos wrote in the 5th comment:
Votes: 0
I don't understand the point in the syntax "doc.thing". You seem to lose quite a bit of flexibility just to save a few keystrokes. As plamzi pointed out, how do you do things like change the color of "thing"? If "doc.thing" is its value, the you can't really do "doc.thing.color" or similar.
20 Jan, 2012, Cratylus wrote in the 6th comment:
Votes: 0
I'm not sure I understand what problem this solves.

It seems like you just don't like how js looks and want something simpler.

Why not just use something simpler?

If yer just futzing around for fun, then go nuts, of course.

-Crat
http://lpmuds.net/derive.jpg
20 Jan, 2012, Runter wrote in the 7th comment:
Votes: 0
Coffeescript is a fine language. Compiling to js is the best strategy to solve this problem if you actually want users to be able to access your software without installing browser plugins. The compiling process actually streamlines the code, can add multiple files and modules together, can minify the code, and can ensure safety javascript doesn't demand. Like that lines of code are always compiled with ; at the end. Incidentally, this is a notorious source of difficult to find problems in javascript. The bottom line is there's compelling reason to use something like coffeescript.

And even much more so something like cscc, which compiles to css. But that's another story.
20 Jan, 2012, David Haley wrote in the 8th comment:
Votes: 0
There are tons of extremely reasons for simplifying syntax if your needs are simpler than what the syntax addresses. "Saving a few keystrokes" means more than saving a little time here or there. For example, it's that much less noise to keep in your head and you can focus on what you mean, not the ceremony and incantations around saying what you mean. But even if it meant just saving time, if my programs are 50% shorter, that's pretty considerable time savings.

No comment regarding this particular case because it's unclear what's motivating it, but I strongly reject the idea that saving on syntax is silly – even when you lose flexibility. (Smart syntax will let you express simple things simply, and give you a way to say more complex things.)
21 Jan, 2012, Rarva.Riendf wrote in the 9th comment:
Votes: 0
If saving a few keystroke meant anything variable names would all be 1 or 2 caracter long….Saving on syntax for the sake of it is silly

C/Java whatever :
if (toto and tata or titi) {
return "end";
}
is definitely more readable than the Lua version where you saved a few keystroke..

if toto and tata or titi
return "end"
end
21 Jan, 2012, Chris Bailey wrote in the 10th comment:
Votes: 0
That might be the most subjective thing I have seen from you. Not only is it a stretch to say that saving on syntax is silly, it is nuts to say that your first example is definitely more readable than the second. Surely you have them backward?

Rarva.Riendf said:
If saving a few keystroke meant anything variable names would all be 1 or 2 caracter long….Saving on syntax for the sake of it is silly

C/Java whatever :
if (toto and tata or titi) {
return "end";
}
is definitely more readable than the Lua version where you saved a few keystroke..

if toto and tata or titi
return "end"
end


EDIT: PS: Variable names are meant to be expressive.
21 Jan, 2012, David Haley wrote in the 11th comment:
Votes: 0
Rarva, you have reduced the point to such an absurdity that of course it sounds silly. Do you want to come back to the actual point now? :smile:
21 Jan, 2012, Runter wrote in the 12th comment:
Votes: 0
race = (winner, runners…) ->
print winner, runners


race = function() {
var runners, winner;
winner = arguments[0], runners = 2 <= arguments.length ? __slice.call(arguments, 1) : [];
return print(winner, runners);
};


Clearly, the javascript is more readable, and saving key strokes is for newbs.
21 Jan, 2012, Chris Bailey wrote in the 13th comment:
Votes: 0
Rarva has broken away from the pack and taken a commanding lead in the race to crippling carpal tunnel syndrome.
22 Jan, 2012, Twisol wrote in the 14th comment:
Votes: 0
JohnnyStarr said:
The only way to include the new language scripts that I can see, would be to use a div with an id that has a style set
by calling the language library.

<script type="text/javascript" src="new_language.js" /> 
// set's the style of new_language to: 'display: none;'

<div id="new_language">
alert doc.thing
</div>


Then, on load you could execute the script:

<body onload="new_lang_execute()">


Which looks for the id's innerHTML and does the rest for you.


You can completely avoid the hackery with invisible divs by putting code for your new language in a <script> tag with a different type attribute.
<script type="text/javascript" src="/path/to/newlang.js">

<script type="application/x-newlang">
// code using your new language here
</script>

This is the same technique CoffeeScript supports.
22 Jan, 2012, Deimos wrote in the 15th comment:
Votes: 0
@David: Of course if all he needs is to juggle element values then "limiting" the syntax to what he is suggesting makes sense, but I don't buy that that is the entirety of the use case. And even if it's not, are you really in disagreement that creating an all new language just so you can use "obj.thing" syntax instead of "obj.thing.value" is bordering on the absurd? Maybe I was being too kind when I suggested that he'd be losing a little flexibility - more like all flexibility :-p
22 Jan, 2012, Runter wrote in the 16th comment:
Votes: 0
Deimos said:
@David: Of course if all he needs is to juggle element values then "limiting" the syntax to what he is suggesting makes sense, but I don't buy that that is the entirety of the use case. And even if it's not, are you really in disagreement that creating an all new language just so you can use "obj.thing" syntax instead of "obj.thing.value" is bordering on the absurd? Maybe I was being too kind when I suggested that he'd be losing a little flexibility - more like all flexibility :-p


I don't know how much value his specific language has, but the underlying technique he is discussing to create a new language is completely legitimate and effective. I think David was pointing out the absurdity of dismissing simplifying syntax in general. Not this specific case. In other words, he's saying it's not always a bad idea… And that's what it seems like others have postulated. And I agree with him.
22 Jan, 2012, David Haley wrote in the 17th comment:
Votes: 0
Runter said:
I think David was pointing out the absurdity of dismissing simplifying syntax in general. Not this specific case. In other words, he's saying it's not always a bad idea… And that's what it seems like others have postulated. And I agree with him.

Yes, exactly.

Deimos said:
And even if it's not, are you really in disagreement that creating an all new language just so you can use "obj.thing" syntax instead of "obj.thing.value" is bordering on the absurd?

That's not the exact thing that he was doing, but regardless, I was assuming that there was going to be more to the story.

Even so, if an operation is extremely common, then no, it's not really absurd to have a language derivative that lets you simplify the syntax for that particular operation. You can see this happening in the evolution of C++ and Java; for instance, the auto type that lets you say "just give me the damn variable and you know what the type is". (And of course, other things were happening too.)
22 Jan, 2012, Rarva.Riendf wrote in the 18th comment:
Votes: 0
David Haley said:
Rarva, you have reduced the point to such an absurdity that of course it sounds silly. Do you want to come back to the actual point now? :smile:


Was just sayig that saving on syntax is often possible, (and done) as my example was showing.
I actually prefer the visual clue of () to limit a test case, a ; to end a line (as you have sometimes multiple line because of wrapping even if it is only one line of code) and {} to limit code block, and not some text that blend with everything else (even if colored in an IDE)

And for Runter: I hate everything about Javascript anyway…including its syntax.
22 Jan, 2012, David Haley wrote in the 19th comment:
Votes: 0
Rarva said:
Was just sayig that saving on syntax is often possible, (and done) as my example was showing.

Well, you also said that reducing syntax was just changing variable names to be 2-4 characters long, which is a non-sequitur.

All your example showed is that one language has more symbols than the other for delimiting blocks and expressions. It wasn't really showing any interesting syntax changes per se.
22 Jan, 2012, Rarva.Riendf wrote in the 20th comment:
Votes: 0
David Haley said:
Well, you also said that reducing syntax was just changing variable names to be 2-4 characters long, which is a non-sequitur.
All your example showed is that one language has more symbols than the other for delimiting blocks and expressions. It wasn't really showing any interesting syntax changes per se.


I did not say that:I said that saving keystroke was not a goal And my example was about saving keystroke.
(The fact you do no find this change in syntax interesting is your opinion, I find it very annoying to read Lua code because of those lack of delimiters)
Sometimes verbose syntax can be useful to be able to concetrate on the mean, because this way you dont have think of everything that is implied instead of stated. The difficulty is to find a good middle ground.
0.0/30