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)
- 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.
On Sat, Oct 1, 2011 at 7:19 PM, Dominic Tarr <dominic.t...@gmail.com> 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?
> 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)
> 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)
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".)
On Sat, Oct 1, 2011 at 10:23, Fedor Indutny <fe...@nodejitsu.com> wrote: > 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
> On Sun, Oct 2, 2011 at 12:19 AM, Dominic Tarr <dominic.t...@gmail.com> > 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? >> 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)
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).
>> 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 :)
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
On Oct 1, 6:00 pm, Isaac Schlueter <i...@izs.me> wrote:
> >> 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 :)
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); }
}); On Sat, Oct 1, 2011 at 6:00 PM, Isaac Schlueter <i...@izs.me> wrote: > >> 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 :)
> 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".)
> On Sat, Oct 1, 2011 at 10:23, Fedor Indutny<fe...@nodejitsu.com> wrote: >> 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
>> On Sun, Oct 2, 2011 at 12:19 AM, Dominic Tarr<dominic.t...@gmail.com> >> 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? >>> 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)
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, > 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
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.
On Sun, Oct 2, 2011 at 8:16 PM, Dominic Tarr <dominic.t...@gmail.com> wrote:
> 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:
> 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.
On Sat, Oct 1, 2011 at 7:19 PM, Dominic Tarr <dominic.t...@gmail.com> 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?
> 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)
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.
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 <bjouh...@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 <lordma...@gmail.com> wrote: > namely, blocks and "method_missing?" - with a large emphasis on > method_missing?.
On Sun, Oct 2, 2011 at 5:44 PM, Isaac Schlueter <i...@izs.me> wrote: > 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 <bjouh...@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 <lordma...@gmail.com> > wrote: > > namely, blocks and "method_missing?" - with a large emphasis on > > method_missing?.
On Sun, Oct 2, 2011 at 17:37, Dean Landolt <d...@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.
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 <d...@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()
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.
On Mon, Oct 3, 2011 at 2:43 PM, Dean Landolt <d...@deanlandolt.com> wrote:
> 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 <d...@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 })
> 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.
On Mon, Oct 3, 2011 at 8:33 PM, Mark Hahn <m...@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?
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.)
On Mon, Oct 3, 2011 at 18:45, Dean Landolt <d...@deanlandolt.com> wrote:
> On Mon, Oct 3, 2011 at 8:33 PM, Mark Hahn <m...@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?
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?
> 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?
On Mon, Oct 3, 2011 at 7:52 PM, Dean Landolt <d...@deanlandolt.com> wrote:
> 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?
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.
