Rust and the Future of Systems Programming [video] - <AUTHOR> https://hacks.mozilla.org/2016/11/rust-and-the-future-of-systems-programming/ <comment><USER2> Now I have four services running on production, all written with Rust. If it compiles, it usually works. Of course you have these late night sessions where you write that one unwrap() because, hey, this will never return an error, right? And bam...

I'm seriously waiting that tokio train to be stable and a unified way of writing async services without needing to use some tricks with the channels or writing lots of ugly callback code. Also the native tls support is coming and the dependency hell with openssl would be gone forever.

If you need http server/client, I'd wait for a moment for Hyper to get their tokio branch stable and maybe having support for http2 by migrating the Solicit library.

<comment><USER3> Would it make sense to have a cargo/rustc flag to disable unwrap and friends when building for production?

<comment><USER4> "Pray, Mr. Babbage, if you put into the machine wrong figures, will the right answers come out?"

Unwrap implies "either this operation should succeed or we should panic". Doing anything other than panic seems like it's terribly difficult to determine what that should be. And I might've put unwrap() there because that's really what I want to happen. For `mv`: don't let's dare go ahead and do the unlink() if the link() failed!

Tangent: errors and exceptions aren't bad, they're how computers work. I've encountered folks who, when faced with runtime errors pepper their code with "if (!NULL)" or truly evil things like "except:pass"/"catch (...) { }" which rarely make sense anywhere but the base of the stack and even then don't usually. If you've ever asked yourself "but how did we even get here‽" it may be because someone dropped something totally incongruous like that in a related module.

<comment><USER5> I think the idea would be the program would fail to compile, and you would need to go back and replace the unwrap with proper error handling. The goal would be to allow the use of unwrap during development, but require the final polish before the code goes into production.

<comment><USER6> unwrap _is_ proper error handling. It says "Try to do this. If it fails, panic". Its like an assert on an invariant that the compiler requires.

If my script depends on a database connection, I might connect to a database and unwrap() it so the script errors out if the database isn't available. If I wrote that logic myself I would just be awkwardly rewriting unwrap.

<comment><USER7> To be more accurate, unwrap can be a legitimate means of error handling when used in an application, as opposed to a library. But if you're writing a library, then unwrapping rather than using Result is a surefire way to make your users hate you. :)

<comment><USER8> Sometimes you've proven some invariant in some other way, so you know that unwrapping is guaranteed to not panic. Although in those cases I prefer to use .expect("this will not fail because of blah") instead in the spirit of self- documenting code.

<comment><USER7> Agreed, I use `.expect("Infallible")` for such cases.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER4> > GC pause ... sufficiently low power hw .. cheap phone

Yeah, but even high-powered hardware can take a "major" hit from a GC pause when your application is extremely latency sensitive.

IMO it would be great to get folks who write the enormous base of existing realtime apps driving critical devices everywhere to sit up and take notice of Rust.

EDIT: I mean to say that many of my colleagues who write realtime software dismiss new languages as including GC baggage by default (because so many do!). So, hey, good that the video calls this out.

<comment><USER9> > IMO it would be great to get folks who write the enormous base of existing > realtime apps driving critical devices everywhere to sit up and take notice > of Rust.

Rust cannot make any latency guarantees either. Reference counting and its lifetimes also have pathological cases, ie. worst-case, an object can reference the entire heap which will take time proportional to the number of dead objects to free.

Copying collection in this case takes literally zero time, but it's pathological case is when all referenced data survives the current GC cycle, ie. proportional to live objects.

There's no free lunch!

<comment><USER10> > Rust cannot make any latency guarantees either. Reference counting and its > lifetimes also have pathological cases, ie. worst-case, an object can > reference the entire heap which will take time proportional to the number of > dead objects to free.

Rust doesn't use reference counting by default. Refcounting is _very_ rare in Rust, much more rare than it is in C++. Most large C++ codebases I've worked with have thrown in the towel and started refcounting all the things. In Servo, for example most of the refcounting is across threads (where you basically have no other option), and a few interesting cases in the DOM, each with very good reasons for using refcounting.

Lifetimes are a concept at compile time and don't exist at runtime.

Edit: Oh, I see what you're talking about. A sufficiently large owned tree/graph in Rust will introduce latency. It's predictable latency though. I can make the same argument about for loops.

Unpredictably sized large trees in Rust are again pretty rare in general.

<comment><USER11> Trees don't have to be refcounted in Rust. Single-ownership trees are possible. As long as they don't have backpointers. Backpointers are a problem under single ownership.

<comment><USER10> Right, I never said that trees have to be refcounted. A sufficiently large ownership tree will get deallocated all at once, which is the kind of latency the GP is talking about.

<comment><USER11> Linked data structures in Rust get complicated, though. See the "Too many lists" book.[1] Doubly linked lists, or trees with backlinks, are especially difficult. Either you have to use refcounts, or the forward pointer and backward pointer need to be updated as an unsafe unit operation. There might be an elegant way to do this with swapping, but I'm not sure yet.

