Why I Write in Pure Swift

I have had the pleasure of working on several Swift data structure and algorithm libraries over the past year, including SwiftGraph, SwiftPriorityQueue, and SwiftCSP. I wrote all of them in what I call "Pure Swift" (and maybe others are calling it that too). By Pure Swift, I mean Swift code that utilizes only the Swift standard library with no external dependencies and no use of Cocoa or Cocoa Touch (including Foundation).

Why write in Pure Swift? Swift has a small standard library, so sometimes being Pure Swift can seem somewhat limiting. Apple has already told us that they will be open sourcing Swift and releasing a version for Linux. It's a near certainty that the release will not include a version of Cocoa for Linux (although there is GNUStep and they say they will have bindings). So, if you're working on a project in Swift that doesn't need to make use of Cocoa and you want it to be portable to future incarnations of Swift (including those on other platforms), then you should write it in Pure Swift.

There's also the possibility that the future will bring a new UI framework from Apple that is written in Swift to begin with to supersede Cocoa, but I wouldn't hold my breath after its near thirty year history. But, if that remote possibility is to come true, then once again you will want your existing projects as much as possible to be in Pure Swift. For the present, by writing in Pure Swift you get automatic cross-platform compatibility between OS X and iOS.

Finally, there's something that just seems hobbled when you rely on too many Objective-C classes in your Swift code. It's hard to make value types work well with them, and there are several other incompatibilities like tuples.  I love Objective-C, but I want to keep my non-UI Swift code pure.

Dart for Absolute Beginners One Year Later

It's been about one year since the release of Dart for Absolute Beginners. The book was very well received by readers around the world. One review on Amazon even called it “…one of the best introductory texts on computer programming in general; bar none.” That's high praise indeed. The exclusively positive reviews in its first year have been very gratifying.

On the flip-side, Dart adoption has not reached the level that I hoped it would and that certainly has affected the book’s sales. The Dart team has been very supportive of the book – highlighting it on social media and participating in its foreword and an interview chapter (chapter 18). But that can't make up for the language’s lack of adoption. I don't think Google's announcement that the Dart VM will not be included in chrome has helped things. Whatever the case, you don't write a book like Dart for Absolute Beginners to make money.

I also created a video series that can be thought of as an accompaniment to the book, for my publisher, Apress. That series is yet to be released although I completed it some time ago. Truthfully, I have not received many updates on its status and I don't know when it will be released.

Dart Language Changes

The source code in the book, despite being written in the early days of Dart when the language was still evolving, is still valid for the current version of the language. However, the language has added some features that are not covered by the book. The most notable of these is async/await (which I anticipated in a note about likely future additions in the concurrency chapter). The Dart team also announced that a future version of the language will include null-aware operators and generalized tear-offs.

I don’t think these are a particularly huge issue given the intended audience of the book (absolute beginners), but it is an annoyance. If the book were written today, async/await would play a significant role in at least a couple of the book's eighteen chapters.

Dart Ecosystem Changes

This is where the larger changes have happened since the publication of the book. The most relevant to the book, is the elimination of Dart Editor (the IDE originally included with one’s download of the Dart SDK). I purposely didn't make the book a tutorial on using Dart Editor. I thought that was a good decision at the time, and its removal has proven me right.

None the less, the book does make mention of Dart Editor enough (especially in the first couple of chapters), that the Dart team's decision to eliminate it will prove confusing for readers. Unfortunately, I feel the alternatives available today are either too simple (DartPad) or too complicated (WebStorm with a Dart plugin) for the type of projects I designed for the book. I’m not sure which I would choose if I rewrote the book today.

Another ecosystem change, the aforementioned end of planning to put the Dart VM into Chrome, make some of the forward-looking statements in the book no longer true. The ecosystem has not yet coalesced around a single server-side solution or GUI toolkit. Therefore I’m glad that I did not “pick a winner” when addressing (or not addressing) these topics.

Is the Book Obsolete?

With the changes mentioned, the book is certainly no longer current. I think it’s still a fantastic introductory programming book and all of the topics covered are still completely valid. The source code is still valid. I think it still offers a ton of value, but I can see how the elimination of Dart Editor in particular, despite being a small part of the book, may confuse new programmers.

I don’t look forward to the inevitable “out of date” bad reviews. If Apress contacted me to do a second edition, I’d certainly be up for it. Will I contact them about it? Maybe – it depends how much free time I have in the next year.

