Archive for May 21, 2015

Thursday, May 21, 2015

Safari URL-spoofing Bug

Lucian Constantin:

The issue was discovered by security researcher David Leo, who published a proof-of-concept exploit for it. Leo’s demonstration consists of a Web page hosted on his domain that, when opened in Safari, causes the browser to display in the address bar.

The ability to control the URL shown by the browser can, for example, be used to easily convince users that they are on a bank’s website when they are actually on a phishing page designed to steal their financial information.


That’s because the attack code is designed to redirect the browser to the spoofed URL, but before the content is loaded, the code reloads the current page.

Hard Drive Icons Through the Ages

Eli Schiff:

Nevertheless, ever since the original OS X hard drive icons were designed, this category of icons has been a touchstone for icon design practitioners. Whether designing a custom application icon, a commercial disk image or making a custom icon to distinguish one's personal drives, hard drive icons have been a prime area for designers to display their skill in both technical execution and creativity.

This post is hardly exhaustive. I have selected only a fraction of the incredible icons that community members have designed over the years.

First-Class “Statements”

Justin Le (via Andy Matuschak):

One thing I’ve really always appreciated about Haskell is that all “statements” in Haskell (or at least, what would be statements in other languages) are first-class members of the language. That is, (imperative) statements are literally just normal objects (no different from numbers, or lists, or booleans) — they can be saved to variables, passed to functions, transformed using normal functions, copied, etc. Haskell doesn’t have statements — everything is an expression, representing normal data! This really opens up a whole world of possibilities for not only reasoning about your code, but also for new ways to frame ideas in contexts of parallelism, concurrency, exceptions, DSLs, and more.


In many other languages, sequencing actions is a special part of the syntax — a semicolon, usually. In Haskell, sequencing is not special — it’s just a normal function on normal data structures.

You can even make your own “first class” control flow!

Which Features Overcomplicate Swift?

Rob Rix (tweet):

It’s even harder to separate out the opportunity cost—how many of the language’s other complexities and inconsistencies would have been reconciled if they hadn’t had to focus on interoperability with a fundamentally unsafe language and runtime with which they share an address space?

While this overwhelms the language’s design, it’s hardly the only example of complexity.


Crucially, the vast majority of this is incidental complexity, not essential complexity. Swift is a crescendo of special cases stopping just short of the general; the result is complexity in the semantics, complexity in the behaviour (i.e. bugs), and complexity in use (i.e. workarounds).

Update (2015-05-23): Marcel Weiher (Hacker News, Reddit):

Or the whole idea of having every arithmetic operation be a potential crash point, despite the fact that proper numeric towers have been around for many decades and decently optimized (certainly no slower than unoptimized Swift).

And yet, Rob for example writes that the main culprit for Swift’s complexity is Objective-C, which I find somewhat mind-boggling. After all, the requirement for Objective-C interoperability couldn’t exactly have come as a last minute surprise foisted on an existing language. Folks: if we’re designing a replacement language for Apple’s Cocoa frameworks, Objective-C compatibility needs to be designed in from the beginning and not added in as an afterthought. And if you don’t design your language to be at odds with the frameworks you will be supporting, you will discover that you can get a much cleaner design.


The situation is even more bizarre when it comes to performance. For example, here’s a talk titled How Swift is Swift. The opening paragraph declares that “Swift is designed to be fast, very fast”, yet a few paragraphs (or slides) down, we learn that debug builds are often 100 times slower than optimized builds (which themselves don’t really rival C).


I like Swift because constantly challenges my skills as engineer, I have to find workarounds to apply all the concepts I know about functional programming, but... this is the current feeling, I don’t know if in a long run this would persist, I can’t image to fight against the language like I have to do sometimes, would make me still happy in 2-3 years, maybe some day I would get tired.

Update (2015-06-11): Marcel Weiher (comments):

Apple used to be very much about going that distance, and I don’t think Swift lives up to that standard. That doesn’t mean it’s all bad or that it’s completely irredeemable, there are good elements. But they stopped at sophisticated complexity. And “well, it’s not all bad” is not exactly what Apple stands for or what we as Apple customers expect and, quite frankly, deserve. And had there been a Steve in Dev Tools, he would have said: do it again, this is not good enough.

Update (2015-06-12): Adam Knight:

Swift is kind of like when you’re a kid and you fill the bag of jelly beans with all your favorite flavors and then reach in and have a handful all at once. Each was a good idea, but together it lacks anything that made any single piece good.