Why don't you just rewrite it in X? - <AUTHOR> http://nibblestew.blogspot.com/2017/04/why-dont-you-just-rewrite-it-in-x.html <comment><USER3> Do you really want to convert the lines one-to-one? This seems pretty wasteful. Surely a better way is to just do step 3, drawing inspiration (and copying where appropriate) from the original code based on the _features_ rather than the structure of the original code.

For example gtk-doc generates documentation from comments in c code. I'm guessing there is some perl code to parse c code, which i would substitute for the great 'pycparser' library. With this method you would copy the existing code, fix it, then throw it away.

The methods to generate HTML from the comments is likely a lot of code. Sure, you could copy whatever method the current perl code does... Or you could substitute a lot of it for Jinja2.

Perhaps these examples are incorrect in the context of this specific project, but i don't see the point in copying the lines one for one. Copy the _meaning_ of the code into idiomatic python from the get go, and test the output against the known good perl code. I doubt perl code copied one for one is ever going to be idiomatic python code, so why bother, especially if it takes so long?

Edit: Yeah, tests are good. No tests are bad. Having a complete understanding of the code doesn't require translating it line-for-line. Re-writing a project in a different language is a breaking change, but in the context of this project your initial tests could be (for every bit of C code you can possibly find that has gtk-doc comments):

       > gtk-doc.py > a
       > gtk-doc.pl > b
       > diff a b

After you can find no differences, great, release it as an alpha or beta. People can then feed back any internal, weird quirky behavior they depend on. Rinse and repeat.

My point is spending 1000000000 hours hand-converting perl into python then again re-writing it into idiomatic python so you can catch any theoretical small perl-specific edge case in what is effectively a complete rewrite and a major version change is IMO a bit pointless, especially when converting Frankenstein python-perl into idiomatic Python may result in deleting large parts of the said slow-to-convert code.

<comment><USER4> It is Perl code to parse X using regular expressions.

This is _always_ the worst kind of Perl code imaginable to try to tinker with.

It will be fiddly. It will have exceptional cases piled upon exceptional cases. It will have hideous numbers of undocumented corners.

All because it isn't a real, _actual_ , fscking parser.

Because we don't really need a parser for this, right now, do we, really?

Yeah, this is one of those cases where "Do the simplest thing" breaks down horribly and very rarely does someone have the wherewithal to apply 2x4 cluebats to the people who _persist_ in writing parsers with regular expressions.

Yes, I have done so (in Python actually). However, my code has a little "counter" in the comments along the lines of "You have debugged a regular expression in this code: <n> times. Use a real parser you idiot."

It is depressing how large I have let that number get before I actually pull my head out of my ass.

<comment><USER5> Yeah, proper parsers are actually super easy once you are comfortable with them and take much much less time than a pile of regexps. Like higher-order parser combinators. You can implement them for most languages in no time and then just construct your parser from a few basic higher-order primitives: regexp tokens, alternations, sequences and repetitions.

Getting there though takes a bit of practice, from recursive descent parsers to parser generators.

<comment><USER6> are you handwriting your parsers or using some kind of parser generator typically?

<comment><USER7> I usually just pull a Parsing Expression Grammar library in.

</comment></comment></comment></comment></comment><comment><USER8> > Manually converting code from one format to another is the most boring, > draining and soul-crushing work you can imagine.

It's not that bad. I've converted many programs from one language to another. For example, in the 1980s I converted the FutureNet DASH schematic editor from 16 bit x86 assembler to C (so it could be ported to other platforms). I converted my game Empire from BASIC to Fortran to PDP11 assembler to C. I've converted parts of Optlink from assembler to C. I've converted a lot of the DMD compiler from C++ to D.

The conversions I've done have all produced valuable results.

It's actually rather enjoyable work, but I like obsessive detail work.

<comment><USER9> There's a certain breed of developer (me included, and probably also Walter above) who really like refactoring and porting tasks which others would consider soul-crushing.

When the codebase has evolved for a really long time, and you can see the different coding styles of different generations of developers, you get to feel like an archeologist or a geologist who's digging through multiple layers of rock.

<comment><USER10> I often use the archeology analogy to describe my work to others. I like how you become familiar with your predecessors and their strategies for solving problems. It's a way of getting to know them even if you never actually get a chance to meet them.

Some of the best parts:

1\. Trying something totally new only to realize that one of your predecessors has attempted to do it before. Bonus points if you can solve it this time around.

2\. Digging around and realizing that your predecessor was in fact yourself.

3\. Randomly encountering one of your predecessors in real life and becoming instant friends while reminiscing about old times. ;-)

</comment></comment></comment><comment><USER11> Applications can accumulate 'business cruft' as much as they do code cruft. Things were built for one reason, then were hacked to do something different. I.e:

"Note that GTK-Doc wasn't originally intended to be a general-purpose documentation tool, so it can be a bit awkward to setup and use."

So pure 'rewriting' is not usually what you want. You want the same functionality but in an easier to use and maintain package. The approach I usually take is finding a well supported project that is already solving the same problem and extending it to solve mine.

In this case, a documentation generator seems a suspect thing to rewrite as there are already many of those out there. I'd look at extending Doxygen to support GTK-Doc's syntax (or automating a GTK-Doc to Doxygen translator).

Anyway this is an approach i've used with some success before. It can't always work, sometimes the problem you're solving is fairly unique or sometimes the available open source projects don't have much better code bases than the one you're trying to replace.

As far as "Chesterton's Fences" I say tear 'em down (but instrument and be prepared to rollback). Sometimes the only way to tell why something exists is to remove it. This is effectively just paying the price of technical debt - <USER2> cost of doing business. The higher cost is to live in a world littered with rusting fences.

</comment><comment><USER12> Rewrites lead to all those wonderful feature-removing and compatibility- breaking scenarios that you see in "new versions" of software. They can really suck for consumers and that is reason alone to be much more cautious.

On the other hand, you can't expect to keep your entire software world standing still. At some point, the operating system or even the _hardware_ will make it really hard to keep an old code base going, and you'll have to do very creative things just to keep it all working. And no, you typically don't have the freedom to force people to use some ancient system for your benefit; you're not in a vacuum, your users are doing lots of other things and their _other_ apps are going to keep moving even if you don't.

You will reach a point of real regret if you don't spend at least some time to move code to more modern concepts/languages/libraries. It doesn't have to be 100% at once, nor does it have to be an outright replacement; leverage multi- language bindings, testing frameworks, etc. and beta users to make progress. And whatever you do, never release a "MyApp 5" that is a completely different code base than "MyApp 4"; this just aggravates people when nothing works quite right. You need MyApp 4.1, 4.2, 4.3, 4.4, etc.

</comment><comment><USER13> _The cURL project consists of roughly 100 thousand lines of C code according to Ohloh._

You do not have to when you choose a more modern safer language that can export functions with C linkage and can trivially call C functions. You decide to use a new language and write new functionality or functions that have to be rewritten anyway.

For instance, gcc first switched to g++ as the default compiler and started allowing a subset of C++. Firefox started using Rust here and there where/when it makes sense. There are countless other examples.

I think very few folks would actually propose converting a 100KLOC or an MLOC project to another language. (Though Go did did it with their runtime and compiler :), though that's quite a special case).

<comment><USER14> Yup, I'm in the middle of porting something over to Rust that's C based and this works _really well_. You can stub in the Rust parts piece-by-piece via FFI and incrementally bring up the port testing along the way instead of a big-bang integration at the end.

</comment></comment><comment><USER15>
                  Should I rewrite X in Y?
                     /               \
                    /                 \
                   /                   \
                  |                     |
                  |                     |
      Am I doing this just        Is my team full of
      for the features in Y?        experts in Y?
                  |                       |
                 Yes                  ___/ \___
                   \                 |         |
                    \               No        Yes
                     \               |         |__________
                      \              |                    |
                       \         Are there any experts    |
                        \          on my team in Y?       |
                         \           |           |        |
                          \          No          |        |
                           \         |          Yes       |
                            \        |     _____/         |
                             \       |     |              |
                              \      |  Did they          |
                               \     |  propose it?       |
                                \    |     |      \       |
                                 \   |    Yes      |      |
                                  \  |     |       No     |
                                 Don't rewrite.    |      |
                                     |             |      |
                                     |           Were you going to
                                     |           rewrite it anyway?
                                     |              No       |
                                     |______________|       Yes
                                                             |
                                                              \
                                                               \
                                                                \
                                                                 \
                                                                  \
                                                                   \
                                                                    \
                                                                     \
                                                                      \
                                                                       \
                                                                        |
                                                                 Think about it.

</comment><comment><USER16> Although LOC metrics are always questionable, converting code from one language to another at 100 lines/hr seems absurdly optimistic to me.

<comment><USER17> Definitely seems completely unrealistic for any conversion involving idiomatic Perl. I could see it being possible for Java to C# or vice versa.

</comment></comment><comment><USER18> A nice example of rewrite in X is the rewrite of 0install in OCaml from Python [0]. A very systematic approach, replacing code gradually. There are multiple posts on this and they were discussed here a few times.

