Making good programmers feel like bad programmers - <AUTHOR> http://clipperhouse.com/blog/post/Making-good-programmers-feel-like-bad-programmers.aspx

<comment><USER2> The problem starts before the leaky abstraction. It is putting a bad or mal- fitting model over a problem to make it easier for non-experts to work with the tool.

This is a commonly-made mistake and comes in the form of using a GUI for large documentation project that is really batch underneath, putting a nice GUI on a commercial application that is high-throughput when done on green screen or equivalent, using a big hairy IDE when vi or emacs will be higher throughput, using a mouse when the keyboard is demonstrably faster.

Seems like we need a good treatise on how adding features or layers weakens rather than strengthens a tool. This article shows one of the perils.

<comment><USER3> Second that. I'm absolutely amazed at how in-productive I am in a java/eclipse environment vs straight C, vi and make. It's like I'm continuously scanning either the documentation or some obscure error.

Of course I pretty much grew up in C but the difference feels larger than can be explained by that fact.

<comment><USER4> Perhaps you are writing different kinds of code in each.

For example, when I'm writing C, I'm usually just using the standard library and maybe a couple of OS routines. It's especially the case because I'm usually writing C in the context of a compiler, which is as close to a pure function of input to output as most programming gets.

On the other hand, when I'm writing in a higher level language, I'm tackling bigger problems and using far, far more third-party code. That's where the occasional documentation lookups and odd errors come in.

<comment><USER3> You are absolutely right, when I'm writing in C I write dataprocessing code, usually elaborate filters and pipelines of filters.

The java stuff is web applications.

</comment></comment></comment></comment><comment><USER5> This pretty much sums up why I'm sometimes hesitant to use frameworks: should my problem evolve past the boundaries of the framework it can become more of a pain to use the framework than the raw constructs.

When it's no big deal to stick to the framework's boundaries, or the framework interoperates well, clearly and easily with custom lower-level code, then it seems wise to use such a framework.

The latter--interoperability with lower level code--does not seem to be true for ASP.NET based on my brief experience.

<comment><USER6> The real problem with ASP.NET is that the abstraction it provides is completely divorced from the way the web actually works. It tries to provide a stateful way to program, and it is completely driven by events. Sure it exposes the response and request, but trying to use those in anything but the most trivial ways is a complete mess

It was great when I was just starting out as a web programmer and I didn't understand how the web worked. Now that I do get it, ASP.NET Webforms is a hassle at best and maddening at worst.

<comment><USER7> You should check out ASP.NET MVC. No postback, viewstate, and other junk, just request and response.

</comment></comment></comment><comment><USER8> Around 2 years ago I started a job as an asp.net developer and this was exactly how I felt. It felt like everything I wanted to do and every problem I wanted to solve had a solution that just didn't quite fit.

It was the whole square peg, round hole scenario. I would need to do something that I knew I could easily do in another language and the asp.NET solution was almost the solution I needed except to get it to work right I had to spend as much time modifying and extending it as I would have spent on a much more elegant solution in another language.

</comment><comment><USER9> Abstraction and convenience layers still need to be learned to be used properly. If you're used to doing things yourself and you shift to using helper tools, there is going to be a learning curve. The idea is that it pays off in the long run so it's worth learning.

</comment><comment><USER10> Remember, the solution is _always_ to add another layer of abstraction!

<comment><USER11> "You can solve any problem by adding another level of abstraction, except having too many levels of abstraction"</comment></comment>


Decoupling action and neurological reward -- read the alt-text - <AUTHOR> http://m.xkcd.com/862/

<comment><AUTHOR> Has anyone tried this?

I could set up a proxy that provided a delay and fiddle with my host file, but I wonder if there is a better way to experiment.

<comment><USER2> [http://www.reddit.com/r/programming/comments/fo276/i_wrote_a...](http://www.reddit.com/r/programming/comments/fo276/i_wrote_a_ruby_script_modeled_after_todays_xkcd/)</comment></comment>


What is the best metric for developer productivity? - <AUTHOR> How do you measure your own and your team's productivity. Points, cycle time, churn rate, something else? If you could see only one data point or take one action each day to improve your own or your team's productivity what would it be? <comment><USER2> Personally I think this is a fantastic question and one I'm very interested in seeing what more experienced developers and managers have to say.

The more I manage people (especially developers) the more I'm drawn to the adage of 'a metric that becomes a target ceases to be a useful metric' but at the same time many companies put great stock in trying to develop measurable KPIs - something that I've greatly struggled with through several roles as a development manager.

If I was going to land on anything currently it would probably be something like 'Features released within a iteratively improved estimated timeframe'. In other words a metric that focused on an improvement between now the and last time the measurement was made but not towards a specific target. Also a metric that made people realise that the focus is more around them working as a team and even across multiple teams to achieve a goal.

</comment><comment><USER3> I wouldn't measure one thing. I'd measure a whole heap of different metrics, do some sort of (possibly nonlinear) mapping so bigger numbers indicate (intuitively) better performance, then take deciles. I'd measure performance by how high each developers' worst metric is. I.e. look for consistency across all metrics and ignore high performance in a small number of areas (to make it harder to game). Also, it might be worth training a model to predict that performance metric from other unstructured data -- again to make it harder to explicitly game the system.</comment>


"DIY U": The End of University Prestige - <AUTHOR> http://www.salon.com/print.html?URL=/books/feature/2010/03/28/anya_kamenetz_diyu_interview <comment><USER2> The problem with this approach is the belief that the university is a place to train undergraduates. Having worked as a staff member, and then jumped to graduate studies, I realized that actually, the modern university is a place of research. The undergraduate bit is simply to pay the bills. The university system's mission to disseminate information to the populace is almost entirely from the research, not the undergraduate teaching. It's not surprising they are inflexible.

The reason the UK has more entry methods is because there are far fewer universities than in the US. Having moved to California from the UK when I was 24, CA has far more "universities" that specialize in teaching. The State school and Community College system doesn't exist in the UK... that's why there are all the internships.

Finally, the author seems to assign all value in a university from what you learned in lectures. That's a flawed premise: the lectures are there to spur you on to learn outside of contact time. Developing all those skills, meeting all those like minded people, having an ecosystem where you can work on the student newspaper to get more skills... those are things that distributed learning doesn't offer.

University != undergraduate lectures.

<comment><USER3> _University != undergraduate lectures._

And that's exactly the problem. Why pay to attend an institution that does not care about your studies?

There are a few profs who really care about the students. The rest just watch for the select few that can succeed in spite of the system, and pick them for grad school.

<comment><USER4> >Why pay to attend an institution that does not care about your studies?

Because you're paying for environment, education, peer group, opportunity, and credibility...not hugs.

</comment></comment></comment><comment><USER5> Prestigious universities were never about quality of education: if you're smart enough to get in, you're smart enough to teach yourself anything.

Rather, they are about the peers you go to school with. You learn and grow from the type of people you surround yourself with, and at elite universities you surround yourself with extraordinarily smart people.

<comment><USER6> This has _never_ been true of MIT (although I'll double check that WRT to the very beginning, which I'm studying now), and to this day _every_ course is taught by a professor (I know of one exception to this rule, an EECS grad student who walked on water and who everyone in the department thought was the very best person to teach one particular course).

MIT is deadly serious about undergraduate education, to the point where if a professor violates certain rules (e.g. no homework of X sort N days before final exams), a committee charged with this sort of thing will take the course away from the professor.

I was also once an employee who's office happened to be in the complex that included the EECS undergraduate HQ. One term a very good professor inexplicably did a _horrible_ job of teaching 6.002 (or maybe 3, but I think it was 2). I read every one of the student course evaluations and with one special case exception they were uniformly negative with plenty of specificity. Then, due to the open office nature of that complex, I got to listen to the department head force the professor to read every single one of them, and then be told he'd _never, ever_ be allowed to teach that course again (which he took very hard, since this is an area the professor really cares about).

In all my personal experiences of taking courses, the professors were seriously dedicated to teaching, although obviously their ability to teach varied. But they _tried_ , and some also would devote a little time to telling us about their research, how it excited them and they tried to give us a little facility in what it was all about. Generally the latter failed, but they seldom failed to get across how something as dry as say physical chemistry might be very interesting.

<comment><USER5> They take education seriously sure, but a school that is 10x more competitive and 10x as expensive as a state school has at most 1.5x better teaching. It doesn't scale. The real asset is the student body. The department is good because it's competitive more so than it's competitive because it's good.

<comment><USER6> Please define "competitive".

E.g. MIT does not grade on the curve; that would be insane, instead they grade on mastery of material. I've e.g. _never_ heard of someone sabotaging another work to improve their own grade, we're all in it together and tend to help each other out.

As for costs, about 5 minutes with Google suggests a 5x difference compared to average state school tuition costs. Based on my experience, the difference in teaching quality is a _LOT_ more than 1.5x, but I wouldn't be able to pin it down.

I'd say the real asset is not the student body per se, but the whole community and the ingrained meritocratic attitudes. It's assumed by default that _everyone_ at MIT is serious about what they're doing (which of course is not 100% academics, not that we've ever managed to top CalTech's Rose Bowl hack :-), and there's a tremendous amount of respect all around.

It's said that undergraduates are treated like grad students (and that includes serious cutting edge research (e.g. through UROP; in both my experiences there, the problems had not been solved, period)) and grad students like junior facility, and on up for faculity (except, I will add, _everyone_ in the Math Department is treated like shit, but it's not entirely horrible (my first job was maintaining a computer system in that department)).

