HN user

skimbrel

949 karma
Posts10
Comments110
View on HN

I hope you never find yourself in a situation where you need medical care and can't pay for it. Because the rest of us, who are in possession of at least a few scraps of human decency, would have to shell out to save your ungrateful ass.

A human life is worth more than its economic output.

But when the model is accessed from four different controllers representing different privilege levels (e.g. public profile page, user settings page, internal admin page) and user experiences, is it really still the model's job to figure out which incoming updates are allowed to update which fields?

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.

To defend myself here (a day later), I was not assigning the causality in that direction. The "Because I took care of them" clause goes with the "I get to keep them", as in "I made sure to clean them and not let them get cavities, so there aren't any problems with them staying around". I thought the English was clear enough as I wrote it, but I guess parse errors are more common than I thought.

It's not a subset of static typing at all.

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.

Begin blocks execute during compilation, immediately after they've been parsed. They're compiled themselves, and execute within the Perl interpreter before it finishes compiling the rest of the containing module. So they don't really execute prior to all compilation, but they execute prior to the compilation of anything sequentially after them in the source.

COMEFROM 15 years ago

I remember being shown call/cc briefly in CS 61A at Berkeley and then forgetting about it until recently when I saw an article on it while I was in the middle of writing an event-driven web application using Perl and Plack. I immediately saw how useful it would be and wished I had it available to use there.

COMEFROM 15 years ago

COME FROM is the reason INTERCAL is among my favorite esoteric programming languages. That and the fact that its name is for "Compiler Language With No Pronounceable Acronym".

From Wikipedia: An actual example in INTERCAL would be too difficult to read

Gotta love it.

They weren't originally intended to provide namespacing, as far as I know. They were there to make the compiler's life easier.

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.

Reminds me of the course I took at Berkeley where the homework was issued as PDF files. Not just any PDF, though; these were designed to be submitted back after you had filled out the form blanks in the file. They used the latest and greatest Adobe extensions to the standard to submit the data over HTTP directly from Adobe Reader, which of course meant that those of us with Macs couldn't use Preview and people on Linux were just plain screwed.

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.

Concur.

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.

I don’t think it’d be fast enough. Even in damn-near-perfect signal conditions I have a RTT over 100 ms when I’m on AT&T 3G. That and how lame would it be if Siri ceased functioning entirely (not just the maps/other network-requiring bits) when you had no coverage?

This.

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.

If this is true, I have to start wondering whether Apple plans to port OS X to ARM. Granted, they’d probably have to evolve ARM into a 64-bit architecture, but the power savings would be incredible. A MacBook Air with the battery life of an iPad 2.

(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.)

As GP said, not if you're creating a new branch. There's no history in the new branch to potentially overwrite your uncommitted changes in the working tree, so nothing for it to object to.

If this actually works as advertised, I hope it makes it to market as fast as possible. I'm pretty much done with the days of having new cavities, but I have composite fillings for all the cavities I did have, and ten years down the line they're starting to go bad. It's incredibly frustrating to have a dentist tell you you need to have an already-filled tooth re-drilled because the composite isn't sealing the cavity anymore and decay has set in around the edges where no amount of brushing could have prevented it. With any luck the current generation will be the last to suffer this fate.

In theory, yes. But can you name a place you've worked where this was actually the case?

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?

Someone who can turn over design of both hardware and software to a single team with a clear vision and give that team the authority to make any and all of the tough decisions required.

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.)

Yelp has had this for a while: when you visit a business page, the first reviews they show you are ones from your friends, if available. It's a good way to make sure you're not seeing spam reviews right off the bat, but it does rely on you actually engaging with Yelp's social features.