The use of map is nice, BUT it shows partially what is wrong:
1. there are too many non-obvious ways to do simple things (this means that out of 10 programmers you will typically see 10 different solutions to a simple problem)
2. i have a problem with using functions for "different" usecases as what their name implies.. in my world eval simply evaluates code and map is short for "apply function to every item" not "filter out an item"
- i hate doing "go over every item in a list and execute a function that returns the item if it is not 'dogfood' and return that new list, overwriting the original one" when all i want is "delete 'dogfood' from my list"
As good as your answers were, you've shown me some good points and that your community indeed is very helpful, i am not convinced of this language. Both of you said yourself that there are quirks in the language. "still try to decide what exceptions look like" after how many years of perl? That was my thought ;)
At the end of the day i will still try to find and fix bugs in other peoples perl code, curse frequently and hope that people move on to the next language..
> 1. there are too many non-obvious ways to do simple things
To a person who learned Lisp first your pythonish ways would be similarly non-obvious. Obviousness depends always on previous knowledge and you seem to know a lot about python; and as such expect things to operate like there.
Consider how confused a foreigner would be when he hears the word "bowling" and does not know about the sport and thinks it has to do with bowls.
> map is short for "apply function to every item" not "filter out an item" - i hate doing "go over every item in a list and execute a function that returns the item if it is not 'dogfood' and return that new list, overwriting the original one" when all i want is "delete 'dogfood' from my list"
But that is what filter does. Literally, there is no other way to implement this, unless you're operating with linked lists, which are not arrays. Filter is a map with a negated search func - wait, i'm an idiot. it should've been grep. But yeah, filter is just a grep with a negated search function.
@list = grep { $_ ne 'dogfood' } @list;
@links = grep { $_->protocol ne 'https' } @links;
> At the end of the day i will still try to find and fix bugs in other peoples perl code, curse frequently
Good luck and hop by on IRC! It will increase your curse frequency a LOT. (Until you meet mst and start to pick things up from him.)
To do what you want you could use list comprehensions or the filter(function, sequence) function:
List comprehension:
links = ["https://securesite.com", "http://unsecuresite.com", "https://sec2.com", "http://unsec2.com"]
[url for url in links if not url.startswith("https")]
>>> ['http://unsecuresite.com', 'http://unsec2.com']
links = ["https://securesite.com", "http://unsecuresite.com", "https://sec2.com", "http://unsec2.com"]
filter(lambda url: not url.startswith("https"), links)
['http://unsecuresite.com', 'http://unsec2.com']
Of course you'd replace the url.startswith with whatever your criteria is.
Also, list comprehension doesn't look bad to me. It's just a slightly weird and more verbose syntax of doing map, while filter does an in-place operation.
To elaborate a bit more: At my last $work i was in a team of four, who preferred to use bash for most things. This however was borne from a sheer lack of knowledge and once i showed them how to get real work done with Perl they started to prefer it.
There is a bug tracker attached to each project. Them having old bugs in there does not mean that they're being ignored, just that the author is lacking round tuits.Also, there is a cpan annotation thing. Unsure of how much it's used. I must admit: CPAN's biggest weakness is that search.cpan.org is closed source. However metacpan is trying to fix that and has made huge strides. :)
It is a question of scale. Is a 5% match in similary enough to say that it's "like it"? I have never needed more than two hours to get feedback on a module in #perl. In fact, i was once trolled for taking more than 5 minutes to accept that XML::Simple is crap. Yes it is. Note how it has not been touched since 2005. As i mentioned: Config::INI::Reader/Writer are preferrable nowadays. We are a community. You look at the reviews to see if there's anything obvious (I just added one: http://cpanratings.perl.org/dist/Config-Simple ) and if the module looks sketchy (long ago since last release, bugs open) you ask on IRC if better solutions have come around in the meantime. As mentioned, you'll get speedy answers. I like this idea. I have the feeling i've seen something like that before, but i'm not sure. I think the best solution would be to be able to order the search results by date. It's lexical and only applies for your code. If you wish to capture warnings in third-party code, the cleanest solution is to wrap it in Capture::Tiny. :) Is this nice enough? Ah, ok then. Honestly, i can accept that, i just would've liked to see more. Then again, not everyone writing about Perl 6 actually know a lot. Nah, it's fine. You allow me to demonstrate more powerful perl to the casual reader. This is a problem though. You've already decided that no matter what i say, you will remain stubborn. How many people think Britney Spears made amazing music? Appeal to majority is not always a good idea.