131–140 of 158 posts
Earlier quoted context omitted.
To each his own. For me it was epoll() that blew me away. Absolutely crazy. Brilliant. But in retrospect so damn obvious.
epoll() (or its predecessor poll()) is a kind of low-level API function, whereas polymorphism is a general and fundamental programming concept.
Earlier quoted context omitted.
-1 for the ad hominem: "... and you are just envious"
Are you kidding me? I was copying his style, to show him how irrelevant and childish the statement was. Also, it wasn't an ad hominem, since there wasn't any argument being debated. Get your fallacies straight. I guess this is why you have 9999 submissions with 1 point. To be able to go around downvoting and incorrectly calling people out on a fallacy (the new trick you have learned).
Earlier quoted context omitted.
Are you kidding me? I was copying his style, to show him how irrelevant and childish the statement was. Also, it wasn't an ad hominem, since there wasn't any argument being debated. Get your fallacies straight. I guess this is why you have 9999 submissions with 1 point. To be able to go around downvoting and incorrectly calling people out on a fallacy (the new trick you have learned).
> Also, it wasn't an ad hominem ... I don't get it. What's the point of replying to a perceived false accusation of ad hominem with three more ad hominems? "Get your fallacies straight" , "I guess this is why you have ..." , " (the new trick you have learned)"
I must have corrected the 'ad hominem' thing at least 5 times today, so I'm tired. It's not ad hominem if it's not trying to undermine an argument (it's just insulting or trolling), and it's not ad hominem either if it's relevant (eg: programmer does not know the basics, that fact comes to light, and is used against him in a programming discussion).
Earlier quoted context omitted.
Thats a very critical point that you just have to understand, to "get". Many people know and learn about object oriented design, but when tasked to actually write a program based on these principles they will often revert to code where they make distinctions based on the type of what they have been handed. TLDR: dynamic_cast is bad design
Using static conditions rather than polymorphism seems to just be a common thing that people tend to do, regardless of skill level or quantity of experience. It's not uncommon for people just not to think of using polymorphism, if the objects in question wouldn't really model any particular kind of object as such (they're just there to provide a table of function pointers). This says nothing about the quality of thei…
Earlier quoted context omitted.
...I rarely trust these kinds of name-generation tricks. So you're probably not a big fan of Rails, then?
and what does `trust` mean? You don't trust that correct object won't be given back to you?
Reading the comments in this thread is very interesting to me, because each programmer seems certain of the superiority of his own programming style. We have some comments that disparage the change, saying that it obfuscates the code and makes it more difficult to understand. We have others saying that this change is a basic technique and it's "shocking" that the author wrote a book without this simple knowledge. Wha…
There are objective ways in which to judge programming, by considering whether simple rules like the SOLID principles, low coupling, DRY, using composition over inheritance, keeping code complexity measurements low, favoring immutability, statelessness and referential transparency, etc. have been followed.
If any programmer is certain of the superiority of 'his programming style' (singular), then that programmer is insufficiently humble and lacks knowledge of multiple programming styles. Tragically, if you don't know what you don't know, you can think you know everything and can thus speak with confidence on a subject.
One can wonder what comments would be left if you removed all those from programmers with less than 5 years of programming experience, programmers under 30 and programmers with experience in only a single language. My suspicion is that a pretty consistent picture would emerge, with a number of caveats and YMMV's, with an eye for the actual, intended and possible future use cases, the language, the maturity of the project, etc.
Earlier quoted context omitted.
Using static conditions rather than polymorphism seems to just be a common thing that people tend to do, regardless of skill level or quantity of experience. It's not uncommon for people just not to think of using polymorphism, if the objects in question wouldn't really model any particular kind of object as such (they're just there to provide a table of function pointers). This says nothing about the quality of thei…
That is strange to hear. That kind of polymorphism is literally the first example given in any OO tutorial. "Bark", "Meow", "Oink", etc.
If you keep an eye out for this, I'm pretty sure you'll start to spot it!
Earlier quoted context omitted.
You may never know - if it teaches you some things and makes you more productive, then what of it?
My concern is the inverse of that: recommending something you either don't fully understand or haven't used long enough to speak to either its pros or cons. Being in a book usually is an indicator that something is a best practice or how the way things should be done, ostensibly being put forth by an expert. Perhaps we shouldn't hold such content to such a standard.
Instead, I found that he wrote from what I can tell the only book that introduces RubyMotion, published by PragProg, and endorsed by other authors.
His blog post shows humility, an ability to praise the work of others, and an effort to add value to the world.
All things that these HN comments distinctly lack and, ultimately, punish.
Here is someone writing books and programming iOS apps who can still have his mind blown by, what seems to me, some fundamental concepts. I think there are a lot of people out there doing real work - who can benefit from a little push. that makes me feel that a) I have things I can teach and b) that its ok to not know everything - even what others may think is "basic" stuff.
Earlier quoted context omitted.
I'm actually not a huge fan of implicit name-generation tricks, but I'm also not entirely opposed to them. The trick here I think is consistency - is name-generated type dispatch the standard across the entirety of the codebase? If it is, go wild. If it's not then I'd be much more wary of it. Consistency and building correct expectations for future maintainers is pretty important. Doing a smart trick in one place but…
I so agree with you. There are few programming mistakes that consistency in use does ameliorate. On the other hand, no matter how "good" the code, if it's inconsistent, it's bad.