And in the end, if you're trying to get into a good grad school, which is the better foundation? If you care about how your resume impresses people and opens doors, which school would you rather have on it (note that in lower quality tech areas MIT envy doesn't make this entirely a good thing, but then again it acts as a filtering function).

<comment><USER5> competitive=admissions acceptance rate\exclusivity. I completely agree that schools like Stanford (7.6% acceptance rate) and MIT (9.7% acceptance rate) are an amazing foundation.

My argument is: As competitiveness\exclusivity of a university increases, the quality of the student body increases at a much faster rate than the quality of instruction.

I once took a single semester at a local state school in the middle of my college career solely to get cheap credits for a new university\department I was transferring to. The professors were still very bright, had PhDs, and repeatedly encouraged students to come into their office (the vast majority didn't). They were however ALL foreign, from India, eastern europe, or china. In addition, the one programming class I took was taught by someone who had spent more time in industry than research. Also, they had to teach at a MUCH slower rate than they were capable of to cater to the student body. The limiting factor was the students.

<comment><USER6> Yes, I see your point, and it's a significant and important one (but I'm not in position to comment well on it, knowing only MIT and Harvard students, the latter through various friends of mine from Up Chuck River :-).

It's significant based on what I've heard of India's famed IITs. They don't have top of the line equipment, their professors aren't always the best; it's their student bodies that make them more than anything else. When you get the very best (in their areas) out of 1 billion people....