Swift Standard Library Signaling

The Swift standard library is small at best. Apple's documentation provides a starting point for understanding it. However, it does not cover the standard library in its entirety. For the curious, a more comprehensive look can be had over at SwiftDoc.org.

Popular programming languages of the past 20 years have tended to incorporate a large standard library. Consider, for example, Java and Python. Both have a batteries-included philosophy. On the other hand, older languages that made it big, like C and Fortran, tend to have small standard libraries. This distinction may be attributed more to the time when they were developed (in terms of hardware capability, especially memory & disk capacity) than anything else. It should also be stated that Java (with the JVM) is more than a programming language; it is a platform unto itself.

So, why in 2014 did Apple decide on such a limited standard library for Swift? Is it a function of the youth of the language? The standard library has evolved and slightly expanded over the past (nearly) year since Swift was released. It may very well expand in the future. There is a more obvious rationale for explaining Swift's anemic standard library than its youth though.

Let's consider other modern languages with tiny standard libraries. JavaScript was purpose designed to run within the confines of a web browser.  Since it piggybacks off of an existing platform with an extensive API (albeit retroactively designed for it), its standard library can remain relatively slim. In a similar vein, languages that run on the JVM, like Clojure and Ceylon, can take advantage of Java's extensive libraries and don't need large standard libraries of their own.

Swift was designed to work with Cocoa and Cocoa-Touch, also therefore piggybacking off of an existing comprehensive platform. By not including a large standard library, Apple is indicating to developers that Swift is expressly designed for its platforms. "Well duh," you might say. But sometimes corporations develop new languages that they hope to eventually have adopted by the wider world beyond the gates of their platform. Wasn't that Sun's hope for Java? Isn't that Google's hope for Go and Dart? They figure being in control of a language widely adopted across the entire computing world is only to their benefit and will lead to additional developers on their platforms.

Perhaps Apple is so large and influential that it has no such concerns. Or, perhaps Apple's need to work within the confines of its existing software technology trumped these pursuits. Or, most likely, perhaps Apple simply prefers to keep its language technology proprietary as a competitive advantage.

In some sense, Swift is to Cocoa as Clojure is to the JVM and JavaScript is to the web browser (as we know, it eventually broke free). Yes, it may be open sourced in the future, and there may be alternative implementations (see Silver for example); but Swift's small standard library is Apple signaling that it was not made for the world, but instead the enclaves of iOS and OS X. As developers, we have to fill in the gaps. If you head over to GitHub, you'll find projects that do just that – provide fundamental functionality in pure Swift (without utilizing Cocoa) that is usually provided by a standard library. I have two such projects in the data structure space: SwiftGraph and SwiftPriorityQueue.

My 2014 in Side Projects

Inspired by similar posts, I decided to recount my last year in side projects. This is helpful for me because it puts the year in perspective, and perhaps hearing about some of these projects will be interesting for other people.

First, what is a side project? To me, a side project is any work that is not your main source of income. That's not a great definition, because reading a book would therefore be a side project. When it comes to side projects, perhaps it's more apt to say, as Justice Stewart did about obscenity, "I know it when I see it."

chess.dart

In early 2014, I ported chess.js from JavaScript to Dart. I had previous experience with chess programming both in graduate school and through one of my oldest still active side projects. chess.dart began as a line for line translation of the original JavaScript source code, but evolved into something more. Initially, the Dart version was several times slower than the JavaScript version (largely because it relied on maps, as in the JavaScript version, rather than custom classes). I was lucky enough to have one of the godfathers of Dart, make contributions to the project that refactored it in a more Dart-like fashion. Of course after this software maestro touched the project, it significantly outperformed its JavaScript counterpart.

I haven't had much of a reason to work on chess.dart since it reached feature parity with the JavaScript version. It even passes all of the same hundreds of unit tests. I have ideas for future projects based on it, but what really delighted me was its use by Anders Forsell in chessboard.dart and chesschallenge. Both of them are really awesome projects that show off the power of Dart and web components. Anders wrote a couple blog posts about them.

Dart for Absolute Beginners

Dart for Absolute Beginners took about 9 months to write and came out in the early summer, published by Apress. It was the first book (and I believe remains the only) written about Dart designed for people learning it as a first programming language. I believe in the book and it has been very well received by reviewers. One reviewer recently called it, "...one of the best introductory texts on computer programming in general; bar none."

