A human life is worth more than its economic output.
949 karma · joined March 25, 2011
A human life is worth more than its economic output.
You can check in things that shouldn't be checked in with any language/framework.
If you have done this, here's how to fix it: http://help.github.com/remove-sensitive-data/
This is "thin controllers" gone too far -- the model shouldn't have to figure out where it's being updated from and what to allow.
Dentists far too often recommend extraction for wisdom teeth when it's unnecessary, probably because they can charge a hefty fee for it.
If multimethods were a subset of static typing, then regular methods would be too. Methods are dynamic by definition: the type of the method's target is inspected at runtime and used to dispatch to the correct function entry. In Python, it's explicitly stated because the first argument of all object methods is "self". Multimethods extend this to do dynamic dispatch on all argument types, not just the target object.
Most Python object methods are declared at compile time; this doesn't make method declaration a "subset of static typing". You can add new methods to classes and objects at runtime using Python's reflection and introspection; you can just as easily add new multimethods at runtime using this framework.
Finally, the @decorator(...) syntax at compile time is just syntactic sugar for something like the following:
def _foo(self, arg):
...
foo = decorator()(_foo)
So you can use decorators at runtime whenever you want too.From Wikipedia: An actual example in INTERCAL would be too difficult to read
Gotta love it.
The reason that an array subscript is "$foo[0]" is because the $ sigil means "HEY COMPILER, the expression here is going to evaluate to some scalar".
@foo is the entire list and the compiler treats it as a list type; $foo[0] is an element of the list and needs storage/behavior of a scalar. Same thing for hashes: %bar is the whole hash; $bar{quux} is an element and must be treated by the compiler as a scalar.
The programmer must remember that square braces mean array subscript and curly braces mean hash lookup.
So basically, this is a compiler optimization implemented by having the programmer provide hints to the compiler. It's overhead that probably isn't needed in the modern age, but we're effectively stuck with it. It wouldn't be so bad if they hadn't made the second (and IMO worse) decision:
You can reuse symbols across contexts. The way this works is that the compiler maintains a symbol table where each symbol has a slot available for each of the types (scalar $, array @, hash %, subroutine &). This was originally the way to emulate pass-by-reference: you'd write a subroutine that assigned its arguments into typeglobs (* foo — think of it as a wildcard for all things named foo that behaves as a magic scalar with the contents of foo's symbol table entry) and then pulled them back out as the types it wanted:
local(*foo) = @_;
foreach $bar (@foo) {
do_something($bar);
}
This amounts to telling the compiler "I want to alias the name foo in all contexts to my argument, and then go look at what's stored in the array at that name" and is a poor man's pass-by-reference.Perl 5 has a real reference system that completely obviates the need for this, except for the case of monkey-patching a subroutine, where you still say:
local *Package::quux = sub { ... }"
What's left is an unfortunate case where things like the GP mentioned ($bar = $foo[$foo]) are possible, and people who think they're being clever will do these things. Like the parent said, this is not a good thing to do.I made as much noise as I could about an electrical engineering course at Berkeley all but requiring Windows, but it pretty much fell on deaf ears.
I don't think I ever managed to clean all traces of Adobe crud off of that poor Mac.
What bothers me the most about Adobe's free player/viewer applications is that installing one of them automagically gets you a copy of AIR and a bunch of auto-update crap. They go against pretty much everything Apple's user experience guidelines recommend, as if they're going out of their way to make us feel like we're back on Windows 98. Gah.
Walk to work instead of driving if you can, walk somewhere a little farther away for lunch, whatever it takes.
Would that more of us spent even a fraction of the time we spend developing our minds on taking care of our bodies.
Guess we'll see who's right in five days.
If Siri works as well as advertised, it will be a triumph for natural language processing as a field, not just Apple.
Getting that sort of parsing and semantic analysis into a form where it can be done by a mobile device must have taken a lot of work, and I'm sure that was only the start — Apple must have had to go back through every single data source and API in iOS to add semantic tags for Siri to latch onto.
(We already know Apple is more than capable of executing CPU transitions on the Mac. I suppose the only other question is how much people value Parallels and Boot Camp.)
This is opt-out.
If push came to shove I could probably take vacation even if my manager didn't think it was a good time, citing mental health/family issues/whatever. But that would involve spending the same amount of goodwill as declaring "I've already earned this PTO so I'm using it whether you want me to or not", and I would be hesitant to do either of those if I had even the slightest bit of respect for my company or co-workers. And if I didn't have that respect for the job, why would I be working there in the first place?
So far I haven't seen this from design-by-committee Google or the-enterprise-doesn't-need-that RIM. WebOS seemed like the closest thing, but it was buggy and hampered by slow and buggy hardware.
Apple's competitors are right to imitate it, but they imitate the end result rather than the process that led to that result, and so they end up with a product lacking a clear vision and goal that can't compete.
That and they always aim at where Apple is now, not where they will be in a year.
(Disclaimer: this comment written on an iPad.)