austinz

This is a blog whose latest entries deal with Xcode 6.0 beta 3 (out of at least 7 eventual betas, many of which made substantial changes to the language). Right now, the 'standard' Swift version is Xcode 6.1's (Swift 1.1), and Swift 1.2 is in its third beta. So it's definitely not representative of the current state of the language (which was, admittedly, in pretty awful shape at that point in time).

The arcade is great. http://en.wikipedia.org/wiki/Mus%C3%A9e_M%C3%A9canique

I enjoyed Metroid Prime 3. Probably the first and the last console shooter type game I'll ever enjoy. It was a pity more games didn't bother exploring using the Wiimote as a pointing device, although the Wii's underwhelming graphics certainly didn't help matters.

It's easy to tell people to quit their shitty jobs and pursue their passions. It's especially easy if one is an "American hedge fund manager, entrepreneur, bestselling author, and podcaster"; i.e. financially independent and wealthy.

By all means, if your job is soul-destroyingly awful, begin making plans to leave it and move onto something better - but there's no shame in finding a less shitty, more fulfilling job as a stepping stone towards that wonderful day when you can leave all your obligations behind and do what you really love. There's no shame in paying taxes as an employee if you're saving up money to become financially independent. There's no shame in taking a reasoned chance on a new job hoping that your coworkers won't all be backstabbing sociopaths. There's no shame in trying something that isn't client-facing sales and marketing if you think your strengths and interests lie elsewhere.

Given that the ECMAScript community has (for good reason; "don't break the web") decided to avoid backwards-incompatible changes, that necessarily places a limit on the amount of "fixing" they can do to the language. New or enhanced features are okay, rectifying mistakes is harder.