Writing the book by myself was a lot of work, but Apress provided a ton of editorial support. Everyone at Apress was pleasant, professional, and helpful. I think we put out a great product. Being a beginners' book, I stuck to core concepts that will not become outdated as the language evolves. However, I did manage to stick in an interview with the founders of Dart, Lars Bak and Kasper Lund. That chapter (chapter 18) is a real gem that even experienced programmers will enjoy.

I created a 12 hour video series based on the book for Apress, but its current status appears to be in limbo after a reorganization of the company. I'm as in the dark as anyone about what will happen to the series, and I am anxiously awaiting some kind of resolution regarding the matter (it was a lot of work to create!). For some reason it seems like you can buy it on Springer's website, although I haven't yet received my advance...

Kopec's Chess Camp 2014

My dad is a well known International Master in chess. He had run fairly successful chess camps since 1994 (with a dedicated business partner, NM Hal Terrie) but took a five year hiatus prior to this year's camp. He asked me to basically run the camp this year from an administrative perspective including marketing, book keeping, handling registrations, medical forms, insurance, making/mailing the brochure, etc. We held the camp at the beautiful New Hampton School near Lake Winnipesaukee in Eastern New Hampshire. While the numbers weren't huge (there's a lot of chess camp competition these days that didn't exist when my dad was a pioneer two decades ago, and the location was a bit remote), everyone had a great week.

Crump

I started working on an 80s style arcade game over the summer to help me learn Swift as part of the Summer of Swift. I used Tiled to edit the levels and the well made JSTileMap to render them with SpriteKit. I got to the point where I had a pretty cool concept and working gameplay. However, once I encountered a rendering bug, I kind of gave up on the project as other work took my time and the contest seemed to be fizzling out (was there even a winner declared?). The (currently showing a black screen) repository is still up - maybe I'll get it rendering again when I have a little more time.

Splip

Splip is an iPhone app I released in the early fall for turning a photo into two encrypted negatives that can only be recombined to view the original when you're in near geographic proximity to the person you shared one of the negatives with. It's a cool concept and the app store version totally works (using email to send negatives and Multipeer Connectivity to recombine them) but I'm not sure there's much of a market for it.

Restaurants

Restaurants is a native Mac Yelp API client that's super fast and integrated with OS X features like Continuity and Maps. I released it in November and it's been selling pretty well. It made it as high as #4 in the top grossing apps in the Lifestyle category on the Mac App Store (which doesn't take much apparently). I wrote a blog post about my experience writing it in Swift that was pretty popular (at least as far as this blog goes!).

SwiftGraph

SwiftGraph is a graph data structure library written in Swift that I created in a few days in November. It recently got a positive mention on a major iOS dev blog. Although it's not battle proven or fast, I did a lot of best open source project practices when making the library - like including copious in-source documentation, unit tests, and a fun example program. I attribute the recent interest in it to these factors.

A side note about SwiftGraph is that despite recently getting about 30 stars in a 24 hour period on GitHub, it never showed up in GitHub's trending Swift repositories. I think the algorithm they use favors projects that already have hundreds of stars, which leads to a lot of inertia. The trending page on GitHub is a place where open source projects get a lot of exposure. It's sad that its cards seem stacked against young projects. There are projects that only have 5 stars in the past 24 hours that show up in the trending 24 hour section. I emailed GitHub about what it takes to trend and they replied that they don't reveal their algorithm - I think it would be great if they were more transparent about this.

Crafting a Course

I took a job as adjunct faculty at a local community college. I'll be teaching an advanced Java class and a database course next semester. It's a side project because it won't be my main source of income, that will still be consulting projects, but I figured it would be fun and provide some great teaching experience (and maybe even inspiration for my next introductory programming book). My boss there asked me to redesign the database course I'll be teaching, so I spent some time doing that this Fall. I'm coming into it with a lot of enthusiasm and excitement. I hope the students feel the same way.

So, that's my 2014 in side projects. Back in my Dartmouth days, we might've called a blog post like this a giant "self call" which is a negative term. But to be popular in tech they say you need to master the humble brag, right? It was quite a productive year for me with regards to side projects, but I hope to exceed it in 2015. With that regard, I rather do a few less and have them be as successful as Dart for Absolute Beginners, than necessarily do as many as I did in 2014.

