Pacabel

Nobody has suggested there's anything wrong with playing with hula hoops, even when it's adults doing it. It just doesn't seem like something that should be done at work, or at work-related events.

It has been tried before.

One example I can think of immediately is Grail, which was implemented in Python: https://en.wikipedia.org/wiki/Grail_%28web_browser%29

Another is HotJava, which was implemented in Java by Sun: https://en.wikipedia.org/wiki/HotJava

The results were less than stellar. Neither browser was really comparable to contemporary browsers written in C or C++ in terms of features and performance. Those factors are just too important to overlook, even in the name of security.

But those "obstacles" and "hurdles" can themselves be exploited in some cases. If they're software-based, then they can just end up making the attack surface much larger.

Patrick, in your first paragraph you admit that there are breaking changes to Rust. Yet in your second paragraph you ask for evidence of the lack of stability? Your first paragraph provides the evidence that you're looking for!

Had I (or anyone else) written code a mere week ago using the old Chan and Port conventions, we'd already have to be updating our code. That's not stability.

I think it'll be safe to say that Rust is headed toward stability once you've committed to not making any more breaking language or library changes, you have a separate code branch receiving only fixes, there are releases available, and at least some assurance is given that any issues that do arise will at least be investigated for a reasonably long period of time.

Until we actually get at least one of those releases, I don't think we can consider Rust to be moving toward stability. We'll have to consider it a moving target, and we'll have to continue inquiring as to when it will start to stabilize.

What's the business justification for using "dialog" when the project leader(s) have requested "dialogue", however?

I think it's obvious that it's good to "get things right" as much as possible before deciding to limit further changes.

However, at some point it needs to be realized that perfection will never be achieved. This is especially true for a programming language that aims to be a "practical language" (as it prominently states on its web page). Practicality requires usability. Usability requires stability.

We keep hearing about how Rust 1.0 is supposedly going to be released sometime later this year. Yet instead of seeing things stabilize, we're still seeing breaking changes like the one mentioned here. It starts to make some people skeptical about when Rust will actually be seriously usable.

Why was it so critical to spell it "dialog", rather than "dialogue", as the higher-ups in the project apparently preferred?

There does seem to be some truth to what you're suggesting.

For whatever reason, there's a propensity for this sort of drama to occur within organizations and at events where Ruby and Ruby on Rails, or users of such technologies, are involved in some way.

Off hand, I can think of that controversial presentation at GoGaRuCo a few years ago, the controversy about the diversity of the presenters at the BritRuby conference a bit later, and this matter here. Then there was that whole "Donglegate" incident, which while it occurred at PyCon, it involved at least one person with some ties to the Ruby community. I'm sure there are other events I'm missing, too.

Maybe it's just the so-called "brogrammer" culture that's so ingrained within the Ruby world that's responsible. Regardless, for a community that's actually quite small, there seems to be a whole lot of this sort of strife.

Gender seems quite irrelevant when it comes to what colechristensen is saying. It'd apply equally well to a male who feels wronged in some way at his place of employment.

"Reasons" are merely statements of why something is as it is. Justification isn't used.

"Excuses" try to put an unjustifiably positive (or perhaps a less-negative) slant on the explanation of why something is as it is.

balladeer wrote things like, "So, there was no way I was going to pass my 10+2 (last school year) without cheating and I am lucky that I somehow managed to cheat." and, "I wish I could have cheated better so that the meagre Chemistry score couldn't bring my total % to around 75."

To me, those appear to try to make it sound like the cheating was somehow okay, or even a good thing, even though this cheating was apparently covering up a lack of ability. They aren't merely saying why cheating was used; they try to make it sound acceptable, when it clearly isn't.

Even a minority of people engaging in a particular behavior can have a very significant impact on a culture as a whole. It's perfectly valid to say that the culture thus suffers from some sort of a problem, even if not everybody associated with that culture is responsible for the problem.

Going based on the information in the article, and assuming it's correct, there does seem to be at least some sort of a problem with cheating far beyond what we see in other cultures, and it does appear to be widespread. The preventative actions described would be very unexpected in many other cultures, and totally unthinkable in others.

Keep in mind that the level of hype often doesn't correspond to the actual amount of usage a technology experiences.

