Comment Re:*cough* bullshit *cough* (Score 1) 183
Nah he's just allergic to all the mold growing on his cool-bricks. He should have thrown them out when they stopped working due to the lattice getting clogged with calcium.
Nah he's just allergic to all the mold growing on his cool-bricks. He should have thrown them out when they stopped working due to the lattice getting clogged with calcium.
You don;t have to worry -- your Perl 5 code is safe, since there is no directive at all being pushed to "replace" Perl 5 with Perl 6. They will exist as sister languages, won't fight each other when installed together, and there is a thriving Perl 5 community actively developing and maintaining Perl 5 for the forseeable future.
Current intergration is through libperl, and future integration will likely be independent of the VM, just a "slang" using the grammar engine and MOP on the backend. Parrot was aimed at being a polyglot VM, but other VMs started to catch up in that regard so Perl 6 began to target those runtimes as well.
This is a tremendous improvement. The best they'd ever managed with Parrot was "abysmally slow." Before that, perl 6 implementations ranged from "diabolically slow" to "the madness-inducing manifestation of the visage of Gn'oguracha, Elder Slug-God of Unspeed."
Hilarious. And yes it was very, very, very, slow. And yes it continues to speed up. At this point it's OK for scripts that run occasionally, and for some medium-duty stuff if you don't mind spending a bit of time doing some tweaking-you-shouldn't-have to.
That's downright weird looking.
...if you don't grok closures/anonsubs. If you do, it looks much neater.
In other words it is the SystemD of programming languages compared to Perl 5.
I've found several choices made by systemd relatively deplorable. I find Perl 6's choices rational and convenient, pretty much all of them. So no.
To be clear, what I meant to say is, I only have to rewrite those portions I feel like rewriting: you can use Perl 5 from inside a Perl 6 file pretty painlessly these days, as long as you aren't looking for heavy performance or too much complex async. Perl 5 and Perl 6 are considered more "sister languages" than a necessary upgrade, with Perl 5 continued to be maintained and even developed.
Languages need to scale to talent, so a codebase maintained by veterans of the language can use advanced constructs, while a codebase meant to be maintained by newbies can stick to the babytalk. Which is where Perl 5's flexibility can be leveraged well. I think you'll find Perl 6 to be a joy to work with, and if you have the privilege of working with a devel team that gets good at it, it will be an awesome experience, plus you can still "talk down" for stuff you need to throw to the public to maintain.
IIRC, the Christmas release will be tagged 6.0.0. That was sort of a misinterpretation of an off-the-cuff remark.
No, you may be thinking of an early prototype, named pugs, written in Haskell as part of the whirpool design process. The pool has whirled several times since then. I really admire the attention to detail that's been put into the Perl 6 specification and the implementation is coming along nicely and is already very usable for both small ad-hoc scripts and larger stuff, too. Just not for high performance quite yet and a few places where you have to work around some TODOs.
Perl6 version, FWIW:
@Lines
Also I'll be enjoying (really, not sarcastically) years of using Perl5 and Perl6 in the same file due to the easy integration between the two, replacing that part of Perl5 that was ugly at my leisure, or not, and still having things work.
I really like this language a lot.
On top of all this, Apple WiFi is especially broken because:
1) The station will never hop to the best AP when it should, it always waits until signal drops to -75dBm before roaming, so it continues to use the AP at the door where you walked in the building,. not the one near where you are sitting, ruining WiFi for everyone with low-rate shouting. Apple thinks we are going to carefully tweak our networks around this weakness (this is their stated offcial position on the matter) and they are wrong.
2) Responding to a bluetooth beacon from various Apple gadgets, the Apples will try to subvert the local WiFi network and communicate directly on channel 149. They won't even try the local network first to see if it is usable, instead they will try to multiplex the radio hardware between 149 and whatever other channel is actually being used. Meanwhile they fire up a radio on chanel 149, which is a common primary channel for bonded 40/80 channel groups, no matter what else is around trying to use it. Apple thinks we are going to hobble our 40MHz/non-DFS and 80Mhz/DFS channel bonding plan by taking all the APs off 149 (also their official position.) They are wrong.
3) Apple cannot manage to get their autodiscovery protocols to shut up long enough to let wifi and bluetooth hardware settle into a usable state. They think having their devices constantly scanning for gadgets is a terrific idea. They are wrong.
4) Apple keeps removing control over the WiFi from the users, preventing them from properly configuring their chipsets for a particular network, or even locking to a specific AP or turn off a band to help network admins troubleshoot a problem. Every new version of the OS, more options for control of the WiFi disappear from the UI. They think every network operator is going to provide
5) For years, Apple has stubbornly refused to implement and support OKC. They think that because their iPads now support 11k this is no longer a problem and we will all just enable 11k even though it will break a bunch of other legacy devices (including iPads too old to run 11k) which still account for a large percentage of our users. They are wrong. And also they won't say whether they ever plan to support 11k on the OSX side.
Scientists trust scientists in other fields because they assume scientists have based their opinions on solid scientific evidence.
Unfortunately, they also are subject to the fundamental human bias that, when you model the behavior, you tend to base your model on what you know about yourself. Even if you know. intellectually, how dumbass a large portion of the population is, when it comes to projecting their predicted behavior, you'll be subject to this bias at some level. So for example, while a majority of scientists support more nuclear power, the majority of scientists are imagining nuclear power plants not built on disaster-prone real estate, because after all, who would do that?
Supposing there is no way to close it faster than it renders, sure they will be confused, but most will just blow it off as just another windows UI flub, close it, and enter their password.
BLISS is ignorance.