A "FaceApp" to enlarge breasts? It's here, and there's more to it than [ ] - <AUTHOR> https://medium.com/ai-academy/a-faceapp-to-enlarge-breasts-its-here-and-there-s-more-to-it-than-you-may-think-966cead81ffd <comment><USER2> All the guys at my gym like to try an app that gives them better abs and lats. So both men and women like to do this.

<comment><USER3> Name of the App?

</comment></comment><comment><USER4> Okay, new startup idea: dating website that uses AI to detect when the other person is using AI to make themselves look better.

<comment><USER5> I'm so glad I quit dating for good at the time I did. All the annoying Snapchat filters were bad enough.

I wonder how much all this AI will affect societal trust. If we're all just expecting that we're constantly lying to each other to get things, might we further devolve into a very low-trust society?

<comment><USER6> Did you quit because you found someone, or quit because you gave up? Asking for a friend.

</comment></comment></comment><comment><USER7> > The aim of this technology is to support women in making decisions on their > body

This is how I avoid scrutiny of all my carnal desires

I've been doing okay acknowledging that there are sexually desirable traits without pretending its a libido-less empowerment experiment.

</comment><comment><USER8> While it might create a remarkably accurate visualization of the best-possible outcome, this won't tell you how it will feel afterwards, and it won't tell you about possible complications. Could be very misleading.

</comment><comment><USER9> Warning: NSFW dataset.

</comment><comment><USER10> Glad everyone learned their privacy lessons.

