PommeDeTerre

13년 전discuss

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.

PommeDeTerre

13년 전discuss

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.

PommeDeTerre

13년 전discuss

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.

PommeDeTerre

13년 전discuss

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.

PommeDeTerre

13년 전discuss

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

PommeDeTerre

13년 전discuss

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.

PommeDeTerre

13년 전discuss

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.

PommeDeTerre

13년 전discuss

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

PommeDeTerre

13년 전discuss

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.

PommeDeTerre

13년 전discuss

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.

PommeDeTerre

13년 전discuss

The universal behavior is to consistently behave inconsistently?

PommeDeTerre

13년 전discuss

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.

PommeDeTerre

13년 전discuss

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

PommeDeTerre

13년 전discuss

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.

PommeDeTerre

13년 전discuss

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.

PommeDeTerre

13년 전discuss

A bad programming language that remains bad for nearly two decades isn't really any better, in my opinion, than a bad language that undergoes some change that may have mixed results in the end.

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.

PommeDeTerre

13년 전discuss

I wouldn't say so. It's far, far closer to a functional programming language than JavaScript is, for instance. But it's clearly nowhere near what Haskell or Standard ML are, either.

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.

PommeDeTerre

13년 전discuss

Syntax is highly important, however. A poor syntax can make an otherwise decent language quite unbearable. A nice syntax doesn't make an otherwise poor language good, either.

PommeDeTerre

13년 전discuss

Support for higher-order functions is obviously a minimal requirement of a "functional programming language". But functional programming extends far, far beyond that.

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.

PommeDeTerre

13년 전discuss

Is that really a good comparison?

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.

comments