As for MIT numbers, you might find these interesting/useful: current yearly applications are something like 13,000, a bit more than 3,000 are judged as being able to do the work (that's the number one thing that's important to MIT; while mistakes are inevitable, it accepts _no one_ who they don't fully believe can make it).

10% of those are "obvious admits" and the admissions staff, augmented by anyone on the staff with a clue who volunteers (especially to make absolutely sure _every_ application gets at least two readings) then agonize over who amongst the rest to offer a slot to. (It's hard and not really fun; I have a very good friend who does this on a time available basis and I helped her a bit one year when I was on the staff.)

MIT shoots for a yield of around 1080 the last time I checked (that figure is old, but is tightly constrained by available student housing, all freshman must spend their first year in it; one year the the admissions office made a big enough mistake they had to turn a graduate dorm's basement into makeshift housing, which perhaps not surprisingly worked out very well (they bonded into a tight and self-supporting group)).

The self-selection in applications is _tremendous_. Nobody attends MIT who doesn't think they wanted to (that can of course change once they arrive ^_^, but I didn't see much of that in the '80s).

Thanks for the intelligent discussion and observations.

</comment></comment></comment></comment></comment></comment><comment><USER7> Meh, there was a lot of vague stuff about improvement and empowering the learner but very little in the way of implementation. Currently the accreditation bodies are the biggest hurdles to overcome because anyone that wants to do anything innovative in education either has to be attached to a big name university or has to face the problem of overcoming a lot of red tape. Most accreditation bodies serve the interests of big name universities so anything that deviates from that model is met with suspicion and disdain.

Speaking from personal experience I wouldn't have missed anything if I had skipped the entire high school and college experience because I learned absolutely nothing in classes. All of my current knowledge was gained by either working closely with a mentor or spending time at the library.

<comment><USER8> _Currently the accreditation bodies are the biggest hurdles to overcome because anyone that wants to do anything innovative in education either has to be attached to a big name university or has to face the problem of overcoming a lot of red tape. Most accreditation bodies serve the interests of big name universities so anything that deviates from that model is met with suspicion and disdain._

I think it will be market-driven.

As the value of credentials relative to demonstrable skill continues to decrease, people will reconsider the proposition of taking on huge debt for a college degree. They'll look for alternative ways to acquire skills, and universities will have to compete by lowering tuition rates and rethinking education. Otherwise they won't attract enough tuition-paying students to cover operation costs. When it comes to the bottom line _then_ administrations will mobilize.

I predict that some universities will make interesting changes (eventually) and many will fail. Just hoping none are "too big to fail".

<comment><USER7> This has been happening for at least the past 10 years and there has been very little change. There is a lot of pressure and monetary incentive in keeping things the way they are. I'll give you an example. Many lower division math classes are offered by the math department because they are service classes with hefty per unit price tags and ridiculous book prices, i.e. other departments use those classes as a screening procedure and the math department gets a whole bunch of money to invite speakers and support incoming graduate students and the book store gets proceeds from old book resale.

So as long as there is at least one department out there that is not feeling the crunch the math department will not do anything differently and there is always at least one technical department that does well no matter how good or bad the economy is. So from the other department's perspective it is a good idea to offload as much of the screening of students to the math department as possible since who really wants to spend time with undergrads when there are multimillion dollar grant proposals to submit to bring in money. From the math department's perspective it is a good idea to offer as many variations of the same course adapted to different departments as possible and from the book store's perspective it is a good idea to keep reselling old books at high prices. You tell me which one is going to innovate and get the others to go along with them. Each will cling to their old ways for as long as possible because honestly there is no real competition. The only way to get a piece of paper with B.S. and your name on it is to go to a big name accredited university.

Long reply because I've been thinking about this problem for a long time now and I don't see any real way to force research oriented universities to innovate. There is no real incentive for innovation.

<comment><USER8> _The only way to get a piece of paper with B.S. and your name on it is to go to a big name accredited university._

But having the piece of paper is starting to matter less [1]. Most people want a degree so they can get a better job, but who would you rather hire as a developer: someone who spent 4 years getting decent grades and a CS degree, or someone who spent 4 years contributing to open source projects and teaching themselves to hack? Of course some employers would choose the former, but a smart one would at least strongly consider the latter.

What does this mean for families? Many will undoubtedly continue supporting the institutions, but others may question the merit of spending years saving for and paying off debt from college when there are alternatives available. It's easy to imagine cheaper ways to work with mentors and spend time at the library, after all. :)

[1] Trends would suggest that the paper actually matters more now than ever, due to degree inflation, but I think this will prove itself to be a bubble.

<comment><USER9> According to Spolsky, he'd take the CS degree. Since he is an internet celebrity, people will use him as a credible source to justify their hiring reasons. Also, the HR filters don't really care what open source you've done in your spare time. They won't have much knowledge on it. They will understand what a Harvard, MIT, Stanford, Yale graduate can bring to the table. But your contribution to Apache won't mean much to the filterer.

Now, having personal contact and a network throws all of this out the window. I don't have a CS degree, I've never gotten a job offer without someone having personally reviewed my application. A friend in HR says they use software that looks for competitors (aka work experience), degrees, languages in that order.

<comment><USER8> _They will understand what a Harvard, MIT, Stanford, Yale graduate can bring to the table._

How about people attending less prestigious schools?

 _Now, having personal contact and a network throws all of this out the window._

Exactly, and this is part of what makes open source exciting. Want an internship at Google? Becoming a key contributor to Chromium OS is arguably a better strategy than going back to school, because if you're good you can get a Google employee to notice you.

<comment><USER9> >How about people attending less prestigious schools?

Nothing wrong with less prestigious schools, but most are specialized in a few focused areas. My own school is not a prestigious school, but it is in engineering and biomed.

</comment></comment></comment></comment></comment></comment></comment><comment><USER10> I find the whole trend of online studying quite disturbing. From what I've seen, it defines studying as sitting in awe and trying to soak up the knowledge flowing from professors, and strives to replace it with possibly more efficient channels and call it the next best thing. All the while completely ignoring the second, in my opinion equally important, part of studying - peer to peer socialization.

For me, the people I got to know during studies, and cemented the relationship during various activities not directly related to my field of studies, have proved to be of more value than the lectures attended. Aside from few basic courses that lay the groundwork, my CS studies have been repeated exercise in rapidly getting to know a field enough not to appear incompetent and pass the tests. Granted, this has helped me to the point where I can quickly find solid ground to stand on when thrown in a new technological field, but still, in the last year of my studies, I am working with technologies that have been at best mentioned in couple slides in somewhat related lectures, following methodology that has had been only passingly referenced. The field moves so fast, that by the time someone has developed a _good_ course material on something, it's already yesterdays news. Technologies come and go, but the dude you that woke you the next day after a wild party because a test would be starting in half hour, he will last. And you can't replace that experience with Facebook or Second Life.

<comment><USER8> _I find the whole trend of online studying quite disturbing. From what I've seen, it defines studying as sitting in awe and trying to soak up the knowledge flowing from professors, and strives to replace it with possibly more efficient channels and call it the next best thing. All the while completely ignoring the second, in my opinion equally important, part of studying - peer to peer socialization._

It's just an immature paradigm still. Obviously the web has proven itself to be an outstanding medium for peer-to-peer socialization, and it's only a matter of time before online education taps into this.

</comment></comment><comment><USER11> I haven't seen any evidence that Big Name universities are going to lose their prestige any time soon (a point which is actually not addressed much in the article). When I tell people what Top-Ranked college I went to, the immediate response 4 times out of 5 is something like, "wow, you must be really smart!"

However, I think if the average "intelligence" (however you want to define that) is higher than the population at large, it's more that the lower ~30-50% of the intelligence spectrum is severely underrepresented, and the upper 1% is maybe twice as common as you'd expect. There's still plenty of people with normal talents.

All of which is to say that the prestige of my undergraduate education far outweighs what it might actually be worth. While there might be a significant cultural shift, I frankly think that the cultural bias is too ingrained to change radically any time soon. What I think is likely to happen is that self- designed courses of study are more likely to become perfectly acceptable alternatives, rather than something stigmatized as weird.

</comment><comment><USER12> I wonder. It would be interesting to see the undergraduate degrees of all the Salon staff. I</comment>


New Study Details Toxic Particles Spewed by 3D Printers - <AUTHOR> https://gizmodo.com/new-study-details-all-the-toxic-shit-spewed-out-by-3d-p-1830379464 <comment><USER2> Anyone with a working nose cannot be really surprised about that, especially w.r.t. ABS printing. There's a reason why things that burn/melt things usually have an exhaust of some kind. I'm sure those will become mandatory at some time, and rightfully so. Just like thermal runaway protection should be mandatory, and yet many cheap 3D printers don't have it either. That should actually worry people more than nano particles. I'm still amazed how many people let their printers run while no one is at home (yes, there's OctoPrint+Webcam, but last I checked that couldn't put out a fire...).

<comment><USER3> > I'm still amazed how many people let their printers run while no one is at > home

When it takes 12-24 hours (or perhaps more) to complete a larger print, are you really going to sit around and watch the thing? No, you're going to go about your life until its finished. That means sleeping, going to work, etc.

<comment><USER4> I have done 3-day long prints and have seen reports of 21+ days for a single print.

This all from hobbyists who have full-time jobs. It would be impossible to sit next to the printer for the entire print time for any big/complex enough print.

<comment><USER5> The argument is not about it being practically possible, but whether you should.

Though I also disagree with that.

</comment></comment></comment></comment><comment><USER6> Personally i never leave my printers "unattended", as in i'm at home, but i don't watch them constantly when they're printing. They're in a room that is normally closed when they're running, and is properly ventilated to the outside after. ABS is printed in the garage.

I made a "better than nothing" auto off switch using an Arduino, a 230V relay, a couple of MQ2 smoke detectors, and a couple of DS18B20 digital thermometers.

The MQ-2 is mounted about 50cm above my printers frame, one for each printer, connected to an arduino which has a relay controlling power to the printers. If smoke is detected, or the temperature rises above 45C, it cuts the power to all printers. The arduino defaults to off, requiring manual intervention to turn it on again via a push button. If the arduino loses power, so does the printers.

It probably won't prevent the house from burning down, but in case of an electrical fire it should shut that down pretty good. The problem is the filament itself. It burns like a candle, so if the flames ever make it to the filament, it should have no problems continuing to the spool, setting the house ablaze.

<comment><USER7>
        > The problem is the filament itself. It burns like a candle...

I wonder if this can be addressed by keeping a slight positive pressure of nitrogen or CO2 in the enclosure of the 3D printer?

<comment><USER8> Filling your room with CO2 by accident won't be great either. That is, proper ventilation would be needed anyway.

<comment><USER9> Could do a really low volume flow of nitrogen or argon at the extruder like in welding. You'd still want some ventilation but you'd just need a tank, regulator, and tubing instead of a sealed enclosure and you'd probably use less gas. Just enough to prevent anything at the tip from burning.

<comment><USER8> Yes, ventilation here is more like a fan in a room window than a sealed box and tubes.

</comment></comment></comment></comment></comment><comment><USER10> As someone who has a 3d printer running about a quarter of the time less than 10 feet away from me hearing that it could be bad for me is alarming that it could be harming me. (Other than the lost sleep because its loud) When though of as a risk benefit analysis though I come to the strong conclusion that I will use my printer no matter what because it is the compiler to my hobby: no printer, much harder time making stuff.

I don't need to iterate on the greatness of them here but they have the potential to radically help teach people how to make stuff which drastically helps in industry.

My main concern with these articles is that there is no relative risk factor presented against. I have no idea if these particulates are something it would be worthy to invest in an enclosure or are there low levels which are permittable.

I know that I personally am much more likely to have health complications from almost anything else but to someone else reading the above article they may draw the conclusion that 3d could be dangerous and should be restricted. If a person shows up to a school board meeting throwing a fit that they are running 3d printers with children in the same room then it looks bad on the printers, possibly having them removed and to generalize I think that that is the last thing anyone wants.

Ninja edit: formating

<comment><USER11> You could of course try for some adequate ventilation and an enclosure instead of just ignoring the issue.

<comment><USER12> This. It's not a big deal. Soldering also produces harmful fumes and as long as you ventilate properly it's not a big deal.

Just do an image search for "solder ventilation" for ideas on how to do it.

Regardless of this I kinda do understand the motivation to ignore the issue. People are afraid that there will be a panic and it's going to be banned.

<comment><USER13> And some people (including myself) actually enjoy the smell of molten rosin flux.

<comment><USER14> And some people enjoy tobacco. That doesn't mean it's smart to continue breathing it in.

</comment></comment></comment></comment></comment><comment><USER15> Some figures about the UFP emitted by FDM:

[https://box3d.eu/3d-printing-safety-pollution- health/](https://box3d.eu/3d-printing-safety-pollution-health/)

From this one data point, it seems that ABS is the big emitter.

<comment><USER16> Here is another one [1] taken from [2]

Though that is just one graph out of many. With modern PLA getting better and better, it's rare people use ABS. Makes me wonder how harmful PLA is.

I want to add an HEPA filter anyway.

[1] [https://www.tandfonline.com/na101/home/literatum/publisher/t...](https://www.tandfonline.com/na101/home/literatum/publisher/tandf/journals/content/uast20/2017/uast20.v051.i11/02786826.2017.1342029/20180430/images/large/uast_a_1342029_f0006_oc.jpeg) [2] [https://www.tandfonline.com/doi/full/10.1080/02786826.2017.1...](https://www.tandfonline.com/doi/full/10.1080/02786826.2017.1342029)

<comment><USER17> PLAs lower melting point is the issue. I only print PLA, mainly because it's less toxic, but I dare not print a part that might end up in a hot car, near a heating source or outside.

<comment><USER18> I am shocked by how many people use 3d printed parts in the kitchen, printed PLA is not a food safe matieral.

And if you print a toy for your kids it's gonna end up in their mouth at some point...

<comment><USER19> See here [1]. No FDM printed item is going to be food safe because the layered properties allow the accumulation of bacteria, but PLA is generally non-toxic and will only leach a few "safe in small quantities" chemicals into things it comes in contact with.

[1] [http://www.sciencedirect.com/science/article/pii/02786915940...](http://www.sciencedirect.com/science/article/pii/027869159400145E)

<comment><USER20> Could they mean that the material is suitable per 21CFR, but as you state, it would not meet the cleaning requirements. Benign material that could be single use, but a user should not be expected to be able to maintain a clean surface?

<comment><USER19> I think that's it. Ok for single use or for things that will only come in contact with food that will be cooked (like cookie cutters). Not ok for plates, cups, spatulas, etc. unless you seal them post-print with a food safe coating. I've seen people print both categories of things, though...

As for toys, I don't see a big problem. Even if you eat PLA it won't really do much harm. It's safer than the ABS most toys are made from.

</comment></comment></comment></comment></comment></comment></comment><comment><USER21> This is hardly surprising though, and it was inevitable that studies started to emerge.

</comment><comment><USER20> I wrote a blog post about one of the earlier studies in 2013 [see below].

HEPA filters can still be effective - the study doesn't talk about the charge of the UFPs - and the 0.3 micron DoP particles used in HEPA testing are designed to be uncharged. It is common designing filter media to use charged media to attract small particles.

If you were running a 3D printer and concerned about this risk, I would suggest: 1/ Encapsulate the unit. 2/ Wear a mask when the enclosure is open. 3/ Ensure a steady flow of process air when running to prevent accumulation. You could also run at a negative pressure to keep USPs in the enclosure. 4/ Have a filter bank on the air outlet that you change out regularly. Pair a HEPA element with a highly charged media.

Link to 2013 blog post: [https://fredlybrand.com/2013/10/19/filtration-in-the- popular...](https://fredlybrand.com/2013/10/19/filtration-in-the-popular- media-ultrafine-particles-and-3d-printing/)

</comment><comment><USER22> Is anyone honestly surprised that melting plastic produces toxic particulates/fumes? It should go without saying that one would want these machines enclosed in a ventilated space separated from people.

<comment><USER23> The most common filament used (PLA) is labeled as non toxic and is made of mostly corn. So yes it would be surprising if that was found to be toxic.

<comment><USER11> You know these labels on cigarettes that state the smoke contains at least 253 toxic chemicals? The smoke from other plants of course contains at least about 200 of the same chemicals.

<comment><USER24> People think the formaldehyde and all these other chemicals with spooky names were added by the bad cigarette companies..but not so!! Whenever any hydrocarbon is burned, a characteristic distribution of alkanes, alkenes, and alkynes is formed -- with the nastiest and most "radical" chemicals (like the alkynes), appearing with the lowest frequency.

That's why smoking has almost no risk unless repeated. With enough exposure, those minimal alkynes add up. And they destroy DNA and wreak general havok due to their bond energy.

I know I just reiterated your point. Thank you for making the point - smoke is what is a probabilistic distribution of energetic hydrocarbons -- not the plant!!

</comment></comment></comment></comment><comment><USER25> Once I got my homemade printer working, the first thing I did was build a 100% air sealed enclosure. Melted ABS stinks.

<comment><USER26> I'd say "stinks" is a bit of an overstatement, unless you have a very sensitive nose.

I've only tried printing with ABS a couple of times, but to me it smells almost exactly like an old photocopier... kind of nostalgic.

<comment><USER27> All the FDM printers I've been around when they print with ABS end up making my eyes water and give me a headache if I stay near them for more than a minute or two. Possibly the types of ABS used matters for this but I cannot stand near an ABS printer without really noticing it affect me.

PLA has a definite smell but doesn't seem to affect me physically.

</comment></comment></comment><comment><USER8> So many man-designed processes produce nano-particles. What _natural_ processes produce them, too? I expect many would. How does nature cope with this?

<comment><USER28> Soil erosion.

A dry atmosphere is full of nano-particles (and yes they are harmful). But natural particles tend to be larger and more benign than most human made ones.

Nature copes with them the same way it copes with ever other long term problem: it affects individuals, and individuals are all dead at the long term anyway.

<comment><USER20> Many allergies are due to microparticles - which have individual features that are in the nano realm.

</comment></comment></comment><comment><USER29> Isn't something like, a HEPA available in most home air filters, enough to remove most particles?

<comment><USER30> Should be better than nothing in any case. A guideline mentioning that there should be extraction and proper ventilation near 3D printers - just like in laser printers, soldering stations, etc - would probably be wise.

<comment><USER31> Yes, let's not forget what laser printers used to spew out. Not sure if that got any better with time?

</comment></comment></comment><comment><USER32> How safe are the printed objects?

<comment><USER17> As safe as any other plastic object made from the same material.

<comment><USER33> Well for example - printed objects are generally not foodsafe. They are fine to touch and whatnot, but they have too many little niches for food that I would not 3d print myself a spoon..

</comment></comment></comment><comment><USER22> In case this feels like dejavu for the graybeards

[https://en.wikipedia.org/wiki/Laser_Printer#Safety_hazards,_...](https://en.wikipedia.org/wiki/Laser_Printer#Safety_hazards,_health_risks,_and_precautions)

</comment><comment><USER34> TL;DR: "We were able to measure that there are _some_ toxic particles emanated, but failed to produce any meaningful results about quantity of said particles, or potential danger to consumers, in any way."

To me that says, the quantities they did measure were too low to publish for this alarmist article.

From the article: >all tests indicated at least some level of toxic response (though the toxic response varied by filament type). >The sheer variety of the toxic substances produced by these printers was alarming. No less than 200 different volatile organic compounds (VOCs)

uh huh. The "sheer variety is alarming" line was about where my eyes started to roll, finishing their 135° journey after confirming there are no meaningful stats in this article.

<comment><USER35> The corrolary of an alarmist report is a dismissive viewpoint. Theres evidence here that FDM printers emit toxic fumes. If you want to believe it's really not so bad, fine, close your made up mind. If there is a chance that filament fumes are harmful, people need to be made aware. They're setting these things up in grade school STEM/STEAM programs; there is potential for real harm here and not pursuing more research is irresponsible.

<comment><USER36> Agreed 100%. Them blowing this off because they don't feel like it has enough data or teeth I think is a big mistake. There's a distinct possibility that there will be a 3d printer in every classroom/office/home at some point in the future (just like regular printers eventually graduated to be everywhere). Discussing that there might actually be some toxic issues with these printers now can head off a potential future where tons of people including children are getting sick due to something that we didn't test enough or look at with enough skepticism before it gained mass acceptance. It's win/win really... they become safer if they are found to be emiting toxic fumes and people can feel more comfortable having a safer 3d printer around them. I just don't see the downside...

Much like how there are wall paints that have low or no VOCs I imagine we'd want these printers to head in the same direction. Why would anyone say... oh yeah these paints have a variety of VOCs they emit. Sounds alarmist and I don't see enough evidence so we shouldn't explore further and come up with ones that don't potentially harm people.

<comment><USER37> I'm worried it will impact the cost of filament and printers. Unless there is a cheap way to test and certify filaments. Volumes are still quite low. Regulation risk concentrating filament production into monopolies. Then it will be hard to trust that those certification anyway.

<comment><USER36> Super valid concern. I imagine it will raise the price considerably and there will be 'safe!' 3d printers that cost a ton because they've been certified and have filaments and suction/vacuum/air pushing systems that have been tested and show no ill effects towards humans. It seems inevitable, but I'd imagine price will come down in a while as things scale.

It also does open the door for someone to come in and make a vent/hood system that works for many types of 3d printers so I guess there's that...</comment></comment></comment></comment></comment>


Url2markdown - <AUTHOR> http://url2markdown.herokuapp.com/

<comment><USER2> I like the premise of this app.

Being able to easily convert random webpage text into Markdown could be incredibly useful (at least for me).

Good stuff!</comment>


Show HN: Prototype for new online learning app - <AUTHOR> http://www.skilldom.org Would love to hear the community's feedback on initial prototype of our online learning app - what would you like to see and NOT see in the full version! :) <comment><AUTHOR> We hope that this becomes the way people learn online. A flexible, mobile way to learn with others who are on the same path as you... The Best content is usually spread across 2 or 3 sources for any topic, so the goal is to curate the best possible structure for any skill. Also to make learning super actionable and easy to track...

We think that all college education and beyond should happen in this format!

</comment><comment><USER2> I really like the look of this. Can you describe more about your long-term goals with this? What is your intended market?</comment>


Boringcc: Proposal for a C compiler for secure software - <AUTHOR> https://groups.google.com/forum/m/#!msg/boring-crypto/48qa1kWignU/o8GGp2K1DAAJ <comment><USER3> I've always thought that there would be more value in exactly the opposite - <USER2> pathological C compiler (or C++ compiler, POSIX operating system, etc.). The pathological compiler would always implement undefined behavior in the most surprising, unpredictable manner - e.g., uninitialized memory would have a properly randomized value that changes from one run to the next, overflows would result in random values, etc.

That way, any programs that are made to work on the pathological implementation are largely guaranteed to rely only on standardized behavior, and work on any other standards compliant implementation.

<comment><USER4> I don't know if it's guaranteed to bark on _all_ possible cases of UB, but there we go:

      $ cat test.c
      int main() {
              return *(int*)0;
      }
      $ gcc test.c -fsanitize=undefined -o test
      $ ./test
      test.c:2:9: runtime error: load of null pointer of type 'int'
      Segmentation fault

I'm pretty sure I've seen similar tool based on clang as well.

And there is valgrind.

<comment><USER5> Just for the hardware-minded: dereferencing null is perfectly fine on Cortex-M processors and is well-defined.

Yes, that's hardware, but a nice place where hardware ain't C.

I'm just sayin'...

<comment><USER6> Dereferencing NULL, in a C program, is ALWAYS undefined behavior. The fact that you are using a Cortex-M processor does not change this fact. It is spelled out very clearly in the C standard.

<comment><USER7> I've used at times it to crash the program (core dump), producing a cleaner stack than abort().

<comment><USER8> You should use __builtin_trap(). Invoking undefined behavior lets the compiler justifiably delete the entire code path leading up to it.

</comment></comment></comment></comment></comment></comment><comment><USER9> > I'd like to see a free C compiler that clearly defines, and permanently > commits to, carefully designed semantics for everything that's labelled > "undefined" or "unspecified" or "implementation-defined" in the C > "standard".

That wouldn't just be a new compiler. That would be a new language. I dont think there are any short cuts to fix C.

C++ is doing something somewhat similar with the "C++ Core Guideline" rules, which are designed to be checkable by static analysis tool. The long term goal is that eventually C++ will become a safe subset, when all the error-prone parts of the language have replacements.

> "Following the rules will lead to code that is statically type safe, has no > resource leaks, and catches many more programming logic errors than is > common in code today. And it will run fast - you can afford to do things > right."

[https://github.com/isocpp/CppCoreGuidelines/blob/master/CppC...](https://github.com/isocpp/CppCoreGuidelines/blob/master/CppCoreGuidelines.md)

<comment><USER10> > That would be a new language

I don't see why it wouldn't be a valid implementation of C by simply defining things that C doesn't fully define.

There's nothing about the definition of "undefined behaviour" that _prevents_ you from defining it in your implementation.

<comment><USER11> Because then you are relying on a specification that's not in the spec. A different interpretation means that your code no longer works. Therefore, you've effectively created a new language.

<comment><USER12> Sixth grader students know all the words third grader students know, but third grade students do not know all the words that sixth grade students know. Are the third and sixth grade students speaking different languages?

<comment><USER11> In a certain sense, yes. Sixth graders can say things that third graders cannot understand.

The trick is to try to bring together all of these dialects in a way that everyone can in fact understand. This is why writing language specifications is _hard_.

And even afterwards, you can still choose a dialect over the standard. You'll just lose a certain segment of your audience. That may or may not matter for your purposes.

</comment></comment></comment></comment></comment><comment><USER13> At this point you pretty much want an alternative language more than a compiler: one that looks like C, but is completely defined. And this makes kinda sense, yet is IMO still quite dangerous (less than the actual situation but still too much)

1/ There are tons of people who will say: "this project is written in C" instead of the reality that is that this project is written in boringC, (actually probably even most of the projects authors will) and will for ex. compile with a regular C compiler instead of a boringC one, maybe for performance improvement...

2/ You just can't take C, even with a completely defined semantics, and call it a day for secure programming. It would still be filled with crazy features that are intrinsically impossible to render secure (everything about C "arrays" comes to mind)

So let's take this idea to its real destination and rewrite secure projects using a really secure programming language, instead of just extending the current mess for 30 more years.

<comment><USER14> So what do you do when an index into an array is out of bounds at run-time. You can't perform a check every time because that would go against the C's principle, and at the same time it would degrade performance, making it less useful compared to newer languages.

How would you implement defined behavior without a significant (which is what an if check is at that level) overhead in this case?

<comment><USER13> Compared to the economic cost of bugs, bound checks everywhere are (very very) cheap. Even more so with the CPU and compilers we have today, which are more than sufficiently smart from the point of view of when C was created. Intel is even adding some new instructions in their CPU to make that even less costly than you could imagine in even some crazy C based situation you would not think to be possible in the first place, because of C. But the cost here is extra complexity, for something that should have been built-in in the first place.

More technically to address fears of slowdowns even with simpler architectures, the additional checks will likely be factored most of the time (for example before a loop with linear accesses). When they are not, to have a real impact 1/ it has to be in a really hot code path (like 1% or maybe even 0.1% or even less of a real system) 2/ the cpu should not be able to use empty OOO slots and execution units to execute it without any extra penality 3/ this is quite a deduction from the two preceding points, but if we are talking about a big array being accessed in random order this will be slow because of RAM access anyway, an extra check won't induce any meaningful slowdown maybe even if it were mispredicted (which it will not be - in regard to performance).

Like always if you have any performance issue, first profile. And actually I can't remember having ever heard a single person complaining that some bound checking in a program was the cause of their slowdowns. It often far more macroscopic, and easy to fix anyway when it is that much micro. Considering usual modern systems, they are sometimes so slow that the problem is certainly NOT native bound checking, but very probably architectural madness.

<comment><USER15> If you were frequently catching out of bounds accesses your CPU's branch predictor would be making mistakes and you'd be frequently eating the branch mispredict penalty. Any extra instruction or check that alters the control flow is often much more expensive than just another addition. However, in this case if you're taking the branch something is seriously broken so that you should not be facing this. Pre-Haswell Intel CPUs only had one branch slot so you still might have a penalty but as you say this isn't the end of the world.

</comment></comment></comment></comment><comment><USER16> I'm someone currently in the process of drinking the Rust kool-aid, in part because the goals of the language are very closely aligned with what Bernstein proposes here. Further, because of the memory model, the compiler can produce quite competitive performance while still preventing the execution of any undefined behavior (related to his last strawman in the bullet list).

I get that even if Rust offers a panacea to the issues he mentions (which it may or may not, I'm no expert), there's still an awful lot of C code that would need to be deprecated and rewritten. But surely there'd be value in efforts to get away from a language that has such a loose standard?

<comment><USER17> I wonder how hard it would be to create a C -> Rust transpiler. The output would probably be God-awful, but it could be a start to moving away from C towards Rust.

<comment><USER18> A guess: very, very difficult. Writing code to satisfy Rust's checking is not much harder than writing C[1], but converting arbitrary C to satisfy Rust is something completely different.

[1] An' I say it as shouldn't. C is my natural language.

</comment></comment></comment><comment><USER19> Required reading here is Chris Lattner's "What Every C/C++ Programmer Should Know About Undefined Behavior", which goes into good detail as to why undefined behavior is important for performance, sometimes very important: [http://blog.llvm.org/2011/05/what-every-c-programmer- should-...](http://blog.llvm.org/2011/05/what-every-c-programmer-should- know.html?m=1)

Could you make a new language that doesn't depend on UB for performance? Sure, quite possibly. Is C that language? Probably not.

</comment><comment><USER20> This is actually something the ISO C++ committee is looking at.

See [https://isocpp.org/std/the-committee](https://isocpp.org/std/the- committee) \- SG12

An example of this is P0145R0 which specifies the previously unspecified order of evaluation.

See [https://isocpp.org/blog/2015/11/kona-standards-meeting- trip-...](https://isocpp.org/blog/2015/11/kona-standards-meeting-trip-report)

Apparently, the performance difference is expected to be zero on currently popular architectures and around 1% on older architectures.

</comment><comment><USER21> How far are we from having the will and ability for it to be common to use safer languages than C/C++/Java/etc.?

A long time ago, it didn't seem pragmatic to write in, say, ocaml, because no one was going to feel like building or even installing the compiler in order to try your dumb software, but now that everything is about packages from distributions...

Today it feels strange to apply security updates for necessary software where the announcements list "Multiple memory safety errors, integer overflows, use- after-frees..."

</comment><comment><USER22> It exists. It's called CompCert.

[https://github.com/AbsInt/CompCert](https://github.com/AbsInt/CompCert)

It's free for non-commercial use. I've used it for several months now to build things like Tor. I haven't noticed any disadvantage compared to GCC or Clang.

<comment><USER23> I don't think compcert avoids undefined behavior pitfalls. Its more of a way to protect yourself from compiler bugs.

<comment><USER24> It's a verified subset of the C standard rather than all behaviors of all compilers. There's some semantics and work covering a lot of that already that just needs to be integrated into CompCert or static analyzers. Likewise, there's static analyzers that already cover it too but not formally verified.

Here's an example of investigating that with Compcert:

[http://robbertkrebbers.nl/research/articles/compcert_formali...](http://robbertkrebbers.nl/research/articles/compcert_formalin.pdf)

Here's a semantics that looks for flaws and undefined behavior:

[https://www.ideals.illinois.edu/bitstream/handle/2142/34297/...](https://www.ideals.illinois.edu/bitstream/handle/2142/34297/Ellison_Charles.pdf?sequence=1)

</comment></comment></comment><comment><USER25> It sounds as if the root of the problem is the C standard. Wouldn't it be better to fix that instead of creating a shadow standard defined by the implementation of this boring compiler?

I also object to the presupposition that there is secure software and non- secure software. In most practical cases, it is impossibly hard to tell in which class an application falls, so it would be better not to make that distinction at all.

<comment><USER26> >It sounds as if the root of the problem is the C standard. Wouldn't it be better to fix that

Isn't the reason for a lot of undefined behavior either in the name of performance through optimization and assumptions, portability because the implementation can just do whatever the underlying platform natively does or the committee just couldn't agree on it?

All three of those scenarios appear inherently unfixable to me without a separate sub-standard that intentionally clamps down on performance/ease of portability and actually gets the committee to agree.

<comment><USER25> I don't know the reasons for why so many things are undefined in C. However, if a program does one thing when compiled with compiler A and another thing when compiled with compiler B, how does that help portability? To my perhaps naive mind this makes portability harder to achieve not easier.

<comment><USER27> A classic example of trying to define behaviour regardless of what all the different hardware does is Java choosing IEEE754 floating point. Which isn't natively supported on x86.

[https://www.cs.berkeley.edu/~wkahan/JAVAhurt.pdf](https://www.cs.berkeley.edu/~wkahan/JAVAhurt.pdf)

If C had standardised to the idiosyncracies of the PDP-11, it might have held back its development.

<comment><USER28> Are you referring to 80-bit floats used by the (long obsolete) x87 FPUs?

<comment><USER27> The 80-bit floats were still in use right through the 2000s; I know because I had to work out what option to use to get reproducible fp rounding on 64-bit doubles in 32-bit C. I've not had occasion to look at the details of amd64 fp.

</comment></comment></comment></comment></comment></comment><comment><USER29> Writing secure software in C is just next to impossible. Memory corruption, arbitrary pointers, deep magic. Even pure assembly is more secure, as everything is explicit and well-defined there. There are lots of safer languages than C, and performance is not everything.

<comment><USER30> Then how do you explain the fact that some of the most secure pieces of software ever written were written in C? (I'm thinking of, e.g., Qmail — and pretty much everything else DJB has ever written — and OpenBSD, just to name a couple off the top of my head.)

I would also qualify your statement that "performance is not everything" to say that performance isn't _always_ everything. Writing a kernel in an interpreted language probably isn't the best idea, for example.

<comment><USER31> > Then how do you explain the fact that some of the most secure pieces of > software ever written were written in C? (I'm thinking of, e.g., Qmail — and > pretty much everything else DJB has ever written — and OpenBSD, just to name > a couple off the top of my head.)

Unusual amounts of manual effort by unusually skilled people, probably using unusually security-focused development processes?

<comment><USER24> Exactly. Freak occurrences never disprove the rule. Most were simple, too, to the point that it's easier to get right. Large one's like OpenBSD had plenty of bugs during the development process. Many problems in small and large are prevented with a language that doesn't introduce them.

Rest has to be caught with other methods. A good language can still help, though, if it's easier to analyze.

</comment></comment></comment></comment><comment><USER32> " Claim that all we need is for some particular "undefined"-catching tool to be widely used. In fact, these tools are full of false positives and false negatives; at best they catch a few limited types of "undefined" behavior, not changing the big picture."

Question: why can't existing C compilers clearly indicate when they encounter undefined behavior?

<comment><USER33> Undefined behavior is primarily something that that has effects, rather than at compile time. For example, taking the value of an uninitialized local variable.

        int main() {
            int i;
            if(some_big_complicated_function()){
                i = 0;
            }
            printf("%d\n",i);
        }

Is this undefined behavior? The compiler can't be sure, because it can't know whether `some_big_complicated_function()` returns true or not.

Therefore, it would need to be a runtime check, rather than a compile time check. But runtime checks are expensive, and so it typically isn't done. It would be entirely allowed by the standard to give such a warning at runtime, but the resulting program would go much, much slower due to all the checks.

<comment><USER34> What you say is true, but this case could easily trigger a warning about _possible_ use before assignment. The compiler doesn't have (and can't) to prove that either branch will always be taken at runtime. And there's no benefit to code like this anyway, just write it so it's obviously to be assigned. Your coworkers will thank you.

<comment><USER34> And really, the main benefit to not assigning a value in the declaration is to get the compiler to tell you if there is a code path that misses an assignment.

        int i;
        if (foo || bar)
            i = 1;
        else if (baz) {
            if (!quux)
                goto fail;
            i = 2;
        }

        printf("%d", i); // not all code paths assign a value

</comment></comment></comment></comment><comment><USER35> Non mobile link: [https://groups.google.com/forum/#!msg/boring- crypto/48qa1kWi...](https://groups.google.com/forum/#!msg/boring- crypto/48qa1kWignU/o8GGp2K1DAAJ)

</comment><comment><USER36> OpenBSD (+LibreSSL) folks have been uncomfortable with unpredictable compiler optimizations for quite a while too. Here's a previous discussion on compilers in OpenBSD: [https://news.ycombinator.com/item?id=9322259](https://news.ycombinator.com/item?id=9322259)

</comment><comment><USER37> It has always seemed to me that the C community (and to an ever greater extent the C++ community) takes particular pride in making it as difficult as possible to write correct code. It provides bragging rights and job security for those select few who have taken the time to master all of the arcana of the language.

Personally, I tend to think that life is too short for that sort of thing. That's why I choose Lisp, at least when it's up to me.

<comment><USER24> Surprised being a LISPer you haven't read Gabriel's Worse is Better essays on the topic. Convincingly argue the reason behind the uptake of certain tech is they do just enough of a good job to work and for a lot of people. Then they get extended gradually in direction of what they should've been. C and UNIX were perfect examples of this on crappy hardware of 70's-80's. By 90's, it was legacy effect in play for various reasons. Still is.

Throw in organizations competing for money or ideology to get a bunch of implementations of a language that was shit to begin with. So, it was more the opposite of what you claim: too many groups trying to make things convenient for themselves in the short-run. LISPers did something similar with their individual messes getting merged into Common LISP. Those doing it clean and sensible on the right hardware were always the outliers.

<comment><USER37> I have read "Worse is better." The point I was trying to make was different:

> Then they get extended gradually in direction of what they should've been.

Yes, this is the part I'm disputing. It seems to me that C and C++ are _not_ being extended in "the direction they should have been" but rather in a direction that is beneficial mainly to a small incumbent minority. Everyone agrees that security is important, and yet it is virtually impossible to write secure code in C or C++, not because it would violate the laws of physics or some mathematical theorem, but because both the standards and the implementations are hopelessly brain-damaged.

<comment><USER24> "but rather in a direction that is beneficial mainly to a small incumbent minority."

The majority of C programmers seem to fight changes to the permissive way of doing things in name of efficiency and compatibility. I don't know what the interplay between them, compiler writers, and standards bodies is. Yet, it seems C programmers react pretty negatively to anything changing their language even here. Just imagine how much of UNIX or GCC might break if we did pre-fixed strings, a reversed stack, compiler-only pointer arithmetic, auto- bounds checks, and so on. It would all just... COLLAPSE.

"yet it is virtually impossible to write secure code in C or C++, not because it would violate the laws of physics or some mathematical theorem, but because both the standards and the implementations are hopelessly brain-damaged."

Totally agree there that this is what resulted. Recently, on a new platform, I needed to code up something that C programmers can read and I can't remember C worth crap. So, I decided to re-learn FreeBASIC cuz even it's easier to get right than C & I straight up can't stand C. Coding style wasn't... modern... but worked, was type-safe, iterated fast, ran in milliseconds, and was very readable. Stuff I can never say collectively about C without state-of-the-art tooling on 4-8 core machine with RAM disks. ;)

</comment></comment></comment></comment><comment><USER38> I don't understand this.

He's not asking for a -wundefined or -ansi -pedantic, he's asking for definitions for everything -ansi -pedantic rejects, and a new compiler. Hard work. Which of those cases are _that_ desirable?

</comment><comment><USER39> I think the biggest problem with undefined behavior in C is that it is taken to justify violation of C's customary semantics[1] on platforms where it isn't necessary.

Many types of undefined behavior in the C standard are essentially dispensations for Lisp machines or one's complement CPUs. It's very surprising to see them invoked by the optimizer on more conventional platforms. It might not satisfy djb, but a standard for these behaviors alone would be great progress.[2]

[1] [http://arcanesentiment.blogspot.com/2014/12/customary- semant...](http://arcanesentiment.blogspot.com/2014/12/customary- semantics.html)

[2] Posix doesn't really address this, sadly. The committee seems to have avoided standardizing byte size until an unforeseen interaction with a later C standard pushed it into a corner.

</comment><comment><USER40> Actual URL, accessible without Javascript: [https://groups.google.com/forum/message/raw?msg=boring- crypt...](https://groups.google.com/forum/message/raw?msg=boring- crypto/48qa1KWignU/o8GGp2K1DAAJ)

</comment><comment><USER41> I think the problem is not the language standard per se, it's the education and historically sloppy compilers. It's a bit like W3Schools for javascript teaching everybody all the worst practices, that's not a problem with the javascript language itself.

I mean really, what are the most common cases of undefined behavior that cause real problems in the world? (Reading past array bounds or trying to dereference uninitialized variables are such obvious _errors_ that i don't categorize them as 'unexpected undefined behavior', the later is caught by most compilers and static analyzers today anyway. Though i agree having the length known in arrays would greatly help.)

Any time i see some raging blog post about how undefined behavior ruined someones day it's 99% of the time because they one way or another were trying to cast a pointer of one type to a pointer of another type, like thinking they could read the first 16 bits of an int* by casting it to a short* first. The root cause of this is because people think that pointers are addresses to a sequential grid of NAND-gates on your DDR4-stick, when they in fact are _abstract_ references to a variable that can carry a value. This comes from school, where the way teachers show you how pointers work is exactly like that. Tutorials on the internet also say that you can do smart tricks with pointers just to teach you and then people think that's how you should do it. When compiling in debug-mode this is how the memory is usually aligned so things still work anyway.

Historically compilers didn't warn about this either and things still worked so many people got used to writing things this way and today those people are the "experienced C gurus" in companies that pass down this misbehavior to their younger peers.

Overflow on signed arithmetic is another of the common pitfalls but that's life if you code for embedded, the alternative solution that "just works" would be to do all arithmetic in a BigInt type as python but that clearly isn't viable on embedded, or to do everything in floating point but that has its own pitfalls.

</comment><comment><USER42> I don't think this can be done with C. Really

\- Remove all possibilities of memory aliasing. Only exception might be when reading from devices/network (some kind of boxing, unboxing)

\- All array accesses are bounds checked.

\- Checked conversion between int/unsigned int and different sized items. Converting a char into an unsigned int? Be explicit in what you want to do

\- No pointers "flying around", unbound to types. Have reference-counted objects at least. Allow a way of passing a sub-array without copying/with read only permissions.

\- Remove "gotchas", like ordering of statements, assignment on comparison (unless it's obviously correct), no "compiler dependent" behaviour, no "undefined behaviour" (unless it's machine specific)

<comment><USER43> You are confusing unsafe behavior with undefined behavior. He is not suggesting that a C compiler should prevent the above mistakes. He's suggesting that it should document what code the compiler will emit in such cases. For example,

\- reading past the end of an array will always segfault the program immediately. or reading past the end of an array will return (arrayType)0

\- signed integer types must overflow according to two's complement. A compiler may not assume that, for instance, (int)x < (int)x + 1 is always true.

\- uninitialized variables are zeroed out. That is, `int *x;` always produces a null pointer, `char y` always produces '0'

\- A compiler may not remove any statements where it determines such an optimization would not change the behavior of the program. See [http://www.daemonology.net/blog/2014-09-04-how-to-zero-a- buf...](http://www.daemonology.net/blog/2014-09-04-how-to-zero-a-buffer.html)

Such a compiler would accept and compile any C program, and the programmer (and any static analysis tools) would have a better idea of the behavior of the output program.

<comment><USER44> > reading past the end of an array will always segfault the program > immediately. or reading past the end of an array will return (arrayType)0

How would this work when you pass the array (i.e., the pointer) to a function? In order to do what you describe, every pointer would need to include bounds information. This would break the C ABI, so your code would no longer link with existing C libraries.

<comment><USER45> OP answered this on the thread. Pointer bounds are stored in a lookup table. Pointers are passed to functions according to C ABI, and bounds are retrieved by querying the lookup table by the pointer.

</comment></comment></comment></comment><comment><USER46> Some small steps could have been made _years_ ago.

For instance, getting rid of unspecified order of evaluation. Or defining a dialect of ISO C in which evaluation is strictly left to right, and making support for that optional (so then your local GCC or whatever can have -fstrict-iso-eval to turn it on).

Another example of "small stuff": catching negative values being passed into the <ctype.h> functions. Also, all the instances in the standard library where a null pointer invokes undefined behavior could be required to abort the program.

Some undefined behaviors cannot be made defined without a lot of overhead (like catching all out of bounds pointers).

However, there is a lot of "low hanging fruit" undefined behavior where things can be improved.

</comment><comment><USER47> One of the bases for security is the age of a program. All other things being equal, the implementation that has been around the longest is expected to have fewer issues than the shiny, new thing (because the old program is well- understood, has been patched to death, considers a thousand corner cases, ran on more hardware, more time passed without any issues, etc.).

As such, changing away from well-known compilers and language behaviors may not be the wisest thing for security.

On the other hand, extending existing compilers to restrict behavior seems reasonable. Also, by all means document the hell out of the things that are not well-defined.

</comment><comment><USER48> My understanding was that with optimizations off, clang/gcc were pretty "boring". Is a whole new compiler really required?

Personally, to fix these problems I'd lean toward finding a new language instead of a new compiler.

<comment><USER45> For example, OP suggests zeroing uninitialized variables. Neither clang nor gcc with optimizations off do that.

</comment></comment><comment><USER49> In the past initializing variables to zero might have been too slow. But not now.

</comment><comment><USER50> CompCert?

<comment><USER51> I believe Compcert still translates programs with undefined behavior and doesn't really do anything about it; or rather, the behavior is defined but based on whatever the Compcert authors define the behavior to be.

</comment></comment><comment><USER52> Is there any list of undefined behaviours in C? Other than the standard.

</comment><comment><USER53> He says this:

> Claim that a boring C compiler can't possibly support the desired system > _performance_. Even if this were true (which I very much doubt), why would > it be more important than system _correctness_?

If correctness is more important than performance, C is the wrong language. Consider a language with, at the very least, garbage-collection built into the core, as memory allocation and usage errors are the base of a lot of what goes badly wrong with C programs.

In short, his notion of "Boring C" seems to be Haskell or Common Lisp.

<comment><USER24> Those languages are incredibly complicated. I'd go with Modula-2 or Pascal as a boring C candidate.

<comment><USER53> I'm not sure that either of those languages are usually GC'd, but they'd be good choices, too, if they were.

(I just don't like Wirth languages. I don't like their type systems and I don't like the definition-before-use requirement. They're better than C, in some respects, but worse in others, and the net isn't always an improvement.)

<comment><USER24> All of Wirth's after Modula-2 were GC'd. C programmers would reject a GC'd language, though. So, I stayed with originals that enhanced safety, predictability, readability, and so on while capable of low-level, fast stuff. Wirth's stuff and industrial variants of it often let you do unsafe stuff in dedicated modules for that so you could turn off GC or checks.

Plus they wrote OS's in Modula-2 and Pascal on ancient hardware. Whole platforms. So, they're proven for the use case C programmers often say you need their language for.

<comment><USER54> For anyone interested in Modula-2 as a potential replacement for C as a systems language, there is a small but hopefully growing revival of the language occurring on the Gnu Modula-2 mailing list and (especially) on comp.lang.modula2 . Right now there is a call on the newsgroup for testers of the Modula-2 to C (M2C) compiler. This is part of a larger effort for the Modula-2 Revision 2010 (M2 R10) language definition and implementation by Benjamin Kowarsch and Rick Sutcliffe.

<comment><USER24> Appreciate the tip: that's exciting. Also an ideal time to extend it with improvements learned from experience since Modula-2 and avoid problems learned similarly. I actually downloaded the old Modula2-to-C compiler, Lilith technical paper, and A2 Oberon sources in case any of that ended up being useful. Maybe it will. :)

</comment></comment></comment></comment></comment></comment><comment><USER55> Clearly what you want is something _other than C_.

<comment><USER56> Ada, and recently Rust, for example. People trying to improve C are sad to watch. People use C because they have an irrational belief in their own faultlessness. Same reason people are afraid of flying but not driving. Selling a correctness-enhancing tool to these people is an impossible task.

<comment><USER57> I recently tried to use Ada, that ended in sadness. I couldn't try Rust, because it doesn't (didn't?) run on arm-none-eabi.

<comment><USER11> Rust should work on `arm-none-eabi` to my knowledge. We don't provide packages out of the box, but people have done it. You need to set up the right target specification, and then it should work.

<comment><USER57> Possible, I don't remember the details. It might also be that setting up a cross compiling toolchain by hand was not exactly how I intended my first contact with a new language be (I had set up a cross compiling GCC, then a cross compiling Ada that ended up in a linux simulator, I might have lazied on the rust test).

<comment><USER11> Yeah, it's not ideal. We are actively working on making it easier to do these kinds of things; it's not well documented, to be honest.

</comment></comment></comment></comment></comment></comment><comment><USER58>
        gcc -O0

Would that do?

<comment><USER45> gcc -O0 does not zero uninitialized variables, which is among things explicitly suggested by OP.

</comment></comment><comment><USER59> Event the greatest brains can fart, this proposal can be safely ignored.

</comment><comment><USER60> Surely this is where things like __attribute__ ((optnone)) and #pragma optimize("", off) come in useful.

</comment><comment><USER61> The compiler for this language will be too slow to be useful. Contrary to this author's belief, crypto people really do care about performance.

Anyway, what the author wants isn't a "boring C" compiler, it's a compiler for a new language that doesn't actually have undefined behavior.

<comment><USER62> From the article:

> * Claim that a boring C compiler can't possibly support the desired system > _performance_. Even if this were true (which I very much doubt), why would > it be more important than system _correctness_?

<comment><USER63> It can't be taken for granted that performance and correctness are separate concerns. Even leaving aside the obvious category of realtime applications, performance issues can create DoS vulnerabilities.

edit: That being said, a boringcc might end up being _less_ susceptible to these vulnerabilities in practice, since the performance of the emitted code might be more predictable. I'm sure djb has considered this. But in general I think it's often a mistake to think of performance as an implementation detail rather than as a deliberate feature.

</comment></comment></comment><comment><USER64> Programmers always want new and more clever constructs in their code, and there is always the next feature that will optimize inner loops 10% better. This is human nature apparently, so don't put too much faith in a boring anything gaining traction.

And for those of you courting Rust, remember there are two kinds of programming languages in the world: those that no one uses, and those that are known to be terrible.</comment>


Best to keep things simple? Backlash from the community - <AUTHOR> http://search.twitter.com/search?q=sitemeter

<comment><AUTHOR> Sitemeter just launched their new version - <https://www.sitemeter.com/viewstats.php?site=sm1giantbikes>

Definitely a lot "flash"-ier (descriptively & literally) than the previous version that was mainly text-based.

I'm honestly surprised by the rejection by the vocal community.

Any Sitemeter users here?</comment>


Ask HN: Would You Pay? - <AUTHOR> Hey HN community, I'm conducting some research for a startup idea and would like to ask the community a question.
Let's say you're renting a car, and there is a $100 hold that is placed on your credit card for the duration of the rental. If you had the option to pay 9% of the $100 deposit, so $9 upfront to not have the $100 hold placed on your card during the rental, would you pay the non-refunded fee? That would mean during the duration of your rental, you would have access to $91 and wouldn't need to wait days after returning the car to get $100 back.
Consider the same option is available for other services like hotel rentals, Airbnb, apartment security deposit, etc. <comment><USER2> This is a terrible place to do market research on this. HN likely skews wealthy and financially literate, and this is a product for people who don't have a spare $200+ in their bank account or on their credit card. Basically it's the same people who would want payday loans.

Further, credit cards already allow people to get cash advances in an emergency.

Lastly,taking a $91 loan for an interest rate of 9% is financially insane.

I don't know if my repulsion at this (both morally and as a business idea) is apparent, but I am repulsed.

If you want to start a business, find a way to give people value rather than exploiting their desperation and/or poverty.

<comment><AUTHOR> You're missing the question. The idea would allow a customer to have better cash flow not take out a loan. What I am asking is would you pay a fee over placing a hold on your card. For a person with not a lot of money, holding $100 for 5 days can be a problem but paying $9 to not have that problem could be helpful.

<comment><USER2> That's just insurance. You'd be insuring the amount of the deposit. Any business can buy this from a major insurance company if they want.

<comment><AUTHOR> They can't because it's not a current product offering.

<comment><USER2> _Insurance_ is not a current product offering? I think you're trying to pitch a financial product without a deep enough understanding of finance as a concept and perhaps as an industry.

If, for example, Hertz wanted to stop requiring a $250 deposit on vehicles and instead take a $22 fee, they could approach any large insurance company and find out if they would underwrite it. That company's actuaries would assess the risk of a typical Hertz customer and either say that, yes, $22 is enough to cover losses, or no, it needs to be higher.

In fact, Hertz may already do this. A $250 deposit is incredibly low for someone renting a $20-40k vehicle with nothing more than a driver's license and credit card.

Source: I'm a partner in an insurance startup.

</comment></comment></comment></comment></comment><comment><USER3> I agree with smt88 regarding market research on HN is likely not a good place to do so.

Having said that, I definitely would not pay the fee. $100 is negligible of a hold and most rentals don't last for more than a week or two in my case (depending on where I am traveling). It wouldn't make sense to pay a fee when the hold is fully refundable and doesn't make a dent in my card usage.</comment>


Working at Google - the first 6 months  - <AUTHOR> http://dondodge.typepad.com/the_next_big_thing/2010/06/working-at-google-the-first-6-months.html?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed:+TheNextBigThing+(The+Next+Big+Thing)

<comment><USER2> See <http://news.ycombinator.com/item?id=1440220> for previous discussion on Don's post.</comment>


AllSides, a news aggregator that tries to quantify the bias of publications - <AUTHOR> http://www.allsides.com/ <comment><USER2> AllSides describes how they rate bias - it is supposed to reflect the average judgment of Americans, only reflects the web pages on news (not opinion pieces) and they are continually getting more data and changing. Explanation here [http://www.allsides.com/bias/bias- ratings](http://www.allsides.com/bias/bias-ratings)

</comment><comment><USER3> This has great potential, I'd definitely argue with some of the classifications but giving people on both sides a single site where they can contrast what both sides are saying could begin to heal the country's great divide.

</comment><comment><USER4> Speaking of bias: the Daily Beast, Politico, and NPR are defined as _centrist_.</comment>


Web APIs and n+1 problem - <AUTHOR> http://byterot.blogspot.com/2014/04/web-apis-and-n-plus-1-problem-web-api-rest-cache-mongodb-soa-microsoervice-timeout-retry-circuit-breaker-layered-caching-nosql.html

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

But you knew that, because you submitted it.</comment>


[Jupyter Search] Utility for searching within multiple Jupyter notebooks - <AUTHOR> https://github.com/cardwizard/JupyterSearch <comment><AUTHOR> We all know how easy it is to create and work on jupyter notebooks. But sometimes we end up creating a lot of notebooks which become unmaintainable.

JupyterSearch is a simple utility which enables you to quickly search for a term in your notebook collection.

You can download it and get it working from here. [https://github.com/cardwizard/JupyterSearch](https://github.com/cardwizard/JupyterSearch)</comment>


A Modest Proposal for the Telephone Network - <AUTHOR> http://apenwarr.ca/log/?m=201306#09

<comment><USER2> It took me a while to realise that this is a rant about IPv6.</comment>


Whois for Ruby Gems - <AUTHOR> http://railstips.org/blog/archives/2010/03/30/because-gem-names-are-like-domains-in-the-90s/ <comment><USER2> Pro tip.

Messages like "Gem not found. It will be mine. Oh yes. It will be mine. _sinister laugh_ " are only funny when they are conditional upon something like rand 100 < 1\. Even then... hire a writer.</comment>


F# and GPUs for Life Insurance Modeling - <AUTHOR> https://devblogs.nvidia.com/parallelforall/gpus-dsls-life-insurance-modeling <comment><USER2> I took a GPU programming course in college and even did a year long thesis implementing a RK4 integrator to solve a particular differential equation.

In my thesis work, the main issue I encountered was that RK4 was a vector operation, but GPUs are matrix processors. The bottleneck in the application was the memory bandwidth, not the GPU itself. We ended up with a speedup of 16 w.r.t a single-core CPU implementation of the same problem.

The article claims a speedup of 35-60, but I see they also compared the GPU to a single-core CPU implementation. This is not a fair comparison. If they want to be fair, they need to utilize the full capabilities of a CPU (think performance per socket, not performance per core). I think Intel makes 18-core CPUs now; with a properly implemented multi-threaded RK4 (not very difficult) I'd expect the speedup to be closer to 2-12 instead of 35-60.

<comment><USER3> >In my thesis work, the main issue I encountered was that RK4 was a vector operation, but GPUs are matrix processors. The bottleneck in the application was the memory bandwidth, not the GPU itself. We ended up with a speedup of 16 w.r.t a single-core CPU implementation of the same problem.

I know more than one large property/casualty company that still uses APL[1] internally, which is a matrix language. I don't have any close friends on the health/life of things, though.

Would be interesting to see how that runs on a GPU.

That said, I imagine most places would rather throw more metal at a problem than have to move their actuaries to a new language. Processors are a lot cheaper than actuaries.

[1] [https://en.wikipedia.org/wiki/APL_(programming_language)](https://en.wikipedia.org/wiki/APL_\(programming_language\))

<comment><USER4> That is the topic of my Ph.D. APL for GPUs.

We've done type inference for a good subset of APL, and compiled it into a small (mostly) functional language. We can generate fused C-code that performs very well and I'm working hard at an OpenCL backend.

[1]: [http://www.elsman.com/pdf/array14_final.pdf](http://www.elsman.com/pdf/array14_final.pdf)

<comment><USER5> I still use J because I think array, or matrix-based languages are a nice fit for the multi-core CPUs and GPUs available for such computations. Wes McKinney of Pandas was/is studying q and J for his current work. There's a reason these languages have been used actuaries and quants to analyze time series, and columnar data. And they're concise which some criticize for readability, but like Math symbols once you know them, they are very powerful.

       [1]   http://conceptualorigami.blogspot.co.id/2010/12/vector-processing-languages-future-of.html?m=1

       [2] https://scottlocklin.wordpress.com/category/tools/j/

</comment></comment></comment></comment><comment><USER6> It seems like a nice and modern stack to work with. Anything on adoption in the industry?

It's a niche market with firms very-very reluctant to switch software and very-very long development cycles. Some googling led me to Edlund, which from their '14 annual report seems a mainly Danish firm [1].

[1] [https://www.edlund.dk/sites/default/files/Downloads/annual-r...](https://www.edlund.dk/sites/default/files/Downloads/annual- report_2014.pdf)

<comment><USER7> I'm busy building a new insurance company called Cuvva.

Initially, we had planned to work with the existing software platforms, as we had assumed it would be too difficult to build the stack ourselves.

But their terms were completely financially untenable for our model. Additionally, they have never supported a truly mobile insurance platform before, so we were concerned that it wouldn't deliver the experience we wanted.

So we ended up building everything from scratch. It took less time than we were quoted by the various software houses, at about a fifth of the cost. We couldn't be happier with how it has turned out.

<comment><USER6> Life or SLT business? Then I'm truly impressed. Any links?

P&C on the backend is imho a few orders of magnitude simpler (although I enjoy the statistics there more). 30 to 50 year complex contracts and then try to manage your market risks.

Edit: sorry, you mentioned the name. Nice idea! I guess you are so far away from traditional products you actually stand a chance. (For readers from other sectors: Market is cut throat and multiline insurera have lower capital requirements so new monoline in Europe is practically impossible.) You'll have contracts running for hours, not decades ;)

<comment><USER7> Hourly/on-demand motor :)

Helps enable people in the UK to borrow their friends' cars (which is often illegal here).

There are a few more complexities in motor insurance which don't exist in other verticals also.

</comment></comment></comment></comment><comment><USER8> Aon Benfield Securities has a Python + GPU approach to actuarial modeling. If you want to compare the approaches they take, there's a video and talk up on the DSLs for Finance homepage: dslfin.org

For those generally interested in financial domain-specific languages, the website also has a comprehensive listing of financials DSLs.</comment>


Video game developers confess their hidden tricks - <AUTHOR> https://www.polygon.com/2017/9/2/16247112/video-game-developer-secrets <comment><USER2> This is really cool. Things that only the developers and the most hardened and dedicated of fans would have noticed.

As much as we feel like games are set micro universes with static rules, they change for the sake of fun/intensity and that is wonderful.</comment>


The Key To Gmail: Sh*t Umbrellas - <AUTHOR> http://techcrunch.com/2010/03/14/key-to-gmail/ <comment><USER2> I think the more appropriate analogy is "shit filter."

I really appreciate project managers that know when the customer is full of shit and can filter that out from our discussions, keeping me and my colleagues focused on the things that actually matter.

On the other hand, when I did front-end work, I was really annoyed that the management would keep the secrets of customer feedback to themselves and only let through the things that aligned with their own "vision." Honest feedback and actual usability testing never seemed to be something that the higher-ups cared about; they simply wanted to go through the motions. I wished they could just let some of this information through.

<comment><USER3> _I think the more appropriate analogy is "shit filter."_

The article specifically mentions the difference between shit "funnels" (or filters) and shit umbrellas. Shit is shit, there's no good amount, other than zero, that it's good for engineers to have rain down on them. If there's anything of importance in the shit a good manager's job is to fish it out, wash it off, and pass that on to their engineers.

</comment></comment><comment><USER4> The revelation that Buzz was produced by a team of 30 engineers and one product person, who only ever meet to give product demos, explains much about that launch.

I'm not a mindless Google-basher. They have many brilliant products. But Buzz was a pointless product that looked terrible and broke user expectations, produced entirely on a "because the data would be fun to have" basis -- something you'd expect from engineers who aren't thinking about the customer.

Engineers _can_ build great, customer-focussed products (heck, that's the idea behind most of YCombinator). But this group did not.

</comment><comment><USER5> _> Internally, the Google Buzz team was known as "Team Taco Town"_

So apt: <http://www.hulu.com/watch/1447/saturday-night-live-taco-town> — It's 15 great tastes all rolled into one!

<comment><USER6> An unfortunate name, considering.

</comment></comment><comment><USER7> I love this article, I showed this to some of my associates at my last job and they fell on the floor. With one of them exclaiming "Dude you are a shit Umbrella" and I had such noble descriptions of the position like "Shielding the developers" and "The gate keeper". Well at lest I know what my job title is now, I guess I should see if Google is hiring for any Shit Umbrella positions, I am pretty good at it.

</comment><comment><USER8> I found this line interesting: "There are several hundred thousands lines of javascript in Gmail – one of the biggest in the world".

I'd like to see what the engineers have to say on managing that much JavaScript.

<comment><USER3> Gmail uses the Google Web Toolkit, a lot of the javascript that runs on the site is actually produced via code that is originally in java.

<http://code.google.com/webtoolkit/>

<comment><USER9> Gmail precedes GWT.

</comment></comment></comment><comment><USER10> > Google uses Gmail internally (obviously), switched over from Microsoft > Outlook at launch (about 6 years ago)

I was under the impression that pine was a popular client at Google.

</comment><comment><USER11> 100 engineers? What have they been up to for the last 5 years? (besides buzz)

<comment><USER12> Buzz, Wave, and Gmail Chat (including Video) aren't enough for you? How about Gmail Labs, which didn't exist 2 years ago, but now lets you skin Gmail, use keyboard shortcuts, embed youtube videos, etc. etc.? Calendar integration, a better text editor, embedded photos, multiple simultaneous attachment uploads w/ progress bars, better filters, incrementally better spam protection, plus the fact that I now have 7.5 gigs of space in my inbox, all while fending off attacks from Chinese hackers?

I think you grossly underestimate the amount of things they've accomplished in the past year, and the number of people it takes to run a service this popular. Facebook releases with grandiose redesigns, prompting temporary revolts among their users. Gmail improves incrementally, so much so that I can't imagine living without it as my primary e-mail client, but the sense of novelty that comes with a massive redesign is lost. Personally, I prefer Gmail's approach.

<comment><USER11> That sounds like a lot of work for 10 people, or a normal amount for 20.</comment></comment></comment>