aufreak3

Wasn't Dileep George part of Numenta?

This is likely the meta-est thing Gruber has written - except perhaps writing the Markdown manual in Markdown.

Apple event happens, random sites write various things about the announcements, Gruber waits for the noise to settle and writes a piece mostly in favour of Apple.

And you know what? It works! (No sarcasm)

- Print to PDF. With articles from online magazines, choosing "Print" to get all pages on page and then Print to PDF is my current preferred snapshotting. It is easily searched using spotlight on my mac.

- Instapaper still works well for me.

- Of late I've also been using archive.is to snapshot pages. This is useful for article permalinks to cite for research, in case the original url disappears or its content changes after the conclusion of said research.

General note to OP and others relying on MDN - if you do spot errors, please remember that it is a Wiki. You can just hit the "edit" button and fix it yourself .. and you'll be helping a ton of others along the way.

Thanks for responding.

By "ui front end at the back end", I was referring to the OP's suggestion to use nodejs as the entry point which the talks to the "real" back end.

I'm interested in real time collaboration where message connections between connected users are easiest held in a shared data structure to reduce latency. I've on occasion mangled this data structure unintentionally without any feedback from JS before deployment. If I'd had some static checking, these problems would've been easily avoided. Hence my fear.

edit: to be clear, my "fear" only applies to languages like JS and untyped racket at the backend. Not of backend programming per se.

Rgd my example, so ... given that I would needs CORS support, the browser->nodejs->backend division of labour that the OP is suggesting doesn't seem workable for such a file upload case.

I code a lot in JS these days and I find this divide suggestion interesting. Though I'm proficient in JS, I don't trust myself enough to write server stuff in JS - for ex: while an accidental global access likely has limited consequences on the browser side, it can result in data cross talk between users on the server side. So I do prefer the help offered by some static typing. Even go feels better, Haskell would rock, typed racket also looks awesome from this perspective.

To my main point, I'm unclear how such a split would actually work in practice. For example, if I have a file upload to do from the client, should that get streamed to the "ui front end at the back end" (whew!) or directly to the "real back end"? Are there any fundamental architectural problems with client side code pulling together an application by accessing a number of independent REST services without going through such a "front end at the back end"?

Thoughts/suggestions?

Google's NaCl set out to solve this same problem (pretty much), but I'm beginning to think Grun's Arc might completely shadow Google's work here for many reasons, not the least of which is total flexibility of development environment (i.e. no need for a special "sdk", except to communicate with the browser).

Dear Grun - Go you!

I did not comment on the implementation. I said, in effect, that an animation would affect the perception of the start/stop times and using one would therefore be a bad idea in this case.

> The similar looking button in the Timer screen DID give visual feedback when pressed. In a consistent UI, either this button would do too, or neither would.

Visual feedback needs to serve a purpose. This is a stop watch we're talking about - one that shows time in tens of milliseconds, which is less than one frame interval at 60fps. Any animation done would hinder the function of the stop watch and raise ambiguity about when the stop watch actually started and stopped. So not using an animation is the right thing to do here. If they'd gone for consistency in this case, it would've been "foolish consistency" [1].

[1] "A foolish consistency is the hobgoblin of little minds." - Ralph Waldo Emerson

edit: typo fix.

Why not go the whole nine yards and say "we're going to be using iOS on the desktop soon"?

At first, when I read the post's title, I thought Apple had created iMessage for Android and put it up on the Play store. Now, that would be a really big deal because that would mean that Apple finally gets that communication is between people and not one family of computers. The current Apple attitude to communication and sharing (like PhotoStream) is akin to a telco saying you can only call other users on their network, or Google saying you can only send and receive emails from other gmail users. Apple finally getting communication would be a really big deal.

I saw, to my great disappointment, that the program was not Apple's.

Btw Prof. Martin Henz was one of the major contributors to the design of Oz.

> Besides, have you tried Android recently? You might be suprised to discover that Android is better.

.. not yet for music apps. Even Google folks admit that [1]. This really can't wait any longer. Where is Garage Band for Android please? ... and to those saying "you can't complain only about music, look at the games, todo lists, blah blah", sorry music IS my domain and that's the only thing I care about.

[1] https://www.youtube.com/watch?v=d3kfEeMZ65c

Can you please clarify with some references where you got that from .. and whether that trend you mention is not because the revenues on iOS are also going down?

