Concurrent JavaScript: It can work - <AUTHOR> https://webkit.org/blog/7846/concurrent-javascript-it-can-work/ <comment><USER2> Of course the language can be made to support it. Given the way Javascript is used, the question is whether supporting it will create a big mess.

They have some good ideas. One is that variables can be marked as restricted to one thread. That should be the default. Other languages could benefit from that feature. Python, for example. If you want to get rid of the Global Interpreter Lock, knowing which variables can't be shared between threads is a big help.

Variables should be owned by a thread or owned by a lock. Rust went that way, and it works well. The proposal here is old C-style locking, where there are locks and variables, but the language doesn't know which locks are protecting which variables.

<comment><USER3> I think it would be weird if objects were thread-restricted by default. Concurrency is most fun when it's easy for a thread to access an object it wants.

<comment><USER4> You say fun, but what you mean is twisted mess.

<comment><USER3> WebKit uses threads. WebKit is not a twisted mess.

<comment><USER5> WebKit needs tons of extra effort to keep it from being a twisted mess precisely because it uses threads.

<comment><USER6> Any well written software requires effort to properly design and maintain. What's the argument here? "Don't give them shotguns, they might shoot themselves"?

<comment><USER7> Don't load the shotguns, turn off the safety, point it at their foot and tell them "please be careful".

</comment></comment></comment></comment></comment></comment></comment><comment><USER8> I'm late to the party but please for anyone reading this, look into the actor model. Shared mutable state quickly becomes unmaintainanble. It used to be slow to do shared immutable state but that's no longer the case. Today there are many better ways to do shared memory with copy-on-write so data is only copied if it's changed. Think back on history - there are only a handful of computation approaches that have stood the test of time. Pipes in unix, spreadsheets, data management systems like MS Access or FileMaker. Had concepts from those programs made it into programming, our lives would be a lot simpler today. We don't need to torture ourselves for imagined efficiency by copying the C threading model that quickly dissolves into spaghetti.

<comment><USER9> > there are only a handful of computation approaches that have stood the test > of time. Pipes in unix, spreadsheets, data management systems like MS Access > or FileMaker. Had concepts from those programs made it into programming, our > lives would be a lot simpler today.

Can you go into more detail on which concepts from Pipes in unix, spreadsheets, data management systems like MS Access or FileMaker you're thinking of? My familiarity with the tools is leading to blindness about application...

<comment><USER8> Ya what I was trying to say for each of those is:

Pipes/streams: one way channels between isolated executables

Spreadsheets: the only form of functional programming that's reached mass adoption (equivalent to lisp for the most part)

DBMS: the only form of declarative programming other than the web that's reached mass adoption. In this case the view has two-way binding to the data, but relationships are declarative and the controller has been abstracted into the GUI and event callbacks on buttons etc (controller is the weakest portion of MVC)

All of these concepts could/should make it into mainstream programming languages. Try searching for Redux, Elm, software transactional memory, the Clojure state store, coroutines (which are interchangeable with state machines but without goto).

I believe that we can use all of these techniques without the ugly syntax of functional programming languages like Haskell, Scala, R, etc. For example Elixir is trying to be a kinder, gentler Erlang.

</comment></comment></comment><comment><USER10> Please, no. Shared-by-default heap memory is one of the greatest mistakes ever made in language design. We need a better design justification than it's the easiest thing to implement right now.

<comment><USER11> The justification is that when you have an array of 100000 elements and split it into into isolated chunks that can be processed without any synchronisation and then marshall it into json and then actually do the computation and then marshall the result into a json string and marshall it back into a javascript array is very wasteful. Heck even when I'm passing immutable messages I'd still implement it via shared memory to avoid the wasteful marshalling step.

<comment><USER12> Fork/join on arrays and trees would be an easier to manage model, IMO.

<comment><USER3> You can implement that on top of threads.

<comment><USER12> Of course you can. You can implement anything on top of threads, especially non-determinism, race conditions and deadlocks.

<comment><USER13> Event loops have these too, they just go by different names:

* non-determinism -> order in which setTimeouts run

* race conditions -> callbacks happen in an unexpected order

* deadlock -> broken callback chain

<comment> a-kojeve Yeah, but nobody relies on the execution order of disparate callbacks to achieve their results in JS. You're going to get burned in like two seconds if you try to do anything you listed. Lower level concurrency primitives in other languages allow developers to build fragile solutions which work 99% of the time until they deadlock and everything blows up. The concurrency model in JS is very explicit about being "no guaruntees."

<comment><USER3> There are many reasons why complex software fails in the 1% case. Concurrency is not the only reason. In my experience it is not the top reason. Our top hard-to-repro or no-repro crashes in JavaScriptCore are from non determinism introduced by the workload itself. Inside our engine we have many sources of nondeterminism that manifests even with concurrency features disabled.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER12> It's awesome to see work on concurrency, but I'd really like to se a model that didn't involve shared memory.

JavaScript on the web already has the concept of Transferrables. It'd be great to explore how user-land code could create transferrable objects and graphs of them so they could be sent between threads without threads sharing the same heap.

<comment><USER14> Sorry, but we need shared memory for fast sharing of large immutable data structures.

<comment><USER12> Then add immutable objects to JS, which enable a host of other optimizations and are useful in single-threaded contexts too.

Shared-memory multithreading is just very difficult to use correctly. Actor- style concurrency hasn't really caught on (possibly because of the poor performance of workers and postMessage), but there is probably a middle ground that's easier for developers to get right.

<comment><USER15> JS already supports immutable objects, by using Object.freeze().

<comment><USER16> That doesn't really make things immutable. Even ignoring the deep vs shallow issue, consider what effect Object.freeze has on a JS Map (hint: none, really; you can still add/remove things).

<comment><USER15> Right, that's where libraries like ImmutableJS come in.

</comment></comment></comment></comment></comment></comment><comment><USER17> I feel like most of the comments here are ignoring the fact that this is a _straw man_ proposal, as the blog post emphasises several times.

They aren't proposing to add threads to JS in exactly this manner. They're pointing out that it would be _technically feasible_ , for WebKit at least, and wouldn't add any unnecessary overhead. The specific proposal is just a starting point for discussion.

</comment><comment><USER18> JS already has a proper concurrency model which is the event loop. What it doesn't have is a model for parallelism. It's important to understand the difference! It can be hard to grasp at first, because few people make the proper distinction.

If you're new to the subject, don't take my word on it, but watch the talk "Concurrency is not parallelism" by Rob Pike[0]. It's highly recommended.

Learning a language that makes a proper distinction will help - I got it through Clojure, but there's certainly others like (obviously) Golang.