[0] [http://roscidus.com/blog/blog/2014/06/06/python-to-ocaml- ret...](http://roscidus.com/blog/blog/2014/06/06/python-to-ocaml- retrospective/)

</comment><comment><USER19> ``Every now and then the code used "fancy" Perl features. Converting those parts was 10x, 100x, and sometimes up to 1000x slower.''

That is why, when I run an engineering team, I constantly push back against "clever" or "fancy" stuff. Engineers love that stuff, eat it up. I get it, it's fun. But when they move on to something else and a mere mortal has to maintain, fix, or convert it, the cost of that clever stuff becomes apparent. I've had to be that mere mortal and I can assure you it is a miserable experience.

I've often thought that one of the most useful things about me is that I'm not smart enough to be that clever, I like simple, obvious code. It's a little bit of a lie, I'm smart enough, sort of, to be that clever but it's a lot more work. And I know that any code that is more than 6 months, doesn't matter if I wrote it or someone else wrote it, it always feels like someone else wrote it. And man, do I love it when that someone else went for straightforward rather than clever.

<comment><USER20> The corollary is that entire languages and libraries dedicated to doing things cleverly, even if they are technically usable, are often bad choices.

But unless you can point at benchmarks, nobody will listen to you, and the better choice may even be described as blub.

</comment></comment><comment><USER21> Summary:

> Manually converting code from one format to another is the most boring, > draining and soul-crushing work you can imagine.

> we can estimate that a sustained rate of conversion one person can maintain > is around 100 lines of code per hour

> This gives us a clear answer on why people don't just convert their projects > from one language to another: There is no such thing as "just rewrite it in > X"

</comment><comment><USER22> The answer to the question "why don't you re-write in X" is the question "what benefit to the client would this create and is it worth the effort?"

<comment><USER16> The other answer is "great idea, please send your pull request when it's ready"

<comment><USER23> Don't do that unless you actually intend to accept the pull request. Saying this was a way of telling someone to go away is not right.

<comment><USER16> If the demand is "you should rewrite in X" from some random user I think it's a perfectly fine way to say "go away."

If there's some indication that the request is from someone qualified _and willing to help_ , maybe you give it more consideration.

<comment><USER22> I get what you're saying. A brilliant idea that someone isn't willing to put any effort into really isn't likely to be brilliant.

I'll ask someone to write a one page summary of the project goals. Similar result.

</comment></comment></comment></comment></comment><comment><USER24> I will smack the next person that says "because x is more productive than y". That's an excuse to scratch an itch to using some latest popular framework or language. If that was actually true, it would be easily measureable with a double blind test. What's usually true is "rewrites (in any language) are more productive than the original team, because now we actually understand the requirements"

<comment><USER25> Easily measurable? With what metric?

Or are you implying that, because you don't know a measurement that has a causal relationship with it, that you can't be improving it?

<comment><USER24> I'm not the person making the absurd claim "x is more productive than y". I've merely pointed out their lack of proof for such a ridiculous statement.

</comment></comment></comment><comment><USER26> Solution: reply to bug report, "please reopen when you have finished that pull request, complete with unit tests", then mark as WONTFIX.

<comment><USER19> Have an upvote, that's brutally honest.

</comment></comment><comment><USER27> People mention that said rewrite needs to have some immediate benefits. I actually like rewrites where no obvious changes are visible. These are rewrites, where one anticipates future problems and does this work preventively.

Three projects come to mind. 1) Rewriting a set of internal libraries from Python 2 to 3, because it's better to do early on, before compatibility problems arise. 2) Rewriting an ancient cli tool written in C++ into Go (nobody here knows C++, some speak Go). It has worked for years untouched, but you never know. 3) Rewriting a Fortran modelling tool into Go, because while people know Fortran, it maintenance costs are annoying and adding functionality is difficult or impossible.

In all cases, no functionality was gained or removed by the rewrite, but future pain was spared thanks to these endeavours.

<comment><USER28> You would not consider all of these maintainability improvements to be immediate benefits?

<comment><USER29> "maintainability" by DEFINITION is not immediate.

</comment></comment></comment><comment><USER30> So disappointing! I thought I was going to read a call to arms to stop building systems as web applications, and move to the venerable window protocol.

</comment><comment><USER31> I've thought about codebase conversions quite a bit while working on the decaffeinate project [1] to help speed up the conversion from CoffeeScript to JavaScript at my work. I've also given some advice on different strategies [2][3], although some of that is specific to the CoffeeScript -> JavaScript problem, which is easier than other situations since the languages can interop easily and are so similar.

The "1 hour per 100 lines" rough number from the article is probably optimistic, at least in some settings. As one example, a coworker of mine manually converted a complex 500-line file, and it took two days to convert, one day to go through code review, and introduced two bugs.

Probably any reasonable strategy needs to find a way to work incrementally and focus on the most valuable parts first. For example, if you focus your efforts on converting files that are the most active, then you may be able to culturally move your team to the new language even if there's still a lot of legacy code in the old language.

In terms of the three phases from the article, I'm hoping that decaffeinate can become stable enough that it completely automates step 1 and avoids the need for step 2, but step 3 will always take time. In my case, my plan is to do a fully-automated conversion over the ~150k lines of code (broken up into maybe 10 chunks), call the style issues tech debt, and slowly clean those up as we work through each part of the code.

