Futures for C++11 at Facebook - <AUTHOR> https://code.facebook.com/posts/1661982097368498 <comment><USER2> Rats, the terminology is backwards from the E/JavaScript promise/future distinction: [https://en.wikipedia.org/wiki/Futures_and_promises#Read- only...](https://en.wikipedia.org/wiki/Futures_and_promises#Read-only_views)

There's been a push to standardize "Promise" to be the read-only side and "Future" to mean the resolver/promise pair, but Folly Futures use the opposite convention.

Agreeing on terminology is hard. :)

Edit: I think it's fine that Folly adopted the C++11 convention. I'm just whining in the open that that promise vs. future may never be agreed upon.

<comment><USER3> I fucking hate the terms future and promise so god damn much. The names are beyond stupid. They're just confusing as hell. No one can read the names and make an educated guess as to which is which it what they do.

The following is my favorite interview response of all time.

Q: what's a quaternion? A: I don't know... But I bet it has four parts.

Genius! An honest answer followed by a wise educated guess. Now, what's a future and what's a promise? How can you remember the difference? Good luck!

Those terms should be retired forever.

<comment><USER4> A promise what you get when you can't get a result immediately: a promise to deliver a result later. "Future" is nonsense terminology.

<comment><USER5> You could as easily say that a promise is a promise you've made to produce a piece of data in the future. That's the problem with the term -- it's equally easy to interpret it as the consumption or production side of the equation. As an exercise in skeuomorphism, it's poor, since just like in real life, you can equally give and receive a promise.

