Pacabel

This really depends on where you set the baseline standard.

You may see the worst-performing variants of a given model as defining the baseline, with some being above the baseline.

But it's perfectly legitimate to define the baseline at the best-performing variants of a given model, with some unfortunately being below the baseline.

Personally, I prefer to set expectations high, and define the baseline based on the best that has been achieved so far. The worst-performing variant from 2014 should still be expected to exceed, or at the very worst be equal to, the best-performing variant from 2013.

The expectation is that a 2014 model will perform at least as well, if not better than, a predecessor model from 2013.

That's a perfectly reasonable expectation to hold, as well. One really shouldn't end up worse off (for whatever reason) merely by buying a more recent model, especially when it's a computer that's being purchased.

I think that's backing up the point he's making, though. When considering the big picture, tiling window managers are quite minor and relatively infrequently used.

Having a small amount of influence within a rather obscure field ends up translating to basically no importance in practice.

There are many examples of very large and critical software systems implemented in languages like C, C++, Java, C#, Perl, Python, Ruby, and others. We just don't see anything like this when it comes to Haskell, however. The examples that do exist are quite minor in reality, and this will naturally make some people skeptical about Haskell's practicality.

Realistically, I don't think that knowing Haskell really would benefit most programmers, especially those working on typical, everyday software systems.

There are some relatively niche situations where it might be a good choice, but those are few and far between.

We've seen the most useful and practical features offered by Haskell make their way into other more mainstream languages over the years. The more theoretical features haven't made this transition because they really aren't all that practical.

At this point, most programmers would be better off learning more about security, cryptography, databases, networking and other everyday topics than they would be by learning about the more theoretical functionality offered by Haskell.

I don't see much "hatred" there at all.

He's merely pointing out the very real fact that Haskell's adoption is quite limited, and the fact that there really isn't much truly critical software written using it, despite the hype surrounding it and its age.

I'd say it has made more of an impact by influencing other, more pragmatic languages than it has by software written using it.

It's a shame to see that comment getting modded down. It's absolutely valid and correct. The three examples given in that other comment are pretty much unknown. xmonad might be a slightly better example, but it's still pretty much unknown, too.

While Haskell has seen some usage, of course, we really haven't seen any major and widely-used non-compiler software developed using it. It's perfectly legitimate to point this out, and using very obscure counterexamples doesn't change this reality.

I think you might be overestimating the actual usage of Clojure. It's still very much a niche language.

Everything I've observed suggests that Scala has a far greater rate of adoption than Clojure, and Scala's usage is still basically irrelevant compared to that of the major entrenched languages. I'd put the adoption of Haskell closer to that of Scala than I would to Clojure.

That isn't really the case at all. Java (the language) is relatively small and simple. Java code can be written quite easily without an IDE. In fact, that's how it was done for many years by most Java developers, before Eclipse, NetBeans and other IDEs became more commonly used.

The unnecessarily complex design of many Java libraries and frameworks is generally what pushed developers toward using an IDE, not the language itself.

I wouldn't be so quick to dismiss it. Maybe that exact situation won't often arise, but in other languages like C++, Java and C# it's not at all uncommon to have nested collections.

I don't think we can really consider it to be "stabilizing" when there are relatively significant and breaking changes like this still going on.

It may be headed in the direction of stability, but that's quite different from stabilizing.

We can consider it to be stabilizing once the language and standard libraries have been frozen, and the only changes happening are very minor ones that are fixing critical bugs.

Until then, it's still in the research and development stage, at best.

Like we always have to ask when somebody says what you have, "What's the alternative?"

Whatever it is, it'll need to be very portable (well beyond just Linux, OS X and Windows), and it'll presumably need a free implementation on each of those platforms, and it'll need to be quite fast, and it'll need to support native compilation, and it'll need to support interoperability with existing code, and it'll need to be "safer" in some way.

At this time, there are very, very few languages that meet every one of those criteria sufficiently. We're looking at C, or C++. Maybe Ada. But that's about it. Rust doesn't cut it yet, and probably won't for some time. Other candidates are lacking severely in one or more of those important areas.

C++ using modern techniques appears to be the only feasible alternative to C today.