Yes, Ruby on Rails has been widely and frequently publicized. Yes, there are some people who have a semi-religious devotion to Ruby on Rails, and are quite vocal about it. Yes, a number of books have been written about it. Yes, training is available for it.

But in reality, we really don't see it used all that much, at least compared to PHP, Java, and ASP.NET. The numbers given in that graphic may not be exact, but I wouldn't be so quick to rule them out, either.

What kind of Android device did you have? What version of Android was it running?

Maybe in 4 or 5 years, if things go well. There hasn't even been a 1.0 release yet. That's the bare minimum necessary for a lot of existing C++ users to even consider Rust as a potentially viable option.

Assuming Rust 1.0 is released sometime this year, it'll still take a number of years before Rust even begins to offer the very wide range of libraries/frameworks that are available to C++ developers.

Interfacing with these existing C++ libraries/frameworks may speed things up, but at that point its disputable whether it's really Rust being used.

Rust may be among the most promising alternatives, but it's just not there yet, and won't be for some time.

How does that help remedy the other four problems he mentioned, especially the ones totally independent of input devices, though?

What makes you think that JavaScript will still be the flavor-of-the-day preferred by this crowd tomorrow, though?

They were pretty gung-ho about Ruby and Ruby on Rails between 2005 and 2010 or so. Then their hype moved to JavaScript and Node.js quite rapidly. It'll very likely move on to something else soon enough.

The consistency of a UI is quite distinct from the quality or the usability of a UI. You're incorrectly blurring these very different concepts.

I never claimed that all UIs back then were "perfect", or that there weren't "badly designed" UIs. I was very clearly talking about consistency between different applications running on the same system.

When using applications from that period of time, one could expect to find a menu bar and menus that were quite similar to those of other applications. Of course there were application-specific menus and items, but there was at least a common subset shared by nearly all applications, especially any that were designed with even the minimal level of care.

The same held true for toolbars, keyboard shortcuts, common dialogs, and so forth. There were also general conventions for how the application-specific parts of UIs looked and behaved. While not everyone followed these conventions, of course, most of the major and seriously-designed applications did.

We have lost much of that today. It's particularly bad when it comes to mobile apps, and getting worse when it comes to desktop applications. Yes, Microsoft and Apple themselves are to blame, to some extent. But it goes much beyond that these days. Inconsistency is the norm, and that does lead to inefficiency.

This really wasn't an issue in the 1990s and even into the early 2000s. Back then, most applications running on Windows, Mac OS and even the various commercial Unixes followed rather clear and uniform UI conventions.

There were differences between applications running within the same ecosystem, of course, and not as wide of a range of device types. But because of the greater consistency, it was generally much easier to learn how to use new applications. A lot of existing knowledge carried over, and was immediately applicable when using a new application.

This uniformity has unfortunately never really developed well on the various mobile platforms used today. It has deteriorated quite badly under Windows, with Microsoft themselves being somewhat responsible for this. The situation is perhaps the best under OS X. But even here we've still seen applications like Chrome and Firefox use non-standard UIs.

Those arguments aren't very convincing.

Launching in just 16 out of 190+ countries isn't very impressive. That's well under 10% of the entire world.

Likewise, having more market share than the 4th or 5th place competitor, but still being significantly far behind the leaders, isn't very impressive either. It's even less impressive when this is in a rather small and irrelevant market.

And the web argument isn't very good, either, given that Android, iOS, BlackBerry OS, and the other major players support the same technology.

All I see here is Mozilla spending a lot of time and effort on a product that's seeing very little adoption, while only being able to do a fraction of what its competitors are able to do.

That's just not a way to gain influence, and it's not a way to maintain whatever influence they still have thanks to their success with Firefox in the distant past.

Such names become much less memorable once there are numerous ones that share the same format.

It can rapidly get to the point where people remember that the name has an -ify or -ly or -joy suffix, but can't remember what the root word was.

If you want to prove your point, using totally unrealistic micro-"benchmarks" such as those is by far the worst way about doing so. You're better off giving no evidence whatsoever than you are referring to those.

How is this "pushing the envelope"?

Running existing software in some convoluted browser-based environment, and giving a worse experience in most ways, doesn't really seem like innovation to me.

I think we could say it was pushing the envelope if the browser experience was superior to the native experience in every or almost every way. But that just isn't what we're seeing with these demos.

