_.m: A port of Underscore.js to Objective C(github.com)
github.com
_.m: A port of Underscore.js to Objective C
https://github.com/kmalakoff/_.m
34 comments
'Underscore.m' seems a lot nicer to me: http://underscorem.org/
I mean, what?
(edited; unwrapping is needed in both libraries)
I mean, what?
N* value = (N*) hash.getOrAdd(l, ^{ return N.I(0); });
(edited; unwrapping is needed in both libraries)
Agreed, I hadn't seen this library before.
fwiw, I do like seeing a variety of libraries - they occasionally come to the same kind behavior through different techniques. It's a fun way to get a deeper knowledge of the language.
For a more Objective-C-ish take on these sorts of functional idioms, have a look at Higher Order Messaging:
myStrings = @[ @"hello" @"world" ];
upperCase = [[myStrings collect] upperCaseString];
myInts = @[ @1 @2 @3 ];
sum = [myInts reduce] add:@0];
[[self onMainThread] doSomething];
[[delegate ifResponds] delegateMessage];
Wow, I just found out about Higher-Order Messaging. This is pretty awesome.
Here are some links for more info:
As an aside, I like to use my own [ATFunctionalCollectionExtensions][] for this purpose, which is a blocks-based implementation of map, reduce, inject, each, and filter.
[ATFunctionalCollectionExtensions]: https://github.com/kballenegger/ATFunctionalCollectionExtens...
Here are some links for more info:
- http://cocoadev.com/wiki/HigherOrderMessaging
- http://macdevcenter.com/pub/a/mac/2004/07/16/hom.html
As an aside, I like to use my own [ATFunctionalCollectionExtensions][] for this purpose, which is a blocks-based implementation of map, reduce, inject, each, and filter.
[ATFunctionalCollectionExtensions]: https://github.com/kballenegger/ATFunctionalCollectionExtens...
First of all, language design is tough business. And for not appreciating that, with all my heart, I thank Netscape's project managers for rushing JS designers.
That said, I don't get all the hate towards ObjC. Taking into consideration its requirements, I think it has been doing great for us.
As for _.m, I appreciate the effort taken by its author, really. However, I won't be using it because it hurts one of the most pristine features of ObjC, which is readability. Fix that, and you'll get a lot more love from the community.
That said, I don't get all the hate towards ObjC. Taking into consideration its requirements, I think it has been doing great for us.
As for _.m, I appreciate the effort taken by its author, really. However, I won't be using it because it hurts one of the most pristine features of ObjC, which is readability. Fix that, and you'll get a lot more love from the community.
I feel as though most of these functions can be achieved with existing methods or with other libs like blocksKit.
Apart from the downright foreign (to objective-c) syntax what makes this different?
Apart from the downright foreign (to objective-c) syntax what makes this different?
It's probably just another attempt to build the same thing. Maybe for learning, maybe because they didn't know others existed (blockKit is new to me, fwiw). Maybe as a curiosity.
I don't get it. So this is a poor mans LINQ? Without the necessary performance considerations and a distressing lack of language support for its primitives?
What an abortion. Seriously just stop.
Every time I see someone misuse properties like this on Objective-C, I want to hire them to work at my company just so I can fire them. And then I would call them a few days later and apologize for being so rash and convince them to come back and work for me just so I could fire them again once they've settled into their desk.
Nobody wants your shitty javascript syntax mixed in with Objective-C. Nobody but you anyways. This isn't smart, regardless of whatever functionality it provides. You've done all this work to create this awkward, unclear, confusing, cryptic layer of shit that makes no sense when read. If I have to read documentation to understand what is going on, you've failed. This is full of fail.
WTF is A? N? N.I what the fuck is that?
underscorem is better for sure, but it still abuses property syntax in a way that I would reject on any project I saw its use in.
I'm always amazed at how much work people want to put into not having to write proper Objective-C. It doesn't make any sense.
So slow clap for writing some useless crap. Sorry for the vitriol, but this shit is just dumb.
Every time I see someone misuse properties like this on Objective-C, I want to hire them to work at my company just so I can fire them. And then I would call them a few days later and apologize for being so rash and convince them to come back and work for me just so I could fire them again once they've settled into their desk.
Nobody wants your shitty javascript syntax mixed in with Objective-C. Nobody but you anyways. This isn't smart, regardless of whatever functionality it provides. You've done all this work to create this awkward, unclear, confusing, cryptic layer of shit that makes no sense when read. If I have to read documentation to understand what is going on, you've failed. This is full of fail.
WTF is A? N? N.I what the fuck is that?
underscorem is better for sure, but it still abuses property syntax in a way that I would reject on any project I saw its use in.
I'm always amazed at how much work people want to put into not having to write proper Objective-C. It doesn't make any sense.
So slow clap for writing some useless crap. Sorry for the vitriol, but this shit is just dumb.
"How dare people port X to run on Y! This has no place in production code and you are WASTING OUR TIME doing theoretical experiments!"
Saying "Sorry for the vitriol" doesn't excuse being an ass, it just confirms that you were being an ass intentionally. How is your verbal assault an appropriate response to this project?
Saying "Sorry for the vitriol" doesn't excuse being an ass, it just confirms that you were being an ass intentionally. How is your verbal assault an appropriate response to this project?
Well said.
The original commenter could easily have said that "This project is sacrificing readability to be terse, and I don't think it's a good tradeoff. N.I? That's not Objective-C, and I don't know anyone that would use it in production code. Interesting experiment, but I'm not impressed."
That's not how I feel; that's just an example of how I'd have expressed his sentiment.
But I don't feel that way, because I think the reasoning behind the sentiment is flawed.
If the argument is about 'wasted development effort', I understand the arguments that effort should be directed at things that benefit a community, but this isn't a project like Meteor that reinvents package management and relegates Node.js to a component in a new platform; this is just a dude writing a module of helpers.
And if the argument is that 'no one should use this in production', well, individuals who write libraries that are in tune with their own personal taste are what a website called 'Hacker News' is about.
The original commenter could easily have said that "This project is sacrificing readability to be terse, and I don't think it's a good tradeoff. N.I? That's not Objective-C, and I don't know anyone that would use it in production code. Interesting experiment, but I'm not impressed."
That's not how I feel; that's just an example of how I'd have expressed his sentiment.
But I don't feel that way, because I think the reasoning behind the sentiment is flawed.
If the argument is about 'wasted development effort', I understand the arguments that effort should be directed at things that benefit a community, but this isn't a project like Meteor that reinvents package management and relegates Node.js to a component in a new platform; this is just a dude writing a module of helpers.
And if the argument is that 'no one should use this in production', well, individuals who write libraries that are in tune with their own personal taste are what a website called 'Hacker News' is about.
It is because this is that offensive to anyone who writes objective-c for a living.
First of all, you are using properties to fake dot syntax for method calls. This is all kinds of wrong.
Second of all, you are shortening the names of types because you are too lazy to type the first letter and hit space. This is beyond wrong.
It's not the functionality, it's the implementation. And when writing libraries for others to use, you must consider how it fits into that surrounding code. There are a bazillion smart people working at Apple writing objective-c libraries. Have you seen anything like this? You think maybe there is a reason for that?
Its just plain lazy, its just plain offensive. Learn objective-c. It's not that hard. Stop putting in all this work to produce something to fit this idea you can get around your weird perceptions of it and to shoehorn it into what you already know.
Like I said in another post, it's sad because there seems to be a lot of work put into this.
First of all, you are using properties to fake dot syntax for method calls. This is all kinds of wrong.
Second of all, you are shortening the names of types because you are too lazy to type the first letter and hit space. This is beyond wrong.
It's not the functionality, it's the implementation. And when writing libraries for others to use, you must consider how it fits into that surrounding code. There are a bazillion smart people working at Apple writing objective-c libraries. Have you seen anything like this? You think maybe there is a reason for that?
Its just plain lazy, its just plain offensive. Learn objective-c. It's not that hard. Stop putting in all this work to produce something to fit this idea you can get around your weird perceptions of it and to shoehorn it into what you already know.
Like I said in another post, it's sad because there seems to be a lot of work put into this.
It is because this is that offensive to anyone who writes objective-c for a living.
This is all kinds of wrong.
[Y]ou must consider how it fits into that surrounding code.
Relax. Don't get upset. It's not meant as an affront to your style or sensibilities. Consider this by @fat [1]:
Projects with the most radically unique styles often have the highest internal
standards for code quality and consistency. People put so much thought into the
written code itself that it actually engenders a new sort of pride.
It is because this is that offensive to anyone who writes objective-c for a living.
I think you need to seriously stop and consider what should and should not offend you, and what is worthy and unworthy of such vitriol.
I think you need to seriously stop and consider what should and should not offend you, and what is worthy and unworthy of such vitriol.
"It is because this is that offensive to anyone who writes objective-c for a living."
Please don't pretend you speak for other people, since it's pretty clear that you don't. Speak for yourself about how you dislike it as much as you want, but don't try to pretend that you have me or other people like me on your side when you don't.
Please don't pretend you speak for other people, since it's pretty clear that you don't. Speak for yourself about how you dislike it as much as you want, but don't try to pretend that you have me or other people like me on your side when you don't.
This kind of internet tough guy juvenile posturing is par for the course for him. Maybe he things talking like a 14-year old bully makes him seem passionate?
I sure as hell wouldn't want him to represent any programming community in which I participate.
I sure as hell wouldn't want him to represent any programming community in which I participate.
I really can't think of any language community that's as religiously defensive as the Obj-C purists. (except for maybe the worst of the Common Lisp queens)
People try to hack Obj-C syntax because it's a verbose, clunky, awkward syntax. Ok maybe the explicitness of something like tableView:cellForRowAtIndexPath:dequeueReusableCellWithIdentifier: is OK but the syntax for blocks and anything to do with collection classes is an abomination.
Thankfully Apple has finally fixed the latter case. The next thing they need to do to reduce the stuttering is steal the var keyword from C# and introduce proper namespaces.
People try to hack Obj-C syntax because it's a verbose, clunky, awkward syntax. Ok maybe the explicitness of something like tableView:cellForRowAtIndexPath:dequeueReusableCellWithIdentifier: is OK but the syntax for blocks and anything to do with collection classes is an abomination.
Thankfully Apple has finally fixed the latter case. The next thing they need to do to reduce the stuttering is steal the var keyword from C# and introduce proper namespaces.
I'm not familiar with C#, but if `var` is anything like `auto` in C++11, I think there's a good chance that they'll add it very very soon.
It's pretty much the same thing. Since they already support the use of auto in Obj-C++ mode it doesn't seem like too much of a stretch, although Apple do currently caution against using auto for Obj-C variables due to some Arc issues.
This uses SubjectiveScript.m by same author: https://github.com/kmalakoff/SubjectiveScript.m
A, N are typedefs of existing types.
"While JavaScript allows flexibility in variable types, Objective-C requires explicit variable types. To try to keep it brief, I tried to condense types down to the shortest name possible:
typedef BOOL B; typedef NSInteger I; typedef NSUInteger UI; typedef float F; typedef double D; typedef id KV[2]; // key-value pair
#define NSO NSObject #define A NSMutableArray #define NSA NSArray #define O NSMutableDictionary #define NSD NSDictionary #define S NSMutableString #define NSS NSString #define Date NSDate #define N NSNumber #define E NSException"
Just read that want me to stay far away from this.
A, N are typedefs of existing types.
"While JavaScript allows flexibility in variable types, Objective-C requires explicit variable types. To try to keep it brief, I tried to condense types down to the shortest name possible:
typedef BOOL B; typedef NSInteger I; typedef NSUInteger UI; typedef float F; typedef double D; typedef id KV[2]; // key-value pair
#define NSO NSObject #define A NSMutableArray #define NSA NSArray #define O NSMutableDictionary #define NSD NSDictionary #define S NSMutableString #define NSS NSString #define Date NSDate #define N NSNumber #define E NSException"
Just read that want me to stay far away from this.
Shortening NSUInteger to UI is anti-ergonomic in a language used to construct UI's.
I'm also surprised that O stands for NSMutableDictionary but NSD for NSDictionary. What is an "O"?
Another thing I would argue is that using the shorter #defines for mutables would encourage their use. Instead, it might be prudent to encourage use of the immutables.
I'm also surprised that O stands for NSMutableDictionary but NSD for NSDictionary. What is an "O"?
Another thing I would argue is that using the shorter #defines for mutables would encourage their use. Instead, it might be prudent to encourage use of the immutables.
I'm not sure why this guy just doesn't use MUMPS instead
Most of those typedefs are just silly, but the KV typedef is outright dangerous, since arrays are treated very differently from other values in C. Try returning a KV from a method and you're in for a big surprise.
Wow. Did somebody run over your dog today?
And just as a follow up, it's kind of sad because it looks like you put a lot of work in this.
But as someone who writes nothing but Objective-C (well, some C++ too) all day, every day, for a living. I would never ever use this. Mostly because it's obvious that you don't get objective-c and are trying to shoe horn some weird javascript idioms into a place where it doesn't belong.
I hate seeing wasted effort. I understand underscore provides nice functionality in javascript land and would appreciate someone taking the time to bringing similar functionality to objective-c in a way that fits and is natural with it's surrounding code.
As this is, no.
But as someone who writes nothing but Objective-C (well, some C++ too) all day, every day, for a living. I would never ever use this. Mostly because it's obvious that you don't get objective-c and are trying to shoe horn some weird javascript idioms into a place where it doesn't belong.
I hate seeing wasted effort. I understand underscore provides nice functionality in javascript land and would appreciate someone taking the time to bringing similar functionality to objective-c in a way that fits and is natural with it's surrounding code.
As this is, no.
Can't wait to see your version.
When it does come out, I hope others can be constructive without coming across like a cunt. Nobody likes that stuff, and as we all know, it's not very helpful.
When it does come out, I hope others can be constructive without coming across like a cunt. Nobody likes that stuff, and as we all know, it's not very helpful.
Well, it's not his, but http://underscorem.org/ looks wayyyy cleaner. It's not the basic concept of a collection of array and hash manipulation functions that's contentious, it's the godawful syntax brought on by abbreviating all of Objective-C's types.
I'm curious to know then what your take on coffee script is ?
I agree with your criticism but there's no excuse for being such a jerk. Settle down.
This isn't smart, regardless of whatever functionality it provides. You've done all this work to create this awkward, unclear, confusing, cryptic layer of shit that makes no sense when read. [...] This is full of fail.
Open up a little and appreciate that software development has an artistic side to it. If that style has engineering drawbacks ("misuses properties" is not valid unless you explain how this misuse is bad for a codebase), then bring those up without souding profoundly deranged.
100% with you.
I also don't understand this JavaScript everywhere.
Why can't kids learn to program in multiple languages nowadays?!
I also don't understand this JavaScript everywhere.
Why can't kids learn to program in multiple languages nowadays?!
Conversely, this makes me want to abuse the language as much as possible (not like I have much room to grow, there) just so I could get a job interview from you, accept, then tell you on my starting day that I changed my mind, and string you along like that.
Underscore.js may have some useful abstractions, but they'd be better exposed as Objective-C categories rather than trying to shoehorn everything into Javascript syntax.