Hands down excellent. High-level overviews, more detailed usage guides, fully-detailed references, and internals. Well-written, well-organized. And guess what else? A TABLE OF CONTENTS at the root, so as soon as you find your way to the docs, you can see what's there and how they're organized. Too many OSS projects lack that. (Oh sure, there's tables of contents, lots of them, for individual areas of documentation which are spread all over the place--not the same thing.)
Ours was the model with two distinct compartments.
I have a very similar one, but it was not recalled. I kind of wish it had been--cooks very unevenly, and corrodes out more rapidly than it should, so it's going to die an early death, but of course out of warranty.
Ugh. That function syntax might look ok for a couple short named variables, but it'll be super ugly for anything that users proper variable names and has more than a couple parameters. Where's the recommended break point? Some styles will have all parameters on one line and the returns on another. Another style will have each variable on it's own line regardless if it's a function argument or return value and it'll easy to accidentally overlook something. The styles for that are gonna be messy.
How is that different from ANY possible alternative syntax???
Ahead of its time and just a decade or so behind Smalltalk in this regard.
Later than Smalltalk, but NOT behind. Smalltalk suffered the same problem that all other single-inheritance class libraries of the time did--hugely deep inheritance hierarchies, with arbitrary, thus hard-to-remember, ordering. With NextStep, that was not the case--the judicious use of delegates to break out functionality that clients could customize, somewhat similar to AOP, massively reduced the depth and complexity of the inheritance hierarchy, but without introducing the problems that multiple inheritance brings. So Objective-C started with a core of features taken directly from Smalltalk, but the end result was actually much cleaner in the big picture.
The fact that this question gets asked basically every year should more than sufficiently answer the question.
Exactly.
The rapid deployment of high speed internet access, fiber to the home, cable and other last-mile technologies, even in developing nations, means that the problem of needing offline access to functionality is becoming more and more a moot point. It is also rapidly doing away with the problem of lengthy load times for bulky web code.
Oh, bullshit. Millions of people in developed nations (particularly the U.S.) have "broadband" that is a few hundred Kbps, or a couple of Mbps--let's just call it 3 orders of magnitude, or more, slower than a spinning disk. And of course there's an order of magnitude difference, or more, in latency as well. And of course, absolutely nothing about the deployment of high-speed internet access deserves to be called "rapid"! Remember, we were hearing about how the rapid rise in internet access speed was outpacing CPU speed increases and would soon make data transfer times irrelevant in the 1990s!
And that's before we even get to the performance difference between JavaScript DOM manipulation vs compiled C manipulation of native view/control hierarchies. Yes, I've heard about how much faster JavaScript has gotten. I use it. I also use native toolkits. You can show me the micro-benchmarks all day long; doesn't change the fact that a complex UI in JavaScript is vastly slower.
And that's before we even get to the performance difference when dealing with more intense data manipulation.
And that's before we even get to the higher memory usage for a control in the DOM than for a native widget. (Don't believe me--inspect an input element, and tell me how many pointers it holds to objects & prototypes...)
Obviously the solution is batteries, which unfortunately isn't there yet from a cost perspective. But I think they'll be there soon.
Tesla's PowerWall is on the cusp. A few years to improve the capacity at the same price point, coupled with a few years' worth of increases in electric rates, and it will be there.
Somebody should drag the developer that build that monstrosity out back and shoot him (or her). Not only because of how it doesn't fit in, but because the living spaces inside are just awful.
There were so many ways to use that space better... (2x2 instead of 4x1 for starters...)
...and the science and the modeling processes have only gotten better over the last four decades.
Yes. Because of the complexity of the problem, they've not been terribly good at making predictions here. But they are the best we've got, and it makes more sense to listen to them than a lunatic with no science whatsoever behind him. (It makes some sense to question specifics of global warming, but it's long past the time when it made any sense to outright deny it and try to call yourself a "sceptic". I am a sceptic, and I say this guy is an deluded fool.)
The focus is on the problems with rogue officers, and that is exactly as it should be. The focus is on what needs to be changed, not on what is already fine as is.
Don't be so melodramatic. The ones who died at the hands of the cops are those with multiple infractions and long rap sheets who physically resisted arrest. Or waved around what appeared to be a weapon and refused to drop it when ordered to do so.
Bullshit. Cases this year completely contradict that.
Now that we live in a world where healthcare is primarily self pay for the first few thousand, we need to take this into our own hands. Ask what a procedure costs before it's done...
Yeah, good luck with that--for anything other than the most trivial example:-(
This is a good idea for single-threaded tasks which can't be sped up anymore by distributing that task over multiple cores....... maximum single-core speed is ideal for certain workloads, and the extra cores would just be wasted.
To be clear, those two are 4-core and 10-core parts...
Looks good for my EM simulation needs. Too bad the licensing to take advantage of all those cores is very expensive.
Intel has 2 parts just for you: E7-8891v3 and E7-8893v3, maximum clock frequency, fewer cores. Seriously, they are designed and marketed specifically for "Lower per-core software license fee costs Higher per-core performance".
For an eleven year old, the best solution was to tape over the corner of the disk and reformat it to 720K.
Heheh, I had totally forgotten about that.
And that I knew people who figured out that, for whatever purpose, office supply stores had a device similar to a hand-held single-hole punch which would punch out the perfect-sized rectangle to go the other way.
I understand your background, but honestly don't think you are qualified based solely on that. Application programming is a whole other world, with different tools, different practices and different objectives.
Where exactly did he say that he was applying for application dev jobs? When I read the post, I assumed he was complaining about being turned down for jobs for which his qualifications were appropriate. Why did you assume otherwise?
...there is a myth that programming skill is somehow distributed on a U-shaped curve and that people either "suck at programming" or that they "rock at programming", without leaving any room for those in between...
30 years full-time in the industry, NEVER heard that before. There's a lot of companies doing mediocre work who believe their mediocre developers are rock stars. That's because to marketing and management types, successfully getting a computer to do anything at all is magic, and they cannot readily distinguish between ho-hum "accomplishments" and serious ones.
The truth is that programming isn't a passion or a talent...
Bull. Fucking. Shit. This is not a truth nor a new insight, it's just wishful thinking, and this author is far from the first management prick to delude himself this way.
...it is just a bunch of skills that can be learned.
Of course it is. But excelling at it takes certain aptitudes and talent. Confusing "it is a just a bunch of skills" with "pretty much anybody could potentially be as good as anybody else" is just stupid.
If we embrace this idea that "it's cool to be okay at these skills"—that being average is fine—it will make programming less intimidating for newcomers.
Well now, that's actually true. But it's equally true that all those jobs ads for "junior" or "intermediate" developers are looking for okay developers, not rock stars. There's jobs for them, and I've never met anybody who expected newbies to excel. So it's kind of an implicit straw man argument--but still, we should all be careful not to drive away newcomers, and keep in mind not creating this (possible) problem.
...the tech industry is rife with sexism, racism, homophobia, and discrimination...
Maybe where this asshole worked;-) And certainly there are companies where this is true, but how common is it? Where I've worked, I really believe the women and minorities were treated well. Granted I've never actually asked them that question, but then again, exactly how would that make them feel like they fit in?
This is the "10x programmer" who is so good at his job that people have to work with him even though his behavior is toxic.
No way. We all know (I hope) that although the 10x (or 25x, or 50x, or infinity-x) must have certain personality traits related to sustained concentration and so on, that when it comes to pleasant vs asshole, they actually exist in a pretty normal distribution. The problem of course is that because they are somewhat rare, it's harder to screw up the nerve to fire one if you think you have one.
And, BTW, there are infinity-x programmers. There are plenty of problems that average programmers would simply not even be able to solve at all--not the majority of work of course. Relative to the amount of work available, problems that require unusual skill to even solve are rare. But given the huge amount of work, there are plenty of problems beyond the grasp of the average...
They mostly remove the safety equipment that's redundant in a Tesla battery pack. Normally they pack a thermal fuse that kills the battery if it overheats or experiences sufficient current overflow.
They have revealed that. (They didn't really have a choice, since they wanted to patent parts of the process, to stop others from duplicating it by tearing apart their battery packs and figuring it out.)
There is no information, none whatsoever, which would confirm that's the only difference in the customized cells they buy from Panasonic.
The point here is that just because some batteries are made from carbon and lithium does not make them equal.
And Tesla's are made from nickel and lithium. They haven't really revealed much else publicly except for 3 things: nickel, removal of safety systems from individual cells, and how they pack them together.
Slashdot Mirror
Hands down excellent. High-level overviews, more detailed usage guides, fully-detailed references, and internals. Well-written, well-organized. And guess what else? A TABLE OF CONTENTS at the root, so as soon as you find your way to the docs, you can see what's there and how they're organized. Too many OSS projects lack that. (Oh sure, there's tables of contents, lots of them, for individual areas of documentation which are spread all over the place--not the same thing.)
Ours was the model with two distinct compartments.
I have a very similar one, but it was not recalled. I kind of wish it had been--cooks very unevenly, and corrodes out more rapidly than it should, so it's going to die an early death, but of course out of warranty.
Just curious: Perfect Flame from Lowe's?
Ugh. That function syntax might look ok for a couple short named variables, but it'll be super ugly for anything that users proper variable names and has more than a couple parameters. Where's the recommended break point? Some styles will have all parameters on one line and the returns on another. Another style will have each variable on it's own line regardless if it's a function argument or return value and it'll easy to accidentally overlook something. The styles for that are gonna be messy.
How is that different from ANY possible alternative syntax???
Ahead of its time and just a decade or so behind Smalltalk in this regard.
Later than Smalltalk, but NOT behind. Smalltalk suffered the same problem that all other single-inheritance class libraries of the time did--hugely deep inheritance hierarchies, with arbitrary, thus hard-to-remember, ordering. With NextStep, that was not the case--the judicious use of delegates to break out functionality that clients could customize, somewhat similar to AOP, massively reduced the depth and complexity of the inheritance hierarchy, but without introducing the problems that multiple inheritance brings. So Objective-C started with a core of features taken directly from Smalltalk, but the end result was actually much cleaner in the big picture.
Of course they forget that free access to addictive substances has been shown in study after study to cause problems.
Uhm, not, it has not.
The fact that this question gets asked basically every year should more than sufficiently answer the question.
Exactly.
The rapid deployment of high speed internet access, fiber to the home, cable and other last-mile technologies, even in developing nations, means that the problem of needing offline access to functionality is becoming more and more a moot point. It is also rapidly doing away with the problem of lengthy load times for bulky web code.
Oh, bullshit. Millions of people in developed nations (particularly the U.S.) have "broadband" that is a few hundred Kbps, or a couple of Mbps--let's just call it 3 orders of magnitude, or more, slower than a spinning disk. And of course there's an order of magnitude difference, or more, in latency as well. And of course, absolutely nothing about the deployment of high-speed internet access deserves to be called "rapid"! Remember, we were hearing about how the rapid rise in internet access speed was outpacing CPU speed increases and would soon make data transfer times irrelevant in the 1990s!
And that's before we even get to the performance difference between JavaScript DOM manipulation vs compiled C manipulation of native view/control hierarchies. Yes, I've heard about how much faster JavaScript has gotten. I use it. I also use native toolkits. You can show me the micro-benchmarks all day long; doesn't change the fact that a complex UI in JavaScript is vastly slower.
And that's before we even get to the performance difference when dealing with more intense data manipulation.
And that's before we even get to the higher memory usage for a control in the DOM than for a native widget. (Don't believe me--inspect an input element, and tell me how many pointers it holds to objects & prototypes...)
Yes, it would be insane to use flash memory for archival purposes as well, but it still should easily retain its contents for at least a decade.
Nope. It's nowhere near that long--more like 1 year, not 10. And that time reduces as the flash wears through being written.
Obviously the solution is batteries, which unfortunately isn't there yet from a cost perspective. But I think they'll be there soon.
Tesla's PowerWall is on the cusp. A few years to improve the capacity at the same price point, coupled with a few years' worth of increases in electric rates, and it will be there.
There are precedents for replacing airports close to the center city with modern, more outlying airports.
Sure. And there are precedents for expanding in-city airports bounded by water. Boston.
Somebody should drag the developer that build that monstrosity out back and shoot him (or her). Not only because of how it doesn't fit in, but because the living spaces inside are just awful.
There were so many ways to use that space better... (2x2 instead of 4x1 for starters...)
...and the science and the modeling processes have only gotten better over the last four decades.
Yes. Because of the complexity of the problem, they've not been terribly good at making predictions here. But they are the best we've got, and it makes more sense to listen to them than a lunatic with no science whatsoever behind him. (It makes some sense to question specifics of global warming, but it's long past the time when it made any sense to outright deny it and try to call yourself a "sceptic". I am a sceptic, and I say this guy is an deluded fool.)
The negative focus on officers is 99.9% wrong.
The focus is on the problems with rogue officers, and that is exactly as it should be. The focus is on what needs to be changed, not on what is already fine as is.
That's an interesting finding of facts on your part - can you cite some established evidence?
The police report, asshole.
Don't be so melodramatic. The ones who died at the hands of the cops are those with multiple infractions and long rap sheets who physically resisted arrest. Or waved around what appeared to be a weapon and refused to drop it when ordered to do so.
Bullshit. Cases this year completely contradict that.
Now that we live in a world where healthcare is primarily self pay for the first few thousand, we need to take this into our own hands. Ask what a procedure costs before it's done...
Yeah, good luck with that--for anything other than the most trivial example :-(
This is a good idea for single-threaded tasks which can't be sped up anymore by distributing that task over multiple cores....... maximum single-core speed is ideal for certain workloads, and the extra cores would just be wasted.
To be clear, those two are 4-core and 10-core parts...
Looks good for my EM simulation needs. Too bad the licensing to take advantage of all those cores is very expensive.
Intel has 2 parts just for you: E7-8891v3 and E7-8893v3, maximum clock frequency, fewer cores. Seriously, they are designed and marketed specifically for "Lower per-core software license fee costs Higher per-core performance".
My understanding is that modern household water wells generally use reverse osmosis systems.
Nope. Reverse osmosis is highly inefficient.
For an eleven year old, the best solution was to tape over the corner of the disk and reformat it to 720K.
Heheh, I had totally forgotten about that.
And that I knew people who figured out that, for whatever purpose, office supply stores had a device similar to a hand-held single-hole punch which would punch out the perfect-sized rectangle to go the other way.
I understand your background, but honestly don't think you are qualified based solely on that. Application programming is a whole other world, with different tools, different practices and different objectives.
Where exactly did he say that he was applying for application dev jobs? When I read the post, I assumed he was complaining about being turned down for jobs for which his qualifications were appropriate. Why did you assume otherwise?
This guy doesn't know how to measure programming ability, but somehow manages to spend 3000 words writing about it.
Wow. I spent so many more words below deconstructing his argument, before I noticed how much more efficiently you had done it.
You've proven that the mythical "25x curmudgeon" actually exists ;-)
...there is a myth that programming skill is somehow distributed on a U-shaped curve and that people either "suck at programming" or that they "rock at programming", without leaving any room for those in between...
30 years full-time in the industry, NEVER heard that before. There's a lot of companies doing mediocre work who believe their mediocre developers are rock stars. That's because to marketing and management types, successfully getting a computer to do anything at all is magic, and they cannot readily distinguish between ho-hum "accomplishments" and serious ones.
The truth is that programming isn't a passion or a talent...
Bull. Fucking. Shit. This is not a truth nor a new insight, it's just wishful thinking, and this author is far from the first management prick to delude himself this way.
...it is just a bunch of skills that can be learned.
Of course it is. But excelling at it takes certain aptitudes and talent. Confusing "it is a just a bunch of skills" with "pretty much anybody could potentially be as good as anybody else" is just stupid.
If we embrace this idea that "it's cool to be okay at these skills"—that being average is fine—it will make programming less intimidating for newcomers.
Well now, that's actually true. But it's equally true that all those jobs ads for "junior" or "intermediate" developers are looking for okay developers, not rock stars. There's jobs for them, and I've never met anybody who expected newbies to excel. So it's kind of an implicit straw man argument--but still, we should all be careful not to drive away newcomers, and keep in mind not creating this (possible) problem.
...the tech industry is rife with sexism, racism, homophobia, and discrimination...
Maybe where this asshole worked ;-) And certainly there are companies where this is true, but how common is it? Where I've worked, I really believe the women and minorities were treated well. Granted I've never actually asked them that question, but then again, exactly how would that make them feel like they fit in?
This is the "10x programmer" who is so good at his job that people have to work with him even though his behavior is toxic.
No way. We all know (I hope) that although the 10x (or 25x, or 50x, or infinity-x) must have certain personality traits related to sustained concentration and so on, that when it comes to pleasant vs asshole, they actually exist in a pretty normal distribution. The problem of course is that because they are somewhat rare, it's harder to screw up the nerve to fire one if you think you have one.
And, BTW, there are infinity-x programmers. There are plenty of problems that average programmers would simply not even be able to solve at all--not the majority of work of course. Relative to the amount of work available, problems that require unusual skill to even solve are rare. But given the huge amount of work, there are plenty of problems beyond the grasp of the average...
They mostly remove the safety equipment that's redundant in a Tesla battery pack. Normally they pack a thermal fuse that kills the battery if it overheats or experiences sufficient current overflow.
They have revealed that. (They didn't really have a choice, since they wanted to patent parts of the process, to stop others from duplicating it by tearing apart their battery packs and figuring it out.)
There is no information, none whatsoever, which would confirm that's the only difference in the customized cells they buy from Panasonic.
The point here is that just because some batteries are made from carbon and lithium does not make them equal.
And Tesla's are made from nickel and lithium. They haven't really revealed much else publicly except for 3 things: nickel, removal of safety systems from individual cells, and how they pack them together.