eevee

And yet I still read Yahoo Answers, and I never read Quora.

veekun is my project, yes :)

Block both, wonder why the site has nothing on it, leave.

I'm actually working on that—hopeful to have something passable out by the release of X/Y.

A vim plugin pack could work very well—I think the problem is with many of the plugins, which were built to scratch the author's itch and inadvertently dig their tendrils into half of vim's functionality. That's sort of tolerable when installing them one at a time (and figuring out how to loosen their grip one at a time), but every time I've installed a plugin pack I've suddenly had a vastly different vim that was both buggy and much slower.

gitgutter, ctrlp, and pretty much anything from tpope are all great in this regard: they do one localized thing and it Just Works. (Downside is when that "one thing" is a shortcut or function, and with no other cues I forget I even have the plugin installed.) On the other hand I've had pretty terrible experiences with SuperTab, which required a lot of fiddling and still breaks my Tab key sometimes, and ctags is such a pain that I've never gotten around to making it actually work. But those are useful enough that they end up in most plugin bundles, so you get a Cartesian product of the interference and brokenness of all of them.

Also seems a little disingenuous to call it "open sourcing" when the vast majority of it is submodules of existing open source projects.

Maybe we should do less crying and more contributing. Google has a bit more dev muscle to throw at projects than Mozilla, so community involvement is far more critical to Rust's health.

It is rather telling that PHP's design is based on whatever was popular at the time. The original design was based on Perl, further additions and the stdlib were designed like C++, the class system is a lot like Java, and recent features have been clearly inspired by Python.

I've met more than enough PHP programmers who genuinely tout "it's free" and "you don't have to declare types" as unique advantages, or are unaware that you can even build a website in anything else.

It's good when languages try to help. Reprimanding someone for not doing enough work is useless.

My problem is that the language is guessing wildly, in ways too obscure to be mentioned in the documentation or known by you (a user of the language), even when both operands are strings. That means it appears to work much of the time even if you don't think you're being lazy, but might actually have a bunch of false positives you didn't expect. And that's kind of a bad thing in a programming language. Same sort of reason manually escaping everything is hard to get right: if you forget, your code still works fine under "normal" circumstances.

Now, if == did a strict comparison and there were a separate imlazyjustslopittogether operator, there wouldn't be a problem. Defaults matter.

Would you expect "1.30" == "13e-1", since both are strings? How about "0xb" == "0xB"? 0 == "zero"?

I don't see how this is anything but bugprone, and all to save you from actually saying what you meant and slapping a couple int()s on your input.

Compare JavaScript, a language with much the same == problems, where the community generally advises against ever using == at all. CoffeeScript (different syntax that compiles directly to JavaScript) even translates == into ===, leaving the original buggy operator unavailable.

I disagree that it wasn't a language fault; it provided very little benefit and directly caused hard-to-diagnose bugs. Being told where the mines are doesn't make walking across a minefield any more palatable. If it were a good idea it wouldn't still be around.

Undeclared variables in PHP produce an E_NOTICE, right? Better than Perl 4, at least. :)

register_globals could not have existed without the legality of undeclared variables, and it could not have been a security issue without code that relied on using undefinedness as a default value.

The people of Thailand didn't invent Thai, and it's unlikely that a handful of them could invent a new language and have it catch on within a few years. The analogy doesn't quite hold. Switching sentence structure is more akin to switching paradigms, anyway.

There are no strict comparison operators for less-than/greater-than. === acts fundamentally differently for objects than for everything else. Alas.

Ah, sorry, some actual context might be helpful.

In Perl, variable declaration was originally even worse than it is in PHP: any variable, anywhere, required no declaration and was assumed to be a global. (This was inherited from... some combination of awk and shell, I guess.) Obvious problems aside, a practical implication was that recursion was pretty awkward, since the callee and the caller were sharing the same namespace for the same code.

Perl 5.000 introduced the `my` function, which would declare a variable as lexically scoped. This solved the practical issues, but it left the problem of error-checking: a typo in a variable name would still create an implicit global with no warning. The solution was the opt-in `use strict;` declaration, which disabled the implicit-global behavior and made unrecognized variable names a compile-time error. Code could be fixed and then opt into the stricter semantics on a per-file (or even per-block!) basis, and nowadays most Perl devs will jump on you like a pack of hyenas if your code doesn't start with `use strict;` or some equivalent. Over time other features with too-sharp edges have been culled, still supported by the interpreter (Perl is more or less compatible going back decades) but made illegal in strict mode.

JavaScript's weird "use strict" opt-in is a spiritual port of Perl's approach, stuffed into a string literal to fit into the existing syntax. One of its effects is even the same: assigning to an unrecognized name is now illegal, rather than creating an implicit global.