It's fine that you don't care about this information. But that in no way means that others hold the same view as you.

There are people and organizations paying significantly more each month than you are, and they're very likely using GitHub in a way that's far more critical to their operations than it may be for you.

For some customers or potential customers, the factual details regarding this case are more important than I think you realize. They need the facts to help decide if they want to keep using GitHub going forward, or if they even want to adopt it in the first place.

Without the facts, they have to sift through rampant speculation, trying to make educated guesses at what's plausible and how it may affect them, their source code, their obligations, and their continued operation as a business.

Part of the "recovery" involves getting factual information out there so that existing and new customers aren't faced with uncertainty. Somebody paying $7 per month might not care, but people and organizations paying $200 or more very well may.

There's no bravery, or merely even resilience, involved with listening to and learning from criticism of one's product.

Sometimes ideas are just plain bad. Sometimes implementation are just plain bad. If somebody wishes to express such sentiment, then that's a perfectly fine thing to do, and in fact it should be encouraged.

I don't think that anyone is claiming that GitHub "owes" the community the details.

While this may have been an "internal company matter" initially, it did eventually become very public. There has already been a huge amount of speculation out in the open regarding whatever might have happened in this case, much of it quite negative.

So given all of this speculation and gossip, it's not at all surprising that there are people, including users and customers of GitHub, who just want some facts. And there's nothing unreasonable about them requesting such information, especially when it's paying customers doing the asking.

While I suppose this may be a "new way" of debugging for the author of this article, it's hardly a new technique. strace, trace, truss and similar tools have been around for decades now. They're the kind of tools that many developers and sysadmins use without a second thought.

Your description of TDD is a pretty blatant misrepresentation of the actual philosophy and techniques.

Furthermore, I think that you're ignoring that TDD tries to be a practical solution to certain real-world problems. This means that trade-offs are made in the name of creating software that works sufficiently well, while keeping expenses in check.

Sure, extensive formal verification of all software would probably bring some benefit in terms of correctness and perhaps security. But you're not considering the cost involved.

So far, such verification has only proven to be possible in rather limited situations, namely where there are significant resources available, or in academic exercises. Maybe this will change in the future, but in the present it's generally far more cost-effective to use a statically-typed programming language along with some form of automated testing. That gives many of the benefits of more formal methods of verification, but while also avoiding many of the costs, even if the end result doesn't conform to some theoretical idea of "perfection".

One big advantage that Go currently has over Rust is much greater stability, in terms of language and standard library changes.

This means that Go is far more predictable than Rust currently is for anyone who wants to use it seriously, especially for larger systems that will take some time to develop.

There has been talk that Rust 1.0 will be released later this year. Hopefully that is the case, as it'll allow for the stability that'll then allow more users to seriously consider using it. But until that happens, Go is a much more viable choice in many cases.

I think there's a difference between sharing ideas and sharing code.

An idea or concept on its own can't really do much, at least until it's put into practice somehow. The potential for harm is quite minimal, if it even exists.

Code, on the other hand, can often be directly used with relative ease by people who may not fully understand the possible implications of using such code. The potential for harm exists, and could be significant.

In the context of security, it's important to avoid potentially-harmful code wherever possible. If somebody has concerns about some code, regardless of who wrote it, it is best to express those concerns in a very blunt and direct manner.

Security is just not something to fool around with. The hard questions and painful facts should be out in the open, especially when code is involved and capable of being used. It's just not the time or place for pussyfooting around.

I really do not know. I prefer not to make specific guesses, even lower-bound estimates, when there is insufficient information available.

Oh, I see. Some people here misinterpreted what I wrote to suggest that Python isn't widely used. Clearly that's not what I meant.

I just dislike how melling basically pulled a number out of his ass, and then used it as "evidence" to back up his claims. I wouldn't even consider it a low-quality estimate, since he doesn't even try to justify or explain how that number was obtained.

In this case, "tens of thousands" could very well really be "hundreds of thousands". It could be significantly less, too. Regardless, it's purely speculative. Using such made up numbers makes his argument weaker than perhaps not using any such value at all.

Where exactly do you get this "tens of thousands" number from?

