Now, now. You can't claim that they aren't similar, because the concept here is unifying both launchers and task lists, which was what distinguished docks from task bars before.
They have different features, yes. Their animations are very different, that's actually where most of the differences lie, yes. But now, as far as task/window management goes, they are pretty much the same thing.
I wouldn't hesitate to call Gnome Shell's activity bar thingy a dock, for one, even though it wouldn't matter; the dock doesn't have the same prominence that environment as in Windows or Mac OS X.
Still, I don't see the problem with them retaining their traditional name for their UI element, given that the new taskbar was still an evolution from the previous one.
Now, with respect to the interaction, MS is mostly following the trend here, as most are converging towards search for launching, and with the reduced task management of smart phones, I would expect that developers would now be encouraged to make their apps save and restore their states without the user's intervention, and thus applications where you actually have to do the clean up, save, close, start, open, repeat cycle would also become rarer, so that those session-restore features that some DEs have would actually start to be used, further downplaying the actual launching of applications.
"Most users never program their computers themselves. Anyone can plainly see the historical trend from the late 80s onward that the average user has no interest in the internals of their computers or in investing time in automation which experts can do for them.
I support Apple 100% in moving forward and removing the option of running, or producing, unreliable homebrewed code without authorization.
Actual programming experts can get a Mac Pro with and their programming license from Apple, or just run Linux on a PC."
Yes, I certainly trust that we won't be seeing posts like the above in the eventuality that Apple puts further restrictions on their (customer's) computers.
I don't think Apple would be so quick to throw away the hacker market like that. Do you think they don't know that their computers are incredibly popular for sysadmins, web developers, and other developers who aren't necessarily writing Cocoa apps?
If I'm wrong I'll eat my hat. AND I'll switch to Linux.
Well now, how are you going to map this issue to something which isn't, in the end, anecdotes, since it pertains to human emotional responses? Are you asking those ethereal (probably fake, as you said, who even knows what this gender bias thing means?) other people to come up with a scale where they have to put it in 1-to-ten how belittled they felt?
Have you stopped to think of why these kinds of posts are held up to such scrutiny in contrast to, say, posts about other, not-related to gender, and thus mostly affecting men (this last point shouldn't need explanation), matters? Like, bad experiences with VCs or age discrimination and some such?
I would hazard a guess that the distinction is not due to something very rational, unless you get very cynical and paranoid.
> Because apparently women are incapable of being overcompetitive jerks, and it (obviously) has to be a male/female dynamic.
It sort of is if its impact is mostly on women, and the behavior is mostly accused on men. Yes, this last point would require something more akin to actual statistics to be turned into the reason for some sort of castigation on men in general, but I haven't seen any of that as of now, really. Unless you count people feeling personally attacked by the existence of this discussion, of course.
> Here's the other thing, and this is kind of a tangent, but a theme I see with a lot of these blog posts isn't that someone was actively hostile, but rather, that someone did something "offensive". [...]
Well, we are quite glad that none of these problems affect you, but this conversation wasn't about you in particular, was it?
> It seems to me that there are two ways one can approach this subject. On to proclaim that these are intentional acts of portraying females in a negative light and keeping them out of the tech industry.
I'm not sure I've actually seen this interpretation being presented here or anywhere else (though I veer off blog comments, they are sometimes good, but not worth the risk of reading the Facebook-quality ones). I think it's pretty well recognized that this is the product of both immaturity and stubborn ignorance, which makes it acceptable for too many folks in this industry to just trample over women nonchalantly with their attitudes and ``jokes''.
But isn't Jython years behind the CPython version, PyPy still experimental and on Python 2.x, and IronPython mostly a novelty? Stackless seems in better shape, though, and couldn't say anything in respect to usage.
The argument for Java is clearer and it's a well known case of the interaction of multiple implementors, and thus it has an standardization process.
I would say that CPython, PyPy and Stackless are in pretty strong competition in different areas. PyPy only supporting 2.x seems to be a relatively unimportant metric given the slow adoption of 3.x. As for it being experimental, perhaps technically but I do believe its used in production in many places. From what I know Stackless gets a large portion of its support from CCP games due to its use in Eve Online. I'm sure there are others but its use case is relatively unique.
In the grand scheme of things, the differences between CPython and PyPy are minor. Stackless is a special case. Relatively Python has very little language fragmentation. It has more of what I'd call "implementation fragmentation," but not too much of that either.
I upvoted you. This whole semicolon war is the most banal and self-aggrandizing conflict I've seen in a while, rife with as much vanity and childishness a the ``blogosphere'' allows, as evidenced by this post. Can we move on, please?
At least everyone acknowledged that the editor war was an inside joke, I would gladly have an editor thread every week on HN over this.
So you could have predicted this yesterday? Just because it's codified somewhere, it doesn't make it clear, or anything other than a whim, or a product of circumstances, at best. That's not how languages should be defined, even if PHP clearly demonstrates that they can end up that way by chance.
Rasmus' lack of foresight does not make it reasonable.
The point, however, is that you shouldn't pepper your language with operations which have consequences as hard to foresee as this with no good reason, and I really don't think that saving yourself some type conversions here and there would do.
"no good reason" is entirely subjective, though. If your purpose is to make the language simpler to newcomers, implicit conversions everywhere are a great way to get things done. And the popularity of PHP (especially for new-to-programming people) heavily supports that they made the correct decision to work well for that market.
The same kind of logic is used to make `false == ""` true. Or any 'falsy' language. If you want strictly typed behavior, yes, it's stupid to do that. If you don't, then it makes some things simpler, at the expense of more edge cases that are unlikely to happen - note that this bug was reported in 2011, and people are acting like it's a new thing. Because it comes up so rarely that, while it technically exists, many people never encounter it.
> "no good reason" is entirely subjective, though. If your purpose is to make the language simpler to newcomers, implicit conversions everywhere are a great way to get things done. And the popularity of PHP (especially for new-to-programming people) heavily supports that they made the correct decision to work well for that market.
You are right, in a way. Sure, it may attract and retain more newcomers, but that's like saying that tobacco is "teenager friendly". I think it's not beginner friendly at all if you must have years of experience to avoid the innumerable pitfalls which PHP lays for you all over the place, learning, e.g. the range of Integers in PHP, which defines when a string will be either a float or an int, or that you should actually use strcmp.
In Python, Ruby, or heck, Haskell, you'd just have to do == and there would be no surprises.
I agree entirely, but we're thinking like programmers. Grab someone who's never programmed at all and ask them if `123 is equal to "123"`.
This essentially breaks down to the top-down vs bottom-up education style debate. You can learn the gritty details and get caught up in minor details that may not matter in other languages, or learn how to do something, and get tripped up by the details in other languages. Similarly, we could teach kids abstract algebra, or basic +-*/ and then over-simplify when they try to divide by zero.
Neither is ideal, both have useful traits and problems, so we have to pick one. Or try to come up with something radically different.
edit: to ask it another way: if PHP is a massively-popular gateway drug to the world of programming, but it gives some people horrible flashbacks for the rest of their lives, do you want to make it illegal and close the door to a huge number of people?
No, it doesn't. Language designers make lots of decisions that end up being silly. But they make them. In PHP, if it looks like a number, it will get treated like a number when being compared via ==. It's a simple, well-established, fundamental rule.