From what I can see, Mozilla is generally going in a direction that's alienating existing users, without necessarily bringing in any new ones.

For example, it's widely understood today that Firefox has a much smaller share of the market now than it did a few years ago. Most measures I've seen show a drop from somewhere in the mid 30%'s down to under 20% today. Proportionally fewer Firefox users means less influence over the future direction of the web, of course.

SeaMonkey never really had that much penetration to begin with, and still remains basically irrelevant.

Firefox OS doesn't really seem to be taking off. While it may sound nice from an ideological standpoint in terms of openness and standards and all of that, in practice it doesn't sound very enjoyable or practical to use. I've seen enough people show displeasure over the low-end devices it's commonly used with, with the highly restrictive development environment (being forced to essentially use JavaScript/HTML5/CSS for apps), with a lack of features, and a lack of apps. Those are very serious and fundamental shortcomings.

Thunderbird and Persona have both been "turned over to the community". That appears to be a polite way of saying that Mozilla has given up on them.

Asm.js is pretty unremarkable. It's a human-unfriendly subset of JavaScript. NaCl is a much better approach that would ideally be adopted by the major browsers. Unfortunately, we've seen nothing but hostility toward it from Mozilla.

Rust sounds appealing, but it's not really usable today. We keep hearing that there will be a stable release sometime later this year, but we'll need to see that actually happen first before it'll have any chance at being widely adopted. Even then, it's doubtful Rust alone will have any major impact on the web any time soon. Servo may, but that's clearly very much also an unusable work in progress at this point.

So overall, I don't see Mozilla as heading in a very positive direction. They really haven't had any wildly successful new offerings in quite some time now, and what they have been working on lately doesn't seem to be getting all that much adoption. Without a large base of users, their influence over the development of the web will just get weaker and weaker.

That's not a bad thing, though. That signifies ambiguity in your code. You're better off fixing problems like that than you are letting them go undetected or unfixed.

This is a very real phenomenon.

A somewhat related one is the effect that the Perl 6 disaster has had on the reputation of the Perl community as a whole, even if Perl 5 is a very different language embraced by a different segment of the community.

Unfortunately, the term "Perl" has become synonymous with terms like "failure", "incompetence" and "wheel-spinning" for a lot of people.

This isn't the kind of reputation that proves useful when trying to advocate for the use of Perl 5 in new projects, for example. One will end up spending more time trying to explain that Perl 5 is pretty unrelated to Perl 6 and that its development has continued, rather than spending time explaining how it'll be beneficial to use it.

There's a huge difference between Perl 6 and Python 3. And Python 3 surely is not "killing Python" or "causing major problems".

In hindsight, I think it's been very good that Python 3 hasn't been about drastic, immediate change. It has been a very controlled transition that has allowed existing users to remain undisturbed, while simultaneously allowing the language to evolve.

Those who don't need Python 3's benefits today are perfectly able to continue using Python 2.7. Nobody is forced into upgrading, yet Python 2 still remains very well supported.

Those who want or need what Python 3 offers can upgrade when they see fit. We've seen the major libraries and frameworks support Python 3 over time, as demand for this support has grown. It now has a very robust community building around it.

Unlike Perl 6, we've actually been able to seriously use Python 3 for a long time now. While it's clear now that Python 3 is the future, Python 2 users haven't been abandoned, either. Everyone has remained as good as they were before, if not better off.

Why is it that you see Android becoming irrelevant? And when do you see this happening by?

Of course it's not an equivalence. But it's also not an analogy, either. There are really no similarities between the two.

Just being capable of being a translation target for other high-level languages is totally insufficient to be considered similar to assembly language.

It's the ratio between the costs and the benefits that matters, not how long people have had the option of moving away from Windows XP.

If it were that simple, it would have happened already.

There are still a lot of businesses that, unfortunately, depend very heavily on Windows XP for their ongoing operation. The cost associated with switching may far, far exceed any benefit it could bring.

We aren't talking about a couple of Ruby on Rails developers sitting in a cafe using MacBooks. We're talking about global organizations with tens of thousands, if not hundreds of thousands, of computers. We're talking about applications that will only run properly on Windows XP. We're talking about astronomical costs that will bring only comparatively minor gain. That's the kind of situation that does not lead to change.