PommeDeTerre

What you say is very true. Furthermore, there's no guarantee that code associated with somebody's GitHub account was actually written by that individual. It's useless to gauge the ability of a developer based on code in his or her GitHub account that somebody else wrote.

If that misconception is the "only one thing" you know about getting a certification, then why do you feel it appropriate to comment on the process?

You don't need to buy the books in order to pass the certification exams. Experience is often far more useful. A list of topics covered by the exam is often provided, too. So somebody with experience can often easily supplement their existing knowledge by reading some online articles or documentation, without ever looking at one of the official books.

And one of the core aspects of certifications is that they usually very specifically target a given product or topic. This is one of the things that differentiates them from college degrees and other ways of suggesting qualification. A certification can help an employer gauge a candidate's abilities in a far more specific manner than a Comp. Sci. degree can, for example.

Certification may not always have the value or reliability that it's claimed to have, but let's not misrepresent it or its process out of ignorance, either.

That approach could have unintended consequences, though. A department could just cut back on the services they provide, in order to cut back on their spending, to stay well within their budget. If these services are critical, then that may be worse than some wasteful spending, but a higher level of service.

What you propose may sound great and easy in theory, but in practice it's usually a huge disaster.

The truly useful code of the application will quickly become overwhelmed by the code that tries to abstract away the high-level abstractions offered by the frameworks being used. The boundary or interfacing code you mention ends up becoming a custom framework in and of itself, but usually far more limited than the underlying frameworks.

It's pointless to use a framework in the first place in order to reduce the time and effort needed to build a software system, only to immediately try to abstract it away with a bunch of custom code.

As an industry, we've seen these kinds of systems in the Java world for many years now, and they never turn out well. The performance is awful due to the layers upon layers of abstraction. It becomes extremely difficult to partially, never mind fully, comprehend such a system. This in turn makes even simple changes risky and awkward. And in virtually all cases, the abstractions end up being useless, because the underlying framework is never actually changed at any time. And in the rare cases that it is, a huge amount of work is needed anyway because the code abstracting away the framework never does this perfectly.

The cost of implementing and maintaining the type of abstraction that you propose can easily exceed the cost of rebuilding from scratch software systems that are highly tied to one or more frameworks.

Wouldn't your own personal pre-peer-review review have caught that?

We may not use GNOME today, but many of us did happily use it before the GNOME 3 disaster. After that happened, though, we had no choice but to move to other environments.

Some of us even hoped that maybe someday the situation would reverse itself, and GNOME could once again become a viable desktop environment. Unfortunately, it has become clear over time that this is not the case, and likely never will be.

It's disappointing to see a project that was once quite useful, yet still with a lot of potential, be destroyed so quickly and unnecessarily. And it's perfectly acceptable and understandable for us to voice our displeasure with further degradation of what GNOME once stood for.

That's sort of a useless distinction to make, in practice. If jQuery isn't usable as-is, then it could very well be said that this problem is at least partially due to using jQuery.

Having to play games with jQuery to strip out or alter some of its functionality just to get it to appease Mozilla really isn't much different than any other bug that might need to be patched to get jQuery to work in a certain situation.

There was no SQL Server 2003. Do you mean 2005?

That platform already exists. It's the "platform" that naturally happens when there aren't any "app stores" or "app marketplaces", and when devices aren't artificially crippled to prevent users from freely installing software.

It's a bunch of people and organizations around the world offering their software for download over the Internet. It's other people who then possibly pay for and download those apps.

It's distributed, it can optionally include compensation, and how that compensation is delivered is up to the app creator and purchaser.

It may not be as pretty or convenient as what Apple or Google offer, but at least it has the freedom that's desired.

Of course, a package system like dpkg or pkgsrc can be used to help make it far more convenient to find and install software. And websites offering a directory of available software can help with this, too.

All of this already exists. I think that a lot of people have just forgotten about it within the past five or six years.

What makes you think that "no one had objections about Apple and Amazon doing so"? Lots of people did. Lots of people have been quite vocal in their dislike of the so-called "walled garden" practices of various organizations.

Google and Android have generally provided a relatively open third-party alternative to what Apple and others are offering. If the degree of openness is changing, however, then I can see people speaking out against them, too, and possibly looking for alternatives.

The universal behavior is to consistently behave inconsistently?

I think that you may be vastly overestimating the number of web and mobile app developers. They're still a relatively small proportion of all software developers.

While web developers may be more vocal and have more content on the web (this isn't unexpected, since they are web developers, after all), you shouldn't forget about the numerous other developers out there. They're working on systems software, embedded software, industrial control software, accounting and billing software, various other kinds of business software, scientific software, and so forth.

These days, these kinds of developers generally use Windows or Linux systems, running on non-Mac PC hardware of some sort. And there are a whole lot of these developers.

There's nothing "snarky" about pointing out stupidly and inexcusably broken programming language features.

The people you refer to as "haters" are usually just professional software developers. As professionals, they don't stand for the unjustifiable inferiority exhibited thoroughly by PHP and JavaScript. So of course they'll speak out against such programming languages.

And contrary to your beliefs, what they say does have an impact. We wouldn't see so much emphasis on web development using languages other than PHP and JavaScript if what you were saying is true.

I wouldn't say that Crockford really "explored JavaScript's good parts".

Rather, he just covered parts of JavaScript that shouldn't be used, and whatever wasn't completely broken was considered to be "good". It isn't truly good, however. It's just not "severely bad" like the rest of JavaScript is.