[1] [http://cglab.ca/~abeinges/blah/too-many- lists/book/](http://cglab.ca/~abeinges/blah/too-many-lists/book/)

<comment><USER10> Right, so you implement them with unsafe. While you can implement doubly linked lists safely with refcounting, you're perfectly free to implement them with unsafe code. This is what unsafe code is _for_ , designing low level abstractions with clean API boundaries.

(Also I don't see how this is relevant at all)

<comment><USER11> _Right, so you implement them with unsafe._

If you need unsafe code for basic operations within the language, something is wrong with the language. This isn't about talking to hardware, or an external library. It's pure Rust code.

(Some pointer manipulations can be built from swap as a basic operation. That may work for doubly-linked lists. The other big problem is partially valid arrays, such as vectors with extra space reserved. There's no way to talk about that concept within the language. There could be, but this isn't the place to discuss it.)

<comment><USER12> > need unsafe code for basic operations within the language

Building custom back-referencing data structures is not a "basic operation" anywhere outside programming classes. Adding significant complexity to rust Rust to make a 2% case marginally safer would be make the language worse. As long as the vast majority of code is not unsafe, then it achieves its goal.

</comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER13> I keep trying to learn rust but fail miserably.

They do say on their website that there's a hump that you have to climb over before everything fits into place, which is probably applicable to everything you'll learn, but sometimes I think that hump is too much of a hurdle

<comment><USER14> How are you trying? What are you getting stuck on? I'd love to improve things.

<comment><USER15> Not specifically about your book, but I would love if there was a quicker way to find methods in the docs.

Right now, if I want to find the methods used by BTreeMap you have to wade through a good amount of information until you can find how to just get the keys. I'm currently on mobile where the issue is more prominent.

<comment><USER4> If I don't find what I'm looking for from the docs, I often use ripgrep on a copy of the rust repo locally to find answers.

<comment><USER16> > I often use ripgrep on a copy of the rust repo locally to find answers

I mean, that works, but it's a workaround and not a solution.

</comment></comment></comment></comment></comment><comment><USER17> The state of Rust editors continues to evolve [1], but I would be curious to learn more about the editors/IDEs that people are using for Rust development. Any stories or thoughts?

[1] [https://areweideyet.com/](https://areweideyet.com/)

<comment><USER18> I'm using IntelliJ-Rust [1]. Doesn't go to the definition of macros, and sometimes auto-complete doesn't work, but - it's comfortable enough to use.

[1] [https://intellij-rust.github.io/](https://intellij-rust.github.io/)

</comment></comment><comment><USER19> Rust is great. I've been following it since pre-1.0 and writing code with it for about as long also. It's really come a long way, my favorite language for pretty much anything except web development.

<comment><USER20> Wow! You've got my attention!

I mean, I feel many rust stuff (crates/dev/tools) seems to focus on high performance web so, as a low level guy enjoying bitwise ops and dynarec stuff I was wondering if rust what a good thing for me or if it would be better to stick in C. Can you tell me which kind of project you do in rust, what was your original language and why rust shine compared to your previous language?

<comment><USER19> I started on Java in school for software eng. After that I did a lot of front and backend development in dynamic languages and forgot all about types.

Until I discovered Haskell and saw what a really powerful type system can do. Rust's type system is very very similar to haskell's if you substitute the word 'trait' for 'typeclass'. However code is imperative, so that's nice for some applications, and is faster/lower level.

I've used the crate nom ([https://github.com/Geal/nom](https://github.com/Geal/nom)) in the past, it's a parserc library for consuming bits/bytes. I used it to write a function that consumes a vector of unsigned bytes, 11 bits at a time. If you're interested in that sort of stuff, take a look for yourself and see if you like it.

As with most things in Rust nom generates parsers with little to no runtime overhead, so you pay nothing for the increase ergonomics.

</comment></comment></comment><comment><USER21> Congrats to all the Rust team!

Love the zero-cost abstraction approach, love the good practice compiler warnings, love the cargo ecosystem, love the markdown code dox that tests the example code.

First time I actually enjoyed reading a programming language's documentation.

</comment><comment><USER22> I'd love to see someone write a game engine in Rust to compete with the "big boys" like Cry or Unreal. C++ game code can be such a nightmare.

<comment><USER23> Not going to happen in the next 10 years, everything is built around C++. And tbh I don't see what would games benefit from using Rust instead of C++.

<comment><USER24> I've never worked on anything gaming related, but the bigger cross-platform games certainly have crashes. I can't even tell you how many times Fallout 4 has crashed for me (likely hundreds). I obviously don't know if rust could help, but it's not unreasonable to think it might.

</comment></comment></comment><comment><USER25> Does Emscripten support Rust already?

<comment><USER4> Yes. See [1] for details.

[1] [https://users.rust-lang.org/t/compiling-to-the-web-with- rust...](https://users.rust-lang.org/t/compiling-to-the-web-with-rust-and- emscripten/7627)

<comment><USER26> Thanks so much, I was digging into this a few weeks ago eagerly and didn't find anything. Glad it's here now!

</comment></comment></comment><comment><USER27> Anyone know a tutorial course for someone only knowing high level languages. And not c or Ruby. More JavaScript, PHP, nodejs, Python

<comment><USER28> Rust for rubyists?

<comment><USER14> It basically doesn't exist anymore; I stopped maintaining it pre-Rust 1.0.

</comment></comment></comment><comment><USER29> Coincidence that many of the Rust promoters have red hair?

</comment><comment><USER30> I'd like to see an analysis: "The amount of real world jobs available for Rust, in comparison to Ada."

The numbers may be self explanatory.

<comment><USER31> What would they explain though?

<comment><USER4> They would explain Rust's relative youth and corresponding growth opportunity. ;)

<comment><USER30> Ada was designed for system programming and, at a time, was also a young language with a huge opportunity for growth ;)

<comment><USER32> To compare Ada's history to Rust's is silly. Even if the languages have a common goal of safety, the projects themselves are fundamentally different in many many ways. One of which is the fact that Ada was designed by the DoD for the DoD, and required a verified compiler, etc etc etc.

They're totally different projects, even if the languages have a small number of shared goals.

</comment></comment></comment></comment></comment><comment><USER33> IMO C++ is unstoppable now, c++ 11, 14 and 17 additions with GSL and all things in the pipeline ...

<comment><USER7> Rust doesn't need to stop C++ to be successful. The market for programmers is already large enough to successfully support dozens of programming languages, and that market will only continue to grow. PHP didn't "stop" Perl, Python didn't "stop" PHP, Ruby didn't "stop" Python, and yet all of these languages continue to be enormously successful. Why should we expect a monoculture on the systems side?

<comment><USER30> What's the place for Rust in the market?

The distributed systems have already moved to Go (when it's not Java/C# :D).

The system programming is done in either C or C++. (Depending on history and availability).

The oldest stuff and/or most constrained is stuck with C. They're struggling to have anything moved over to C++. Rust is entirely out of question.

<comment><USER34> Rust overlaps with C/C++ and even with Go. Go was initially trying to be a replacement for C/C++, but hasn't succeeded, because it is too high level. Rust on the other hand looks very promising in that area, which requires low level access but also desires safety.

<comment><USER35> I wouldn't say Go hasn't succeeded. Maybe not as a general replacement for C/C++. But still lots of new applications that would most likely have been written in C/C++ a few years ago are now popping up in Go (unix daemons, commandline tools, ...).

<comment><USER30> Go has succeeded in its niche (distributed systems). There are real jobs opportunities in Go, in the major tech hubs.

Funny thing is. Everything that is done in Go could be done in Java. Go is succeeding because lots of dev despise Java (related to the entreprisey & the usual culture of java companies).

<comment><USER36> As well as the fact that Go runs markedly faster and lighter (memory) than Java, and without needing to worry about JVM versions. We've been slowly migrating services and the statically compiled binaries are truly amazing for ensuring it will run. Not once have I encountered an 'it runs on my machine' situation.

</comment></comment></comment></comment></comment></comment></comment><comment><USER37> still compiles too slowly, a language in 2016 just cannot take multiple seconds for me to use it add 5 crates and watch ur compile/run cycle climb to a cool 10+ second average.

<comment><USER14> We had significant compile-time improvements in the release yesterday, with more to come in the future. Also, you might want to give incremental recompilation a try, it's nightly-only for now, but being actively worked on.

> add 5 crates and watch ur compile/run cycle climb to a cool 10+ second > average.

It should not recompile those crates each time, if it does, that's a bug. Please report them!

<comment><USER38> > It should not recompile those crates each time, if it does, that's a bug. > Please report them!

Depends on the inter-crate dependencies, alas. Touching one crate can easily cause multiple other crates to rebuild.

<comment><USER14> Only if you need to modify both crates; not if you're just adding them as dependencies, because then you're not modifying them. I was assuming that's what the parent was doing, due to their wording, but that might have been a bad assumption.

</comment></comment></comment></comment><comment><USER39> I agree. We need safer languages. Not that I know much about safety. I still know we need it.

</comment><comment><USER40> I'll never use rust for anything important. Too dangerous, unstable, badly organized, toxic development community, the list goes on.

<comment><USER25> Huh? Did you mix it up with something else? Rust community is one of the best. And what's "dangerous and unstable" there?

<comment><USER41> Check his comment history and draw your own conclusions ;).

<comment><USER42> First time I saw someone with negative karma.

</comment></comment></comment></comment><comment><USER43> when you can run javascript on a pebble watch it blurs the boundaries ... Want to concat an number and string ? JavaScript wont complain.

<comment><USER44> Want to make a _fast_ application on a pebble and with actual type checking? C and Ada won't complain or blur your lines... [http://blog.adacore.com/make- with-ada-formal-proof-on-my-wri...](http://blog.adacore.com/make-with-ada- formal-proof-on-my-wrist)

<comment><USER43> And _real_ programmers write in machine code. Want to get shit done ? Most systems now a day has more then 20kb RAM! Where do you draw the line between systems programming and non system programming ? And why not write some quick and dirty code in say JavaScript and then do what needs optimization in C/assembly ? Assuming you are not restricted to a CPU that cost less then a dollar. And where does Rust come in ?

<comment><USER45> What kind of engineer goes around saying "It could be faster, leaner, and more efficient? No! Build the biggest, flakiest, ugliest thing that gets the job done today!"

</comment></comment></comment></comment><comment><USER46> I lament what Rust could have been had its designers not jumped on the anti- exception bandwagon. Rust's error handling is bad and makes me prefer C++

<comment><USER47> Seriously? Rust's error handling is great, and frankly I'm glad that exceptions have gone out of favour. I tried them but they never really delivered their promise. At their best they do is give you nice stack traces. At their worst they make error handling stupidly verbose, they erase the context you need to properly handle errors, and they make it much more difficult to even know which errors can occur!

Rust's solution is the best I've seen so far. Go's multiple return values are pretty good too but I think Rusts's is better.

<comment><USER46> I very strongly believe exceptions are a lot closer to optimal than Result is. Exceptions remove the need for inline error checking code and make it possible to implement types with value semantics. You can't have reasonable value types that own resources if you need explicit error checking.

The need for explicit error checking makes OOM handling in Rust awkward at best. I've ranted about this side effect before.

Also, in Rust since we can panic, we need to worry about exception anyway! Rust has the worst of both kinds of error handling.

Exceptions are _anti_ verbosity: you're supposed to let them propagate, not catch and rethrow them. They don't erase context: they preserve it, since an exception object is constructed as close as possible to the error site that caused it.

I realize that I have a minority view, but I'm utterly convinced that I'm right and that I'm living in a world gone mad. I've written a ton of code over the years. At least hear me out and try to understand my perspective.

<comment><USER48> I think I know what this trend is, more generally. It has to do with how explicit our code is. We've been through an era where you have some very powerful and compact indirection constructs(event callbacks, polymorphic objects, dynamic types, exceptions) in common parlance and the trend has turned against these lately. Their utility in many instances is mostly to enable technical debt, by worrying about the edge case later, and this has scared a generation of coders who have seen it go astray too often and create code that is hard to usefully refactor. And while exceptions aren't at the center of that trend, they're often implicated as a contributor.

With the new trend, you pay up front and go verbose, put more logic at the call site instead of indirecting it away. Go is at the leading edge of that: lots of LOC for boilerplate is OK in Go-land.

I'm more pragmatic with my error handing methods: I mostly care about whether I can eliminate a class of errors altogether, and secondarily what debugging implications are presented. I don't have a strong opinion on verbosity although I have followed the trend in that respect towards more call site logic.

<comment><USER46> This trend represents the unlearning of very hard earned lessons. Personally, I can't wait until people rediscover that programming can be more fun and productive without boilerplate. A language being explicit, by itself, is not a feature. Being explicit instead of implicit is only worthwhile if you get clarity in exchange, and boilerplate is clarity-reducing because it's so regular and so obscures program logic.

<comment><USER49> In Rust, in the common case, the boiler plate you're talking about here is literally a single sigil. (Previously, it was `try!(...)`.)

This is of course to say nothing about the _advantages_ of having something that signals "this operation can return an error," (at the call site) but you seem to dismiss that out-of-hand.

<comment><USER46> I do dismiss this advantage out of hand: almost everything can fail, because most things allocate memory. It's only because Rust treats memory specially (incorrectly --- memory is just another resource) that it doesn't appear that more functions can fail. It's much more valuable to flip the sense of the annotation and mark the few functions that cannot fail in any way.

Allowing most code to throw just reflects reality and allows you to stop obscuring your program logic with mechanical error handling plumbing.

All you do with "try!" is annoy readers by constantly reminding them that things can go wrong when the default assumption should be that things can go wrong.

<comment><USER50> (I just want to tell you somewhere that you are not alone, and that I appreciate the time you are taking to have this conversation. The arguments you are making are the exact same things I am often found saying, and in my experience it takes hours of time alone in front of a blackboard with someone to really get them to understand concept like "everything can fail" and "memory is no different than disk space". The one thing I haven't seen you argue with yet is that functions which are adamant they can't fail today often find themselves in a position where they can fail tomorrow, such as by adding authentication or storage; this makes "explicit" error handling a limiting contract that either requires you to proactively return error codes from everything even when they only currently return Success, never extend the functionality of existing systems to avoid accumulating an error condition, be prepared to break that contract in the future, or fall back really really hard on panic.)

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER11> Unfortunately, this is just a promotion for a series of videos. Probably talking head videos with PowerPoints.

Most people who do systems programming probably already know about Rust. They may not have used it, but know it exists.

What's "Hacks"?

<comment><USER14>
      > Probably talking head videos with PowerPoints.

Almost everyone in this video is an engineer on Rust, Servo, or Firefox. The exception is Dave Herman, head of Mozilla Research.

These are unscripted responses to questions, no powerpoint involved.

      > They may not have used it, but know it exists.

There are a lot of programmers in the world, and many of them don't read Hacker News. I meet new people who have never heard of Rust every week almost. Or may have heard of it, but can't tell you what it's for, just vaguely remember hearing the name. Or have heard of it, but remember their first impression from a pre-1.0 version and haven't listened since. ("How's its GC?")

<comment><USER7>
      > but remember their first impression from a pre-1.0 version

Can confirm, I routinely observe people in the wild dismissing Rust based on the existence of the `@` and `~` sigils, not realizing that we removed those years ago. :P

<comment><USER4> I dismissed it when I first heard about it (prob just prior to 1.0). I saw "Mozilla" as a primary sponsor and just knee-jerk assumed it was part of the what-if-we-put-JS-here mania.

Thankfully due to repeated popularity on HN I gave it a try and I'm a convert now!

</comment></comment></comment></comment><comment><USER51> Although I am not against improving the safety of languages we use for system programming, the model that Rust advocates are pushing of "preventing mistakes" as a way to make systems secure doesn't convince me.

Mistakes (and security breaches) happen. A system should be written in such a way as mistakes are few, indeed, however it is essential to also efficiently protect our users' assets (data) first, assuming that mistakes are being made.

Ideally as a user I should not care much, nor can I trust that all software is "mistake free." I need the assurance and the tools to guarantee that 1) mistakes are detected 2) my data/privacy/identity is protected.

<comment><USER31> Nothing prevents you from doing both approaches. I mean, while Mozilla is increasing Rust usage, they're also rolling out more extensive sandboxing.

Either of those by themselves are not a good enough solution though. Just trusting on Rust means you are vulnerable to Rust bugs or logic errors. Just trusting on sandboxing means you're hoping that your trusted code (written in C/C++) doesn't have any security bugs.

<comment><USER52> It also means trusting that the "unsafe" usage in the Rust code doesn't have any security bugs.

<comment><USER7> Indeed, though trusting unsafe blocks in Rust is more tractable than trusting an entire C/C++ codebase due to the fact that unsafe blocks present a drastically reduced auditing surface.

<comment><USER52> That's the contention, yes. In practice currently there is an incredible self- selection bias with respect to how tractable that position is if (when?) Rust becomes more widely used outside the circle of the True Faithful.</comment></comment></comment></comment></comment>


Becoming an iOS Developer - <AUTHOR> http://joshsmithonwpf.wordpress.com/2012/02/19/becoming-an-ios-developer/

<comment><USER2> I'm a new Cocoa developer (on OS X) and can attest to the mental pain of accepting Interface Builder if you're used to programming other GUI frameworks. Usually I stick my neck out and comment on HN when I know what I'm talking about or I think I have an interesting question, but here I'll speak as a noob, for what that's worth. (I'm speaking so that people who know what they're talking about can get the perspective of somebody who doesn't, in other words. Please don't make fun of me, but corrections would really help.)

The first mental sticking point for people used to other frameworks is that you really _must_ use Interface Builder as a beginner, even if it seems undesirable or unnecessary. Drag and drop an NSFooView in Interface Builder, and it will be nicely initialized and will act the way you expect. Instantiate an NSFooView in code, and you have a debugging task ahead of you, because the defaults you get when you init an object in code are different from the defaults you get when you create it in Interface Builder. It doesn't look or act the same at all. You end up creating the same object in Interface Builder just so you can inspect its attributes and try to set them to be the same in your code, maybe running your Interface Builder code in the debugger to see how the object behaves. (I assume the same is true of UIFooViews, though their default configuration might be closer to what Interface Builder creates since iOS interface objects are newer, code-wise, than the NextStep-derived objects used in Cocoa on OS X.) It's hard work to do things the wrong way. Someone used to another UI framework can put themselves through a lot of misery trying to figure out how to accomplish things in code without the help of Interface Builder, before they realize Interface Builder is an important part of the framework, not just a minor feature of Xcode that you can easily do without.

Another major cause of disorientation is that the learning curve is shaped very differently because of Interface Builder. In a framework that doesn't have a GUI builder, the beginner documentation holds your hand line by line through the code required to create a window, instantiate UI elements, configure them to behave properly, add them to a container, and specify how they're laid out. Why all that? Because you can't do _anything_ without being able to do that! You can't pop up "Hello World!" with a button below it saying "Hi there" unless you can do all of the above!

With Interface Builder you don't have to do any of that in code. It's just drag, drop, done. No need for a twenty-page tutorial that explains containers and layout managers and the event-handling loop.

But here's the thing. There isn't much more to a typical UI framework than containers, layout managers, elements inside the containers, and events. So the "beginner" tutorial in a typical framework holds your hand across all the territory you need to master, and a decent book will explain the things that the tutorial glossed over. By the time you're able to make the button under "Hello World!" change the text to "Ha ha ha fart face" you've learned all the fundamentals, and you can reason things out for yourself. You're self- sufficient! From that point on, the rest of the learning curve consists of reading documentation for the various framework elements you need to use (individual widgets, menus and menu items, layout managers, framework APIs for background tasks, keyboard shortcuts, persistence of preferences, etc.)

Interface Builder, on the other hand, makes it so easy to get a simple application up and running that programmers are assumed to spend a certain amount of time at the static layout level. If you try to jump ahead and create a more complex app (what I think of as a _realistically_ complex application) then you're already leaving beginner territory. If it's your first app, then you're trying to take the curve too fast. Personally, it's been weeks and I don't feel self-sufficient. I don't grok GUI development in OS X at all; I can't fend for myself at all in Cocoa-land; and it feels like I'm shamefully slow at accomplishing these things. Creating widgets at runtime and laying them out dynamically (because I don't know at compile time how many widgets I'll need and of what type -- I SWEAR IT -- I will kill any man who questions it) is just _killing_ me. All of the documentation seems to assume I know what the hell I'm doing much more than I actually do. The response I get from other beginners when I ask about dynamically creating and laying out views is, "You're braver than me!" which isn't true. I'm not brave! I'm a shivering, sniveling noob! I want this to be beginner stuff! But the Interface Builder learning curve is shaped completely differently. What I'm trying to do follows naturally from noob tutorials in other GUI frameworks, because it's _really hard to be a noob_ in other frameworks. In Interface Builder, it's easy to be a noob. How you get beyond that is still a mystery to me, though.

<comment><USER3> Pre-noob question: what do you mean by "NSFooView"? Googling for it revealed almost nothing, so I take it that you made up the term as a stand-in for some general case. Yes? If so, does NS mean something? Even something that is just a joke or related only to your example? And are you using "Foo" as a reference to the general stand-in phrases "foobar" and "foo = bar"? These questions are sincere, and if you get a chance to set me straight I would seriously appreciate it.

<comment><USER2> NS is the prefix for Cocoa classes on OS X. It dates back to NextStep. NSFooView is a stand-in for various subclasses of NSView that are the basic UI components in Cocoa. If you open an OS X nib (see below) in Xcode and select "Data Views" or "Layout Views" you'll have a choice of NSView subclasses to add to your UI: NSTableView, NSOutlineView, NSSplitView, and so on. Custom UI components usually subclass NSView.

A nib is a file created by Interface Builder that contains serialized objects that can be reconstituted at runtime. An xib is an XML file that compiles to a nib. An xib is somewhat human-readable and (if you keep the target platform exactly the same) can be somewhat usefully diffed as you modify the interface. I'd like to explain more, but my lack of understanding of the precise nature and use of nibs is part of what makes me a noob.

<comment><USER3> Thank you. Understanding what abbreviations stand for has always been an obsession of mine, and knowing the origin of "NS" may actually make learning this stuff much easier for me. I really appreciate your taking the time.

<comment><USER4> A little background to the 'NS' prefix:

<http://en.wikipedia.org/wiki/Cocoa_(API)#Cocoa_history>

</comment></comment></comment></comment></comment><comment><USER5> "ARC is awesome, but I highly suggest that you don't use it until you can manage memory yourself. In other words, don't rely on ARC until you understand what it's doing."

This is not good advice.

ARC is meant to free the programmer from having to think about memory management and allow us to instead think about what we're trying to express in our object graphs and algorithms. Deciding where to call retain and release is an old, tired dance and is where the vast majority of memory leaks and app crashes come from. With ARC, we can just relax and let the compiler insert all those pesky retains and releases where it knows they should go.

There is no reason for newcomers to learn the old style. If a newcomer is reading old-style code, she can skip over the retain/release calls and pretend they're not even there, because they don't affect the algorithm.

<comment><USER6> I very strongly disagree. ARC still reveals the underlying nuts and bolts, necessitating a basic understanding of reference counting systems.

It doesn't solve retain cycles, thus requiring the judicious use of __weak in cases where a retain cycle may emerge. Determining where such a cycle may occur requires understanding reference counting. This significantly impacts your expression of algorithms where the simplest/best implementation may involve cyclic object graphs.

Additionally, ARC does not handle mixing CoreFoundation and Foundation code directly, requiring one to manually express bridging rules based on an understanding of reference counting.

It may be that ARC gradually smooths out its rough edges, and we find ourselves in a situation similar to GC, where developers need only understand the difference between weak and strong references, and the opportunities that exist there for leaks caused by maintaining strong live references.

However, we're still a bit far from that point, and newcomers should remain well-aware of retain/release and the vagaries of reference counting systems.

<comment><USER7> I agree (with you, nupark) For example, thr other day I was debugging a crash in my Cocoa (ARC) app. I've been programming Cocoa since 10.1, although I stepped away for a few years.

Anyway, random crash. My "manage memory manually" training knew it was an object getting released too early: I know I needed to retain it. Think think think... Of yes, my @property declaration was missing a retain declaration. Of _course_ cocoa was releasing that object!

ARC sure helps, and between it and use of the autorelease pool (thanks Brent Simmons!) I hardly have to worry about memory management at all - except when I do, then I need to know what ARC is or is not doing behind the scenes.

</comment></comment></comment><comment><USER8> Here's how I learned iOS dev (still not wildly experienced, but I'm familiar with the beast).

If you're a Rubyist, pick up PeepCode's Objetive-C for Rubyists. You're going to watch that multiple times.

Then, go and get yourself a subscription at teamtreehouse.com and subscribe to Stanford's CS193P (a fantastic course taught by Paul Heggarty) on iTunes U.

Treehouse's iOS 4 badges' topics are somewhat aligned with the topics on CS193P. You should watch the topic on treehouse first, and then watch the corresponding Stanford lecture, which will be much more detailed and a bit heavier. Having watched the treehouse videos, though, you'll have a basic understanding of what Paul is talking about, and the progression will seem very natural.

Set aside 1-3 hours a day for this. The basic things I learned in a day, the more complex ones like CoreData took me a bit longer. If you don't fancy the homework assignments on iTunes U (the first one is rather boring, the other ones are ok and practical), do something else that uses what you learned.

Two weeks of 2-3 hours a day and you'll be on your way.

</comment><comment><USER9> XCode is the obvious choice for beginners but even after a short time of using AppCode I hope I never have to go back: <http://www.jetbrains.com/objc/>

<comment><USER10> Why?

<comment><USER9> \- Sane tab handling.

\- Much better refactoring support.

\- Excellent code generation.

\- Better project file management.

\- Superior navigation tools.

\- Deeper code analysis.

\- Better stability.

</comment></comment></comment><comment><USER11> I came to Objective-C from Java (server side web apps) and it really was quite a shock. However, once I got past the syntax , I found that it was just another OO language. Encapsulation, inheritance, interfaces, they were all there. I will say that while Apple (and the web) provide lots of examples of specific implementation details, they usually don't get past the simple stage of that one API. It's a bit more challenging to put all of them together in a way that is both good form and sensible for your problem.

Re learning: I highly recommend this site: <http://cocoadevcentral.com/d/learn_objectivec/>

Very helpful for getting your mind around basic concepts.

Re: Interface builder. I think the trick is knowing when to use it and when not to. Certainly it is incredibly useful for getting your layout exactly as you want it. (This was a refreshing change from html) But it can be cumbersome if you're trying to share common interface elements via subclassing or without wanting to load a nib file every time. Occasionally I would use it just to get the layout right and then implement the same interface in code.

</comment><comment><USER12> I'd order the steps 5, 6, 2...

1\. Build an app in Interface Builder. 2\. Learn Cocoa Touch. The breadth of the library is more intimidating than the complexities of Objective-C. 3\. Learn C and Objective-C.

Then think about paying apple to develop, releasing products, learning how memory management works, adding core data...

</comment><comment><USER13> I was in a similar situation a few years ago, but I opted for Monotouch [1]. I still had to learn UIKit, Foundation etc, but I didn't have to learn a "new" language. I did have to hack together a Visual Studio package to trick it into loading monotouch project files, but it was like 10 lines of code, and now you don't have to.

I did spend several months developing (and shipping) two Objective-C apps for the few months that Apple banned Adobe AIR (and everything else along with it), and despite having spent 30 years programming, and a good part of that in C and C++, the full awfulness of ObjC was a surprise. But if all you've ever done is C#/WPF, ObjectiveC is going to be quite a shock. In fact there'll be a lot of cognitive dissonance.

[1] <http://xamarin.com/monotouch>

</comment><comment><USER14> The biggest complaint I hear about iOS is the somewhat manual memory management. It's really not that bad, and is nowhere near as tricky as C or C++.

To be fair, iOS does have a garbage collector (NSPool), but you have to free up references for it to reclaim space.

<comment><USER15> NSAutoreleasePool is not a garbage collector, it is merely delayed deallocation. There is no such API as NSPool.

</comment></comment><comment><USER16> > You need to buy an Apple computer, an iDevice (iPhone, iPad, iPod Touch), > and pay $99 per year to be in the iOS Developer program.

Is there any way around the "buy an Apple computer" requirement? Like installing OS X on a PC?

</comment><comment><USER17> Started reading and here we go: "Apple gives Xcode away FOR FREE, [...] you can GET IT."

About Apple's this and that: "WONDERFUL" (new compiler service), "which [...(does miracles)] FOR YOU", "arc is AWESOME"

Long story short - there are a lot of evangelist's marks badly hidden that convey into "acceptance and humility" - requested, and... oh yeah: "pay Apple".</comment>


Some ambient noises to intensify your "gaming" atmosphere - <AUTHOR> http://defonic.ovh/?intens <comment><USER2> "Create beautiful soundscapes with Soundscaper app for _Adroid_ "

Are there noticeable loops in the generated noises? What is so special about it compared to the others?</comment>


SXSWeek 2010 (March 12-20) Panel Picker - <AUTHOR> http://panelpicker.sxsw.com/ Who all is going? Anyone else submit a panel? <comment><AUTHOR> These are mine:

Making The Leap From Consulting To Web Product Company: <http://bit.ly/120FwV>

Get Scientific: What to Track to Grow Your Business: <http://bit.ly/1IcQ2P>

Any other Hacker News people submit panels?

<comment><USER2> I did -

Mind Control: Psychology for the Web: <http://bit.ly/HUyl9>

Difficult Domains: Alternative Databases for the Web: <http://bit.ly/9sK0a>

(Hmm, guess adding "for the Web" wasn't required after all :)

</comment></comment><comment><USER3> Shameless self-promotion:

My YQL talk: <http://panelpicker.sxsw.com/ideas/view/4620>

My e-Gov talk with the fine folks at the City of SF: <http://panelpicker.sxsw.com/ideas/view/4607>

</comment><comment><USER4> Mine's a humorous topic :)

"The Ballmer Peak: How Alcohol Intake Affects Coding"

<http://panelpicker.sxsw.com/ideas/view/3115></comment>


Unemployed man facing jail for not paying child support burns himself alive - <AUTHOR> http://www.sentinelsource.com/news/local/last-statement-sent-to-sentinel-from-self-immolation-victim/article_cd181c8e-983b-11e0-a559-001cc4c03286.html <comment><USER2> He slapped his 4 year old daughter for licking his hand. The fewer of these kinds of "men", the better.</comment>


Show HN: Monitor your friends Facebook online status and activity - <AUTHOR> http://fsm.vertalab.com/

<comment><USER2> This is awesome!

Would be super cool to have this as browser extension and then let users easily copy and paste the reports they gather on each others walls or as status updates.

Destroy facebook! This would make users wary of spending too much time on fb, just to know that a report might be generated and shared with others should be enough to make people stop using facebook as much.

Hm, a good idea would be to also share the "activity of my friends" in a public post, perhaps outside of facebook on google+ or similar.

Then ones friends perhaps would be upset and all that and then I would tell them "suck it, remember all the the times you uploaded my picture or revealed my location to facebook?".

This would be a great way to illustrate to people the danges or spewing personal information on and to facebook about ones friends.

</comment><comment><USER3> This is unbelievably creepy, most of all the 'free trial' part - how is this going to be monetized? Who would pay? Why?

<comment><USER4> Your boss, that added you on Facebook. To check how much you are slacking!

<comment><USER3> That's why you use IRC :)

</comment></comment></comment><comment><USER5> PRISM Jr.! (Or perhaps My First Surveillance?)

Jokes aside, I think there will be some cool infographics to come out of this. Imagine creating a visual friend graph where links are perhaps weighted or colored by the amount of time two people were online at the same time.

</comment><comment><USER6> That seems... disturbing. What are the practical applications of this outside of stalking?

<comment><AUTHOR> This is experimental side project. I am looking for feedback and ideas on how this can be used practically.

I see few applications:

\- you can know who is most active from your network

\- it is possible to calculate power index for each of your friends

\- it is possible to measure social impact made by friends by collecting their activity also

\- it just interesting what open social api can show about users activity. you can see when friends wake up or go to bed.</comment></comment>


It Can Be Done (2003) - <AUTHOR> https://multicians.org/andre.html <comment><USER2> My experience with writing assembler is the same. The run-try-correct sequence encourages trying things until it _seems_ to work.

The best code I wrote was in assembly language. I'd divide the code into blocks with comments. Each comment would document the expected state at that point, what the block would do, and the state after that block.

I wrote pages and pages in my noteblock, and while not everything was bug-free most of it was, and I have never experienced such a nice development process. Nowadays I have to consult five coworkers to ask how to call their undocumented methods and initialize the classes.

I have recently encountered the book 'Toward Zero-defect Programming', where exactly this approach is recommended. Key points are (from the top of my head):

      1. You should know the programming language you're using inside-out.
      2. Don't *try* your code, but *reason* about it, and comment/document this reasoning.
      3. Do group reviews of the code and try to find holes in the reasoning, and problems with the code.

</comment><comment><USER3> >How did André do this, with no tool but a pencil?

And paper, paper is the most important thing here. It is the extended human memory. The short term memory of human beings is extremely sort.

I use paper with color marker pens all the time for programming. Nothing beats paper right now. For doing the same thing on computers you need expensive gear like Ipads pro or surfaces and the useful surface is minimal.

I could use several A4s(normal paper size in Europe), A3s(double that), A2s(4 times that) A1 and A0. I increase the resolution using fineliners. It cost nothing compared with expensive gear.

When you are done you take a high res picture for archival. You can replot it if necessary or wacht it on TVs.

</comment><comment><USER4> Former Multician here. Andre was super-smart, but it is perhaps also relevant that even the most junior developers (as I was then) had quiet private space to work with large desks. All design was done offline. Multics terminals were like type-writers (although video did show up near the end), hence no stream of popups. The environment both allowed for and demanded focus and concentration. This is no longer so.

<comment><AUTHOR> Thanks for commenting!

And yes, more than the pencil-and-paper aspect of this, what I find striking is that it's one person working quietly and alone, with a manager who was prepared to take "Still designing" as an answer. There seems to be very little room for that in a lot of modern workplaces, and I find that rather sad.

</comment></comment><comment><USER5> I also prefer to spend a bit more time thinking before writing code. Things usually work fine but it's in direct contrast to TDD and other agile methodologies. Not saying they're bad, great things have been achieved with them, just that it's not a silver bullet (or the most enjoyable way to program for some people).

</comment><comment><USER6> These types of designs work when the problem is well defined. For something like this, where the easy part is stating how it should behave, and you're 100% sure what perfect behaviour looks like, then by all means diagram and math it out until the system is complete or at least as complete as it can be for you to start performance testing some of the subsegments that can't be determined from first principles.

But most people are not programming up things like this. Most of the time, either the data or customer usage informs next design decisions.

Even so, I spend about 40% of my time these days in "plan mode" because nailing a plan always halves the time it takes to implement some feature and can even tenth it.

</comment><comment><USER7> I wish I was working in an environment where it's possible to know everything well enough so I can design something on paper. Nowadays I plug a lot of systems together and and I first spend a lot of time establishing that they really behave the way as expected. It's really hard to design something well that always gets tripped up by some external system behaving in unexpected ways.

Makes me want to go back to pure C/C++ development where you know the environment in and out.

<comment><USER8> That kind of summarizes what I like about Haskell. The types of every value and function are so informative, and the definitions, even in third-party libraries, are often so short and to-the-point that surprises are very minimal even when working a library that I've never used before. The avoidance of code with side-effects also helps a lot, since it means that for most functions I only care about what goes in and what comes out of the function.

This also carries to frameworks. Web frameworks like Ember and Rails rely very much on side effects, especially Ember. I don't even know how a rendered template is updated when updating a controller property. It just works automagically! Defining an app in frameworks like this is a lot of defining hooks that get called by the framework environment. Trouble then happens when it calls it when you didn't expect it or when it doesn't when you did expect it.

Haskell's Yesod, on the other hand, has been a pleasure to work with. If something's calling my code, the caller is going to be in my repo. I get control all the way to the final executable's main function. Yesod's code is there only as support for me to call.

</comment></comment><comment><USER9> since this isn't immediately obvious: the code in question is linked in the article: [https://multicians.org/vtoc_man.html](https://multicians.org/vtoc_man.html)

</comment><comment><USER10> I used to do this with a method kind of like Cleanroom with inspiration from formal specs and refinement, too. You have to be able to figure out the specifics ahead of time without explorative execution. From there, I used decomposition noting the inputs, outputs, and so on of each function. I used a subset of a programming language with predictable behavior that maps to that. I'd usually know what's going to happen before it happened by just walking through the program in my head. Main problem was third-party libraries, which I had to profile ahead of time. Or just use a friggin' computer since even that wasn't reliable for those in C.

Here's a write-up on Cleanroom:

[http://infohost.nmt.edu/~al/cseet- paper.html](http://infohost.nmt.edu/~al/cseet-paper.html)

Here's a test of it by NASA around 1990 where the E.3 and E.4 sections highlight its benefits and requirements:

[https://ntrs.nasa.gov/archive/nasa/casi.ntrs.nasa.gov/199100...](https://ntrs.nasa.gov/archive/nasa/casi.ntrs.nasa.gov/19910008271.pdf)

</comment><comment><USER11> I am not sure if one should be taking a lesson away from here. Sure, a programmer was able to write software on paper with incredible clarity but in my opinion, that approach is counter-productive than useful in most contexts. Yes, it's unavoidable in certain cases (space rovers, critical health-related equipment), but in most cases, it's not.

Getting something on the screen is useful. It's motivating. It helps to expose the limits of the approach taken. The scope of the project becomes much clearer when have written a chunk of code. I have rarely felt that I should have spent more time dabbling with pen and paper, than firing up my text editor. After all, mistakes can always be corrected.

With the rising complexity of software, and of the whole ecosystem itself, does it make sense to know all the edge cases you're going to stumble upon beforehand? Not to mention that requirements can themselves change. And what about processes like code-reviews? You're not the only person working on the software. I am hard-pressed to say that seeking an extreme level of clarity isn't a great use of time.

<comment><USER12> > Yes, it's unavoidable in certain cases (space rovers, critical health- > related equipment), but in most cases, it's not.

I'd still like it in my filesystem, though.

</comment></comment><comment><USER13> Dijkstra talks about this. Post-war European computing science departments couldn't afford computers and they only got to borrow something like an hour a week from the Americans. This forced them to devise methods for writing reliable code without a computer.

</comment><comment><USER14> This article is older... OK, I see there's a 1994 there, but not in the HN title. I remember it clearly because I did a similar thing (for 1/4 the lines though) just before I read it in 1999. I felt like a million dollars :)

<comment><USER15> Yes it should be (1994) in the HN title and not 2003, as it was published in "IEEE Computer, April 1994."

I'd guess the mentioned "update" on the page is not relevant, that is, that there aren't any important changes compared to the 1994 original of the article.

</comment></comment><comment><USER16> Am I the only one who's fascinated by the UX of this site? It's just so clear and so usable. It resembles to [https://motherfuckingwebsite.com/](https://motherfuckingwebsite.com/) but it's not a gag, it's an actual site.

<comment><AUTHOR> Yes, I like it.

I'm not sure [https://motherfuckingwebsite.com/](https://motherfuckingwebsite.com/) is the analogy I'd make though. It uses a non-trivial amount of CSS (about 5k) -- but not so much that it'll slow most people's downloads, and not a big "framework". It's got some somewhat distinctive branding -- you'll know instantly if you navigate away from the site -- but the elements don't take up too much of the screen. It actually has some responsive elements (try making your browser window narrow).

There's a few lines of JS to make the drop down menus work. But again, nothing huge.

It doesn't seem to be consciously _avoiding_ anything. It looks to me like the work of someone who's started from a clean sheet and is trying to build a site that works for them rather than ticking off a list of best practices. And yes, I like the results.</comment></comment>


Show HN: Autonomous Recruiting Software – We Are on Product Hunt, Need Support - <AUTHOR> https://www.qpage.one/ <comment><AUTHOR> Hey Community! We are on ProductHunt and needs your feedback and comments [https://www.producthunt.com/posts/qpage](https://www.producthunt.com/posts/qpage)

Pouya, Aram and Farhad here and we're the co-founders of QPage ([https://www.qpage.one/](https://www.qpage.one/)) - QPage is an Autonomous Recruiting Software. We help busy founders/recruiters cut time-taking manual work from writing Job Descriptions to find proper Psychometric/skills assessments or coordinate interviews and invest the precious time in choosing data-driven good fits.

We started building QPage because we had to spend tons of hours recruiting new team members either at scale or cherry-picking the one to get on the bus in the right seat. We had to write a job description, find or design proper assessments and integrate coordinate interviews and get together a separate set of information.

"You should spend 50% of your time hiring. This is the most fundamental thing you'll ever do."- Sam Altman Founders are keen on interviewing candidates and getting their skin in the game and that's pretty hard to keep on the track once you have a busy schedule. It goes to spend hefty amounts of dollars to pay recruiting agencies while they might have no sense of what the position is.

We started our company about a year ago, after working at our first venture, a leading Online Food ordering in the Middle east, LG Electronics and Rocket Internet SE ventures in Dubai, where we were building Amazon and Uber's clone there (I know, but people all around the world need such services too). We had to spend a vast amount of energy and cash on hiring talents at scale because the year-waiting campaign was coming.

The idea of building autonomous software by having the freedom to govern itself or control its own affair while steel is in control of recruiters evolved after working for 4 months on developing the infrastructure and the team after talking with few founders, recruiters and founders around us.

The way QPage works can be broken into 3 main steps. Set your workspace up and start creating an open position by choosing among generated job descriptions, inviting the recruit's team, and choosing among psychometric and skills assessments or events such as interviews, calls or AI led interviews and publishing it in different channels. Monitor your pipeline outbound where the analysis comes to provide meaningful insights, start by checking Candidate's scores in AI analysis of CV and the job description. The analysis and results of assessments come among the progress of candidates in the pipeline while the platform communicates and informs candidates upon schedule, progress, and future actions. You'll get calendar invites for calls, video, and F2F interviews while practicing the virtual interviews in the platform and leaving your score and comments. And the third one where you will be offered a candidate pool, unlimited users access, tribes, and auto-generation of your organizational chart. There is an advanced reporting module providing insightful information. We're long time fans of SUS and are eagerly looking forward to feedback from the community (especially criticism). We've made a free version available so you can try it with no strings attached. [https://www.producthunt.com/posts/qpage](https://www.producthunt.com/posts/qpage)

Cheers! ~Pouya, Aram and Farhad</comment>


Node.js v0.2.2 released - <AUTHOR> http://nodejs.org/docs/v0.2.2/changelog.html <comment><USER2> Not exactly a breathtaking changelog, but appreciated all the same:

* REPL improvements (Trent Mick)

* Fix bug in fs.realpath (Isaac Schlueter)

* sys.pump catches errors (Russell Haering)</comment>


The Redis criticism thread - <AUTHOR> http://antirez.com/news/67 <comment><USER2> To summarize quickly for those that didn't read the article, this focuses mostly on the new "clustering" aspect not on the "classic" single Redis server (if you wish).

I think it is important to be honest with the users and make it clear how and what happens behind the scenes, how data could be lost. And Salvatore has done most of this, maybe just make it a bit more explicit, as there still seems to be some confusion around.

All this is in light of 2 things -- 1) With the popularity and amount of talks and churn around distributed systems these days, people sort of expect a point on the map in the CAP triangle. So just saying we kind of do this and we provide some C, a little A and a dash HA was probably ok 5 years ago, now it needs a bit more definition, 2) In light of other database systems misleading users about what it could provides (you know which one I am talking about) and having resulted in lost data, there is a bit of apprehension and a higher bar that needs to be met in order for a db product to be accepted.

One good thing that came out recently is NoSQL database writers/vendors pushing for more rigorous tests. Tests that run for weeks and months. Consistency tests, network partition tests as run by Aphyr. It is a very good idea those things are talked about and defined better.

<comment><USER3> I think Antirez is simply doing a master/slave system with async replication. This is what mysql, solr, elasticsearch, kafka, etc do. This is not an unusual model at all.

In CAP theorem terms, Redis has picked zero (remember CAP theorem is pick _at most_ two).

There's a bunch of people who've made this choice, but why? C incurs a synchronization cost. A means that you have to reconcile different writestreams. If you want consistent semantics in a very fast database, you can't pick either. So you end up somewhere in the middle of the triangle.

The consequence of picking zero is that you'll lose a time window of data roughly proportional to the replication lag when the master fails/partitions. There are many applications for which bounded data loss is a perfectly reasonable paradigm.

<comment><USER4> I assert that this design actually allows for arbitrarily long windows of data loss, but I haven't verified that the implementation matches my understanding of antirez's WAIT/failover algorithm yet. Pretty sure though.

<comment><USER5> If you read the Redis Cluster documentation, the data loss is acknowledged, even explaining what are the most obvious failure modes where this happens. WAIT does not provide strong consistency either, and is actually not even documented in the Cluster doc. However WAIT as it is makes the possibility for data loss less likely.

Once everything in the Redis Cluster design and documentation is about trading consistency for performance, I would expect the system to be analyzed for what it is: is it good at providing weak but practically usable consistency and performances? In short, it does respect the design intent?

Saying again and again that it features not consistency is a sterile exercise.

</comment></comment></comment></comment><comment><USER6> This is the first time I've ever heard any criticism for redis. As far as I know, everyone loves it, it's a great tool for many jobs and it's amazingly written and solid to boot. I think many of the critics are trying to apply it in ways it wasn't meant to be used.

As far as I know, its main purpose is non-critical data that needs to be accessed as quickly as possible in various different ways, and that's where redis shines.

<comment><USER7> I don't pay super close attention to this stuff, but it's very obvious to me that not everyone likes Redis; in particular, the kinds of people who have problems with Mongodb tend also to have the same problems with Redis; long- term operational reliability is a big question mark with it.

For my part: on only a few occasions (mostly fuzzer farm stuff) have I ever used Redis and been happy with the decision. I usually regret using it. I _always_ regret using it as an alternative to SQL.

<comment><USER6> I don't know, I don't think it should be compared (or considered as an alternative to) MongoDB, and certainly never SQL. I use it to store cached keys, session data and similar other data that I can always regenerate. I've also had great success using it as a message queue on multiple projects.

What was your use case, and what was your experience with it?

<comment><USER8> Agreed. If Redis is an acceptable alternative to MongoDB you're using one of the two very incorrectly.

<comment><USER9> Use case: I want to store some json values against some string keys. Which would be very incorrect to use for this?

<comment><USER10> How often are you updating the json values? 10/s? 100/s? 1M/s?

How many string keys? Millions? Billions? What happens if you lose an update?

Redis great for lots of rapid reads and moderate write speed for data that fits on a single server or can be manually sharded well (if it's straight k=>v, as you describe, that basically means your json fits in RAM; if you're using larger objects like sets/zsets/etc, it becomes a slightly different discussion), as long as your application can lose a few seconds without killing you (BGSAVE isn't instantaneous, of course).

</comment></comment></comment></comment></comment></comment><comment><USER11> Just to be clear, the criticism is of Redis Cluster, which has been redesigned because the first design was so lax it was effectively unusable. The real issue, is that as of right now I have no idea what the exact semantics and failure conditions of Redis cluster are. I'm not clear that anyone really knows. Salvatore _thinks_ he knows, but we can't be sure that he does.

With all this talk of practicality, what really makes distributed systems practical is when someone can do a formal analysis of them and conclude what possible states can occur in the system. This is not work that database users should do, it is work that database implementors should do. The failure to use a known consensus system is a failure to deliver a database I can understand.

I find this all a bit disappointing since I've been a huge fan of Redis since the early days. It's an amazing tool that I still have in production, but I get the feeling that it's utility will never expand to suit some of my larger needs. Bummer.

<comment><USER12> He is using known algorithms. He describes them here: [https://news.ycombinator.com/item?id=6780342](https://news.ycombinator.com/item?id=6780342).

<comment><USER11> see Aphyr's comments here: [https://groups.google.com/d/msg/redis- db/Oazt2k7Lzz4/q9YDD7D...](https://groups.google.com/d/msg/redis- db/Oazt2k7Lzz4/q9YDD7Da9ZkJ)

<comment><USER12> Thanks, I hadn't seen this

</comment></comment></comment></comment><comment><USER13> > Redis is probably the only top-used database system developed mostly by a > single individual currently

isn't SQLite pretty much just Richard Hipp?

<comment><USER14> Dan Kennedy does a lot of work, certainly appearing to be a similar order of magnitude to DRH. Joe Mistachkin appears to do Windows almost exclusively and I can't tell if he is part time or full time.

[https://www.sqlite.org/crew.html](https://www.sqlite.org/crew.html)

<comment><USER13> I had not realised that. Thanks.

</comment></comment></comment><comment><AUTHOR> Salvatore is admirably proactive at garnering criticism for his project. He's also incredibly gracious when accepting it.

</comment><comment><USER15> There has been a lot of constructive discussion in the Google Groups thread, and a lot of negativity on the same topic on Twitter. Ignoring for the moment the difference in discussion platforms, I am uncertain why the sudden uptick in Redis negativity.

Is it from users trying (and failing) to replace RDBMS or distributed platforms feature-for-feature with a single threaded, memory limited store like Redis? Or could it be FUD from people interested in seeing their new platform-du-jour get more attention?

<comment><USER16> The "clustering" feature is just now becoming stable. Distributed systems are complex (in no small part because they're generally poorly explained) so some mistakes were guaranteed. Hence the uptick in critics makes perfect sense even sans self-promotion conspiracies.

</comment></comment><comment><USER17> I think many times people criticize new-ish web technologies because they don't want to spend time learning it (which can be okay). They hope to sway others away so that a critical mass of users never compels them to adopt the, now necessary, tech (not that redis is 'necessary').

</comment><comment><USER18> Quick things

1) I expected that thread to look like a Cultural Revolution struggle session". Thankfully it wasn't.

2) As I am sure many others have already said it, durability has very little to do with CAP. CAP is about the A and I in in ACID, D is an orthogonal concern.

3) Durability doesn't necessarily mean losing high performance. Most databases let the user choose how much data they're willing to lose and for what latency decreases -- the standard approach (used even in main-memory databases like RAMCloud[1] and recent versions of VoltDB[2]) is to keep a separate write- ahead log (WAL) and let the end-user choose how frequently to fsync() it to disk as well as how frequently to flush a snapshot of main memory data structures to disk.

There are many papers (e.g., [http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.174....](http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.174.6205)) that talk about various challenges of building WALs, but fundamentally users who want strongest possible single-machine durability can choose to fsync() on every write (and usually use battery backed raid controllers or separate log devices like SSDs with supercapacitors or even NVRAM if the writes are going to be larger than what fits into the RAID controller's write-back cache). Others can choose to live with possibility of losing some writes, but use replication[3] to protect against power supply failure and crashes -- idea being that machines in a datacenter are connected to a UPS, replicas don't all live on the same rack (to protect against -- usually rack local -- UPS failure), and there's cross-data center replication (usually asynchronous with possibility of some conflicts -- notable exception being Google's Spanner/F1) to protect (amongst many other things...) against someone leaning against the big red-button labeled "Emergency Power Off" (which is exactly what you think it is).

Flushes of main data do also hurt bandwidth with spinning disks and old or cheap SSDs, but there's a solution: use a a good, but commodity MLC SSD with synchronous toggle NAND flash with a good controller/firmware (Sandforce SF2000 or later series, Intel/Samsung/Indilinx's recent controllers) -- these work on the same principle as DDR memory (latch onto both edges of a signal) to provide sufficient bandwidth to handle both random reads (traffic you're serving) and sequential writes (the flush).

4) I known several tech companies and/or engineering departments therein who absolutely love and swear by redis. There are very good reasons for it: the code is extremely clean and simple[4] and it handles a use case that neither conventional databases nor pure kv-stores or caches handle well.

That use case is roughly described data structures on an outsourced heap for maintaining a materialized view (such as a user's newsfeed, adjacency lists of graphs stored efficiently using compressed bitmaps, counts, etc...) on top of a database. So my advise to antirez is to focus the effort around making this use case simpler rather than build redis out into a database: build primitives to let developers piggy back durability and replication to a database or a message queue. In fact, I've known of multiple startups that have (in an ad- hoc way) implement pretty much exactly that.

This is still a tough problem, but one which (I think) would yield a lot more value to redis users. Just thinking out loud, one approach could be a way to associate each write to redis with an external transaction id (HBase LSN, MySQL gtid, or perhaps an offset in a message queue like Kafka). When redis flushes its data structures to disk, it stores the last flushed transaction id to persistent storage.

I would also implement fencing within redis: when in a "fenced" mode redis won't accept any requests on a normal port, but can accept writes through an bulk batch update interface that users can program against. This could be more fine grained by having both a read-fence and a write fence, etc...

This makes it easier for users to tackle replication and durability themselves:

For recovery/durability, users can configure redis such that after a crash, it is automatically fence and "calls-back" with that last flushed id into users' own code -- by either invoking a plugin, doing an REST or RPC call to a specified endpoint, or simply using fork() and executing a user configured script which would use the bulk API.

For replication, users could use a high-performance durable message queue (something I'd imagine some users already do) -- a (write-fenced) standby redis node can then become a "leader" (unfence itself) once its caught up to the latest "transaction id" (last consumed offset in the message queue, as maintained by the message queue itself -- in case of Kafka this is stored in ZooKeeper). More advanced users can tie this with database replication by either tailing the database's WAL (with a way to transform WAL edits into requests to redis) or using a plugin storage engine for the database.

Fundamentally, where I see redis used successfully are uses cases where (prior to redis) users would use custom C/C++ code. This cycles back to the "outsourced on heap data structures" idea -- redis lets you use a high level languages to do fast data manipulation without worrying about performance of the code (especially if using a language like Ruby or Python) or garbage collection on large heaps (a problem with even the most advanced concurrent GCs like Java's).

There have been previous attempts to build these outsourced heaps as end-to- end distributed system that handle persistence, replication, and scale-out and transactions. These are generally called "in-memory data grids" \-- some simply provide custom implementations of common data structures, others act almost completely transparent and require no modifications to the code (e.g., some by using jvmti). Terracotta is a well known one with a fairly good reputation (friends who contract for financial institutions and live in hell^H^H^H^H world of app servers and WAR files swear by it), but JINI and JavaSpaces were some of the first (too came too early, way before the market was ready) and are rightly still covered by most distributed systems textbooks. However their successful use usually requires Infiniband or 10GbE (or Myrinet back in dotcom days) -- reliable low-latency message delivery is needed as (with no API to speak off) there's no easy way for users to recover from network failures or handle non-atomic operations.

To sum it up, I'd suggest to examine and focus on use-case where redis is already _loved_ by its users, don't try to build a magical end to system as it won't conserve the former, and make it easy (and to an extent redis already does this) to let users build custom distributed systems with redis as a well- behaved component (again, they're already doing this).

[1] [https://ramcloud.stanford.edu/wiki/display/ramcloud/Recovery](https://ramcloud.stanford.edu/wiki/display/ramcloud/Recovery)

[2] [http://voltdb.com/intro-to-voltdb-command- logging/](http://voltdb.com/intro-to-voltdb-command-logging/)

[3] Whether it's synchronous or not is about the atomicity guarantees and not durability -- the failure mode of acknowledging a write and then 'forgetting' can happen in these systems even if they fsync every write.

[4] It reminds me of NetBSD source code: I can open up a method and it's very obvious what it does and how.

<comment><USER5> Hello strlen, thanks for the interesting reply.

While CAP and durability are orthogonal they are very related in actual systems, I don't think it is ok for a system like Redis to assume that users have multi DC replication and/or other infrastructure preventing mass reboots of small clusters composed of a few nodes. Also note that the more nodes in a distributed system are "decoupled" from the point of view of failures (different physical networks / equipment, different datacenter), the more you are likely adding latency.

But the point in the discussion was _never_ that, since synchronous replication by default is already, exactly as you express in your message, not the Redis business, so fsync or not, Redis Cluster is not going to feature "C". WAIT and its semantics ended taking all the attention, because you know, if your work is to show "C" is violated, you tend to focus there, regardless of the system analyzed not claiming to be consistent.

As for Redis Cluster, many places where Redis is used in the right way, in the environments you say people are happy with Redis, would benefit from the automatic sharding and the operational simplicity that Redis Cluster can provide to Redis, this is why Redis Cluster is IMHO a good milestone in the roadmap.

</comment></comment><comment><USER19> I had no idea that there was ONLY antirez working on Redis. That is some crazy inspirational stuff.

</comment><comment><USER20> Mm Nn</comment>


The joy of index cards (2009) - <AUTHOR> http://nickpage.co.uk/stuff/the-joy-of-index-cards/ <comment><USER3> Minor exploration of the sentence "Before the computer became ubiquitous, index cards were the tools of all academics and researchers."

Some academics used edge-notched punched cards, which is a sort of index card with manual mechanical selection ability. See [https://en.wikipedia.org/wiki/Edge- notched_card](https://en.wikipedia.org/wiki/Edge-notched_card) and [http://kk.org/thetechnium/one-dead-media/](http://kk.org/thetechnium/one- dead-media/) .

These were used until the 1980s. The contents for the Whole Earth Catalog in the 1970s was organized with them.

A smaller number of academics and researchers used interior-notched punched cards (eg, the well-known IBM punched card) with sorting/selection machines and not computers. I think these can no longer be called index cards.

<comment><USER4> I vaguely recall having read some article or other about a pre-computer plan someone had for a "database of everything".

I suspect the idea hinged on edge notched cards or something similar.

<comment><USER3> Almost certainly you're thinking of Paul Otlet and Henri La Fontaine, leading to the Mundaneum. [https://en.wikipedia.org/wiki/Mundaneum](https://en.wikipedia.org/wiki/Mundaneum)

> It aimed to gather together all the world's knowledge and classify it > according to a system they developed called the Universal Decimal > Classification.

Quoting [https://en.wikipedia.org/wiki/Paul_Otlet](https://en.wikipedia.org/wiki/Paul_Otlet) :

> Otlet was responsible for the widespread adoption in Europe of the standard > American 3x5 inch index card used until recently in most library catalogs > around the world (by now largely displaced by the advent of the online > public access catalog (OPAC)).

Mechanized (but non-computer) versions of such a system include Vannevar Bush's Memex ([https://en.wikipedia.org/wiki/Memex](https://en.wikipedia.org/wiki/Memex) ) and more obscurely Calvin Mooers' DOKEN ([http://www.historyofinformation.com/expanded.php?id=4243](http://www.historyofinformation.com/expanded.php?id=4243) ) and ... there's a French information scientist from the same era but I've forgotten his name.

The materials I read said that after 10K-100K cards (forgot the actual tradeoff point), it's better to switch to interior cards because it becomes more worthwhile to sort by machine. The machines are expensive to rent, and not worthwhile until many searches are needed.

</comment></comment></comment><comment><USER5> This reminds me of the Hipster PDA, a small collection of index cards for daily use held together with a binder clip.

Perhaps more relevant now than ever with our smartphones and their infinite capacity for distraction.

[http://www.43folders.com/2004/09/03/introducing-the- hipster-...](http://www.43folders.com/2004/09/03/introducing-the-hipster-pda)

[https://en.m.wikipedia.org/wiki/Hipster_PDA](https://en.m.wikipedia.org/wiki/Hipster_PDA)

<comment><USER6> I've taken to carrying around small notebooks in my pocket recently.

I found that I never looked at notes written on my phone, but I do with paper.

It also has the advantage that I can tear pages out to give to people. No need to try and text a shopping list to someone when you can just give them one.

</comment></comment><comment><USER7> Since no one has mentioned it yet, this is a wonderful book on the evolution of index cards:

Paper Machines: About Cards & Catalogs, 1548 – 1929 (History and Foundations of Information Science) ([https://mitpress.mit.edu/books/paper- machines](https://mitpress.mit.edu/books/paper-machines))

<comment><USER8> Thank you for sharing this! I have been interested for a while in the idea that index cards, as analogue forms of cataloguing and computation, have been used in a number of ways that are still relevant to our new designs. It's great to have this thread full of resources, and I don't think that I have seen this one before.

</comment></comment><comment><USER9> I love index cards - despite running a computational lab, without index cards the whole thing would come tumbling down. And they're so versatile - <USER2> project management cards get taken off one board and then go into a pile that you can pull for annual reports, etc.

And yeah, there's something about being able to touch them, move them, etc.

<comment><USER10> Do you mind describing how you use index cards for project management? As a younger person, I don't have have the habit of using index cards at all.

Whenever I use it, I can't help but feel bothered by the finality of the act of writing in ink. Since we only use index cards when the task becomes too complex to hold in our brain, it also means that we often need to re-organize our thoughts about the task several times. The act of writing (as opposed to typing in a computer) doesn't seem conducive to that kind or re-oganization.

<comment><USER9> Each project I'm working on - or parts of a project - get an index card. They're color coded for what they are, and then go up on the massive pinboard in my office. As things move into different categories, they get moved around physically.

This does a couple things:

1) There's something satisfying about physically moving a thing 2) I can get a quick visual representation of the balance of my work. Am I conspicuously low on a certain type of project in the queue? If so, why? 3) When they're done, they go in a pile of either successful or unsuccessful (I'm an academic, so for example a rejected grant is unsuccessful). When I need to work on my annual report? I just grab 2018's successful pile and it's an accounting of what I've done.

Personally, I like the finality of committing something to ink. If it needs to be changed, it's not as if index cards are expensive, but I like there being a sense of solidity to "What we're doing".

</comment></comment></comment><comment><USER11> if you're not using an actual 3x5" filing system, or constructing stacks of cards - cutting heavy cardstock into longer thinner strips makes it smaller to carry and gives you four logical pages. as I get older and more absent minded its nice to have a reliable cache.

reasons I like paper better even though I have to carry my phone at all times

always faster

when the page i'm carrying is full I have to review it and chuck it. phone note apps for me tend to be write only

diagrams and sketches carry alot more meaning for me

no screwing around with menus for shading/font/line weight

just looking at the shape of the marks on the page brings an immediate recall, whereas with text I kind of have to read it and figure it out again

when I pull out my little card to write down to remember to buy socket head screws, I don't get derailed by my unread messages

the classic style has you keep your 3x5 notes as a permanent lab record, I can transcribe it into a notebook for that, this is just 'my day in scribbles'

<comment><USER12> > phone note apps for me tend to be write only

In that vein, I've recently realized that the CRUD model also defines how I interact with task management apps - I Create lots of stuff, Read maybe 10% of that, Update maybe 50% of what I read, and then maybe Delete (or mark done/hide) 10% of what I update - in short tons of stuff goes in and almost nothing ever comes out.

I realized that with data on a computer, for the most part the default state is that it lives forever, and you have to take positive action to remove data. With paper or physical media, the default state is for things to be lost/culled over time and positive action must be taken to retain things with some sort of organization. "Lost" can mean that what you wrote down 3 months ago is now 30 pages back in your daily notebook, etc. The "presence" of the data fades a bit over time.

So, for me, positive action is fatiguing. It is more valuable to have an organization system that is self-limiting where I must take positive action to capture more, rather than one where I must take positive action to distill far too much data down to what is important. I'm always looking for a better system, but so far a daily notebook where I keep the important stuff "bubbled up" to the most recent 1-3 pages has been more sustainable than any of the Wunderlist/Notes/Reminders/Omnifocus/Trello/etc. ever were.

<comment><USER11> i think this applies to programming issues as well. the IETF used to strongly emphasize 'soft state' protocols. Not that there was no state, but it was always associated with a timeout and went away on its own. A best effort cache - although alot of these protocols (i.e pim) depend on having some non-zero lifetime to work at all.

think about the additional bookkeeping and correctness issues associated with the destruction/cleanup path. alot of the time we maintain references and search structures so that we can 'properly clean up', when in reality we just want to tear down the whole world.

construction and destruction do have a certain pleasant symmetry, but since the destruction path is often less tested and error prone, and may double the work at hand, isn't it worth considering implicit destruction?

</comment></comment></comment><comment><USER13> I used index cards to write all my papers in college, up to and including my MS thesis. One fact/idea/thought per card, including citations/quotes/rough diagrams. Once all the information is there, lay them out in order, and the rest pretty much writes itself.

They're a great way to organize information; it can be difficult to track down enough phones to spread them out on the floor and see the whole picture.

</comment><comment><USER14> Love index cards, there are knockoffs but the Levenger Pocket Briefcase is the consummate personal index card repository.

Also just learned recently there are whiteboard index cards used for flash cards and they're awesome!

Cheap, bright white (good for small signs) and radiused corners so they stay nice as long as they don't get bent.

Dangerous track however, because Staedler makes a line of (refillable!) LumaColor fine point correctable pens which are amazing but not cheap. Basically dry erase but needs more friction to remove.

Finally, NUBoard is a "blues clues" style whiteboard notepad, in pocket versions and larger letter sized with tracing/overlay sheets, expensive, cool, still looking for a good use case.

</comment><comment><USER15> I thought I'd see Hawk Sugano's system mentioned here, but haven't so I'll share the link: [http://pileofindexcards.org/](http://pileofindexcards.org/)

What's nice about his index card system is the simple taxonomy for organization, which can be expanded upon for specific projects or just carrying on day-to-day. Of course these can be modified, but I've found the four groups he proposes (Record, Discovery, GTD/to-do, Citation) work well for everyday capturing of ideas big and small.

This, and Marc Andreesen's note to make a short to-do list nightly for the next day are my main uses for index cards. [https://pmarchive.com/guide_to_personal_productivity.html](https://pmarchive.com/guide_to_personal_productivity.html)

</comment><comment><USER16> Heh! My first "PDA" was the Hipster PDA, a stack of index cards and a binder clip: [http://www.43folders.com/2004/09/03/introducing-the- hipster-...](http://www.43folders.com/2004/09/03/introducing-the-hipster-pda)

I'm prioritizing my personal to-do lists with Trello, which is like digital index cards.

</comment><comment><USER17> Have any HNers found an effective digital version of index cards? The author mentions a" years of trying all kinds of digital equivalents a much-loved Mac outliner programme called 3×5" but then returns to return to physical cards. Probably the usefulness of actual cards comes from their materiality, but maybe there's some effective replacement that lets you combine/create cards with added digital ease - I can type a lot faster than write by hand.

<comment><USER18> If using index cards for memorizing, I think the Anki system can't be beat. Simple HTML/css formatting, tons of configuration options, plug in a .CSV with as many columns as you like and out the other end can come decks with cards configured in all sorts of wild ways.

So for example I have a Japanese learning deck with columns "word - Japanese", "example sentence - kanji", "example sentence - hurigana helper text (phonetic speller for characters I don't know)", "English definition for word", "English definition for sentence", "part of speech" , "commonality of word.".

So I can make decks sorted by commonality of words with English on front, or Japanese on front, to practice vocabulary. Or I can have one with English sentences on front to practice sentence building.

You can even attach media files, like audio.

And best of all, last I checked this is all free. Still not sure how the creator funds hosting public decks.

<comment><USER19> Thank you for this. I hadn't come across Anki and it looks like a great tool.

<comment><USER20> AnkiDroid on F-Droid store is an excellent open source mobile version

</comment></comment></comment></comment><comment><USER21> I just started carrying a notebook in my back pocket, and a pen in my front pocket.

Technology is great, but there are some things that I have a better experience doing on paper.

<comment><USER22> This was the go to method of keeping information when I was in the military (05-09), which was _strongly_ encouraged starting in boot camp. If one was found without a pen or two and a notebook, there was some words said. I've kept the habit going into my civilian life though I don't take notes as often.

</comment></comment><comment><USER23> Arno Schmidt's _Zettels Traum_ ( _Bottom 's Dream_ in English) is a mammoth book originally written entirely with a collection of 130,000 index cards. [0][1]

The book's title is German wordplay referencing the medium which Schmidt wrote the book on ("Zettel") and Bottom from Shakespeare's _A Midsummer Night 's Dream_ ("Zettel" being the translation of Bottom's name into German).

[0]: [https://en.wikipedia.org/wiki/Bottom%27s_Dream](https://en.wikipedia.org/wiki/Bottom%27s_Dream)

[1]: [https://www.zinzin.com/observations/2013/who-was-arno- schmid...](https://www.zinzin.com/observations/2013/who-was-arno-schmidt-and- what-is-zettels-traum-some-evidentiary-fragments/)

</comment><comment><USER24> At the moment of writing this I can't find anyone mentioning CRC-cards(1) - have these been completely forgotten?

(1)[https://en.wikipedia.org/wiki/Class-responsibility- collabora...](https://en.wikipedia.org/wiki/Class-responsibility- collaboration_card)

<comment><USER25> Many years ago there was a book, Java Modeling in Color with UML, which event gave you a reason to purchase the nice red/blue/green/yellow packs of index cards. I found it a very nice way of decomposing a problem (into entities, roles/interfaces, temporal things and description/lookup tables), but I've not seen anything like it survive.

</comment></comment><comment><USER26> How many times is this going to get subbed to HN? Maybe now that it earned some karma, the same user (@Tomte) won't resub it for another year at least. Right?

 _The joy of index cards (2009) 136 points Tomte 20 hours ago 59 comments

The joy of index cards (2009) 3 points Tomte 5 months ago 0 comments

The joy of index cards (2009) 1 points Tomte 9 months ago 0 comments

The joy of index cards (2009) 1 points Tomte a year ago 0 comments

The joy of index cards (2009) 3 points Tomte a year ago 0 comments_

<comment><USER27> Yes, there were plenty of reposts, and reposts are typically bad. But that doesn't mean it isn't a topic HN wants to discuss as it did finally get traction on this latest go at it.

Timing (and luck) can be everything on these sites and some don't actively attempt to game the system and post at the most optimal times to get views/votes. If it stops here, I don't see a problem with the reposts... Just not sure where you would draw the line between this and spamming the boards.

<comment><USER26> I don't have a problem with the content (I found it interesting myself). What I have a problem with is users who keep submitting the same stories over and over again. I'm pretty sure that's against the HN TOS.

</comment></comment></comment><comment><USER28> Even the largest computer screens fall short of the flexibility of a large table of index card piles. You can lay out piles in a 2D array or 2D separated groups. Then resuffle the piles. Each pile can be ordered by importance, time, or expository order.

</comment><comment><USER29> During an intense period at university, index cards kept me sane. I wrote my next day schedule on one side every night and kept little to-dos to add on the other throughout the day. I should probably go back to them at some point.

<comment><USER30> Since then, have you found a better way?

<comment><USER31> I still start each day at work recopying the previous day's list, reordering it, and adding new items. I've tried to move to a computer TODO for a couple of decades, but no success. Most of my peers do _nothing_ , so I do lists for them, too, occasionally. They really like getting a list, and they tend to be more productuve for it. They doodle on them, cross out items, take notes, etc.

<comment><USER32> Your system of recopying the previous day's list, reordering, adding new items, and I assume removing any done or stale items, is very close to the Bullet Journal [1] system that I have started to use since last year.

It's interesting to see that you came up with a similar system.

It really is an excellent system that keeps me organized and sane during the hectic periods of life and work.

[1] [http://bulletjournal.com/get-started/](http://bulletjournal.com/get- started/)

</comment></comment></comment></comment><comment><USER33> I have always wanted to make a set of reusable, "erasable" index cards, perhaps constructed out of "whiteboard" material.

<comment><USER34> Thomas Jefferson "carried a small notebook made up of ivory leaves on which to record his observations. He would write down his measurements in pencil and in the evening transfer the data to seven large notebooks, each devoted to a different subject. He would then erase the ivory plates, readying them for another day of scientific inquiry." Source: [https://www.artofmanliness.com/2010/09/13/the-pocket- noteboo...](https://www.artofmanliness.com/2010/09/13/the-pocket-notebooks- of-20-famous-men/)</comment></comment>


Kevin Mitnick's business card... lockpicker now? - <AUTHOR> http://www.flickr.com/photos/ranh/106709219/

<comment><USER2> I have one of these! I met Kevin at The Last HOPE a couple years back, and he was handing these out. It's pretty much the most fantastic business card I've ever seen.</comment>