Incidentally, if you have potential consulting projects that are related to anything covered in this post, do get in touch with me through Oak Snow Consulting. I'm pretty booked for the next couple of months, but let's get the conversation started if there's a good fit.

My Experience Building a Small Mac App in Swift

I dabbled with a Mac Sprite Kit game over the summer and was generally pleased with the experience. The last couple of weeks I put together a small full Mac app(Restaurants) currently under review on the Mac App Store (Update: now released) written largely in Swift. Here are a few notes from my experience. As you read them, please keep in mind that the last Mac Cocoa app I built was in 2003 (pre Cocoa Bindings even!). Since then all my Cocoa programming has been iOS. Also keep in mind, while I have a formal CS graduate education, I am a very applied guy, so I might not always get the theory parts/terminology right here.

Cocoa Bindings
Having not built a Mac Cocoa app since pre-Cocoa Bindings, I was amazed with how convenient this technology is (and a little disappointed that it never made its way to iOS). It relies on KVO/KVC of course, which feels like a bit of a hack in Swift (make sure to use the dynamic keyword). It would seem that there is a lot of room for improvement/new innovation in Swift with more advanced versions of property notifiers like didSet/willSet taking the place of KVO/KVC somehow (although I haven't yet figured out how). Ultimately everything did "just work," including doing Bindings between Swift interface elements with Swift objects that have properties which are Objective-C objects, which speaks to how well the two languages really do integrate.

Objective-C Integration
Speaking of Objective-C, the library for interacting with Yelp used in Restaurants is written in Objective-C. I modified it a bit as I worked and once again it was impressive how things "just worked" when called from Swift. Clearly this language was designed for that purpose. The bridging header is short and simple enough, but like dynamic, it also feels a bit hacky.  Once when I created it manually (and even setup the project settings correctly I thought), the linker didn't recongnize it. It seemed like only when Xcode created it for me, was everything setup correctly (yes I specified the name of the bridging header). It could be that I made a mistake in the project settings - but I do think things should be more automatic. Can't the bridging header be created for us at build time when Xcode detects the project has a mixture of Objective-C and Swift code in it?  Ah... first world problems.

Sometimes it was unclear to me as a Swift newbie how some Objective-C method parameters should be provided from Swift as far as type signatures go. Better hints in Xcode would be helpful.

Optionals
Although I've worked in a lot of different languages over the years, I never have worked in one that made such extensive use of optionals (Haskell has maybe - feels like sorta the same thing to me, but I only did Haskell for a few months). Do optionals make the code safer? Yeah it feels like they do - a little bit - although I still created errors for myself occasionally by unwrapping nil optionals - so clearly we can't completely protect ourselves from ourselves. But I also now have an inoordinate amount of boilerplate if let statements.

The big problem with optionals though is interacting with the Cocoa frameworks. I feel like Swift was designed for most variables to be non-optional, non-nullable values (I could be wrong of course) and optionals are supposed to be the special cases. But instead, due to having to work with the Objective-C Cocoa frameworks, almost everything is an optional. It's annoying - the boilerplate is annoying, the unwrapping is annoying, and the cognitive overhead of deciding what should be !, ?, etc. is annoying. Personally, while I feel I fully grasp the concept and I appreciate the safety, it hasn't been worth the loss in productivity for me when dealing with Cocoa.

Syntax
There have been a lot of comparisons saying "it's like this or that language." For me, someone who has spent the last few years programming professionally in C, Objective-C, Java, Dart, JavaScript, Python, Ruby (so mostly C-like languages except the latter two) but with significant exposure to some more academic languages, Swift doesn't quite feel like any of them. It does feel fresh. It does feel like an amalgamation of some of the best ideas of each. Just the lack of @ symbols and headers makes it more compact than Objective-C (and I like Objective-C a lot). I honestly think it's the optionals again that stops it from being perfect for me. It feels like there are too many ?s, !s, and if lets littering my code. Frankly I think that sort of stuff is what makes a language a bit hard/not fun for a beginner to grasp (and I'm the author of an absolute beginners programming text and do teach beginners professionally so I know something about this - this might be the only opinion of mine here that shouldn't be taken with a grain of salt).

Philosophy
Like every mainstream new language out there, Swift tries to bring the best of the functional world to object-oriented programmers. I think it largely succeeds. I'm even worried the community is going too far in the functional direction. I'd like to see more of an emphasis on the object-oriented features of Swift in the future. On a day-to-day basis, that's the world I think/work in, and I think that's true for most Mac/iOS developers. It's great to see the energy, enthusiasm, and contributions of the functional folks who have gotten involved with Swift. I look forward to taking advantage of it. However, my work is so much more about building intelligent class hierarchies than it is about building cool recursion tricks (ha that sounds awful and debasing - didn't mean it that way!).