[1] [https://github.com/decaffeinate/decaffeinate](https://github.com/decaffeinate/decaffeinate)

[2] [https://github.com/decaffeinate/decaffeinate/blob/master/doc...](https://github.com/decaffeinate/decaffeinate/blob/master/docs/conversion- guide.md#converting-a-whole-project)

[3] [https://github.com/codecombat/codecombat/issues/4276#issueco...](https://github.com/codecombat/codecombat/issues/4276#issuecomment-291954686)

</comment><comment><USER32> > There is no such thing as "just rewrite it in X".

People do it all the time, every day. Code has side affects and features you don't necessarily need. NIH is usually, "don't need most of that here" or "language X would do it cleaner/with-less-bugs(tm)", which is different wording for the exact same reasoning. So I'm not sure why the focus on this line-by-line conversion that nobody would choose to do.

On the other hand, rewriting my java chat server in erlang (in 2008) went from 5000 lines to about 500. That was a point by point functionality conversion of my own project, for existing java clients.

</comment><comment><USER33> For any reasonably complex codebase the complete rewrite is not possible. The first several versions of the rewrite will inevitably lack the functionality present in the original version and have more bugs compared to the original version. In my experience, you can only achieve the feature and quality parity if you continue to work on the code long after the initial rewrite.

Take for example a rewrite of coreutils in Rust. The LS utility in original C ([https://github.com/goj/coreutils/blob/rm-d/src/ls.c](https://github.com/goj/coreutils/blob/rm-d/src/ls.c)) and its rewrite in Rust ([https://github.com/uutils/coreutils/blob/master/src/ls/ls.rs](https://github.com/uutils/coreutils/blob/master/src/ls/ls.rs)) are quite different. The rewrite doesn't implement half of the original options. It's reasonable to assume that not many people even use the rewritten LS, so it contains bugs that the original widely used version doesn't have.

The bottom line is that if you want to achieve comparable quality and features, the time and effort invested in rewriting some code is almost the same as the time and effort invested in creating that code from scratch.

<comment><USER34> > For any reasonably complex codebase the complete rewrite is not possible.

If it's reasonably complex but also reasonably well designed, it can be completely but incrementally rewritten by module, without the problems you describe.

OTOH, those are usually the things that there is less pain with the existing system driving by a desire to rewrite. Chances are if you want to rewrite it, it's going to be a nightmare.

</comment></comment><comment><USER35> At least where I work, switching from perl to python happens when the guy that wrote the perl leaves the company and nobody else wants to touch it.

Every time I've been handed a perl script to 'fix', if I think I'm ever going to have to touch it again, I rewrite it in python. Our perl code is a migraine-inducing mess of unmaintainable punctuation vomit.

</comment><comment><USER36> Generally you'll be porting to a more expressive language so you'll be hopefully removing lines overall.

</comment><comment><USER37> When Red Hat converted our OVirt VM/cloud management tool from C# to Java, it was done using an external tool (I think using a tool written by Tangible Inc). This converted the code mostly automatically, with some manual tidying up afterwards. It was about 100K lines of code, and I believe the conversion took about 6 months (while existing development continued). The project was ultimately successful. It is now a respected open source Java project and widely used and sold.

More on the conversion here: [https://lpeer.blogspot.co.uk/2010/04/switching- from-c-to-jav...](https://lpeer.blogspot.co.uk/2010/04/switching-from-c-to- java.html)

</comment><comment><USER38> An interesting recent example of successful rewrite was moving the Go compiler from C to Go. They wrote a transpiler from the (very disciplined) C code to Go, and then have been slowly idiomaticifying the code since.

<comment><USER39> You have to realise the scope and context: the Go compiler rewrite was done by people who were:

* _working on the codebase full time_

* _intimately familiar with the quirks_

* relying on _the transpiling to be mostly automated_

IMO as far as rewrites go, that's a pretty tall order.

I'm personally contemplating a rewrite of an old project (mostly due to GTK having gone downhill in past years), and harbour no misconceptions about the scale of the effort. It's only about 10k lines of python, across two different projects, but if it takes me less than 2 months (of _active_ spare time work), I will be very much surprised.

<comment><USER38> Oh, totally. Very much agree.

Out of curiosity, what's the app, and what UI toolkit would you port to? (And would you stick with python?)

<comment><USER39> The app is my old online poker tracker, written with pygtk.

I am tempted to move to Qt instead, and for a number of reasons will probably try Go instead.

1) As much as I have traditionally disliked Go's dependency management, with the vendoring support it can be made reasonable

2) I never got python's threading to work properly, which made the UI unresponsive when dealing with database operations; and threading in python is a hack anyway

3) I believe ( _cough_ hubris!) that I can simplify the internals by further splitting the architecture

One of the best ideas I ever had was to forego all attempts at subprocess management and just go for DBus and its process autolauncher instead. I mean, have you ever tried to make a fork/exec work from within GTK software without causing X hiccups?

<comment><USER38> Cool stuff. I think the UI library story is still pretty raw, but I've done several backend applications in Go, and I'm pretty much in love. It's a very well-engineered language with a strong appreciation for real-world practicalities.

</comment></comment></comment></comment></comment><comment><USER40> I was thinking many of the manual changes in step one could have been done through a program or script freeing you to help with phase 2/3\. Rewriting without introducing something new: features, stability, cost reduction, easier to maintain, etc is usually a waste of time but could be a fun if you are using the exercise to learn.

</comment><comment><USER41> I mostly agree with the sentiment of this article but converting a bunch of shell, Awk and Perl into Python 3 is probably a good idea. It's not like Python is some newfangled untested language. Making the build system portable and easy to use is _really_ important for an Open-Source project.

</comment><comment><USER42> The Eighth Dirty Word - "Just"

[https://blog.forrestthewoods.com/the-eighth-dirty-word- just-...](https://blog.forrestthewoods.com/the-eighth-dirty-word- just-2d2386850cda)

</comment><comment><USER43> I'm not sure that large organizations are soon going to grok this trick to save them millions of dollars and tens of thousands of hours of meetings and employee debate. Anyhow, here it is:

 _Only allow coding that lets the company change its mind._

If you choose a language which has conservative, well established features, devoid of parsing quirks, and you enforce very strong coding standards per- team, then it is possible for every program to be composed of per-team idioms which can then be automatically translated to idiomatic code in a different language through isomorphic changes.

You will still need to have a project to port your program, but instead of trying to outstrip the rate at which production code changes, the effort is instead going towards perfecting a software machine which translates the program in an instant. By doing it this way, you can always upgrade your technology without slowing down the production team, or without trying to outstrip a production team which is already trying to move competitively fast.

I know this trick works. I've done it. What makes this challenging:

        - Management will be afraid of this, because it's unconventional
        - Teams may not want to or be able to usefully adhere to such standards

But if your organization can pull this off, then you will be able to upgrade technology without slowdowns in implementing new business functionality. If organizations can pull this off, they can "just rewrite in in X" any time they want to! ( _And_ wind up with idiomatic code in the new language! If you are trying to do this, and not winding up with idiomatic new code, then you have tackled this at the wrong level of abstraction, possibly being hampered by a team which didn't have suitable coding standards.)

(Think of it this way: Do you think it's easier for a very capable team to outstrip your ability to keep up with features, or your ability to keep up with new programming idioms? If you team is competent, they will be _quickly_ producing new features, but _seldom_ producing new coding idioms!)

</comment><comment><USER44> Another flavor of this topic is the following: just convert from database X to database Y. It should be easy, they are both SQL.</comment>


The iPad Pro - <AUTHOR> http://daringfireball.net/2015/11/the_ipad_pro <comment><USER4> "The entire x86 computer architecture is living on borrowed time. It's a dead platform walking. The future belongs to ARM, and Apple's A-series SoC's are leading the way."

I can't believe that lines like this are still being written. I devoted the better part of a career to successfully debunking this idea that ARM has some sort of magical power efficiency advantages over x86. I can, however, console myself that such claims are exceedingly rare. Most people who lived through the "RISC vs. CISC" platform wars and made such claims conceded defeat a long time ago.

Anyway, I addressed this issue in one of my last CPU articles for Ars back in 2011:

[http://arstechnica.com/business/2011/02/nvidia-30-and-the- ri...](http://arstechnica.com/business/2011/02/nvidia-30-and-the- riscification-of-x86/)

Quote:

"It's also the case that as ARM moves up the performance ladder, it will necessarily start to drop in terms of power efficiency. Again, there is no magic pixie dust here, and the impact of the ISA alone on power consumption in processors that draw many tens of watts is negligible. A multicore ARM chip and a multicore Xeon chip that give similar performance on compute-intensive workloads will have similar power profiles; to believe otherwise is to believe in magical little ARM performance elves."

Also, I think that benchmarks run in this article for the purpose of comparing the iPad to the MacBook are pretty worthless. I don't have a good answer for how to comparatively benchmark them, or even if that makes sense. Meaningful cross-platform benchmarking is really hard, just ask the SPEC people.

Finally, in the article linked above, I predicted that the only way ARM is a threat to x86 is because it's cheaper, and that if ARM can get within something like 2X the performance of Intel's higher end CPUs, it might have a shot by virtue of being widely and inexpensively licensed.

Anyway, the TL;DR here is that those benchmarks say more about the software stack (the benchmark software included) than the do about the CPU and GPU hardware, and the reports of x86's death at the hands of PowerPC^H^H^H ARM are, as always, greatly exaggerated.

<comment><USER5> I don't know if outdated "RISC vs. CISC" thinking is what motivated Gruber's statement, but I think there are much more convincing ways to justify it.

If I could change Gruber's statement, I would say that "The future belongs to _custom-designed SoCs_ "

The advantages that Apple derives from the A-series SoCs is not due to any inherent advantage of ARM vs. x86, but because Apple has full control over the design and manufacturing.

\- Apple can design an SoC for a specific product given the manufacturing process available at the time: see last year's one-off 3-core A8X, because adding a 3rd core was a better tradeoff than increasing clocks. This year, the A9X is back to 2 cores but much higher clocked than the A9.

\- Apple gains a competitive advantage by building processors only for themselves, and can catch the rest of the industry off guard (see: ARMv8 A7). They also get to follow their own principles (two fast, wide cores) rather than being forced into everyone else's marketing hype (8 heterogeneous, slower cores)

\- If Apple wants a stronger GPU they can just license it from PowerVR, rather than having to lobby Intel and hope the resulting silicon is better (or worse, having to add an external GPU)

\- Apple can even hedge its bets w.r.t fab processes: see the dual-sourced TSMC/Samsung A9

ARM is a threat to x86 because anyone can design/buy an ARM core, design an SoC around it, and manufacture it anywhere they want. Intel/AMD can't come close to that flexibility, and on platforms where Win32/Intel binary compatibility is irrelevant, x86 will decline/stay irrelevant.

<comment><USER6> The GPU issue is a good one. Every desktop system my friends have has two GPUs in it: one built into the processor that no one ever uses, and one they add separately so that they can play any games. AMD at least has half-decent GPUs built into their CPUs, but their CPUs are only half-decent anyway. Meanwhile, Intel refuses to license any Thunderbolt external GPU docks or anything of the sort, despite how popular they would be with laptop-toting would-be gamers, because they want to promote their own, awful GPUs instead.

Likewise the core count issue. Jeff Atwood's recent blog post[1] about how Android JS performance has stagnated because Android SoC single-core performance hasn't improved in years blew me away, but in retrospect it makes sense; it's presumably more engineering work to design a faster CPU core than it is to just put more of the onto a die and call it a day.

[1] [https://meta.discourse.org/t/the-state-of-javascript-on- andr...](https://meta.discourse.org/t/the-state-of-javascript-on-android- in-2015-is-poor/33889)

<comment><USER7> Thunderbolt 3 includes official support for external GPU docks. Intel's reasoning for not allowing them sooner was due to hot-plugging issues but they could be spinning it around.

Source: [http://www.anandtech.com/show/9331/intel-announces- thunderbo...](http://www.anandtech.com/show/9331/intel-announces- thunderbolt-3)

</comment></comment></comment></comment><comment><USER8> This is starting to feel like Apple and Microsoft are really starting to switch places like some bizarro world. Admittedly, this is Daring Fireball and not Apple itself, but wasn't Apple supposed to always talk about what their products do, why it's important, and not what the specs are?

Here, a huge portion of the write-up of the iPad Pro is the performance of the hardware. Was anybody really complaining that their iPad wasn't fast enough? Was that holding back developers? (honest question, maybe it was, I'm not sure).

Then there is this statment "Anyone tying themselves in knots looking for a specific target audience for the iPad Pro is going about it the wrong way. There is no single target audience. Is the iPad Pro meant for office workers in the enterprise? Professional artists creating content? Casual users playing games, watching movies, and reading? The answer is simply "Yes"."

Isn't this often the kiss of death? Not recognizing a single target audience for your product? The original iPad had a target, all be it a hugely diverse one. It was for people who wanted to consume content on a larger screen device than their phone, but wanted something simpler than a laptop.

<comment><USER9> _Was anybody really complaining that their iPad wasn 't fast enough? Was that holding back developers?_

When combined with Apple's effectively forced upgrade policy with iOS, yes, many people have complained that their iPad is no longer fast enough, even if it was just fine before the OS update.

App developers are forced to collaborate in that exercise by Apple deciding which versions of iOS (and visual styles etc.) apps must support to go into the App Store.

Probably the most serious example so far was people with 2nd or 3rd generation iPads, who were effectively forced to update to at least iOS 7 because of app compatibility issues. Significant numbers of users appear to have experienced serious performance problems afterwards (just google any plausible complaint wording) and to have reported varying degrees of success in ever resolving them.

<comment><USER8> That's an interesting perspective, but that is essentially Apple breaking everything for everybody and forcing obsolescence of their products.

I consider that slightly different from "I can't do task x on my iPad because it isn't powerful enough".

<comment><USER9> _That 's an interesting perspective, but that is essentially Apple breaking everything for everybody and forcing obsolescence of their products._

In practice, yes, that is very much the result. Sadly this seems to be SOP for Apple across the board in recent years, but it's particularly bad with the mobile devices. The thing is, people don't notice the cost of their shiny new iPhone so much because it's obscured by ongoing contracts with their network. Tablets and laptops don't enjoy the same luxury, which I suspect is a large part of the reason tablet sales figures have been less impressive since the early new-shiny rush for a few years after the first iPad arrived.

 _I consider that slightly different from "I can't do task x on my iPad because it isn't powerful enough"._

Fair point, but I think it starts to become relevant for much the same reasons if you want the iPad to be taken seriously as a laptop competitor. At that point, it doesn't just have to be powerful enough to run toy apps today, it also has to be powerful enough to run serious productivity applications tomorrow. Earlier generation iPads -- even ones just a few years old and well within the normally expected working lifetime of a professional computer -- demonstrably didn't have enough power to do that with the combination of hardware and software being offered.

</comment></comment></comment></comment><comment><USER10> This reads more like a bad review of the new Macbook than a great review of the new iPad Pro. Of course, this was already the case before, the new Macbook has always been kind of a head-scratcher:

1\. Despite the amazing battery advancements it gets worse batter life than the Macbook Air (9 hrs web vs 12 hrs).

2\. A worse graphics card than the Macbook Air yet MORE pixels.

3\. A higher price point.

Any time I bring this up, I'm told I don't get it and this isn't a computer for a "pro" like me. But that doesn't really mesh with the fact that its a super expensive computer. Who is this for?

I guess it makes for a really great comparison to the new iPad Pro.

<comment><USER11> > _" But that doesn't really mesh with the fact that its a super expensive > computer. Who is this for?"_

Early adopters and people who need absolute maximum portability and are not particularly price-sensitive.

The MacBook is smaller, thinner, and lighter than the MBA, and has a higher quality screen. If you need a laptop that fits the above description and don't mind the cost, it's a good bet.

More to the point though - it occupies a similar space as the MacBook Air when it originally came out (recall that the MBA was ~$1500-2000 when it first came out). I think it's fairly obvious that Apple's letting early adopters pay the premium, and once they can get production costs down enough it will simply take over as the lowest-tier Mac laptop entirely, probably at the same $900-1000 price point the MBA is at today.

It is the exact same trajectory as the original MacBook Air - introduced as premium ultra-portable product, eventually replacing the plastic MacBooks as the base-level product.

<comment><USER10> _> The MacBook is smaller, thinner, and lighter than the MBA, and has a higher quality screen._

I just find it hard to say that its a higher quality screen when you have a worse graphics card, and thus the stuff that will actually be on the screen will be worse (more dropped frames, worse effects, etc). What does it mean to want a higher quality screen? If it had 8x as many pixel but was black and white, is it higher quality? If you want a retina screen for awesome gaming, this isn't for you. If you want a retina screen for video editing, this isn't for you. If you want a retina screen for ... web browsing, as long as there are no CSS animations because they'll be horrible... then its for you?

 _> it occupies a similar space as the MacBook Air when it originally came out_

Sure, I get that, but the difference is that when the Macbook Air came out the Macbook Air didn't already exist. Let's think about it another way, if next year they announce an EVEN thinner Macbook with even stranger performance tradeoffs, would we accept 3 computers in this space? Probably not. I suppose my fear is that the plan here is to replace Macbook Airs with this. What I wanted out of a Macbook Air was more RAM, that's about it. Instead this huge detour was taken on compromise features -- which again is fine, except if the plan is to turn this entire product category into a worse-than-iPad computer, which is definitely not where the Air sat before. The Air before seemed like good compromises, and perhaps the Macbook will get there too.

</comment></comment></comment><comment><USER12> It really is a loss that Apple enthusiasts are so trapped in their bubble. Apple makes some fantastic gear, but there's a whole world exploring design choices. I recognize some of the compromises the author talks about trying to use a tablet as a computer from time spent with those devices, like the Samsung Q1 and numerous exotic devices that were more like prototypes than anything.

It's not clear Apple will care to consider developers on the iPad platform, or professional users of any requirement, since Apple seems to like to sell users a device for every purpose.

I just spent time with an Asus Chromebook Flip, which has an excellent keyboard and trackpad and converts into a tablet or the useful tent mode, has a quality aluminium body and IPS display, and weighs less than 2lbs. Give that $300 device a faster CPU, backlit keys, replace the bezel with a full size 4:3 12" screen and it's pretty much the perfect no-compromises browser-centric device that'd still be less than half the price of the iPad Pro with keyboard. And ChromeOS acknowledges enough of its Linux base that the user will get respect when they want to go below the covers.

<comment><USER13> I really like my Asus Chromebook Flip, but I suspect that by the time you're done enhancing the design you're getting into the laptop/high-end tablet price range. And I don't understand the market for the Pixel.

I do think there's going to be a re-convergence between tablets and laptops even given the track record of convertibles but it's going to require a lot of thought and engineering and testing around specific use cases. (And I also understand why Apple might not be incented to drive things too hard in this direction.)

<comment><USER12> I've wondered about the price too, but I think with $200 they could upgrade to a 12" IPS display and something like a Core M chip. Maybe the more square display would be too exotic, 16:9 is weird in tablet mode but could be acceptable for the price. I'd expect USB 3.1 charging in that timeframe too. Backlit keys are a $20 option for Thinkpads so they should be achievable too.

What's there is already so nice and the form factor works so well I'd be really surprised (and disappointed) if we don't see this in 2016, and it should be something of an inflection in the market to contrast with Apple's unrelentingly expensive offerings.

The Pixel is clearly for Chromebook developers, or those with money to burn.

<comment><USER13> >Apple's unrelentingly expensive offerings

It's really the relative expense of quality laptops more broadly.

Story. I forgot my laptop on a weeklong business trip last week. It actually made sense to pickup a Chromebook for the week. After all, it was only about 3x what a forgotten laptop charger would have cost.

Chromebooks aren't a laptop replacement but they are very useful. I don't know enough about component costs to know what a Chromebook+ which isn't a Pixel would cost. However, I do see them as a complement to a laptop rather than a replacement. And, by historical standards, a MacBook Pro is very cheap.

<comment><USER12> I agree by historical standards they are cheap, but by current volume, simplification (SOC) and process they should continue to drop in price. [https://www.semiwiki.com/forum/attachments/content/attachmen...](https://www.semiwiki.com/forum/attachments/content/attachments/15150d1440356386-untitled- jpg?s=d2e192a51882cefee4d114236c37f162)

But the Macbook is a bit of an novelty, really it's the Macbook Air that I find to be badly overpriced now. I like to project on Apple cause I always look for some idealism that must exist somewhere past good design and profit margins since they can't simply be aspiring to smugness. So I find the Asus Chromebook Flip a good example of what a 2016 Macbook Air could look like because it has many attributes of excellent design while integrating practical innovations, yet remans inexpensive. With their own chip they could easily make a quality lower priced Air and still have profit higher than the rest of the industry.

However Apple is unlikely to use the flip design, much less put a touchscreen on a keyboarded device. It would shatter their image.

As well I think Apple has stacked their market, including the Apple resale market, such that any lower cost product would cause value problems across their line. So hopefully these factors create a good opening for a reasonably priced, quality product that is intentionally more open to the hacking mindset from a company like Asus.

</comment></comment></comment></comment></comment><comment><USER14> All of the claims of ARM vs x86 performance are based on Geekbench and Javascript benchmarks. This seems woefully thin data to make real comparisons, especially against platforms with active cooling.

1\. How does an A9x fare with long endurance workloads? Bursty benchmarks are one thing, but what's performance like after 30 minutes of active use? None of the A9x benchmarks do any kind of battery rundown throttle tests.

2\. How does A9x fare with large workloads? Loading up small streaming kernels into the CPU is one thing, but what about workloads that lean more heavily on the cache, memory architecture, and branch prediction units?

<comment><USER15> I've done benchmarks across mobile devices as my bread & butter job for several years. All of the benchmarks in this review mean almost nothing. Even the testing methodology is fundamentally flawed. I'll explain.

Javascript benchmarks are heavily dependent on the browser's javascript engine(big surprise). With Apple's restriction on the ability to use a custom Javascript engine on iOS - there really is no way to compare say for example: Chrome on iOS vs Chrome on Android. They are running very different Javascript engines. The hardware is not the only variable that is changing.

Running Octane/Kraken on Safari on the iPad vs Chrome on a Surface Pro - <USER2> why even bother running this test?

Also, ever wonder why the companies making the browser have their own browser benchmark suites? Google with Octane and Mozilla with Kraken, and Microsoft with their Testdrive? Guess who is the winner in each of the benchmark suites.

It is not that these companies consciously cheat by building the browser and the test to make it look good. The teams building the benchmarks and the teams building the browser are not in collusion. It just happens that when you use a single benchmark as the only metric to optimize for, you will eventually build a product that is optimized for that metric. No cheating required, it just looks that way.

Geekbench - I've seen refered to by my coworkers as "Jokebench". Not that the benchmark itself is bad in some way - it is very useful in comparing one Apple device generation to another - or one mac to another mac. But cross-platform, cross-ISA, cross-OS? Joke. The authors of Geekbench know this fact, and yet they market GeekBench as a "cross-platform" processor benchmark. And your average tech product reviewer - who has never heard of the terms 'LINPACK' or 'SPECint' will have you believe it is a great benchmark - and loves basing their product recommendations on these scores rather than the subjective review of the experience of devices that they're paid to review.

Additionally, all mobile devices throttle quite heavily under sustained load. 2.26GHz processor? Yeah 10 minutes in with 100% CPU load, I will bet real money that frequency drops below 1GHz. This is not a jab towards the A9 or Apple specifically. Qualcomm's chips do the exact same thing. Intel's Core does the same thing. Infact, they've put considerable marketing money behind this feature - calling it "TurboBoost".

Anyone in the industry knows you absolutely have to measure performance in the thermal steady state - fancy way of saying when the temperatures across the device stay the same throughout the test. Try this right now. Download Geekbench or Antutu on your phone. Run it once. Note the score. Run the same test immediately again. What? The score is lower the second time? Did your hardware just get worse all of a sudden? No. The device is warmed up. So it has to throttle its frequency and power envelope to keep itself from burning you. Now the problem is that the difference in scores between the cold state and the warm state is quite dramatic. Which one do you use when you want to compare it to the iPad? Was the measurement you just did a 'cold' one or a 'hot' one?

Our team has entire rigs built out specifically for keeping devices cool during benchmarks. It's the only reliable way to ensure thermal throttling doesn't fog up your benchmark results. The reviews you'll see on the internet never use such rigs. So the results are mostly non-sense.

ARM vs x86 ISA? Entirely pointless discussion. It is like saying Germany has a higher GDP than the UK because they speak German rather than English.

So what do you use for comparison? You need to base the benchmarks on real- world tests. Who cares about kraken or octane? Fire up a 1000 page loads for some common top sites on Safari, and calculate via image capture and analysis, the time the device takes to render the page. The time it takes to render the screen is one of the key psycho-visual cues to device performance. Which is why iOS has been steadily decreasing their animation intervals every iOS version - to make it feel faster even though, it might not actually be.

Another key metric is how long things take to copy/move/download/encode - <USER3> wait interval. How fast does the device install apps? Typically, users get a sense of device performance when they try to download an app. The user wants to access the app he/she wants to access. All of the things your device must do - download the app binary, authenticate your user with the app store, install the downloaded bundle and then launch - all these things are crucial indicators for device performance.

This article talks almost exclusively about benchmark performance. Not a single sentence about how fast the iPad Pro actually feels in comparison to the iPad Air or the Surface Pro. Very little words are devoted to talking about the capabilities of the platform. The Surface Pro runs Windows desktop and the Macbook runs Deskop OS X. Radically different capabilities on these platforms. On a Macbook, I can SSH into a production server, reboot it, while I write code in XCode. How does it compare with what I can do on an iPad or a Surface? What is the point of this article even?

<comment><USER16> OK, let me confirm: browsing the web on iPad Pro feels noticeably faster than browsing the web on a MacBook (the new 2015 Core-M).

</comment></comment></comment><comment><USER17> Good review. I especially appreciated the comments about app support for the keyboard issues - although I expect most will get resolved in a few months.

I have an iPad mini 4 and I am surprised at how much I use it for work tasks. I write a lot and having a text editor open for markdown manuscript files in Dropbox with a generated PDF open for viewing (I use leanpub.com for writing) is really convenient. Easy to edit markdown files and it just takes a second to switch the latest PDF file. For situations when I am only adding a few pages in a writing session, text input speed is not an issue.

In the same spirit, when I need to SSH to a server for something simple, it is faster to use my iPad. I sometimes use the nitrous.io web IDE, but not often on my iPad.

With a larger screen, multi Windows, and more processing power of an iPad Pro, I think that it will make a fine partial laptop replacement. I will always, probably, need a laptop for running IDEs like IntelliJ however.

My wife also has an iPad mini and we have talked about just traveling with a mini, not a smartphone. Right now, my Note 4 does everything I need while traveling (SSH shells, writing using leanpub, calls, and web access) but an iPad with 4G might also be a replacement for a phone when traveling because I always have a backpack with me.

I am very keen on the iPad model as being the most used device in the near future. I think this is Apple's plan.

</comment><comment><USER18> I think this is an Apple me too moment that does not have the right stuff to succeed.

Apple decided they needed a tablet that was geared for production versus consumption. Unfortunately, the OS X is not optimized for touch interaction, so they are forced to go with iOS and ARM.

Microsoft on the other hand went through the pain with Windows 8 of actually making their main OS touch friendly. They are now on their 4th generation of tablets that actually run a real desktop OS on Intel x86 processors.

I think for the professional person that is wanting to work on a tablet, Microsoft Surface Pro is going to be a much better choice. You will have a real desktop operating system on x86 that actually runs the productivity/design/development software that is actually out there.

It will be interesting to see how this develops.

<comment><USER19> Even with Windows 10 and the latest Surface Pro 4, I don't think they're very usable as actual tablets. Virtually every time I see a Surface Pro, either in real life or even advertisements, it's being used as a laptop with the kickstand and keyboard attachment. You almost never see anybody use it as a tablet. This happens so much that it's actually hard to find a review of the SP4 that even shows what it's like to use as a tablet.

So while Windows 10 supports touch interaction, it's honestly not that great at it, and so far as I can tell nobody really uses it outside of content consumption. But by taking this approach, Microsoft skipped the massive step of needing to get new versions of all major software developed for a truly touch-centric interface.

The SP4 is also not nearly as good as a family device. It's much harder to use and is far more susceptible to user error.

Apple seems to be taking the opposite approach. They're taking a hit early on by building up everything from scratch for a touch interface, but their bet is that over the long-term the end result will be better.

I don't know which approach will pan out, of course. I suspect to begin with the iPad Pro will simply serve a more affluent segment of exactly the same demographic that the iPad has always served, but over time it might expand to more professional users as its software develops and begins to rival desktop software.

<comment><USER20> How often do you see people use a Surface in general? I see people using them as OneNote scratch pads regularly: in business meetings, at conferences, and for diagramming.

> So while Windows 10 supports touch interaction, it's honestly not that great > at it, and so far as I can tell nobody really uses it outside of content > consumption.

That's fine, that is what tablet mode is often for.

You have the kickstand/keyboard/touchpad for actual productivity. You have the tablet for consumption, and you have the tablet + pen for productivity when the activity allows it (e.g. drawing, hand-written notes, etc).

I haven't used a Surface Pro 4, but the Surface Pro 3 had issues: It was too heavy, and the touchpad on the keyboard cover was frankly terrible (and per this article nobody wants to sit there with their outstretched arm touching the screen). We'll see if the SP4 solves any of the above.

> The SP4 is also not nearly as good as a family device. It's much harder to > use and is far more susceptible to user error.

Absolutely. Which is why it was never targeted at that demographic. It is a professional device, just like the iPad Pro.

</comment></comment></comment><comment><USER21> It has been some years since we got the first "iX will kill the pc" and we know where the story goes. There are several things you have to keep in mind when referring to ARM and how fast it's been evolving, PC and iX devices:

-Apple is pushing forward at an incredible pace, the new Ax cpus with the pciE based storage solutions are remarkable proofs of it.

-contrary to x86, ARM power is still increasing per release, some day it will hit Moore's law 2: more cores and not speed (MHz) irremediably, this is: it wasn't fast enough. _Moore 's law 2: a side effect of not being able to make cores faster thus taking the path of adding more cores with the well know issues of not being able to spread work across cores efficiently.

-x86 on the other side has been getting better at power usage, I can't do a forecast but I would suggest the race comes to if x86 can get power efficient enough or ARM can get fast enough_.

*as the review mention is already very fast, the question is what's the thermal envelope, how much time it can stay there and the ram in soc package.

-traditional x86 work vs ios ecosystem, another comment here states:"how much I use it for work tasks" referring to the ipad where those tasks are "text editor open for markdown manuscript files in Dropbox with a generated PDF open for viewing" vs what he states is pc work "I will always, probably, need a laptop for running IDEs like IntelliJ however" and again what he feels is the new ipad pro lacking "larger screen, multi Windows, and more processing power" this is: pc capabilities.

-user cliche? is always the argument about being laptop killer that you can write on it? "I write a lot" and from the article "I've written this entire review using it"? what does define the ability to be a pc killer? to browse the web?

-ecosystem, unless apple get macosx to run in arm it's a very fast iPhone.

<comment><USER22> The ecosystem is a killer. As a developer, it's missing everything I need to be built-in on a device: a terminal, VMware, SSH, remote access to other machines. Obviously I'm not the target market, but consider the same thing for designers: where is Sketch for iOS? Where is the equivalent of desktop Photoshop?

I still think that iX devices are create for consumption and very basic creation, but anyone who is doing creation full-time isn't going to able to switch for some time.

<comment><USER23> Fwiw most of my iPad dev time I spend in a terminal (I use the one bundled in coda) working on a remote machine. Being able to have a split screen between a terminal and safari actually sounds like it could actually be enough for me most of the time.

</comment></comment></comment><comment><USER24> Seems that "desktop class hardware" is needed nowadays to run iOS 9 blur smoothly, which was fine in iOS 8 :

[https://www.youtube.com/watch?v=QxtQ8IoiYa4](https://www.youtube.com/watch?v=QxtQ8IoiYa4)

[https://www.youtube.com/watch?v=agsN6Dxwk7g](https://www.youtube.com/watch?v=agsN6Dxwk7g)

<comment><USER25> I held off upgrading to iOS 8 for a long time out of fear that my iPhone 5 would slow to a halt; when it had to be replaced for an expanding battery I got it back with the upgrade and was pleasantly surprised at how well it performed. I took the jump with iOS 9 and now experience almost the same as in your link. I rarely have more than 3 apps open at a time, no media (photos, music, ...) stored, and all optional effects disabled. I wish they had some internal incentive for keeping old stuff working like new; it used to be a source of pride to own an Apple device that was several years old and still looked and worked like a new product. The iPhone 5 and unibody MacBook Pro are both examples of products that I've owned for years but continue to impress.

<comment><USER26> We need a law mandating security updates which are decoupled from new features. Alternately, an OS vendor who makes this a point of competitive differentiation.

Unfortunately, MS is forcing new features alongside security fixes, and Android devices have a poor track record of timely security updates. So we are left with Apple, whose iOS9 effectively destroyed the performant usability of older devices.

<comment><USER6> On the other hand, at least you can get those updates on your older iOS devices. Most Android devices have never seen updates at all, and of the ones who have, most of them will never see more than a few minor updates above what they came with.

<comment><USER27> I'd rather have a machine that works but is no longer receiving updates than one that is effectively bricked. At the very worst, if you're paranoid, you can just use the device for non-critical tasks. That's better than not being able to use it for anything, which is what happens to your iPad if you get unlucky and upgrade it beyond the point of no return.

<comment><USER26> iOS9 was a bait-and-switch because it was advertised as the release that would (a) support older devices, (b) prioritize stability over features, and (c) receive extensive public beta testing. Then iOS9 delivered ... _much worse_ performance regressions than iOS7->iOS8, regressions so bad that a new device needed to be purchased.

</comment></comment></comment></comment></comment></comment><comment><USER28> That was an interesting read. So in full disclosure I've been an iPad user since they came out (the company bought everyone an iPad in 2010 when we launched the search engine, and I upgraded it to the Retina one when that came out)

I was waiting until I could order and iPad Pro, then saw the video demo of the Surface Book and ordered the core i7 one right away. It is entirely possible the Microsoft took money off Apple's plate in my case (we'll know for sure when I can actually get my hands on an iPad pro to play with). My Surface Book arrived last week and I've been playing with it ever since.

To understand that my use case is replacing books and notebooks. I want to have a library of books where ever I go, and the ability to sketch as well. In 1997 I saw a prototype 200 dpi OLED display at IBM's Almaden Research lab, I ended up buying an Illiad 2 from iREX which was about 157 dpi and a watcom stylus circuit for about $800. The plan being all docs and notes on docs and sketches.

Between then and now I've going through several iterations each adding a bit here or there, cursed the Plastic Logic folks for killing themselves by reaching too far, and finally found the 10" iPad (retina) to have the screen, and battery life characteristics I could live with but drawing really sucked.

When I saw the iPad Pro announcement I felt it was the closet thing yet to the ideal paper notebook and infinite library replacement with a couple of shortcomings (limited local storage, possibly limited drawing experience) and then saw the Surface Book announcement which has a different set of short comings (primarily cellular connectivity).

So while I vastly prefer IOS over Windows 10, I really need the ability to access my library on my local network, or through SD cards. The drawing experience on the Surface has been perfect, the display resolution also best of class. The application selection less than stellar, and the lack of cellular connectivity means I have to tether it to my phone when I'm out and about.

So had iPad Pro come out last February I would already own one. Now I'm not so sure.

The Surface is wicked fast, and yes 50% more expensive than an equivalently equipped iPad Pro. From a fundamental engineering capability standpoint I think it holds its own, from an apps standpoint I'm still evaluating various drawing apps (wish I could find one that created the ruler tool when you put down two fingers)

I really love the idea of having two compelling solutions available!

<comment><USER29> > _The drawing experience on the Surface has been perfect, the display > resolution also best of class._

How's the latency, precision, pressure sensitivity, palm rejection (especially latency)?

Have you compared the generations of the Surface w/ Wacom vs. N-Trig tech? Have you tried a recent Cintiq? If so, any thoughts?

I'd really love to see some reviews from artists comparing Cintiq vs. Surface Pro 2 vs. Surface Pro 3 vs. iPad Pro for stylus use.

<comment><USER28> It has been especially good at palm rejection (I'm left handed). Latency and precision were better than the Galaxy Note, and way better than the Retina Ipad with the Jot pro stylus (one of the bluetooth assisted stylii) I played with the Surface Pro 3 at a Microsoft store based on recommendations from here, and my recollection was that the pen experience wasn't quite as good (but it too was better than the iPad) at the time the SP3 did not have the performance though and so larger drawings would start to bog down.

I too would love to see artists do some analysis of the available technologies.

<comment><USER30> Noah Bradley's review of the SB is up.

</comment></comment></comment></comment><comment><USER31> "The entire x86 computer architecture is living on borrowed time. It's a dead platform walking. The future belongs to ARM, and Apple's A-series SoC's are leading the way."

That is an extremely bold claim. I'd love for it to be true though.

<comment><USER32> It would not surprise me to see an Apple ARM chip in future Macs. The improvement to battery life would be huge. As with the Intel transition, I bet Apple already has OS X running on ARM chips.

The biggest problem would be to get third-party software developers to port to ARM, especially the major ones like Adobe. Microsoft already does a lot of work for ARM, so the barrier to getting Office running on OS X on ARM might be pretty low.

<comment><USER33> The MacBook has a 4.5W processor. That's less power than a standard iPad's processor, let alone the iPad Pro.

</comment></comment></comment><comment><USER34> From the OP:

> The entire x86 computer architecture is living on borrowed time. It's a dead > platform walking. The future belongs to ARM, and Apple's A-series SoC's are > leading the way.

> The A9X didn't come out of nowhere. Watching Apple's A-series chips gain on > x86 over the past five years, we've all been speculating about whether Apple > might someday start using ARM chips in MacBooks. As of now, it's only a > question of whether they want to.

The most interesting point of this review in my opinion. x86 is hampered by backwards-compatibility. Could anyone comment on some of the more technical CPU architecture reasons for this? Do A64 CPUs have potential to outpace x86_64 processors in power consumption and performance simply because of the architecture?

<comment><USER35> >Could anyone comment on some of the more technical CPU architecture reasons for this?

>x86 is hampered by backwards-compatibility.

Those two sentences don't belong in a single comment.

<comment><USER36> I assume the question was about _how_ backwards compatibility is holding x86 back and what features are problematic.

</comment></comment></comment><comment><USER26> The Logitech keyboard is available at Apple stores, offering real (19mm) keys, backlighting and shortcuts for home/lock, spotlight search, brightness, volume and music (reverse/play/pause/forward). A bit cheaper and heavier than Apple's keyboard.

Walt Mossberg said, _" Of the three keyboards I used to write this column, I found that the MacBook Pro was best, the Logitech Create second, and Apple's iPad Pro Smart Keyboard dead last."_, [http://www.theverge.com/2015/11/11/9711284/logitech-ipad- pro...](http://www.theverge.com/2015/11/11/9711284/logitech-ipad-pro-keyboard- case-announced)

<comment><USER23> Also Logitech have Azerty and qwertz keyboard, whereas I think Apple only has qwerty at the moment

</comment></comment><comment><USER37> If iPads are able to become the defacto portable work/personal device I wonder how Apple forcing a 30% cut on every digital things sold through apps will work.

Are there any people here who use an iPad regularly for work? Is it easy to keep things organized without a file system?

</comment><comment><USER38> The question that most interests me is, how does it compare with Microsoft's Surface Pro?

<comment><USER39> Seems to me more like a well-executed Surface RT than a Surface Pro.

</comment></comment><comment><USER40> Over time, I've begun to take daringfireball reviews with a grain of salt. Despite having bought into the apple ecosphere, I don't think iPad Pro or any other product deserves as much appreciation as daringfireball reviews give. Sure they are great pieces of technology, but the difference is not like it was between a dumbphone and an iPhone. The reviews are much more fanboy like than objective.

<comment><USER41> Did you read it? A _large_ section of the review was complaining about bugs and software shortcomings. That's not being a very good "fanboy".

<comment><USER40> I was talking about the general articles/reviews from daringfireball. Not this one is particular. I don't understand the need to give a build up that starts from the dawn of civilization to talk about a tablet or a laptop.

<comment><USER16> Which reviews of mine do you think this applies to?

</comment></comment></comment></comment><comment><USER42> "It brings me no joy to observe this, but the future of mass market portable computing involves neither a mouse pointer nor an x86 processor."

Or freedom.

</comment><comment><USER43> I think laptops are becoming irrelevant for many use cases. They are not sufficiently powerful to do heavy data processing without running into thermal issues, and they are less mobile than tablets equipped with external keyboards. This is what Microsoft has realised about when they created the Surface product line.

Workstations are surprisingly capable for the money. A big NVMe consumer-grade SSD, some RAM and a good GPU can take you really far. 5 years ago I never thought I would be able to run my stuff on a workstation instead of a big server.

Tablets are very interesting, because they fill in the mobility use case much better than laptops. They are way more ergonomic as long as you have an external keyboard. The shame with the iPad Pro is not being able to run a full OS. I'd love to run say Arch Linux ARM.

<comment><USER44> It almost sounds like you're saying laptops may be on the decline, something that many people claimed laptops were going to do to desktops.

<comment><USER45> Desktops did go on the decline. Certainly not eradicated, but the laptop is now the default choice, and the correct choice for most people.

<comment><USER44> desktops simply stopped being used in situations where laptops were the better choice, but they were never in danger of ever being displaced by anything.

Most of those people who have laptops either have desktops at home or have a docking station with a full blown monitor and keyboard at home.

There's a reason for that.

</comment></comment></comment></comment><comment><USER46> The iPad Pro mainly interests me for the stylus. I can't wait to read some reviews by actual artists who've been using Wacom hardware for years. If the Pencil is as precise and lag-free as early reviews indicate and it comes to the Mini, it will be my first must-buy iPad in many years.

"The entire x86 computer architecture is living on borrowed time. It's a dead platform walking."

This kind of talk makes me sad, though. It almost seems like Apple bloggers get excited at the prospect of an ARM future. All I see, though, is a future where the walled garden has won out over open computing, and also a future where several decades of x86 video game history have been dumped in the trash. Not in any way acceptable to me.

<comment><USER30> Reviews are out, but in general, if your work flow involves photoshop, you'd be on the wacom/surface lines.

</comment></comment><comment><USER8> Can somebody explain the 'single-core' description in the tests? Doesn't the number of cores need to be taken into account when considering the actual performance?

This may be wrong, but the way I'm looking at it is like comparing the power of a 4 cylinder car vs an 8 cylinder but measuring the power that comes only out of one cylinder as your comparison measurement. It is possible that a single cylinder from a 4-banger creates more power than a single cylinder from an 8, but in the real world, that won't matter.

I'm guessing I'm wrong, but why?

<comment><USER29> Typically both single-core and multiple-core benchmarks are reported. Because some workloads can be effectively multithreaded while others cannot, single- core performance is often as useful a metric as multi-core performance.

</comment></comment><comment><USER26> How can Apple source laptop-sized 4:3 screens for the iPad Pro, when every laptop vendor has abandoned this high-productivity aspect ratio that offers more vertical real estate for text?

<comment><USER47> Because Apple is ordering ~25M units of that display panel but PC vendors are not.

Or because Apple gives customers what they need but PC vendors give customers what they want.

<comment><USER26> Laptop customers have begged for 4:3 screens, but were told that display vendors had all switched to 16:9 because of movies. Yet Apple managed to find/mandate production of 4:3 high-res screens.

</comment></comment></comment><comment><USER23> I really wish they'll upgrade keyboard navigation (whether scrolling or selecting items, etc) - I've started relying on my iPad more and leaving my computer at the office, and it's fine for most tasks with a keyboard except when navigating in an app - having to touch the screen is just too slow. I wonder how the option-tab combo works when multitasking with two apps on the screen though

</comment><comment><USER48> Hmm, no one seems to be talking about the use case I'm interested in with the pro, namely watching Netflix/iTunes/VLC, which is currently ~90% of my iPad use.

I use an ancient iPad 2 on a stand for this now, I'd like the pro for the bigger, better screen, and speakers. Don't care about the rest, which has been overkill for several generations. Wish there were a cheaper model. ;)</comment>


New component vue js for vuesax Update image - <AUTHOR> https://github.com/lusaxweb/vuesax <comment><USER2> Why do I need all this overhead for something as simple as a button or other native form input elements?</comment>


WiFi Experiment Done by a Group of 9th Grade Students Got Serious Intl Attention - <AUTHOR> http://ofthebox.org/wifi-experiment-done-group-9th-grade-students-got-serious-international-attention/ <comment><USER2> [https://www.snopes.com/cress-wifi-experiment/](https://www.snopes.com/cress- wifi-experiment/)

Please flag this to hell.

<comment><USER3> Not so fast. Snopes article is little more than ad-hominem attack against scientists interested in the cress experiment. Claim of "lack of an apparent biophysical mechanism of interaction" is just flawed and 20+ years behind actual scientific progress in RF bioeffects, see [https://www.ncbi.nlm.nih.gov/pubmed/26151230](https://www.ncbi.nlm.nih.gov/pubmed/26151230) and [https://www.ncbi.nlm.nih.gov/pubmed/23802593](https://www.ncbi.nlm.nih.gov/pubmed/23802593) . "Replication" attempts mentioned by Snopes fail to actually replicate the orig. experiment exposure setup. A constant ping-flood was run through Wi-Fi router in orig. experiment to simulate real exposure situation like video- streaming. Replications just position a Wi-Fi router in idle-mode close to cress.

</comment></comment><comment><USER4> I looked in the article for how far away from the router and didn't see that. Did anyone else see it?

Because don't the radiation effects drop off like 1/r^3 ? Not my area, I'm asking, not claiming.</comment>


Remote Code Execution in Elasticsearch – CVE-2015-1427 - <AUTHOR> https://jordan-wright.github.io/blog/2015/03/08/elasticsearch-rce-vulnerability-cve-2015-1427/

<comment><USER2> Great article.

 _One feature of the _search API endpoint is to allow users to submit Groovy code in the search query itself. The server will then execute the code in a sandboxed environment, returning the result to the user. This way, the elasticsearch code can be used to execute… more code._

Quite a dangerous feature indeed. Thankfully, according to the documentation[0], this feature is disabled by default since v1.4.3. (Hindsight is 20/20, but this probably should have been the case from the get-go)

0\. [https://www.elastic.co/guide/en/elasticsearch/reference/curr...](https://www.elastic.co/guide/en/elasticsearch/reference/current/modules- scripting.html#modules-scripting)

</comment><comment><USER3> Hey there! Author here - thanks for posting this!

In response to this, I made an open-source honeypot (in Go!) called Elastichoney. I recently released every single log I collected in nice JSON form:

[http://jordan-wright.github.io/blog/2015/05/11/60-days-of- wa...](http://jordan-wright.github.io/blog/2015/05/11/60-days-of-watching- hackers-attack-elasticsearch/)

Let me know if you have any questions!

</comment><comment><USER4> This is old. There are bots that scan servers for ES and try to exploit this vulnerability. Our servers were hacked through this hole before we upgraded to a newer version of ES. Now we don't allow remote access to ES directly. We use a proxy script that parses HTTP requests from users, interacts with local ES instance and serves users with transformed data.

<comment><USER5> How did you have it open to the Internet? Couldn't someone just DELETE everything? Or what kind of setup/restriction did you have?

<comment><USER4> It was served through a proxy script, but actual ES instance was accessible to anyone and yes anyone could delete documents, groovy dynamic scripting was also enabled. Stupid setup I know... Our documents were not touched, but our servers were used to ddos something.

</comment></comment></comment><comment><USER6> I created an Nmap script to find this on your own networks:

[https://gist.github.com/jwpari/3369a537b422ecfa23f5](https://gist.github.com/jwpari/3369a537b422ecfa23f5)

Use with:

      nmap -T5 -p 9200 -Pn --script=+elasticsearch-cve-2015-1427 10.0.0.0/8

</comment><comment><USER7> I had a Digital Ocean VPS shut down because of the previous exploit (mentioned in the article). I was just testing an open-source project of my own and did a standard/stock install.

I don't really understand why a project like this would default to having such vulnerable settings turned ON.

</comment><comment><USER8> FYI, it looks like this was released ~3 months ago on Feb 17th of this year: [https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2015-14...](https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2015-1427)

</comment><comment><USER9> This vulnerability sounds similar to the issue I described here: [https://crashcoherency.net/posts/perils_of_source_based_sand...](https://crashcoherency.net/posts/perils_of_source_based_sandboxing)

tl;dr: If you're doing sandboxing by blacklisting specific strings in your input, you're doing it wrong. Java actually has good sandboxing capabilities. Use them!

</comment><comment><USER10> The author of that sandboxing feature of Groovy recently wrote a blog article on improving sandboxing of Groovy scripts that are executed at runtime, see [http://melix.github.io/blog/2015/03/sandboxing.html](http://melix.github.io/blog/2015/03/sandboxing.html)

His conclusion says that using Groovy for scripting on the JVM comes at the price of security, and that the customizers in the Groovy distribution and those in the wild aren't enough to guarantee security of execution of scripts in the general case, but if you loosen some of the dynamic features of Groovy, you can work around those limitations through type checking extensions, though that solution _isn 't available_ in Groovy's core distro. He adds he'll have less time to work on Groovy, probably refering to how he and the other full- timer building Groovy had their funding pulled beginning the following week (end March 2015). There's now noone working fulltime building Groovy.

</comment><comment><USER5> If you have Elasticsearch open to arbitrary inputs, isn't it a given anyone can mess you up?

</comment><comment><USER11> I have always followed CouchDB from a distance, so I am curious, has anyone been able to pull the same crap writing Erlang or Javascript? This is more relevant to the latter bc of the sandbox, but this NoSQL architecture decision sounds very familiar.

I swore I read something about attempting to break the JS sandbox but found nothing with my weak Googlefu.

<comment><USER5> So there's plenty of bugs in the JS interpreters, and you can use those to do regular exploits and run arbitrary code.

Separately is escaping the sandbox due to a bug in the verification. JS is probably far easier to secure, since all the APIs are "safe" to call. That is, there isn't a huge JS stdlib that needs to be restricted. Like brainfuck- there's no way to make dangerous calls. Whereas Java has a huge stdlib that's accessible, so you're fighting an uphill battle to lock it down.

</comment></comment><comment><USER12> Don't expose elasticsearch to the public. You wouldn't expose your database to the public (or would you?), and this isn't any different.

At the very least, limit the set of IPs that can connect to your server.</comment>


Shocking evidence shows people in vegetative states may be conscious - <AUTHOR> https://www.newscientist.com/article/mg24232360-800-shocking-evidence-shows-people-in-vegetative-states-may-be-conscious/ <comment> grayed-down Yeah, this something I think about. Back in the 80s a friend's younger brother was hit by a car while on his bike. He was in a coma for over two months and his family was ready to write him off, so to speak.

One morning he wakes up and a few hours later his first question was, "why couldn't anyone hear me?"

To hear the story from him was a lot spookier.</comment>


C++11 lock-free command buffers for multi-thread rendering - <AUTHOR> http://alinloghin.com/articles/command_buffer.html <comment><USER2> It's an interesting idea, but you still have single threaded rendering in the end with OpenGL. However, you are able to keep that thread constantly busy which is a big plus.

<comment><USER3> This fits really well with the single submission queue model, particularly if you're careful to use AZDO style OpenGL. You merge sort the lists once you're done with the frame, and then you have a pretty good approximation of the minimum state changes needed as you iterate through the sorted list on your submission thread.

Now, the better implementations I've seen use per thread lists during queueing so you don't need any of the barriers or atomics here at all, but this is a good first pass.

<comment><USER2> Agreed, this is actually a fun exercise to think about

</comment></comment></comment><comment><USER4> Hmm, I was curious about the implementation. I checked out the code: [https://github.com/tuxalin/CommandBuffer/blob/master/Command...](https://github.com/tuxalin/CommandBuffer/blob/master/CommandBuffer.h)

EDIT: I was wrong. Editing out a lot of wrong stuff I put here. Thanks to scott_s for pointing out something I missed.

<comment><USER5> The member m_currentIndex is a std::atomic<uint32_t>. The loads and stores to that member specify the memory consistency, and will use the appropriate fences as needed to meet those requirements.

<comment><USER4> Wow. I feel like I herp-derped hard. I don't know how I missed that.

I'll look at this later. Apparently I'm not in the right state of mind yet.

<comment><AUTHOR> No worries, too much work tends to do that to you, I recommend some beers to fix the state of mind.

Regarding the implemention, I presumed you asked about the lock-free logic, apart from m_currentIndex which is used with the m_commands vector, the LinearAllocator also has to be lock-free, see it's alloc function. The allocator is used for storing the command packets (along with their command data) and also their auxiliary data (if they have that).

Another implementation detail of the allocator is that it has two modes, an auto-alignment mode which requires two atomic operations (load acquire and compare_exchange_weak) and will be slower but lower memory usage, therother mode uses the alignment of the CommandPacket class which will be faster (one fetch_add) but consume more memory.

And another detail is the CommandPacket uses a intrusive list approach, that's how you actually chain multiple commands together and do an indirect function call (instead of virtual or other blasphemies) with dispatch of the command.

Hope that clears some things up about it.

<comment><USER4> I was getting ready to type something up, but you've basically answered my questions!

> an auto-alignment mode which requires two atomic operations (load acquire > and compare_exchange_weak)and will be slower but lower memory usage, ther > other mode uses the alignment of the CommandPacket class which will be > faster (one fetch_add) but consume more memory.

That's the main thing I was wondering about, especially the relative speeds of the implementation.

<comment><AUTHOR> Glad to hear that!

I dont have anymore the exact numbers, usually when you have around 1000 commands/calls you won't really feel a difference, in that case even using std::sort is fast enough and there's no point in using radix sort, however when you go over 10k commands/calls you'll feel it (can be up to a msec on the dispatch side).

You can check this great post that provides numbers (see part 4): [https://blog.molecular-matters.com/2014/11/06/stateless- laye...](https://blog.molecular-matters.com/2014/11/06/stateless-layered- multi-threaded-rendering-part-1/)

The performance should be very similar and it even goes further by adding thread local storage to reduce false sharing even more, which I didn't add but should be considered as it's easy to do.

<comment><USER4> Okay, now that I've had some time to look at other things and come back to this, lemme offer some more detailed questions.

COMMAND_QUAL::addCommand uses fetch_add(1, std::memory_order_relaxed); It seems like this is sufficient for memory-consistency for the list, but I'm worried about the eventual sort() command.

In particular, your update in "addCommand" is as follows:

        const uint32_t currentIndex = m_currentIndex.fetch_add(1, boost::memory_order_relaxed);
        // asserts removed
        CommandPair& pair = m_commands[currentIndex];
        pair.cmd = packet;
        pair.key = key;

How does COMMAND_QUAL::sort() know that the other threads are "done adding" and that pair.key is a valid value for comparison? My race-condition would be "sort" has been called, while some thread is still setting pair.key=key, which may corrupt the command/key packet.

\</comment></comment></comment></comment></comment></comment></comment><comment>-----

EDIT: Oh, you answered this in your blogpost. Lol. You assume that the user waits and safely calls sort after waiting.

Okay, that's perfectly acceptable in my eyes. I'll leave this post up for discussion purposes, even if I answered my own question.

<comment><AUTHOR> Correct, you could also use a double buffering approach to avoid that, if possible, depending on your use case. Feel free to reach out if you have any other questions.</comment></comment>


Ask HN: Who here does not like party+fireworks on 2018-12-31? What will you do? - <AUTHOR> <comment><USER2> I can see London's fireworks on the Thames from my flat, but I'm not a party person. So I'll do the same as I always do, sitting there, coding, but I'll watch through the window.

I'll be writing happy new year messages to all the business contacts I made during the year :)</comment>


Ask HN: Can we recruit on HN if not YC-funded? - <AUTHOR>

We need people to do things (casually but paid) that we think some people on HN may find interesting. Would it be acceptable to post seeking those people, if not is there somewhere more suitable? <comment><USER2> Since the Guidelines/FAQ has nothing on this specifically and it might be useful to one(Maybe more) HN readers I believe you should post a "We are hiring" thread.

Especially if no one gives any good reasons why not to in this thread.

</comment><comment><USER3> Wait for a "hiring" thread. They happen once a month or so.

<comment><USER4> This one's only a couple days old. I'm still tracking it.

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

</comment></comment><comment><USER5> You already did. ;)

I think there should be no problem.</comment>


Show HN: ReacType – Visual Prototyping Tool for React/Next.js/TypeScript - <AUTHOR> https://github.com/open-source-labs/ReacType <comment><USER2> Very cool, do you maintain a list of the other options out there?

Will be definitely adding this to mine and pushing it to the front of the queue for testing!

<comment><AUTHOR> Thanks! There are other design-to-code tools like Framer and Bit but neither of these options allow you to build the entire skeleton of a Next.js / React app. We published a medium article talking about the different options + boilerplate repos if you're interested in more of our input :)

[https://medium.com/@tylersullberg/letters-from-the-dark- worl...](https://medium.com/@tylersullberg/letters-from-the-dark-world-of- react-boilerplate-5de9b4b8e2a3)

<comment><USER2> There's MeetAlva and some more I have bookmarked on GitHub too

Generally put this close to the low code world

I'm working on [https://github.com/hofstadter- io/hof](https://github.com/hofstadter-io/hof) though it lacks visual design in its current form. Jumping right to AR for that, will be posting videos soon!

</comment></comment></comment><comment><USER3> very cool!

I just wished an approach better than this, please see how does bubble [1] work!

[1]: [https://bubble.io](https://bubble.io)</comment>


Roger Ebert on What It's Like to Not Eat - <AUTHOR> http://blogs.suntimes.com/ebert/2010/01/nil_by_mouth.html

<comment><AUTHOR> Credit for this goes to jcdreads: <http://news.ycombinator.com/item?id=1130429></comment>


This Atomic Tank survived a nuclear test, then went to war (2014) - <AUTHOR> https://io9.gizmodo.com/the-atomic-tank-survived-a-nuclear-test-then-went-to-w-1542451635 <comment><USER2> Once again the world is reminded how remote parts of the Australian outback are. Emu Flats is the only place ever decided to be _too remote for nuclear testing_.</comment>


Ask HN: What book changed the way you think about almost everything? - <AUTHOR> I was reflecting today about how often I think about The magic of reality by Richard Dawkins. I read it one time more than 1 year ago. I can't remember anything certain from the book. And yet the simple idea about how we become who we are has fundamentally changed the way I view the world. Can anyone recommend books that have had a similar impact on them? <comment><USER2> My top pick would be Antifragile, by Nassim Taleb. In fiction, would be Charles Stross's Accelerando. One teached me how little I really know and how small things can become big ones, the other, how fast things could happen.

</comment><comment><USER3> This sounds a bit strange, I think, but for me it was Arthur C. Clarke's "Childhood's End". It totally shifted the way I look at humanity and society.

The more time passes, the more pertinent that book seems to become.

</comment><comment><USER4> [https://en.wikipedia.org/wiki/Simulacra_and_Simulation](https://en.wikipedia.org/wiki/Simulacra_and_Simulation)

</comment><comment><USER5> Mythical Man Month The moon is a Harsh Mistress</comment>


The man who buried his treasure in a poem - <AUTHOR> http://www.telegraph.co.uk/culture/books/10302886/The-man-who-buried-his-treasure-in-a-poem.html <comment><AUTHOR> Many claim they've solved Forrest Fenn riddle, but treasure hunt continues: [http://www.santafenewmexican.com/news/local_news/many- claim-...](http://www.santafenewmexican.com/news/local_news/many-claim-they- ve-solved-forrest-fenn-riddle-but- treasure/article_3605fc91-a501-5764-b47e-5bf2efdab234.html)</comment>


The Trade of the Century: When George Soros Broke the British Pound - <AUTHOR> http://priceonomics.com/the-trade-of-the-century-when-george-soros-broke/ <comment><USER2> This is the best summary I've read. It details the mechanics of the entire process and the steps that Soros and his fund (Quantum) took to pull the whole thing off.</comment>


Two-way Dataflow in Subtext - <AUTHOR> https://vimeo.com/106073134?1

<comment><AUTHOR> The to-do MVC demo is quite convincing, but it is not clear to me what the flow restrictions outlined in the presentation would mean for a more complex app.</comment>


Shit Programmers Say, Translated - <AUTHOR> https://hackernoon.com/shit-programmers-say-translated-946849c2fbd4 <comment><USER2> They left off "frictionless". I hear that all the time as reasoning for leaving out security and privacy considerations.

</comment><comment><USER3> And product folks wonder why programmers hate them...</comment>


Ask HN: What stretches can I do to prevent long term damage from sitting? - <AUTHOR> So just like many of you, I sit for very long periods of time and work. I've started to feel pain in my forearm and upper back.<p>What are some things I can do to help minimize damage? <comment><USER2> The best thing I've ever done is to not sit for as long as I used to. A convertible standing Desk allows me to switch and I do, all the time.

Iirc I read research showing that no physical activity can compensate for sitting. We need to sit less and move more often, something like every 20-30 min.

As for stretches I'd second physical therapy. For the pain I'd also recommend Feldenkrais as well as Yoga.

<comment><USER3> While that's a great idea, it assumes that people have control over their work environment, which they typically don't. That's why I'm sitting at a flimsy Ikea desk with about 20 square feet of space to myself.

<comment><USER2> What a surgeon recommended to me was "a rigorous 10 minute walk every hour or so"

</comment></comment></comment><comment><USER4> I've been doing this and it's really helped with pain in my back/neck, while improving my posture:

[https://www.youtube.com/watch?v=LT_dFRnmdGs](https://www.youtube.com/watch?v=LT_dFRnmdGs)

</comment><comment><USER5> I would recommend seeing a physical therapist to get started instead of trying to put together s plan yourself, especially since you're already experiencing pain.

Based on my experience I'd also recommend seeing one in a private practice, not attached to a large hospital, but ymmv. Hospital centers I went to would only treat one thing at a time for insurance reasons even though I had two problems.

Anyway, I think good professional guidance will help you recover faster and more completely because they'll be able to identify problems, design solutions, and give you feedback & knowledge more effectively than if you DIY.

<comment><USER6> I agree. I've been a PT, I've done Yoga, stretching, all that usual stuff, and the key to not exacerbating the existing problems is doing it right.

By sitting for hours at a time you're changing the muscle balance of your body - some are turned on for longer, some are turned off entirely. You're tightening muscles while others atrophy over time. You may eventually find that there are muscles you're unable to consciously relax, and this could be a source of pain.

Other issues brought on by this include skeletal alignment problems, such as slumping forward or head rolled back, and not using joints correctly.

This takes knowledge to correct, and while it may seem quite simple even a small change can have a large impact. Consider shoe inserts for an example of this.

TL;DR is "See an appropriate qualified medical practitioner."

It's worth noting that you should find someone who does specialize in this field. I had knee problems for a while, and my doctor diagnosed me with having weak muscles in my knees. She gave me exercises that didn't help, and after a few months of more pain, I approached a sports physio who took quick look and gave me stretches to fix the muscle tension in my anterior thighs. Don't waste your time with alternative medicine such as chiropractic. Yoga may have some value, but more as a preventative than a complete cure, although nothing beats standing up and going for a walk for a few minutes every 20 minutes, though. When you've had a correct postural alignment pointed out to you, you'll recognize the proper relaxed state.

</comment></comment><comment><USER7> Recently started doing the Jefferson Curl after hearing about it on Tim Ferriss's podcast. Huge impact, my back began to improve right away > [http://fourhourworkweek.com/2016/05/09/the-secrets-of- gymnas...](http://fourhourworkweek.com/2016/05/09/the-secrets-of-gymnastic- strength-training/)

<comment><USER8> Why would you link to a page that contains a link to the podcast episode? It would have been better to post a link to a page explaining the Jefferson Curl because that's what most people who read your comment are interested in.

You know, just because you mention something in a comment doesn't mean you have to post a link to it. I can only assume you receive a portion of the revenue that podcast generates, is that true?

For example, if the phrase "Tim Ferriss's podcast" interested me at all, how difficult do you think it would be for me, a regular reader of HN, do find that information myself?

Sorry for the length of this comment, I just get confused by the hero worship that I see around here.

</comment></comment><comment><USER9> I suspect each person truly needs different supports.

I have fallen in love with the material from Eric Goodman. His company is called Foundation Training, and he has a lot of freebies on YouTube.

I would say, with no hyperbole, his simple exercises have changed the way I walk, stand, and move in general, and they have been the antidote to my hours at a desk.

Maybe it will be valuable for you!

</comment><comment><USER10> Related discussion: [https://news.ycombinator.com/item?id=12652368](https://news.ycombinator.com/item?id=12652368)

</comment><comment><USER11> Obviously: don't sit for very long periods of time.

Stand up and walk for a minute every fifteen to thirty minutes can help a lot, and also is an opportunity to reflect on the work you just did. Not typing isn't a synonym for not working.

</comment><comment><USER12> [https://news.ycombinator.com/item?id=12205854](https://news.ycombinator.com/item?id=12205854)</comment>