It looks to me like the trend on the iOS app store is also downwards to the cheap/free end - i.e. a race to the bottom. My paid niche app ($5) used to get a couple of downloads a week. I made it free for one week, during which I got about 500 downloads. There is interest, but no willingness to pay for it. I think the overall statistic of $5B paid to devs with about 500,000 apps on the app store gives an average of $10k per app. So one app can get you, what, one month's salary? Even that's rosy I think, 'cos the distribution is not uniform but a long tail exponential, which means the me-the-solo-dev is more likely to fall on the tail than near the elite end of the exponential.

Bottom line is that I'm beginning to think that a mobile-only company strategy is likely to be doomed. Anyone thinks otherwise?

The ones in this all feel more attractive - http://www.telegraph.co.uk/technology/reviews/9943578/Electr.... I think that's because of the segway effect - it looks weird to be riding a vehicle while appearing to not "do" anything.

On the segway effect, I wonder what would've happened to the product had it been designed for rough riding and stunts first before it was targeted at the commuter.

I'm beginning to wonder whether "support for 2FA" is a way for companies to get your telephone number into their database. Does using an authenticator application also provide the same information to the company?

For me, the real indicator that progressive enhancement is "dead" was that as I began reading the post, I was left wondering "what the &*%^ is this progressive enhancement that he's declaring as dead?" until, pretty much, when I finished the post.

Technical: The "break out the notebook" is close. Use the scientific method in your debugging. By this I mean form hypotheses about the bug and test them ... rinse and repeat. The important bit here is that you keep track of the hypotheses you come up with and the way you tested them. This track serves as proof of your work that you can ask for a co-worker to examine for its effectiveness. You don't need to do all the hypotheses testing yourself if your hypothesize about some part of the system that a colleague is more familiar with. No shame in asking for help here, even if it is repeatedly denied.

Managerial: Ask how to improve. Are bugs being prioritized properly? If some level of management is not involved in prioritizing bugs, ask them to take and look and prioritize. It is not enough for you to think "hmm .. no hurry to fix this bug for the next release 'cos its a very obscure case and there are these other important ones to tackle first."

Self management: If you're overwhelmed by many bugs and are zombied about where to begin or touch next, just pick whatever looks the easiest to fix and fix it, irrespective of priority (and loop that). This at least gets some momentum going. A management that expects bugs to be fixed exactly in the prioritized order is ignorant. That's not how systems fail. What might be thought of as trivial might turn out to be very significant, and vice versa.

It would be nice if the article had some absolute minimal details on how about 10 terrawatts of power[1] is going to be beamed down, and if that's a no brainer, over what area is it going to be beamed down.

[1] Based on energy consumption figures from http://en.wikipedia.org/wiki/World_energy_consumption

The memory tax for GCed language was written up in [1]. The blog post [2] (which is a great read that I recommend) summarized it like this - "As long as you have about 6 times as much memory as you really need, you’re fine. But woe betide you if you have less than 4x the required memory."

[1] http://www-cs.canisius.edu/~hertzm/gcmalloc-oopsla-2005.pdf [2] http://sealedabstract.com/rants/why-mobile-web-apps-are-slow...