(This isn't just a JS thing; go talk to any random Python developer and ask them what they think of Python 2 vs 3. There are tradeoffs to both approaches.)

http://www.2ality.com/2014/12/one-javascript.html

I think the missing piece is here:

"I am not questioning the many benefits of broadening or learning activities, just the premise that they lead to any sort of mastery." - Rich Hickey (from the same gist).

Norvig is speaking about becoming a better developer by becoming exposed to tools that solve problems in different ways, so that you can internalize those different problem-solving techniques and apply them when appropriate. But exposure alone has only a limited benefit - at some point being able to write a quicksort in a new language is going to produce diminishing returns. At some point understanding the advanced techniques offered to you by a programming paradigm is going to require studying that one paradigm to a greater level of detail.

Hickey is speaking about becoming a better developer through 'mastery' in the sense of thoroughly understanding a system, having the ability to acquire new information, identify and solve problems that comes only through extensive experience.

These are two different ways to become better as a developer. Hickey's point is that the 'skill ceiling' for the former is very low - once you've been exposed to a number of different paradigms, you can either continue learning even more languages for little marginal benefit, or you can begin to master one or more of the paradigms you've seen. And that mastery builds a whole different set of skills that will make you a better developer no matter what toolset you end up using.

> I can't help not getting excited by React or not spending a month learning OCaml or building side-projects tangential to my 9-5 line of work...it is a sure fire way to level up as a developer.

Do you feel the side-projects you've worked on in the past have made it easier for you to work on your job, or your current side-projects? Have they given you more insight? Do you come across solutions more easily because...

* you've seen and solved a similar problem before?

* the month you spent working on OCaml gave you insight into a functional way to reframe the issue?

* your exploration of react.js gave you a better appreciation of client-side engineering issues?

* something else?

If you can honestly say 'yes', you are almost certainly leveling up as a developer. Otherwise, you might want to examine whether your side-interests amount to more than dilettantism and whether you might be better served spending some time focused on a single topic.

Deadlines (self-imposed, even) make a huge difference for me. Being the lazy, unmotivated, dissolute individual that I am, I can confidently say that some of the most productive, sustained learning efforts I undertook these past few years were Coursera classes with weekly problem set (e.g. coding) deadlines.

Take this with the caveat that advice is what worked for the advisor, not necessarily the advisee. But if you really have this problem of focus, I ask you to consider doing this: go to Coursera, choose an upcoming course that fits your "highly technical subjects" the closest and looks the most appealing in terms of subject matter, and make the commitment to see that course through. If/when you complete it, in the future when you need to focus again you'll at least have that experience to encourage you, reminding you that in fact you can see something complex through to completion.

I heartily recommend everyone with a Google account follow that link and double-check your security and allowed app settings. (Also take some time to go through your app-specific passwords and revoke any that aren't relevant anymore.)

In addition to being good practice in and of itself, Google is currently doing a promotion where they'll increase your Google Drive space by 2 GB if you go through their security checklist (see link below):

http://googledrive.blogspot.com/2015/02/safer-internet-day-2...

> We conclude that developers limit themselves to using goto appropriately in most cases, and not in an unrestricted manner like Dijkstra feared

So this is pretty much the control flow equivalent of someone complaining about memory errors in languages like C (dangling pointers/memory leaks), and then much later some academics look through some code written in a managed GC'ed language like Java or C# and decide that the original complainer really didn't have anything to worry about.

Thanks! Exactly what I was looking for.

Question (not being sarcastic): what's the difference between 'science-based medicine' and 'evidence-based medicine'? I did a quick Wikipedia search, but the former just redirects to the latter.

Another interesting thing to try (and maybe complementary as well) is building an interpreter or compiler for a language you like, trying to match the spec and feature set as closely as possible, and (hopefully) gaining more insight into the tradeoffs the language designers made when deciding why things are the way they are.

Potential users can decide whether or not it's a poor choice themselves. I suspect the language would be more popular than a strict reading of its merits might suggest.

Swift has its own standard library, Foundation for things that fall outside the purview of the native stdlib (e.g. JSON parsing and regular expressions), and ApplicationKit/UIKit for GUI stuff. A multiplatform Swift + stdlib would already be quite useful for non-GUI applications on other platforms.

It looks like the annotations will allow the compiler to produce warnings when compiling the Objective-C code, so that's something:

"However, nullability annotations—in addition to improving the experience in Swift—provide new warnings in Objective-C"

Thanks! That makes a lot of sense.

Just out of curiosity, is it stated anywhere that Swift is memory-safe in parallel mode? Or is this a necessary prerequisite for reference-counted objects to be safely used with Grand Central Dispatch?

(I assume that whatever implementation exists is similar for Rc'ed objects in Rust, assuming Swift is indeed parallel-memory-safe.)

I use a combination of SourceTree and the command line for my workflow, and can heartily recommend it. Some operations are just more intuitive to me when using the GUI such as:

  - staging portions of many files scattered across a directory tree
  - quickly glancing over diffs for a given commit
  - understanding the commit graph and the relationship between local and remote branches

Each developer's experience may vary, but in general I feel like a good GUI tool can help a novice user develop and reinforce the mental model necessary to understand what git is doing. For example, what am I doing when I rebase my commit onto master vs merging it?

Of course. Understanding the underlying principles is necessary but not sufficient wrt the practice of engineering.

> but if you speak with them about their process, etc... it becomes clear they just hack on something until is works (sort of).

Do you think these sort of people still try to possess the underlying mental model needed to know how the system works and what effects changing something will have on the system? Or are they literally cut-and-paste/change-something-till-it-works coders to whom the actual code is little more than meaningless incantations?

I like how, out of the 20 examples, 10 of them essentially copied the HTML snippet in the 'Coder' section of the 2012 image. Most of them even left the "jedi" div intact.

On the other hand, only 6 of the examples copied the yellow-blue-pink splotch motif from the 'Designer' section.

(These don't have any meaning in the bigger scheme of things; they're just statistics that amused me.)

I wonder if creating a wrapper struct (let's call it Buffer) which combines an UnsafeMutablePointer and an UnsafeMutableBufferPointer would improve the language ergonomics while keeping the performance of the 'Swift*' version.

Buffer would have a constructor taking the number of items to store, and would upon creation create a buffer using UnsafeMutablePointer.alloc(). It would then use the UnsafeMutablePointer to build an UnsafeMutableBufferPointer. The latter type allows subscript indexing (e.g. myBuffer[10]) and iteration using for-in, which we could support by implementing a pass-through subscript() and generate() function.

Then, when using the struct, we'd pass it using inout parameters to ensure that it doesn't get copied.

This wouldn't fix the problem of Arrays being ludicrously unperformant, but it would at least make using the C-style buffer less painful.

That's quite plausible.

The code isn't quite as terrible if compiled with optimizations on. I like your hypothesis elsewhere in the thread, that the optimization pass is probably removing unneeded array copying that hinder the performance of the debug build.

Semantically, an Array is an automatically resizing, reference-counted, copy-on-write, bounds-checking sequence of elements, none of which I want if I'm building a buffer for pixel values. So there is a significant mismatch between my desired use case and the characteristics of Array. I really do think there should be a fixed-size non-copy-on-write collection type at some point added to the language.

From an operational perspective, you're right, the analogy is quite leaky if you examine it closely.

> told to use Swift arrays as we would C arrays

Until you can declare a fixed-length Swift array, or a Swift array that isn't copy-on-write by default, or a fixed-length Swift array that doesn't live on the heap, this can't possibly be true, no matter what you think you've been told.

> it should be usable for low level, high performance programming but "safer than C".

With optimizations turned on, the 'Swift []' code comes within 3x of the performance of the ObjC code. Lots of room for improvement, but not abysmal either.

> Furthermore, using UnsafeMutablePointers in Swift makes the program a magnitude larger than the corresponding C program...It is a last resort, not something you should use all of the time.

I agree.

> UnsafeMutablePointer (which is basically direct C-style memory access)

The article discusses two Swift versions of the same program, one that uses UnsafeMutablePointer (which is basically direct C-style memory access), and one that uses Swift's built-in Array type. The former runs well, the latter is slow.

If you look at the Objective-C code, BackingBuffer is a C struct containing a C array of Pixels (themselves each a 32-bit C struct).

The problem is that the best analogy to Swift's Array type is not the C array in Objective-C - it's the Foundation class NSArray. For the given use case, most Objective-C developers would eschew NSArrays and classes serving as data bags in favor of fixed-length C arrays containing C structs. C arrays don't perform bounds checking, they require you to manually decide when to allocate, copy, and free the backing memory, they require you to know how much space each piece of data requires and work with the data accordingly, and so forth.

The fact that NSArrays can't hold value types, only references to classes, complicates things a bit, but I doubt the Objective-C code would be anywhere as fast if the backing store was an NSArray holding NSValues or something similar. Comparing the Swift implementation using Arrays to the Objective-C implementation using C arrays is not really fair.

Thanks for the paper link! I'll check it out. (The histogram legend seems to indicate two distributions of observed GRBs, the larger centered around 8 degree cones.)

Is the gamma-ray burst a spherical field, or is it a narrow, directed cone? If the latter, I wonder how the burst spreads/diffuses as it travels and what sort of equation governs the energy flux with respect to distance and initial conditions.

If you're comfortable writing object-oriented code in Python and PHP, you should be fine. The object-oriented parts of Swift are thoroughly ordinary.

One major concept you will want to become comfortable with (that doesn't really exist in dynamic languages AFAIK) is the concept of protocols: https://developer.apple.com/library/ios/documentation/Swift/...

If you're not comfortable with anonymous functions and closures, I'd recommend getting familiar with them as well, since they play a major role later on in the course.