The Windows taskbar and start menu allow for certain levels of usability and efficiency.

The approaches offered by newer systems like Unity, GNOME Shell, and Windows 8 all fall well, well below these levels set by the earlier approaches, however.

They're seen as "problematic", to use your terminology, because they are inherently inferior to earlier approaches in many important ways. They leave users worse off. So of course they will be seen in a negative light.

I don't think that's very good reasoning.

Bad software is bad software regardless of who has funded it, who has committed code to it, or who has written its documentation.

One does not have to be a contributor to that software in order to analyze it and make a judgment regarding its quality.

Even if there's no publically-known way of using a particular security vulnerability to get access to private keys, how are we to be sure that somebody (perhaps malicious) didn't find a way and are just keeping it a secret?

I think that C++ is so useful in practice because it gives you most of each of those, rather than just some of two (or even just one) of them.

Programs written in C++ aren't necessarily the fastest out there, but they're usually pretty close. They're at least almost always better than what you'd get when using most other languages.

And the same goes for safety. It may not allow you to write bulletproof code, but using modern C++ techniques can go a very long way toward avoiding many common problems with relative ease.

C++ may not be the most productive language for some developers, but it still does quite a good job of offering a wide variety of functionality, reasonably high-level constructs, good library support, and decent tooling.

It's a shame to see that comment has been downvoted. That's a quote directly from the bottom-right corner of the Rust website itself!

Rust is promising, without a doubt. But it's not yet truly usable in the same sense that C, C++, Java, Python, Haskell, Go and so many other languages are.

Maybe it'll start to get to that point once 1.0 is released, once we see at least some language and library stability, and then perhaps some adoption. But that just hasn't happened yet.

I'm curious how many of those installations actually see much use, especially on an ongoing basis.

I know several people who have all sorts of browsers installed on their Android devices, but only end up using one of them frequently. The others are used for the rare site that doesn't work well in the preferred browser, but these other browsers don't see much, if any, use beyond that.

Promises can be encouraging, but they really do us no good in practice. And it's practice that truly matters.

We really need at least a stable (in terms of the language and its standard libraries) of Rust before it can even be considered as a viable option. Even then, we'll need to see it used seriously in industry for at least a few years by early adopters before it'll be more widely trusted.

We keep hearing about how Rust 1.0 will be available sometime this year, and how there are only a relatively small handful of compatibility-breaking issues to resolve. But until those issues are all resolved and until Rust 1.0 is actually released and usable, Rust just isn't something we can take seriously, I'm afraid to say.

They are generally better than nothing, however. And they do generally offer better performance, better predictability, an a simpler implementation than other approaches to memory management and garbage collection.

Maybe a language like Rust will offer a safer alternative at some point, but that point surely isn't today, and probably not tomorrow, either. Maybe there are other languages that offer better safety, but they often bring along their own set of very serious drawbacks.

In terms of writing relatively safe code today, that performs relatively well, that can integrate easily with other libraries/frameworks/code, and can be readily maintained, the use of C++ with modern C++ techniques is often the only truly viable option.

I think you might be missing the overarching issue here.

It isn't so much about the specifics of gay marriage, or Eich's donation, or him losing his job because of his opinions.

The real issue is hypocrisy, contradiction and double-standards.

We've seen one group (in this case the pro-gay-marriage crowd) act in a way towards others (Eich and the anti-gay-marriage crowd) that the first group would think is absolutely abhorrent were they the target, yet they consider perfectly acceptable when they direct it towards others.

On one hand, we've seen arguments like, "There is no right to free speech without consequences." and, "he had views that the community was overwhelmingly against" used in this very submission's discussion to justify Eich losing his job merely for expressing an opinion that may be construed as against gay marriage.

Yet imagine the uproar if somebody lost his or her job for merely expressing an opinion in favor of gay marriage, and those exact same arguments were used to justify it.

It's difficult to take people seriously when they claim to support "equality" and "tolerance", or when they claim to be against "discrimination", yet they act in a way that's completely contradictory to all of those ideals.

If one group of people is going to hold another group of people to a certain set of standards, they really should make sure that they're willing to live by that exact same set of standards, too.