I'm not aware of anything so fundamental being changed in such a heavy-handed way in PHP. From the outside looking in, I'm not even sure the PHP community has a strong consensus on what PHP-specific features to avoid. I'd be happy to learn that I'm wrong on either count.

Despite your sarcasm, that is a significant part of actually solving a problem: getting the solution into people's hands. Would you be very impressed with all the improvements if Ford's new line of 100% safe cars all cost millions of dollars?

I'm not sure how to reconcile this analogy with the existence of government programs (carpool lanes, tax incentives for hybrids) that encourage the use of more efficient cars with more people in them, on the grounds that it's better overall for the ecosystem.

PHP has deprecated obviously insecure behaviors that are largely Web-related, yes. I'm coming from a Perl perspective, where deprecating bad language features means things like "radically overhauling how variables work" or "putting major community effort into eliminating an entire kind of variable". I'm not aware of many similarly-radical changes in PHP, except perhaps whatever happened with PHP 4's short-lived classes.

I'm only observing that the article comes across weirdly as a result, especially when the author makes judgments like "simple". Not defending the condescension. (Though the same tone might well be taken if he were a Ruby novice writing articles titled "A Look at Ruby's Continuing Evolution".)

Tools should be designed to fit with humans; the goal is to minimize how much humans have to contort themselves to fit their tools.

There'll always be some degree of learning and adjusting. But a mallet is still an improvement over a rock, because it's designed to fit in a human hand. I doubt anyone scoffed at the mallet and blogged that rocks have 80% market share so why can't we just get over it already.

Hello, author here. You're not the first to scoff at my hammer description, but perhaps you can explain to me what kind of nail puller looks exactly like a hammer but with two claws, or why it would be useful to have the exact same tool on both sides of the handle. (This is still a PHP analogy.)

I don't see how to solve most of the issues, either. That sucks, and I genuinely sympathize with Zend on this, but it doesn't make them not-issues. As I think I said, they'd be acceptable if they were reasonable tradeoffs, but many of them are not.

Your == counterargument seems apologetic and trivially applied to anything: whenever a program is wrong because the language violated expectations, it's the programmer's fault for not having memorized some matrix of arcane rules. Languages aren't perfect and human beings have wildly differing expectations, but ultimately we only have programming languages to make it easier to express ourselves—no one's stopping you from writing the next big web 2.0 thing in x86 machine code. So yes, when it's difficult to reliably ask a language "are these things the same" without learning paragraphs of gotchas, that's bad.

Glad you enjoyed the article!

Variable declaration is pretty core to the language. Remember register_globals? That was only a problem because so much code relied on having undeclared variables act like empty strings.

I suppose they could have made it work differently just for nested functions, but that's a major inconsistency, it's not clear how it would interact with globals, etc.

GP's phrasing aside, it does make the article read as though the author has never used any other closure implementation (and, by extension, any other programming language).

Speed will always matter. You'll never find time to address technical debt; you have to make it.

PHP's worst problem is an exacerbated form of what strangled Perl for many years (and still does, though they're actively fighting it): lots and lots of existing code that's really, really bad.

Adding new features doesn't help that. Only gradually deprecating old ones (or waiting a few decades) does, and that doesn't seem to be in PHP's blood.

I'm pretty sure w3techs is just measuring who has what in their `Server` headers, so even a static site that happens to have mod_php available would still ping as PHP.

For the same reason, Python is virtually nonexistent—because nobody uses mod_python.

With what? Rails? Doesn't that require generating a whole "project" (whatever that is) with a bunch of directories and files and then figuring out where everything is and...

PHP requires opening index.php and typing "hello world". Obviously that's not going to work anywhere else, but something like Flask (or Sinatra) is much closer.

Deployment, maybe. The biggest stumbling block is that no matter how magical a deployment solution anyone invents, it's worthless unless there are free/cheap hosts that come with it installed and have cPanel integration.

PHP supports lexical scope; it's just local to the current function.

The actual problem is that PHP automatically initializes variables even on read—the same reason all globals have to be manually "imported", even if they're only read from. Similar to the problem Python 3's `nonlocal` solves, except imagine a world where Python didn't have NameErrors and instead initialized every unrecognized name to None.

This is maybe the third comment about whether the 80% is lies, damned lies, or statistics.

I would much rather see a conversation about how other languages can bridge the gaps of "hello world in a browser isn't obvious" and "deployment is hard". Those are important and useful things to do, regardless of PHP's market share.

Why is Python 3 relevant? Porting a large Python 2 library to Python 3 (or, more likely, to both 2 and 3) is a significant undertaking. Porting a PHP library to use namespaces would largely be a matter of adding global aliases for backwards-compatibility, surely?

I don't think that's accurate. There's not really any notion of "success", and the most important part of the process is that changes are made effectively at random and either propel the species forward by some minor increment or never make it past being rare curiosities.

Wait...