131–140 of 156 posts
TLDR: if you’re a new programmer, don’t take this seriously. This person clearly doesn’t understand programming languages so well. Sorry to make this response an “ad hominem” one, I should revoke the claims. But it’s impossible if they don’t understand basic concepts of programming languages. For example, complaining that a dictionary key must be place in quotes. It’s not that “the key needs quotes”, but that you’re…
> For example, complaining that a dictionary key must be place in quotes. It’s not that “the key needs quotes”, but that you’re using “a string” as a key. In fact in Python, you can use any immutable object as a key (tuples, for example). They clearly come from Javascript, Python works differently (and arguably better), and they’re complaining that it doesn’t work the way they’d like it to work. Agreed. However, ther…
This list is so deliciously sophomoric. The best one is, and I quote: """To many other weirdo bits of magic syntax, like [list comprehensions]""" Obviously without actually proposing how comprehensions could be made better one has to hope the author would say he likes the equivalent Haskell better, but there is a strong doubt that is not the case.
Complaining about having to cast generators to list... seems like the kind of dev that has their code randomly run out of memory until a senior dev comes and fixes it.
Earlier quoted context omitted.
" Please don't post shallow dismissals, especially of other people's work. A good critical comment teaches us something. " https://news.ycombinator.com/newsguidelines.html For example, instead of putting someone's article down as sophomoric, you could explain what's different and possibly better about Haskell list comprehensions.
You could, but you'd lose the Socratic method and efficiency of thinking. There is a reason why many academics can be quite acerbic. All these politeness comments are a speed bump that distracts from the real issues.
I used to think similarly about this to what you express, because I've always enjoyed reading about the sort of discourse in which devastating wit is exchanged. But eventually I realized that it doesn't translate into this context at all. This is a case of 'the medium is the message'. When you have millions of people who don't know each other all potentially interacting at the same time, the dynamics are so different as to be incommensurable with, say, small debates, literary journals, elite social events, and other places where the groups are small and highly cohesive. Here are some previous explanations about this:
https://hn.algolia.com/?dateRange=all&page=0&prefix=true&sor...
https://news.ycombinator.com/item?id=15378909
https://news.ycombinator.com/item?id=9378899
https://news.ycombinator.com/item?id=7906377
https://news.ycombinator.com/item?id=7742471
The bottom line is that having a forum like HN be open to everybody comes at the cost of some blandness.
Earlier quoted context omitted.
I personally find list comprehensions in python pretty horrible. They seem to exist only to do lots of stuff in one single line of code. You end up with totally impenetrable unreadable perl-esq garbage write-once-read-never code that is too clever for its own good. And people say python is easy to learn and good for beginners...! A better approach would be something like Java Streams/.net Lync/RxX pattern IMO. Explic…
dic = {k: v for k, v in dic.items() if k in other_dic and v == "bar"} How could that be improved? That's 3-4 LOC minimum in any other language My main grip is python's ternary operators, since the True value is evaluated before the condition, if you are doing ternaries on things that might throw exceptions the False value has to come first value = 0 if key not in dic else dic[key] * 5 rather than (throws indexerror i…
dic.iter().filter(|k, v| other_dic.contains(k) && v == "bar").collect();
it's one line, though I'd format it as 3 for readability (list comprehension is hard to read and functional style composes better.
> a big part of my frustration comes from having a JavaScript background Yeah, I thought so when I was reading the list of "problems". In fact, many of those are features (e.g. lists & tuples being different, list comprehensions, lazy evaluation, distinction between maps/dicts and objects, ...) but the author doesn't actually understand them. I hate to sound so negative, I guess I just didn't realize how bad a progra…
There's some annoyances that have accumulated in python, like the inheritance patterns and too many underscored things. Decorators are kinda weird, too. I think Python is pretty awesome, but to pretend that it's super clean is a bit of a stretch. (a,) for a single-elem tuple-- avoiding colliding with (a) as a paren'd expression-- is wonky, too.
Part of the problem here is clearly this person is mapping JavaScript idioms to python; in particular "Needing to put dict property names `{'in': 'quotes'}": these aren't object properties , these are keys in a map, and they can be and often are variables themselves, (also, can be any hashable type, not just strings) and I don't see how that can detract from the 'greatness' of python. Also "foo['bar'] returns a KeyEr…
{'a':1, 'b':2, 'c':3}
dict(a=1, b=2, c=3)
> a big part of my frustration comes from having a JavaScript background Yeah, I thought so when I was reading the list of "problems". In fact, many of those are features (e.g. lists & tuples being different, list comprehensions, lazy evaluation, distinction between maps/dicts and objects, ...) but the author doesn't actually understand them. I hate to sound so negative, I guess I just didn't realize how bad a progra…
There's some annoyances that have accumulated in python, like the inheritance patterns and too many underscored things. Decorators are kinda weird, too. I think Python is pretty awesome, but to pretend that it's super clean is a bit of a stretch. (a,) for a single-elem tuple-- avoiding colliding with (a) as a paren'd expression-- is wonky, too.
x = 1,
x = (1,)
Using (a,) is the belts-and-suspenders way of saying "this is a 1 element tuple".
This list is so deliciously sophomoric. The best one is, and I quote: """To many other weirdo bits of magic syntax, like [list comprehensions]""" Obviously without actually proposing how comprehensions could be made better one has to hope the author would say he likes the equivalent Haskell better, but there is a strong doubt that is not the case.
I personally find list comprehensions in python pretty horrible. They seem to exist only to do lots of stuff in one single line of code. You end up with totally impenetrable unreadable perl-esq garbage write-once-read-never code that is too clever for its own good. And people say python is easy to learn and good for beginners...! A better approach would be something like Java Streams/.net Lync/RxX pattern IMO. Explic…