[nodejs] meta-programming?

[Dominic Tarr]

hey,

it just occurred to me that I don't hear the phrase 'meta-programming' much any more. 

I don't hear it because I don't do ruby anymore. nodians do not use this phrase.

I wonder why? any theories?

is it because javascript has more powerful constructs*, and thus it just seems like it ain't no thing?

(*or rather, I suspect, that ruby is crippled by it's sugary syntax)

[Nuno Job]

Hi Domenic,

I see two reasons:

• With so many closures and functions being passed around the necessity for evals diminuishes
• Less is more is kind of a hidden guideline in node. Simplicity is appreciated and projects that do very simple things very well (like request) are what the community thrives on. In Ruby the community cares more about abstractions and DRY and stuff, which often makes them construct abstractions that you can use easily but can't understand in a million years. In node it's normally either I understand the source code, or I don't use it.

Nuno

--
Job Board: http://jobs.nodejs.org/
Posting guidelines: https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines
You received this message because you are subscribed to the Google
Groups "nodejs" group.
To post to this group, send email to nod...@googlegroups.com
To unsubscribe from this group, send email to
nodejs+un...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/nodejs?hl=en?hl=en

[Fedor Indutny]

Dominic,

I think meta-programming is a ruby trend, but anyway javascript and, of course, node supports it.

Just no one here is doing a big accent on it.

Fedor Indutny

Engineer

Nodejitsu, Inc.

fe...@nodejitsu.com

--

[Isaac Schlueter]

Dominic,

It's because ruby rots people's brains. It is the programming
language equivalent of high fructose corn syrup -- tasty at first, and
then you get overweight, and can't run fast any more, and anything
healthy seems gross to you.

Javascript might not be healthy, but it's slightly less poisonous.

"Meta-programming", in my experience, is usually a fancy term for
"programming badly".

(We *do* have such a thing in node, it's called "flow control libraries".)

[Dean Landolt]

On Sat, Oct 1, 2011 at 1:35 PM, Isaac Schlueter <i...@izs.me> wrote:

Dominic,

It's because ruby rots people's brains.  It is the programming
language equivalent of high fructose corn syrup -- tasty at first, and
then you get overweight, and can't run fast any more, and anything
healthy seems gross to you.

 

I just want to jump in and say not all metaprogramming is bad. Perhaps it's a scourge in rubyland (I'm no rubyist so I wouldn't know), but generic programming is a form of metaprogramming and it's certainly not brain-rotting. Some would say the same about scheme's hygienic macros (Brendan Eich has said javascript won't be "done" until it gets hygienic macros). Dependent types are also a promising idea. Sure, metaprogramming in javascript, at least for now, pretty much means a eval or a preprocessor -- corn syrup in the best cases -- but let's not paint all metaprogramming with ruby's brush.

 

Javascript might not be healthy, but it's slightly less poisonous.

"Meta-programming", in my experience, is usually a fancy term for
"programming badly".

(We *do* have such a thing in node, it's called "flow control libraries".)

Are you saying using a flow control library makes you program badly? I'd buy that but I'd qualify it by adding that it's one you don't fully understand (read: one you haven't written or hacked on the internals of).

[Isaac Schlueter]

>> Javascript might not be healthy, but it's slightly less poisonous.
>>
>> "Meta-programming", in my experience, is usually a fancy term for
>> "programming badly".
>>
>> (We *do* have such a thing in node, it's called "flow control libraries".)
>
> Are you saying using a flow control library makes you program badly? I'd buy
> that but I'd qualify it by adding that it's one you don't fully
> understand (read: one you haven't written or hacked on the internals of).

Not all flow control libraries make you program badly. However, the
more a library obscures the intent or logic of the programs using it,
the more it should be called "bad".

The reason that I see a corollary here is that metaprogramming, DSLs,
and flow-control often act as a magnet for attention and effort,
dramatically in excess of the value they provide. If you're doing
"metaprogramming", or writing a DSL, or a flow-control library, or a
test framework, I think you should do as little as possible, as fast
as possible, as simply as possible, and get back to real work, and
never ever touch it again. Otherwise it's just make-work.

Not everyone agrees with me on this point, and that's fine :)

[Scott Taylor]

You could spend a while debating whether metaprogramming / dynamicity
in a programming language is itself a good or bad thing. Personally,
I like to have it, and don't want others to (because it's easily
abused)!

But (IMHO), you don't hear about it much for several reasons:

1. People in the JS community don't care that much about being super
DRY code. I have the feeling that most of them come from less
"powerful" languages. (DRY itself is a mixed bag - usually a good
thing, sometimes a terrible thing.)

2. The ones that do care more have either given up the ability to do
extra powerful things, or are looking at javascript generating
languages like CoffeeScript or Parenscript.

3. JS doesn't have as many powerful abstractions, and the ones it does
have are being phased out in ECMA 5 (for some good reasons). Consider
instance_eval / instance_exec in ruby. Eval'ing a block (lambda) in
some other context is super easy in ruby, but in JS it's now almost
impossible (as with and Function#callee are deprecated and will throw
errors in ECMA 5 strict).

4. Closures are, (aside from any syntactic sugar reasons), one of the
most powerful abstractions you could have. They are also more "first
class" in JS: creating a method in JS is just creating a lambda, where
in ruby, it isn't (unless you were to use define_method).

5. Ruby doesn't have real macros (like lisp macros) - so most of
Ruby's macros are _generational_ instead of _transformative_ (i.e.
they generate code instead of transforming existing code). But most
of these code generation abilities are simply getting around issues
with the object system. Consider the dynamic methods on Object in
ruby (#*methods, #define_method, #instance_variable_*, #extend,
#*send*, #respond_to?, etc): there is absolutely no need for these
methods in JS because of the prototype system and the convenient hash
syntax (Object#methods in ruby === writing a for loop inspecting
properties, send(:foo) in ruby === obj["foo"]() etc). Same goes for
Method, UnboundMethod, Binding, etc.

So - my conclusion is that it's a bit of both. JS is missing some of
Ruby's dynamic methods, but it has a lot of hidden power in it's
object as a hash (prototype) system. This doesn't mean that it's less
powerful than Ruby - just that it *appears* so because you don't have
to jump through any hoops to do something super dynamic like
define_method.

As far as metaprogramming goes in the JS community, I have the feeling
that the real promise lies in the CoffeeScript movement, but as of yet
it doesn't look like they have more powerful macros (lisp macros) and
often sell themselves as simply a JS without as much pain (no
semicolons, forward declarations of variables, etc).

Best,

Scott

[Stewart Mckinney]

Dominic,

The primary reason you don't hear "meta-programming" around the node community is because Javascript doesn't feature two primary constructs (present in Ruby) that are critical to good and worthwhile meta-programming; namely, blocks and "method_missing?" - with a large emphasis on method_missing?.

The combination of blocks and method_missing is what provides the language with the ability to create very flexible DSL's; the most common pattern of which is creating a method that yields a special "meta-class" to a block, like in
this simple (contrived) example that would produce a stylesheet/style tag for a HTML element:

my_collection.style do |meta|
 meta.float = left
 meta.left = 5
 meta.right = 5
 meta.padding-left = 50px
end

..assuming of course my_collection was an instance of an object that had the method "style" defined, and yielded the block passed to it a "StyleBuilder" object with a method_missing? call that takes any undefined method name and
simply appends it to a string which contains an element's style information.

Pure eval isn't the core of meta-programming in Ruby; in fact, generally speaking, the worst meta-programming is done in this way. Most (decent) meta_programming is done via class_eval and instance_eval as a last resort with nested
"define_method" calls.

Keep in mind you can still do similar eval-y "meta-programming" things in Javascript...using jQuery, here:

var obj = {}

$.each([0,1,2], function(i,el){ //hate this about jQuery, wish each and map had the same argument list
  obj[i+"_function"] = function(){ //accessing property of the array in [] form, so we can use 'dynamically named' functions
    alert(el);
  }
});

[fernando trasvina]

Meta-programming its bad for you don't use it, design good APIS and you
should be good.

[Dominic Tarr]

On Sun, Oct 2, 2011 at 4:35 AM, Isaac Schlueter <i...@izs.me> wrote:

Dominic,

It's because ruby rots people's brains.  It is the programming
language equivalent of high fructose corn syrup -- tasty at first, and
then you get overweight, and can't run fast any more, and anything
healthy seems gross to you.

Javascript might not be healthy, but it's slightly less poisonous.

"Meta-programming", in my experience, is usually a fancy term for
"programming badly".

(We *do* have such a thing in node, it's called "flow control libraries".)

hey! I've read your code, (learnt a lot!) 

npm uses two different control flow libraries:

chain: https://github.com/isaacs/npm/blob/master/lib/build.js#L50-58 

and promise-chain: https://github.com/isaacs/npm/blob/master/lib/init.js#L61-176

now I think the important thing here is that you have used each control flow libraries in the appropriate situation.

and at other times, do not use a control flow library.

[Branko Vukelić]

On 2011-10-02 04:19 +1100, Dominic Tarr wrote:
> hey,
> it just�occurred�to me that I don't hear the phrase 'meta-programming'
> much any more.�
> I don't hear it because I don't do ruby anymore. nodians do not use this
> phrase.
> I wonder why? any theories?

There are a few reasons. First and foremost, meta-programming has as
many definitions as there are people who don't know what it means.
Second, JavaScript is a functional language, so you don't really need
it even if you knew what it meant.

--
Branko Vukelic
bra...@brankovukelic.com
bra...@herdhound.com

IDEA MACHINE
www.brankovukelic.com

Lead Developer
Herd Hound (tm) - Travel that doesn't bite
www.herdhound.com

Love coffee? You might love Loveffee, too.
loveffee.appspot.com

[Dominic Tarr]

perhaps the reason there is this "thing" called meta-programming in ruby is because the ways in which it is accomplished are all querks of ruby.

I trace it all back to how ruby does not require parentheses around function args.

so you can do `object.functionName` and that is like in `object.functionName()` in js. great huh? you save typing two characters that are right next to each other on the keyboard. 

which means that since you can't just return a function by going return `object.functionName` so there has to be another syntax for that, and so ruby's hubris undoes itself, by creating all these additional syntaxes to attempt to reclaim what was lost by dropping parenthesis.

so in conclusion. in js you things like higher order functions, which actually have a defined name, hardly need to be talked about. because they are so simple.

funny then, how ruby has become so popular...

[Bruno Jouhier]

> The reason that I see a corollary here is that metaprogramming, DSLs,
> and flow-control often act as a magnet for attention and effort,
> dramatically in excess of the value they provide.  If you're doing
> "metaprogramming", or writing a DSL, or a flow-control library, or a
> test framework, I think you should do as little as possible, as fast
> as possible, as simply as possible, and get back to real work, and
> never ever touch it again.  Otherwise it's just make-work.
>
> Not everyone agrees with me on this point, and that's fine :)

"As little as possible, as fast as possible, as simply as possible,
and get back to real work". I fully agree with you.

"Never ever touch it again". I would not be that strict. You may have
to fix edge cases, optimize, etc. As long as this does not change the
usage, this is fine.

Bruno

[Marak Squires]

I use to say, "I can bend space and time with .toString() and eval()".

I've come to realize that it's generally better to not bend space and time in JavaScript.

- Marak

--

[Alexey Petrushin]

Because just making JS working right is already very big thing and You are so happy about it, even if it's dirty and bloated. 

You just don't even think about metaprogramming.

[Isaac Schlueter]

PromiseChain is a mistake that I regret bringing into this world.
It's a relic from the days when npm had a lot of "var p = new
node.Promise", retrofitted (inconsistently and badly) to work with
callbacks. It's only used in a few places, and if anyone wants to
send me a pull req that eradicates it, I'll be grateful. But, messing
with it (or worse yet, improving it) is just not worth the time and
attention.

"chain(list, cb)" is one of three functions that the "slide" library
exports. It's 20 lines long (about the right size for a flow-control
utility), does exactly what it looks like, and I hardly ever have to
touch it or look at it. "slide" is so-named because I derived it live
at OakJS, so every piece of it fits on a slide presentation.

I never meant you shouldn't *use* flow-control libraries. What I
meant was simply that every second *spent* on a flow control library
-- whether writing one or figuring out how to use it -- must be viewed
as a cost, and is usually not worth it. I don't spend my time pimping
slide because I don't care if you use it or not. In fact, I'd
slightly rather you didn't, because then you might be tempted to mess
with the code and send me pull requests, and then we'd have to have a
whole conversation about it, when there are much more interesting
problems to solve.

Metaprogramming, in my experience, is similar. Either it's something
you just do, because it happens to be the simplest and most obvious
way to solve a problem and you might not even think to call it
"metaprogramming", or it's something you waste a bunch of time messing
around with, because it's hip and fun and makes you feel smart.
Programs like that are fun to write, but they are seriously
infuriating to use. Every time I have to interact with some silly
DSL, I have to work hard to contain the seething resentment. Isn't it
bad enough that we need to know JavaScript and C and C++ and HTML and
CSS, and all the browser and system quirks, now you're adding *more*
complexity, just to make it *pretty*?

Maybe this is the part where I shake my cane at the ruby kids on my
lawn, but that kind of thing just doesn't seem very interesting to me.

Programs that solve a real problem with an elegant api, now *that's* exciting.

On Sun, Oct 2, 2011 at 05:02, Bruno Jouhier <bjou...@gmail.com> wrote:
> "Never ever touch it again". I would not be that strict. You may have
> to fix edge cases, optimize, etc. As long as this does not change the
> usage, this is fine.

I've fixed a few typos in slide. But that's about it.

On Sat, Oct 1, 2011 at 15:40, Stewart Mckinney <lord...@gmail.com> wrote:
> namely, blocks and "method_missing?" - with a large emphasis on
> method_missing?.

ES-Harmony adds both features. :’(

[Dean Landolt]

Blocks ain't in yet.

[Isaac Schlueter]

On Sun, Oct 2, 2011 at 17:37, Dean Landolt <de...@deanlandolt.com> wrote:
>> > namely, blocks and "method_missing?" - with a large emphasis on
>> > method_missing?.
>>
>> ES-Harmony adds both features.  :’(
>
> Blocks ain't in yet.

Oh, really? I thought it was just a matter of minor details at this
point. Have there been new developments?

Proxy objects are a bit unfortunate, imo, but I guess if you want to
really emulate a DOM in JS (which is regrettably necessary in some
cases), they're necessary.

[Dean Landolt]

On Sun, Oct 2, 2011 at 10:44 PM, Isaac Schlueter <i...@izs.me> wrote:

On Sun, Oct 2, 2011 at 17:37, Dean Landolt <de...@deanlandolt.com> wrote:
>> > namely, blocks and "method_missing?" - with a large emphasis on
>> > method_missing?.
>>
>> ES-Harmony adds both features.  :’(
>
> Blocks ain't in yet.

Oh, really?  I thought it was just a matter of minor details at this
point.  Have there been new developments?

 

IIRC /be's working simultaneously on blocks and the -> function-shortening sugar. There are some problems with the -> syntax for parsing, and implicit return is out because of its potential to accidentally leak capabilities.

On the other hand blocks have some weird TCP implications, and otherwise introduce completely distinct semantics from the traditional functions we know and love. They're a new construct entirely -- which could be a good thing, but may already enough to doom them. And I can't imagine anyone really cares for the syntax.

Personally I think they both stink. I wish they'd just alias function with some esoteric character like florin (ƒ) and be done with it. Those of us that can't be bothered to map florin on our keyboards (or use opt-f on a mac) will continue typing "function" like suckers (we seem to be doing just fine with those 8 chars so far...)

I tried to make the case for florin a few weeks back to /be -- he countered that without shortening return it's not as big of a win. It took just long enough for him to walk away for me to conclude that we could do the same damn thing with return -- pick another esoteric (but pretty, and mathematically appropriate) unicode character. Too bad the colon's ambiguous -- it's just about right from a math standpoint. I really like how the standard rightwards array (→) looks -- this example, adapted from npm/lib/search.js):

opts.concat(args).map(function (s) {

  return s.toLowerCase()

}).filter(function (s) { return s })

Turns it into this:

opts.concat(args).map( ƒ(s) { → s.toLowerCase() } ).filter( ƒ(s) { → s } )

Not bad, eh? You could even make the space optional and save another byte per return. Of course, using the arrow may turn off some math heads and confuse the coffeescripters, so maybe the arrow isn't perfect. I'm sure we could come up with something...

And in the terribly unlikely event you've got code using these symbols today you'll have a negligible migration tax when moving to es-next. Big freakin' deal. This looks great, a solid win for readability all around; a solid win for devs that map the characters; a win for minifiers; and I'd think it would be a whole lot easier for the committee (and community) to swallow since it changes nothing about the language.

So, umm, if anybody else is down with this, take some of that passion the node community boils over with and bring it to the es-discuss list to make the case before it's too late :D

 

Proxy objects are a bit unfortunate, imo, but I guess if you want to
really emulate a DOM in JS (which is regrettably necessary in some
cases), they're necessary.

Yep. They've got their use cases for sure, but I hear you re: their pitfalls. Hopefully the javascript community's far enough along in its evolutionary path sans catchalls to swallow a whole cup of catchall koolaid. At the very least, we may be able to use the total Proxy count metric as a proxy for code quality.

[Mark Hahn]

The arrow should point left for a return.

--

[Dean Landolt]

On Mon, Oct 3, 2011 at 8:33 PM, Mark Hahn <ma...@boutiquing.com> wrote:

The arrow should point left for a return.

Damn, this occurred to me on the drive home and I was hoping I wouldn't get beaten to it :)

But now that I've got your attention: what do you think of this ƒ/← pairing? Do you think it's worth broaching with es-discuss? Do you see any problems other the obvious issue of these chars are reserved?

[Isaac Schlueter]

ƒ and ← are cute, but a pain to type.

The "just make your editor do it for you" argument is not very
convincing. *Having* to use vim means that it's harder to discuss
programs online, which is where a lot of highly interesting
code-writing actually happens.

Programming languages ought to be limited to the characters on
keyboards used by programmers (ie, latin characters and common
punctuation. Blah blah chauvinism, I know, but that's how the
demographics are today.)

[Dean Landolt]

On Mon, Oct 3, 2011 at 9:58 PM, Isaac Schlueter <i...@izs.me> wrote:

ƒ and ← are cute, but a pain to type.

The "just make your editor do it for you" argument is not very
convincing.  *Having* to use vim means that it's harder to discuss
programs online, which is where a lot of highly interesting
code-writing actually happens.

Programming languages ought to be limited to the characters on
keyboards used by programmers (ie, latin characters and common
punctuation.  Blah blah chauvinism, I know, but that's how the
demographics are today.)

You insensitive, ethnocentric bastard ;)

But seriously, this argument falls apart when you acknowledge that every operating system offers ways to remap key combinations. This wouldn't force you into a particular editor to take advantage of these shortcuts. There's also copy/paste. But more importantly, you'll always have access to those good old "f", "u", "n", "c", "t", "i", "o", "n", "r", and "e" keys. So you're good to go.

The more important question IMHO is whether it's easier (or just as easy) to read. This is the optimization problem to solve, and it's completely independent of whether or not you have the ability to type some character. To my eyes this is pretty winful. What say you?

[Tim Smart]

Just bind whatever you like to a shortcut in your text editor :)

Tim.

--

[Martin Cooper]

I find that I can very quickly read code and identify functions within
it because the word 'function' is more than one or two characters and
jumps out at me because it's green on black. If it was just one
character, no matter which character, it would be much harder to
instantly spot a function hiding in a chunk of code. One-character
keywords will be hard to spot in most colour schemes.

Faced with your earlier example and no syntax highlighting, to me it's
close to six and half a dozen. Add syntax highlighting to the mix and
I actually find the lengthier example easier to read and comprehend.

--
Martin Cooper

[Bradley Meck]

ƒ , # , whatever you replace "function" with should follow some sane rules:

1. Don't rely on implementation / utf8 bom: aka notepad.exe better not barf.

2. It should be easily accessible via the keyboard somehow rather than requiring text macros or alt+1337 etc. Changing keyboard setting on an application level may be fine (APL) but doing it globally so that google/bing/etc. quick lookups means swapping back is unacceptable. Creating key mappings is fine and dandy, but your operating system better offer a way to move that to new machines easily for people picking it up (not all of us like the VIM / EMACS way when we also want to be able to type).

3. It should be at least as readable as "function"; # has connotations both in generic symbolism and in programming.

4. It should be a sane unicode symbol, looking up "florin" is not what the person is going to do when they see its talking about a function and go to the character map (seriously, why do we even need to go to the character map?). Most unicode fonts don't even support florin or the function symbol  ( http://www.fileformat.info/info/unicode/char/2394/index.htm ) so we are stuck with programmer fonts only (which most do not support these anyway).

5. You will have to convince people that for all these problems it makes it not just more readable; but also saves time (alt+1337 != time saved, basically anything with a keypress distance bigger than 1 from the home row will be a hard sell), because it already is readable.

I personally find arguments like this to be about as logical as: math uses a single letter for variables, we can too!... Symbols distinguishing programming language constructs from ascii have traditionally been ignored and the existing ascii based languages are the convention for computing. Math has different conventions and its own set of troubles with readability and writability due to usage of symbols. While there may be a desire for a shortened syntax, the need for a keyword in a language is going to have trouble if it goes outside of ascii (unless you go all the way and provide an IDE like APL).

[Isaac Schlueter]

Bradley, you pretty well summed up my feelings on the matter in much
more detail. Thanks :)

[Mark Hahn]

You guys are taking all the fun out of it.

I've daydreamed about languages that don't use ascii.  I haven't actually designed one yet, but I've thought that there has to be some symbolic (graphic) version of a language that is more readable than ascii.

I've also spent time thinking that the syntax of a language should be independent of the semantics.  I gave a presentation on this once.  The idea is that one person could write in one syntax and another could read the same source in a different syntax of their choice.  This is not a good example, but it would be cool if I could write coffeescript in my editor and then someone else would pull it up in javascript, add some code, and then I could pull it back up in coffeescript.

[Dominic Tarr]

this thread is swelling nicely!

whether or not a language uses function a florin, --> or whatever else is nearly completely unimportant with respect to how useful the language actually is.

you could always get your editor to abbreviate function to florin and return to <--, etc. or whatever makes you feel clever, without having to convince anyone else that it's a good idea.

personally, I'm against changing js at all. It's only this good on accident, and it's better than all those other languages for being smaller.

make faster/smarter interpreters, but it's impossible to make rational decisions about what "better" syntax is. so just leave it.

[Dean Landolt]

On Tue, Oct 4, 2011 at 3:50 AM, Dominic Tarr <domini...@gmail.com> wrote:

this thread is swelling nicely!

whether or not a language uses function a florin, --> or whatever else is nearly completely unimportant with respect to how useful the language actually is.

 

This is provably false...

 

you could always get your editor to abbreviate function to florin and return to <--, etc. or whatever makes you feel clever, without having to convince anyone else that it's a good idea.

personally, I'm against changing js at all.

If es5 suites your fancy than you're in luck -- it's already here.

 

It's only this good on accident,

This is a pretty naive view.

 

and it's better than all those other languages for being smaller.

 

Now this I buy.

 

make faster/smarter interpreters, but it's impossible to make rational decisions about what "better" syntax is. so just leave it.

Again, I call bullshit -- it's not hard to imagine quantitatively bad syntax.

[Dean Landolt]

On Mon, Oct 3, 2011 at 11:39 PM, Bradley Meck <bradle...@gmail.com> wrote:

ƒ , # , whatever you replace "function" with should follow some sane rules:

1. Don't rely on implementation / utf8 bom: aka notepad.exe better not barf.

2. It should be easily accessible via the keyboard somehow rather than requiring text macros or alt+1337 etc. Changing keyboard setting on an application level may be fine (APL) but doing it globally so that google/bing/etc. quick lookups means swapping back is unacceptable. Creating key mappings is fine and dandy, but your operating system better offer a way to move that to new machines easily for people picking it up (not all of us like the VIM / EMACS way when we also want to be able to type).

3. It should be at least as readable as "function"; # has connotations both in generic symbolism and in programming.

4. It should be a sane unicode symbol, looking up "florin" is not what the person is going to do when they see its talking about a function and go to the character map (seriously, why do we even need to go to the character map?). Most unicode fonts don't even support florin or the function symbol  ( http://www.fileformat.info/info/unicode/char/2394/index.htm ) so we are stuck with programmer fonts only (which most do not support these anyway).

This is a great point -- I suspect florin's got pretty broad support but it may not be broad enough.

 

5. You will have to convince people that for all these problems it makes it not just more readable; but also saves time (alt+1337 != time saved, basically anything with a keypress distance bigger than 1 from the home row will be a hard sell), because it already is readable.

 

I don't have to convince people of anything. I'm personally not convinced shorter function syntax is necessary -- I type pretty fast myself, and I'm also partial to Martin's argument that `function` and `return` are really easy to spot. But if the committee wants to do it my argument was that it's best to do it by simply mapping characters, rather than introducing a whole new syntactical structure.

 

I personally find arguments like this to be about as logical as: math uses a single letter for variables, we can too!... Symbols distinguishing programming language constructs from ascii have traditionally been ignored and the existing ascii based languages are the convention for computing. Math has different conventions and its own set of troubles with readability and writability due to usage of symbols. While there may be a desire for a shortened syntax, the need for a keyword in a language is going to have trouble if it goes outside of ascii (unless you go all the way and provide an IDE like APL).

--

[Dominic Tarr]

Dean, 

what I mean that it is "nearly completely unimportant" is that anyone really thinks it's a good idea to use a florin instead of "function" can just do that, it's trivial to write a script to just replace one with the other.

here is a demonstration of basically how trivial:

https://gist.github.com/c93084ce119fa5ea95a9

what I mean by "by accident" is that there are many things that had they been different, js would not have ended up with the features that make it great for nodejs.

Like, it was written in 10 days. If Brendan Eich had more time he may have added more features. If javascript had been taken more seriously (it was Java that was taken seriously) then it may have been given a "proper" module system, or threads, or worst of all, been made yet more like java.

on one planned this, and if this non-plan didn't workout the way it did nodejs might have been noderb or something else...

[Isaac Schlueter]

On Tue, Oct 4, 2011 at 21:51, Dominic Tarr <domini...@gmail.com> wrote:
> here is a demonstration of basically how trivial:
> https://gist.github.com/c93084ce119fa5ea95a9

Erm. I think you'll find you can't, um, use florins in string
literals in florinscript.

That's probably a bug.

So.

[Dominic Tarr]

I accept pull requests.

[Charlie McConnell]

I'd way rather see the florin implemented at the syntax-highlighting level.  I type 'function', my editor changes it to a nice colored curly f to save me space.

I'll also take my bikeshed green, and my scotch with one ice cube and a splash of water.

--
Charlie McConnell

Support Engineer

Nodejitsu, Inc.

avia...@nodejitsu.com

[Dominic Tarr]

That is what this bikeshed needs! a BAR.

[Dean Landolt]

On Wed, Oct 5, 2011 at 4:50 AM, Charlie McConnell <cha...@charlieistheman.com> wrote:

I'd way rather see the florin implemented at the syntax-highlighting level.  I type 'function', my editor changes it to a nice colored curly f to save me space.

I'll also take my bikeshed green, and my scotch with one ice cube and a splash of water.

And that was kind of my point -- if we need shorter function syntax I'd much rather it be nothing more than a bikeshed -- and I happen to fancy the florin paint color...

Up until now noone had really come out of the woodwork against shorter function syntax of some sort -- it'd just been a matter of how. If you all care at all about this -- especially if you're against shorter function syntax of any sort -- you should probably take it up w/ es-discuss -- AFAIK there hasn't been much opposition to the idea in principle.

[aaronblohowiak]

https://github.com/aaronblohowiak/macros has an example of using "f"
instead of "function" in 4 lines of code that works with all the JS
that Uglify-JS supports (read: all JS.)

I don't use it, though. Why? Because it is another layer of
complexity.

On Oct 4, 9:51 pm, Dominic Tarr <dominic.t...@gmail.com> wrote:
> Dean,
>
> what I mean that it is "nearly completely unimportant" is that anyone really
> thinks it's a good idea to use a florin instead of "function" can just do
> that, it's trivial to write a script to just replace one with the other.
>
> here is a demonstration of basically how trivial:https://gist.github.com/c93084ce119fa5ea95a9
>
> what I mean by "by accident" is that there are many things that had they
> been different, js would not have ended up with the features that make it
> great for nodejs.
>
> Like, it was written in 10 days. If Brendan Eich had more time he may have
> added more features. If javascript had been taken more seriously (it was
> Java that was taken seriously) then it may have been given a "proper" module
> system, or threads, or worst of all, been made yet more like java.
>
> on one planned this, and if this non-plan didn't workout the way it did
> nodejs might have been noderb or something else...
>
>
>
>
>
>
>

> On Tue, Oct 4, 2011 at 9:39 PM, Dean Landolt <d...@deanlandolt.com> wrote:

>
> > On Tue, Oct 4, 2011 at 3:50 AM, Dominic Tarr <dominic.t...@gmail.com>wrote:
>
> >> this thread is swelling nicely!
>
> >> whether or not a language uses function a florin, --> or whatever else is
> >> nearly completely unimportant with respect to how useful the language
> >> actually is.
>
> > This is provably false...
>
> >> you could always get your editor to abbreviate function to florin and
> >> return to <--, etc. or whatever makes you feel clever, without having to
> >> convince anyone else that it's a good idea.
>
> >> personally, I'm against changing js at all.
>
> > If es5 suites your fancy than you're in luck -- it's already here.
>
> >> It's only this good on accident,
>
> > This is a pretty naive view.
>
> >> and it's better than all those other languages for being smaller.
>
> > Now this I buy.
>
> >> make faster/smarter interpreters, but it's impossible to make rational
> >> decisions about what "better" syntax is. so just leave it.
>
> > Again, I call bullshit -- it's not hard to imagine quantitatively bad
> > syntax.
>

[aaronblohowiak]

meta-programming in javascript is just called “programming” because
the methods used are familiar and used for non-meta-programming tasks,
unlike ruby which requires a large set of specialized knowledge that
is only used within the task of meta-programming.

I wrote up a bit more about this on my blog:
http://aaronblohowiak.com/meta-programming-in-javascript