1,406 karma · joined April 26, 2012
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.
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.
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.
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.
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.
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.
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.
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.
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.
JavaScript is bad. PHP is bad. They're both bad in many of the same ways, and they're bad in different ways. None of this changes the inherent fact that they're both bad programming languages.
Of course all programming languages have "warts". Very few, however, have as many horrible and inexcusable "warts" as JavaScript and PHP do.
As an industry and as a community, we can do better than JavaScript and PHP. In fact, we have already done better in the past (sometimes many years ago), many times over.
So, yes, I will speak out against programming languages that are inherently broken and inferior, and even extremely harmful, whenever I get the chance. It's the right thing to do.
This is not about my ego, or about my "superiority", or about me at all. This is about doing things properly, as an industry and as an entire community of programmers and software developers. JavaScript and PHP are very clearly not acceptable programming languages to use, even if a lot of people make the mistake of doing so.
Maybe "semi-functional" would be a good term for it and Scheme. It has some of the important elements of functional programming, but not all of them.
It also embodies a philosophy emphasizing the purity of such functions. It encourages the use of recursion for iteration. It encourages the use of robust type systems. It encourages the use of pattern matching. It discourages the use of many imperative approaches.
Although they may offer some form of higher-order functions these days, I don't consider languages like JavaScript, C#, C++, Ruby or PHP to be "functional programming languages". They're imperative languages that just happen to have added the most basic of functionality expected from functional programming languages. They don't truly encourage, and only partially enable, the writing of software using a functional approach.
The PHP code you linked to is basically a class with a bunch of getters and setters.
The Python code, on the other hand, handles numerous real-world HTTP requests that do actual work.
So it's not unexpected that the PHP code is lighter; it doesn't really do anything useful!
Although it helps implement a wiki system, the Python code is still very readable and comprehensible with minimal effort.
I think I know the point that you're trying to make, but those examples surely don't back it up in any way.
I've worked on a number of software systems at several different organizations that have very effectively used Python 3 for years now. I think that Python 3 has been adopted perfectly fine by many other people and organizations, too.
We're just not overly vocal about using it, because it has worked for us with so little pain and so little effort in many cases. It really wasn't much different going from 2.7 to 3.0 or 3.1 than it was going from 2.6 to 2.7, for example.
JavaScript does not promote the use of pure functions, referential transparency, and the minimization of state.
JavaScript does not encourage the use of recursion.
JavaScript has an atrociously broken type system, rather than a robust and theoretically sound one.
JavaScript does not offer pattern matching and other functionality offered by modern functional languages.
In fact, JavaScript goes out of its way to promote a very imperative, non-functional style of software development, even when efforts are made to try to use it in a functional way.
And JavaScript's prototype-based OO is anything but powerful. In practice, it's nearly useless. That's why we see so many JavaScript developers try to fake a class-like OO system using it, since class-based OO does offer what they need and want. But due to the incapability of JavaScript's prototype-based approach, these hacks end up being incompatible maintenance headaches.
JavaScript does not have a "powerful core". It has a rotten core, just like PHP, and it has evolved in a broken manner, just like PHP.
Another thing to consider is that PHP developers have a track record of deprecating certain functionality, then a few releases later changing their minds and no longer deprecating it. Some examples of this include is_a, and var in property declarations.
Given how it's still relatively common to see PHP 4.x installations in use today, 10 or more years after they were first released in some cases, merely deprecating some of the broken functionality now won't help much. We'll still see deprecated features in use in 2020, if not well beyond then.
The broken functionality needs to be stripped out completely within a reasonable time frame (well under a year), not merely deprecated and left around for years, if it even stays deprecated. But this involves the PHP community acting responsibly, and going along with these changes for their own good. I don't think we can expect that level of responsibility out of them, unfortunately.
The only real option is to give up backward compatibility, to then throw out every broken language feature, and to then reimplement them properly. Unfortunately for those two languages, that would involve an awful lot of stuff getting thrown out and reimplemented, which is very likely why it hasn't happened yet.
Given how much core functionality needs to be reworked in both cases, I don't think they can really be saved. There are numerous other better languages out there, and it's easier just to use them instead of trying to salvage PHP or JavaScript.
Keep in mind that there are also many cases that are the opposite of what you describe. I've worked with many systems that were initially implemented in a non-C++ high-level language, yet the developers had to go back and start incorporating C or C++ code at some point for various reasons, if not re-writing the entire system in C++.
The hybrid approach that Python allows for is extremely powerful, given how it makes calling down to C and C++ code from Python code quite trivial, or embedding a Python interpreter within existing C or C++ code.
Changes to the language should not be done just to attract more users. This is especially true if these new users would be today's PHP, JavaScript and Ruby users. The C++ community is much better off without these kinds of programmers.
It's much better for people to use C++ when they realize that they need the powerful functionality it offers, rather than dumbing down C++ in a way that'll make it attractive to less-skilled developers.
The Harmony work is somewhat of a step in the right direction, but its impact will still be quite limited, assuming it ever does become a standard.
C++, on the other hand, has seen significant improvement over the past two decades. Much of its complexity can now be avoided when using a "Modern C++" approach, all without losing access to its powerful functionality in those cases when it truly is needed.
C++ has evolved in a way that makes it more usable. JavaScript has merely stagnated, without the community showing any real interest in cleaning up what's a very unjustifiably bad situation.
The complexities of C++ almost always arise out of the extremely high degree of power and flexibility it offers programmers.
The complexities of Java end up having to do with hyper-"architected" class libraries, rife with excessively-used design patterns to the point of being incomprehensible.
JavaScript's complexity arises due to core functionality that's missing (such as proper class-based OO, namespaces, and proper support for modularity), or core functionality that's limited in practice (like it's prototype-based OO), or core functionality that's unjustifiably broken (its comparison operators, semicolon insertion, its scoping, its type system, its awful standard library, among others).
Out of those three, JavaScript's complexities are by far the worse. The flaws are outright stupid to being with, and there's nothing that can really be done to avoid them in many cases. At least Java programmers can choose not to create and use bloated class hierarchies, for instance. And at least C++'s complexity offers superbly powerful features and excellent performance, and at least it's understandable how and why this complexity thus arises.
The basic fact is that prototype-based OO, for example, is much less practical than class-based OO. Experienced developers comprehend JavaScript's attempt at it just fine. This understanding doesn't change its inferiority, however. This is exactly why so many developers need to compensate for JavaScript's lack of desired functionality in this area by trying to fake class-based OO using the limited functionality that JavaScript does offer.
The same goes for many other aspects of JavaScript. Bad tools are still bad, even in the hands of experts.
I'm not really sure what you're talking about when you mention "evolving standards". If anything, JavaScript's standards haven't evolved well at all. Harmony is only now proposing the addition of core functionality that has been present in other languages for decades now, and should have been in JavaScript from the very beginning, too. JavaScript is merely "evolving" to where it should have been many years ago.