Is this a real scenario you've encountered (if so, provide details), or just some made up, straw man scenario trying to illustrate... something?
Not sure it's relevant, but I/O in Python is quite fast, and Python can call non-Python libraries just fine. Also, it seems far more likely that the "internationally recognized company" would be the one with the bizarro artificial coding policies, while the startup would be the one more free to do whatever makes sense.
Great comment, thank you. As someone who is fairly religious, I'd like to highlight/expound on a couple of points:
a) There are a lot of us out here who "like" both science and religion - we don't see any conflict between the two. There are others who simply don't participate in religion - they don't believe in it, they don't want it, whatever. That's cool too. Finally, there are two small but vocal groups: science-leaning people that feel threatened by religion, and religious-leaning people that feel threatened by science. Both groups are annoying, neither is representative of the rest of us.
b) The fact that there are loud-mouthed religious crazies out there is irrelevant in terms of religion overall. We (the other religious people) think they are crazy too. Any citing of things they have said or done as arguments against religion generally are straw man arguments because it's based on the assumption that we agree with them.
c) I'm not bothered by people who aren't interested in religion or even those who have carefully studied it and actively disagree with it, but I do take issue with a lot of the negative comments to this article that seem to come from people who appear to be fairly settled in their conclusion that religion and science must always conflict, that religion is for simpletons and the naive, that religion is always been bad, and that all religion can be distilled down to a very tiny set of core ideas that are easily dismissed. Don't want religion? Fine by me. But the gross oversimplification of religious thought and history gets old, and makes them look extremely foolish and ignorant (and, embarrassingly, more or less on par with the corresponding religious crazies).
I guess I read this essay differently. I don't think he was trying to argue that nobody in history has used religion to the detriment of science (if he was, then I agree that he made a poor case). To me it read more like an observation that the apparent "conflict" between religion in science is not all-encompassing historically nor is it necessarily inherent.
On/. there are tons of comments along the lines of, "here's an example of a religious nutjob; therefore all religious people are anti-science nutjobs, all religion is stupid, God can't exist. QED". This article is a nice counter-perspective: it's neither trying to be all-encompassing (just citing a few examples), nor is it trying to defend the nutjobs out there. Just offering a perspective that religion and science can coexist quite well - in some cases they do today and in history there are some examples of that as well.
I'm a fairly religious person and I see no inherent conflict whatsoever between science and religion. Are there religious nutjobs? You bet, and I have no interest in defending any of them. Has religion been used in the past to do bad things? You bet, and I have no interest in defending that either. By the same token, anyone who truly trusts the scientific method (and I do) must recognize that the presence of religious wackos or the abuse of religion does not universally prove anything about religion. Perhaps it can imply quite strongly that most or even all religion is bunk, but it stops short of proving it. It could even suggest strongly that there is no God, but again, a true scientists still leaves open for that possibility, even if they perceive that possibility to be remote.
Blind belief in religion is lazy and shameful IMO. But so too is the writing off of all religion because there are examples presently and throughout history of dumb religious beliefs or doing evil in the name of religion - basically strawman arguments. Ditto to people who think the scientific method is used for proving things - they are on no better intellectual footing than a blind religionist. Religion and religious history has far more depth, complexity, and even substance than many here give it credit for. I don't blame people for not being interested in religion - totally fine by me - but I do fault them for taking a stance on it in relative ignorance, speaking in grand generalities that are patently false, or for twisting science into a religion of its own (I don't think most scientific-oriented people do this, but some do, e.g. the aforementioned who misunderstand the scientific method).
Maybe I haven't woken up all the way, but I don't get the point of this article. All app stores (Amazon's, Google's, Apple's) have open source apps to some degree or another, and tons and tons more apps are built on open source libraries. So Microsoft's app store is on par with... everybody else? Ok, great.
A big part of the problem is that in many countries (especially the US) the tax system is so broken that it has created enormous incentives to look for loopholes. Some commenters have noted that they pay more than they actually have to because they don't pay some accountant to go find all the ways to reduce it. Exactly! This is a shortcut way of saying that the cost exceeds the benefit. For a corporation, that is not the case, in part because corporations are taxed to death, so there is a large incentive to reduce their tax burden. It's that simple.
I really don't understand the attitude of some people on here who are outraged by companies taking advantage of legal ways to reduce taxes. If there is a legal way for a company to reduce its tax burden, it's naive to be upset that companies use it. Direct the outrage towards the bought congresspeople, if anyone, but really it should be funneled into fixing the actual problem: the government takes way too much.
In the US, the government taxes over a/third/ of all of a company's profits (http://en.wikipedia.org/wiki/Corporate_tax_in_the_United_States) at a bare minimum. That alone is a staggering amount of money. But that's before the money even makes it to any of the owners, who are also taxed. By many estimations, the total tax on people is *half* of gross income (http://www.nowandfutures.com/taxes.html - just one example, there are many).
Half! That's absurd! A government provides many services and I'm happy to pay my fair share for those services, but IMO half is far in excess of what is reasonable - the government does some nice things, but in no way is what it provides worth what it costs. What is fair and reasonable? Honestly, even low double digits seems to be pushing the limit of reasonable, but I'd jump at the chance to have the government take "only" a fifth of my total income.
So, if my total tax is in the neighborhood of 50%, and fair is at most 10%, but I'd settle for 20%, then if I discover some *legal* way to get that 50 closer to 20, will I take advantage of it? Absolutely! It's not unethical at all. I'm *already* paying an unethical amount of my total income, so reducing my tax to something closer to fair is something I'm happy to do.
Until real tax reform happens and people and companies are taxed reasonably, there will always be huge incentives to find every possible means of reducing one's tax burden.
Agreed! Higher education is widely available to those who want it enough to work for it. It could be made more affordable perhaps, the system isn't perfect, etc. but if somebody is truly motivated to pull themselves up and pursue a degree, there are many, many ways to make it happen without going into huge amounts of debt. Taking away the challenges (including labeling it a universal "right") isn't helping anybody - many of the challenges of going on to higher education are exactly the things that are needed to transform high school students into mature, responsible adults.
Amen! I finished my degree without any debt and it wasn't always a cakewalk, but it wasn't insanely difficult either. I knew my parents wouldn't be able to pay for it, so I got good grades in high school and landed a scholarship that helped. I had a job all through high school and college and tried to be frugal - stuff that I assumed everybody else would do.
I have a hard time feeling sympathy for people who leave school with absurd amounts of debt. Some debt might make sense in some cases, but huge debt seems foolish, especially when the graduate then whines about their burden and even more so when their degree is in a field with generally low wages and/or few job prospects. Nobody forced them into it, were they just not thinking things through? Did they have no plan?
Yeah, good point - I didn't think much about the tool issues, but I think you're right. For us it's always 1:1 - if it's a language / platform that feels like you must have an IDE, then we use that IDE for writing code, project management, debugging, etc.
As noted early, it's not really that cut and dry - I find developing in an IDE to often be pretty cumbersome - just get out of my way and let me tackle the problem I'm trying to solve. I don't do much Windows dev anymore, but I do think the VS IDEs were some of the best (VS 6.0 or whatever it was back in the day is still IMO the best ever), while Xcode and Eclipse are often maddening.
But it does seem to have a lot to do with the particular language and its libraries or frameworks. I've tried the IDE-less approach with Java/C#/ObjC and my productivity felt like it was a tiny fraction of what it was with an IDE. Conversely, over the years I've tried just about every major Python IDE and felt like there was very minimal benefit. That minimal benefit coupled with the annoyances of an IDE have always led me back to being most productive in emacs or vim.
That makes a lot of sense, yes, although even with duck typing the autocomplete plugins for Python IDEs are really good. This conversation has reminded me that the one for vim is actually really good these days, and yet I still don't use it (and now I'm curious as to why that is).
I think the thrust of my point was that using an IDE wasn't/all/ pluses, there are some drawbacks, so it comes down to whether or not the benefits outweigh the costs, i.e. it's not just a question of developing with, say, inline help vs developing without it.
Now I don't think the costs are/that/ huge, most of them are in the realm of nits and minor annoyances, but they do add up to enough to make me shy away from it when it's not virtually required. Whether it's a feeling of having to shoehorn my project into whatever constraints are required by the IDE's project management features, or the littering of IDE support files, the more I'm aware of the presence of the IDE, the more annoying it is. Case in point: I checked out an Android app from one of our other developers and it took me quite some time to figure out how to load it into Eclipse. I figured it was just my lack of experience with Eclipse, except that Google showed lots of other people with the same confusion. In the end I caved and moved the files into the subdirectory where Eclipse wanted them just so I could get moving. I don't really care about that specific example, but that is the sort of thing I run into with IDEs.
One of the things that I like about not using an IDE and just using vim is that my full development environment is immediately present on any machine I have to work on - just scp a tree with some useful plugins and config settings and troubleshooting a problem on a production box is hardly different than working on it locally. Anyway, it really does boil down to personal preference a lot, my point was just that an IDE is definitely not all plusses without any minuses.
I partially agree but don't think it's quite so cut and dry. You/can/ build very large systems without an IDE and be quite productive at it, i.e. I disagree with any assertion that an IDE is or isn't required to make you productive, efficient, able to build big things, etc. Further, not using an IDE does not necessarily imply monolithic files, either. I also haven't found any correlation between rate of defects and whether or not an IDE is used.
So, some of the reasoning in the article is a little off IMO, but so too is the implication that an IDE is universally the best/proper way to do modern development. ISTM that it has more to do with the language than other factors - for development in some languages, an IDE is nearly a requirement. In other languages the benefit is much less assured and can even be a net negative, at least for some people.
Modern IDEs can be great, but using them does come at a cost, so I think people end up using them in situations where there is a net benefit (and the opposite is true - people don't use them where there is a net cost to using an IDE). Personally, using a full-fledge IDE often leaves me with a feeling of it getting in the way, but I tolerate it because with some languages or platforms the IDE is still a net win.
This is nothing but an anecdote, but we have several non-trivial projects (100kLOC+ each) in C/C++, C#, ObjC, Java, and Python worked on by about 10 people (so not huge by any means, but not so trivial as to be meaningless) and:
* Everybody uses an IDE for the ObjC, C#, and Java projects
* About half use an IDE for the C/C++ projects (rest use vim)
* Nobody uses an IDE for the Python projects (most use vim)
What's interesting to me is that as far as I know everyone has/tried/ not using an IDE for Java/ObjC/C#, and everyone has tried using an IDE for Python, and there has never been any sort of mandate to go one way or another, and so the present situation is the result of everyone sort of landing where it feels most natural and where they are the most productive, and that we have the same results regardless of proficiency in a particular language (i.e. the C# experts and C# noobs end up with the same development environment, as do the Python experts and the Python noobs). The same also appears to be true regardless of language affinity - lovers and haters of Java use the same environment, lovers and haters of Python do as well, etc.
I do wonder if there is some sort of correlation between environment and the language. I know this is pretty subjective, but for me languages like Python feel like they rarely get in your way, and so it's interesting that when people in our company use Python, they gravitate towards development environments that are similarly lightweight. And conversely, for me a language like Java tends to feel like it gets in the way a lot (as in, you have to do lots of things that are satisfying the demands of the language that aren't directly tied to the problem you're trying to solve), and an IDE is indispensable because the IDE helps shoulder some of that burden.
Yeah, in those areas I tend to do 80-85. Not going higher could also be other factors - the older the car, the more it starts to rattle at those speeds. Also, the roads tend to be more remote so they have fewer lanes, which increases the odds that a zippy driver gets stuck behind somebody going "only" 80.
My experience is only a single data point of course, but I think I speed because I'm focused on the driving and usually want to get it done - I want to get out of traffic, stop dealing with all the stoplights and other motorists, and move onto something that either requires more of my focus or less. Driving is one of those tasks that takes enough of your attention that you can't focus on something else, but not so much that you feel engaged usually (which is probably another reason why I speed - it's riskier and therefore more engaging).
Further, a good driver often checks the gauges, dials, etc., so they are constantly looking at the speedometer, and fixating on it IMO contributes to the desire to speed - limit is 65 so I nudge up to 68 or 69, then over 70. Oops there's a cop, slow down. Ok, ease up again, get to 75, another cop slow down, etc. It almost becomes a lame game to deal with the boredom.
OTOH if I am in a self-driving car I can pretty much ignore the road and focus on a book or a laptop or the scenery or a conversation. While I'll always want to "get there" faster, whether I'm going at 65 or 68 or 72 becomes much less of an issue - I'd make that trade any day as it's similar to mass transportation but without all the stops along the way. And if self-driving cars get their own HOV-ish lanes to encourage adoption/throughput or if enough people switch to those cars, then overall we should have fewer traffic jams and accidents anyway, so the average speed can really be close to the speed limit (as opposed to right now where it's often bursts of speeding, then congestion, then speeding).
Sorry, but "Amazon's cloud has gone down" is wildly incorrect. From the sounds of it, *one* of their many data centers went down. We run tons of stuff on AWS and some of our servers were affected but most were not. Most important of all is that we had *zero* service interruption because we deployed our service according to their published best practices, so our traffic was automatically handled in different zones/regions.
Having managed our own infrastructure in the past, it's these sort of outages at AWS that make us grateful we switched and that continue to convince us it was a good move. It might not be for everybody, but for us it's been a huge win. When we started getting alarms that some of our servers weren't responding, it was so cool to see that the overall service continued on its merry way. I didn't even bother staying up late to babysit things - checked it before bed and checked it again this morning.
Firing up a VM on EC2 (or any other provider) != architecting for the cloud.
This also fits in well with the hashability of tuples vs lists - the latter aren't hashable, so they can't be used as e.g. dictionary keys, but typically that also simply makes a lot of sense: a tuple usually represents a record or a distinct "item", so it makes sense that it should be usable as a dictionary key because it's more or less a specific "thing", whereas a list can't be used as a dictionary key and this also typically makes sense: a list of a bunch of things as opposed to being something specific, so it's less sensical for it to be used as a key anyway.
I'd argue that the reason why tuples are hashable and lists aren't is precisely because of the difference in mutability
Yes, that's most definitely why one is hashable and the other isn't. I'm suggesting that that's largely separate from why you use one or the other - in Python, the technical difference between a tuple and a list may involve things like hashability and mutability, but that's rarely what leads one to choose one over the other.
What you're trying to represent is most often what pushes you one way or another. If you tracking sifting through a set of data to count the number of people with a particular left/right-handedness and gender, you typically wouldn't think of that as something you'd put into a two-item array. It's naturally a tuple because it represents a specific combination you're looking to track, e.g. (right, female).
IOW at a technical level lists and tuples are very similar, but I'm suggesting that issues of hashability and mutability aren't/normally/ the driving force for choosing one over the other. I think it'd be rare for someone to put something in a list and then say, "oops, better make that a tuple so it's hashable". Rather, if the combination of values represents a specific "thing" or combines to represent a unique value, then that sort of thing naturally ends up in a tuple more than in an array.
Circling back around, it's that difference in common usage that doesn't really map to the difference in how NSArray and NSMutableArray are typically used.
This isn't a rant against code completion - I think it's safe to say we've all used it for years prior to ObjC gaining traction due to iOS and yes, it is an expected feature of any modern IDE. What feels like a crutch about it with ObjC is that it's nearly impossible to be productive in ObjC without it. It's similar to developing in Flex if you've tried that.
I've heard the maintenance argument before and I somewhat agree with it, but in general if you're changing a method signature in any language and being diligent about it, then you'll be checking existing uses of it anyway (similarly, if you're relying on the compiler to find all the issues, then more often than not you're overlooking a bug).
As with the complaint about forced named parameters being redundant in the majority of cases, requiring it as a protection against future refactoring also seems a bit heavy handed - i.e. a cost with only a just-in-case benefit. And, similarly, coming from other languages where this isn't required, it feels cumbersome since in those languages we don't have that requirement and yet we also don't run into the types of problems these features help prevent.
I'm very eager to get to ARC, no doubt about it. As for the existing ways to get instance vars in categories, to me they all feel a bit on the side of hackery. That's just my perception of course.
[snip] Seems very straight forward to me and very readable.
And that's very fair as this is, after all, a largely subjective question. To me that sort of code scans very poorly (as does the equivalent C++) and is one of the things I dislike about the language. Still, I completely understand that other people have a different reaction to it.
Like I said before, it's bad form to do the latter without a comment or other contextual information explaining why you have those hardcoded values in there. The fact that you are explicitly saying which one is x,y,z, or index is beside the point - someone reading the code is going to be less interested in which '1' corresponds to which parameter and more wondering why those values are hardcoded. And once they know that, then explicitly calling out the names of the parameters has less value anyway.
(the purpose of the comment is much more than just telling which values are which, it's a level-of-intent comment, and should be there regardless)
The other point already mentioned is that even if in this extremely specialized case (where you have 4 hardcoded values and no variables) it provides value (and I'm skeptical it does, due to the above), that still doesn't justify requiring it all the other times where it's just redundant.
There is nothing "Magic" about some constants. There is no reason to put numbers that will never change in variables. Named parameters make the comment in the Objective C example not necessary.
Not at all. The idea is that if you have some hard coded set of values going on, then either there is a comment explaining why or the surrounding context makes it abundantly clear. This should be the case whether you're in ObjC or some other language - i.e. things you should already be doing will be providing nearly as much if not all of the value that forced named parameters provides. So in one extremely contrived case there might be a modicum of debatable benefit, but in all other cases you have to do it anyway even when there is no benefit.
Again, continuing with this contrived example, other languages handle this better. For example, in Python you'd normally do something like:
self.drawAt(x, y, z, index)
but in the case where you have some hard coded values you can make it explicit for clarity:
self.drawAt(x=1, y=1, z=1, index=1)
That's the beauty of it: in normal cases where naming the parameters is redundant (since it's implied by the names of your variables) you can leave it off, but in the corner cases where the parameters don't convey as much information you can, if you want, be explicit. This is why the ObjC way is so grating: rather than giving me the option of doing what makes the most sense, the language designers chose one of the two and IMO chose the wrong one - you pay the price every time even if most of the time you don't get any benefit from it.
Your complaint about named parameters is just you have to type more.
No - my complaint is that it's more writing and - more importantly - more reading. My biggest complaint is that the verbosity is such that the overall readability tends to be reduced due to the clutter. Given that code is read a lot more than it is written, this is a big deal to me.
Of course all of your arguments are contrived bullshit.
LOL, you do recognize of course that the example we're arguing about is one provided by you or some other AC, and one where we're calling a function with 4 hard coded values all with the value of 1, right? Contrived indeed!
Slashdot Mirror
Agreed! The curly braces exist /primarily/ for the computer, not the humans reading/writing the code.
lol, there's no static type checking because it's not a statically typed language.
Static and dynamic typing each have their advantages ya know.
Is this a real scenario you've encountered (if so, provide details), or just some made up, straw man scenario trying to illustrate... something?
Not sure it's relevant, but I/O in Python is quite fast, and Python can call non-Python libraries just fine. Also, it seems far more likely that the "internationally recognized company" would be the one with the bizarro artificial coding policies, while the startup would be the one more free to do whatever makes sense.
Great comment, thank you. As someone who is fairly religious, I'd like to highlight/expound on a couple of points:
a) There are a lot of us out here who "like" both science and religion - we don't see any conflict between the two. There are others who simply don't participate in religion - they don't believe in it, they don't want it, whatever. That's cool too. Finally, there are two small but vocal groups: science-leaning people that feel threatened by religion, and religious-leaning people that feel threatened by science. Both groups are annoying, neither is representative of the rest of us.
b) The fact that there are loud-mouthed religious crazies out there is irrelevant in terms of religion overall. We (the other religious people) think they are crazy too. Any citing of things they have said or done as arguments against religion generally are straw man arguments because it's based on the assumption that we agree with them.
c) I'm not bothered by people who aren't interested in religion or even those who have carefully studied it and actively disagree with it, but I do take issue with a lot of the negative comments to this article that seem to come from people who appear to be fairly settled in their conclusion that religion and science must always conflict, that religion is for simpletons and the naive, that religion is always been bad, and that all religion can be distilled down to a very tiny set of core ideas that are easily dismissed. Don't want religion? Fine by me. But the gross oversimplification of religious thought and history gets old, and makes them look extremely foolish and ignorant (and, embarrassingly, more or less on par with the corresponding religious crazies).
I guess I read this essay differently. I don't think he was trying to argue that nobody in history has used religion to the detriment of science (if he was, then I agree that he made a poor case). To me it read more like an observation that the apparent "conflict" between religion in science is not all-encompassing historically nor is it necessarily inherent.
On /. there are tons of comments along the lines of, "here's an example of a religious nutjob; therefore all religious people are anti-science nutjobs, all religion is stupid, God can't exist. QED". This article is a nice counter-perspective: it's neither trying to be all-encompassing (just citing a few examples), nor is it trying to defend the nutjobs out there. Just offering a perspective that religion and science can coexist quite well - in some cases they do today and in history there are some examples of that as well.
I'm a fairly religious person and I see no inherent conflict whatsoever between science and religion. Are there religious nutjobs? You bet, and I have no interest in defending any of them. Has religion been used in the past to do bad things? You bet, and I have no interest in defending that either. By the same token, anyone who truly trusts the scientific method (and I do) must recognize that the presence of religious wackos or the abuse of religion does not universally prove anything about religion. Perhaps it can imply quite strongly that most or even all religion is bunk, but it stops short of proving it. It could even suggest strongly that there is no God, but again, a true scientists still leaves open for that possibility, even if they perceive that possibility to be remote.
Blind belief in religion is lazy and shameful IMO. But so too is the writing off of all religion because there are examples presently and throughout history of dumb religious beliefs or doing evil in the name of religion - basically strawman arguments. Ditto to people who think the scientific method is used for proving things - they are on no better intellectual footing than a blind religionist. Religion and religious history has far more depth, complexity, and even substance than many here give it credit for. I don't blame people for not being interested in religion - totally fine by me - but I do fault them for taking a stance on it in relative ignorance, speaking in grand generalities that are patently false, or for twisting science into a religion of its own (I don't think most scientific-oriented people do this, but some do, e.g. the aforementioned who misunderstand the scientific method).
Maybe I haven't woken up all the way, but I don't get the point of this article. All app stores (Amazon's, Google's, Apple's) have open source apps to some degree or another, and tons and tons more apps are built on open source libraries. So Microsoft's app store is on par with ... everybody else? Ok, great.
A big part of the problem is that in many countries (especially the US) the tax system is so broken that it has created enormous incentives to look for loopholes. Some commenters have noted that they pay more than they actually have to because they don't pay some accountant to go find all the ways to reduce it. Exactly! This is a shortcut way of saying that the cost exceeds the benefit. For a corporation, that is not the case, in part because corporations are taxed to death, so there is a large incentive to reduce their tax burden. It's that simple.
I really don't understand the attitude of some people on here who are outraged by companies taking advantage of legal ways to reduce taxes. If there is a legal way for a company to reduce its tax burden, it's naive to be upset that companies use it. Direct the outrage towards the bought congresspeople, if anyone, but really it should be funneled into fixing the actual problem: the government takes way too much.
In the US, the government taxes over a /third/ of all of a company's profits (http://en.wikipedia.org/wiki/Corporate_tax_in_the_United_States) at a bare minimum. That alone is a staggering amount of money. But that's before the money even makes it to any of the owners, who are also taxed. By many estimations, the total tax on people is *half* of gross income (http://www.nowandfutures.com/taxes.html - just one example, there are many).
Half! That's absurd! A government provides many services and I'm happy to pay my fair share for those services, but IMO half is far in excess of what is reasonable - the government does some nice things, but in no way is what it provides worth what it costs. What is fair and reasonable? Honestly, even low double digits seems to be pushing the limit of reasonable, but I'd jump at the chance to have the government take "only" a fifth of my total income.
So, if my total tax is in the neighborhood of 50%, and fair is at most 10%, but I'd settle for 20%, then if I discover some *legal* way to get that 50 closer to 20, will I take advantage of it? Absolutely! It's not unethical at all. I'm *already* paying an unethical amount of my total income, so reducing my tax to something closer to fair is something I'm happy to do.
Until real tax reform happens and people and companies are taxed reasonably, there will always be huge incentives to find every possible means of reducing one's tax burden.
Agreed! Higher education is widely available to those who want it enough to work for it. It could be made more affordable perhaps, the system isn't perfect, etc. but if somebody is truly motivated to pull themselves up and pursue a degree, there are many, many ways to make it happen without going into huge amounts of debt. Taking away the challenges (including labeling it a universal "right") isn't helping anybody - many of the challenges of going on to higher education are exactly the things that are needed to transform high school students into mature, responsible adults.
Amen! I finished my degree without any debt and it wasn't always a cakewalk, but it wasn't insanely difficult either. I knew my parents wouldn't be able to pay for it, so I got good grades in high school and landed a scholarship that helped. I had a job all through high school and college and tried to be frugal - stuff that I assumed everybody else would do.
I have a hard time feeling sympathy for people who leave school with absurd amounts of debt. Some debt might make sense in some cases, but huge debt seems foolish, especially when the graduate then whines about their burden and even more so when their degree is in a field with generally low wages and/or few job prospects. Nobody forced them into it, were they just not thinking things through? Did they have no plan?
+1 to all those who cited the Zebra. Relatively cheap, no mess (and I'm a lefty), fine detail for my tiny writing. There's a gel variant - avoid that.
Yeah, good point - I didn't think much about the tool issues, but I think you're right. For us it's always 1:1 - if it's a language / platform that feels like you must have an IDE, then we use that IDE for writing code, project management, debugging, etc.
As noted early, it's not really that cut and dry - I find developing in an IDE to often be pretty cumbersome - just get out of my way and let me tackle the problem I'm trying to solve. I don't do much Windows dev anymore, but I do think the VS IDEs were some of the best (VS 6.0 or whatever it was back in the day is still IMO the best ever), while Xcode and Eclipse are often maddening.
But it does seem to have a lot to do with the particular language and its libraries or frameworks. I've tried the IDE-less approach with Java/C#/ObjC and my productivity felt like it was a tiny fraction of what it was with an IDE. Conversely, over the years I've tried just about every major Python IDE and felt like there was very minimal benefit. That minimal benefit coupled with the annoyances of an IDE have always led me back to being most productive in emacs or vim.
That makes a lot of sense, yes, although even with duck typing the autocomplete plugins for Python IDEs are really good. This conversation has reminded me that the one for vim is actually really good these days, and yet I still don't use it (and now I'm curious as to why that is).
I think the thrust of my point was that using an IDE wasn't /all/ pluses, there are some drawbacks, so it comes down to whether or not the benefits outweigh the costs, i.e. it's not just a question of developing with, say, inline help vs developing without it.
Now I don't think the costs are /that/ huge, most of them are in the realm of nits and minor annoyances, but they do add up to enough to make me shy away from it when it's not virtually required. Whether it's a feeling of having to shoehorn my project into whatever constraints are required by the IDE's project management features, or the littering of IDE support files, the more I'm aware of the presence of the IDE, the more annoying it is. Case in point: I checked out an Android app from one of our other developers and it took me quite some time to figure out how to load it into Eclipse. I figured it was just my lack of experience with Eclipse, except that Google showed lots of other people with the same confusion. In the end I caved and moved the files into the subdirectory where Eclipse wanted them just so I could get moving. I don't really care about that specific example, but that is the sort of thing I run into with IDEs.
One of the things that I like about not using an IDE and just using vim is that my full development environment is immediately present on any machine I have to work on - just scp a tree with some useful plugins and config settings and troubleshooting a problem on a production box is hardly different than working on it locally. Anyway, it really does boil down to personal preference a lot, my point was just that an IDE is definitely not all plusses without any minuses.
I partially agree but don't think it's quite so cut and dry. You /can/ build very large systems without an IDE and be quite productive at it, i.e. I disagree with any assertion that an IDE is or isn't required to make you productive, efficient, able to build big things, etc. Further, not using an IDE does not necessarily imply monolithic files, either. I also haven't found any correlation between rate of defects and whether or not an IDE is used.
So, some of the reasoning in the article is a little off IMO, but so too is the implication that an IDE is universally the best/proper way to do modern development. ISTM that it has more to do with the language than other factors - for development in some languages, an IDE is nearly a requirement. In other languages the benefit is much less assured and can even be a net negative, at least for some people.
Modern IDEs can be great, but using them does come at a cost, so I think people end up using them in situations where there is a net benefit (and the opposite is true - people don't use them where there is a net cost to using an IDE). Personally, using a full-fledge IDE often leaves me with a feeling of it getting in the way, but I tolerate it because with some languages or platforms the IDE is still a net win.
This is nothing but an anecdote, but we have several non-trivial projects (100kLOC+ each) in C/C++, C#, ObjC, Java, and Python worked on by about 10 people (so not huge by any means, but not so trivial as to be meaningless) and:
* Everybody uses an IDE for the ObjC, C#, and Java projects
* About half use an IDE for the C/C++ projects (rest use vim)
* Nobody uses an IDE for the Python projects (most use vim)
What's interesting to me is that as far as I know everyone has /tried/ not using an IDE for Java/ObjC/C#, and everyone has tried using an IDE for Python, and there has never been any sort of mandate to go one way or another, and so the present situation is the result of everyone sort of landing where it feels most natural and where they are the most productive, and that we have the same results regardless of proficiency in a particular language (i.e. the C# experts and C# noobs end up with the same development environment, as do the Python experts and the Python noobs). The same also appears to be true regardless of language affinity - lovers and haters of Java use the same environment, lovers and haters of Python do as well, etc.
I do wonder if there is some sort of correlation between environment and the language. I know this is pretty subjective, but for me languages like Python feel like they rarely get in your way, and so it's interesting that when people in our company use Python, they gravitate towards development environments that are similarly lightweight. And conversely, for me a language like Java tends to feel like it gets in the way a lot (as in, you have to do lots of things that are satisfying the demands of the language that aren't directly tied to the problem you're trying to solve), and an IDE is indispensable because the IDE helps shoulder some of that burden.
Yeah, in those areas I tend to do 80-85. Not going higher could also be other factors - the older the car, the more it starts to rattle at those speeds. Also, the roads tend to be more remote so they have fewer lanes, which increases the odds that a zippy driver gets stuck behind somebody going "only" 80.
Yup, and in a few places the posted speed limit is 80, which means you go 85-90! :)
My experience is only a single data point of course, but I think I speed because I'm focused on the driving and usually want to get it done - I want to get out of traffic, stop dealing with all the stoplights and other motorists, and move onto something that either requires more of my focus or less. Driving is one of those tasks that takes enough of your attention that you can't focus on something else, but not so much that you feel engaged usually (which is probably another reason why I speed - it's riskier and therefore more engaging).
Further, a good driver often checks the gauges, dials, etc., so they are constantly looking at the speedometer, and fixating on it IMO contributes to the desire to speed - limit is 65 so I nudge up to 68 or 69, then over 70. Oops there's a cop, slow down. Ok, ease up again, get to 75, another cop slow down, etc. It almost becomes a lame game to deal with the boredom.
OTOH if I am in a self-driving car I can pretty much ignore the road and focus on a book or a laptop or the scenery or a conversation. While I'll always want to "get there" faster, whether I'm going at 65 or 68 or 72 becomes much less of an issue - I'd make that trade any day as it's similar to mass transportation but without all the stops along the way. And if self-driving cars get their own HOV-ish lanes to encourage adoption/throughput or if enough people switch to those cars, then overall we should have fewer traffic jams and accidents anyway, so the average speed can really be close to the speed limit (as opposed to right now where it's often bursts of speeding, then congestion, then speeding).
Sorry, but "Amazon's cloud has gone down" is wildly incorrect. From the sounds of it, *one* of their many data centers went down. We run tons of stuff on AWS and some of our servers were affected but most were not. Most important of all is that we had *zero* service interruption because we deployed our service according to their published best practices, so our traffic was automatically handled in different zones/regions.
Having managed our own infrastructure in the past, it's these sort of outages at AWS that make us grateful we switched and that continue to convince us it was a good move. It might not be for everybody, but for us it's been a huge win. When we started getting alarms that some of our servers weren't responding, it was so cool to see that the overall service continued on its merry way. I didn't even bother staying up late to babysit things - checked it before bed and checked it again this morning.
Firing up a VM on EC2 (or any other provider) != architecting for the cloud.
This also fits in well with the hashability of tuples vs lists - the latter aren't hashable, so they can't be used as e.g. dictionary keys, but typically that also simply makes a lot of sense: a tuple usually represents a record or a distinct "item", so it makes sense that it should be usable as a dictionary key because it's more or less a specific "thing", whereas a list can't be used as a dictionary key and this also typically makes sense: a list of a bunch of things as opposed to being something specific, so it's less sensical for it to be used as a key anyway.
I'd argue that the reason why tuples are hashable and lists aren't is precisely because of the difference in mutability
Yes, that's most definitely why one is hashable and the other isn't. I'm suggesting that that's largely separate from why you use one or the other - in Python, the technical difference between a tuple and a list may involve things like hashability and mutability, but that's rarely what leads one to choose one over the other.
What you're trying to represent is most often what pushes you one way or another. If you tracking sifting through a set of data to count the number of people with a particular left/right-handedness and gender, you typically wouldn't think of that as something you'd put into a two-item array. It's naturally a tuple because it represents a specific combination you're looking to track, e.g. (right, female).
IOW at a technical level lists and tuples are very similar, but I'm suggesting that issues of hashability and mutability aren't /normally/ the driving force for choosing one over the other. I think it'd be rare for someone to put something in a list and then say, "oops, better make that a tuple so it's hashable". Rather, if the combination of values represents a specific "thing" or combines to represent a unique value, then that sort of thing naturally ends up in a tuple more than in an array.
Circling back around, it's that difference in common usage that doesn't really map to the difference in how NSArray and NSMutableArray are typically used.
This isn't a rant against code completion - I think it's safe to say we've all used it for years prior to ObjC gaining traction due to iOS and yes, it is an expected feature of any modern IDE. What feels like a crutch about it with ObjC is that it's nearly impossible to be productive in ObjC without it. It's similar to developing in Flex if you've tried that.
I've heard the maintenance argument before and I somewhat agree with it, but in general if you're changing a method signature in any language and being diligent about it, then you'll be checking existing uses of it anyway (similarly, if you're relying on the compiler to find all the issues, then more often than not you're overlooking a bug).
As with the complaint about forced named parameters being redundant in the majority of cases, requiring it as a protection against future refactoring also seems a bit heavy handed - i.e. a cost with only a just-in-case benefit. And, similarly, coming from other languages where this isn't required, it feels cumbersome since in those languages we don't have that requirement and yet we also don't run into the types of problems these features help prevent.
I'm very eager to get to ARC, no doubt about it. As for the existing ways to get instance vars in categories, to me they all feel a bit on the side of hackery. That's just my perception of course.
[snip]
Seems very straight forward to me and very readable.
And that's very fair as this is, after all, a largely subjective question. To me that sort of code scans very poorly (as does the equivalent C++) and is one of the things I dislike about the language. Still, I completely understand that other people have a different reaction to it.
Like I said before, it's bad form to do the latter without a comment or other contextual information explaining why you have those hardcoded values in there. The fact that you are explicitly saying which one is x,y,z, or index is beside the point - someone reading the code is going to be less interested in which '1' corresponds to which parameter and more wondering why those values are hardcoded. And once they know that, then explicitly calling out the names of the parameters has less value anyway.
(the purpose of the comment is much more than just telling which values are which, it's a level-of-intent comment, and should be there regardless)
The other point already mentioned is that even if in this extremely specialized case (where you have 4 hardcoded values and no variables) it provides value (and I'm skeptical it does, due to the above), that still doesn't justify requiring it all the other times where it's just redundant.
There is nothing "Magic" about some constants. There is no reason to put numbers that will never change in variables. Named parameters make the comment in the Objective C example not necessary.
Not at all. The idea is that if you have some hard coded set of values going on, then either there is a comment explaining why or the surrounding context makes it abundantly clear. This should be the case whether you're in ObjC or some other language - i.e. things you should already be doing will be providing nearly as much if not all of the value that forced named parameters provides. So in one extremely contrived case there might be a modicum of debatable benefit, but in all other cases you have to do it anyway even when there is no benefit.
Again, continuing with this contrived example, other languages handle this better. For example, in Python you'd normally do something like:
self.drawAt(x, y, z, index)
but in the case where you have some hard coded values you can make it explicit for clarity:
self.drawAt(x=1, y=1, z=1, index=1)
That's the beauty of it: in normal cases where naming the parameters is redundant (since it's implied by the names of your variables) you can leave it off, but in the corner cases where the parameters don't convey as much information you can, if you want, be explicit. This is why the ObjC way is so grating: rather than giving me the option of doing what makes the most sense, the language designers chose one of the two and IMO chose the wrong one - you pay the price every time even if most of the time you don't get any benefit from it.
Your complaint about named parameters is just you have to type more.
No - my complaint is that it's more writing and - more importantly - more reading. My biggest complaint is that the verbosity is such that the overall readability tends to be reduced due to the clutter. Given that code is read a lot more than it is written, this is a big deal to me.
Of course all of your arguments are contrived bullshit.
LOL, you do recognize of course that the example we're arguing about is one provided by you or some other AC, and one where we're calling a function with 4 hard coded values all with the value of 1, right? Contrived indeed!