Also, I appreciate the dynamacism of Objective-C. Like many have said, Swift feels more like C++ (and my understanding is that its method dispatch is more similar to it than Objective-C (please correct me if I'm wrong)) than Objective-C. Maybe we need that for the speed advantages, but that's awkward when we have to deal with these huge Objective-C frameworks all_the_time. I saw someone propose on the Apple developer forums that the dynamic keyword should be default. No, I don't think we want that slowness by default. I think what we want is to take full advantage of new, better ways of doing things, than what we had available to us in Objective-C. But we're handcuffed by Cocoa. I think Swift won't start to really have its own voice/come into its own until we have Apple frameworks written in Swift.

Bugs
I had Source Kit crashes. I had weird, unexplainable errors. I had bad syntax highlighting. Generally things got slightly better over time but some of them I still can't explain. Unfortunately it's not very easy to explain how to reproduce all of these bugs in Radars. I feel like it would be helpful if it was easier to just share full projects with the team somehow. Here's a radical idea - what about adding a built in screen capture video tool in Xcode that could also send your source code (with your permission of course) straight to Radar. Too much potential for hackers maybe?

Working on a small app, I didn't encounter some of the slow compilation issues that a lot of other people have. In general, I found the actual compiling/running process to be pretty pain free.

Community
The Swift team at Apple has been awesome on the Apple developer forums. Some cool sites have popped up on the Web like sososwift.com and others that aggregate high quality material. However there's also been a lot of negativity, which is understandable given how invested some people have become in the language given the obviousness of its future as the premier Apple sanctified language. A lot of the tastemakers who are updating their Cocoa books for Swift have been particularly vocal. I appreciate that - I wrote a book about Dart starting when it was still in beta and nothing is more frustrating than changing something big when you're going to print. But that language faced relatively few changes/bug issues compared to Swift in its early development (they also made the first public beta release a full 2 years before I started, so it's not a fair comparison).

Swift has attracted an interesting combination of long time Apple developers, brand new Apple developers, and people from the functional programming world. Sometimes it feels like these three groups are speaking Greek to each other. There are regularly code snippets on the Apple developer forums that I, a long time developer, don't fully grasp without careful study. We need coding standards, and we need more direction from Apple regarding conventions and style. We need more sample code. We need the first few books by the people most invested in Swift to come out from the major publishers. Then we'll see where the cards fall and which of these groups will get the most pull in the Swift world.

Anyway, that's it for now. I will not be doing my next big client project in Swift, but I will continue to use it in my personal projects. I also posted this on the Apple developer forums.

Network Connection Required

One thing I see time and again in mobile app development is bugs caused by syncing a local persistent data store with centralized data on a server accessed via API calls. An incredible amount of software development time goes into making the sync process smooth, elegant, and robust. Yet, in a mobile world with nearly-always-on network connections, we need to ask ourselves if the effort makes sense for all apps, especially for MVPs (Minimum Viable Products) of apps focused on content consumption.

Why is sync hard? Generally, it's a matter of the server and the client having radically different data store technologies. The translation that needs to mediate that disconnect can be complicated. A common scenario is for a mobile app developer to use a BaaS (Backend as a Service) like Parse. To take the example and run with it, Parse has an arguably excellent, easy-to-use API. Yet once the mobile app pulls data down from Parse, which will be in the form of Parse objects (PFObjects), he needs to translate it into a format suitable for storage in something like Core Data or SQLite.

This translation needs to happen in two directions (SQLite -> Parse and Parse -> SQLite). Further, consider the situation where the client accesses the application from two different devices simultaneously. Perhaps device one makes changes to the same piece of data as device two in their respective local data stores, and then both are synced with the Parse data store. Which revision should take priority? There are solutions to this problem (of course), and they're not necessarily complicated - but they are intricate when one considers corner cases.

Parse together with SQLite was just one example - perhaps the server-side is using an ORM wrapping around MySQL and the client-side is using Realm. Perhaps the client-side is just using NSUserDefaults... It really doesn't matter. The bottom line is it gets complicated. So complicated in fact that the well-known and highly regarded Mac/iOS developer Brent Simmons wrote a "diary" about his experience implementing sync for the note taking app Vesper.

Is it worth it? I don't believe so for the majority of apps, especially when they're in the get traction phase. It's not worth the potential bugs and it's not worth the development time. What's the alternative? Keeping the local data in a more flexible in-memory store - essentially a cache - and requiring a network connection to do any content creation.

The advantage here is that it takes away a step in the translation process. After the data is deserialized from the remote server, it can be used instantly and we're not beholden to worrying about multiple devices. The copy on the server is always the canonical copy when it's the only permanent data store. If the user tries to post a comment/post a rating when not connected to the net, we simply tell him he needs a network connection. Keep it simple. It's not ideal, but in a content consumption app, it's probably a minor annoyance rather than a deal breaker.

This doesn't work for apps that feature long form content creation (such as a note taking app like Vesper - or perhaps a video sharing app). They need something robust that ensures even if the network connection dies the user will not lose his work. But for apps that are all about consumption of content not produced by the user, or where the user's data input will never be more than a short blurb, perhaps the syncing madness is unjustified. I rather the user have the risk of once in a blue moon losing a star rating than be subject to a crash-prone MVP.

It goes without saying that as apps move from the MVP phase to the "we have more resources" phase, syncing becomes a much larger priority. The point here is that early on, sometimes syncing is just too much of a distraction.

A Purposeful Personal Loss of Anonymity

This blog has existed for nearly three years and it's time for its author to stand behind its writing. Up to now, it's been unsigned. Sure, if one wanted to lookup who owned the domain name, the authorship could be easily obtained. However, it was purposely presented as anonymous to offer the subject matter a certain degree of freedom.

Yet, retrospectively, none of the content has been that controversial and there is certain merit to signing one's work:

• It informs the reader about the biases of the author. Some may even argue it's a more ethical way of writing.
• It may help to create a sense of connection between the author and the reader.
• It may pique the reader's interest in continuing to read if he finds the author somehow relatable.
• It lets the reader know what other works are by the author so that he can judge the work in the right context.
• It allows the reader to judge whether the author is a reliable source.

So, my name is David Kopec, and I'm the author. I'm a software consultant in New York. That means I build iOS and Web apps (mostly for startups). I'm also the author of Dart for Absolute Beginners which in my highly biased opinion is an excellent starting point for learning how to program. I haven't yet written about politics or foreign affairs here and I don't plan to. I hope to keep the hate mail to a minimum. I also plan to start using this blog as a platform to write about more technical topics.

I started this blog in early 2012 when I was quite interested in the concept of anonymous content creation. Just a few months before that, I had launched the anonymous poetry app Poemz as an experiment, which has been mildly successful. As its sole moderator, having to read thousands of mostly anonymous poems, I've learned a lot about the strengths and weaknesses of anonymous content creation. The biggest feature requests are for less anonymity - users want to have profiles and commenting systems. They want to have some sort of identity and voice. Some users find ways to link to their real-life online profiles, which is of course against the anonymous spirit of the app.

In that time period we've also seen the rise of anonymous social networks like Secret. Anonymous content certainly has its place. It gives voice to those with something valuable to say who for whatever reason can't risk their reputation by putting their name behind it. The Federalist Papers were famously published by Alexander Hamilton, John Jay, and James Madison anonymously. Was there ever a better collection of thoughts on governmental theory?

I recently met with a startup founder focused on an "anonymous social network for positivity." They had built a cool app that was out in the wild and had some good ideas. The anonymous space is hot right now. Yet, positivity is not usually what people want to use anonymity for. Usually they want to use it for negativity. Think Reddit, 4Chan, black-hat hackers, and violent flash mobs.

I used to believe that the future of the Web was anonymity. The Web boom of the '90s focused on anonymous content consumption. The '00s were all about signed content creation (think Facebook, YouTube). I thought the third era would be a combo of the two - anonymous content creation. But anonymous content creation has its limits. We want to trust our sources, so we need to know who they are. We want to connect with other people, not just ideas.

For most long-form writing, for all of the reasons stated above, you should sign your work. That's what I've come to believe and that's what I'm now going to practice. I think Poemz and Secret are great platforms for short-form expression. I think long-form expression should usually be coupled with ownership/authorship. Especially, if it wants to be taken seriously. And I do.