[https://www.newyorker.com/cartoons/daily-cartoon/friday- july...](https://www.newyorker.com/cartoons/daily-cartoon/friday-july-26th- social-security-app)</comment>


Single Page Web Application Part Two - <AUTHOR> http://www.petermartinblog.com/single-page-web-application-part-two-2/

<comment><USER2> Why did the OP pick RequireJS and not LabJS. I have been looking at both and have not been able to pick.

<comment><USER3> I really like RequireJS. The have a build optimizer. It is pretty handy. I have not tried LabJS. It looks pretty interesting. I am looking forward to more about KnockoutJS. It seems like it would really reduce the amount of code you need to write compared to pure JQuery.</comment></comment>


The National Debt Road Trip [video] - <AUTHOR> http://www.youtube.com/watch?v=P5yxFtTwDcc&eurl=http%3A%2F%2Ftwitter%2Ecom%2F&feature=player_embedded <comment><USER3> This one's good too.

[http://www.youtube.com/watch?v=cWt8hTayupE&NR=1](http://www.youtube.com/watch?v=cWt8hTayupE&NR=1)

</comment><comment><AUTHOR> This is a really creative way to turn the debt into a trip across the US showing the difference among presidents this century in miles per hour - <USER2> visualization.</comment>


What will happen to remote work after Covid-19? - <AUTHOR> https://medium.com/@lukethomas14/what-will-happen-to-remote-work-after-covid-19-628a15bf5160 <comment><USER2> I feel like people will look at COVID-19's remote working situation as a failure and "proof that remote working doesn't work".

The holes in that argument are incredibly obvious to anyone here I think, but I really feel like the powers that be, and the people who like the office status-quo will take any argument and parrot it to ensure that nothing changes.

I know that's a pessimistic outlook but based on how people tend to be regarding open-office landscapes I think it's a realistic situation.

I'm one of the supremely fortunate people to be both childless and having a personal office at home, for me remote work is without a doubt more productive, however that's personal productivity vs team productivity. I have no idea what my colleagues are working on. Communication is one of the hardest problems that people are trying to solve and poorly managed companies use "collaboration" (IE; disrupting people or overhearing things) as a venue to avoid tackling the real communication issue.

The other thing is the majority of people at home are not set up like me, they have little humans that are distracting and curious nature. Or no dedicated space to actually focus.

Two anecdotes: My girlfriend is working from home using the kitchen table and one of my external monitors with her Mac, the ergonomics are horrible and her job is to play video games all day.. those video games are restricted IP so they can't be copied (or even if they could, they wouldn't run) on her mac.. so she plays video games over RDP+VPN which is obviously less productive than being at work with her high powered machine.

The other is my Mother. Who literally has no dining table or desk in the whole house, she works from the couch- I have no idea how productive she is but it certainly can't be as much as the office.</comment>


Ask HN: How many devs open Terminal vs. Browser when you start your comp? - <AUTHOR> <comment><USER2> Terminal & Firefox, at the same time. I am currently in a very small netbook (and old EeePC with 1 GB RAM) and it cannot run much more than that. I read my e-mail in mutt, my ttrss in newsbeuter, so with that and the browser I am covered. Firefox has uBlock origin and NoScript, so it loads the bare basics for each site I visit.

</comment><comment><USER3> Terminator then Chrome.</comment>


Mental Models: How to Train Your Brain to Think in New Ways - <AUTHOR> http://jamesclear.com/feynman-mental-models <comment><USER2> I would love to see a trend where posters post anonymously. I don't want to see a trend towards cosy, TED style content where the person is just as/more important than the message.</comment>


R for Data Science - <AUTHOR> http://r4ds.had.co.nz <comment><AUTHOR> I'm the author, and I'm happy to answer any questions.

The book should be in print by (hopefully) the end of this year, or definitely by Jan 2017. The content will not change significantly, but there is will be minor fixes and a lot of proof reading.

<comment><USER2> Trivial, self-serving question: is there a library for generating the diagram of table relationships here (13.2 nycflights13) [http://r4ds.had.co.nz/relational-data.html](http://r4ds.had.co.nz/relational- data.html)

And of course, thanks for another great book, it's helpful for learning R but I'm always enlightened by how thoroughly you explain the general concepts (e.g. Relational data and joins). Have heard a few people on faculty speak enthusiastically about the book even as I hold out for more adoption of Python :)

<comment><AUTHOR> No, I wish there was. Those were painstakingly drawn by hand.

<comment><USER3> Possibly DiagrammeR?

[https://github.com/rich-iannone/DiagrammeR](https://github.com/rich- iannone/DiagrammeR)

</comment></comment></comment></comment><comment><USER4> R for Data Science is the canonical source for learning R and other real-world R tools such as dplyr/tidyr/ggplot2, and one I've recommended on HN submissions about R tutorials which simply go over primitative data types and out-of-date packages. (It's one of the reasons I've postponed making R tutorials myself, since the book would be better/more accurate in all circumstances.)

</comment><comment><USER5> Seems interesting. Quick question:

Some background on myself first. I am a financial consultant (only 1 year since graduating) and am planning to do a PhD in Accounting in the next 3 years. Currently working through the GMAT, but once that is complete, I will find myself with 2 or so years to do things that will help prepare me for research. One thing I have considered is taking a course/reading books on data science and such to prepare me for the advanced stats/data analysis that will go on during research. As someone with no coding experience, and with solid quant background (I was an economics undergrad), would this book be a good starting point for getting experience with this stuff? And is R the appropriate language to learn? I don't mind learning to code, but it is intimidating.

Thanks!

<comment><USER6> Personally I work in macro and fixed income market analysis (strategist), and I can heartily recommend R as your first language. Indeed, coming from a CS background, I first applied Python to many problems, and resisted R which was not a "grown up" programming language, in my opinion (some would make the same accusation on Python). However I dipped my toe in the water one day because R had a Bloomberg terminal add in and Python did not (at the time), and after about a month of uphill learning curve the eureka moments started materializing thick and fast. I cannot recommend R enough, as a problem exploration language. It just beats Python hands down when it comes to grabbing some (usually dirty) data, mangling it around, cleaning it, and then install.package'ing a bunch of potentially useful libraries which allow you to do everything you could possibly imagine to a small to medium sized data set. And crucially, static graphing. Nothing else comes close for this use case.

Now...caveats. R is not a production programming language. If you find yourself creating something truly useful for many users, that requires robust programming language structures such as threading, proper memory management, server-capability, or indeed, speed, R is going to become frustrating. Yes a whole bunch of people will tell you "it's possible, I do it, etc", but that is not its sweet spot. Also, if your data set is bigger than 2-3 gig or so, you're going to start hitting R's memory management wall. It's slow. You'll then be better off with Python, C, or indeed, Scala, or possibly, Apache Spark. The common thing about these caveats, however, is that they're definitely second order problems, later in your career life cycle, than the excellent mainstream data science tool which is R for people who have outgrown Excel, but are not full fledged computer scientists, and who want to get (lots of) stuff, done.

(by the way, pre-empting comments. Yes Pandas is great, but no it's not quite R).

<comment><USER5> Thanks for the replies everyone. I'll definitely save this link and pick up the book when it comes out!

<comment><USER7> If you want to attain a deeper understanding of coding, I suggest you try another language once you get the working basics of R. Maybe some basic MOOC on Python or C. You'll understand concepts of CS that are hard to grasp by learning only R.

</comment></comment></comment></comment><comment><USER8> Looks really nice. I'm a heavy Python/Stata user, but I'm seriously thinking about transitioning, given all the amazing work in the hadleyverse.

Also, RMarkdown looks incredibly well thought out

<comment><AUTHOR> _cough_ tidyverse _cough_

</comment></comment><comment><USER9> I'm learning R for fun at the moment. I'm sure it's super useful for statisticians but it's quite an intricate language! It's an unlikely mix of different paradigms and features mixed together. Not something I'd recommend to a beginner programmer, yet it seems that people love it (even non- programmers).

I looked at several tutorials and what worked for me the best so far are the official manuals [https://cran.r-project.org/manuals.html](https://cran.r-project.org/manuals.html) (esp. the language definition and the "introduction to R").

Moreover, for the programming languages enthusiasts, the following article is pretty interesting:

Evaluating the Design of the R Language (Morandat, Hill, Osvald, Vitek).

"R is a dynamic language for statistical computing that combines lazy functional features and object-oriented programming. This rather unlikely linguistic cocktail would probably never have been prepared by computer scientists, yet the language has become surprisingly popular. With millions of lines of R code available in repositories, we have an opportunity to evaluate the fundamental choices underlying the R language design. Using a combination of static and dynamic program analysis we can assess the impact and success of different language features."

<comment><AUTHOR> You might enjoy <[http://adv-r.had.co.nz/>](http://adv-r.had.co.nz/>), which discusses R from more of a programming language perspective (albeit a programming language that is chiefly used for data analysis). There are a lot of misunderstanding about R the language.

</comment></comment><comment><USER10> Great book!

We also have almost 10,000 forkable & executable R examples on Kaggle ([https://www.kaggle.com/kernels](https://www.kaggle.com/kernels) \- select R from languages). Almost all of these use at least one of Hadley's libraries

</comment><comment><USER11> hadley, I love your book, and I learn a lot from your preferences in R packages. Now is there a general source for determining the "best" packages for various tasks?

CRAN has task views, but they are long lists and don't clearly show popularity or feature matrices. There are just so many options.

Im thinking something like [https://djangopackages.org](https://djangopackages.org) , for example see [https://djangopackages.org/grids/g/commenting/](https://djangopackages.org/grids/g/commenting/)

<comment><AUTHOR> Not yet. It's a hard problem.

</comment></comment><comment><USER12> Hadley, can you share a bit more about your plans for modelr and what need(s) the package will be designed to solve? Congrats on your book btw, I've been reading it for a few weeks and it's quite simply excellent.

<comment><AUTHOR> I don't think modelr is going to change significantly in the future. It solved a pressing problem (fitting models as part of a pipeline) so I could teach modelling using the same interface as everything else in the book.

However, the modelling infrastructure in R is generally showing it's age, and thinking about how to make modelling easier is something that I will be working on in the coming months.

<comment><USER13> I saw the vctrs package repo the other day on your GitHub. What's your plan with that? I guess your covering all of R's base data types (dplyr:data frames, purrr:lists, forcats:factors, vctrs:vectors)? Also do you plan on developing further functional programming packages?

<comment><AUTHOR> Yes. You can read the issues for what the package will start with.

No plans for more FP packages in the near future, although I do want to add multicore and progress bars to purrr.

</comment></comment></comment></comment><comment><USER14> What is the equivalent book for Python and data science?

<comment><USER2> There's a large number of such books, though none that are as authoritative with respect to Python (this is a statement about the size of Python's community vs. R, not necessarily about the authors):

\- via Wes McKinney, creator of pandas (which makes Python about as close to R as you can get): [https://www.amazon.com/Python-Data-Analysis-Wrangling- IPytho...](https://www.amazon.com/Python-Data-Analysis-Wrangling- IPython/dp/1449319793)

\- [http://joelgrus.com/2015/04/26/data-science-from-scratch- fir...](http://joelgrus.com/2015/04/26/data-science-from-scratch-first- principles-with-python/)

There are a bunch of books specific to machine learning too though I haven't read them myself.

<comment><AUTHOR> What would you recommend for visualisation?

<comment><USER2> I actually have no idea about that. I don't think there's an equivalent to R's base graphics, so that would seem to make matplotlib the closest thing to a standard -- seaborn [0], which I've seen used a lot lately for more advanced dataviz, lives atop it, but it's also relatively new.

People seem to have conflicted feelings about matplotlib, maybe because of its origin in MATLAB? Not that Matlab itself is bad, but I think the decision to make matplotlib's API comfortable for MATLAB users seems to cause confusion to contemporary users, even before the usual 2.x vs 3.x issues (matplotlib ported to 3.x a few years ago but many users still write Python in the 2.x style.)

Anecdotally, I feel like I see advice like "Just use plotly" more than I see recommendations to actually learn matplotlib. I actually gave up on matplotlib until I stumbled upon this comprehensive tutorial, which covers the basics and many elaborate use cases. If there's a book that does it better, I haven't heard about it:

[http://www.labri.fr/perso/nrougier/teaching/matplotlib/](http://www.labri.fr/perso/nrougier/teaching/matplotlib/)

The matplotlib site itself is chockful of well-documented examples, but some of them seem to be significantly more verbose than they need to be. My impression is that the library is stable/ubiquitous enough that there isn't a big movement to overhaul things. Last time I looked at the API changes for v2.0 [1] (1.5.3 is stable), most of the changes had to do with default styles and stylesheets, which is non-trivial given the number of people who use ggplot2 because it "just works"

[0] [https://stanford.edu/~mwaskom/software/seaborn/](https://stanford.edu/~mwaskom/software/seaborn/)

[1] [http://matplotlib.org/devdocs/users/dflt_style_changes.html](http://matplotlib.org/devdocs/users/dflt_style_changes.html)

<comment><USER15> What are your thoughts on bokeh? I seem to always revert to R for visualizations</comment></comment></comment></comment></comment>


Experimental drug targeting Alzheimer's disease shows anti-aging effects - <AUTHOR> http://www.salk.edu/news/pressrelease_details.php?press_id=2130 <comment><AUTHOR> Also interesting links about this compounds safety and effect as a treatment to Alzheimer's disease that was previously published ([http://www.alzres.com/content/5/3/25](http://www.alzres.com/content/5/3/25))

Summary from that paper: J147 is an exciting new compound that is extremely potent, safe in animal studies and orally active. J147 is a potential AD therapeutic due to its ability to provide immediate cognition benefits, and it also has the potential to halt and perhaps reverse disease progression in symptomatic animals as demonstrated in these studies.

\--- The new paper is at: [http://www.impactaging.com/papers/v7/n11/pdf/100838.pdf](http://www.impactaging.com/papers/v7/n11/pdf/100838.pdf)

Abstract: Because age is the greatest risk factor for sporadic Alzheimer's disease (AD), phenotypic screens based upon old age‐associated brain toxicities were used to develop the potent neurotrophic drug J147. Since certain aspects of aging may be primary cause of AD, we hypothesized that J147 would be effective against AD‐associated pathology in rapidly aging SAMP8 mice and could be used to identify some of the molecular contributions of aging to AD. An inclusive and integrative multiomics approach was used to investigate protein and gene expression, metabolite levels, and cognition in old and young SAMP8 mice. J147 reduced cognitive deficits in old SAMP8 mice, while restoring multiple molecular markers associated with human AD, vascular pathology, impaired synaptic function, and inflammation to those approaching the young phenotype. The extensive assays used in this study identified a subset of molecular changes associated with aging that may be necessary for the development of AD.</comment>


Porn Site Says PayPal Ban Will Hurt More Than 100k Performers - <AUTHOR> https://www.bloomberg.com/news/articles/2019-11-14/porn-site-says-paypal-ban-will-hurt-more-than-100-000-performers <comment><USER2> Main thread is [https://news.ycombinator.com/item?id=21538460](https://news.ycombinator.com/item?id=21538460)

</comment><comment><USER3> I'm curious why the site isn't mentioned in the title…</comment>


V8 Release 5.2 - <AUTHOR> http://v8project.blogspot.com/2016/06/release-52.html <comment><USER2> Available to use today with NW.js v0.16.0-beta1: [http://nwjs.io/blog/v0.16.0-beta1/](http://nwjs.io/blog/v0.16.0-beta1/)</comment>


DNC Has Told the FBI It Found Evidence Its HQ Was Bugged - <AUTHOR> http://www.motherjones.com/politics/2016/11/dnc-told-fbi-it-may-have-been-bugged <comment><USER2> TL:DR - if there is fire to that smoke, the fire is in the form of an single amateurish IMSI catcher.</comment>


Performance Matters - <AUTHOR> https://www.hillelwayne.com/post/performance-matters/ <comment><USER2> Not sure where the author is from, but I'm not aware of any states that still allow paper PCRs. ePCRs are just a fact of life.

I pretty much never bother opening the laptop until I'm at the hospital. There are a lot of reasons for that, but a laggy UX isn't really one of them (despite the fact that the UX is indeed super laggy on any ePCR I've ever used). Instead I use a pen and paper (or a pen and a strip of white medical tape on my thigh, for a more critical patient).

The reason I don't bother is because the whole UI is just too much of a hassle. Not the application frontend, the whole thing. The laptop, the keyboard, etc. With a pen and paper I don't have to keep taking my gloves off and putting new ones on each time I need to switch from documenting something to caring for the patient (a pen is trivial to wipe down, or just toss if needed). With a pen and paper I can jot simple notes in a shorthand I'm familiar with, rather than having to navigate to the right page to enter the information I want to record at the moment.

I know very few providers that bother touching the laptop prior to arrival at the hospital. Generally we write notes on paper, then bring the laptop into the ER and start typing while we we're waiting for a bed for our patient (it's not uncommon that this takes long enough to get the whole chart written). At my agency we have two hours from when we transfer care to when the chart has to be signed off and locked.

I also chuckled at the suggestion that "0.1% of PCRs have errors that waste an hour of a doctor's time". In my experience 0.1% is pretty much how frequently the PCR gets reviewed at all in the ER, and anything important enough to spend an _hour_ on would have been mentioned up front during the transfer of care (nevermind the fact that an hour is an absurd amount of time for a doctor to be spending on a single patient).

<comment><USER3> My boyfriend is a nurse and said a very similar thing. He said he very rarely looks at a PCR as everything important is conveyed verbally when the handoff from EMT->Hospital.

<comment><USER2> I'm glad I omitted the ER nurse targeted snark in that case... ;)

</comment></comment></comment><comment><USER4> When I was writing software for medical devices in the '90s, we had a very clear policies for dealing with cognitive drift that included performance ceilings, testing for drift in beta testing, etc. In our testing, 10 seconds was the absolute maximum time that a surgeon could "idle" and stay on task in surgery.

In addition, we found that including spinners, progress bars, etc. would not necessarily reduce the cognitive drift but would reduce emotional frustration.

The worst thing for frustration was UI elements being slow; buttons that responded slowly, scrolls that lag, pull-downs that didn't pull down. Exactly as this author notes. There was very little tolerance for those kinds of delays.

I presume that, like website response rate tolerance thresholds that have dropped from 5 seconds to less than 2 seconds now, the medical industry is probably using much lower times now.

<comment><USER5> >> The worst thing for frustration was UI elements being slow; buttons that responded slowly, scrolls that lag, pull-downs that didn't pull down. Exactly as this author notes. There was very little tolerance for those kinds of delays.

IMHO there is NO excuse for those kinds of delays. None. If you have those issues you're doing something terribly wrong.

<comment><USER6> I don't know the details, but many embedded interfaces/controllers don't have very fast processors/microcontrollers and UI is really expensive compared to everything else it has to do (take some inputs, and submit some data).

Think about how laggy the raspberry pi 2 or even 3 in the desktop interface. Sure they can be optimized etc, but now imagine what they wouldn've used 10+ years ago and how slow it would be.

EDIT: I have to agree with you guys, even given the tech they had they should've put a higher priority on responsiveness. I don't know what the status is today, but I know even the 2015 Prius's touch screen feels too unresponsive to my liking.

<comment><USER7> Respectfully, that is a common and tempting argument, but no, no, and no. The raspberry pi 3 has a freaking dual core 64-bit 1.4Ghz processor that is more than fast enough to run full-screen video games at 60Hz.

It's more than just an "optimization" that is making UIs on these plenty-fast processors so slow, it's a large scale failure of software engineering, building slow layers on top of slow layers.

The processor is not the reason for slowness, and we've had absolutely responsive UIs not just 10 years ago, but 50 years ago too. The actual reason is economic: cheap engineering. Using freely available components not well suited to embedded devices, writing layers using scripting languages because it's easy, treating the problem as solved when the functionality is there without regard to the speed.

<comment><USER8> On the other hand, the times were the CPU was polling keyboard resistances and then directly controlling your CRT's electron beam accordingly are long over. Today's systems are complicated, and we try to hide that complexity behind abstractions. All of those with buffers. Input buffers, OS message buffers, tripple image buffers, and so on. All of it adding time.

Yes, we won't again have the responsiveness we had 30 years ago. Because the tradeoffs are just not worth it. At the same time, stories like the article are a necessary reminder of there being worth in performance.

<comment><USER7> There's unnecessary complexity and abstractions -- especially in poorly designed systems, yes, that's part of my point, so I agree there.

> we won't again have the responsiveness we had 30 years ago.

Not sure I can agree with that. For the best systems, we absolutely have better responsiveness now than we've ever had, shorter latencies now in the hundreds sometimes thousands of hertz, and orders of magnitude more compute we can put in between input and response.

Maybe the worst systems are getting worse, but I think on the whole responsiveness has been monotonically improving since the invention of the microchip.

> the times were the CPU was polling keyboard resistances and then directly > controlling your CRT's electron beam accordingly are long over.

I don't know every system ever made, but I don't think there was any long period of time when application software on digital computers controlled the electron beam in a CRT directly or polled keyboard resistances directly, those were abstracted by the hardware via DACs & buffers more or less from the start. Maybe some of the old vector display video games did, I'm not certain, but in any case, it's been abstracted that way for more than 30 years. The first framebuffers happened almost 70 years ago, before 1950.

<comment><USER9> The raw throughputs are definitely better but there is concern regarding latency even at the lowest levels, since today's CPUs have complex cache, power state and frequency throttling mechanisms. You cannot guarantee that something will perform with identical runtime in all expected use-cases unless you take care to use hardware that is optimized in that direction. And because the software environments are more complex a lot of capability is just dropped on the floor because the intermediate layers get in the way.

W/R to buffers in front of things, a decent number of the micro systems of the 70's were so memory starved that they would make these tradeoffs to retain video sync - that describes the Atari 2600("racing the beam" is the name of a book about the console), and Cinematronics vector games(if it did not complete drawing at 60hz, it reset). Most early arcade games did work with DACs(or rather ADCs) but ran their own calibration and button debounce code - and even with layers of abstraction that's still basically true today.

With graphics, the move towards desktop environments doing GPU compositing impacts graphics coders, since they now often have window manager buffers in front of them instead of direct access to a rectangle of pixels.

Web browsers are a more extreme example of this. Because the graphics model revolves around document presentation, things that aren't really documents, or are extremely customized documents, often get burdened by latency that they wouldn't have if it weren't for the browser.

<comment><USER7> Ah, I've been meaning to read Racing the Beam for years!

That's all true, and thanks for an insightful comment!

I would just add though that it's easy to frame things in a way that makes it seem harder than it really is to maintain responsiveness. For example, while yes caching makes guaranteeing exactly repeatable timing a problem, that's an issue at the nanosecond/microsecond level, and not really a problem at the millisecond (human perception) level at all. Today's hardware doesn't have issues maintaining 60hz unless the software isn't even trying.

Another counter-example would be that while yes, browsers and desktop UIs are doing compositing and don't have direct access to the pixel buffer, the compositing is actually done on the GPU via low-latency commands. Direct access to the pixel buffer would actually be much slower than what we have right now. The browser has no trouble responding and rendering at 60hz unless you do things that cause more than the ~16ms of compute you have time for. Triggering page reflows will do that, but compositing an animated WebGL canvas over something else on the page is plenty fast.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER10> People who quote "premature optimization is etc." never provide the full quote. The full quote has a significant degree of highly important nuance.

> "Programmers waste enormous amounts of time thinking about, or worrying > about, the speed of noncritical parts of their programs, and these attempts > at efficiency actually have a strong negative impact when debugging and > maintenance are considered. We should forget about small efficiencies, say > about 97% of the time: premature optimization is the root of all evil. Yet > we should not pass up our opportunities in that critical 3%."

"Premature optimization is the root of all evil" is incomplete without the surrounding context, and people unfortunately take it to mean "never worry about how efficient your code is," which is not at all what Knuth intended.

<comment><USER11> Basically it can be summed up to "don't optimize until you've identified the critical paths"

<comment><USER12> That's oversimplifying it. Knuth was writing about micro-optimizations, like writing a section of code in assembly language to shave off some milliseconds from a critical section of code.

What many people today mean by optimization is a far cry from that.

Here's a real-life example. Some code was super-slow and nobody could figure out why. It took only a minute to see the code was passing a string (in C++) by value, causing unnecessary copy construction and destruction (in a tight loop, to boot).

Writing that code by passing a const reference in the first place is Good Coding 101, but many people might consider that "premature optimization".

</comment></comment></comment><comment><USER13> Something is missing in this conversation. Do the people who are creating the applications that deal with medical data have motivation to make it better or more useful?

I've spoken with numerous people in my life who deal with these types of systems. Everyone complains. Fields for information are in unexpected places. There are too many things to click on. All of the people I've talked with agree on the same things.

It's as if no UX people were involved. The experience doesn't fit the need quite right.

What would motivate the makers of these things to improve on the situation? How are the contracts won? Do the people who have to use this stuff have a say in it? Do the hospitals and doctors offices measure stats to see what's working and what's not?

This space is ripe for disruption simply based on user experience.

<comment><USER14> I worked on EMS data entry software for a while (deepest apologies to any EMTs reading) and the big issue we ran into was needing to fulfill doctor/administrator pet projects to get a sale.

The county wants to collect data on if a drowning incident happened at a pool without a locking gate. Now all services need to update their software to include a random checkbox. An EMT was caught without gloves and now the parent hospital wants EMTs to record what levels of PPE they wear on every run. The customer might get a grant if they can help track infectious diseases so now there is an extra box where the EMT can guess if the patient has the flu.

In the abstract that is good data to want to know, but it ends up being more junk on the screen for the EMT to skip over while dealing with the patient or sitting in the hospital parking lot after a run.

<comment><USER2> If I had a dollar for every time I swore at NEMSIS, I could quit my day job...

<comment><USER14> NEMSIS is ugly, but it is vastly easier to work with than HL7. That was an evil XML standard.

<comment><USER15> Was? Has the US medical system finally moved on from HL7?

<comment><USER2> Newer versions of HL7 (and FHIR) aren't (exclusively) XML.

</comment></comment></comment></comment></comment></comment><comment><USER16> I believe performance does matter and should factor into the design of a system. There is an ISO guidelines on software system requirements and specifications that has a section for performance requirements. It does matter even for banal, non-critical or non-life-threatening software systems.

Another often-overlooked requirement: environment. Does the human using your software system have to pay attention to more important situations around them? Is the environment they're using your software in noisy, stressful, dangerous or dirty? Should you expect frequent wireless interference or degraded wireless performance?

Reading the ISO specs are pretty boring, so is the SWEBOK guide, but it's rather interesting to think about software in terms of the whole system and not as an artifact unto itself.

<comment><USER17> You'll probably like Nancy Leveson's model and work if you haven't seen it:

[http://sunnyday.mit.edu/accidents/safetyscience- single.pdf](http://sunnyday.mit.edu/accidents/safetyscience-single.pdf)

[http://sunnyday.mit.edu/](http://sunnyday.mit.edu/)

</comment></comment><comment><USER18> As a former EMT and someone who built their own software to create run reports, I'm a bit skeptical as to that being the only reason.

Paper can be edited, even after the point at which you given a carbon copy to a hospital, if you're friendly enough. This probably doesn't happen often or at all but there is a psychological safety there.

People make small mistakes all the time on the ambulance in the rush to get them to the ER. We live in an extremely litigious society.

<comment><USER19> That's a good insight. Never dealt with any medical stuff, but I dealt with paperwork in the military as it was going through a (long painful) transition to electronic documents back in the '00s.

And I don't think it's just that society is litigous, but that databases actually (mostly?) work in terms of enforcing the rules you give them.

One anecdote of how things changed was that you used to be able to arrive on post, and if you didn't like your orders, talk to a sergeant major of another unit and quietly get your orders changed, which no doubt drove PERSCOM crazy.

When things were done with paper, there was a certain degree of flexibility in the rules that gave people some amount of local autonomy. When those rules are enforced by a computer, there's much less possibility of someone being able to override the rules when it makes sense.

Normal human social interaction tends to create unwritten rules that are simply more flexible and realistic than the rules we're willing or able to write down.

<comment><USER20> We have a platform that amongst other things automates filling in a fairly complex government form, including online signature.

We did a demo the other day to a large new customer. I learned that when they filled in the existing paper form, they didn't just sign it, they also stamped in the signature box with a little rubber stamp that "signed on behalf of the CEO".

It wasn't immediately clear whether anyone handling the form was looking for that stamp, nor what they did when they saw it. As a result, it's not clear to us at this stage whether our pdf generation now needs a new feature to allow a user-uploadable image file to be imprinted over the form.

That's the sort of thing you get with the joyous "flexibility" of paper.

</comment></comment></comment><comment><USER21> So, interesting and all, but it ignores the main reason for the advice to build it first, then optimize for performance, which is that if you build everything for performance from the beginning, you end up with a lot of code that is optimizing for performance of something that isn't the bottleneck. In other words, performance that doesn't show up in the user's experience, because something else is the main delay.

Now, if all that meant was that the programmer has to do some more work, and you aren't worried about paying more for the software, this may not matter, but that is far from the only (or even most important) result of optimizing everything for performance. Instead, what you get is code that is much longer, and more complex, and therefore harder to update, and more likely to be buggy.

For example, one common thing you have to do to get performance, is to cache values in multiple places, instead of looking them up every time. This can result in big improvements to software performance if done in the places which are the current limiting step, but now you have to make sure you invalidate the cache correctly. In particular, if you don't, you get stale values in the cache, which is to say false data.

If you make a system with cacheing all over the place, it will be very hard to make changes correctly, which means sometimes they will get made incorrectly. In mission-critical systems, this is even less acceptable than elsewhere.

It's not just "I don't feel like optimizing". More often, it's the cost of optimizing is not worth the benefit, for this particular part of the code. How do you know what spots in the code it's worth it? You don't optimize, at first, and then see which two or three spots in the system are rate-limiting.

<comment><USER22> > _Instead, what you get is code that is much longer, and more complex, and > therefore harder to update, and more likely to be buggy._

I'm gonna repost a chart I made previously[0][1].

      Spectrum of performance:
      LO |---*</comment></comment><comment>-*</comment><comment>--*</comment><comment></comment><comment>*</comment><comment>-| HI
             ^       ^        ^            ^
             |       |        |            |_root of all evil if premature
             |       |        |_you should be here
             |       |_you can be here if you don't do stupid things
             |_you are here

Tricks like denormalizing your data model ("cache values in multiple places") start somewhere around the "you should be here" point. But in any typical program there's plenty of stuff to be done left of that point, and those things don't make your code more complex or longer. They only require care and willingness from the software vendor.

\--

[0] - [https://news.ycombinator.com/item?id=20389856](https://news.ycombinator.com/item?id=20389856)

[1] - [https://news.ycombinator.com/item?id=20520605](https://news.ycombinator.com/item?id=20520605)

<comment><USER23> Usually, it's more like this:

      LO |---*</comment></comment><comment></comment><comment></comment><comment>*----*--*-| HI
             ^                  ^    ^  ^
             |                  |    |  |_root of all evil if premature
             |                  |    |_you should be here
             |                  |_you can be here if you don't do stupid things
             |_you are here

</comment><comment><USER24> Welcome to the world of soft realtime applications. Sounds like this one is just so bad that a) the designers didn't realize that was what they were designing and b) consequently it failed to meet any of its deadlines in the UI domain.

One detail I've noticed is that even if you do a shitty job of hitting the deadlines, users will often find workarounds. As long as a critical mass of features respond consistently within the deadlines, users will fiddle around to make the rest work-- even if you tell them directly that it isn't possible.

Say the dropdown menus here performed fast enough, but going to the "next page" required a bunch of DOM mutation or something that grinds to a halt for two seconds. I'd bet EMTs would have trained themselves to do branch prediction-- hit the button to change pages before setting it down, hit it again based on what the patient is communicating to the other EMT, and so forth. I've seen users do weirder stuff.

The fact that they discarded it altogether tells you how bad the UI was.

</comment><comment><USER25> I use to use Amiga computers, I presently use Haiku - i am not trying to say those are the best OSes. But when I use Windows I am surprise how slow some functions are.

Worse, I can use two different programs in Windows and one will be dog-slow compared to the other.

I blame the use of pre-written libraries that in turn call more libraries that in turn call still more. There was a site on Windows bloat-ware, there were for example programs having multiple version of the same library link into the code even while the program only used one library ever.

Also the screen layout is runned thru a layout program/library that slows things down, the layout system is great when you are designing the system, but once you reach the point of final and fixed design there are faster ways to display it.

on the other hand, management is too often cheap, and says "It works, don't it?" and do not want to pay for the extra coding that would make so much faster.

<comment><USER26> It isn't just management. Most software ecosystems (Rust, C, c++ excluded) discourage any thinking about or tinkering with performance knowledge. You see evidence of this on stackoverflow questions, questions on reddit and twitter. Young people or new programmers curious about the fastest way to do things are always lectured about how this is not good to do. It is quite unfortunate because building some experience for how to do things fast is very useful. It isn't always correct to optimize the hell out of things, of course, but we should encourage the curiosity behind it, so that more of us have the tools to do it when it is correct to do so.

<comment> mark-r I have often found that doing things efficiently isn't really harder than doing them slow. So why not aim for software that's reasonably performant from the start? Sure you can micro-optimize to get every last nanosecond, but that's not what I'm talking about.

</comment></comment></comment><comment><USER27> My philosophical rule of thumb is that it is morally wrong for humans to ever wait on computers, period. It's an unattainable standard but results in much better software IMO.

</comment><comment><USER28> > Something like a quarter-second lag when you opened a dropdown or clicked a > button

So the title would more accurately be "UI responsiveness matters"? I doubt anyone would think this kind of lag doesn't matter. It sounds like the software was designed (and tested) for better hardware than it is running on, or at least different hardware. But that's just a guess.

<comment><USER29> Genuinely curious, what is the difference between performance and responsiveness in this context, and why would it be better as "responsiveness"?

<comment><USER30> You can make a UI feel responsive even if the underlying system is not performant.

Let's say you have a client app with checkbox that toggles some boolean variable that communicates with a server. If you're on a 3g connection in an ambulance, it might take a few seconds to send that request to the server and get a response back.

An unresponsive UI would sit there and make you wait for the request/response to complete. You click the checkbox, then nothing happens, then suddenly, some time later, the checkbox is checked and the page refreshes, or a state change happens. It's jarring and weird. A responsive UI would update the state of the app based on the user's actions even if the request hasn't completed yet.

Tightly related to this the concept of optimistic UIs - the UI acts optimistically and updates the state of the app under the assumption that server-backed state changes will work. The iPhone's messages app sending messages is the prototypical optimistic UI interaction. You send a message, the blue / green speech bubble shows up on your messages app while the message is in flight. If it succeeds, nothing changes and you're none the wiser. If it fails, you get an option to delete the message or resend.

<comment><USER31> Some (subtle) confirmation is nice, too, when the user is actively aware that the process is fallible. The Messages example you chose has this: a small gray "Delivered" tag is added below the message when the sending device hears back from the server.

</comment></comment></comment></comment><comment><USER32> _Did that quarter-second lag kill anyone? Was there someone who wouldn't have died if the ePCR was just a little bit faster, fast enough to be usable? And the people who built it: did they ask the same questions? Did they say "premature optimization is bad" and not think about performance until it was too late? Did they decide another feature for the client was more important than making the existing features faster? Did they even think about performance at all?_

This seems like a lot of imagining of scenarios that may or may not have happened. Perhaps another way of looking at this is - did the company hired to build this actually care whether EMTs used their software, or were they looking to get a paycheck?

So many health tech firms fall in the latter bucket. Such is the reality of the business - with huge enterprise sales funnels and hospital networks that don't understand the value of UX & great product (and caring a lot about their bottom line), this result isn't unexpected.

<comment><USER2> If someone is sick enough that a "quarter second" matters, there's zero chance the tablet is out in the first place. In reality if a quarter second is enough to kill someone, they're gonna die anyway...

<comment><USER33> I feel the same about my EKG. What's a quarter second when it comes to measuring a heart? Who cares about precision.

<comment><USER2> A quarter of a second in measurement resolution of an EKG is huge. An extra quarter of a second interpreting or documenting that EKG couldn't be any more meaningless.

</comment></comment></comment></comment><comment><USER34> This sounds like a clear case of consultant software. _The people building it won 't be dogfooding the result_ \- at most they'll be clicking around the UI on their powerful desktop machine and patting themselves on the back because it responds in less than half a second. _The requirements will be vague,_ because getting performance requirements anywhere beyond stupidly vague "performant on modern hardware" or some shit requires _real expertise_ in UI design and will cost _real money_ to build, and UI designers won't be involved in the details until the contract is signed.

"Premature optimization" in reality is a vacuous phrase, because premature _anything_ is bad - it's right there in the word! (Insert joke here.) The problem is that most developers (myself included in many cases) are just not qualified to say when it is premature to optimize, _because the requirements do not state anything meaningful about performance._

If you think this is overly pessimistic, I would encourage running pretty much any Android app or opening any major website on a 2018 or older smartphone. It's pretty obvious developers don't know how to build software for the probably 50% or more of customers who don't buy a new top-of-the-line phone every year.

As for performance guidelines, have a look at Jakob Nielsen's amazing _evidence-backed_ UX guidelines such as Response Times: The 3 Important Limits[0]. The ones which should stick are that 0.1s feels instantaneous (probably not when using a scroll bar, but that's another matter) and 1s is the limit for not interrupting the user's flow of thought. In other words, if _anything_ your program does takes more than 0.1s to respond to user input on the target hardware that should at least be acknowledged and prioritized (maybe at the end of the backlog, but at least then it's a known issue).

[0] [https://www.nngroup.com/articles/response- times-3-important-...](https://www.nngroup.com/articles/response- times-3-important-limits/)

</comment><comment><USER35> I have a theory on the dynamic being described, based on my experiences as a software developer.

When you are juggling and prioritizing a list of tasks, they are occupying short term memory. If you can perform the current task from muscle memory, you don't upset working memory. But as soon as you start having to think about it, and worse once you start editorializing in your head, things start to drop off.

Worst case results of this phenomenon have occurred when you finish a hard task and you have to ask yourself, "what was I doing?/why was I doing this?"

So you want your tools to be unobtrusive. People who love hand tools know this. Somehow we do not.

<comment><USER36> Indeed.

"If I have to pay nearly as much or more attention to the use of this software than it saves me, it is by definition worthless."

Intellisense in VS/Resharper went through a nice period a few years back where it was smart enough to match what was meant, fast enough that it didn't (usually) drop keypresses, and (crucially) stupid enough that typing the same thing twice would get the same results. Sadly, all of the above have been lost in the hail of features...

Context sensitivity is not always a good thing in a tool. Muscle memory wins.

</comment></comment><comment><USER37> Sounds like this PCR software should be structured around letting the operator enter information almost as freeform as possible, basically collecting timestamped notes that are reviewed and formalized afterward.

UI up front can be very fast capture, with asynch layer to parse and formalize constructs, with a third stage of prefilling the final form (if paper layout needs to be maintained etc) and allowing very flexible revision.

Last step would be archiving locally and then transmitting to whatever outside system.

<comment><USER38> It'd be even better if, say, your insurance card had your basic medical info stored on it in some encrypted form, and then the EMTs could just scan the card and have half the form populated with accurate information automatically. Or if it just stored some kind of UID that the PCR system could use to pull that information from the insurance company's database.

</comment></comment><comment><USER39> I saw this myself in an ambulance in the Boston area. The PCR system they were using was on some Toughbook-style computer, and I could tell that it was lagging and slow to input basic stuff on. Apparently whoever had put it together cared more about durability (important) than performance. Or maybe it worked great when it was deployed, but the newer software updates weren't built for such a slow machine. They used it; but it was like inputting a data on a slow ATM.

<comment><USER22> Or maybe they made some stupid decisions like making each update query something over the Internet, which works fine when testing, but not when you're on the streets, in close proximity to a lot of other cellular Internet users.

</comment></comment><comment><USER40> I'm can't dispute that fast software is a desirable trait for users. I would love to spec low latencies into the requirements documents for my GUI projects. But from a business standpoint, UI latency requirements are a good way to sabotage a project.

Slow solutions have a dramatic business advantage: using libraries, you can shave months off your delivery schedule by adding miliseconds to your UI delays. The months add up; so do the miliseconds. By using someone else's crufty libraries, you can write a calculator app over the weekend. Libraries will handle the double buffering for screen painting, unpacking fonts and rendering them into bitmaps, how to reflow text onto a screen, etc. It might take seconds for the app to load all it's assets and display the first user activity, but it was cheap to create, easy to iterate, and it gets the job done. These are hallmarks of a valuable startup engineering effort.

But the development process for speedy applications is anathema to businesses of any size. You have to throw away Electron and hire systems engineers with knowledge of the entire platform. After some profiling, they may determine that the required speed is only possible once the system event handler has been replaced with a pared down routine, or when the framework's audio interface is bypassed so the sound card can be accessed through low-latency DMA mode. You have to repeat this for every platform you intend to support. You have to throw away the wheel that everyone else is using and pay to reinvent one that spins a little faster.

To paraphrase Joel Spolsky's comment on rewriting software: are you sure you want to give that kind of a gift to your competitor? For most companies it isn't worth it.

Are there exceptions? Yes: a motivated engineer like John Carmack may work months to eliminate another 3ms frame latency out of a VR headset simply because of personal passion. Google can amortize additional billions by wringing 100ms out of page load times by funding a browser project so complex that you also have to design a new build system for it. But if you're not Carmack and you're not Google, you probably can't afford to reinvent the wheel.

<comment><USER41> John Carmack doesn't work hard to eliminate 3ms of frame latency simply because of personal passion. In VR applications, latency kills and will make people sick. Those hard fought ms are needed. You only have 11 ms per frame at 90 Hz.

As someone who works in the performance arena myself I feel like a lot of the work I do is undoing the mistakes that the attitude that it's OK to not care about performance so I'll just do it the 'easy' way. It's pretty much a form of technical debt that is somehow culturally acceptable. For years we've had Moore's law covering everyone's asses but perhaps there will be a reckoning yet.

<comment><USER40> I don't mean to belittle performance work, but the value of Carmack's successful optimizations in the VR industry doesn't translate to most business.

Let's say we have a $1M/year business opportunity with a requirement that a user be able to take 1MB photos on a phone and have them appear on a PC/laptop which are both connected to a 802.11G access point and on the same internet- connected network segment. The time requirement on this phone->pc transfer will dramatically affect the software development effort in terms of time, money, and skills.

With a requirement spec of 1 photo every 10 seconds, commodity software can already accomplish this. With a cloud account from their smartphone vendor, a user can monitor their photo album from their PC browser, and photos taken on their phone will be sync'd to the cloud, then visible on the laptop. Assuming both devices are on wifi with a typical cable modem connection, the transfer of the photo from phone->cloud->PC-browser would occur within 10 seconds. No software engineering required, supports MAC/Windows/Linux and iOS/Android out of the box.

Now let's spec a 1 second transfer time. Cloud syncing is out; we'll need the phone and the PC to communicate directly over the wifi link; we'll have to write a phone app that sends the photo file over a socket, and a PC app to receive it and display it on screen. 1MB will take 500ms across a healthy 802.11G link, so we have 500ms leftover to allow the phone's camera app to store the photo as a file, for our app to establish a TCP connection, for our PC app to accept the incoming file, and display it in an ImageBox control. We can still meet the 1 second spec on a poor wifi connection... Wait, how does the phone know the address of the PC it's going to send the picture to? We'll need to write our own discovery service to allow the phone to learn the IP of the PC... Should we do layer 2 , or cloud assisted? Or maybe we'll have the phone scan a QR code on the PC in order to link the phone to the PC... We've only imposed a 1-frame-per-second requirement, but we're going to require a software team familiar with PC app development, phone app development, layer 2 and layer 3 network protocols. You could hard code the IP addresses for a quick demo, but you're looking at a small team coding in several languages for several months just to support a single platform (say, Windows PC with Android phone.) Additional platforms will require a repeated effort.

But Carmack would never be happy with 1FPS. What if we spec a 40ms transfer time (24FPS), such that the user could use the laptop/PC screen as a hollywood-movie-grade viewfinder. Now we have to throw away the phone's camera app and write our own that bypasses the save-to-file step and streams the image data directly to the PC over UDP, perhaps RTP. Since the raw camera data takes too long to send over the network, we may also need to visit image compression techniques. Some techniques will be faster on certain phones, so we'll need a heuristic compression algorithm selector to make sure we're correctly optimizing for spending the least amount of time in the combination of compression+transport. On the PC side we'll need an RTP client to receive the data, but also a method to paint the frame buffer data directly into the viewport (no more loading files into an ImageBox control). We may need to explore the gains from painting the image as an OpenGL texture. At this point, our engineering budget has exploded! We're talking about hiring telecom engineers with experience tuning VoIP stacks, digital signal processing and codecs, and video game engine experts to help with low level graphics in OpenGL/DirectX. Perhaps we'd need to retain Carmack himself to advise.

If you have a business opportunity worth $1M/year that relies on moving photos from your iPhone to your Macbook, spec'ing 10s is a great way to get your business started leveraging existing technology. Spec'ing 1s might be acceptable to give your app some polish once you're established, and if you're not FAANG and not Carmack himself, spec'ing 10ms would be a great way to kill your business regardless of size.

</comment></comment></comment><comment><USER42> "Premature optimization is the root of all evil" is one of those programming sayings that's very often misunderstood.

It _does not_ mean that performance doesn't matter or that you shouldn't think about performance.

What it means is two things:

(1) It's usually a waste of time to tinker with small optimizations until you've made things work and until you've profiled.

(2) Don't compromise your design or write unmaintainable code out of premature concern over performance.

The second is the more important and subtile meaning. It means don't let concern for performance hobble your thinking about a problem.

</comment><comment><USER43> Why does this post have so many points? How is that article useful to most readers? I sometimes don't understand HN.

Performance matters... the article talks about a case that most of us aren't confronted with.

Beside, it concludes that in spite of paper being slower, it's still prefered, so how does that prove that "performance matters"?!

Should an article be upvoted just because an article is about life and death and has a catchy (pretentiously) laconic title?

<comment><USER44> Paper is preferred because it has better performance than the software, which is the thing that people should think about. Writing software that can outperform paper shouldn't be hard to do, but apparently it is.

</comment></comment><comment><USER45> It's about trade-off. You improve performance at the cost of something else you're not working on. Without the context, it's hard to tell if that cost was justified. I.e. maybe there were 20 critical bugs and the team made the call that perf. was good-enough and it was better to stabilize the software. Most often than not, you can always improve performance and drawing the line is hard.

</comment><comment><USER46> My first tablet was kinda slow. At least slow enough that when it got too old, I wondered if I even wanted to buy another tablet, because I rarely used the first one.

Then I bought a new one, which was faster and more responsive and my tablet usage completely changed ;-)

So I can personally testify that performance is a most relevant part of the user experience.

</comment><comment><USER47> I don't think the word performance is key, but rather /user experience/.

</comment><comment><USER48> Sometimes you need to take a step back and consider the bigger picture. Is it really necessary to make an EMT fill out a 100-field form?

</comment><comment><USER49> B

</comment><comment><USER44> Always remember the Doherty-Threshold.

"Productivity soars when a computer and its users interact at a pace (<400ms) that ensures that neither has to wait on the other."

[https://lawsofux.com/doherty-threshold](https://lawsofux.com/doherty- threshold)

</comment><comment><USER50> Quote: _It wasn't even that slow. Something like a quarter-second lag when you opened a dropdown or clicked a button. But it made things so unpleasant that nobody wanted to touch it._

I'm skeptical that's the reason they didn't use it unless it's a high-volume application. Like everything in IT, it depends.

A high-volume app definitely needs attention to response and performance because employees will be wasting tons of hours if it's not. That's why primary applications should probably be desktop client-server applications, where it's easier to control the UI. But that's typically only roughly 1/4 of all apps used by an org.

Something used only occasionally, such as for customers with special conditions, a somewhat sluggish web app is probably fine. If it's easy to make it snappy, great, but not everything is, due to our annoying web (non) standards[1]. If it takes 100 hours of programming to reduce 50 hours of UI waits over say a 10 year period, then the org doesn't benefit. 10 years is a good default rule of thumb duration for software lifetime. Your org may vary. Remember to include program maintenance, not just initial coding.

In short, use the right tool for the job, and do some analysis math before starting.

[1] My "favorite" rant is that web-standards suck for typical work-oriented productivity applications, and need a big overhaul or supplement. Nobody wants to solve this.

<comment><USER51> I'm sorry; are you saying that electronic patient care reports are not a "high volume application", that they should be "desktop client-server applications," or that the statements by the users about why they don't use the system should be disregarded?

<comment><USER50> I don't have the usage & programming labor stats to make a definitive statement on that _particular_ application including the size of the org using it. My main point was that "it depends" and should be subject to further tradeoff and business analysis rather than "X is _always_ bad".

A quarter-second lag does not sound like a significant problem to me, and may require a lot of IT funds to remove. Often such is only justified if it's a high-use application. Would you agree that 100 hours of extra programming to save 50 hours of data entry time is usually not worth it (all else being equal)? If so, let's start there and slice into further factors.

Please don't give me bad scores for trying to be logical and rational, people! Resources are limited, orgs have to spend with care. Sure, it's nice job security for us IT people if orgs spend big bucks to make all apps snappy, but from a business and/or accounting standpoint, it could be the wrong decision. You view the world different when _your_ money is on the line.

If you know a way to make all apps cheap, good, AND snappy at the same time, let's here it! I'm all Vulcan ears.

Note that one can make web apps snappy, but there are often maintenance and/or creation time tradeoffs for doing such. A few well-run shops do it well, but most shops are average-run.

<comment><USER50> Correction: "let's hear it" instead of "let's here it". Modnays.</comment></comment></comment></comment>


Show HN: BerkananSDK – Empowering crowds with cross-app offline chat - <AUTHOR> https://github.com/zssz/BerkananSDK <comment><AUTHOR> Hi Hacker News!

We're Carmen and Zsombor, the co-founders of Berkanan ([https://berkanan.chat](https://berkanan.chat)), a YC Startup School 2019 graduate ([https://www.startupschool.org/companies/berkanan](https://www.startupschool.org/companies/berkanan)).

We're building a Bluetooth-powered offline messaging service for crowds and we invite you, app developers, to join us on our mission!

Today we're excited to release BerkananSDK ([https://github.com/zssz/BerkananSDK](https://github.com/zssz/BerkananSDK)) — an open-source SDK that unites apps into a shared Bluetooth service.

How it works from a user's perspective: Launch an app with BerkananSDK on your device. Type in a message for the crowd around you and hit send. The app will broadcast your message to all apps with BerkananSDK in range. The range is about 70 meters, but your message can reach further because it's retransmitted by receiving apps.

We're very excited about this and its benefits for the community, especially in emergencies, and we believe it can be enabled if multiple apps join forces.

Looking forward to reading your thoughts, ideas, and suggestions!</comment>


Smart Watch Will Charge Itself Using Heat from Your Skin - <AUTHOR> http://spectrum.ieee.org/view-from-the-valley/consumer-electronics/gadgets/this-smart-watch-will-charge-itself-using-the-heat-of-your-skin <comment><USER2> "Launched […] on Indiegogo"

This should be a huge red flag.

Indiegogo is _notorious_ for hosting fundraisers for technology projects that are impractical, overpromised, or even physically impossible. Unlike their competitor Kickstarter, Indiegogo performs almost no fact-checking on projects, which has resulted in a number of high-profile scams (like the Skarp laser razor, the DragonFly FutureFon smartphone, and the Triton Gills breathing apparatus).

The fact that their fundraiser is operating in Indiegogo's "flexible funding" mode -- which allows them to receive funds even if their goal is not met -- should be an additional warning sign. Real hardware projects have financial targets that must be reached to make them break even.

<comment><USER3> but a writeup on ieee.org has to mean they are vetted!

oh wait, its some blog hosted on ieee domain :), certain Australian is bound to make a video about this.

<comment><USER4> Spectrum is a great publication actually. They cover a lot of stuff fresh out of the lab, but I'm surprised to see this on there. I can't remember the last time I covered something launching on Indiegogo, it always turns on my BS sensor.

</comment></comment></comment><comment><USER5> So if a human burns ~2000 calories per day and has 1.5-2 m^2 of skin, that means that a reasonable upper bound on (mean) thermal flux density of human skin is around 65 W/m^2. So if a watch makes contact with an area of, say, 2 square inches, that comes out to... 85 mW of available thermal energy?

Am I missing something?

<comment> david-given A basic low-power microprocessor (like the MSP430) will run at 1MIPS at about 0.5mA. (Less when sleeping.) At 3V, that's 1.5mW. A Sharp epaper display, like on the Pebble, consumes basically nil when not changing, although I can't find data on energy use when updating. A traditional STN LCD uses about 1mW.

So I reckon it's _plausible_ , just --- thermoelectric generators have traditionally been really inefficient, and I don't know whether getting 2.5mW of electricity out of 85mW of heat is possible. Particularly if you're like me and wear the watch quite loosely.

 _Edit:_ Datasheet: [http://www.ti.com/lit/ds/slase54a/slase54a.pdf](http://www.ti.com/lit/ds/slase54a/slase54a.pdf)

That's an FRAM model with non-volatile RAM, so it can power down completely without losing memory. It claims it'll sleep with the clock on at 450nA. (That's nano, not milli.) It also claims it'll run with the processor on at 120 µA/MHz, so the 1 MIPS figure I quoted above must be about 4MHz. I've never run one below that but I gather they'll go down to about 500kHz. Enabling peripherals costs more, of course, but you can leave them powered off until you want to use them.

So, yeah. Totally plausible.

<comment><USER6> There are CPUs out there with sleep currents well below 0.1 mA, for example the Microchip nanoWatt XLP. The product page advertises 9 nA in a best case sceneario.

<comment> david-given Well, the MSP430 sleeps at about 1µA --- below if you turn the clock off!

But as you're not really getting anything done when the processor's not asleep, I quoted the power consumption when running. (Of course it's possible to use a capacitor to soak up energy and then run the processor at higher currents, in burst. You'd probably want to do this if you want radio. But on average, you're still getting about the same amount of work done.)

<comment><USER7> Slight digression, but the MSP430 is obsolete; modern low power ARM microcontrollers are superior in every dimension.[1]

[1] I have worked on products with both uC, and the company where I work buys both by the reel and tray.

<comment> david-given Would those be the new Atmel SAM L21? I see a reference to 35 µA/MHz and 200 nA sleep mode:

[http://www.atmel.com/products/microcontrollers/arm/sam-l.asp...](http://www.atmel.com/products/microcontrollers/arm/sam-l.aspx)

So:

(a) yay! super low power processors! Bet you can run these off a couple of long wires and radio scavanging;

(b) ARMs are so dull. [sad face] The MSP430 is a lovely processor to write machine code for. ARMs are just... dull.

Anyway, thanks for the suggestion. I _think_ the MSP430s have a monopoly on FRAM, which makes a vast difference in usability, but I'll check these out.

<comment><USER7> The low power Kinetis processor can run at low speed for 32 µA, and down to 1.7 V. Many of the ARM manufacturers produce similar parts.

</comment></comment></comment></comment></comment></comment></comment><comment><USER8> Wow, so great to see this on the front page of HN! I work here, any questions, just ask!

<comment><USER9> If it requires temperature differentials so that the cold side of the watch is away from your skin, what happens when the external temperature gets somewhere above 90F/32C?

<comment><USER8> The technology is able to harness a temperature gradient regardless of its direction, but you're right that the larger the gradient the better it works.

<comment><USER10> Do you expect to see different performance (and therefore adoption rates) in different regions of the US/world?

Folks in sunny California saw optimal performance of their Tesla batteries, compared to folks in the chilly northeast—perhaps this is the flip side of the coin?

</comment></comment></comment></comment><comment><USER11> Seiko built similar thermoelectric harvesters for their (very!) limited run of Thermic watches in the late 1990s:

[http://www.travisdeyle.com/blog/2007/03/12/thermo- electric-g...](http://www.travisdeyle.com/blog/2007/03/12/thermo-electric- generator-energy-scavenging)

<comment><USER12> Citizen, Seiko, Casio all seem to offer a wide range of solar powered watches now. I wonder what the ranges are for energy collected by watches for various thermal, kinetic, and solar methods?

I've had a Citizen EcoDrive (solar) for over a decade now.. it just keeps going..

Edit: I see now Citizen also started (1999) and stopped making thermal powered watches... [https://en.wikipedia.org/wiki/Eco- Drive](https://en.wikipedia.org/wiki/Eco-Drive)

</comment></comment><comment><USER13> I see the same problem here as with self winding watches -- the idea works well enough so long as a person has only one watch which they wear daily. Otherwise, the watch may lose enough energy that it stops keeping time and has to be reset the next time it's worn.

Watch collectors can buy "watch winders", a motor driven storage case that will keep their self-winding watches going when they're not being worn. I suppose that now the manufacturers will have to add little heating pads to keep these body heat powered watches going as well.

</comment><comment><USER14> Why don't they just use kinetic energy from the movement of your arm like mechanical watches have been doing for many decades now? Surely it's easier and more of it.

</comment><comment><USER15> I love that they're called "Matrix".

Turning us into batteries.

</comment><comment><USER16> Temperature differential is the hardest aspect of this, even if they somehow manage to pipe the heat around the edges any time the user is wearing long sleeves you're going to wreck the heat dissipation - if they could use the top surface of the strap as a heat sink then at least they could get the surface area.

Using a Marlow TEG harvester is out of the question as they are too big (and work best at much higher temperatures) but I guess one of the micro scale TEGs made by Micropelt could maybe possibly work - last I checked they were still in beta and when I referenced them in my lit review 7 years ago they were just getting going so it's been a long slog.

Even then, as others have said, the harvestable energy from the surface of the skin is so small that it would have to be pretty limited in capability. The best bet would probably be an arsenal of energy harvesters, micro-scale vibration energy harvesters (mems piezo maybe), a magnet in a coil to get walking energy and then also TEG. Could land up being pretty huge.

Either way, so long as this isn't a scam, good luck to them.

</comment><comment><USER17> >"We see ourselves as a thermal energy harvesting company," Anne Ruminski, Matrix's head of engineering told me, not a watch company.

Harvesting humans for energy? I guess the Matrix name is fairly tongue-in- cheek here.

Curious to know how plausible this is considering how little heat we produce. I wonder if there's a catch like "needs weekly charging" on top of the heat based charging or also has a charger from the kinetic movement of our wrists with the heat charging being a gimmick to get attention and VC money.

I'm also concerned this watch will have way too many energy saving compromises to be practical. How often will it pool its bluetooth connection for messages? If it all? The indiegogo page doesn't show any integration with your phone other than fitness stuff, which can be synced infrequently. What about alerts and messages? I don't even see that addressed. Sorry, but its not a smartwatch if it can't integrate with my phone for alerts and messages. Its just a fitness device with a clock then.

</comment><comment><USER18> Pelting devices are pretty expensive and relatively low efficiency. I'm surprised nobody has made a small MEMS oscillator to generate power the same way self-winding mechanical watches work. Perhaps arms smply don't move enough.</comment>


Diesel cars produce more toxic emissions than trucks and buses, EU study says - J-dawg http://www.theverge.com/2017/1/6/14188676/diesel-cars-toxic-emissions-nitrogen-oxides-trucks-buses-europe <comment><USER2> Part of the problem is that basically the closer you run the diesel engine to its optimum mpg-wise, the more NOx it emits.

So, when you are trying very hard to make engines more efficient to get impressive mpg numbers, you also end up generating more NOx (Which you can then get rid of using urea, which I think is the preferred option in trucks and buses - think AdBlue or whatever it is called when used for cars.

<comment><USER3> One problem with AdBlue is that the car makers decided that the car owners were not supposed to refill it, it was considered more like an oil change than a fill-up. So the tank needs to be large enough to cover a full maintenance interval - which either requires quite a large tank or creative solution to limit consumption. And - meh - the decision was made to limit consumption.

<comment><USER2> I think - mind, think - that car makers may be innocent in this particular instance; I am pretty sure I read some time ago (Just as Dieselgate blew up) that regulations required AdBlue to be refilled primarily by workshops - <AUTHOR> as it directly affected the emissions of the vehicle, and as such shouldn't (couldn't?) be entrusted to Joe Q. Public to do.

However, at least around here they sell it at (some) gas stations, and the user manual (2012 Passat 3c) shows how you go about topping it up, so it can't be that much of a concern.

<comment><USER4> Just another step to the complete infantilization of citizens by the government. If you can't pour a liquid into another container, you have no business being outdoors.

<comment><USER5> On the other hand, when strapped for cash, many citizens will stop doing it. You can make it illegal to drive with that tank empty, but that still won't make many citizens do it. The environment is better off this way.

<comment><USER6> Well, running the engine (or not to) with empty AdBlue tank has nothing to do with topping it up yourself.

\- You can let the tank go empty and not turn up to the workshop for the fill up, how does disallowing to top it up yourself prevent that?

\- Many current cars with AdBlue will flash increasingly annoying warnings at you, and although many people drive with check engine lights lit, running out of urea will display you a counter of remaining kilometers and the car will simply refuse to start when empty. Again, nothing to do with whether you push the car to the dealership on foot or fill the tank yourself from the bottle (and actually, there are very foolproof anti-spill bottles, which let the liquid go only when tightly screwed onto the DEF tank).

<comment><USER5> > Well, running the engine (or not to) with empty AdBlue tank has nothing to > do with topping it up yourself.

Yes it does, since it affects the design of the vehicle. Remember that the context of this thread includes:

"So the tank needs to be large enough to cover a full maintenance interval...or creative solution to limit consumption."

</comment></comment></comment></comment></comment></comment></comment><comment><USER7> I'm in Northern Ireland, and while I can't speak for the rest of the UK or Europe, I know the stats put diesel vehicles at almost half in Europe as a whole.

It sounds absurd, but I can _see_ the increase in Diesel soot on the roads and pavements here, and more often than not, it can be smelt from passing traffic.

To be fair, that I've become more aware of it is making me notice it more - but I live now not so far from where I grew up and it's clear how much difference the last 10-15 years have made to the state of the local environment. It's disgusting, and no doubt a massive public health crisis 10-20 years from now in the UK, where we already lead the world in lung disease.

<comment><USER8> It's made worse by the fact that manufacturers don't offer, or offer worse petrol engines in the UK, pushing buyers towards diesel. For the past 10 years, you couldn't buy a petrol Land Rover in the UK, despite the fact that petrol land rovers are assembled in the Sollihul plant. The Latest Discovery 5 finally has a petrol option, but the Discovery Sport is still only offered with a diesel, despite the fact that the rest of the continent enjoys an excellent Si4 Petrol engine in the same vehicle.

It's the same story elsewhere - MB offers probably half of the engines that rest of Europe gets, if there is a petrol option it is hugely underpowered, and diesel is the only way to go.

<comment><USER9> It could be a market perception thing in the UK. "Diesel 4x4s are the best" and petrol versions just don't sell enough to warrant releasing them in the UK.

<comment><USER8> But then it's a self fulfilling prophecy,no? You can't buy a petrol 4x4 = petrol 4x4s don't sell = manufacturers don't release them in UK = you can't buy a petrol 4x4.

</comment></comment></comment></comment><comment><USER10> This could really the death blow for the Diesel engine in cars. Over a decade people have promoted the Diesel as a cleaner, more efficient fuel for cars and car makers spent billions to improve the engines and apparently even more in marketing.

Now, the bubble collapsed.

Also, Germany currently gives Diesel owners a rebate on the fuel tax. That is why a liter of Diesel is around €1.10 and a liter of gas is around €1.30. I wouldn't be surprised if this rebate will be gone soon. (But I wouldn't take bets on when)

<comment><USER11> But isn't the truth a little more complex? In terms of CO2 emissions, those diesels are about twice as efficient (distance traveled on the same volume of fuel). So they are potentially better for the global environment at the same time they are worse for the local one... That said, I am happy to have just switched from an old diesel to a PHEV, but even it can't beat riding my bicycle to work...

<comment><USER10> I think that is a fair point. But as the report mentions, trucks and busses are fine. Because with those it apparently not an issue to add Diesel exhaust fluid to the mix.

But I can't imagine that the usual drivers want the hassle with filling up two tanks.

</comment></comment></comment><comment><USER12> One of the reasons, I am not proud to be a German, since it was/is my government (shame on them all!) that actively prevents real progress in the area of emission reduction of cars.

Reality is, that ADAC or TÜV years ago already warned, that EURO 6 cars may produce even more emissions than EURO 5 cars. So, decades of EU environment politics where just Potemkin villages to please German car producers.

<comment><USER13> > my government (shame on them all!) that actively prevents real progress in > the area of emission reduction of cars

how?

> So, decades of EU environment politics where just Potemkin villages to > please German car producers.

???

<comment><USER12> Because they actively blocked (and still do) any attempts in the EU to release real-life regulations (not measure pollution in artificial environments, but on the roads!) -- for many years now. And still, they hinder that car buyers in Germany get the same compensation as US customers do.

The German news where full of it.

It is not helpful, when the labs are cleaner during car testing, but at the roads the people suffer from the pollution. VW is not the only brand, that optimizes the emissions for artificial environments.

</comment></comment></comment><comment><USER14> Article doesn't mention DPF(Diesel Particulate Filter) removal. Many owners don't wanna pay for new one, so they pay for removal. There are so many cars without it and emissions are completely sick.

<comment><USER15> Same applies to petrol cars, many don't replace the catalytic converter they just remove it. Don't want to get in a argumentation which one is "cleaner" afterwards, both are equally stupid.

<comment><USER16> How long does a DPF last? Replacing a catalytic converter is a rare maintenance item on a car. Most of the time they last the lifetime of the vehicle. In fact the only person I know who had to replace one had it stolen from under his car while he was parked on a city street.

<comment><USER17> It depends on many aspects (car usage, quality, etc.) I recently bought a used diesel car (10 years old, 150k KM), the DPF was almost dead. Needless to say that is wasn't a pleasant surprise... Edit: Also the DPF is not the catalytic converter, these are two different elements.

</comment></comment></comment></comment><comment><USER18> This isn't surprising. Larger engines are almost always more efficient, compare for example a gas boiler in a house vs a CCGT in a powerplant.

But overall diesel has been a complete disaster and will take probably a decade minimum to undo. Complete tunnel vision focus on CO2 emissions at all costs which continues to plague environmental regulation IMO.

<comment> 08-15 > compare for example a gas boiler in a house vs a CCGT in a powerplant

One makes hot water (~100% efficiency based on LHV), the other makes electricity (~50% effciency). What's your point?

</comment></comment><comment><USER19> This happened because environmental policy focused too much on one metric: CO2 emissions. It should've been reduction of all polluting emissions, which would naturally favor hybrids and then plug-in cars as the rules get more strict.

<comment><USER2> In Norway (and probably elsewhere, but I only followed the debate here), the engineer's union, automobile association and just about everyone who knew the first thing about engines said 'NOOO!!!' when our parliament decided that favouring diesels was The Right Thing to do.

However, as CO2 was bad and diesels emitted less overall, diesel it was.

Result? Air quality in towns took a nosedive, and suddenly diesel cars were forbidden to drive in city centres on days with poor air quality. Much annoyance (naturally) ensued - first the public is being told (by diesels suddenly costing thousands of € less) to buy diesels; then they are being told that they cannot drive them.

I luckily live in a very rural area; otherwise I wouldn't have had the conscience to (nor need for) my daily driver - an old diesel Land Cruiser.

</comment></comment><comment><USER20> Here's a good article on how diesel engines became popular in Europe and not in the US

[https://longtailpipe.com/2015/10/02/differences-in-us-and- eu...](https://longtailpipe.com/2015/10/02/differences-in-us-and-eu-emissions- standard-key-cause-of-dieselgate/)

<comment><USER21> Very interesting. I'm often under the impression that the EU has stricter standards than the USA. But in this case not at all, it's even somehow unethical (to me at least) that the laws were made as economic incentives over health.

</comment></comment><comment> 08-15 > Nitrogen oxides cause tens of thousands of early deaths in Europe

Complete bullshit. There isn't a single death certificate in the world that lists "NOx poisoning" as cause of death, unless it was an industrial accident.

These numbers come from assuming that some high dose of NOx will kill you, therefore 1% of that dose kills one in a hundred. So, at least for regulatory purposes to scare people, we can take a tiny dose, multiply it by a huge number of people, and get the number of deaths.

Apparently, this is true for any chemical, such as Paracetamol. 10g of Paracetamol are reasonably likely (about 50%?) to kill you. So if 100 people take 200mg each, one of them is going to die, right? Apparently, "30 million packs" are sold each year in the UK, each containing about 10g, and somebody swallows most of it. So every year, Paracetamol kills about 15 million people in the UK. Or maybe just 5 million, if some Paracetamol is flushed down the toilet. So it takes no more than 13 years, and there nobody left in the UK to be killed by NOx.

But the UK isn't devoid of people. That's because this whole logic is bullshit, and when applied to medicine, everybody knows it. When NOx concentrations of less than a ppm are involved, it suddenly makes sense.

Dear ICCT: If you feel the need to make up bullshit like this, you are tackling a non-problem.

<comment><USER22> Do you have a source on that? I thought that the numbers came from extrapolating from large population studies on the effects of air pollution (e.g. [http://www.nejm.org/doi/full/10.1056/NEJM199312093292401#t=a...](http://www.nejm.org/doi/full/10.1056/NEJM199312093292401#t=article)).

<comment> 08-15 The article itself cites the Guardian, who cites the European Environmental Agency, who cites REVIHAAP, which is only a review. REVIHAAP ([http://www.euro.who.int/__data/assets/pdf_file/0004/193108/R...](http://www.euro.who.int/__data/assets/pdf_file/0004/193108/REVIHAAP- Final-technical-report-final-version.pdf)) mentions a lot of studies that estimate the proportionality factor between mortality and NOx concentration. This is precisely the method I described above: _assume_ proportionality, then estimate the proportionality constant, then multiply by millions of people and get a scary number. Few studies in the REVIHAAP report cite actual concentrations, but when they do they are invariably much higher than the 20µg the EEA applies as lower cutoff.

(The study you linked to doesn't include NOx. REVIHAAP itself has more inapplicable stuff, such as one study that actually looked at proximity to roads, then noted that they can't tease apart the effects of NOx, ozone, soot, etc, then proceeded to make a claim about NOx specifically anyway.)

</comment></comment></comment><comment><USER23> Does this explain why European cities smell the way they do? It makes me feel a bit sick after a while

<comment><USER24> Yeah, even though they might produce less CO2, they do put out a ton of NOx and particulates. They can be mitigated to some extent, but the good systems are expensive and EU regulations on NOx are not as high as in California. And most cars sold in the US are built to CA specs because they are the largest market.

</comment></comment><comment><USER25> Many areas in London breach EU NOx limits hundreds of times each year - [https://www.theguardian.com/environment/2017/jan/06/london-b...](https://www.theguardian.com/environment/2017/jan/06/london- breaches-toxic-air-pollution-limit-for-2017-in-just-five-days)

</comment><comment><USER26> As I've cycled around Cambridge, UK for the last 17 years, I've noticed now diesel cars that seemed OK when new (ie no noticeable soot or smell from the exhaust) become problematic about half way through their life - presumably due to wear or poor maintenance.

Are there any studies of emissions from vehicles in the second half of their useful life? Let's say the average car in the UK will have done about 120,000 miles by the time is it scrapped. I want to know what typical cars are like in the 60 to 120 thousand mile range of their life. I guess this is the dominant source of pollution on UK roads. If so, there'd be a case for more thorough testing of emissions in the MOT.

<comment><USER27> Here in California I find the emissions testing bizarre. Instead of actually measuring the emissions, they just plug a computer into the OBD port and use whatever the car itself reports!

<comment><USER28> Which circles back to where VW Dieselgate was a fucking disaster and a lot of people at a lot of levels of government on multiple continents are just as at fault as VW is.

First rule of computer security: do not trust humans.

First rule of not trusting humans: computers lie when ordered to by computers, and cannot be trusted, and results should be checked as often and as completely as possible.

</comment></comment></comment><comment><USER29> Have a look at cargo ship emissions and then think.

<comment><USER2> Which is why lots of very smart people spend lots of money figuring out better ways to power commercial shipping; gas turbines for instance - and even sails may make a comeback.

The problem with cars (in particular diesel ones) is that their pollution causes problems locally, too. That is less of an immediate concern if you're plying the Yokohama-US Pacific coast route.

<comment><USER29> I don't negate that this is the case but bunker and "gas turbines" seems a bit on the opposite for fossile energy regarding the environment.

And this fuel does not seem to loose attraction due to its price. "Worldwide bunker use in 2001 was estimated at 278 million tons, of which around 212 million tons were residual fuels. ƒ Between 2001 and 2020, total consumption grows at an average annual rate of 3.1% [...]" [1]

[1] [https://nepis.epa.gov/Exe/ZyPDF.cgi/P1001TZU.PDF?Dockey=P100...](https://nepis.epa.gov/Exe/ZyPDF.cgi/P1001TZU.PDF?Dockey=P1001TZU.PDF)

<comment><USER2> I (partially) agree; however, we have a saying in Norway that "The best is the worst enemy of the good."

In a perfect world, shipping would be emissions-free; however, it is not; the vast majority of the world's commercial shipping runs off heavy fuel oil.

Getting it to pollute less in the short term is IMHO better than holding out, waiting for zero emissions somewhere down the line.

<comment><USER30> Off-topic remark: [https://en.m.wikipedia.org/wiki/Perfect_is_the_enemy_of_good](https://en.m.wikipedia.org/wiki/Perfect_is_the_enemy_of_good)

<comment><USER2> Aah, should've expected someone had thought of that one before we did! :)

</comment></comment></comment></comment></comment></comment><comment><USER31> But, they have all those blue and green emblems on the back. :/

When I see these cars getting floored and I see the dark grey/black smoke coming out I often wonder, this must be super healthy for all of us.

<comment><USER32> The smoke/soot you can see is particulate matter, not NOx. That's only a problem with older diesels or if the owner removes the filter, modern diesels with intact DPFs emit way less particulate matter than an average gasoline car.

The health problem with NOx (as I understand it) is that it will react with oxygen producing ozone and therefore smog, if there is enough in the air.

<comment><USER33> Even new diesel trucks from Japan do this in places like the Caribbean. Maybe the standards are lower but I haven't seen a similar problem with new gas cars.

<comment><USER32> The US has _way_ stricter new car auto emission standards than pretty much anywhere else, and I think lots of countries don't require DPFs at all, good point.

If the US standards get much stricter there will have to be PM filters on gasoline cars too.

</comment></comment></comment></comment><comment><USER34> I think since they are used more, and burn more fuel generally more total emissions come from heavy commercial vehicles, so at least the more rigorous testing was introduced in the right sector first.

This is also part of the reasoning one of the Tesla founders used when they moved on to creating hybrid drivetrains for trucks with Wrightspeed.</comment>


Silicon Valley Assholes - <AUTHOR> https://medium.com/pop-of-culture/6566abbf7101

<comment><USER2> I posit that it isn't class tension, rather cultural tension. I moved to San Francisco in 2000 (during the dot com boom and subsequent bust) when the first wave of anti-tech worker sentiment start to brew.

Since then it's completely normal and reasonable to tote around a Macbook Pro with you around town; people who understand and use tech aren't the problem.

JWZ alluded to this cultural tension in his 1996 "San Jose is hell on earth" rant.

What people don't want is dilution of San Francisco culture; I personally love how there are so many neat, quirky people in San Francisco. In my time here, I've run into and had interesting conversations with artists, musicians, teachers, coffee roasters, hipsters, students, bicyclists, ... yes, even homeless people. But I cringe when I'm sitting down at Tartine and overhear some tech worker talking about Quartz Compositing, unrolling a loop and adding SIMD, or Javascript -- I'm a tech guy, but come on, that's really boring to discuss in public. I look around and think, "no, wait, we're not all that boring and narrow!"

It's one thing to have an employer in Silicon Valley, but it's another thing when your employer drives a bunch of shuttle busses to San Francisco that wait at and hog up Muni bus stops. Every time I ride the Muni and a Google shuttle is blocking the stop, forcing Muni riders to get off the bus further down the street (sometimes in unsafe conditions), I can't help but understand why some people want those Google/Apple/Facebook people to "give back to their community" and view them as outsiders, as if they were rude tourists. As for my (tech) employer, they give us nearly unlimited Clipper eCash to use on any and all transit systems -- pumping money into the transit system to make improvements instead of privatizing transit as we know it.

No, you don't need to give lots of money to the homeless or get involved in local politics, but if you're going to live in San Francisco, it helps to have skin in the game, instead of being a permanent tourist. For example, I ride my bicycle around San Francisco as my primary means of transportation; I donate to the San Francisco Bicycle Coalition because their interests align with mine. I volunteer time at GLIDE, because it's important to me to do something like that.

If you're going to live in San Francisco, then try to enjoy living there for what it is. You could always move to San Jose if you want the big city + tech worker thing, or Mountain View if you just want the tech thing.

If you dislike San Francisco but choose to live there anyways, consider this quote from Lao Tzu: "Fail to honor people, they fail to honor you."</comment>


A New Set of Wants - <AUTHOR> http://www.medialens.org/index.php/current-alert-sp-298539227/cogitations-archive/56-mind-training-part-2.html

<comment><USER2> "The point, however, is that as a consequence of noticing when our mind has wandered and then replacing our attention on the breath 10,00 or 100,000 times, we are subtly strengthening our awareness of what is happening in our mind and, so, our ability to take control of where we focus our concentration."

So true. But mindfulness doesn't need to be obtained/focused solely by focusing on your breath. I think you can gain a lot of mindfulness strength by training yourself how to (actually) focus on your work: [http://focusr.co](http://focusr.co)</comment>