0\. [https://youtu.be/cN_DpYBzKso](https://youtu.be/cN_DpYBzKso)

<comment><USER3> Even loop is not concurrency.

Just because concurrency and parallelism are different does not meant that concurrency and event loops are the same.

<comment><USER19> How? Explain please. [https://en.wikipedia.org/wiki/Concurrency_(computer_science)](https://en.wikipedia.org/wiki/Concurrency_\(computer_science\))

"order-independent components", which makes sense for the Event loop.

<comment><USER3> I draw the line at whether the interleaving granule is under the programmer's control or not.

For example, I can say that _when a task executes on an event loop, no other tasks are executing concurrently to it because the event loop executes tasks sequentially_.

<comment><USER19> Ok you draw the line there, but definitions are supposed to be commonly understood, that's how language works...

<comment><USER3> Yeah, I agree it would be better if people in the event loop community learned to use the word "concurrency" correctly.

</comment></comment></comment></comment></comment></comment><comment><USER16> What's not quite clear to me is whether "the cell never moves" is one of the assumptions that actually goes into making this work or not. And if it is, how that plays with a compacting or generational collector, where you do in fact want the cell to move.

<comment><USER3> From the standpoint of the concurrency scheme I'm proposing, it's OK to move the cell in the GC. Then it becomes a standard GC moving problem.

In JSC we don't move cells for other reasons, and the point of saying that they don't move is that the object model itself does not require the cell to ever move.

<comment><USER16> Thank you for the explanation!

</comment></comment></comment><comment><USER20> Genuine question: Aren't locks a quagmire in terms of lock management? Why start there?

<comment><USER3> All of the alternatives are an even bigger quagmire.

</comment></comment><comment><USER21> JavaScript is already concurrent. It isn't parallel though.

Is there any real world application that currently cannot exist without this feature? It seems like a solution looking for a problem.

I can see needing the ability for parallel JS for highly-parallel compute- heavy applications but those already seem serviced by SharedArrayBuffer.

So... why?

</comment><comment><USER22> Forgive the ignorance, but why do we need threads when we already have the event loop?

And, as a follow-up, why introduce a new concurrency model that's based on Java instead of, say, creating a concurrent "event pool" where execution order isn't guaranteed and callbacks are executed with maximum concurrency (edit: to clarify, I mean maximum parallelism)?

<comment><USER23> Event loops are great for handling work that can be handed off occasionally to worker threads (like how Node works with libuv), but are awful when doing consistent CPU-bound work, such as with games, 2D/3D visualizations, finance, and the like.

SharedArrayBuffer is a nice primitive that allows multiple Threads (or WebWorkers) to work on data in parallel. The additional primitives they're proposing offer quite a bit of flexibility. For one, I would really like an easy `new Thread(fn).asyncJoin()` to create a Promise to do expensive CPU- bound work. There are a few npm modules that do some version of this but it can be slow.

As for the concurrency model, it should be possible to delegate tasks to a pool in this one. Map an array of input data and functions to an array of promises, then Promise.all() or Promise.race() on them.

<comment><USER24> I think that kind of stuff it much more relevant in the land of WebAssembly. It _certainly_ makes sense there, but in normal JS, I doubt the usefulness.

<comment><USER23> It depends. It could be very useful for React/React Native, for one.

</comment></comment></comment></comment><comment><USER25> One other thing to consider, the SharedArrayBuffer can only carry limited data types, it's not a shared object. I used Flash's SharedArrayBuffer and found it was very limited in what you could use it for.

</comment><comment><USER6> This is very interesting. If this is indeed implemented, it will remove a serious hurdle from the equation of RN. Still JS, but the ceiling will go up considerably.

</comment><comment><USER26> JavaScript should just copy the Tcl threading model.

</comment><comment><USER27> They mean parallelism, right? Concurrency is what JS is already known for.

<comment><USER28> Yeah, JS definitely has concurrency. He's just twisting the term a bit into his world of shared-memory multithreading to make his model sound superior to other concurrency models.

</comment></comment><comment><USER29> Or use ClojureScript with core.async - which implements a go-like concurrency model. (Not saying that's fully or equivalent, or meant to denigrate this interesting work.)

</comment><comment><USER30> Yeah, and lets have the gazillion scripts, loaded by your usual favourite news site, spawn 10 threads each...

For browsers, this is a bad idea. The biggest advantage of the event loop approach is that it is somewhat deterministic. With threads, that determinism goes out of the window. Lock-management? No way I do that for Browsers. I will quit working on client-side code if that is becoming a requirement!

Threads for the server-side? I don't care.

<comment><USER31> Whether it's a good addition to the language or not is debatable, but as a browser feature, it sounds terrifying. Browsers have a huge attack surface as it is (I mean, WebGL is a thing – exposing GPU drivers to random untrusted code on the internet, what a brilliant idea...), and exposing threading will only make it worse. Every single API would have to be carefully audited and made thread-safe, and I'm sure that many 'fun' bugs would crop up as a result.

<comment><USER32> Which is why the proposal specifically says that only a few DOM APIs would be exposed to background threads (Like console.log())</comment></comment></comment>


A QML engine in a web browser - <AUTHOR> https://qmlweb.github.io/ <comment><USER2> I couldn't find more advance examples than this Hello World one, did anyone find any?

<comment><USER3> Examples of QML? How about official docs [http://doc.qt.io/qt-4.8/qdeclarativeexamples.html](http://doc.qt.io/qt-4.8/qdeclarativeexamples.html)</comment></comment>


Popsong Piracy: Napster in the 1930s and the Story of Fakebooks (2004) - <AUTHOR> http://www.stayfreemagazine.org/archives/22/piracy-fakebooks.html

<comment><USER2> Fakebooks still persist these days in the shape and form of PDF torrents of songbooks. Just go on Amazon and search for your artists (e.g., Adele/White Stripes/Eric Clapton) and chances there is an official songbook for their albums and corresponding seeded torrent. With YouTube version/lessons of the songs and PDF of the song tabulature, someone can learn to play a lot of classic's and modern songs. I should also add, Eric Clapton shouldn't get mad as that's exactly what he did back in his teenage days (source: "Clapton" autobiography), playing back to the blues greats on his recorder and replicating their songs exactly without paying any royalty.

</comment><comment><USER3> I'm a jazz musician, and even within the last few years, I've seen musicians pull out pages copied from those old Tune-Dex cards.

>>>>> The law had attempted to express a prohibition but that prohibition had been repeatedly ignored, and hereafter it would be permanently ignored. There were no further federal trials surround-ing bootleg fake books. Compared to the new problems raised by record and movie piracy from the 1970s onward, prosecuting fake-books was no longer worth the effort.

Today, the most common mechanism for enforcement of performance rights for copyrighted songs is to go after the venues that host live music, rather than the musicians themselves. A restaurant or bar that hosts live music will get a visit from a representative of ASCAP or BMI, to arrange for a license that covers the performances of musicians.

</comment><comment><USER4> Seeqpod was my favorite but then came spotify. Music streaming is certainly the future.

</comment><comment><USER5> Reminds me of the time in grade 3 my music teacher told me about Mozart and how he was arrested as a kid for transcribing a song he heard because people thought he "stole" it. I thought no way adults are this stupid.

<comment><USER6> You're thinking of the Allegri _Miserere_?

<comment><USER5> the story checks out yeah.

what a wonderful song I'm listening to it now.</comment></comment></comment>


Prolific Engineers Take Small Bites - <AUTHOR> https://blog.gitprime.com/check-in-frequency-and-codebase-impact-the-surprising-correlation/ <comment><USER2> This post is a good example of my current issues with modern data journalism as content marketing: you can say _anything you want_ without evidence to back it up, but hey, there's a pretty chart, so it doesn't matter. (In this blog post, the data points _don 't correspond to actual data!_)

This is also the primary reason I have switched to Jupyter/R Notebooks for my blog posts: if I make ridiculous claims, people can check my work as evidence. This post doesn't even provide any quantifiable metrics, just "we analyzed millions of commits."

<comment><USER3> I just got done staring at some code written by a prolific upper quadrant coder, that I'm going to have to noodle on and figure out how to disentangle some bad design decisions. I might be able to do a fairly short commit to refactor and extend, in which case my metrics will be crap. I might wind up looking at all the outstanding issues with this codebase and rewrite every class in this directory (in which case my LoC metrics will improve dramatically). Right now I'm probably one of those "stuck" coders that need "help". Kinda? But most software developers hit problems like this and run away in terror, and looking around me IDK who can really help me that much, I'll run my ideas by some colleagues, but the other ones who work on problems this gnarly are also neck deep in their own issues...

<comment><USER4> Mikado Method might offer you some clues, or at least confirm some of your existing habits.

Basically, start a top-down refactor. When you find the bottom you stop, revert your code, and refactor from the bottom up.

You probably won't find the actual bottom, but in my experience the moment when I was about to give up and call it quits was usually just before I reached the bottom. Taking a break, and starting over from the spot where I stopped, usually the solution became obvious, and far less invasive than I expected.

<comment><USER5> Do I understand this correctly:

You start refactoring at a high level -- essentially set out to rewrite the whole chunk of code in which your refactoring work lies. And focus on the most important until you get to the inner-most structure.

Then when you are to the "sum(a,b)" level you start over with the original code base and refactor bottom up. With the knowledge of how it works all the way up to the top? Re-creating your original refactorings?

It seems interesting. Like tackling a math problem or puzzle from two directions. Are there certain situations in which it is most effective? Architectures? Paradigms?

<comment><USER4> Most refactoring is from the bottom up. Make the change easy, then make the easy change. I said "start a top down refactor" but redesigning from the top or all at once isn't really refactoring. Some of the actions look similar but you get few of the benefits of refactoring.

When the architecture problem has gotten away from you, or only becomes apparent late in the project, it's hard to see the trees for the forest. The only way to decompose the problem is to start somewhere and see what happens. With a top down rewrite the number of bits in flux becomes overwhelming, which is the anxiety I picked up from the previous commenter.

Mikado is just an exploratory development trick to help you find a way to make the change with refactoring. You try rewriting pieces until the number of concerns starts to multiply, you keep going essentially until your brain starts telling you, "this is nuts, you should stop", and you take that detail that broke the camel's back and do just that part, and build up and out from there.

</comment></comment></comment></comment></comment><comment><USER6> Non-technical co-founder of Git analysis tool writes blog post that makes assertions about all sorts of things and then justifies this with mockup charts whose axes are unlabeled. Then offers tools to help micro-manage engineers.

<comment><USER7> @trevyn Co-founder here.

You're right: this post is a narrative about product development, and a strong correlation we found between two variables across 20 Million+ commits that we thought was fascinating and supports general 'kitchen logic' around best practices. The axes are not labeled, but if you like we can set you up with a demo account and walk through your data with you.

One other note: the typical common use case for the product has been stakeholder management; something we have doubled down on in product development. Any specific critique about how we can improve most welcome!

<comment><USER8> > The axes are not labeled, but if you like we can set you up with a demo > account and walk through your data with you.

Really? Rather than going back and labeling you axes you are converting this into a sales call???

<comment><USER7> My actual suggestion was to hop on with the product team/co-founder. This article is a narrative about something we found pretty interesting during product development.

Similarly, the offer here is to take a deeper look at what we're building and a (quite genuine) offer to incorporate any suggestions you might have into our roadmap.

<comment><USER9> Congratulations, you have completely missed the point.

</comment></comment></comment></comment></comment><comment><USER10> Neither in the article or in the referenced article/blog post linked to "Impact" is impact defined.

[https://blog.gitprime.com/impact-a-better-way-to-measure- cod...](https://blog.gitprime.com/impact-a-better-way-to-measure-codebase- change)

      What I found is:

Impact takes the following into account:

        The amount of code in the change
        What percentage of the work is edits to old code
        The surface area of the change (think 'number of edit locations')
        The number of files affected
        The severity of changes when old code is modified
        How this change compares to others from the project history

No exact or detailed formula for "impact" is given. "takes the following into account" is extremely vague as it could indicate any relationship. Is impact higher with more files changed in the commit? Why would it be better if more files are changed? Is it lower? Why would it be better if fewer files are changed? Is it some totally unobvious non-linear function such as a trigonometric sine?

Based on the vague description above, nothing in "impact" is directly related to the actual end user/paying customer experience or a reasonable proxy such as systematic end user testing by a QA team.

This lack of a direct relationship to the desired end result is the same problem that lines of code (loc or LoC) and many other metrics of software engineer output have.

The "impact" metric, whatever it precisely is, looks suspiciously like it would naturally be positively correlated with a large number of commits/high frequency of commits.

Also the plot is labeled with "volume" on the horizontal axis and not the mysterious "impact" metric. The text implies this horizontal axis is the "impact" metric. Why is the horizontal axis not labeled impact?

Even more peculiar, "impact" is claimed to measure cognitive load:

Impact attempts to answer the question: "Roughly how much cognitive load did the engineer carry when implementing these changes?"

A good engineer will attempt to find a low or no cognitive load solution to a problem! In general this will be faster and less error prone and cheaper! Reinventing the wheel has a very high cognitive load.

<comment><USER11> Not to mention that's a pretty easy to game metric. By that rational, renaming a variable name across a few files is going to make me quite impactful.

If my job were being judged by this metric, I'd sure be thinking a lot about that.

This measurement also seems to favor overengineering, which is one of the biggest things I've learned to stay away from. When I was early on in my career, I thought I could implement anything myself, and so I often did. It wasn't until years later that I understand the implications of maintaining these implementations.

A true measure of impact to me would be a ratio of the most concise (but still understandable) amount of code to the amount that it solves the requirement it's built for. It's impossible to measure that without the context of the problem you are trying to solve.

</comment></comment><comment><USER12> The title, well actually the entire article, is one of those things where A -> B is stated, well knowing (and almost expecting) that readers will understand it as B -> A or B <-> A. It's the developer version of the typical _" 10 Things Successful People Do_" clickbait.

Yes, a lot of (although far from all!) good coders have the habit of taking small bites. That doesn't mean though that by taking smaller bites you are (or are becoming) a good coder. I've had the past displeasure of dealing with code that hit all the superficial checkmarks (small commits, unit-tested, peer- reviewed, you name it...) yet completely stunk.

</comment><comment><USER13> Jesus that site was annoying. I go to read the article, and a popup beeps at me distracting me. I think "what the hell is this crap" and move my mouse towards the "about" page. A pop-up pops up (as they do) and distracts me from even that.

Both times I tried to get information out of their site they found a way to interrupt me.

Then I leave without reading the article.

<comment><USER14> Heard of Adblocker much? I didn't have your experience on that page :)

<comment><USER13> I've got ublock installed under ff, and there weren't popups in the sense of a new window, but in the sense of an in page element.

</comment></comment></comment><comment><USER15> I large agree with this, although with some provisos.

First of all, sometimes it's most useful to take a step back and think about problems in a wider context. Often the biggest impact is from the code you don't write. There's really no way those kinds of contributions come out in any kind of metrics, but the team will sure remember them.

More commonly, I prefer to commit often to aid my dev process but then rebase those commits into more cohesive units before merging. How chunky to make those final commits is somewhat a matter of taste, and probably shaped by the domain one is working in. Personally I like the finest grain possible without any build breakage, that way git-bisect still works, but hopefully there's still enough granularity to help with trickier merge/rebase scenarios around dependency upgrades and/or db migrations. But pardoning the digression, my point is the output seen by the rest of the team may not represent the original frequency of commits.

<comment><USER16> I tend towards larger commits, large enough that the commit message can be more "why" than "what". That way git blame works better.

(My issue tracker isn't coupled to my repo, and bisect is mostly useless for me because my builds take so long. So like you said, depends on the codebase.)

</comment></comment><comment><USER17> Title of the article uses the word "Engineers" rather than software engineers, and if you lump together virtually anybody who makes changes to a code base (testers, sw architects, sw leads, etc), it seems like its easy to have the data obviously skewed by people who essentially spam the commit process. I think most people can look at a commit log and sort of eye-ball who are the people who really make shit happen on a project--and who is probably causing more grief than anybody else. I agree its hard to quantify, but to be honest I didn't take away much from this article. I like the goal of the article, just think it didn't really hit the mark.

</comment><comment><USER18> Extrapolating a "prolific engineer" from one's commit log is no less absurd than from lines of code.

Their methodology fails to account for so many things, commit squashing feature branches, for example. A fundamentally flawed "study".

<comment><USER19> The methodology also suggests a particular workflow is better. A workflow where you commit and merge, instead of commit, rebase, then merge.

</comment></comment><comment><USER20> What are they measuring? Public git repositories? The article doesn't say anything about whatever data is being analyzed. If its public git that's hardly comparable to a large corporate entity.

</comment><comment><USER21> Analyzing churn is tricky and can be easily misinterpreted by management. This reminds me of what was revealed from studies in behavioral sciences and presented by Dan Ariely: [https://www.youtube.com/watch?v=Q92BqouxyX4](https://www.youtube.com/watch?v=Q92BqouxyX4)

</comment><comment><USER22> Can you make any claims about the number of commits? That's another metric that changes depending on tools and processes.

If you're using a code review tool well (if you are more experienced with it) then you'll automatically be making lots of small commits vs people that may not be well versed in working that way.

If you're working with large or prolific teams then you'll be committing all the time with eg feature toggles to ensure everyone is as close to the current code with their changes as possible.

So making general claims about more commits without taking into consideration the ways that metric is bent and changes with tools and processes and different experiences seems to be dangerous.

</comment><comment><USER23> Unless I'm missing something, how is 'Impact' derived here?

Impact as a metric is fine, but you have to show what it is and how you arrived at that conclusion, and have verified that against a test set of data otherwise it's turtles all the way down.

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

</comment><comment><USER24> This article and company can be safely ignored.

</comment><comment><USER25> We have a hard rule that you do not commit code that doesn't pass unit tests.

This leads to bad coders not being able to commit as frequently as good coders.

However, this seems like a very, very loose heuristic.

</comment><comment><USER26> Huh, strange. My made up charts say something completely different.

</comment><comment> awinter-py concepts missing from the article: 'staging' and 'commit size'.

People who have worked in code review shops tend to stage their commits, i.e. do a bunch of work but commit it with git commit -p.

Article also doesn't look at deployment frequency, and 'merge' appears only once. We don't know if these 'high impact' devs are in their own branch for 6 weeks cooking up the PR from hell. That's one way to have a high impact.

</comment><comment><USER27> I'm curious what the general vehemence is to quantifying and understanding this information is? It's right there in your commit history. I've run my own analyses out of curiosity in the past... statistics just isn't my favourite subject. I think it's an interesting metric and I'd certainly like to know more about how it's calculated.

(Although I'm sure that's part of the secret sauce).

<comment><USER28> I think people get uncomfortable because people will run with the data and enact policies that are potentially detrimental, and then people will game it. (You see this happen all the time with "velocity" at agile shops). Data itself is great, it's just scary what happens with it when it falls into unwise hands.

</comment></comment><comment><USER29> We tried this. It gave us an unmaintainable code base that our platform could no longer add features unless we threw so many people at it.

</comment><comment><USER30> Well I guess I'd be labelled a poor programmer since I wait to commit until my code has passed a few core specification tests.

</comment><comment><USER29> We tried this. Fast commits for small features gave us an unmaintainable code base that eventually didn't work anymore.

</comment><comment><USER31> This reminds me that one of the things I loved about working on server-side efficiency is that for any given diff, you can measure the performance improvement, multiply by hardware costs, and say, "That diff saved $X." Makes it really easy to measure impact and feel that my salary is justified.

<comment><USER32> That is one side to the coin, however if you made a change that was a performance improvement yet the code was highly cryptic and hard for anyone else to understand then this wouldn't be a good thing.

Essentially what I'm getting at is that peer review from team members is the best metric for what is good and isn't.

<comment><USER31> Absolutely true. Still, it helps when one side of the coin is precisely quantifiable, since it helps frame the more subjective questions like code complexity.

</comment></comment></comment><comment><USER33> This is misleading, however I would like to point out that if Small Bites == Kaizen. Then, Prolific Engineers like any other prolific professionals may be Kizening the crap out of their codebases. No data here either to back the smart ones up though.

</comment><comment><USER34> Unfortunately know some bottom-right quadrant people. We got rid of some of those not too long ago - wouldn't want them on my team again. Super hard to manage and work with.

</comment><comment><USER35> How do you finish a project ? One step at a time !

</comment><comment><USER36> There's a great, fun, programmer-centric website called thedailywtf.com (sorry, I just scheduled the rest of your afternoon for you). Developers can submit WTF's that they've found in other's code - as the site admin says, "curious perversions in information technology".

One thing that strikes me about the majority of the submissions, as funny as they are, is that they mostly boil down to "so-and-so didn't know that such- and-such feature existed, so wrote reams of code to implement that feature in a complex way". It also strikes me that just this article's sort of analysis of "prolific" (aka "good") engineers/programmers drives this same sort of behavior. If every developer is supposed to be committing code all day, every day, there's no time left over to read the product documentation, try out a new feature, review a reference implementation, read a blog post: to be "good", you must be spending as much time as possible _typing_, because that's what you're paid to do. This (ubiquitous) management mentality is how we end up with roll-your-own crypto, or five competing Javascript frameworks, parsing using regular expressions... it's not so much that what they did was wrong - and trust me, if it works, it won't be removed - it's that it's pointless.

<comment><USER37> It can also work the opposite way. You can think you understand the requirements and go hole yourself away for a couple of days pumping out code. When you finally merge your work, another developer tells you, "Why didn't you just use function X or package Y?".

If you're doing your work in small, sharp bursts, you actually end up with more time in between work for talking with other devs, reading up on technology, etc.

<comment><USER38> I think this is the better insight.

A lot of DailyWTF posts are about people not knowing a function existed _and then reimplementing it horribly_. Many of them include a note like "the other 10,000 lines were similar".

Ignorance is not embarrassing, it's the default state when all of our tools grow and change daily. But a lot of the worst wtf moments are clearly cases where something wasn't sanity checked by anyone until it was presented as a finished product - sometimes too late to keep out of production. That's the benefit of frequent commits, reviews, and research breaks; they might not prevent our ignorance, but they keep it under control.</comment></comment></comment>


Apple retail chief Angela Ahrendts: We will not upsell customers to the iPhone X - <AUTHOR> https://www.cnbc.com/2017/10/20/angela-ahrendts-apple-retail-senior-vp-interview.html <comment><USER2> It was very weird to see people take on this pearl-clutching tone when it was announced the iPhone X would cost a thousand dollars. "Can you believe how much the new iPhone costs?" If that's too much for you then buy the one that costs the same as the last few iPhones did when they came out.</comment>


Hipstamatic lays off all but core employees, including designers and engineers - <AUTHOR> http://thenextweb.com/insider/2012/08/16/hipsta-dramatic-hipstamatic-lays-core-employees-including-designers-engineers/

<comment><USER2> If the product was seriously making money and growing then they should've raised money. The problem with bootstrapping and growing a team like this is if you have a bad month you can run out of money near-instantly. You have little runway. I'm not sure if this was a killer product but they did stay in the app store top 10 constantly with a paid product.

I know they may have bigger fish to fry but the founding team would've been good to find a company to take on this team, I know a few and there's some very talented folks in there. I know almost all of them will get hired quickly but as they let them go instantly with no warning it seems unfair.

Also I'm not sure how this company can function with only "core employees" if none of them are designers or engineers. As they're bootstrapped I'm guessing they're going to just live on whatever revenue they have and work on something else or just leave it, as they probably have enough to pay for themselves but not a whole team.

<comment><USER3> I think that headline is ambiguous; just because they laid off a lot of people _including designers and engineers_ doesn't mean that the core team doesn't consist of designers and engineers.</comment></comment>


Ask HN: Thoughts On What The New HN Feature Might Be? - <AUTHOR>

Sam Altman tweeted yesterday saying there is a new feature coming to HN. Any thoughts? <comment><AUTHOR> [https://twitter.com/sama/status/484504242938331136](https://twitter.com/sama/status/484504242938331136)</comment>


IRS hasnt implemented more than 100 federal cybersecurity recommendations - <AUTHOR> https://www.fifthdomain.com/civilian/2020/05/20/irs-hasnt-implemented-more-than-100-federal-watchdogs-cybersecurity-recommendations/ <comment><USER2> It is not linked in the article, but here is a link to the PDF of the GAO report: [https://www.gao.gov/assets/710/706908.pdf](https://www.gao.gov/assets/710/706908.pdf)

"Improvements Are Needed to Enhance the Internal Revenue Service's Information System Security Controls" ([https://www.gao.gov/products/GAO-20-411R](https://www.gao.gov/products/GAO-20-411R))</comment>


Sim-free iphone? Don't insert an EE sim card - <AUTHOR> https://ee.response.lithium.com/portal/conversation/1284584

<comment><USER2> Someone care to explain what's going on here?

<comment><USER3> Reading further down the Twitter conversation it sounds like if you don't buy your iPhone outright from the Apple Store it'll lock to the first carrier you try to connect it to. The lady on Twitter was pissed because she had a unlocked phone, put an EE pay-as-you-go SIM in it on a 30 day contract, only to find EE had locked her iPhone to EE, and wouldn't unlock for 6 months.

<comment><USER4> Looks like it's an Apple / iPhone 'feature' [0] so not directly EE's fault or intention. EE's initial response was quite unhelpful though, probably through misunderstanding. After all, who expects an unlocked phone to magically lock itself?

[0] [http://selfhelp.carphonewarehouse.com/SelfHelp/request.do?vi...](http://selfhelp.carphonewarehouse.com/SelfHelp/request.do?view\(\)=c%7Bd9c6aeb0-f0d2-11e0-763b-f20203001e3d%7D)

</comment></comment></comment><comment><USER5> Interesting, I've heard of this before with Orange (the parent company of EE). A former colleague had used her sim lock free phone with an Orange SIM, after which the phone would no longer accept non-Orange SIMs. The response from Orange was nearly identical in her case and I don't think she ever got it resolved.

</comment><comment><USER6> I don't think EE has the ability to carrier lock an unlocked phone. My guess is that she bought an EE locked phone. Maybe the salesman at CPW made a mistake or was running a little scam. If this were generally happening we would have heard about it before now

</comment><comment><USER7> Why is this even possible, technologically speaking. Why did anyone think that designing a system that gives this kind of control over your phone to your carrier was a good idea. More importantly, why didn't anyone complain?

<comment><USER8> Apple is 100% in bed with the carriers. "Carrier support" bundles include a lengthy list of lockdown features that Apple develops and supports, including the ability for your carrier to:

\- turn off tethering (the OS 'helpfully' will give you the carrier's phone number to call to let tethering-colored bits through and to collect their fee) \- neuter FaceTime to only work over wi-fi \- prohibit you from editing the APNs in use \- force your iPhone to always connect to an arbitrary wi-fi hotspot without prompting \- automatically add the carrier's stock ticker to the stock app

Source: [http://theiphonewiki.com/wiki/Carrier.plist](http://theiphonewiki.com/wiki/Carrier.plist)

Apple has developed these malfeatures and continues to add new ones, showing you who their real customers are. Let's not even get into how screwed up the locking system is (you can _never_ really, permanently, 100% unlock an iPhone.)</comment></comment>


All social apps end up becoming content apps, or else. - <AUTHOR> http://rajibedi.tumblr.com/post/31783309650/all-social-apps-end-up-becoming-content-apps-or-else

<comment><AUTHOR> May sound trivial, but if product decisions are based on the value of the data they produce, the feature pipeline for a product could look a lot different.</comment>


Augmented Reality comes to Real Estate - <AUTHOR> http://www.nytimes.com/2010/03/26/greathomesanddestinations/26iht-rear.html?ref=technology

<comment><USER2> I'm going to make a bold assertion here: This is useless.

This kind of "augmented reality" (I think it diminishes reality) is a usability disaster. It's basically the worst possible way to display information about locations. Maps offer so many more advantages that it makes it hard to find _any_ way to justify Layar.

<comment><USER3> I think one of the biggest hinderances to "augmented reality" is the currently available viewers. Holding up an iPhone or some other smart device to look through its small screen doesn't cut it. The concept is powerful, the usability is awful.

The smart device needs to be used as sender / receiver of data, not as the viewing tool. If there were glasses that could synch with your smart device and semi-transparently overlay whatever augmented reality layer you wanted to currently view, then you have something that is very powerful AND usable.</comment></comment>


If you gaze into nil, nil gazes also into you - <AUTHOR> http://robots.thoughtbot.com/post/8181879506/if-you-gaze-into-nil-nil-gazes-also-into-you

<comment><USER2> This is very consultant-y code. It's great billable time to have another reason to take 1 line of code with a predicate and "refactor" it into a broccoli floret of mock classes and exception handlers. But really, nothing insulates a competent programmer from needing to know what a library is going to return.

<comment><USER3> Exactly, they have traded .nil? for .present? and added complexity.

</comment></comment><comment><USER4> I think this is mostly a workaround for a huge flaw in most languages—especially one as dynamic as ruby. Nil should accept any method and return nil.

This is the pattern that Objective-C embraces, and it works very well. You can chain method calls to nil and get nil as the result of the expression, should any method return nil. You end up with cleaner, more readable code. Sure, it makes some edge cases harder to debug, but not by very much. In this case, the benefits far outweigh the code. You'd simply end up with:

      def admin_of?(project)
        membership_for(project).admin? || false
      end

Additionally since nil is falsy, you could even skip the `|| false`, and any `if u.admin_of? p` statement would still work. (Not recommended, but just pointing it out.)

      def admin_of?(project)
        membership_for(project).admin?
      end

<comment><USER5> In Ruby nil can receive any method and return nil:

      class NilClass; def method_missing(*args); nil; end; end

The problem? It makes code fail late and siltently, which can happen with a simple mispeling of key names on hashes.

In ruby, Andand allows you to solve this more locally: <http://andand.rubyforge.org/>

<comment><USER6> andand doesn't seem any different than using try(:method), which is defined in Rails 2.3+ for the Object class:

      > nil.try(:name)                     #==> nil
      > User.first.try(:name)              #==>"john doe"
      > nil.try(:name).try(:upcase)        #==> nil
      > User.first.try(:name).try(:upcase) #==>"JOHN DOE"

<comment><USER5> Thanks for pointing out the try method (it is important to note that it is avaible to anyone using Active Support, not only Rails apps).

It is mildly different (syntax mostly). All of these are attempts to recreate the elvis operator tha Groovy[1] (nowadays present as the The Existential Operator in Coffescript[2]) have.

For better chaining, the Maybe monad can be implemented in Ruby[3]. However they really shine on Haskell and Scala because they have, respectively, do notation and for comprehensions, which effectively work (on this restricted case of handling nulls) as a scope were nulls are ignored.

Doing this with ruby is possible, but requires AST metaprogramming[4], which is the sort of thing that LISP macros do (and is quite suitable to accomplish in LISP[6], as it is homoiconic[5], while Ruby isn't).

[1] [http://groovy.codehaus.org/Operators#Operators- ElvisOperator...](http://groovy.codehaus.org/Operators#Operators- ElvisOperator%28%3F%3A%29)

[2] <http://jashkenas.github.com/coffee-script/#operators>

[3] [http://pretheory.wordpress.com/2008/02/14/the-maybe-monad- in...](http://pretheory.wordpress.com/2008/02/14/the-maybe-monad-in-ruby/)

[4] [http://metaphysicaldeveloper.wordpress.com/2010/10/31/rubyun...](http://metaphysicaldeveloper.wordpress.com/2010/10/31/rubyunderscore- a-bit-of-arc-and-scala-in-ruby/)

[5] <http://en.wikipedia.org/wiki/Homoiconicity>

[6] [http://onclojure.com/2009/03/06/a-monad-tutorial-for- clojure...](http://onclojure.com/2009/03/06/a-monad-tutorial-for-clojure- programmers-part-2/)

<comment><USER6> Thanks for the links. Some ruby food for thought . . .

      > x = nil || 5                   #behaviorally equivalent to elvis?
      > [nil,4,3].compact.map(&:to_s)  #null-ignored scope

<comment><USER5> You are welcome. The second line is the essential notion of Maybe monad as a restriction of the Sequence monad (Some of x works like [x] and None works like [], using ruby's [] notation for lists).

</comment></comment></comment></comment></comment></comment><comment><USER7> When I first looked at Haskell, the 'Maybe' concept was new to me and seemed like a useful concept for other languages. [http://haskell.org/ghc/docs/6.12.2/html/libraries/base-4.2.0...](http://haskell.org/ghc/docs/6.12.2/html/libraries/base-126.96.36.199/Data- Maybe.html)

<comment><USER8> Haskell is compiled. As I understand it, much of the point of Maybe is that it provides a formal language for expressing and manipulating unhandled edge cases. Then the compiler can spot those unhandled edge cases at compile time and make sure you handle them at one level of scope or another.

In Ruby the concept seems less useful because there is no compiler.

<comment><USER9> That's not the point, the point is that Maybe is the right way to handle what nil (or None or null) fails to handle properly. Scala gets it right too, IIRC, with Nullable.

1\. A "null" instance of one type should not be conflated with a "null" instance of a separate type. 2\. By type-wrapping in a Maybe, you declare where you need to be able to handle nulls and where you are free to ignore them (but can never pass them in). You confine the null to specific regions of your code. 3\. You force your code's clients to think about the null case wherever you make it visible.

<comment><USER10> Maybe is really just a special case of Either, where it optimizes for the situation where the second return type is "failure." The type of Either is necessary because proper type theory requires a container type to wrap two types. This is immediately obvious if you try to write the type signature for any function which has a return arity of one.

</comment></comment></comment></comment><comment><USER11> I'm a big fan of Lua's use of nil and the simplified error handling (No exception 'types') in that language. I think the problem with 'typing' Exceptions is that it means you are using it to record and pass describable\known state similar to return, instead of being reserved for unknown state. For indicating predictable failure states without using exceptions, I think multiple return values is a much better paradigm. Here's what happens when you open a non-existent file in Lua:

        =io.open 'sdfasdf'
        nil	sdfasdf: No such file or directory	2

The first value returned is nil, the 2nd value is a string containing an error message, and the 3rd is an integer error code. This allows you to write most code using 2 state boolean logic:

        f=io.open 'sasdasdfsf'
        if f then -- nil is a boolean 0

whereas in Python, one often has to reason about 3 states by using the try\except blocks. Even though you are not using typed Exceptions, multiple return values does not discard any state about the error if it is desired:

        f, err = io.open 'sasdasd'
        print(err)

I believe this also the design decision Google's Go language has made: <http://golang.org/doc/effective_go.html#multiple-returns>

<comment><USER12> This also works really well when combined with the assert function. Any function that returns nil and an error on failure can be wrapped in assert (which is just a normal function that takes a value and a message, and raises an error with the message if the value is nil or false).

If the function returned a value (besides nil or false), then assert merely returns the value. If the function returns nil or false, then assert raises an error, and the error message is used as the error in the assert. For example:

      > = assert(io.open("hello"))
      file (0x8b9f658)
      > = assert(io.open("goodbye"))
      stdin:1: goodbye: No such file or directory
      stack traceback:
        [C]: in function 'assert'
        stdin:1: in main chunk
        [C]: ?

This makes it possible to fail early when you don't need or want to do full error handling, or to use advanced logic if you need to recover from the error - without a try/catch statement. Effectively, it makes exceptions optional.

</comment></comment><comment><USER13> This argument just seems like a step along the path to static typing. If you're using Ruby, haven't you already decided that you prefer the simplicity of a dynamic language to the safety of static types? So why start to add half- baked typing to your code? It seems like it just puts you in an uncomfortable middle ground.

</comment><comment><USER9> I commend the author for re-implementing basic typing for Ruby, but this example completely misses the point. If the client to User asks whether a user is an admin of a project before asking if it is a member of that project, the client code is broken already.

</comment><comment><USER14> I can't comment on Ruby, but as the author decided to throw in a "...AttributeError in Python" reference I figure I have two cents to add.

Unfortunately the author is out of their depth. Why are they checking for specific attributes or assuming objects are an instance of a particular class? This violates the spirit of Python. Indeed, from the Python glossary:

        (Duck typing is a) Pythonic programming style that determines an object's
        type by inspection of its method or attribute signature rather than by
        explicit relationship to some type object ("If it looks like a duck and
        quacks like a duck, it must be a duck.") By emphasizing interfaces rather
        than specific types, well-designed code improves its flexibility by
        allowing polymorphic substitution. Duck-typing avoids tests using type()
        or isinstance(). Instead, it typically employs the EAFP (Easier to Ask
        Forgiveness than Permission) style of programming.

The author even misinterprets the first reference they provide! How outrageous is that? The author links to a blog comment as "These errors are one of the largest sources of bugs.", but the actual link _explicitly states_:

        The nowhere-near-ready-for-peer-review numbers I've seen suggest that
        something like 70% of bugs in Java manifest to the programmer as
        NullPointerExceptions.

These bugs _manifest_ using some language-specific exception, but clearly the actual bug is a different kettle of fish. It could be absolutely anything; poorly specified interfaces, well-specified interfaces that are called badly, some lower-level exception getting silently caught, inconsistent state. What does null, nil, None, NULL, whatever, have to do with this?

</comment><comment><USER15> I think one's opinion of the final solution in the article boils down to if you would prefer to raise (or throw) an exception if there desired value is not found (i.e. like in Java when a file is not found), or you would rather return an error value (i.e. NULL in C from fopen etc).

This is just creating a specific proxy object to return a more specialised error condition rather than just returning nil and making the user of the function guess at what could have gone wrong.

I could see this sort of proxy object mechanism being extended so that you could add retrying mechanisms to the code.

</comment><comment><USER16> Part of the problem stems from the calling semantics of the language, namely when the operation hangs off of an object. Broadly speaking, functional languages avoid that manifestation.

The other part of the problem stems from handling nils when one is given them, either as the result of an operation, or the arguments to one. Either way, this necessarily needs to be a context-specific decision.

</comment><comment><USER17> Having read the comments, I havn't seen what I find to be the gravest problem with this article - the poor OO practices of the author.

Seriously. If you have a family of methods on a user that only work in the presence of an instance of a project, then the first thing you ask yourself should be 'hey, maybe these methods belong on the project instead' and not 'hey, lets reinvent nil'.

<comment><USER18> Don't these methods only work in the presence of an instance of a user as well?</comment></comment>


Spectacle: Write Your Slide Decks in JSX - <AUTHOR> http://spectacle.surge.sh <comment><USER2> Nice! Feature request: Use replaceState so I don't need to hit back seventy times when I'm done reading slides on the internet.

<comment><USER3> This, so very necessary. It's the one major qualm I have with many JS slide show packages.

<comment><USER4> Done & Pushed. Great call guys.

<comment><USER3> nice turn around time!

</comment></comment></comment></comment><comment><USER5> This is actually the coolest demo of what React is all about. I was on the fence, but this is so awesome; I'm jumping into React. To the OP; thanks!

</comment><comment><USER6> Am I the only one who's annoyed by animations when I switch back to the slide? I can understand animating the slide when I first land on it; but animating it again when I hit the left arrow is wasteful, IMHO. Just show me the slide, because in all likelihood I'm just flipping backwards to get to a particular slide as fast as possible.

<comment><USER4> Good point. I'll split the transition prop into transistionIn and transitionOut so that you could set one direction to have no transitions. Realistically I don't even use transitions in my presentations, but folks seem to like them sooo....

<comment><USER7> That's clever! Nice work btw, love the little DSL it becomes, very clear and readable!

</comment></comment></comment><comment><USER8> This reminds me of slid.es (now slides.com) and reveal.js ([https://github.com/hakimel/reveal.js](https://github.com/hakimel/reveal.js)) which its based on.

That said, Spectacle doesn't seem to allow mouse / scroll wheel navigation yet?

<comment><USER4> Not yet, as I'm still working out some of the feature set, but I'll file an issue for addition.

</comment></comment><comment><USER9> This worked well on my old Nexus 7 (in Chrome), which a lot of similar systems haven't worked on. I've lost track of how many swipe-for-next-slide systems _haven 't_ worked for me, lately.

Some of the slides looked like they had a tiny bit cut off at the bottom, though.

<comment><USER4> Thats awesome. I've done a lot with swipey things in the past. The cut off should be fixed in the next patch, with height conditional scaling.

<comment><USER10> Just a heads up, I was going to post the opposite comment - no navigation on Firefox on the nexus 7. I did see this first and check Chrome, that works fine (although I get a constant loader in the tab bar - is that a known side effect of something?).

This is really nice in Chrome on the tablet though, I agree! :)

</comment></comment></comment><comment><USER11> Not sure if it's an intentional effect, but the "full width" is a bit more than full for me: [http://i.imgur.com/S3jrA7S.jpg](http://i.imgur.com/S3jrA7S.jpg)

<comment><USER4> Oh no! Could I trouble you for what env this occurs in? Does a refresh fix it?

<comment><USER11> Sorry for the terrible bug report. I just had a good guess: my laptop has a higher-DPI display so I have Chrome adjust all websites to ~130% larger to make them match a normal website. I can reproduce the problem from my desktop if I zoom the page a bit.

<comment><USER4> That is a very strange and very valid bug. Head scratcher, but I'll get it worked out.

</comment></comment></comment></comment><comment><USER12> "EASY THERE PAL"

</comment><comment><USER13> Neat!

p.s. On the "click me" demo, the state is preserved when going back then forward, but not preserved when going forward then back. - Is that a design decision or unintended effect?

<comment><USER14> For me it's only preserved if I press left-right or right-left quickly. I'm guessing it's intentional.

It would be nice if it kept the state though.

<comment><USER4> The component in question is using component local state, so that resets on mount/unmount. That said, it would be very easy to embed one that instead used flux, and state would be preserved.

</comment></comment></comment><comment><USER15> I can appreciate the advantages in terms of portability of something like this, but it's sort of funny watching trivial animations choke on a desktop with a beefy discrete graphics card in 2015. Maybe that's just Chrome on Ubuntu, though.

I guess you could put everything in a webgl canvas? Otherwise I guess we'd either need to build DOM layout engines better optimized for on-line layout updates or make them more parallelizable?

<comment><USER4> Hmm I'll take a look. Is there any particular animation choking? Or all of them? It runs like butter on my Macbook Air in Chrome.

<comment><USER15> I'm seeing pretty consistent drops to ~12 FPS on all animations - very well could be an Ubuntu issue then.

</comment></comment></comment><comment><USER16> Yet another javascript slide system which fails at what I consider one of of primary requirement of a slide system:

Actually displaying the content of each slide, when viewed at different aspect ratios.

I can't imagine doing a presentation with this -- all it takes is one weird aspect ratio projector and half your talk disappears off the bottom.

<comment><USER4> Is there an particular set of aspect ratios this is failing at that I can test against? This is 0.0.1 so theres still a couple of loose ends.

<comment><USER16> Just grab the bottom left corner, drag around, and see bits of slides disappear.

I have fixed this in my slide library by choosing a single ratio, and using css3 zoom to fit that best in the browser window. Is less "weby", but better for displaying same slide to everyone.

</comment></comment></comment><comment><USER17> hey it's another Ken Wheeler joint. What's up mothaforka?!

Have been letting Colin Megill's 'Inline Styles are the Future of CSS' vid [0] marinate in my brain recently. Keep up the good work!

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

</comment><comment><USER18> Sweet! The source is very nicely laid out as well, can serve as a realistic example of building a modern ReactJS app

<comment><USER4> Thanks! I write React full time at a very large company, so we've had some time to develop some cool best practices and solve some of the challenges something like this presents.

</comment></comment><comment><USER19> PDF export, excellent! Not many presentation libraries take this in consideration...

</comment><comment><USER20> loved it. extremely smooth and not confusing at all.

</comment><comment><USER21> no right arrow?

<comment><USER22> I assume you're meaning the message on the first slide? Hit the right arrow on your keyboard.</comment></comment>


Scott's Cheap Flights no longer sending deals outside of the USA - <AUTHOR> It's been a little while since I've received a deal email (located in Australia) and I just received this email today. Such a shame, this service not only saved me money, but also gave me a little day-dream every time a new destination appeared in my inbox.
Anyone know what has happened?
——
Hi there, Scott here. I'm reaching out to let you know Scott's Cheap Flights is no longer sending flight deals departing from airports outside of the United States.
We'll be issuing a prorated refund for the time remaining on your membership as of our last date of international service, which was Wednesday, September 25th, 2019. You'll receive a [redacted] refund in about 15 business days. If you don't receive a refund, please reply to this email and our Advocacy team will help you out.
Thank you so much for being a member and giving us the privilege of searching for flights for you. I hope that you scored some incredible deals.
Love,
Scott <comment><USER2> I do. (Scott here.)

It was a really tough decision—we loved serving our members all around the world. We tried as hard as we could to make it work, but trying to serve everyone around the world was really complex and difficult, and we felt like we were coming up short. We have a vision for what we're trying to accomplish and it's nearly impossible to do it while serving everywhere. (Especially given that Scott's Cheap Flights is a bootstrapped company.) In the end we felt like the best approach was to narrow our focus and just serve the US market so we can build the best possible service.

I hope that makes sense. We're hoping someday down the road to be back your way—until then, we'll miss you and really appreciate your being a part of all this.

<comment><AUTHOR> Thanks for the thoughtful response Scott. All the best for this next phase :)</comment></comment>


JavaScript Cold War simulation - <AUTHOR> https://simonswain.com/coldwar <comment><USER2> The author also worked on a deep space simulator [1] which has been on hacker news [2] before. Another very interesting simulation.

[1] ([https://github.com/simonswain/deepspace](https://github.com/simonswain/deepspace)) [2] ([https://news.ycombinator.com/item?id=8837204](https://news.ycombinator.com/item?id=8837204))

</comment><comment><USER3> For "authorized" advice, see [https://www.youtube.com/watch?v=q2v0YuDatpc](https://www.youtube.com/watch?v=q2v0YuDatpc) (Declassified USAF training material, 1958), alternate source: [https://archive.org/details/AirForceSpecialFilmProject416pow...](https://archive.org/details/AirForceSpecialFilmProject416powerOfDecision)

(Amazing actors' performance included.)

<comment><AUTHOR> SAGE is the inspiration for this...

[https://www.youtube.com/results?search_query=sage+computer](https://www.youtube.com/results?search_query=sage+computer)

This thing was off the hook...

<comment><USER3> I once included this video in something similar (also relating to SAGE) as the help option, see this easter-egg: [http://www.masswerk.at/google60/?q=list%20games](http://www.masswerk.at/google60/?q=list%20games) (option 4)

(Edit: Similar just intention-wise, else much simpler, since just in ASCII, meant to be EBCDIC.)

BTW: "System Technology" (SDC, 1960) is also an impressive source in this context: [https://www.youtube.com/watch?v=Yqu3YX2cLA8](https://www.youtube.com/watch?v=Yqu3YX2cLA8)

<comment><AUTHOR> Nice Easter Egg!

<comment><USER3> On "System Technology": See esp. at 17:00, ca., this is very similar to the view conveyed by your rendition (note the swarming aircrafts).

</comment></comment></comment></comment></comment><comment><USER4> People who like this might like the very similar PC game "DEFCON" [http://www.introversion.co.uk/defcon/](http://www.introversion.co.uk/defcon/)

</comment><comment><USER5> This is a hot war simulation, is it not?

<comment><AUTHOR> Technically, yes. It's meant to escalate from cold to hot as munitions stockpiles build.

But that doesn't make for a very interesting presentation, so it goes direct to Hot.

<comment><USER6> I think WWIII sim is probably a better description. Or could go with the 1985 War Games "Global Thermonuclear War". Just nitpicking. The simulation is awesome.

</comment></comment></comment><comment><USER7> The creator held a talk about simulations at JSConf.Asia 2014. Highly recommended: [https://www.youtube.com/watch?v=0HJPilemNns](https://www.youtube.com/watch?v=0HJPilemNns)

</comment><comment><USER8> Really cool - would be good to have a quick instructions drop down - I started with clicking things and hitting keys until I realised it was a simulation on initial conditions only.

The bombers seem too effective in anti-fighter measures, and has been said, the sats are very effective at anti-ICBM, but seem invincible themselves?

Interesting how quickly the tide turns from stalemate to dominance once a few factories or bases fall. And also how long it takes to really finish the opponent off (probably my launch_max is too low).

Also interesting the 'fronts' or lines of bombers that form between oppositions. This happens in naval and ground battle, but I'd think a major air war, with high speed relative to density of fighters would avoid this?

Would be cool to involve some sort of strategic element? I'd hoped the fighters would protect the bombers more, but it seems they are more defensive?

Well done!

<comment><AUTHOR> Yep. All that will be there one day. This is v0.1

</comment></comment><comment><USER9> Can you give an explanation about what each type of unit does?

<comment><USER10> Seems like:

      - circle: city
      - triangle: factory
      - square: military base
      - big plane: bomber
      - little plane: fighter
      - things with rocket trails: ICBMs
      - floaty diamond things: satellites (which shoot down ICBMs)

The square in the middle of each team represents the current defcon. Assuming you start at defcon 5, when an enemy unit crosses the big blinking circle, drop to defcon 4. When a unit crosses the next blinking circle, drop to defcon 3. I haven't figured out yet how the escalation proceeds after that.

<comment><AUTHOR> Bang on.

The dust coming up out of the bases (and to a limited amount, the other assets) are ABMs, trying to take out incoming ICBMs.

Goes to Defcon 2 on enemy bombers reaching city limits (the radius Cities and Bases are at).

</comment></comment></comment><comment><USER11> Yikes! Is this realistic? There seems to be a doctrine that ICBMs will only be launched upon receiving a complete nuclear strike, and once that happens it's pretty much game over.

This makes fighter jets a critical buffer because the only way a defense can prevent mutually assured destruction is to prevent non-ICBM first strikes.

<comment><USER12> If you're looking for realism in your apocalyptic nightmare scenarios, there's an ooooold DOS game called _Bravo Romeo Delta_ you should track down. I wrote a little bit about it here: [http://jasonlefkowitz.net/2014/11/choreographing- armageddon-...](http://jasonlefkowitz.net/2014/11/choreographing-armageddon- bravo-romeo-delta/)

It's fallen into abandonware hell, so you can't buy a copy at GOG or anything like that, but _cough_ I'm sure you could find a copy if you looked on the right sites.

<comment><AUTHOR> This is awesome... so much detail.

</comment></comment></comment><comment> guard-of-terra Real Cold War is more of this: Two side point lethal nukes at each other, but at a point one side falls on its face and proceeds selling factories for scraps, while other one forgets near-death experience in a whim deriving no lesson from it.

Not so fun to simulate mind you.

</comment><comment><USER13> This was a presentation at JSConf US 2 weeks ago. I'm sure everyone will enjoy it much more with the video once it winds up online.

<comment><USER14> It wss a fun talk. My only regret is that Simon didn't use an [apropos quote]([http://www.imdb.com/title/tt0086567/quotes?item=qt0453844](http://www.imdb.com/title/tt0086567/quotes?item=qt0453844)) during the talk.

<comment><AUTHOR> The BBS login at the start of the talk said: "Greetings, Simon".

</comment></comment></comment><comment><USER15> Reminds me a lot of the game Defcon. I love it!

<comment><USER16> Reminds me of Missile Command

</comment></comment><comment><USER17> I love the dual side/top view setup.

</comment><comment><USER18> The game also becomes interesting and easier to watch the escalation by turning it straight to Defcon 3 and then reducing the number of bombers.

This leads to skirmishes between fighters and a few stray icbm's in the beginning, but once one hits the situation escalates extremely rapidly.

</comment><comment><USER19> This was super fun to play with and the visuals are very cool! One minor thing though, the Star Wars program simulation seems too good: once you have around 5 sats going around you're safe for a long long time that it starts becoming boring (and I'm pretty sure it wouldn't be the case IRL). Like, I watched a game for 30min and all sats were too effective and nobody could really hit each other no matter how many attacks they did. Maybe make sats attack each other while in orbit? Perhaps only in specific timed cases, sort of during an orbit apogee or perigee or whatever, just to make them a bit less effective or durable?

<comment><USER20> _> Maybe make sats attack each other while in orbit?_

Just add ASAT. If they've got ICBM technology and especially if they've got ABMs, they can certainly knock a satellite out of orbit.

</comment></comment><comment><USER21> Reminds me somewhat of DefCon ([http://www.introversion.co.uk/defcon/](http://www.introversion.co.uk/defcon/)). No one wins. Try to be the one who loses least...

</comment><comment><USER22> The author's Github contains the source for this:

[https://github.com/simonswain/coldwar](https://github.com/simonswain/coldwar)

</comment><comment><USER23> I wish the parameters were url parameters. Comparing simulations would have been possible.

(I'm currently running a conventional war scenario -- bombers and fighters only - no icbms or sats).

<comment><AUTHOR> Yep. Need the ability to save and share scenarios. Coming.

</comment></comment><comment><USER24> Very impressive. As a crusty old desktop programmer I am amazed how smoothly it runs in the browser. A few questions (didn't see them answered below):

1\. What Javascript frameworks/libraries did you use (if any)? 2\. Do the 2 sides always have to be symmetric?

It would be great if you could add some brief notes explaining what is going on (even if you just copy and paste some of the below).

<comment><USER18> It was definitely something compiled to JavaScript, I can tell you that.

[https://simonswain.com/coldwar/assets/pub- script-14324351717...](https://simonswain.com/coldwar/assets/pub- script-1432435171707.js)

<comment><USER25> That's plain JavaScript, only minified.

</comment></comment></comment><comment><USER26> >Doing heavy lifting with JavaScript in IE8 is just not fun.

Please force your customers to upgrade their browser. You'll do the better good for yourself, your customers, and mankind in general. :)

</comment><comment><USER27> I spent an hour playing with this - very enjoyable! Would love an iOS app with something similar. Recommendations?

</comment><comment><USER28> Slight bug, If there's any bombers on the field at all the other sides fighters won't shoot any fighters.

If side A has fighters on side B. A has a bomber just launched. B fighters just try to fly at the bomber, dieing to the B fighters.

</comment><comment><USER29> Joshua, is that you?

<comment><USER30> Wouldn't you prefer a nice game of chess?

</comment></comment><comment><USER31> Reminds me of Minestorm on the Vectrex!

</comment><comment><USER32> Reminds me of Atari Missile Command.

Good ol' days.

</comment><comment><USER33> Every time the same team wins over and over again, when I change some values other team keeps winning all the time.

</comment><comment><USER34> Awesome!

</comment><comment> anti-shill the only winning move is .....

<comment><USER35> To play, perfectly, waiting for your opponent to make a mistake. ([https://xkcd.com/832/](https://xkcd.com/832/))

<comment><USER36> Alternately, watch SMBC's more explicit version [https://www.youtube.com/watch?v=TFCOapq3uYY](https://www.youtube.com/watch?v=TFCOapq3uYY)

</comment></comment></comment><comment><USER37> need more visual

</comment><comment><USER38> @simonswain - You should avoid the bright flashes when the game is over, some people might have health issues.

<comment><USER39> Meh, the flashing-lights-in-games thing is waaaaaay overrated as a public health concern. Most photosensitive (=~'flashing light') epileptics require flashes in the range of ~8-18 Hz (mostly in 12-16 Hz), and even then it almost always takes some time to build up, and even then it's a fraction of epileptics that are susceptable. And flashing lights by themselves don't make non-photosensitive epileptics have seizures (or non-eplieptics). Only about 15% of people epilepsy with are photosensitive. A photosensitive epileptic will know to look away if they see their kind of triggering flash.

By the time you narrow it down to the mere handful of epileptics that will have a seizure from one or two flashes (ever hear anyone complain of a single camera flash and epileptics?), you're in a very rare group. At which point, nothing is safe - I heard of one epileptic who had seizures due to orange circles. Other colour circles were fine, other orange shapes were fine, it was just orange circles (which mean no driving...). Another patient had seizures when ice touched their lips. They do exist, of course, but at that point you're optimising for an incredibly rare user. If you're going to optimise for that, there's plenty of usability optimisations that hit way more people that you should be doing first :)

Source: spent four years doing several EEGs on neuro patients per day, each of which had a 5-minute session with a strobe light at various frequencies. Most of those patients were there for epilepsy or suspicion of epilepsy, but not all, of course. Seeing a photosensitive response at 8Hz was uncommon, but not rare. Some people had some response to single flashes (well, 1Hz) but it never built up to a dangerous level - I never saw someone in danger of having a seizure from 1Hz flashes.

/rant (sorry, nothing personal, I just keep seeing this (largely) urban myth)

<comment><USER40> > I just keep seeing this (largely) urban myth)

It is reinforced by those warnings in all games.

<comment><USER39> A fair point - they're just doing CYA because of public hysteria on the issue. Game designers are rarely biologists, let alone neurologists, and it's a topic that the public knows little about :)</comment></comment></comment></comment>


Quotes From PG's FBFund Talk From Today - <AUTHOR> http://jasonlbaptiste.com/jason-l-baptiste-random-thoughts/quotes-pgs-fbfund-talk/ <comment><USER2> These are pretty far from verbatim. Way far in some cases. I never said anything about board meetings, for example. I said it was good to keep in touch with your investors, but I assume most of a startup's investors won't be on the board.

</comment><comment><USER3> I like the quote about no technical founder. I meet many people who are doing start-ups & they have no techical background or those who want to do a start- up have no skill. IT's not impossible, but almost and it's tiring and progress is slow!

I am sorta one of these people who is now learning back end code (some) along with the hack web design skills I picked up(average web designer now). I look forward doing another start-up where I am doing back and front end. As oppose to just front end and relying on a consultant/partner in India who cared some for our product, but no way had the same passion i did/do.

Learn how to code if you want to start a start-up, also find partners who are as crazy focused as you are.

</comment><comment><USER4> I know PG well enough to know he never said "u" instead of "you".

<comment><USER5> These are just a collection of some raw tweets by someone who was at the event.

<comment><USER6> I have the somewhat incongruous vision of PG speaking like a 14 year old girl.

<comment><USER2> OMG, I would so never do that.

</comment></comment></comment></comment><comment><USER7> What I found encouraging and enlightening was knowing that most startups go through the "Trough of Sorrow" (the time after launch when you don't get any users and things look really bad). Just knowing that you're not alone makes it so much easier to go through it.

</comment><comment><USER8> I know that tweeting is all the rage, but these would sound less childish rewritten with proper spelling and grammar. I doubt that the tweets were direct quotes in the first place.

</comment><comment><USER9> _"one thing at YC we learned that determination matters FAR more than intelligence."_

There's an insult somewhere in that quote.

<comment><USER10> another way of viewing this is: "we screen suitably for intelligence but have not thus far screened [effectively] for determination."

</comment></comment><comment><USER11> This is interesting, but the 1337speak makes them somewhat hard to read.

</comment><comment><USER12> One more: "Work on hard problems. Keep trying things."

</comment><comment><USER13> _"Pattern recognition is what you fall back on when you don't quite understand something…"_ \- I've heard this one applied to neural networks.

 _"Startups rarely die from competitors. They die of_ SUICIDE _." (stupidity, lack of money, lack of customers)_ \- I wouldn't call it suicide (misquote?), but it's a great point that you don't need to worry about _relative market share_ when you're small. You just have to worry about getting _some_ market share (i.e. _some_ customers). There's plenty enough available if you're small and don't need that many.

</comment><comment><USER14> "Startups rarely die from competitors. They die of SUICIDE." (stupidity, lack of money, lack of customers)"

Startups do die from competition. Kiko is one example straight out of PG's book.

<comment><USER15> As one of the two founders from Kiko, I can say that we had ideas for how to sustain the company and try different routes, but instead decided to shutter and move on to something else (which turned out to be Justin.tv). I think that scenario is actually a perfect example of what PG is talking about: a startup that possibly could have made it by iterating, but instead gave up b/c the founders decided to move on. Competition may have caused the depression, but the founders themselves loaded the shotgun and pulled the trigger.

</comment></comment><comment><USER16> "we've learned if yr talking 2 bunch startup founders & can't tell who leader is, that means there _isn't_ one."

Is this damning?</comment>


Cornell U. Startup Wiggio Passes 100k Users - <AUTHOR> http://www.collegemogul.com/content/group-collaboration-startup-wiggio-passes-100000-users

<comment><USER2> They got to 100k users because the person creating a group can add however many email addresses they want to each group. There is no invitation step, like there is with Google or Yahoo groups.

So they can sign up a thousand people a day with a hundred people creating groups of 10.

And since it's free text & email blasting, it seems like this would be a spammer's dream come true.</comment>


Handy online OAuth explorer - <AUTHOR> http://sevengoslings.net/~fangel/oauth-explorer/

<comment><USER2> How is this superior to (or different than) Google's opensourced OAuth Playground?

<http://googlecodesamples.com/oauth_playground/>

<comment><USER3> Google's Playground in it's current online form only supports Google's own OAuth end-points. My (disclosure: yes, I made the tool in question) tool supports arbitrary end-points.

If anyone can come up with improvements, please do say so.</comment></comment>


Ask HN: What was the website that lets you create a "step-by-step" guide? - <AUTHOR>

There was a site that let you create a step by step guide for your users. It would automatically attach to your links and buttons and tell users to click there.
It was posted on here around a week ago.
I want to use it for a project and can't find it or remember the name. I've tried searchyc, looked in google reader, but can't find it.
Anyone remember what it was called?
Edit: let me try to explain the site a bit better. What it does is let you add hover text next to a link that says "click me to get started" <comment><USER2> I think you are talking about IORAD - <http://www.iorad.com/>

It's funny you forgot the name because that was just the comment I made!

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

<comment><AUTHOR> Thanks, that was it. Yea, the name is definitely forgettable. Though, I doubt I'll forget it again now ;)

</comment></comment><comment><USER3> Amberjack?

<http://amberjack.org/>

<http://www.slideshare.net/Jazkarta/amberjack-lightning-talk>

</comment><comment><USER4> <http://www.thestartuptoolkit.com>? I've found it very useful and a clever design.

<comment><AUTHOR> No, this site would let you pick links on your site that you can attach a little notification that says "click me to go to the next step", so you could build a whole getting started guide using it. It's hard to explain, without seeing it.

</comment></comment><comment><USER5> Was it helpbubble? <http://www.helpbubble.com/tryit>

</comment><comment><USER6> It wasn't wikihow by any chance?</comment>


Show HN: TallTube : client for vertical vids - <AUTHOR> http://talltube.com

<comment><AUTHOR> OP here. Definitely one on the "dumb project" list -- total effort to create this was no more than a weekend's time. Just thought it's be neat/funny to have a YouTube site specifically designed for viewing vertical videos -- since those are popular nowadays with smart phones.

There is no feature on this that YouTube doesn't have, other than the video player being shaped for vertical videos.

Uses YouTube API for the video player, of course. There's not much of a backend to speak of. The only job the backend code has to do is to read the video id, and load the thumbnail image and put it into meta/link tags for proper social sharing thumbnails.

<comment><AUTHOR> Bit more tech notes:

DigitalOcean micro server, CloudFlare to handle burst traffic (in case any comes in), Google Analytics for stats, and a basic Redis setup to record every video people watched on this in a Set and a Hash, so in the future I could create a "Other Popular Tall Videos" widget.

<comment><USER2> What language did you use to write this app?

<comment><AUTHOR> Sorry I missed this message, hadn't been checking after the first day of the post. Backend language is just PHP with ToroPHP for routing (only framework involved).</comment></comment></comment></comment>


A list of questions common when interviewing for a job as a Graphics Programmer - <AUTHOR> https://erkaman.github.io/posts/junior_graphics_programmer_interview.html <comment><AUTHOR> Some months ago, I interviewed for a job as a junior graphics programmer for various game companies, in order to break into the industry. Since computer graphics is a very niche field, there is not very much information out there on what questions are common during an interview for such a job. So I decided to compile this little list of common questions, and to write some general advice about how you can prepare for the interview. Hope someone finds this useful. :)

</comment><comment><USER2> Should add "write me a pseudocode vertex shader and fragment shader", and a question or two about the order of magnitude costs for switching uniforms/buffers/framebuffers/shaders.

<comment><USER2> Also order-of-magnitude questions about cpu vs gpu perf (arithmetic, special functions, memory bandwidth and latency)</comment></comment>


Smartbooks have been delayed by Flash issues, says ARM - <AUTHOR> http://www.zdnet.co.uk/news/mobile-devices/2010/05/05/smartbooks-have-been-delayed-by-flash-issues-says-arm-40088854/

<comment><USER2> With regard to the low uptake of Linux on netbooks, I checked prices on Dell's website about a year ago. In several cases, the same machine cost _more_ with Linux than WinXP. In another case, the Linux netbook was only offered with 8gb of flash storage while the Windows version was available with real hard drives.

They were also hard to find. For reasons I don't understand, they don't simply offer an operating system option when you're custom-configuring the machine. You have to go looking for it.

The same issues won't affect smartbooks.

<comment><USER3> Yeah, I thought that line was odd. I'm under the impression that people who put linux on netbooks just blow out windows and install Linux over it? Thats what I do anyway.

My first thought was the same as yours, "Well uptake wouldn't be slow if vendors actually offered it!"

</comment></comment><comment><USER4> Let me be the first to say I don't care about Flash. All I want is a Linux- compatible netbook running a standard distro with great battery life, 2+ gigs of RAM, a real hard disk and a _standard_ external monitor port. Hardware- accelerated 3D and 1366x768 built-in screen are pluses.

And, for the Flash thing, I would love if ARM decided to pour some money on Gnash development.

<comment><USER5> I don't think Gnash fixes anything. The reason why flash is so prominent is that there is no good flash-creator-like program out there that outputs files as HTML5/SVG/AJAX/Javascript. People use Flash because it is the only good way to create animations that work for many people, but with a proper editor, we could eliminate the need for additional addons entirely.

<comment><USER4> But if Gnash can run anything the Flash "IDE" outputs, then everything works. If enough people start using non-Adobe implementations of Flash, applications will have to be tested against those implementations.

<comment><USER5> But we both know it wont in the real world. We also know that Adobe will probably change the Flash output slightly in the future, and Gnash will always be a step behind.

It doesn't change the fact that you would be wasting development resources, because you then have duplicate functionality. Why waste resources on developing an addon, which will need to be updated with the browser api's, for many browsers, and optimised, when the browsers themselves already have the functionality built in? If resources are spent optimising the browsers themselves rather than a foreign addon, every website benefits.

Fact is, the same problem's we've had with flash addon in the past (such as in cases where updating the browser caused crashes), will still exist in Gnash player instead.

Why are you so eager to encourage people to duplicate functionality browsers are building into their core code these days?

You can either improve the browser, or you can improve Gnash. Both are open source. Unless there is something the flash standard can do which open standards couldn't?

<comment><USER4> There are lots of applications, in embedded devices, that are built with Flash and target Gnash instead of the Adobe runtime.

Gnash is reasonably good and supports hardware-acceleration. I agree we should move over to HTML5 as soon as possible (taking encumbered codecs in consideration), but some flash support is a nice to have, even if it's not full support.

</comment></comment></comment></comment></comment><comment><USER5> It couldn't possibly have anything to do with the fact that ARM is competing against the faster atom processors, which can run windows and a lot more applications? I would have thought that consumers would see an Atom netbook, compare it to ARM, realise the minimal cost difference and then settle on the Atom based one.

It sounds like they are simply fishing for excuses honestly. Flash may make ARM netbook's more appealing, but if this was the sole reason that they were delayed, the companies interested in creating smartbooks would have simply released the products now, and introduced a flash update later.

I think it probably has more to do with lack of demand. Whilst the ARM processors are good mobile phone CPU's, for laptops/netbooks, it is simply a trade-off of compatibility for slightly lower cost, and it would have to be a significant reduction in cost for salespeople to recommend a foreign processor.

That's just my opinion though. Personally, I used to sell laptops, and I would much rather push Atom netbooks than ARM netbooks.

<comment><USER6> I would argue that the smartphone market (and indeed any non-standard desktop OS or hardware) was also held up by lack of Flash support.

You have Intel executives banging on about "the whole internet" or the "real internet" etc. in other words don't buy that (or invest money in offering them for sale) as they don't run Flash. That was their one big talking point against ARM. They even slagged off the iPhone for this despite Apple being a big customer of theirs in other areas.

 _Intel Blasts iPhone_ : <http://news.cnet.com/8301-13579_3-10072779-37.html>

<comment><USER5> ZeroGravitas. Apple also banged on in 2004 about how awesome PowerPC was compared to Intel. Remind me what happened 2 years later? Yes, companies do slag others off..

The smartphone market was held up for many other reasons too. It mostly came down to the fact that the mobile OS's sucked at the time. One would have also expected Android/iPhone sales to have been flat without flash support, and this is untrue (Apple have said they refuse to support Flash, and iPhones are unfortunately flying off the shelves).

If you think Flash will suddenly replace the fact that software support for ARM is limited, that the CPU's are slow (and only recently started operating at good enough speeds) and that no major OS's even support ARM (Windows, Ubuntu, redhat, many other major linux distro's) then you should perhaps list EXACTLY what you think consumers need flash for (youtube perhaps would have been one valid reason, but it has been accessible via other means since at least 2006 now).

Whilst technologies such as Flash and ActiveX do still have their uses (hopefully though HTML5 will kill flash), I doubt that the lack of flash would have influenced any manufacturers into delaying an ARM product (which would be slightly cheaper), if they were serious.

Lets face it, The major issues with the iPhone 2G was the lack of applications (and even a javascript refreshing security camera stream caused safari to crash) and on Windows Mobile it was general usability issues. Or do you think these problems would have magically disappeared because of a really-slow version of Flash?

<comment><USER6> If there's X things that make a market look unlikely to succeed and so prevent investment, then things are going to develop even slower if it's X+1 instead. Poor Flash support is just one more thing that hampered smartphones, just as it hampered Linux. I'm not saying either were perfect if you ignore Flash support.

My point with Intel is that they're going to choose the very worst aspects of their competitors to talk about. If ARM phones could kill your pets, or explode in your face, then Intel would be talking about that. The fact that they were talking about Flash support means that it must have been, in their opinion, one of the biggest weaknesses of ARM in the smartphone space.

</comment></comment></comment></comment><comment><USER7> The iPhone's 3.1.1 rejection of CS5 is very dangerous to Adobe, because it undermines their platform's relevance. Particularly during a changing of the guard. One response is to ensure their great tools work well for HTML5 (which is probably in their interests anyway); but Flash remains valuable and worth protecting. IMO, they now have an extremely strong motivation to make Flash work on ARM.

Wonder what's stopping them?

I agree with the article that ARM smartbooks need the whole web, since they are competing with the near-universal applications on the x86 platform. But maybe even that isn't enough, since the network is intrinsically slow and unreliable [http://en.wikipedia.org/wiki/Fallacies_of_Distributed_Comput...](http://en.wikipedia.org/wiki/Fallacies_of_Distributed_Computing#The_fallacies) and consider the demand for iPhone native apps.

Perhaps faster javascript and RIA will fix this, enabling "native" webapps.</comment>


Learning Rust: Rust Programming Language Tutorials - <AUTHOR> https://medium.com/learning-rust <comment><AUTHOR> This covers,

▸ Installation & Hello World

▸ Cargo & Crates

▸ Variable bindings , Constants & Statics

▸ Comments

▸ Functions

▸ Primitive Data Types

▸ Operators

▸ Control Flows

▸ Vectors

▸ Structs

▸ Enums

▸ Generics

▸ Impls & Traits

▸ Ownership

▸ Borrowing

▸ Lifetimes & Lifetime Elision

▸ Modules

▸ Crates

▸ Workspaces

▸ std modules and Preludes</comment>


EU's highest court delivers blow to UK snooper's charter - <AUTHOR> https://www.theguardian.com/law/2016/dec/21/eus-highest-court-delivers-blow-to-uk-snoopers-charter?CMP=Share_iOSApp_Other <comment><USER2> Amen. Of course, what this will mean after a hard Brexit is anybody's guess.

<comment><USER3> at least it is good precedence for other EU countries.</comment></comment>