I really hate to be the one to say this, but what is with all these links to stackoverflow? These features are all well-documented in the respective specifications, and to call them "hidden" is just silly. So why the 30 upvotes?
I don't expect the discussion in a stackoverflow thread to (currently) be more intelligent or interesting than a discussion here, or a blog post which actually shows such "lesser-known features" in a more coherent fashion. Taking that into account, it seems to me that these recent submissions are simply an attempt to improve the quality of stackoverflow. Call me selfish, but I don't think it's right to (even temporarily) decrease the quality of Hacker News in an effort to improve the quality of stackoverflow.
I submitted the links because there had been a discussion about how many politics and economics articles there were on the front page. So, I noodled around and found some articles on language features that might stimulate an interesting discussion here on HN.
And, even though I'm a python programmer, there were one or two elements on the list that made me want to go read up on them in the documentation.
I originally found the articles on javascript.reddit, not on stack overflow. It's not an attempt to boost stack overflow at all. These are the first few posts from stack overflow that I've actually read.
If people would like to see different kinds of articles, or more interesting articles, I'd be thrilled if others would take the time to find them and submit them: https://qht.co/submitted?id=BrandonM
Sorry about the unwarranted criticism. I think that one annoyance was that the titles presented programming in a way that someone would present video game cheat codes or easter eggs, when they were (of course) nothing of the sort. I realize that those were the original titles and you can't really be blamed for that; it is a reflection of the current population of stackoverflow, though, and is one example of why I don't exactly rate its submissions highly.
I am also sorry that I made a false assumption about the reason for the submissions, especially since that is what bothered me the most. I had assumed that you were a "loyal" member of stackoverflow and were trying to encourage us to join in on the discussion over there, which seems somewhat counterproductive as far as the community here is concerned. Coupled with the numerous stackoverflow comments I've seen to the effect of, "If something is wrong, why don't you go fix it?" (also not your fault), it just touched a nerve I guess.
I applaud your efforts to improve the community and to help shift it away from its recent politics/economics trend. As you can see from the link you gave, I submitted an article today, too, so I am in the same boat that you are (in terms of trying to improve the HN community). I am not much of a blog reader and don't often have much of value to submit, but since I did today and I had improving HN on my mind, I was glad to have something to contribute. I am certainly grateful for members like you who get the ball rolling with many good contributions, I just get disappointed when I feel that the community is overvaluing a submission without a lot of substance. (For example, I liked your "PHP vs. Lisp?" submission, however slanted it was, better than the stackoverflow ones.)
Also, I realize that your link was mostly a swipe at my lack of submissions, but that does not mean that I am not an active, contributing member. Nearly all of my 800+ karma has come from commenting, and I feel that buried in there are some gems with useful personal experiences, educated opinions, etc. In addition to that, I spend a decent amount of time lurking... reading submissions and voting them up if I feel they are "Hacker News"-worthy, reading countless comments and voting up/down based on my opinion of their value to me and to the community as a whole, and heading over to the "new" page when I have some time to kill.
Surely there is something to be said for members who contribute not as a primary filter (initial submitter) but as a secondary filter (up/down-voter who reads and votes on the submissions and comments) or as a commentator, adding insights to the discussion provoked by the article. After all, many of us are here at Hacker News for not only the low signal-to-noise ratio but also the unparalleled quality of discussion, and there are many non-submitting members who are doing this work behind the scenes without a lot of recognition.
I'm sorry about the swipe, Brandon. I was just annoyed, because there were a couple of disparaging comments about the stack overflow articles. I should have handled that a bit more tactfully. My bad.
It's been about a year or two since I've done anything serious in python, and ... yikes. Does anyone else get the feeling that Python is "C++ing" itself into a confusing mess? While lots of these elements weren't surprising to me, some were. And many that were convey little to no real value (c.f. "decorators", or "the step argument in slice operators").
This is the same thing that happened to C++. If you keep adding features that are useful to someone in some specific context, what you get is a more powerful language for an expert user writing code, but one that is much less productive for the people who have to maintain it.
And, can I just ask: how many ways to iterate over stuff does python really need?
Well, a lot of these suggestions are the sort of "tricks" that you wouldn't want to use in any normal situation. I think the additions to python are mostly making it cleaner and simpler.
List comprehensions are a great example. If you want to reverse the keys and values of a dictionary you can do
reversed_dict = dict((value, key) for (key, value) in original_dict.items())
Whereas in c++ this would have to be something like...
map<string, string> reversed_dict;
for (map<string, string>::iterator it = original_dict.begin();
it != original_dict.end(); ++it) {
reversed_dict[it->second] = it->first;
}
C++ may have added a lot of new stuff but they did not make the simple cases simple, they just made the simple cases possible but still ugly.
You're comparing the python syntax with the equivalent C++, not with the python syntax it replaced, which by my count is three lines shorter. The point is this: does the savings in code size from a list comprehension (which is 100% pure sugar on top of the existing loop syntax -- there's no new semantics in that feature) balance out the difficulty of teaching them to every new python programmer?
If you're a python expert, clearly your answer is "yes! this is a great feature!". But that's what the C++ experts say too, even as their language buries itself under a mountain of complexity. From the outside looking in, I'm seeing exactly the same thing happen to python.
Some fancy features make a language fun and productive. Too many such features make it a mess.
List comprehensions don't exist in their own vacuum though. For generators (the generalization of list comprehensions) and then coroutines, it's a feature that can't be replicated in Python without serious kludges; it does indeed add semantics. It enables you to do more: threads, actor model, state machine, modularize large functions. I think the cost of implementing list comprehensions was more than worth the while for all the benefits that have been reaped from it.
I think you're making a good point, which is that the new python features are usually more "syntactic sugar" than they are "features". It is not very hard to teach people that
alist = [foo(x) for x in things if isok(x)]
is equivalent to
alist = []
for x in things:
if isok(x):
alist.append(foo(x))
Similarly it's not hard to explain what an @login_required or a @memoize decorator does, although it is tricky to write a decorator yourself. Same goes for generators.
I don't think syntactic sugar is a bad thing. I wish C++ had better syntax. If I could never type hash_map<blah, blah>::iterator ever again, I would be happy. But that isn't the sort of feature that C++ tends to add.
1. Can you list a couple of features of C++ you are talking about?
2. Why do you thing that list comprehensions are so difficuilt to learn? iterators, generators and list comprehensions are easy and clean concepts.
If you want a feature, you write a lib. Once the feature is widely deployed it becomes a recognized pattern, so why not to include this one into the language?
Look at lambda or bind in boost - they are scary, but people still use them, since it's a powerful concept, and it would be much better to include them into the language.
List comprehensions aren't syntactic sugar. They're actually faster outright than for loops are. Especially if you're aiming to use the resulting list.
For example, in a framework like Django they are used for permissions in views. So you can quickly just make sure a user is logged in or is an admin to see a specific view, all with an un-obtrusive @login_required.
I don't find any of these features bad - they are easy to read and useful.
Agreed. The decorator idea didn't just come out of nowhere: It merely codified a convention that appeared in a lot of code where `function` would be defined and then you'd see `function = decorate(function)` afterward. (This is, for example, arguably the core idea of WSGI.)
Right. So ... why bother with adding a feature to the language when the language as it already exists can do it in one easily-comprehended line of six tokens? I'm sure you like the shorter syntax better. But I didn't know it, despite years of experience with scripting languages (and even this paradigm) that should have informed me about what that code means.
But it didn't, for the simple reason that it looked funny because I haven't been keeping up with Python. I'll say it one last time: this idea, that the language should cater to its experts by adding features wherever possible, is what has killed C++ as a hacker's language. Python is walking blindly down the same path.
"So ... why bother with adding a feature to the language when the language as it already exists can do it in one easily-comprehended line of six tokens?"
The decorator syntax is easier to read. It's at the top of the function where the arguments list and docstring are. Yes, there are tradeoffs when introducing new syntax, but decorators are definitely worth it.
is it? python3000 has deleted some unnecessary stuff. i dont really see your concern. it seems gvr is still concerned about the opposite of what you claim.
I wouldn't blame the language for code being hard to maintain. As long as the people doing the maintaing are as competent as the ones that wrote the code to begin with, and the code is well structured, tested and documented there should be no problem maintaining and extending it.
I don't expect the discussion in a stackoverflow thread to (currently) be more intelligent or interesting than a discussion here, or a blog post which actually shows such "lesser-known features" in a more coherent fashion. Taking that into account, it seems to me that these recent submissions are simply an attempt to improve the quality of stackoverflow. Call me selfish, but I don't think it's right to (even temporarily) decrease the quality of Hacker News in an effort to improve the quality of stackoverflow.