23 Jan, 2012, David Haley wrote in the 21st comment:
Votes: 0
I'm not sure where I said that saving keystrokes for the sake of saving keystrokes was the only goal, but ok. I'm glad that we're agreed that making variable names be 2-4 characters is a little absurd.

And you don't really understand what I meant by interesting change in syntax. Something like what Runter gave is interesting. Or, having a for loop to construct a new list, vs. a list comprehension.
23 Jan, 2012, JohnnyStarr wrote in the 22nd comment:
Votes: 0
Perhaps it was a tall-order to expect everyone to infer what the derivative language was offering.
I was proposing more than the equivalent of C's typedef functionality - although I see that
I didn't do so effectively.

I'm glad that Runter and David seem to see some potential in the idea. My ultimate goal is to do
something that hasn't been done before to benefit the web community.
24 Jan, 2012, Chris Bailey wrote in the 23rd comment:
Votes: 0
What is the thing you are going to do that hasn't been done before? =)
24 Jan, 2012, Rarva.Riendf wrote in the 24th comment:
Votes: 0
David Haley said:
And you don't really understand what I meant by interesting change in syntax. Something like what Runter gave is interesting. Or, having a for loop to construct a new list, vs. a list comprehension.

I did, the world interesting is totally opinion based.
The syntax and everything about Javascript is awful anyway, so picking it as an example is like the Godwin of langage.
To get back to loop, most langage will have multiple way of doing them, but in the end, what really matters to me is not the few seconds I could win by typing a little less key, than the hours I will lose when I read code and try to see where it begins or end when I maintain code. Readibility is more important than some keystroke. Hence long variable Name. saving on syntax often means less visible visual clue about what the code does.

Javascript (bloody awful)
var txt = document.getElementById("thing").value;

what prevents you from creating a function get(value)
var txt = get("thing")

where function would be
get(xxx)
return document.getElementById(xxx).value;

Really….
24 Jan, 2012, David Haley wrote in the 25th comment:
Votes: 0
Rarva said:
I did, the world interesting is totally opinion based.

Like I said, and as I believe even more after reading your reply, I think you didn't. I was using more of a mathematical definition of "interesting". Adding a curly brace isn't really transformative. The list comprehension is a very different way of expressing things.

You keep talking about variable names as if that's what's relevant when discussing syntactic shortcuts. But you're the only one who seems to care about that and are the only one who keeps talking about it. Do you know what list comprehensions are? I think that if you had more experience in a bunch of languages, the argument would be very clear to you.

Rarva said:
The syntax and everything about Javascript is awful anyway, so picking it as an example is like the Godwin of langage.

I am amused that you talk so much about things being opinion-based and then you say something like this.
24 Jan, 2012, Runter wrote in the 26th comment:
Votes: 0
Rarva, that has nothing to do with the language syntax. That's a browser dom function and it's not part of the EMCAscript specification. So that was a terrible choice to use as an example since it's not even actually javascript but specific library implementation. Evidenced by the fact that you replaced it with perfectly valid javascript.

Furthermore, there's a lot to like about javascript, and frankly, I think for most purposes it's a superior tool to something like C.
25 Jan, 2012, Deimos wrote in the 27th comment:
Votes: 0
@David: Simplifying syntax is great, but you can't simplify it beyond a certain point without losing flexibility. In this case, he wants to be able to do "element" and that be the value, instead of "element.value", but how then do you access the actual element to do other things with it? In normal JS you can do "element.name", "element.type", "element.disabled", etc. If "element" is no longer the actual element, then you either lose the ability to do much of anything, or you have to provide alternate syntax.

I guess I just don't see the benefit, is all. Not for the cost, anyway.
25 Jan, 2012, Runter wrote in the 28th comment:
Votes: 0
Well, I agree this specific proposed change to the library isn't well thought out. Fundamentally the issue here is we're dealing with javascript objects:

obj = {
value: "lol",
somethingElse: "notLol"
};

console.log(obj.value);

/* incidentally can also, and often times must be, written */
console.log(obj["value"]);


So we can see that above that objects are basically associative arrays. Once one understands that the dom functions are actually just using the language object constructs it becomes much more clear why you need .value appended. Because value isn't dereferencing obj, it's actually just an attribute on the object.
25 Jan, 2012, Rarva.Riendf wrote in the 29th comment:
Votes: 0
Runter said:
Rarva, that has nothing to do with the language syntax. That's a browser dom function and it's not part of the EMCAscript specification. So that was a terrible choice to use as an example since it's not even actually javascript but specific library implementation. Evidenced by the fact that you replaced it with perfectly valid javascript.

Furthermore, there's a lot to like about javascript, and frankly, I think for most purposes it's a superior tool to something like C.

It is a superior tool to C, does not mean it is a nice langage. It has evolved to something it was not intended to do in the first place.

Quote
I am amused that you talk so much about things being opinion-based and then you say something like this.

Cause I do not deny it is my opinion, and I accept you can dismiss it as 'not being intersting' if you wish so…I am familar with C, Java, C++, Some Lua, Some Javascript, Old version of VisualBasic, Pascal, 68k Assembler, LISP…..You find brace and symbols are not interesting when you talk about syntax ? Well I hate to read C++ when I never know what + is actually doing….
The one I prefer from all that still is Java, but that does not mean it is a panacea (I think I would like C# better now from what I read about it). Because it is a quite naturally readable langage, you dont need to 'think' about every implied hided syntax or too complicated initialization mecanism to understand what it actually does. (every langage that changes their output depending on contex call are better left to the domain they are actually needed)
26 Jan, 2012, David Haley wrote in the 30th comment:
Votes: 0
Deimos said:
@David: Simplifying syntax is great, but you can't simplify it beyond a certain point without losing flexibility.

Sure. I never said that simplification never entails loss of flexibility. I did however say that sometimes you don't need that flexibility, but I am not sure if this particular case is such an instance.
20.0/30