> I like all of these tools but can't help feeling I'd be more effective if I could just get at the underlying code half the time (in cases where that's not an option).

I've seen novices do cool stuff with Max without thinking that. Perhaps this feeling comes more from familiarity with textual coding than something fundamental about textual coding.

On the other hand, we keep saying "a picture is worth a thousand words", but here we are writing blog posts in gobs! That suggests that text is what we train for, and is what we might be most effective with in the future too.

Extract from the abstract - "People consistently report that sound is the most important source of information in evaluating performance in music. However, the findings demonstrate that people actually depend primarily on visual information when making judgments about music performance."

Not too surprising a result. It would've been interesting to propose a model of cognition that might account for this effect. The "embodied music cognition" school might, for example, propose something like this -- "the brain needs to process the inputs and reconstruct the body movements required to produce the sound so that the music can be experienced in the listener's body. This is less work when given the visual signal alone than when given the audio signal alone."

Also, I was curious about what instruments or vocal music the competitions were about, but the paper doesn't talk about that (in my quick scan through). I venture a prediction that for vocal music, the audio alone is likely to be a better predictor than the visual alone, but for piano and violin the visual may show this effect.

Another point that struck me was that the experiments featured the performances of only the top-three finalists in competitions. These are already performers who the judges in those competitions selected as good, suggesting that perhaps these performers are not very distinguishable by their sound alone anyway. It would've been better to also include non-top performers to see how the audio-alone and visual-alone inputs fare when they are also included. Then again, stating the result as (simplified) "among top performers, the visuals are important" reduces the surprise factor :)

> an amount that would rid the hungry part of the planet for 2 years

I meant "rid the planet of hunger for 2 years"! What a typo!

It feels odd to lift this to a problem with an "ism" and ignore the people behind it. The problem I have with the original article is that it seems to think that innovation and markets consist of investors, entrepreneurs and nasdaq/snp.

So here I have a "theory 10" -

THE PEOPLE go "meh" when faced with something like Hyperloop, but are excited to tell their 500 friends what they had for lunch at the push of a button. Hence the investors go "who cares?" and hence the "entrepreneurs" go "hmm, I better think about more efficient lunch sharing".

People need to be told something like "folks we're going to throw $60B of your tax money (an amount that would rid the hungry part of the planet for 2 years) at a transport system that you won't even be proud of, won't be that much faster or safer than air travel" to get a non-meh reaction to hyperloop. Even then, fast travel between SF and LA is, perhaps, a solved problem according to common folks - just fly already. Heck, you don't even have an interesting view during the trip according to the proposed designs.

On the other hand, post after post on HN talks about cool materials, 3D printing, maker culture, break through science, etc. So funded innovation is happening, it would seem. Just not in the main news very much perhaps.

And here is a "theory 11" - the common folk may actually <shock!> be satisfied with the status quo? Innovators often talk about a persistent dissatisfaction with the status quo as motivation for their work. On the "eastern" side of the planet, this dissatisfaction itself would seem to be the one that needs addressing .. i.e. being happy and contented is not the problem, but the lack of them is.

> ... the issue is that a program has at least two different logical structures: its lexical organization in text, and its dynamic organization in time.

That's a concise way to put it and I'll certainly remember and reuse it! Did you come up with it or did you come across it somewhere?

Though true, the "banners" aren't always obvious. Some folks may have a complementary mission. The golang authors are perhaps not directly working to "organize the world's information", for instance and their banner would read "making it easy to build simple, reliable, and efficient software".

It is still, a nice exercise to do it though ... and I might turn mine into an LLC anyway :)

> "Folks like Musk" are smart enough to know that the progress of humanity, the great and meaningful leaps of technology to strive for, are accomplished by people solving those hard problems under a common banner.

That's an interesting aspect of their work you point out. It made me think about describing my "banner" and add it to my HN profile.

It would be cool if we can all identify such "banners" under which we work in our HN profiles. Note that the banner doesn't have to be a technological breakthrough. In my case, for example, I wish for cultural impact.

    Computing is in a sad state today, but not because of
    fucking callbacks. It's in a sad state today because 
    we're still thinking about problems on this level at all.

The unfortunate part about thinking about problems is it that problems are relative - i.e. they are problems only relative to a context. Nobody even in the tech world has a clue how solving a simple problem just to satisfy some intellectual curiosity can affect life on the planet. What meaning does Wiles' proof of Fermat's last theorem have on the part of the world that's sleeping hungry every night?

The stuff we're talking about here has irked some pretty decent brains enough for them to go out and make ... another textual programming language.

Folks like Musk are an inspiration indeed for boldly thinking at the high level they do and seeing it through. However, that's exactly what's easy for press to write up on. Stuff like the moon speech is what's easy to communicate. It is also simple to attribute some great deed to one of these great "visions". But behind each such vision lies the incremental work of millions - each of it, I say, worth every penny - unsung heroes, all of them.

On a related point, not all the time where we've heard a call to greater action do we see the ability in those folks to imagine how that might come about.

edit: typos.

(Don't mean to divert this thread from Kal, but this is on the topic of "callbacks are bad" etc.)

For some time now, I've been accumulating async patterns I've needed when writing JS code in my monadic IO.js library[1]. The aim of IO.js is to provide higher levels of thinking about sequences of actions without worrying about whether they are async, and with a rich set of error management tools (for ex, exceptions are turned into recoverable conditions in IO.js).

The crux of the "callback hell" problem is, contrary to what many have claimed, is not the nesting that results when the callbacks need to be called in temporal order. That much is straightforward to deal with. The "hell" rears its head when you need to coordinate multiple such sequences that are running concurrently. The composable actions you get from a monadic treatment combined with CSP-style channels, are an expressive framework to build abstractions on (tldr - Haskell's implementation is awesome!).

For illustration, the framework in IO.js is flexible enough to implement a node.js web server that can express PG's "Arc challenge" concisely (though that challenge is practically obsolete). Take a look at [2].

For a simpler example, `IO.trace` is a straight forward way to generate a trace dump to console of a sequence of asynchronous actions. You don't need to "enable trace" for an entire app. You can choose to trace only a particular sequence. This is pretty neat when debugging. Stack traces are useless when dealing with async processes anyway.

[1]: https://github.com/srikumarks/IO.js [2]: https://github.com/srikumarks/IO.js/blob/master/examples/arc...