</comment></comment></comment></comment><comment><USER6> There is another fine post about this project at [http://instagram- engineering.tumblr.com/post/121930298932/c-...](http://instagram- engineering.tumblr.com/post/121930298932/c-futures-at-instagram).

It was posted as [https://news.ycombinator.com/item?id=9746522](https://news.ycombinator.com/item?id=9746522), but we merged that thread with this one so as not to have two on the front page.

</comment><comment><USER7> On a related note, MS has PPL on Windows: [https://msdn.microsoft.com/en- us/library/dd492427.aspx](https://msdn.microsoft.com/en- us/library/dd492427.aspx)

Very similar to C#'s TPL.

And VS2015 has experimental support for async/await in C++: [http://blogs.msdn.com/b/vcblog/archive/2014/11/12/resumable-...](http://blogs.msdn.com/b/vcblog/archive/2014/11/12/resumable- functions-in-c.aspx)

<comment><USER8> There's also pplx, which is a cross-plattfor implementation of ppl: [http://microsoft.github.io/cpprestsdk/namespacepplx.html](http://microsoft.github.io/cpprestsdk/namespacepplx.html)

</comment></comment><comment><USER9> How does this project relate to Facebook's other futures/promises library, Bolts?

[https://code.facebook.com/posts/225525624316574/building- and...](https://code.facebook.com/posts/225525624316574/building-and-open- sourcing-bolts-a-mobile-developer-tools-library/)

<comment><USER10> They might look related in terms of various "idioms/building blocks" used but they cater to two completely different programming languages i.e. Objective C/C++.

</comment></comment><comment><USER5> I'm totally on board with futures, IF your application needs to scale to the point that blocking, threaded computation is infeasible. However, I honestly don't think that's the case for most folk. Blocking, direct-call computation is way simpler than futures.

<comment><USER11> Or use fibers (lightweight threads) and enjoy the best of both worlds: simple, blocking code with the scalable performance of async.

<comment><USER5> Fibers are fine as an idea. But all the C++ implementations I'm aware of require the programmer to mark up their code for cooperative scheduling. That's a non-starter for me.

<comment><USER11> So writing their code completely differently is a less-costly alternative?

<comment><USER5> If I compare the three alternatives:

        - Standard blocking code in OS threads.
        - Future-based code.
        - Coroutines with explicit annotation.

The latter is probably only viable for very large organizations in terms of engineering cost. The other two are doable for smaller organizations.

<comment><USER11> Can you explain why? Futures seem to be much more intrusive than the other two.

<comment><USER5> They are intrusive in the sense that the code looks much different. On the other hand, I'd guess they are less error prone. Marking up syscalls would be a constant cognitive load, since you have to remember to do it each time (or else maintain an abstraction layer). But once you've decided to use futures, that's just how you do async.

</comment></comment></comment></comment></comment></comment></comment><comment><USER12> Am I the only one who thinks ".then(...)" code is also unreadable? Composability with ".then(...)" looks like a workaround for C++ limitations.

Why can't we have this instead:

      fooAsync(input) {
        //...
        USING_B_THREAD_POOL
        //...
        USING_A_THREAD_POOL
        //...
        USING_B_THREAD_POOL
        //...
      }

What are the disadvantages?

<comment><USER13> .then() is a hack as much as the entire async paradigm is a hack to make up for the weight of OS-supported threads used in their intended way. We have to step back and ask: what is the _ideal_ mode of development? What does one _want_ to do but can't? The ideal answer is to continue developing in the traditional, stackful, RAII-made-easy way where the operating system can provide a suitable natural API and runtime environment (i.e threads and kernel scheduling), and the programmer can state their intent as clearly and naturally as possible.

The std::future interface is good, but it has no truly suitable implementation. I'm not familiar with FB's Folly but at a glance I don't see it solving the fundamental problems with both std::future and callback-hell; .then() seems to just move callback-hell into one place rather than having it spread out -- it's still hell. std::future on the other hand is tied directly to the OS thread interface. Are you able to .wait() on say, 1,000,000 items at once? You'd either need 1,000,000 threads or you're bound by the slowest waiting entity in the current thread. It's definitely flawed.

The solution is to once again break down the execution context. Like threads did with processes, a new division is necessary in userspace based on stackful context switching (think boost::context crossed with boost::asio using the yield_context feature). Userspace contexts can "go to sleep" and "wake up" while being agnostic to the bounds of the thread-pool, and working fine on even a single thread. This model allows synchronous-looking programming while really acting in an asynchronous way -- which is what the obsoleted OS process/thread system offered.

"Async" and "callbacks" are really just a model of no-model -- it hasn't inverted the stack, it's basically eliminated it -- and I treat it as nothing more than temporary.

<comment><USER14> Fibers which could do async IO coded in a blocking style (co-operatively tasked) would rock so hard that one day it has to work without sucking...

</comment></comment></comment><comment><USER15> I'm a huge fan of Finagle futures, which this project seems to draw a lot of inspiration from. My biggest challenge is actually the fact that Folly as a dependency is so heavyweight memory wise: I have trouble building anything on my laptop with 4 gigabytes of memory. Most of the Folly code is template code - I guess lots of template code leads to large memory compile time footprints?

Anyway - great project. I'd love to use it sometime maybe when I get a bigger dev machine.

<comment><USER16> Yes, templates are expensive at compile time (memory and time both). folly/futures only depends on a few pieces of folly/, you may find that you can use the futures headers just fine. If building libfolly is the showstopper, you might be able to comment out all the non-dependent files.

</comment></comment><comment><USER17> Excellent library and writeup !!

This is very similar to HPX, the general purpose C++ runtime system for parallel and distributed applications by the Stellar Group - [https://github.com/STEllAR-GROUP/hpx](https://github.com/STEllAR-GROUP/hpx).

I recently saw the excellent video presentation by Hartmut Kaiser on this [https://www.youtube.com/watch?v=5xyztU__yys](https://www.youtube.com/watch?v=5xyztU__yys) and a lot of concepts in folly futures are quite similar. However the most striking thing in HPX was that all the building blocks are serializable, and the presenter mentioned that it is so because you could serialize and move a thread to a different machine and run it there.

<comment><USER18> Kaiser also gave a pretty good keynote at Meeting C++, "Plain Threads are the GOTO of todays computing:" [https://www.youtube.com/watch?v=4OCUEgSNIAY](https://www.youtube.com/watch?v=4OCUEgSNIAY)

Same talk maybe?

</comment></comment><comment><USER19> > Threads are heavyweight — switching threads is inefficient, they have > considerable memory overhead, and the OS will bog down if you make too many > of them.

I didn't realize Posix threads were that inefficient?

First, I can't see why the memory overhead would be anything more than having a separate stack and entry in the TCB?

Second, can you not just save the stack pointer, program counter and registers into the TCB, then do the reverse when restoring a thread?

Finally, I wouldn't have thought you'd have too many TLB misses either, thus leaving the only expense being trapping to the kernel to switch between threads?

Can anyone explain?

<comment><USER20> I can't explain completely, but check out [http://blog.tsunanet.net/2010/11/how-long-does-it-take-to- ma...](http://blog.tsunanet.net/2010/11/how-long-does-it-take-to-make- context.html).

Relatively speaking, I don't think context switching is _that_ expensive compared to other areas you can focus on like doing smarter memory management.

I don't know exactly what they mean by threads having heavy memory overhead, but possibly they mean cache interference mentioned in that link? I'd be curious if there is an actual large memory chunk other than stack/scheduling details in play here too.

On modern cores too, there are a decent chunk of registers, including floating point registers. I've looked into timings before for embedded applications and the performance hit here isn't trivial when looking at interrupts and the like; but I'd be surprised if it was that overwhelming on servers.

</comment></comment><comment><USER21> Futures sounds a lot like Promises to me. Or am I wrong?

<comment><USER16> Yes, the two terms are unfortunately both synonymous (comparing different implementations of the pattern in different languages), and usually have specific meanings in the context of any given implementation. Often, as here, Promise is the write handle and Future is the read handle.

</comment></comment><comment><USER22> I've never programmed seriously with futures, and I'm a little apprehensive.

For example, let's say I type the string "123". If there's a future / promise / async whatever anywhere, we risk processing the characters out of order. We may not catch that in testing, because it's usually fast enough that it comes out in the right order.

> It is more efficient to make service A asynchronous, meaning that while B is > busy computing its answer, A has moved on to service other requests. When > the answer from B becomes available, A will use it to finish the request.

What if the first request is "set sharing permissions to private" and the second request is "upload this compromising photo?" Obviously it would be bad to process these out of order. How is this handled?

<comment><USER23> Are you asking "how do you do concurrent programming?" These problems aren't specific to promises.

<comment><USER22> I don't think so. Here's a concrete example of what I mean.

Say we are making a Todo list app. We have a list of Pending and a list of Completed todos, and when the user completes one, we move it from Pending to Completed. But how do we ensure other threads can't see the transient in- between state? Traditional concurrent programming might solve this with a lock:

        lock()
        Pending.remove(todo)
        Completed.add(todo)
        unlock()

This problem is very well known, and any discussion of threads will spend a lot of time on locks, queues, serialization techniques, etc. for avoiding races. Now, with futures:

        Pending.remove(todo).then({Completed.add(todo)})

We've got the analogous race condition, even if we're single threaded. But articles on Futures never seem to discuss techniques for mitigating this. Why not? Is there a Futures equivalent for a lock?

<comment><USER24> Futures are used when you want to do something asynchronously -- that is, you want the action to happen in the background and be notified _after_ it completes. If you want actions to take place atomically, then why make them asynchronous? Nobody ever said that all code blocks of the form "A; B" should be replaced with "A.then(B)".

If you're writing in C++ with shared data structures accessible from multiple threads, you need locks anyway; futures don't change that. If you're writing in Javascript, your code is inherently single-threaded and no locks are necessary.

<comment><USER22> > If you want actions to take place atomically, then why make them > asynchronous?

This is usually up to the API you are using. You may not have a choice.

> your code is inherently single-threaded and no locks are necessary

Locks are necessary in the single threaded case. See my example:

        Pending.remove(todo).then({Completed.add(todo)})

Nothing prevents another operation from executing between the remove() and add() calls, and seeing the transient state. You need the analog of a lock to prevent that. What is that with Futures?

<comment><USER24> Sorry, maybe I was unclear. Let me try again from a different angle: It's up to an API designer to come up with a sane API, including sane usage of futures/promises only where it makes sense.

In the browser world, futures or promises are an abstraction over some operation that doesn't block the UI thread, and therefore can allow some other work to happen in the meantime. In your example, if Pending and Completed provide an interface to some remote API, then a lock provides no benefit because making separate RPCs can't possibly be atomic anyway. If they're operating on local data or the DOM, then making them return futures is pointless because the work will happen on the same thread, and no other code could possibly observe the intermediate state anyway. (This is a core principle of the browser event loop: Javascript code is never preempted, it can only yield control by running to completion. Apologies if I'm repeating stuff you already know.)

In other languages, futures are more flexible because they can contain CPU- bound work that operates on shared memory. In that case, futures don't magically absolve you of the need to protect that shared memory. But if you have multiple operations on the same shared data, it once again doesn't normally make sense to decouple them with futures in the first place.

<comment><USER22> That makes sense. Thank you for your thoughtful reply.

</comment></comment></comment></comment></comment></comment></comment><comment><USER25> I'd be interested in seeing why instagram didn't implement the suggested user service as a batch process that populated some KV store. Online evaluation is great for guaranteeing up-to-date results, but the tradeoff is that you now have to bring up and maintain a fairly critical production service.

> The SU service fetches candidate accounts from various sources, such as your > friends, accounts that you may be interested in, and popular accounts in > your area. Then, a machine learning model blends them to produce a list of > personalized account suggestions.

> This enabled us to reduce the number of instances of the Suggested Users > service from 720 to 38.

<comment><USER26> We've seen huge gains from making the system as realtime as possible. Consider a new user who hasn't followed anyone yet--each new follow is super helpful in informing the recommendation system.

</comment></comment><comment><USER27> But how does one _elegantly_ stop a chain of futures from executing when one is no longer interested in the final outcome of this chain of futures?

<comment><USER28> Folly Futures support interrupts and cancellations. See [https://github.com/facebook/folly/blob/master/folly/futures/...](https://github.com/facebook/folly/blob/master/folly/futures/README.md#interrupts- and-cancellations)

</comment></comment><comment><USER29> This is quite nice. I still wish C++11 would add some CSP style channels into the core language, with appropriate elegant syntax (maybe they could steal Go's syntax for channels).

I'm sure there is a good performance reason they haven't done this yet. I don't know enough about the design of programming languages to know all the complexities involved. I'm just idly wishing.

</comment><comment><USER10> Can someone explain to me what does it add over [http://www.boost.org/doc/libs/1_58_0/doc/html/thread/synchro...](http://www.boost.org/doc/libs/1_58_0/doc/html/thread/synchronization.html#thread.synchronization.futures) and pros/cons ? Thanks.

<comment><USER16> It is along the same lines as boost's futures implementation. We have a different mechanism for expressing thread management, born out of trial and error and Facebook engineer feedback. At the time we set out to write this boost futures were slow and buggy (1.53), and C++ standard monadic futures proposals were in very early stages (it now appears that there will be monadic futures in C++17). I do not know if boost futures are now more robust and/or more performant in 1.58.

<comment><USER30> Since it seems like you're at FB, do you know if anyone's working on an equivalent of FB's Swift but for C++ instead of Java? If so, I'd love an email to express interest in such a thing. Thanks in advance!

<comment><USER31> Swift uses annotations (reflection) and generates bytecode on the fly. This fits much better with modern Java development practices and tooling than source code generation. Is such a thing feasible C++, especially in an idiomatic way? Or perhaps I am misunderstanding your question.

To my knowledge, our C++ Thrift code is here: [https://github.com/facebook/fbthrift](https://github.com/facebook/fbthrift)

(I work on Presto and occasionally Swift at Facebook, but am not at all familiar with modern C++)

<comment><USER30> Thanks for the reply! You're right, I should have been more clear - the goal would be to autogenerate Thrift IDL at compile-time from annotations in our C++ source, to avoid having to hand write the IDL. So more in the sprit of Swift rather than a direct parallel.

</comment></comment></comment></comment></comment><comment><USER32> Has anyone used the Reactive Extensions for C++? I've used RxJs fairly extensively, but I haven't tried it any other languages. Rx solves a similar problem, but observables are more general than promises.

[https://github.com/Reactive-Extensions/RxCpp](https://github.com/Reactive- Extensions/RxCpp)

</comment><comment><USER33> Futures/promises seem like they're basically just a limited subset of FRP (Rx, RAC) observables/streams - such that they either "next" once and "complete", or "error" without "nexting".

I suppose they also have caching built in, but that is easy to build on top of FRP.

<comment><USER32> Yeah, I think you're right on the money. Matt Podwysocki has a chart explaining how promises fit in to all of this but I can't seem to find it. Here's what he says in the RxJs documentation.

"One question you may ask yourself, is why RxJS? What about Promises? Promises are good for solving asynchronous operations such as querying a service with an XMLHttpRequest, where the expected behavior is one value and then completion. The Reactive Extensions for JavaScript unifies both the world of Promises, callbacks as well as evented data such as DOM Input, Web Workers, Web Sockets. Once we have unified these concepts, this enables rich composition."

</comment></comment><comment><USER34> Total strawman on the code example. They don't really need the mutex and all the complexity, but they add it so they can overstate their point -- make the most complex code you can and compare it to a simple example you code. Blah.

</comment><comment><USER35> Another option that has been around for a number of years is: [http://doc.qt.io/qt-5/qtconcurrent- index.html](http://doc.qt.io/qt-5/qtconcurrent-index.html)

</comment><comment><USER36> Promises, C++ style?

<comment><USER37> That's what I surmised as well.

</comment></comment><comment><USER38> Names go against C++ convention, should be. Future<T> => future<T> makeFuture => make_future

</comment><comment><USER39> In game development we don't use futures or similar mechanisms. We use job systems. They are much more powerful for serious muktithreading requirements. I'm not saying futures are useless at all, but we wouldn't use them where performance matters.</comment>


Daniel Dennett: The Normal Well-Tempered Mind - <AUTHOR> http://edge.org/conversation/normal-well-tempered-mind <comment><USER3> _You begin to think about the normal well-tempered mind, in effect, the well- organized mind, as an achievement, not as the base state_

As an aside,

Almost no one ever really analyzes sanity. Somehow, despite not understanding why exactly we exist, what our purpose is, and that at any given moment we could die and cease to exist, we don't go insane. Do you have any idea how crazy that is? Even "insane" people are just experiencing delusions ontop of reality - the constructs from their mind are mundane in a sense because while they aren't real, they are sane. Real insanity would be realizing how large the universe is, that philosophers cant even prove anything besides solipsism exists, or how meaningless life is. I've come to the conclusion that I must be insane, since sane people don't notice any of this - clearly all the completely sane people don't give it a second thought.

And of course I'm sure plenty of you will say sure life has purpose, or solipsism is too narrow because it isn't useful to use as a worldview. Because you're all sane. ;)

<comment><USER4> >>Real insanity would be realizing how large the universe is

I remember going camping when I was 15. After everyone else fell asleep, I laid on my back under the clear open night sky and let my mind wander.

I first thought about planets in our solar system, then the interstellar medium, then other star systems with their own stars, planets and asteroid belts. I then "zoomed out" and thought about the Milky Way, then about other galaxies, spiral ones and starburst ones and irregular galaxies, and the void between them. I thought about nebulae and black holes. As time passed, I started to view Earth as _just a planet_ , and our sun not as _the Sun_ but as _a star_. Just one out of countless. I started to put myself in the shoes of an alien who lives on another planet - or maybe within interstellar clouds! - and tried to...

Then I stopped.

The reason I stopped was because I had the distinct feeling that my mind was about to _break_. As if I was about to run a buggy function, and if I pressed Enter to run it, it would throw an _index out of bounds_ error and crash permanently. So I did the sane thing by pulling my sleeping bag over my head and falling asleep.

<comment><USER5> I think that feeling is a major barrier we as a species need to get past, which is more of a spiritual/therapeutic issue than an intellectual one as far as I can tell. This foundation provides free 10-day silent meditation retreats where they push you to have that experience but instead of opening your eyes and "pulling the sleeping bag over your head", you embrace it and explore beyond. It changed my life. I've been to two of these things, one in CA and one in TX and if you ever have time it's worth it in every way. I'm not affiliated with them in any way, I just think it's relevant.

</comment></comment></comment><comment><USER6> I really like this conception of brains working as internally competing and cooperating ferral units. I'll have to give it some more thought in the morning. I do have an entreaty for you though:

In this era of high throughput computing, elegant biotechnology, and the coming of the BRAIN initiative from the national level, I believe the best way to attack the problems of mind/brain right now is hard work and the scientific method. We need more data and we need to analyze it.

We're hiring developers for eyewire.org - a game to map the brain by crowd sourcing/gamifying the analysis of electron micrographs of stained retinal slices from mice. We're developing the tools to map the connectome. For real. The PI for my lab, Dr. Sebastian Seung, is mentioned in this article, and I love working with him. There are other absolutely incredible people working here too that will blow your mind.

Send an email to support at eyewire dot org if you want in or email me personally (see link in my profile) if you want more details. (I won't be able to get back to you instantly - I'm totally swamped, but if you're hired, based on my experiences so far, it'll be worth the wait).

Here are two fun explanatory videos from TED/TEDx: [http://www.youtube.com/watch?v=HA7GwKXfJB0](http://www.youtube.com/watch?v=HA7GwKXfJB0) \- Sebastian Seung talking connectomes [http://www.youtube.com/watch?v=7gKt8iT08Zc](http://www.youtube.com/watch?v=7gKt8iT08Zc) \- Amy Robinson talking EyeWire

Thanks for reading. I hope this post isn't too far out of our community norms - I don't see too many (large) job postings in the comments, but I felt like this article is the perfect place to find someone willing and able to provide much needed help (I'm the only web developer / aspiring neuroscientist there right now). :) If I'm taking up too much space, let me know and I'll condense it.

<comment><USER7> Looks like an amazing project. I think crowdsourcing is vastly underutilized for tasks like this.

May I make a suggestion re: the web site? In the home/registration page, it would be very helpful to link to some kind of description of the project, even if it's just one paragraph. Better yet, include that short description on the page itself.

As things stand now, I go to the sign-up page, but if I want to have any idea what the project involves before I sign up, I have to leave your site and go google the project (fortunately, there's an excellent Wikipedia article about the project).

Best of luck with your project and finding some good job candidates. If I were in a position to relocate, I'd apply for the job.

<comment><USER6> Haha, this is something hotly debated in the lab as we speak. We just started A/B testing descriptions on Friday. :) Thanks for the kind words!

</comment></comment></comment><comment><USER8> "You [use a highlighter and] break the whole article down into two or three or four or thirty-two sub articles that are basically ideas...and this looks like a regress, but it's only a finite regress, because you this gigantic article and you break it down into a group of simpler, more obvious points, and you keep going until you arrive at the end, and that's a great way of reading about cognitive science without wanting to stab yourself."

</comment><comment><USER9> The strange thing to me is that our minds aren't really that great at studying and describing themselves. You'd think that a mind interested in how minds worked would happily examine itself in whatever level of detail it wanted. One could hope that someone like Dennett could just close his eyes, sit back, and directly observe the answer to all of his most pressing questions. Why doesn't that seem to be possible?

<comment><USER10> Why would it be? Evolution is mostly driven by getting enough calories and mates. If your brain needed to be twice as big and needed twice the calories to perform self introspection, for example, it would probably be selected against by evolution since the gain wouldn't be worth the cost.

It would be like running a debugger in production. Kills the performance.

<comment><USER9> I'm not saying that we should be introspective in lieu of reproducing. It's not an all or nothing thing. BTW that same line of argument could be made against philosophy or even large portions of science, but clearly people can (and do) think about things that don't have an evolutionary advantage. But for some reason, direct knowledge (and manipulation) of our own minds is curiously out-of-reach.

<comment><USER11> Larger brain by itself is a very strong evolutionary disadvantage - <USER2> consumes a lot of calories, and in humans it hampers childbirth which in out natural state is very deadly already.

There is a strong pressure for us to have a brain that's "barely just enough" capable for the functions that increase survivability.

</comment></comment></comment></comment><comment><USER12> If you'd like to read more of Dennett's (newer) understandings in a more cohesive form, check out The Intuition Pump. He talks less about his mistakes but more about how his new ideas really mesh with science and real ethics.

</comment><comment><USER13> Nothing new in the philosophy departments: thousands of words and nothing to say at all that would be connected to reality. I heard he cites some experimental works sometimes, but his own work seems still to be in this good old tradition of medieval scholasticism of thinking very hard what "ought to be", he even personifies neurons and throws in some "emergence". Missing is only some chaos theory and Goedels theorem, but Plato is there, so maybe this makes up for it. Worst is that he will inspire hundreds of cranks to do similar attempts at "explaining how brain works" and people doing real research will receive still more letters with "revolutionary" ideas of no use.

On the topic of the brain, I will take a paragraph from a biologist over a treatise by a philosopher.

<comment><USER14> I assume this is just a troll, anyone who doesn't know who Daniel Dennett is should peruse his CV sometime [http://ase.tufts.edu/cogstud/incbios/dennettd/dennettdcv.htm](http://ase.tufts.edu/cogstud/incbios/dennettd/dennettdcv.htm)

<comment><USER13> I know "who he is". Do I have to agree with him because he is a professor? Every piece of his writing I saw used the most complicated language possible and the largest amount of digressions to in the end convey nothing concrete whatsoever and this is all the more true of this article. Moreover I think one can not make any serious contribution to cognitive science using the methodology he uses and that what he is doing is akin to people trying to explain "what gravity is" before Galileo came, abandoned the question, and used equations to predict effects of gravity instead. If I am wrong, I seriously would love an explanation of why do you think so.

As others have said Marvin Minsky, who I by the way respect way more than Dennett because in his prime he actually did do real research, had this idea of a "community of agents" thirty years ago or more, in fact he several time claimed that if only he would receive the money to hire programmers he would produce revolutionary AI programs in a matter of months. How this is looked upon by more mainstream scientists one can guess. To me the whole theory is as vague as saying that the brain is made up of cooperating parts. Does any of this lead to testable scientific predictions?

<comment><USER15> I admire your healthy level of skepticism. I've been intrigued by Dennett for years, but I haven't drunk his Kool-Aid.

How do you find triune brain theory? I'm finding it a very useful model. Want to know what I think many of these "brain guys" get wrong? The fact that many neural circuits include loops through the body at various distances. Doesn't it seem like many theories are actually projections of social models? (consider the shift from cleverly-connected agents to "decentralization" to competing individual neurons). There's a theory somewhere that says technocracies develop products that mimic their internal communication/social structure. I see startups go through this all the time. anyhoo...

<comment><AUTHOR> It would have been good if you included your references instead of halfheartedly telling us the keywords why you maybe disagree. I still upped your comment, because despite your ignorance, you've developed your own views to things, which as I said, just lack the references. Have an open mind and go beyond the words, start with your own imagination. To me it sounds, as if you cannot reason Dennett, but you leave us unclear what "that" logic inaccuracy is, thus making you appear ignorant.

The missing links (please complete them, if there was more that you'd like to share):

[http://en.wikipedia.org/wiki/Diffusion_of_innovations](http://en.wikipedia.org/wiki/Diffusion_of_innovations) [http://en.wikipedia.org/wiki/Triune_brain](http://en.wikipedia.org/wiki/Triune_brain)

</comment></comment></comment></comment></comment><comment><USER16> Minsky talked about the 'society of mind' involving competition between many autonomous modules a very long time ago; funny that he isn't even mentioned.

The brain-as-computer analogy needs more qualification than it is usually given. When one says that, people tend to think of a computer very abstractly; as some Turing-machine like substrate on which one can run any computation. The brain isn't like that at all; it's built out of all kinds of ASICs that have evolved for very specific functions. The reality is probably much closer to 19th century phrenology than 50s cybernetics.

<comment><USER17> > The brain isn't like that at all; it's built out of all kinds of ASICs that > have evolved for very specific functions.

That turns out not to be the case. There _are_ some specialized modules, but stroke studies have shown that massive damage to specific functions can often be recovered by retraining. It seems that particular parts of the brain are especially good at learning particular jobs, and that when they learn a job they somehow suppress redundant learning by other regions. Much of the apparent specialization of the brain is very possibly an optimization process, akin to a computer cluster that automatically assigns I/O jobs to nodes near the mass storage.

<comment><USER18> I believe that optimizations observed are almost purely function of brain activity. Any boosts genes provide to specific regions are quantitative not qualitative in nature.

<comment><USER17> In the cerebral cortex, I agree. It seems like any handy chunk of cortex with enough connections can learn a task.

Outside the cortex there are dedicated organs within the brain: circadian rhythym generators, the locus ceruleus, the hippocampus, and many others.

</comment></comment></comment></comment><comment><USER19> 2nd time in one week that Dennett has popped up on HN (see [https://news.ycombinator.com/item?id=6374470](https://news.ycombinator.com/item?id=6374470))

Philosophy of mind is a very interesting topic as computers become more and more 'human' like. Dug up an essay I wrote freshman year on one of his books called Consciousness Explained - funny to look back at old writings:

[https://www.dropbox.com/s/g3t7ntwy782m005/Dennett%20Paper%20...](https://www.dropbox.com/s/g3t7ntwy782m005/Dennett%20Paper%20%28Spring%20%2708%29.pdf)

<comment><AUTHOR> Thanks for sharing.

</comment></comment><comment><USER18> Whenever I hear about "free will" I wonder if that's just Judeochristian narrative or do other cultures also have same idea featured so prominently.

</comment><comment><USER20> One bit of additional info on this topic. To understand how and why neurons are independent, you need to understand how a baby's brain grows into its body by producing an overabundance of neurons and then "pruning" the ones that aren't used. So neurons are subject to natural selection as we grow:

[http://mxplx.com/Meme/922/](http://mxplx.com/Meme/922/)

</comment><comment><USER21> "...and I suspect that a more free-wheeling, anarchic organization is the secret of our greater capacities of creativity, imagination, thinking outside the box and all that, and the price we pay for it is our susceptibility to obsessions, mental illnesses, delusions and smaller problems."

Great observation! Isn't it true that the geniuses of this world have very often been afflicted with mental abnormalities? Take the most brilliant mathematicians, engineers, scientists; so many of them faced such problems. There indeed seems to be some connection between the mind's capacity to innovate and create and its capacity to suffer delusions and obsessions. Take examples of Gödel, Turing, Tesla, Hemingway, etc. [http://dsc.discovery.com/tv-shows/curiosity/topics/mad- geniu...](http://dsc.discovery.com/tv-shows/curiosity/topics/mad-genius.htm)

<comment><USER15> >geniuses of this world have very often been afflicted

Maybe so, but don't forget, there is no "normal" human being. We create the criteria of genius, normal and mental illness all in order to fulfill our social needs. It's possible we categorize certain individuals as genius and afflicted just so we can deny them the fruits of their labor. It's possible we create the concept of normalcy just so we can leverage techniques of mass manufacturing and social control.

It's possible that innovation without being identified as a genius is a smart way to escape the disadvantages of being labelled afflicted. It's possible Dennett's newest change-of-mind is just an update to the fairy tale that tells those in charge how to handle workers for the maximum effect and least disruption.

After all, who wants anarchic disruptions in the social order? We want reliable electrical networks and food delivery, not creative, experimental protests. So instead of heeding the words directly of those with insight, appeal to their ego, call them geniuses, strip their innovations to the bare minimum and label them as crazy or problematic to keep them separated safely from others. (cough) Torvalds (cough) RMS.

<comment><USER21> Maybe so. Even though I am not aware of any studies of this kind of a link between insanity and genius, the kinds of afflictions I am talking about are not imaginary. They are real mental disorders like OCD, bipolar disorder etc.

</comment></comment></comment><comment><USER22> I was slightly confused the format of seemingly disconnected subsections, but I can't really complain because each section was quite interesting on its own.

While we are on the topic, if anyone has any great recommendations for entry level philosophy/ethics books, I would love to hear them.

<comment><USER23> > recommendations for entry level philosophy/ethics books

Nice (but opinionated and now ~50y old) overview: Bertrand Russell's "History of Western Philosophy". Long but extremely readable. Not necessarily very reliable.

Ethics specifically: Peter Singer's "Practical ethics". Note that Singer thinks that we (in the affluent West) should all be giving a lot more than most of us do to help less well-off people, and that non-human animals' welfare is much more important than most people treat it as, and he's quite persuasive. So reading his work might be bad for your financial and/or gastronomic well-being (but if so, you will consider that that's for the best).

Not all that entry-level but full of clever things and exceptionally clear (in approximately the way that maths/physics/computing people value clear thinking extra-highly): Gary Drescher's "Good and Real". Subtitle is "demystifying paradoxes from physics to ethics".

Just for fun: Quine's "Quiddities: an intermittently philosophical dictionary". Not really a dictionary, but a collection of short essays and remarks in alphabetical order of (single-word) subject. Quine was an absolutely first-rank philosopher, though he's not in particularly serious mode here.

Not at all entry-level (in terms of how hard you need to think; I don't think much expert philosophical _knowledge_ is needed) but extraordinarily good and highly relevant to questions of ethics, though it's more about questions of personal identity: Derek Parfit's "Reasons and persons". He's more recently written a large two-volume work on ethics, which I haven't read.

<comment><USER22> Thanks! I will definitely check some of those out.

</comment></comment></comment><comment><USER24> If "the normal well-tempered mind" is an achievement, rather than the base state, then can it really be called normal at all?

</comment><comment><USER5> [http://www.dhamma.org/](http://www.dhamma.org/)</comment>


Go 1.6 Beta 1 is released - <AUTHOR> https://groups.google.com/forum/#!topic/golang-nuts/24zV9JeBoEE <comment><USER2> named blocks in templates! and http/2 in core! it's like an early christmas!

OK I know I have to wait till February... but still</comment>


Ask HN: Why does no one talk about working or interviewing for Apple? - <AUTHOR> I find it interesting that people here talk about the interview process and working at companies such as Google and Microsoft, but I almost never hear about Apple.<p>Why is this? Is it the iPhone/Android debate? Or is it something else? <comment><USER2> I interviewed with Apple last year, and I wasn't asked to sign an NDA. That said, I didn't actually see anything that would have required one.

I didn't apply to Apple - they found me. A year later, I'm still not sure how that happened, since I don't know anyone there. It could have been through a public talk about user experience that I gave (the position was for UX director of the Apple web site), it might have been through something I wrote, or it could have been as mundane as a LinkedIn search.

I went through a series of phone interviews in the usual ascending order. Everyone I spoke with was very sincere and conversational, there were no MS or Google-style "tests" to go through. We looked at work I'd done, I talked about my approach to UX, we got to know one another a bit.

Eventually, they flew me out to Cupertino (I live in NYC), and put me up at a nice hotel near the Apple campus. I spent a full day in an interview room, meeting various members of the team I would be working with, both above and below the position I was being considered for.

The only time we left the conference room where the interviews were happening was to take a stroll over to the cafe for lunch. I went with most of the team, and we talked about day to day life at Apple, what it's like working with tight security, the fancy Apple buses that take employees from SF and the East Bay to work, people's personal projects and hobbies, etc.

I got some insight into the way Apple works, and predictably, there was none of the corporate silliness that you'd find in a less confident company, none of the buzzwords or process for the sake of process. I could see that they all worked incredibly hard, but the fulfillment on everyone's faces made me want very much to be a part of it.

In the end, I didn't get the job - they ended up either not filling the position at all, changing their team structure, I'm not sure - they left me feeling very good about myself and the experience, probably the best way that I've ever not gotten a job.

The main impression I was left with was that I had just wandered back to a pre-dot com era where people worked incredibly hard to make great things, rather than to maximize profits or burn towards an IPO or whatever. It was one of the most human job interviews I'd ever been through.

<comment><USER3> My experiences were similar. I had several interviews with Apple:

1) Several phone interviews for an internship. They don't do fly outs for internships, if I remember correctly. I never finished this process because I took another position before the interviews were complete.

2) Phone interviews and fly out for a position about 1 year ago. The team had good things to say about me, but it wasn't a good fit for either myself or that team. I was referred to another part of Apple, where I started over.

3) Phone interviews and fly out for a different position just one week after #2. In a spat of horrible luck, I lost my contact lens at the hotel that morning. I decided that a makeshift eyepatch wouldn't look good, but having only 1 contact lens in gave me a splitting headache. As I struggled more than I should have, I felt them grow more cold. I was kindly told that the interviews were over about 3/4 of the way through.

Similar to jaysonelliot, I didn't sign an NDA and didn't leave the interview room except for lunch.

A few notable things about my interviews:

I was asked to code over the phone. That's much harder than white board coding, in my opinion. It was something fairly easy, though (atoi in c, or something like that).

I felt like I was judged on my Apple culture. When I revealed that I didn't know Objective C, that didn't seem to matter to much, but when I revealed that I didn't own an iPhone or a Mac, I did feel that my answers weren't what they were hoping.

The questions were very broad. Because I come from both a hardware and a software background, I was asked about everything from basic power dissipation to more traditional CS topics.

Honestly, I felt a much more happy and welcome atmosphere at Microsoft, which surprised me. It was kind of the opposite of the consumer perspectives of those companies.

<comment><USER4> I had an on-campus interview for an internship years ago that contrasts this a bit. It was about 30 minutes and there was no second interview. There were absolutely no technical questions. I was asked about whether I had experience with Apple products and development and the interviewer wasn't too offended when I said no. Absolutely no coding. The interviewer didn't seem to really care about the job description that was posted.

I was asked about some problem solving I had to do at a previous internship and I talked about how setjmp/longjmp saved my skin once. The interviewer seemed more pleased in the fact that I was excited about the solution than the fact that I had one.

Unlike you, I found it refreshing. I got the impression that they cared more about passion than obscure technical answers. In the end, I took another offer instead but it was a difficult decision to make.

</comment></comment></comment><comment><USER5> For the people working there, talking about it on a public forum is cause enough to get fired, and hiding behind an online alias is not going to give you enough protection. Apple is full of really smart people, who like their jobs well enough not to risk losing them so casually and for such little incentive.

As for the process of interviewing: for a lot of the more interesting jobs at Apple, interviewing involves signing an NDA. Hence, whether or not they end up getting hired, they're contractually prevented from talking about the interview process.

Having worked there in the past myself but not anymore, I can speak only _somewhat_ freely about it all. The interview process can be intense, taking up to several weeks and with a minimum of 4 interviews, but usually 7 or 8. Often, for practicality reasons (travel to Cupertino), all those interviews are done in a single day, and if it's more than 8 it'll be done across two+ days. As for the specifics of an average interview itself, I can't really say anything.

And as for working there, my own experience was largely fantastic, but it wasn't for me in the end. Apple's campus is by far the nicest I've seen of all the major companies (and I've seen all the ones in Silicon Valley), and though there is always a constant pressure, stress and a major (and insane) deadline to make, working there is incredibly satisfying. Unless, perhaps, you're at MobileMe. But maybe that was just me.

<comment><USER6> You can interview for all kinds of positions involving classified weapons and intelligence without signing an NDA _, but Apple requires you to sign one? What could possibly be so special about their interview process?

I guess they're worried about people gaming the system, but what stops someone from breaking the NDA to one individual going in for the interview and not online? Wouldn't that give the one individual a huge advantage?

_(Though I got fingerprinted and background checked before I could even sit down for those interviews)

<comment><USER5> As I said below, it's about the secrecy of the products & plans they're working on. Keeping those secrets is worth anywhere between $200 and $300 million of free advertisement a year (a conservative estimate, these days), so it shouldn't really be such a shock they'd like to keep secret things secret.

</comment></comment></comment><comment><USER7> I interviewed for Apple earlier this month. I didn't get the position, but I really enjoyed the challenging interview process and meeting the 7 people who interviewed me.

I had a phone interview with a manager, and then a three-hour process at Apple HQ in which I was interviewed by three pairs of employees from the team I was applying to work with. I was very impressed that they devoted so much employee time to talking with me. They were very friendly people, and asked an interesting variety of questions, ranging from puzzles to how I'd handle various theoretical work scenarios to technical questions of various kinds.

The gent who recommended me told me that he had to apply six times before getting hired, so I'm planning to keep applying, for other positions.

There. Now someone has posted about interviewing at Apple. Happy? :)

</comment><comment><USER8> There were 3 basic periods at Apple: the beginnings (aka Steve I), the Dark Ages (roughly '85-'97), and Steve Returns.

During the Dark Ages, Apple leaked internal information _badly_. One of the first things that Steve did upon return was try to clamp down (and fire people if necessary). He even had one of those WW-II posters "Loose lips sink ships" tacked up. And there is a certain truth to that. Competition has heated up (esp in the mobile space). Anyone and everyone would love to know what Apple is working on now, and what they will announce next month. Witness the kerkuffle with gawker over the iphone 4 engineering test device.

So people at Apple learn to say nothing, or move on down the road.

<comment><USER9> I think the period names you are looking for are "A New Hope", "The Board Strikes Back", and "The Return of the Jobs".

<comment><USER10> _The Phantom Menace, Attack of the Clones,_ and _Revenge of the Sith._

</comment></comment></comment><comment><USER11> My first guess would be respect for the company. Secondarily, plenty of results in google reveal that the policy (if somewhat unofficially) is that you can say you work at Apple on your blog, etc, but not really blog /about/ Working At Apple. Even if there's no official policy on it, it's just better taste to say "The thoughts of John Doe" and not represent oneself as "John Doe of Apple."

"There's a PR department for that."

All that said, there are plenty of writers/bloggers who work at Apple. Randsinrepose.com is a personal favorite, and contains the writing work of Michael Lopp who may be an engineering manager at the fruit company. This policy of sorts goes much further back than iPhone/Android or any other blog- hyped non-competition.

<comment><USER12> Interesting, I never realised that Rands works at Apple...

<comment><USER13> Worked, according to WP: <http://en.wikipedia.org/wiki/Rands>

</comment></comment></comment><comment><USER14> The first rule of working at Apple - No one talks about Apple.

<comment><USER15> Second rule of Apple: one button and no more. If you need more, just use the on-screen buttons.

<comment><USER16> I actually understood the one-button mouse idea recently. It forces software developers to try not to hide all the useful features behind right-click menus, but figure out how to consistently lead a user to where they want to go.

User Story: My wifi wasn't working on my windows laptop the other day, I knew there was some nice "troubleshoot network" button, but I could not find it for the life of me every time i clicked on the wifi icon, causing me to go through the "network and sharing center" menu . 10 minutes later I finally realized right-clicking instantly brought up the troubleshoot menu.

<comment><USER17> > It forces software developers to try not to hide all the useful features

except that in the Mac you can option-click, which is even more complicated than a right click. There is always a way to make features obscure, if you want to.

<comment><USER18> >except that in the Mac you can option-click, which is even >more complicated than a right click. There is always a way >to make features obscure, if you want to.

Emm, I think you missed his point. This is EXACTLY why the single button mouse forced software developers to make it work with a single click --because it made the "right click" equivalent more difficult for the user.

</comment></comment></comment></comment></comment><comment><USER19> Probably because most of the people working there would like to keep their jobs.

<comment><USER20> Freedom, yeah baby!

</comment></comment><comment><USER21> I believe that they've got somewhat strictest policies on talking about internal stuff.

Well, at least that's what some bloggers write about [1] and I haven't heard about any counter-proofs.

[1] [http://gizmodo.com/5427058/apple-gestapo-how-apple-hunts- dow...](http://gizmodo.com/5427058/apple-gestapo-how-apple-hunts-down-leaks)

<comment><USER22> I agree. I have close, personal friends who went to work at Apple. The last time I talked to one of them, they started getting visibly nervous just talking about the breakfast they had at the on-campus cafe.

Not what it cost, or what it was, but even that it existed.

I quickly changed the topic.

<comment><USER23> Sounds like your friend suffers from bizarre paranoia or acute social anxiety. (See how I can just make stuff up too?)

Having been invited multiple times by friends to Infinite Loop for lunch and dinner, and debated the quality of the food vs Google's with them (Google still wins on that front), I can safely say that nobody at Apple gives a shit if employees talk about the cafe.

The Gizmodo article is pretty much bullshit as well, my friends tell me. Unless there are groups at Apple that are more secretive than the UI team/iPhone/iPad are and actually enforce those rules on their own.

<comment><USER22> "(See how I can just make stuff up too?)"

Unfortunately, I didn't make up my post. Your reply is just as interesting without peppering in a baseless accusation.

<comment><USER23> My apologies!

Your friend's reaction was just plain absurd, unless he/she was playing a joke on you.

</comment></comment></comment></comment></comment><comment><USER24> This is a really interesting question, and got me thinking - maybe google's brutal interview process has a secondary purpose - to increase the allure of working at google?

This reminds me of a business case I read once about the difference between Mac Donalds and Burger King. That Mac Donalds uses a batch processing method that is faster but requires a higher skill level, whereas BK uses an assembly line, and that this affects their advertising. MacD's ads often double as recruiting ads, whereas BK tends to emphasize "have it your way" (easier to customize when you make burgers one at a time).

Maybe Google wants to interview more people than necessary, and subject them to an interview that leaves them thinking "man, you need to be at the top of your game to work there!" as a way of increasing the prestige of working there (and perhaps getting more top applicants?)

The thing is, I don't really see why this strategy would apply more to google than apple (unlike the MD vs BK thing...)

One thing is sure - devs are all aware of google's notorious interview process, but we (well, I should really just speak for myself, so I) never really hear these stories about apple.

<comment><USER25> Anthropologists have noted for a long time that social groups with high barriers to entry engender greater loyalty. This behaviour occurs throughout many cultures -- from tribal rites of passage through to frat boy hazing, the nastier the experience, the stronger the bond.

I expect that brutal interviewing is no different.

</comment></comment><comment><USER26> When Glyph Lefkowitz (of the Twisted project) was hired, he posted unboxing pics of his job offer to his blog (which has since been closed down). He praised the usability of the letter.

Second-hand mention in: [http://www.geek.com/articles/apple/unboxing-an-apple- job-off...](http://www.geek.com/articles/apple/unboxing-an-apple-job- offer-2009106/)

</comment><comment><USER27> I worked at Apple EMEIA for a year and, truth be told, the interview process there depends.

It depends on where you want to work. If it's in Cupertino I'm told it's a completely different story to the EMEIA office. Having worked there, I can vouch for there really being a culture of absolute secrecy. It's quite common for one team to not know what's going on in the other corner of the room with another team. Secrecy has gotten even more prevalent in the EMEIA office (the office being made up of project managers alone, it was formerly less secretive than Apple World Wide/Cupertino) since the Gizmodo iPhone 4 affair. As regards fear related to Apple's security paranoia? It was moreover regarded as an irritation.

Going back to the interview process at Apple EMEIA (I can't say for Apple WW), it depends entirely upon who interviews you, which team, for what role, and what level. There is no set pattern. There may be an NDA for the interview process, there may not. It depends on the role and the person you are seeing. I know some who've had only two interviews, some who've had nine. It depends.

</comment><comment><USER28> Whether it's intentional or coincidence, it's interesting how it parallels their products. There are approximately three people who work for Apple. They are the shiny, slick interface. Everything else is an implementation detail.

Jonathan Ive is like OS X. Nobody knows how OS X actually works, but they know the name and that it is why their screen shows such pretty things.

<comment><USER29> What makes you say nobody knows how OS X actually works? The developer documents aren't a big batch of jokes, they describe how the system works. Also take a look at "Mac OS X Internals" by Amit Singh, there's more about the inner workings of OS X there than you could ever possibly care to know.

<comment><USER28> When I say nobody, I mean no normal people. By posting here, you automatically exclude yourself from that group. Your mom doesn't know how OS X works.

<comment><USER29> Normal people aren't supposed to know OS internals, that's the whole point of UI abstractions! They have more important matters to deal with when they use a computer. OS X isn't any different from other OSs in this regard: your mom doesn't know what the registry is.

</comment></comment></comment></comment><comment><USER30> The man in the black turtleneck will find you if you talk

</comment><comment><USER31> I interviewed for Apple a few months ago. I didn't get to the NDA signing part (I backed out because another opportunity came up during the process) but still wouldn't talk about the interviews I went through because I still hope to go back and try again someday (in the slim chance that our current venture doesn't work out).

</comment><comment><USER32> There's folklore.org but that's like 25 years ago.

</comment><comment><USER33> I blogged about my experiences both in Apple Retail, and in "corporate" Apple for a number of years. Eventually I took it all down, though not due to any pressure from the company. I took it down because I was inundated with emails from 15 year olds who wanted to know how to get a job in an AppleStore. But I worked for Apple for 6 years in Retail and AppleCare, and interfaced extensively with hardware engineering. I'm not sure I'd have anything interesting to say, but if you have any questions, I'll try my best to answer them.

</comment><comment><USER34> The NDA comments across this thread are interesting, in the company I work for we NDA on just about every single external interaction. We're an IP black hole - anything you do using company resources (including sitting interviews) is considered our IP and is controlled as such.

We often get PHD students in to do research for us, and we compensate the hell out of them - because nothing they do ever leaves the walls. They sign a series of NDA and IP related contracts up front and don't get to use any external assets internally or vice versa.

The structure of the business itself is a mess of interwoven black box systems / IP and our own work, so it gets pretty aggressive / tight lipped whenever anyone is dealing with other people / companies, even internal branches.

</comment><comment><USER35> NDA?

<comment><USER36> This comment probably has one of the highest upvote-to-character-length ratios in HN history.

<comment><USER37> __

<comment><USER38> #DIV/0!

</comment></comment></comment></comment><comment><USER39> If you go to Apple, you might be surprised to find out that you've already agreed to some form of NDA with them. Especially, for example, if you're a part of any Apple Developer program. They might not always feel compelled to remind you of this, however.

I wouldn't know, though; I don't think I recall ever having been to Apple. No, not in a million years. I do find this Apple sweatshirt which I must've found at a thrift store to be especially comfy, however.

</comment><comment><USER40> but i think the author's got a point, you never hear about any stalwarts of software dev defecting to apple, do you?

<comment><USER41> no never. not jordan hubbard, not dominic giampolo. no-one.

<comment><USER42> Who?

<comment><USER41> Tsk, young people today. No idea of history (where history == about ten years ago)

<comment><USER43> It could be that it's not as common currently? I may have just missed it, but I haven't noticed any high-profile moves to Apple in the past 2-3 years, contrary to the situation with people moving around between Microsoft, Google, and Facebook.

</comment></comment></comment></comment></comment><comment><USER44> Regarding NDA's - Don't most companies sign some sort of an NDA with potential hires/ employees??Still, interview questions of most companies are available if you google well enough. But yeah, the difference is humongous- Apple doesnt seem to have the faintest thing similar to mini-microsoft :-)

</comment><comment><USER45> i have a friend that works at apple, and other than providing a vague job description and saying they like it, they don't discuss details.

i think it's the culture, your work speaks for itself. he puts in long hours (on par with goog really) and has a great salary and perks.

</comment><comment><USER46> The first rule of interviewing at apple is that you do not talk about interviewing at apple.

</comment><comment><USER47> Sounds like a cult tbh - and I'm a mac fan.

</comment><comment><USER48> It's simple.

If you want the job,

And you're smart,

You'll keep your goddamn mouth shut.

</comment><comment><USER49> The first rule of Fight Club?

<comment><USER50> "No smoking."

<comment><USER41> that's the second rule

</comment></comment></comment><comment><USER51> Fear is a man's best friend.

<comment><USER52> "Fear is a dictator's best friend"

FTFY :-)

<comment><USER51> It's probably not nice to refer to Steve in that way ... ;)

</comment></comment></comment><comment><USER53> I interviewed at Apple for a product manager role. I have an MBA, and they were an on-campus recruiter. I interviewed on campus, then they called me to tell me I was going to have a 2nd round interview in Cupertino. 2 weeks later, I haven't heard anything and I am scheduled to be in Mountain View for a GOOG interview. I email them, telling them that I'd be happy to come in and save myself the time and them the travel expense...

They email me a week later (post my interview) and tell me "that should work..." They really have a crappy set of recruiters working there. Ultimately, I needed to accept another job (ended up being at AMZN), and Apple never actually got back to me. I've heard some similar stories about recruiter ineptitude there.

<comment><USER25> So they treat engineers and designers better than MBAs?

Oh noes!

</comment></comment><comment><USER54> Remember the Oompa Loompas?

Same concept.

</comment><comment><USER55> We all talk about how Megan Fox is hot, but then return to designing a descript schemantic intended to woo the girl next door.

And I dont mean to say that apple is out of one's league.

</comment><comment><USER56> There's enough talk here about Apple, maybe not about working or interviewing there, but honestly there's just way too much talk about big companies on HN already; we don't need more.

What's the point of this meta thread anyway? Are you planning to work at Apple? If so, why don't you just ask specific direct questions about that?

Flagged for zero content.

<comment><USER57> Sounds like personal preference. This site is for natural selection. If people are interested in it then it will get voted up. _Voted Up because I've often wondered it myself_

<comment><USER42> It's kinda interesting, though, that when this site was founded almost 4 years ago, everything was about "What's it like to work for a startup?" And now, everything is apparently "What's it like to work for Google/Facebook/Apple?"

I wonder if that's a symptom of HN's widening userbase, or if it's a sign of the times. Back in 2007, the startup market was _very_ glutted, and a lot of people (including myself) were founding companies who probably should not have been. Now, it seems like every top developer's dream is to work for one of the Big 3. I wonder if that's a sign that it's time to start founding companies again.

<comment><USER58> Don't forget that some of the original Hacker News user base is getting older and deciding to try out new things. Working for a large technology company, even if you ultimately want to strike out on your own, is a good experience and can teach you a lot of thing you're not going to learn at a startup or small business (simply because you'll never encounter them)

<comment><USER59> > Don't forget that some of the original Hacker News user base is getting > older and deciding to try out new things.

I think for the most part that it is because they're simply leaving.</comment></comment></comment></comment></comment>


Building Large-Scale jQuery Applications - <AUTHOR> http://addyosmani.com/blog/large-scale-jquery/ <comment><USER2> Backbone.js is amazing.

We're rebuilding some pieces of our editor in Poll Everywhere and to date, its the most sensible approach to JS MVC that we've seen. Frameworks like Cappuccino and SproutCore make it really hard to control the look and feel if your application and take an "all or nothing" approach whereas Backbone.js goes with the "grain" of the web letting you mix-and-match whatever JS libs you want to use for your project.

</comment><comment><USER3> Definitely check out this article if you want to hear more about how these things are used over at Grooveshark (article by our very own sant0sk1):

<http://news.ycombinator.com/item?id=2008079>

</comment><comment><USER4> There is a lot to digest in that article. My gut tells me to stick with jQuery plug-ins for consistency, but he seems to lean to the mix and match side of things. Any opinions on that from the folks here?

<comment><USER5> jQuery plugins are the devil.

</comment></comment><comment><USER6> Oh the irony of a "user interface ninja" who puts all the actual content below the fold. (My laptop res is 1366x768 which I believe is fairly typical for Lenovo branded thinkpads)

</comment><comment><USER7> This is the best list of JavaScript tools I have ever seen.

</comment><comment><USER8> For people who want to get things done instead of becoming architecture astronauts:

<https://github.com/hafriedlander/jquery.entwine>

(Go ahead, play with it: <http://jsfiddle.net/eterps/kKvbC/> )

<comment><USER8> More elaborate example: <http://jsfiddle.net/eterps/4Yacx/1/>

<comment><USER8> Full screen: <http://fiddle.jshell.net/eterps/4Yacx/1/show/light/>

</comment></comment></comment><comment><USER9> Maybe this guy is a Javascript Ninja but he doesn't know the first thing about colors.

Terrible readability, just horrid.

Edit: This sounds really mean. I usually don't criticize the design of stuff posted on HN but on the top of the page he claims to be a 'web interface ninja'. That's really pompous. But he designs this?

<comment><USER10> He wants to get his money's worth, so he uses all of the colors.</comment></comment>


RemoteStorage.js 1.0.0 released - <AUTHOR> https://community.remotestorage.io/t/remotestorage-js-1-0-0-released/414 <comment> le-mark I've been watching "unhosted" for a while, and the key thing to know is they're talking about data. The idea is that web apps following the "unhosted" pattern will get/put data from _your storage_. And this is an api that presumably storage providers/services would implement to enable that. So you'd either host a storage provider on your server somewhere, or pay a provider of such a service.

This is vastly different than some web app, ie a single page app, storing data on a cloud database somewhere (DBaaS for example). Because, the web app owner _still owns and controls that cloud database_. I'm very interested to see where this goes.

Edit: reading the docs, I have a lot of questions. This appears to be wrapper for browser local storage, that can then sync to a third party provider (local first). But browser storage is basically a key value store. Also reading the docs, they talk about using data modules defined with jsSchema.

That's all fine, but consider the use case for a note taking app. I store all the users data as json objects, that are evenutally persisted to the storage provider. So to query the users data on a new device, to get last weeks notes for example, I have to pull down _all_ the user note data. So basically with this model you are pushing around large sets of json from device, with no way to query or get at a range of objects for example.

This is less appealing than it first seemed. Am I missing something?

<comment><USER2> Yeah, would understand that the data pull would be biggest on that initial set up of a newly-introduced device...but then smaller pulls of only deltas going forward (like rsync, etc.). At least, i hope that is the direction taken eventually.

<comment><USER3> This is roughly how the library works. It will compare the directory listings with the cached items and only download new and updated ones, as well as remove deleted ones.

</comment></comment></comment><comment><USER4> Cool, congrats to team getting to 1.0.0

We (draw.io) 100% believe in this model, it's absurd that the data should live with the SaaS application provider. It's user lock-in, plain and simple.

<comment><USER3> Thanks! I love how many different providers you support already. Ping us on IRC or the forums if you need help integrating RS into your app.

</comment></comment><comment><USER5> I get that the SaaS model of owning user data is wrong. However, I've noticed that some comments seem to imply that it combats being "locked-in" to a provider. Surely a web-app'a data structure is so tailored to its service that you couldn't switch to another provider easily, with local storage.

What I'm getting at here is that remote storage isn't service agnostic really, is it? Unless the data structures are really standardised/simplistic.

Nonetheless user ownership is worth enough in of itself.

<comment><USER6> It gets somewhat easier to reverse engineer one of these apps, since the structured data can easily be made available. Not that it means that much, but it's something.

Also we can hope that the next step is standardized ways to store some data (e.g. a common key and data structure for calendar events) allowing multiple apps to read the same data =D

<comment><USER3> Core team member here. This is indeed something you can already do today, but more importantly which is our next area of focus for development and improvements: [https://remotestoragejs.readthedocs.io/en/latest/data- module...](https://remotestoragejs.readthedocs.io/en/latest/data-modules.html)

We'd be happy about any and all feedback and ideas about this specific topic. Our community forums are a good place for that: [https://community.remotestorage.io](https://community.remotestorage.io)

</comment></comment></comment><comment><USER7> This is very interesting. I've been thinking about what kind of storage solutions to use for several tiny PWAs (progressive web apps) with which I've been tinkering.

I'm pretty skeptical that this is really practical for most people. I think it's a lot like 'programming for everyone' tools. Most people are basically doomed to fail in some kind of way because both maintaining data and programming are just inherently difficult.

Hell, I'm pretty confident in my programming abilities, but most possible interesting projects require a significant amount of time, if nothing else. Similarly, even tho I'm pretty comfortable with servers, command line shells, etc., managing a working and reliable personal backup system – that's actually resilient to infrequent but inevitable catastrophes – is not a trivial amount of work. And getting the damn thing setup in the first place has been a very significant amount of work!

I'm not sure most people are making a wrong decision with respect to all of the relevant tradeoffs. Most data is probably not that valuable and so the effort to _actually_ secure it and protect it is wasteful.

<comment><USER3> That's why you can choose a storage provider to do it for you. But as with email, you're not locked in to a single provider, and small ones will probably not scan your personal data using AI/ML algorithms, like e.g. Google does.

Edit: the library in question also supports using Dropbox and Google Drive, so your users don't even have to know about RS in order to sync your PWA's data to their own account with those.

<comment><USER7> > That's why you can choose a storage provider to do it for you. But as with > email, you're not locked in to a single provider

I wrote this before I realized you're right:

> Yeah, I get it. But the real benefit, that outweighs the cost in time and > attention, and maybe money too, is that you can control your data. Not > having your own copy, and your own backups, or not having the technical > ability to access relevant _info_ in your data, as I'd expect the vast > majority of people to not have, doesn't seem like it means that much > effectively.

Thinking about email was what opened my eyes. Even tho most people don't understand email technically, it's a standard feature, effectively, that pretty much anyone can have a new email provider import their emails from their old provider. That's a big benefit and just that benefit alone is worth implementing something like RS for a lot of webapps, if not nearly all of them.

</comment></comment></comment><comment><USER8> If only some company would release a "homepod" RemoteStorage endpoint with easy backups, this could have a chance at becoming widespread.

<comment><USER2> Hellz YES!

</comment></comment><comment><USER9> Would be nice if RemoteStorage were include as an App in Cloudron.io and/or Sandstorm.io, or even better, in NextCloud/Owncloud.

<comment><USER10> I seem to recall that Nextcloud actually supported this, but I can't find it right now. In any case, I know that there are people who are at least somewhat involved with both projects.

<comment><USER11> Yeah, that would be me. :) At some point we supported it, but it turned out that for security reasons you would have to have a separate domain for your remoteStorage than your Nextcloud – which kind of defeats the purpose of easy integration.

At leas that is what I recall. Still think it would be great to integrate remoteStorage properly with Nextcloud! :)

<comment><USER12> Hmm, maybe you could use Content-Security-Policy to force the files to be treated by the browser as if they came from a different origin?

</comment></comment></comment></comment><comment><USER13> How is remotestorage.io different to [https://tent.io](https://tent.io) ?

Are there any other data protocols aimed at helping users "own" their data out there?

<comment><USER11> As far as I can see, Tent unfortunately seems to be inactive. Last commit in 2013: [https://github.com/tent/tentd](https://github.com/tent/tentd), last blog post 2014: [https://tent.io/blog](https://tent.io/blog)

<comment><USER13> so we have a failed protocol from 4 years ago, what makes this remotestorage more likely to succeed?

</comment></comment></comment><comment><USER14> My immediate concern with the unhosted model diagram on the page is how do you make sure the data hasn't been tempered with? The web application needs to see it but now the added problem of not knowing if it's legit because the data source is the end user.

Another side idea that comes with this is something like IPFS or even torrent, where bits of the file storage are stored on individual nodes but incapable of meaningful data unless put together with other bits of data from other nodes.

I admit I'm not even sure how bittorrent make sures the other "bits" are valid, would love to know if there is some _p2p-storage.js_ you could drop on your webpage

<comment><USER15> Why do you need to worry if the data has been tampered with, the user can only hurt themselves.

If you need access to the users data then you will need to run your own server anyways, so you deal with the trust problem as any other web application does.

</comment></comment><comment><USER16> WebSQL when?

@Firefox devs: please add WebSQL support. Now that you lost the IndexedDB devs who voted against WebSQL, it's rather time. Mind you, NoSQL and NewSQL nowadays coexist next to each other. Safari and Chrome based browsers (90% global market share) support WebSQL, except Firefox.

<comment><USER17> Until WebSQL gets a full spec, I personally am completely against it.

Right now it's defined as "What SQLite does", which is not a way to implement a standard.

Not to mention that even if they did create a full "specification" for the SQL that it uses, it seems like way too much to force onto a browser to develop for not all that much benefit.

Safari and Chrome both support it, but it's not going to get any major updates and only exists in the browser today because it was added at one point.

<comment><USER18> I will be happy to write a spec for a cut-down SQL language (a subset of the language understood by SQLite) for WebSQL, and provide a "strict" flag for SQLite to force it to understand all and only the spec language. The prerequisite for doing this is that you (or anybody else, as long as it isn't me) need to get all the browser vendors on-board and promising to implement WebSQL if I write the spec.

The cut-down SQL would include just the basics: CREATE TABLE, CREATE INDEX, INSERT, UPDATE, DELETE, SELECT. No triggers or views. No support for partial indexes or indexes on expressions, common table expressions, or other such features. There would be a minimal set of built-in SQL functions, but with support for application-defined SQL functions written in javascript.

A competing implementation would not need to understand the SQLite file format nor the complete SQLite language nor would it need to implement the SQLite API. All it would need to do is support the basic SQL subset defined by the spec.

If you get the browser vendors on-board with this idea, and I'll write the spec.

<comment><USER17> While I'd love to see this happen, I'm not even sure where I would begin.

But if someone out there has experience working with whatwg or W3C on these kinds of things and wants someone to help out, I'd love to be a part of it.

But like you said, the hardest part is getting the different browser engines to promise support (or even take it seriously). I remember reading on HN a post from a woman who was involved in trying to get SVG in the browser standardized (sadly I can't seem to find it any more!), and just reading about the struggles she went through to even talk to someone involved who, while receptive, basically told her that it wasn't going to get done.

It seems like there would need to be an "advocate" who is part of the teams on EdgeHTML and Gecko that would be willing to fight for it before it would even begin, otherwise, like you said, it would all basically be wasted effort.

The JavaScript standardization system is quite nice, I wish that browsers could get together and come up with something similar for Web APIs...</comment></comment></comment></comment>


Oded Wins the Knuth Prize - <AUTHOR> https://rjlipton.wordpress.com/2017/06/22/oded-wins-the-knuth-prize/ <comment><USER2> The post mentions him apologizing "For not declining the award—as some might have hoped" \- can anyone comment on why that might have been the case?

<comment><USER3> Just a guess: It's a joke, referring to the fact that most people who win the $2.56 checks from Knuth don't cash them in.

<comment><USER4> Knuth's checks have their own wikipedia page: [https://en.wikipedia.org/wiki/Knuth_reward_check](https://en.wikipedia.org/wiki/Knuth_reward_check)

<comment><USER5> From the Wiki page:

> Very few of these checks were actually cashed, even the largest ones. More > often they have been framed and kept as "bragging rights".[4][5]

Cashing a check only removes it from your possession if you hand it in to do so. Banks these days need only a physical scan of a check, e.g. via mobile phone deposit. Why not do both? There's nothing wrong with taking payment for your efforts.

<comment><USER6> AFAIK, after deposit, you're supposed to void a check by either destroying it or writing something on the front of it (such as "void")

<comment><USER7> (void*)

</comment></comment></comment></comment></comment></comment><comment><USER8> Some context: doubly efficient interactive proofs are one of the fundamental ideas that make Zcash possible on modern hardware.

<comment> Ar-Curunir No, doubly efficient IPs do not have much to do with ZCash. deIPs are currently too weak to prove the general NP statements that ZCash requires.

ZCash relies on a different kind of "proof" system: SNARKs.

There's many differences between the two:

a) deIPs assume a computationally unbounded adversary, whereas SNARKs assume a polytime adversary.

b) deIP constructions currently suffice only for a limited class of languages, whereas SNARKs can prove any NP statement.

c) SNARKs have zero knowledge variants, whereas it is not clear how to extend many deIP constructions to be zero knowledge without changing the model (ala [https://eprint.iacr.org/2017/305](https://eprint.iacr.org/2017/305)).

d) Most deIPs are interactive proof systems, whereas SNARKs are non- interactive.

<comment><USER9> I think what you are claiming here is misleading.

Some pre-processing SNARK constructions (particularly ones used by some ZCash scientists) are based on multi-round interactive proof systems which reduce to one round (depending on how you count) when you relax some requirements. Such relaxations include weakening the adversary from being computationally unbounded to polynomial time bounded, forcing the prover and verifier to use a specific set of functions, or restricting what kinds of statements can be proven. Oded's work on efficient interactive proofs contributed to this effort. It is partially this efficiency that helps SNARKs actually be "succinct" and quick to verify.

You should check out some of the citations to Oded's work in [https://eprint.iacr.org/2012/718.pdf](https://eprint.iacr.org/2012/718.pdf) (which is co-authored by Alessandro Chiesa of ZCash) and see for yourself.

<comment> Ar-Curunir One can construct SNARKs from succinct MIPs, but these are again very different from deIPs. Sure, both SNARKs and deIPs involve highly efficient verifiers, and there is some overlap between the techniques used for succinct MIPs and deIPs, but that's pretty much where the similarities end. Furthermore, MIP based SNARKs are way too inefficient, and definitely not the ones used in Zerocash.

There are no constructions of SNARKs from deIPs, nor vice versa. In particular, one cannot construct laconic IPs at all for NP like languages.

P.S.: I'm Alessandro's student ;-)

</comment></comment></comment></comment><comment><USER10> Took me a while to register that the simple letter replacement cipher used on that message has 26! = 403291461126605635584000000 possible keys... Ha!

<comment><USER11> "ODED WINS THE KNUTH PRIZE"

I had a little help from context ;)

<comment><USER12> For those who don't get it, the cryptogram "YXWX APRN LKW CRTLK DHPFW" decodes to the above.

<comment><USER13> I was still deciding between "ODED GIRL SHE BRUSH TWICE" and "ODED MANY THE KNUTH SLAVE". This makes more sense.

</comment></comment></comment></comment><comment><USER14> Looks like he does research in theoretical computer science, applied to cryptography. With his academic expertise, what kind of industry jobs would fit his skill sets? He wouldn't fit the typical tech security job.

<comment><USER15> _> With his academic expertise, what kind of industry jobs would fit his skill sets?_

I would imagine his pick among the various industry research labs, if he wanted them.

 _> He wouldn't fit the typical tech security job._

Nor would he be a good fit as a line cook or as a surgeon...</comment></comment>


Ask HN: Please help test Mugasha audio player on linux distributions - <AUTHOR>

Hey guys,
I have been making many changes to our player and have had some folks complain about linux support. If you are using a linux distro, could you spare a few minutes and test it in a browser.
If everything works(or not) please reply to this post with your distribution and browser used.
http://mugasha.com/crossroads/28
Thank you :)
- Akshay <comment><USER2> Ubuntu 10.04 LTS Lucid Lynx / Google Chrome 5.0.375.38 beta \- works like a charm so far. Music plays well, I can start/stop and navigate to other songs. No issues.

Btw huge fan of mugasha! I used you guys everyday when you were in beta, but then I moved to shared office space where mugasha didn't seem to be able to stream =( [same computer, just would not stream] . Back home now though so glad to see you guys still rocking <3

</comment><comment><USER3> Kubuntu Lucid 64bit Chrome 5.0.375.38 beta - no action on buttons, except rollover. Same on Konqueror (Webkit-based). Also FF3.6.3. All are using Flash 10.0.45.2 (64 bit).

</comment><comment><USER4> Ubuntu 9.04 Karmic Koala

\- Firefox 3.5.9: Buttons don't work.

\- Crome 5.0.375.29 beta: Page becomes unresponsive and crashes.

</comment><comment><USER5> Ubuntu 10.04 LTS Lucid Lynx / chromium dailt builds, clicking on buttons does nothing. Song length is always zero.

</comment><comment><USER6> Ubuntu 10.04/FF 3.6 the buttons dont do anything on clicking. So nothing works. Are you based in India?

</comment><comment><USER7> Archlinux, gnome, chrome 5.0.396.0 dev. Page loads but buttons don't work.

</comment><comment><USER8> The browser back button does not work as expected in Vista + FF 3.6</comment>


Forth versus C - <AUTHOR> http://www.inventio.co.uk/forthvsc.htm

<comment><USER2> > Q. Could you define "better" in this context? > A. Easier to read and > maintain, fewer bugs, smaller, faster development.

That's fairly subjective. I find the whole "keep track of the stack in your head" thing quite irritating, to be honest. Forth is more dynamic than C, certainly, but beyond that, I find C much easier to utilize in that you mostly concentrate on what you're doing rather than dup dup swap drop roll bee bop a lop bam boom tutti frutti etc... C's big "extraneous" overhead is keeping track of memory allocation.

<comment><USER3> You can use variables in Forth. It's just scorned as non-Forth-ish. And you also have to keep track of memory allocation in Forth. (Though it's possible to write a garbage collector.)

<comment><USER4>
      "Though it's possible to write a garbage collector."

There is a Garbage Collection package available for Forth here (<http://www.complang.tuwien.ac.at/projects/forth.html>).

</comment></comment></comment><comment><USER5> Probably if you substitute Lisp for Forth, and Java for C, it would be more "modern" and still true.

<comment><USER4> They are in two different segments.

Forth and C are low-level languages. I can (and do) use them to develop firmware.

Lisp and Java are for "big-iron" system.

But you are right, one of the strength of Forth and Lisp is the availability of a REPL.

<comment><USER6> Lisp was for big iron in 1975. Machines with over a megabyte of RAM and several hundred KIPS. There are several Lisps and Schemes targeting the embedded world these days.

<comment><USER4> Yep!

Even Java is used in the embedded world today (luckily not my world).

Simply, C and Forth can scale down to really small MCU with few hundreds bytes of code space and some bytes of RAM (with Forth, on such small target you will probably loose REPL).

A readily available OSS Forth I really like can be used on small MSP430 where no lisp or scheme can go! (www.camelforth.com)

Currently most embbeddable scheme I know is the Armpit <http://armpit.sourceforge.net/>

<comment><USER7> Java was _designed_ as an embedded language for a set-top box.

<comment><USER4> True, but that was oak (oak 0.2 langage spec is here <https://duke.dev.java.net/green/OakSpec0.2.ps>).

BTW this specs put some lights on some java behavior: <http://www.devx.com/Java/Article/10686>.

</comment></comment></comment></comment></comment></comment><comment><USER8> Regardless the merits of the language itself, the culture of Forth has some serious issues that cause me to doubt that a skilled Forth programmer truly has a development speed that is a multiple of that of a skilled C programmer. Cf. this advice from _Thinking Forth_ :

"Some Forth practitioners advocate storing source code in variable-length, named text files, deliberately emulating the approach used in traditional compilers and text editors. This approach may become more and more common, but its usefulness is still controversial.

Sure it's nice not to have to worry about running out of room in a screen, but the hassle of writing in a restricted area is compensated for by retaining control of discrete chunks of code. In developing an application, you spend a lot more time loading and reloading screens than rearranging their contents.

"Infinite length" files allow sloppy, disorganized thinking and bad factoring. Definitions become longer without the discipline imposed by the 1K block boundaries. The tendency becomes to write a 20K file, or worse: a 20K definition."

(from page 144 of the 2004 edition)

<comment><AUTHOR> There are some developers that prefer the block-oriented approach of creating Forth code. Remember that Forth is a dynamic language, so there is a tradition of viewing the system as an image (similar to Smalltalk), instead of a bunch of static files saved on a file system. They achieve this by creating small blocks of code that are dynamically loaded as necessary.

This doesn't mean you can't create Forth programs from standard text files. All modern Forths work this way, providing blocks only as an additional feature.

<comment><USER8> My main beef was with the last bit - ""Infinite length" files allow sloppy, disorganized thinking and bad factoring. Definitions become longer without the discipline imposed by the 1K block boundaries. The tendency becomes to write a 20K file, or worse: a 20K definition." This reeks of Stackholm Syndrome, where having toiled under the limitations of a system for some time and developed workarounds and jerry-rigs* to get by them, one begins to view them as strengths for no other reason than their familiarity.

If nobody thinks like this any more though, congrats on escaping what is normally a sure route to smug weenie-ism.

*Eg. later in the same section, Brodie suggests defining constants associated with block numbers as a sort of ersatz filenames

<comment><USER9> _Stackholm Syndrome_

Nice.

</comment></comment></comment></comment><comment><USER10> Also, Forth can compile itself into a new compiler!

<comment> loup-vaillant And so can C. And almost any language out there with a reasonable implementation. We call that "bootstrapping".

Did you mean something else?

<comment><USER10> True, but it's a bigger undertaking in C.

</comment></comment></comment><comment><USER11> The linker and makefile are not at all part of the c standard.

Also, I assert that any "A versus B" will almost invariably favor A.</comment>


Haste is a form of violence. - <AUTHOR> http://www.37signals.com/svn/posts/1026-haste-is-a-form-of-violence <comment><USER2> Slack is a form of theft.

</comment><comment><USER3> I suffer from the same problem, so the article was a good read, but, strangely, the comments were even better. I even slowed down enough to read them all.

</comment><comment><USER4> redefining words at random is a form of bad thinking</comment>