Truth First, or Why You Should Mostly Implement Database-First Designs - <AUTHOR> https://blog.jooq.org/2018/06/06/truth-first-or-why-you-should-mostly-implement-database-first-designs/ <comment><USER2> This is a really important piece for developers to read.

We get very used to the ability to blow away everything and start from scratch, and that's very often the right answer for build tools, but the database is fundamentally different from that, and you _need_ to internalize this.

A database, in most cases, is the business. It's essentially a collection of all the contracts made with customers, and your mode of thinking "I can blow this away and start over" that you've learned from all sorts of build tools is completely contrary to that.

An infamous example of this is in Active Record migrations[1], and possibly some other migration tools.

> Note that we define the change that we want to happen moving forward in > time. Before this migration is run, there will be no table. After, the table > will exist. Active Record knows how to reverse this migration as well: if we > roll this migration back, it will remove the table.

These are smart people, and indeed there are some _rare_ cases where this is the right thing to do. But only our strongly ingrained belief that data is ephemeral would cause us to think this should be the normal behavior, that we'd want to blow away customer data to force the database to track what version X of the code thinks it should.

[1] [http://edgeguides.rubyonrails.org/active_record_migrations.h...](http://edgeguides.rubyonrails.org/active_record_migrations.html)

<comment><USER3> There are very, very common cases where this is the right thing to do - development. You'll want to be able to check out a branch, apply the migrations, test the code, and roll back the migrations before you switch off to another branch all the dang time.

When you're limiting yourself to discussion of production environments, absolutely you're correct, rollbacks should be essentially prevented, ideally through tooling that makes them nearly impossible to run, especially without performing a backup first.

<comment><USER4> I don't think I would be comfortable doing database schema related work in a branch unless I was also essentially branching my database at the same time. Even for my mostly garbage personal developer database that's filled to the brim with nonsense names and keyboard mashing. The chance of breaking something and wasting a large amount of time and data are too great. Of course, Thou Shalt Have Backups, but it's not exactly a frictionless experience if you fry things and have to go back to them.

Unfortunately it's not quite as quick and easy to clone off a copy every time you want to run some tests or fiddle with a spike as it is to jump between Git branches.

<comment><USER5> _> branching my database_

This sounds like a great product idea! Someone please do this. :)

<comment><USER6> Check out Delphix ([https://www.delphix.com](https://www.delphix.com)). It provides a ZFS-backed copy of your production database per developer using snapshots, with rollback. Disclaimer: a friend worked there, I haven't used it personally, and it's not free.

</comment></comment></comment></comment></comment><comment><USER7> No, you shouldn't use a code first, _or_ a database first design.

The article explains the problems with the code-first approach very well, but there are just as many problems with the database-first approach:

\- There is never just one database. There will be your production database, a staging database, one or more testing databases, local development databases, etc. This makes the database useless as a single source of truth.

\- When you write code against your development database, there's no guarantee that it will be the same as the production database, and you shouldn't be able to connect to your production database while developing locally to verify that. Usually you want to deploy identical build artefacts to staging and production, so there's a danger that your staging database gets out of sync with production (eg. after an issue was caught and improperly rolled back on staging) and then you deploy your fully tested code from staging to production and your entire system breaks down.

\- When you need to restore a backup of your database, you need to somehow find a compatible version of the code to deploy as well.

My recommendation is to use your migration scripts as your source of truth. Each service should access separate schemas within the database, or at the very least separate tables. If you really need multiple services to share tables then those services should be versioned and deployed as one.

The database should have a table which stores a list of the migrations which have been applied, and you should use a migration tool such that when you deploy, outstanding migrations are applied as required.

If you want something easier to read than the history of migration scripts, then you should keep an up-to-date schema _as well_ next to your code, and verify as part of CI that running all the migrations results in that exact schema.

<comment><USER8> It can help to establish rules such as "new DB migrations must always be compatible with old code" aka "migrations first". This gets everyone into the mindset that a db+code change must be carefully staged in a way that both (new DB, old code) and not just (new DB, new code) are tested. If the migration goes wrong due to different data in prod, it's easier to roll that back before new code is deployed.

<comment><USER9> Anything faster than what you're suggesting here is trying to rush the process.

Create the data before it's needed, clean up old records, verify the quality, make it required. And only then do you use it.

</comment></comment></comment><comment><USER10> From a startup perspective I strongly disagree, I think the UI should almost always be designed first. The HTML/CSS/JS frontend that the users see comes first, and have it hooked up to an empty backend that does nothing. Then once the UI requirements are fleshed out and the final specs nailed down, only then the database schema should be designed. The backend glue e.g. Django/Rails comes last.

I find this approach has led to the fewest number of code rewrites and database migrations needed to get from initial mockup to finished product, because UI requirements can change much faster and are more fickle than DB schemas and backend code.

<comment><USER11> I agree that the UI / user experience needs to be spec-ed out first. However, in terms of actual development, writing the DB schema's first is usually the right call. I typically feel that things should be designed outside-in, and developed inside out. Of course those are just general principles.

<comment><USER12> > [T]hings should be designed outside-in, and developed inside out.

This is gold, and so many do not do this.

</comment></comment></comment><comment><USER13> My two cents: always source control your databases.

I don't care if you are code first or database first, but I do think database schema and migration scripts are code artifacts and need to be source controlled _somewhere_.

You should be able to track who made a change and when and what for, and maintaining by hand a "commit list" in a comment at the top of a stored proc doesn't count.

You shouldn't need a full backup of a Production database to spin up a new test server, and you shouldn't need to rifle through every developer's documents and desktop folders looking for random .sql script files to figure out if you are missing a migration/update/refactor script somewhere.

(The argument that you rarely spin up a new Production server is I think tempered by how many developers and testing environments you need. Setup time for developer/testing instances indicates a part of how long onboarding new developers may take; and here I lean to the side of developer productivity and good backups.)

Most code first methods give you source control "for free", which makes them easy to recommend to junior developers / small startup projects.

Visual Studio has decent SQL Server Project support to help with the database- first crowd, as one option I've relied on heavily. Unfortunately, I've yet to see an open source, more database agnostic relative to it.

</comment><comment><USER14> First supervisor I had in my 2nd job out of school had a mantra: get the data model right and everything else falls into place.

Has worked for me for 30+ years.

<comment><USER15> "Show me your flowcharts and conceal your tables, and I shall continue to be mystified. Show me your tables, and I won't usually need your flowcharts; they'll be obvious."

\-- Fred Brooks

<comment><USER16> I've gotten the feeling that flowcharts used to be considered quite important by lots of coders, while today they are only used in particular subcultures. A flowchart is sort of an ungainly artifact. It repeats information that is in code, but is more difficult to produce and save than code is.

<comment><USER17> I've found them worth the effort pretty much only when trying to explain to stakeholders that they have given me conflicting requirements. When they can follow the logic path with their own eyes they are usually able to figure out what they actually want

</comment></comment></comment></comment><comment><USER18> One use case for when you may consider code-first - pure experimentation and fast iteration around the data model that supports your application.

I have used both models, and did database-first extensively, for at least 15 years. However, having been working in .NET lately and having EF Code First migrations (painful, but read on), I did discover a sort of hybrid model that worked.

Eventually, I believe you will always end up at database-first, even if you start code-first, unless your database is relatively small (by # of table/procs/views count) or limited in scope. But as applications grow, multiple databases become a reality, the database might grow truly huge(# of tables/procs/views), you might need customization to your database platform, etc. - limiting it by the application / code-first becomes impossible.

Where code-first works well, for me, is limited scope OR, more importantly, when you need really fast iteration for prototyping and don't want to think about building the tables. I've found that use case, code-first can be really helpful to think in code, let the system generate the database, at least enough to get to an MVP or PoC type-level of work product. Then, once it's working enough, to really take it all the way, switching to a database-first approach to do all the customizations to a particular database platform's strengths, etc. can work - I've done it myself on several projects successfully.

The tooling is almost there to do this... just start code first, and then once you have your system bootstrapped, generate the database first model and switch. But, you have to be careful with naming things so that names of things in your code match up (or can easily be updated) if you switch from code-first to database-first - something that not all code generators let you control completely (most template-driven ones do, though).

</comment><comment> steve-chavez If you're using PostgreSQL, I invite you to try PostgREST [https://postgrest.org/en/v5.0/intro.html](https://postgrest.org/en/v5.0/intro.html) which takes the database-first approach even further, with PostgREST you develop all your business logic in SQL, there's no code generation, no ORM, which no matter how elegant will always impose a performance and abstraction overhead(to do an aggregate you have to read the ORM docs, learn/understand the abstractions, add the code, all of this in addition to what you already know how to do in SQL).

Check the API [https://postgrest.org/en/v5.0/api.html](https://postgrest.org/en/v5.0/api.html) for more details on all the features that work out of the box, no ad-hoc code needed.

</comment><comment><USER19> I couldn't agree more. The code first design is what kept me away from Rails. I'm sure they have sensible approaches as well, but unfortunately I couldn't get over my prejudice that anyone who teaches the creation of the database through the app's code instead of actually designing the database is someone I don't want to follow or learn from and whose framework I don't want to use even if it provides alternatives (I hope it does). Database design in a CRUD app is by far the single most important task. Show me your code and I know nothing, show me your data structures and I understand the whole app never applied more.

The consequences of not following this advice I see everyday at my current job where we are stuck with an ORM that needs at least 3-4 files modified for each entity change and that requires management using an external GUI tool. The ORM adds 10x overhead to already unoptimized SQL queries so optimizing the queries is never a problem because the system's overhead is so slow even if it was possible to make the queries run in zero time, the overhead would still kill us. 10x. Query is 10ms and overhead is 100ms. And the trade-off for this? Nothing but a shitty ORM that makes no sense (Doctrine 2/PHP) and slows down development a few times over as well. Changing even the name of a column requires editing multiple files. We have camelCase, snake_case, and kebab-case for all our entities and depending on where you are in the system, a different case is required. Using the ORM to generate entities after you're in production? Don't make me laugh. That's impossible. And this isn't even the worst ORM I've used (though it's close). Everything the author mentions and then a whole bunch of stuff that's a million times worse has resulted from this drive to abstract away the most important component, the database, and not have it be the single source of truth. Frankly, it's fucking stupid and beyond maddening, not to mention slow and due for a rewrite. Never again will I tolerate this kid of design that ORMs encourage or the use of ORMs at all, especially if they replace solid database design. I'll leave that kind of fuckery and stupidity to the rookies.

<comment><USER20> What's stopping you from designing your database in Rails? You can spend all the time you need designing it, and then just write your design down in migrations/models.

<comment><USER16> I've never used Rails, but I will be surprised to learn this "migrations/models" abstraction allows the full range of foreign keys, indexes, triggers, constraints, stored procs, etc. without which we might as well just be on NoSQL... Not that there is anything wrong with that in principle, but in many situations that's not what we want.

<comment><USER21> Rails provide ruby DLS for migrations but you can always put plain SQL in that migration files. I do this most of the time and the Rails conveniently tracks which script needs to be executed against particular database state and runs them for me.

I find myself rarely do triggers. Not because I can't. It's just more handy to do on the ActiveRecord layer having access to all my ruby code.

Indexes, indexes on PL/pgsql procedures, foreign keys and constraints – they absolutely have their place in Rails applications.

Although you could do a rather complicated SELECT's with ActiveRecord, sometimes, for particular queries, I prefer to create a database VIEW and then point the ActiveRecord model to it.

<comment><USER22> > Although you could do a rather complicated SELECT's with ActiveRecord, > sometimes, for particular queries, I prefer to create a database VIEW and > then point the ActiveRecord model to it.

Database views + ActiveRecord are a super power.

</comment></comment></comment></comment></comment><comment><USER23> What I want is a doctrine that gives an ideal approach for data management, similar to how 12 factor gives an ideal approach for overall application architecture management. Data architecture, even though it's a subfield of application architecture, is important and vulnerable enough to need it's own doctrine.

What I like about 12 factor is that you don't have to get it all done at once. The concepts start high level and you can dive into the details as they become necessary. Initially, you can get by with dotenv for configuration management, and slowly build out more tooling _as you need it_.

But data management seems to need a new lexicon and set of organizing principles. How do I think about the varied aspects of database design in a way that I can be reasonably sure won't bite me in the ass before I can get around to scaling it? How do I pick a database, what are the relevant decision criteria? At what point do you want to introduce different kinds of databases, like say a graph database or ElasticSearch?

<comment><USER24> Undoubtedly, Designing Data-Intensive Applications is a great place to start: [https://dataintensive.net/](https://dataintensive.net/)

It's not as purely distilled as the 12 factor app by any means, but amongst all the details about B trees and such, a number of very solid principles around storing data creep out.

<comment><USER23> Looks great, thanks!

</comment></comment></comment><comment><USER25> Jooq has become my favorite ORM with how bare metal it is. I have it set up in gitlab pipelines to auto build my schema into an ORM. Just kick build on a sql change, and then inherit the new package.

I saw an ancillary remark about prod connections, being bad. I generally agree. I usually build mine off of my staging environment. Assuming a staging database schema, was promoted to production. Then I have a sister build job, that kicks off my jooq build, trigger on the promotion task.

The biggest thing is the professional license for several databases. But it's not that bad really.

It also goes to one of my thoughts as well. The data model is crucial to the application. This is like the foundation for your home. I always try and hammer in talk about the data model first. Where did it come from, where next, and finally where do you want it to go.

<comment><USER26> If JOOQ is anything like LINQ-to-SQL (and it certainly looks inspired by it), then it isn't an ORM. It's a typed query language with a one-to-one mapping to SQL database tables/views. This gives us the low-level control of SQL, but with the ability to build our own abstractions and compositions using the host language. ORM's are frameworks (bad), JOOQ is a library (good).

<comment><USER25> You're exactly right it's very reminiscent of LINQ. It's pretty much raw sql exposed as methods. I just say ORM, because saying near bare metal sql. Bothers a lot of developers.

</comment></comment></comment><comment><USER27> Sometimes, I get the feeling that we're all in the story of the "blind ones and the matter of the elephant". Design UI first? Design data model first? Design code first? Write documentation first? Write tests first?

How many things can we actually do "first"? All of them are important. Writing documentation tells you about what you might need implemented. So does designing UI, but that might still leave out what users need. Which means we probably don't know enough about the data model anyway. Or the code.

So ... here is one more blind person's view - iterate as quickly as you can on everything.

</comment><comment><USER28> I'm not sure that the statement "All generated DDL is only an approximation of that." is necessarily correct and is database engine/server-dependent.

It's typically pretty easy to reverse-engineer the production database schema, including any vendor-specific extensions, into a SQL file that can be used to recreate an empty version of the same database schema. Furthermore, it's just as simple with most database engines/servers to use an automated tool to compare two schemas and generate a DDL script that will upgrade the old schema to the new schema. It helps immensely because such tools will avoid circular dependencies with foreign keys, etc. that may trip you up if you're trying to manually write such upgrades.

Other than that, this article is spot-on. The database should be the source of all truth and yes, you need to become proficient in SQL to be a good general application developer.

</comment><comment><USER29> I know in the HN comments they'll be a whole bunch of "you don't do design when you're trying to iterate fast". I wholly disagree. Design phases expose problems in your thinking that you'll be tripping over very shortly, except now you didn't waste the time implementing something that wouldn't work anyway. Skipping the design phase is "productivity theater", where it appears you're being productive because code is being written, but in reality, you're just being busy.

</comment><comment><USER30> The database really is an API, in that client code depends on it and its structure will be difficult to change once you go live, whether you want that to be true or not. Writing the API before code that depends on it seems like an inherently good idea to me.

You can pretend like you don't need to figure these things out first and get away with it for a while, but at some point the lack of a solid foundation is going to bite you.

I think all devs should answer the question, "What if they don't want to use my UI or interface, or they want to automate something?" That's a good scenario to support for any client, including yourself.

<comment><USER31> I think it's really interesting that I find this insightful:

> The database really is an API, in that client code depends on it and its > structure will be difficult to change once you go live, whether you want > that to be true or not.

And then have a different conclusion than this:

> Writing the API before code that depends on it seems like an inherently good > idea to me.

I'd guess it comes down to differences about the value of top-down and bottom- up approaches to systems.

My experience is that top-down thinking usually is a better guide to creating the API you actually want to call -- writing the API calls you wish you had in the flow of the code, and then making them real.

But then again, that's application-specific context, and may not lead one to answer the question "What if they don't want to use my UI or interface, or they want to automate something?"

</comment></comment><comment><USER32> Perhaps I am too new to back-end development, but what strikes me in this article is the misconception that code-first is going to give you a bad DB schema, and that migrations will loose data.

I think part of it could be blamed on the tools: from the code I see, the ORM doesn't seem well-built, if it needs that much code to generate a proper DB schema.

For the record, I'm using Django (for about a year, I was developping apps before), and my workflow is:

1) code, while thinking about what the DB schema will be as a result

2) generate the migrations

3) apply them and check if what's generated is good and usable when you need to directly query the database (mostly for dev purpose). If need be, either change your code, or even manually modify the migrations. Migrations are code too, they are there to be overriden when required.

Sure, your rollbacks can loose data, but only if you don't pay attention to them and don't change them to avoid that. As a developer, it's your responsibility to think about that if it's of critical importance to your business.

Feel free to enlighten me if something I say seems very wrong, after all I'm still quite junior at this, and have not experienced huge scales / large team.

</comment><comment><USER33> The article seems to advocate generating code from a live connection to the production database.

This seems very risky. Typically you don't want developers to even have access to the production database most of the time, let alone make it a hard dependency to do a build. Development work should be done using temporary databases.

Also, database schema migrations need to be tested somewhere other than the prod database before going live. All the code changes needed (including to applications) should be written and tested _before_ actually doing the migration.

But this approach would be reasonable with a bit of indirection: one developer (DBA?) makes a database schema change, resulting in a change to a schema file that's checked in (after testing), and code gets generated from the schema file. That way developers all have access to a history of the prod database schema, without access to the database itself.

(This is pretty close to how things are done using protocol buffers.)

<comment><USER34> I don't think anyone advocates for generating based on a production database connection. I can only tell you how I've used jOOQ, using the same general setup for 6 years despite job changes. I wrote the original Gradle plugins for jOOQ and Flyway, the latter being a migration tool. These were then contributed back and I use the official variants now.

I write SQL migrations for H2, an in-memory db. This is used by the build tool to code generate prior to compilation. It is also used by unit tests, when the Postgres queries can be emulated (majority of the time). The Postgres migrations are written separately, with similar code but minor dialect differences. That might be less duplicated (but trivial) work if I used LiquiBase instead of Flyway. When the application starts the migrations are run. Someday I might drop H2 for a containerized Postgres, especially if they add in-memory support for faster testing. This would avoid some codegen differences, like jsonb or (soon to be released) enum support.

The work setting things up wasn't too bad. It was more when I originally started, since I had to build part of the ecosystem. But repeating the process elsewhere has been straightforward. It definitely pays off and is a joy to use day to day.

</comment></comment><comment><USER35> Fantastic.

There's an earlier article from the same blog that addresses this at a deep level

[https://blog.jooq.org/2014/01/02/why-your-data-will- outlast-...](https://blog.jooq.org/2014/01/02/why-your-data-will-outlast-your- sexy-new-technology/)

A couple of fundamental principles here: Systems tend to outlast their developers Data tends to outlast the systems operating on it

This is why I'd almost always go with database first design.

As a general rule (and test), a well designed database is useful outside of the context of the application that accesses it for persistence.

As an example from the kind of apps I've worked on: suppose you are writing a system for tracking and managing inventory, which will be used through a web interface. If you have direct access to the database, can you get useful information about orders, lead times, existing inventory levels, and so forth? If not, you don't have a useful database, and you are at risk. Migrating to a new system, which is probably inevitable down the road, will be very difficult as you no longer have control over your data.

Now, apps are useful, and code is useful. I wouldn't want to try to code up various supply chain management algorithms in SQL directly. The estimated lead time can be quite a calculation, and yeah, you are probably going to want to write python or ruby or java code to do that. But in the ruby world (with rails in particular), I have noticed databases used almost as a kind of object serialization and persistence, where the information makes almost no sense and can't be queried in any meaningful manner through the DB. It is simply used to store and retrieve information that needs to be drawn into and reassembled through various bits of code and configuration files in a rails app before it takes a form that makes any sense.

In short, the database has no meaning, almost, outside the rails app.

Now, I'm not saying this to knock rails. I've used it, and I enjoyed the experience. Metaprogramming, in fact, makes it very easy to map an object to a database table without a ton of irritating configuration or extra code. You don't have to generate your schema through rails to map models to tables, you can create them independently of the app and use rails to do the mapping for you. Also, it's entirely possible to use rails generators to create a very sensible database design. The problem is probably that a lot of people using these generators never considered databases or SQL or schemas as something that had meaning outside the context of a rails app. My guess is that this anti-pattern happens in almost all frameworks that allow developers to quickly push objects with relationships off into a database schema that they never took the time to consider or design. It's almost no different than if they serialized the objects for persistence, and used a hash to find and retrieve them.

I also think this emphasizes why clarity is so important in code and database design. Sometimes people talk about upgrading an existing code base, and say "well, it's already written in [java/ruby/python/...] , so it'll be easier if we stick with a [java/ruby/python/...] based framework". Nah. If the code lacks clarity, it'll be hell to port it from python to python. If it has clarity, it won't be hell to port it from python to ruby.

If you can use your database to answer meaningful questions about your data outside the context of an app, your database is not only useful, it also probably has clarity of design and purpose. If you can easily read your code and know what it is intended to do and why, you have clarity.

I'm amazed with how often developers are willing to sacrifice clarity to meet the demands of a testing framework, or a particular architecture, or to accommodate a cutting edge UI/javascript approach. These can be good things, but you _know_ that shit ain't lasting, and then, without clarity, where will you be?

Well, we all know, the developer who gained experience with the nifty new framework will be: at a new, better paid job.

Beyond that... eh, I suppose a code generator from a database can be useful and save you some typing, but if it's all cluttered and clunky and lacks clarity I'd rather just do it myself. It's not really that hard.

</comment><comment><USER36> Really great post. Code generation is seen by many as old school, but this post shows it's still well alive. We are seeing a revival of code generation with tools like jooq, Protocol Buffers, static website generator, and some Go tools for example.

</comment><comment><USER37> There are some who say that architectures that are able to postpone choice of front end and DB are flexible and well designed.

You should design your app to make it desktop _or_ web... and choose any DB you want.

</comment><comment><USER38> My favorite version of this, is when a new version of something is greenlit by the business, and a bunch of enthusiastic devs look at the old system and decide to rewrite. Instead of starting with the existing data, and determining how it's going to fit in the new design, they just make a new design and figure, "we accounted for most business requirements, so the data should be able to fit...". Then they set a launch date with the business, and just need to do that data migration. What could go wrong?

</comment><comment><USER39> This goes with any system. Get the data pipelines hot then drive in the business logic. Otherwise you are surprised with latency and have to do major refactors.</comment>


A New Ergonomic Mechanical Keyboard – Protect Your Hands with the ErgoPro - <AUTHOR> http://matias.ca/ergopro/pc/

<comment><AUTHOR> In case anyone has doubts about my motivations, I just want to state that I'm not an employee of the company that makes the keyboard and I don't get a cut of the sales or anything. I'm just a satisfied customer who's spent a long time looking for the right ergonomic keyboard for software developers.</comment>


Google Search Is Down - <AUTHOR> https://www.google.com/ <comment><AUTHOR> At least for me:

      Hmm. We're having trouble finding that site.
      We can't connect to the server at www.google.com.

</comment><comment><USER2> Not for me. Working in India and over VPN in Australia.

</comment><comment><USER3> Not for me. (Berlin, Germany)

<comment><AUTHOR> Google.de works for me in Zürich, but google.com is not responding</comment></comment>


The Impending Demise of the University - <AUTHOR> http://edge.org/3rd_culture/tapscott09/tapscott09_index.html

<comment><USER3> Most universities make a large part of their money through research - <USER2> money will always be there so I don't see colleges ever going away.

What about the value of the diploma? Sure, I could code out of high school. But now employers can see my resume, my GPA, and my college achievements and get a fair idea about my abilities. Unless there is a great innovator that can provide a great testing/grading service for topics covered by traditional university classes today, there is no way that the university system will start faltering.

<comment><USER4> _But now employers can see my resume, my GPA, and my college achievements and get a fair idea about my abilities._

None of that has any correlation to productivity as a commercial programmer.

</comment></comment><comment><USER5> >But a credential and even the prestige of a university is rooted in its effectiveness as a learning institution. If these institutions are shown to be inferior learning environments to other alternatives their capacity to credential will surely diminish.

I think the author is blissfully unaware of the fact that universities are often judged (from the outside) on their effectiveness not as "learning institutions," but as markers of belonging to a particular social stratum.

The existence of anachronisms such as "legacy admissions" seems to merit this view.

[http://www.boston.com/news/globe/editorial_opinion/oped/arti...](http://www.boston.com/news/globe/editorial_opinion/oped/articles/2007/09/28/at_the_elite_colleges___dim_white_kids?mode=PF)

</comment><comment><USER6> Universities aren't going to disappear completely. The strong ones will survive through adaptation - witness Stanford and MIT vis-a-vis online courses. The stodgy, bureaucratic, state-supported universities risk becoming the do-do birds of higher learning. Current fiscal stressors may be the thing that drives the weaker universities into extinction.

</comment><comment><USER7> We could be even more confident about this if universities were not so thoroughly funded, controlled, and supported by the government. If they weren't, then sure, better methods of education could easily replace them. But the government will continue to invest large sums of money to prop up the existing university system. We can hope they fail.

</comment><comment><USER8> university won't go away if govt joins in further in cooperative exploitation, like requiring degree/certificate to do something

like, what if the average mom is required to have a degree just to cook regular food? because otherwise she's unqualified and can 'danger' her family

altho it seems that certification is required for lucrative professions (we prolly won't see degree is required for cooking, gardening, plumbing, etc) ... to protect the incumbent

anyway, we won't see law and medical schools going away if the artificial limits, exams, certifications still exist (those further making these fields harder to enter -> more lucrative)

like it or not, education (and religion) is a form of social control.

</comment><comment><USER9> College is valuable as hacker incubation period, even if a degree is not attained. You have a lot of time to hack on a lot of things, hopefully without worrying about rent quite so much (be it through parental or federal/stage aid/loans).

</comment><comment><USER10> For this hacker crowd (in general), the ROI of a university education isn't fulfilling the promise proclaimed on my former high school walls, that college grads will make 1 million more in their life time than non-grads.

That being said, I can't wait to start college next year. For learning to be independent, for networking, for taking courses like Accounting I and II.

That being said, I am going to college starting next year but for 2 years I have been watching podcasts through iTunes U. Learning economics from berkeley, CS from Stanford. Thanks to the web, my professors are not limited to my university. :P

</comment><comment><USER11> You know, the original idea of a university was to research stuff in three areas that weren't covered by other institutions of society at that time: philosophy, medicine, law.

What about that?

<comment><USER12> Don't forget theology. Otherwise, point well taken.

</comment></comment><comment><USER13> Couldn't agree more with this article. For a more rich analysis, I'd recommend checking out Disrupting Class by Christensen and Horn. All about how disruption is going to transform education.

We are working on a startup that hopes to facilitate this wave. If you are interested in helping us beta test, then please sign up at www.nixty.com. Thanks!

<comment><USER14> Months ago (or was it years), there was a similar article on here. You (or someone else from your startup) suggested the same thing. I signed up. Even though watching your video or reading your blog doesn't tell me what you do at all.

Now looking back, no mail in that time. No blog posts for a year. In other words: You don't call! You don't write!

What's the point of encouraging signups?</comment></comment>


Kotlin 1.3 RC is here - <AUTHOR> https://blog.jetbrains.com/kotlin/2018/09/kotlin-1-3-rc-is-here-migrate-your-coroutines/ <comment><USER2> I wish they did enforce the official code style in a similar way to go.

</comment><comment><USER3> Has anyone written a web application with Kotlin? Can you share your experience?</comment>


Atlassian: Our bold new brand - <AUTHOR> https://www.atlassian.com/blog/announcements/our-bold-new-brand <comment><USER2> Most Atlassian users are not thier customers. Their users' employers are the customer. This appeals to the customer who doesn't actually have to use this stuff. "ooh pretty".

Those of us stuck with Atlassian refusing to fix their garbage, differing markdown syntaxes, removal of stratight text in favour of rich gui brokeness and the unrelenting S L O W...

Yeah we won't be so impressed by it.

Fix your junk. I can't threaten to leave - the choice isn't mine to do so. The only choice I have is to complain in public. Just like the public service. Go Atlassian! Hooray! User hatred achievement unlocked!

<comment><USER3> Complain all you want.

But I have clients who force the use of Sharepoint, and emails for team collaboration.

Coming over to a client with atlassian stack on premise or in the cloud, is like a peachy holiday in comparison. /anecdote.

/question At massive [project] scale; what would you rather recommend to use than Jira and Confluence for the project lifecycle, functional collaboration, technical collaboration, development, CI, and CD?

<comment><USER4> For my startup I found gitlab to be a massive help from managing our repos to CI integration and task management

</comment></comment></comment><comment><USER5> I really like how they've tried to come up with a consistent design for each product logo.

Unfortunately, I feel the 'A' isn't as unique as the original Atlas holding the world The 'A' is much more generic. The curve, fairly subtle at small sizes.

I'm not a designer, how do designers feel about this? Am I looking at it wrong?

<comment><USER6> As a would-be designer turned developer I'd say their old icons were good enough. IMO colors and logotype consistency are probably more important.

Soaking of text... maybe consistent defaults for markup among products would more appreciated than anything.

</comment></comment><comment><USER7> >" Like us, you may notice important symbolism around teams in the new Atlassian logo – two people high-fiving, a mountain ready for teams to scale, or even the letter A formed from two pillars reinforcing each other."

Oh god, really? _really_?

<comment><USER8> Yes. These people are so far removed from the actual products they create that you get this type of drivel. I can't imagine how much time was wasted with all this.

</comment></comment><comment><USER9> New Atlassian logo is better than the old logo. Old one always looked more like an unimportant decorative element than logo.

I totally agree about the hate on rich markup replacing plaintext, though. Entirely counterproductive and stinks of excess engineers syndrome.

</comment><comment><USER10> Their new logo screams airline to me - I can only see it on the side of an aircraft.

</comment><comment><USER11> Is it just me, or do other people have a sort-of branding/design language fatigue now?

I simply could not give a shit about the thought processes behind a company's branding any more, but 5 years ago it was very interesting.

<comment><USER8> You grew up and realized it barely matters.

</comment></comment><comment><USER12> Discussion from earlier today (16 comments):

[https://news.ycombinator.com/item?id=15219658](https://news.ycombinator.com/item?id=15219658)

</comment><comment><USER13> I was ready to take shit on their rebranding effort as unnecessary waste, but I have to say the new product logos are nicely done.

I would've kept the old Atlassian logo however.

</comment><comment><USER14> I love Atlassian stack. Yes, the UI of JIRA is slightly clumsy and overwhelmed and slow but the integration between BitBucket, Jira, Bamboo and Hipchat(and soon Stride) is the fantastic feature. I also enjoy SourceTree, that's amazing Git client, very convenient. I can't wait until Atlassian releases the IDE so that I give up VS Code. And I am not high as many might think.

</comment><comment><USER15> Not a designer, but I pretend to be one sometimes... One thing I've always read is to avoid relying on gradients in logos.

</comment><comment><USER16> Thus continuing the tradition of taking easily recognized icons and replacing them with blue blobs that are barely distinguishable from their neighbors. Why is everything blue! OMG WHY! A hundred blue icons and you have to find the one you are looking for....

</comment><comment><USER17> Trello's logo is inconsistent with the rest.

</comment><comment><USER18> I see a pinched finger and thumb</comment>


Ask HN: node kills your Macbook battery and AppleCare doesn't cover it? - <AUTHOR>

My Macbook Air is 6 months old, and I've been noticing that it no longer has its killer 7hr battery life like it used to.<p>I took it to the Apple Store Genius Bar and they ran the battery diagnostic program. The battery only holds 85% of its charge now, but all cells are in working order.
When the Genius asked me to load up my apps I use everyday, I loaded Terminal, booted my node server and Sublime Text 2.
When he checked Activity monitor the Genius immediately pointed out that the node process was consistently hammering 30% of one of the i7 cores.
As most developers must do, I run the little node server for 18hrs a day. He said, 'consistently hammering the core at 30% is killing your battery'.
To which I said, 'ok, but I have Apple Care etc...' and he explained that Apple Care does not cover this type of "battery depletion", it only covers "battery failure" when one of the battery cells malfunctions. A new battery is £100.
Has anyone else had this same experience? What to do? <comment><USER2> Apple Care, as far as I can tell, is just an extended warrantee and support contract. Why should they replace hardware that is acting as expected? That's how galvanic cells work, get used to it.

</comment><comment><USER3> Take it to another store and just say you browse facebook all day and you don't know why the battery's deteriorating.</comment>


Nancy Pelosi urges FCC to reclassify broadband as a utility - <AUTHOR> http://www.theverge.com/2014/9/8/6123801/pelosi-urges-title-ii-classification-of-broadband

<comment><USER2> This is the ONLY solution.

But like health care I suspect there is going to be a horrifying compromise.</comment>


Spock: small powerful Haskell web framework - <AUTHOR> https://github.com/agrafix/Spock

<comment><USER2> This name is also used for a Chicken Scheme to Javascript compiler.

[http://wiki.call-cc.org/eggref/4/spock](http://wiki.call- cc.org/eggref/4/spock)</comment>


Google Cloud Platform Is Down - <AUTHOR> https://console.cloud.google.com <comment><USER2> Title should be changed to "Google Cloud Console is down". Still a big pain...

The status has been updated here: [https://status.cloud.google.com/incident/developers- console/...](https://status.cloud.google.com/incident/developers- console/19001)

</comment><comment><USER3> Web console shows 500s, mobile app still seems to be working, CLI is working.

Seems the cloud console is down, but Google cloud is not down. All my stuff is still running and responding

</comment><comment><USER4> I am having some weird issues trying to switch my account user, but I can access the console home page.

<comment><USER4> Ok. Nope. I finally switched my google user, and I'm getting errors messages when I try to access my VM list.

<comment><USER5> Same here, made a print screen of the error message

> [https://imgur.com/a/mxgqTXH](https://imgur.com/a/mxgqTXH)

It says

> There's a problem at our end.

> Please try again. If the problem persists, please let us know using the > "Send Feedback" link below. Thanks!

</comment></comment></comment><comment><USER6> works fine for me</comment>


Spelunky Level Generator Lessons (2013) - <AUTHOR> http://tinysubversions.com/spelunkyGen/ <comment><USER2> As a few other people and the page noted, it only works in Chrome. For Firefox, it fails when it tries to use chrome.storage. That doesn't even work in Chrome, as it's an API that can only be accessed by extensions. However, in Chrome, the chrome object is defined, so accessing chrome.storage just returns undefined instead of throwing.

It's kind of weird that it's using that when it could just use localStorage.

</comment><comment><USER3> I came across a video yesterday about how Dead Cells uses a similar generation method (random composition of pre-designed tiles), as well as some other interesting UX hacks: [https://www.youtube.com/watch?v=Uv5NwboDDhk](https://www.youtube.com/watch?v=Uv5NwboDDhk)

<comment><USER4> I love Dead Cells as a game (slick combat, great graphics and atmosphere, etc.), but it's levels are one of the weak design points IMHO. They are nowhere near as fun and interesting as Spelunky's. Dead Cells levels are just simple tree-like structure that branch out and have a bunch of random rooms placed alongside the branch. It even has errors where you get two checkpoints so close, they can fit on one screen. The only exception is level 5 where you have teleport doors that add some interconnections, but the rest of the game levels are meh. You start going down a side path and you know it's a dead-end every single time.

</comment></comment><comment><USER5> I wish I could do more than leave a comment that sounds like a complaint, but in case it's helpful: I get a black screen on iOS.

I might dig into the reason why it's failing when I get home. Whatever its doing should at least render on mobile without extra dev effort. Curious...

<comment><USER6> Works ok for me, maybe it was a load issue?

Edit: Oh, the live demo doesn't work. I thought you meant the whole page was black, which sadly is apparently an option these days.

</comment></comment><comment><USER7> Looks like Derek Yu is hard at work on Spelunky 2, though no release data yet

Spelunky is like the Gold Standard of ProcGen in GameDev. It just works. Trying to apply the same techniques to Super Mario Bros might not. "Instant Death" and randomized exploration rewards seem to be key. This is a game that is probably impossible for an AI to master

[http://pcg.wikidot.com/pcg-games:spelunky](http://pcg.wikidot.com/pcg- games:spelunky)

OpenAI also recently released a ProcGen Benchmark that conceivably is used to explore generalizability in learning agents. A few of the modes look like they were Spelunky-inspired ;)

[https://openai.com/blog/procgen-benchmark/](https://openai.com/blog/procgen- benchmark/)

<comment><USER8> _" Instant Death" and randomized exploration rewards seem to be key._

Usually called permanent death or permadeath. These two happen to be the defining traits of the Roguelike genre. They're the two highest value factors of the _Berlin Interpretation_ [1].

[1] [http://www.roguebasin.com/index.php?title=Berlin_Interpretat...](http://www.roguebasin.com/index.php?title=Berlin_Interpretation)

 _Note that all of the other factors have been violated by one Roguelike or another, so I would take them with a grain of salt._

</comment></comment><comment><USER9> The depths of Spelunky hacking go super deep. See here for a lot more: [http://sashavol.com/frozlunky/](http://sashavol.com/frozlunky/)

</comment><comment><USER10> Discussed at the time: [https://news.ycombinator.com/item?id=6866310](https://news.ycombinator.com/item?id=6866310)

</comment><comment><USER11> If you like Spelunky, check out Catacomb Kids. It's similar in many ways, but has fundamental differences such as no terrain destruction (by design). Check out youtube videos to see if it's for you. It's harder than Spelunky.

Caution: it's having trouble getting out of Early Access. Only two stages are complete, third is on the way and a patch comes out every month or two.

</comment><comment><USER12> This is pretty cool. It shows you how spelunky procedurally generates levels and ensures they can be completed by the player.

Unfortunately, it only works in Chrome.</comment>


The World of Liquid Crystal Displays (2006) - <AUTHOR> http://www.personal.kent.edu/~mgu/LCD/home.htm <comment><USER2> I know it's an introduction, but it misses a lot of the interesting points that are actually important even for people just buying LCDs --- like how intensity gradation is achieved (FRC/temporal dithering vs. pure DAC) and why inversion/AC driving signals are necessary, and how they can contribute to flicker and odd artifacts when displaying certain patterns.

Those wishing to know may find the answers in here:

[http://web.nchu.edu.tw/pweb/users/fansen_wang/lesson/7043.pd...](http://web.nchu.edu.tw/pweb/users/fansen_wang/lesson/7043.pdf)

[http://www.techmind.org/lcd/](http://www.techmind.org/lcd/)

[http://www.solomon- systech.com/files/ck/files/Application%20...](http://www.solomon- systech.com/files/ck/files/Application%20Notes/TFT%20Flickering%20Application%20Note_1.1.pdf)

In my experience, panel and driver IC manufacturers seem to give the best explanations of the technology, and it's often quite readable even for someone without experience with LCDs.

<comment><AUTHOR> These are great! I'm actually diametrically opposed to expert status in this area.

I came across this trying to figure out how these work: [https://www.youtube.com/watch?v=CJvNEzCaNwg](https://www.youtube.com/watch?v=CJvNEzCaNwg)

to try to answer some questions: a) How hard could it be to do a DIY version vs buying one? b) Why don't they produce larger (blackboard-sized) versions of this tablet i.e. for school settings? c) Downsides? How much do these really last?

<comment><USER2> Internal examination of a slightly different model: [https://www.youtube.com/watch?v=Qgt1b81DJEw](https://www.youtube.com/watch?v=Qgt1b81DJEw)

</comment></comment></comment><comment><USER3> I assume transflective displays hit a limit on density and color reproduction. But I really wish they hadn't. A tablet would be perfectly readable indoors and outdoors with it. My Dell Axim was great in sunlight and still had a backlight for indoors.

</comment><comment><USER4> This probably needs a [2006] in the title.

<comment><USER5> That explains the web design as well.

<comment><USER6> you mean how it loaded instantaneously?</comment></comment></comment>


Why does the SEC prosecute companies instead of people? - <AUTHOR> http://www.thebigmoney.com/articles/explainer/2009/09/22/ghosts-market-machine

<comment><USER2> You're assuming they prosecute at all. They're quite inept at their job given the amount of funding that is poured into the organization.

Example: Perot Systems gets bought out Monday by Dell. The week prior we see 2500 calls bought at the offer for $1, and on Monday they traded at 9.60. Do note that the calls were an unusual volume anomaly in the name.

This trade data will most likely be looked over by the SEC.

<comment><USER3> I'm guessing the SEC is both underfunded && following political direction. They may have needed more funding to go after all the potential illicit trading the last 10 years or so, but it seems they could have gone after more than they did. I find it very interesting the SEC did not touch Madoff until the end of 2008 when there seem to be strong warnings several years earlier.

</comment></comment><comment><USER4> Prosecuting individuals would be a step in the right direction. As long as an enterprise is successful, the leaders take full credit and get a shitload of bonuses, justified by the tremendous amount of responsibility.

As soon as everything goes downhill, they return to being employees, cashing out a nice severance on their way to the next gig...

edit: Core problem remains the personalization of success along with the socialization of failure.

<comment><USER5> maybe. but also consider that if the SEC can go after 2 or 3 times as many companies, it may have a bigger deterrent effect, via extra publicity.

<comment><AUTHOR> The problem with going after companies and not people is that it doesn't necessarily act as a future deterrent since these people aren't the ones paying for the penalties anyway - it's the companies. So there's that agency problem that the interests of managers are different than that of shareholders (the risks for the managers may be much lower than the potential reward).

Further, as in the case now of some of these prosecutions that are negotiated against companies (as Spitzer arguably did with AIG), the appearance is also that it amounts to extortion. The simple act of threatening to charge a company making it more difficult to do business, may be enough to "settle" to provide some prosecutor with publicity for a future gubernatorial run.

</comment></comment></comment><comment><USER6> They do!

I used to work for a very small NASDAQ-traded company headed by a bunch of scumbags. Actually, just _one_ scumbag: as far as I could tell the rest of them only stuck around because they wanted their investment back. A few years after I left, I found out that the company was being sued by the SEC, and specific officers _and family members_ were ordered to disgorge illegally retained profits. SEC even ordered that the accounting firm that produced the annual/quarterly reports be prohibited from ever representing a public corporation again!

I laughed my ass off for days!!!

It may be rare, but in extreme cases of fraud, they will investigate and prosecute. I just wish I knew who among their pissed-off shareholders pulled enough strings to make it happen.</comment>


10 Year Old Entrepreneur Launches Sushimee at Startup Weekend - <AUTHOR> http://sushimee.com How many 10 year olds do you know who would attend a Startup Weekend? We need more kids doing things like this. <comment><AUTHOR> We need more kids doing things like this. So cool to see self-motivated, young entrepreneurs, starting things.</comment>


WannaCrypt ransomware has resumed spreading - <AUTHOR> https://motherboard.vice.com/en_us/article/round-two-wannacry-ransomware-that-struck-the-globe-is-back <comment><USER2> There seems to be a lot of confusion about versions without killswitches. This guy says he made a mistake: [https://twitter.com/craiu/status/863718940870139904](https://twitter.com/craiu/status/863718940870139904)

<comment><USER3> Interesting for context:

[https://twitter.com/marksteward/status/863747839117201409](https://twitter.com/marksteward/status/863747839117201409)

New domains are just trivial modifications of the old one. Still hardcoded. That's unlikely to be a new version, but rather people playing around.

</comment></comment><comment><USER4> This guy just found a new kill switch and registered the domain already:

[https://twitter.com/msuiche](https://twitter.com/msuiche)

He's talking about versions with nop'ed kill switches.

EDIT: not nop, but with a jnz +2, still similar to a nop-nop.

</comment><comment><USER5> Was only a matter of time. What's it doing to detect anti-virus sandboxing now, if that was the original purpose of the fixed domain?</comment>


"The financial services industry is the most influential political force" - <AUTHOR> http://thenextwavefutures.wordpress.com/2009/12/07/banksters-1/ <comment><AUTHOR> Relevant for hackers because it argues that political choices have incentivised "too-big-to-fail" unsuccessful companies rather than market-led innovation. The discussion is UK-centric, but refers to (and seems relevant for) the US as well.</comment>


Steve Jobs – The Movie - <AUTHOR> http://www.stevejobsthefilm.com/

<comment><USER2> They couldn't find someone that looked a little bit more like Steve Jobs?</comment>


Paul Allen just rolled out the world's largest airplane - <AUTHOR> https://www.washingtonpost.com/news/the-switch/wp/2017/05/31/paul-allen-just-rolled-out-the-worlds-largest-airplane-and-he-ready-to-take-on-the-rocket-makers/ <comment><AUTHOR> Title edited for space.</comment>


Show HN: I've built an ATS that reduces unqualified applications - <AUTHOR> https://www.mropus.com <comment><AUTHOR> Hi guys, I've developed Mr. Opus in the last few years (with big breaks in between) but I feel it's now in a good place to see the world.

Features:

\- smart job requirements that include work experience based on field, education qualifications, languages spoken and country of residence. If the applicant doesn't meet one, he can't apply.

\- digital profiles so you won't have to deal with CVs anymore

There's quite a few features I want to add in the future but for the time being, give it a try and let me know what you think! The first job opening is free.</comment>


The Most Important New Technology Since the Smart Phone Arrives December 2012 - <AUTHOR> http://www.technologyreview.com/view/428350/the-most-important-new-technology-since-the-smart/ <comment><USER3> This is the Leap Motion for the folks that don't want to click through - <USER2> I don't recommend.

Disclaimer: I have one on order.

The hype machine that Leap is unleashing is astronomical. Every day I read new journalists that say this is the most amazing technology ever. Leap has been constantly Tweeting about new jobs - designers, coders, managers, lawyers?!?

There is NO way that they can a) sustain this hype or b) pay for it.

Hope I get mine before they a) go out of business or b) get purchased by Google or Microsoft and left to rot on the vine.

</comment><comment><USER4> Bah... I'll wait until Apple invents this technology about five years from now. I never buy non-apple product or technologies because I'm creative.

<comment><USER3> Real artist ship (Apple). Fake artists announce early (Google, Microsoft, Dell, HP, Samsung and LEAP).

<comment><USER4> Heh... fanboy much ?

</comment></comment></comment><comment><USER5> most important will be Google Glass

this one is merely on the Kinect level

<comment><USER6> I haven't seen a Leap Motion in person, but if the demos are accurate then it is to Kinect what multi-touch capacitive touchscreens were to single-touch resistive touchscreens. That is potentially a pretty huge deal.</comment></comment>


Live WWDC Photo Wall - <AUTHOR> http://slidechute.com/w/757

<comment><USER2> I wrote an Instagram #wwdc wall last year while waiting in the WWDC line (5hours of waiting used in a meaningful way). The result is was InstaWWDC, still online and working

<http://instawwdc.appspot.com/>

</comment><comment><USER3> Really cool implementation, but goes on to show how noisy twitter data can be. Quite a lot of repetition, spam and irrelevant photos.

<comment><AUTHOR> Agreed. The next version we're working on will be able to suppress RTs and other stuff.

</comment></comment><comment><USER4> This is really cool. I wish that links within the tweets were clickable, but that's a minor gripe.

<comment><AUTHOR> Good idea.. we need to find those and activate them</comment></comment>


Obama Gives Keynes His First Real-World Test - <AUTHOR> http://www.npr.org/templates/story/story.php?storyId=100018973&ft=1&f=1001

<comment><USER2> One point about Keynes theory that if I remember correctly goes something like spend in bad times _cut back_ in good times.

Keynes is overused much like prescription antibiotics.

"Prescribing Keynesianism to some politicians is like prescribing crack to a coke addict. In the 1970s, the patient hit rock bottom. The U.S. had high unemployment, and the Keynesian solution stopped working. The national government spent and spent, but unemployment only got worse. Then came inflation, something Keynesians had no answer for."

The problem is we have been borrowing and spending like crazy both publicly and privately. We've had the accelerator pushed to the floor, how do we go faster now?

Keynes (again as I remember) recommended these fixes for short term problems. Our problem is systematic over spending.

Obama et al. are prescribing aspirin because they believe the patient has a hangover, when the country really needs chemotherapy for debt cancer.

The bad debt that has accumulated needs to be accounted for, losses have to be taken, companies need to go into bankruptcy (which is often reorganization, not necessarily going out of business.)

We can't "cheat" our way out of this with Keynes.

<comment><USER3> The article cites this as the essential feature of Keyne's theory that Obama is calling for: government spending should make up the difference between national capacity for economic output, and the current projected level of economic output.

Paraphrasing the article: the US economy has a $15 trillion capacity, but the lack of effective demand has reduced our projected output to $14 trillion. By spending $650 billion we can make up that difference in output with the help of Keynesian multipliers.

I certainly sympathize with the parent. For the last three months I canvassed for Greenpeace pushing a reinvestment in renewable energy. One gentleman whose door I knocked on was skeptical (way more than just this one guy, door-to-door canvassing amidst recession is a great job if you enjoy getting kicked in the nuggets 100 times/day). He speculated the green movement was just another attempt to sell a newly packaged bubble to the American people.

So are we foolish to pursue this short-term fix? Is the reinvestment plan fairly characterized as a short-term fix?

To the first question I can at least express the hope that this investment will leave us with something inherently useful: much needed improvements to our infrastructure. We've been riding the wave of cheap energy from the petrochemical revolution for the last 100 years (thanks Steve Jobs Playboy article) and that is certainly appearing to mainstream America as a habit to kick.

To the second question, maybe it will help to explore the long term consequences of not meeting our productive capacity. By analogy we can consider the consequences of not meeting our capacity to educate. Imagine if America lost an entire year of engineering graduates. A short fall in capacity may result in a long-term compounded drop in overall engineering output.

<comment><USER4> Completely off-topic, but for a few years now I thought Greenpeace was... how should I put it in a polite way? Too passionate to be taken seriously. I take it it's not really so?

</comment></comment></comment><comment><USER3> Given the headline I expected more of an argument about how Obama's stimulus plan is Keynesianism's first "true" test.

Really the argument amounts to this: 1\. FDR didn't really try Keynesianism until he was forced to during WWII (the 30s didn't count). Too little Keynes. 2\. The whiz kids of the 60s took Keynes too seriously. 3\. The ~$650 billion Obama wants to spend follows directly from Keynes's formula. Goldilocks Keynes.

Not particularly rigorous, but the link to the "Marginal Revolution" blog might be fruitful. <http://www.marginalrevolution.com/>

<comment><USER5> Richard Nixon said, "I am a Keynesian." Obama is no better than in second place (in Keynsianism :-).

<comment><USER6> To be fair, Richard Nixon also said 'I am not a crook' and that turned out to be untrue.

<comment><USER7> Nixon was a keynesian and a statist. I'm not calling him a statist becuase of what he did in watergate. <http://en.wikipedia.org/wiki/Richard_Nixon#cite_note-66> <http://en.wikipedia.org/wiki/Richard_Nixon#cite_note-76> (moved us off of the gold standard, giving the government complete control over our currency) [http://en.wikipedia.org/wiki/Richard_Nixon#cite_note- Hetzel2...](http://en.wikipedia.org/wiki/Richard_Nixon#cite_note- Hetzel2008_p92-72) (implemented price controls on agricultural products) [http://en.wikipedia.org/wiki/Richard_Nixon#cite_note-.2770s_...](http://en.wikipedia.org/wiki/Richard_Nixon#cite_note-.2770s_180-137) (established the EPA) <http://en.wikipedia.org/wiki/Richard_Nixon#cite_note- pbs2-69> (established OSHA)

Nixon was far from what I or most people would consider a classical.

</comment></comment></comment></comment><comment><USER8> All this spending - will it not cause inflation? And considering the weakness of the dollar, will the inflation not cause further weakness? And when American goods become so cheap, considering that most manufactured goods are imported, will this not cause an exodus of capital?

I really don't know, since I have no real understand of global economics.

<comment><USER9> There's a much bigger fear of deflation rather than inflation at the moment. Also, the dollar has actually been relatively strong since the financial crisis because there's been a large increase in the demand for safer assets, ie cash and treasury bills. A weakening dollar would probably be better for the economy as goods manufactured in America would be cheaper abroad, leading to an increase in net exports.

I don't quite follow the reasoning of cheap American goods -> exodus of capital.

<comment><USER10> The problem with deflation is what is going to happen afterwards. My guess is hyperinflation. Once prices get so low, you will have a lot of people coming back into the market that have been hording dollars. Once they get back into the market you will have to many dollars chasing to few goods, since the world has slowed production.

I really agree with you. That is why deflation is scary, it will likely lead to hyper-inflation.

<comment><USER11> As far as I know, deflation cannot cause inflation. Maybe the governments response to deflation (print money!) can cause inflation, but the destruction of value and the reduction of the money supply cannot cause the overvaluation of assets or an expansion in the money supply, except through government action.

Of course, it is true that hyper-inflation, if it happens, will happen quickly. People will be, as you say, hoarding their cash because of uncertainty. But when they become confident enough to borrow from the banks again, and the large reserves they have been stockpiling hit the fan, it is quite possible that people will quickly notice the change in money supply, and react by trying to get rid of their money too. Which would set off hyper- inflation. But this hyper-inflation is not caused by deflation, but rather by inflation, which people may not notice because of their presently high hoarding rate.

</comment></comment></comment></comment><comment><USER12> The problem I have with the idea of "managing the economy" is that we might not even know what that phrase actually means. I often read "economy" and translate that as "runaway complexity." I sense this complexity in a system of such magnitude, involving so many interacting systems, and so many individual actors (many of which are computer programs at this point, I think) that it simply cannot be grasped by any single human mind, no matter the training or intelligence. This is just my sense of this; am I wrong? Someone here, please educate me.

<comment><USER13> Do you know what your neighbours want? What they like and dislike, what they want for their children, and so on?

Now, do you think a genius would know? And if he knew, would he know better than them?

You can "run the economy" (that is, rule other people) to achieve _your_ goals (e.g. if you are a pharaoh and want your own pyramid) but you just can't go against people's will to help them achieve their own goals.

<comment><USER12> I agree with you inasmuch as an economy is about people, but what if it isn't about people so much as some larger "thing" (an incomprehensible interaction of systems, perhaps?) that individuals, and even governments, have to deal/interact with? What if that's just as true for the so-called global "elites" as for the rest of us? I suspect that it is. I think that what you say about people controlling other people is accurate; I just think it's only a small percentage of the data we have to account for.

<comment><USER14> If it isn't about people, who or what could it possibly be about? What other data are you looking for? What do you think is moving the money around? The economy isn't some magical system that randomly shuffles dollar bills around, it's people and businesses buying things.

</comment></comment></comment></comment><comment><USER15> I wish him luck, but it seems like a really big gamble to me :-( Going the Keynes route seems relatively uninspired - isn't that what all governments like to do, because it gives them an excuse to spend large?

<comment><USER16> "isn't that what all governments like to do, because it gives them an excuse to spend large?"

Well, if you are talking about irresponsible governments full of bureaucratic self-serving idiots (which would be most modern governments), then yes. That is what all governments do.

</comment></comment><comment><USER17> I recommend checking out Keynes' opus The General theory of Employment Interest and Money. If it seems too daunting skip straight chapter 24 for a more general take before diving into the rest. [http://www.marxists.org/reference/subject/economics/keynes/g...](http://www.marxists.org/reference/subject/economics/keynes/general- theory/ch24.htm)

If that first sentence doesn't strike you as odd go back and re-read Mind the Gap by Paul Graham.

<comment><USER18> What do you think the fundamental flaw of capitalism is? The wording is a little odd, but capitalism by its very nature has a tendency to concentrate capital in the hands of the few.

<comment><USER17> Why is that a bad thing? Successful companies in the free market are successful because they have given people something they want for a voluntary exchange of capital. These companies turn around and develop more products that people want.

Why do you seek a flaw in capitalism? Capitalism simply means the voluntary exchange of goods and services. The alternative is non-voluntary exchange i.e. you are forced.

If you don't know why privately controlled means of production are good you have a lot of reading to do. Might I point you to the Cato Institute or Ludwig Von Mises Institute (google for free literature). Or for a more popular example check out Friedman's bestsellers.

For the ugly and fast version: Would you put up with wal-mart taking $40 from your paycheck every month and telling you that you can come get a gallon of milk every week for "free"?

first you should be free to choose whether you want milk or not and whether to support it with your money.

second you have no way of knowing if you're overpaying because you have no idea what price milk would sell for if several companies were competing for your business.

thirdly you have no recourse if the quality of the milk goes down. you can try to sue wal mart..good luck with that. You might claim that people are still free to go buy other milk, but any other company selling milk is at a huge disadvantage. People have to pay that $40 a month regardless, so most figure they might as well get the milk out of it. competitors milk could cost half of what wal-mart charges, $20 a month. But from the perspective of the citizen that "private milk" costs $60 a month since they have to pay the $40 regardless.

In this scenario wal-mart has you as a captive customer. Before it made money by convincing you to buy milk from it with high quality and a low price. Freed of having to convince you to buy it wal-mart doesn't have to care much about customer service or product quality.

This is essentially the scenario of state owned goods and services. you're assuming that the central planner can come up with a better solution than lots of entrepreneurs taking a crack at it.

<comment><USER18> My lament against capitalism doesn't propose a solution. There are no alternatives.

<comment><USER17> but people think there are. people think of things like income inequity as a flaw. it's not a bug, it's a feature. You want income allocated to those who show themselves fit to efficiently use resources to produce more things that people want. If someone is 1000 times more productive than me there is some kind of problem if they aren't making 1000 times as much money.

Going with the other issue: unemployment at least has some legs to stand on as it has been suggested that there just aren't enough low skilled jobs for all of the low skilled people to do since most low skill work has been either automated or increased in efficiency to the point where 1 person can do something 1000 used to do.

<comment><USER19> Of course there are alternatives to capitalism. Or, more accurately, there will be something that will succeed it, sometime in the future.

If history has taught anyone anything, it should be that civilizations are not static. I very seriously doubt that democracy and capitalism will be the predominant foundations of society 1,000 years in the future.

When will the "next big thing" come? I have no idea, nor does anyone else. But to say that there are no alternatives to capitalism, and to imply that there never will be, is shortsighted.

<comment><USER17> who said anything about democracy? If democracy was an efficient form of governing a large complex system you would have seen corporations adopt it and become more competitive.

like I said before, the alternative to a free exchange of goods is a forced exchange of goods. I don't see how to improve on this. capitalism isn't a system in the same way socialism is. It's just what naturally happens when violence is made less profitable than free exchange.

<comment><USER20> Every political and economic system of every kind involves both free and forced exchange of goods. For example, in a system of property rights, if a person is considered to violate someone else's property rights then they will be punished, possibly through forced appropriation of their goods.

Capitalism vs. socialism is not an example of free exchange vs. force, but of two different standards of when force is appropriate.

<comment><USER17> right, but centrally planned economies don't naturally occur in the same way that free exchange does. It is contrary to reason that if I make something and my neighbor makes something and we decide to trade that a third party _must_ be involved by law who will take a percentage of the value of the exchange. You can make the argument that by providing the legal framework that makes non-violent exchange possible (police, contract law) as well as the infrastructure that facilitated our exchange (roads) that the third party deserves a small piece.

This would be a devastating argument. _If_ I had a choice in the matter. In a free market system of courts and transportation I would pay a fee for use. This is fair. But to tithe a percentage of my productivity regardless of how much or little I make use of said system seems fraudulent.

<comment><USER20> What does it mean for a human-constructed system to be 'natural'? In most tribes of the world, the income of one person is not considered the property of that person, but is divided according to customs about the distribution of wealth in that society. Tribal communities are about as close to 'natural' behaviour as you can get, so what is unnatural about it?

I also don't understand the term 'contrary to reason'. How can a set of conventions be rational or irrational? They can be beneficial, harmful, fair, unfair, moral, immoral etc, but how can they be contrary to reason?

Also: taxation is as much a part of capitalism as it is a part of socialism, especially taxation for expenditure on police and law.

</comment></comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER21> This list of Macroeconomist opinion is interesting:

[http://www.ambrosini.us/wordpress/2009/01/political- affiliat...](http://www.ambrosini.us/wordpress/2009/01/political-affiliations- of-modern-macroeconomists/)

Seems the professional macro guys are ambivalent about the stimulus.

Of course, the only economists' views that will actually make it into policy will be the Democrat economists.

</comment><comment><USER22> Japan tried Keynesian policies. The result was the infamous lost decade: <http://www.heritage.org/research/economy/bg2222.cfm>

</comment><comment><USER23> Like all policies, you have to look at the downside risk.

IMO, the downside of a Keynesian solution is MASSIVELY larger than an chicago school type solution. You have the government taking on huge quantities of debt, no guaranteed cure for unemployment, and a risk for massive inflation..

</comment><comment><USER24> First real-world test? Look at Japan in the 1990s. How soon we forget history...and repeat it.

<comment><USER23> I don't think Japanese monetary policy in the 1990's really qualifies as Keynesian..

They had a zero % interest rate and pioneered the concept of quantitative easing, but the theory underlying the policy wasn't exactly based on being able to manage growth through government spending

<comment><USER9> from an article on japanese fiscal policy in the 90s:

"In the end, the September 1995 stimulus package did add significantly to economic growth in 1996. Not only was the actual real GDP growth of 3.6 significantly higher than the 0.9 percent recorded in 1995, it was at least 0.9 percent higher than the growth forecasted for 1996 by all of the major international institutions and the financial consensus...This stimulative effect can largely be attributed to the fiscal package, although the decline in the yen also stemmed the decline in net exports (by -1 percent of GDP in 1995 and by -0.4 percent in 1996)...There was actually no other source of positive impetus to the Japanese economy in late 1995 and early 1996 that can be identified except discretionary fiscal policy."

here's the rest: [http://www.marginalrevolution.com/marginalrevolution/2008/12...](http://www.marginalrevolution.com/marginalrevolution/2008/12/japanese- fiscal.html)

</comment></comment></comment><comment><USER25> > Organized public works, at home and abroad, may be the right cure for a > chronic tendency to a deficiency of effective demand. But they are not > capable of sufficiently rapid organisation (and above all cannot be reversed > or undone at a later date), to be the most serviceable instrument for the > prevention of the trade cycle.

-John Maynard Keynes</comment>


My one night hack: Two-way gateway between Flowdock and IRC - <AUTHOR> https://github.com/hannu/flowdock-irc

<comment><USER2> Is the password plaintext?

FLOW_TO_IRC = { "organization/flow" => "#secret password" }

<comment><AUTHOR> Yes it is, but it's a password for the IRC channel so there is no point to encrypt it. IRC operates passwords in plaintext format so you don't use your most secret password here any way.

<comment><USER3> > IRC operates passwords in plaintext format

Only if you don't have an SSL connection (which most IRC networks do support).</comment></comment></comment>


Premature optimization is the root of all evil - <AUTHOR> http://c2.com/cgi/wiki?PrematureOptimization

<comment><USER2> Premature optimization used to mean unnecessarily writing assembly or borderline obfuscated C in the name of performance, which led to programs being difficult to comprehend, hence it being the root of all evil. Today this has been perverted to mean "hey, buddy, if you think about performance you're optimizing prematurely!"

People need to learn their history before throwing out such maxims.

<comment><USER3> Perhaps misguided optimisation would be a better term, and seems to be what Knuth is driving at. People do spend a lot of time worrying about all the wrong things, many of which a decent optimising compiler will take care of.

Efficient code should always be on your mind, but actual optimisation probably ought to be done with the aid of a profiler rather than a hunch a 'clever' way of doing something.

<comment><USER4> Agreed - I've seen cases where someone obsesses about shaving milliseconds off a tight loop whilst using a profiler would reveal that the real bottleneck is the code called just before entering the loop.

Premature optimisation is optimisation without knowing what needs to be optimised.

</comment></comment></comment><comment><USER5> I've seen that perverted to design absolute nonsense and as a defense say: "hey, we don't do premature optimization here!".

</comment><comment><USER6> I'm glad this came up; I've been thinking about it for a while.

When I first started programming professionally and read this quote, I thought it didn't really apply to me. I do a lot of low-traffic webapps and never really felt like I did much trade-off with premature optimization. It certainly sounded strong to say that pre-mature optimization was the root of _all evil_. Hell, I messed up so many other things that I would have picked any one of them and thought it to be more of a problem. But I respected the person saying it, so I kept it in the back of my mind.

Then I had an epiphany. Pre-mature optimization isn't just about performance, and it doesn't even have to be about only programming. In your business, are you focusing on automating something that will only save a miniscule amount of time? Are you building a feature that will rarely ever be used? Sounds like pre-mature optimization to me. And the problem is not that the end-product won't be better; the problem is the opportunity cost. You're trading off a whole host of other things that could be worked on instead.

Pre-mature optimization for me comes down to reassessing where I am at every stage of building a project and asking myself: am I focused on the right thing? Because if not, I'm wasting my time.

</comment><comment><USER7> I think what Knuth/Hoare/whoever was trying to say here is - solve the problems you _know_ you have. The key point is that the "know" should be demonstrable knowledge (as opposed to asserting "I know" with authority), in which case it would be justifiable to extend the principle to "solve the problems you _know_ you have or will have".

<comment><AUTHOR> This sounds like the most appropriate assertion in this case. I doubt Knuth suggested writing inefficient code, it's just that first comes the stuff you know (as you mentioned), then - if required - improvements.

</comment></comment><comment><USER8> It boils down to common sense. My approach is to try to writing the code reasonably efficient, but initially, readability, maintainability and simplicity take precedence over performance. I wouldn't write a more hacky or complex code just for the sake of performance before I KNOW there's a problem.

</comment><comment><USER9> Nothing actionable in the article nor in these comments. Some folks use hashtable as a default container - is that premature optimization? Wouldn't a vector do? Which one is 'evil' and which one is right?

</comment><comment><AUTHOR> This came up when watching a CS193p lecture 2 on iTunesU (Winter 2013).

</comment><comment><USER10> Bad optimization is bad. Of course.

<comment><USER11> You're missing the point.

The point is that in many cases, you should optimize for readability and simplicity first, and optimize for performance only if it's likely to become an issue. If you optimize for performance first, you may well have massively increased your cost of development for incremental performance gains that you could have got by throwing a bit more hardware at the problem.

</comment></comment><comment><USER12> It's not. Poor communication is.

<comment><AUTHOR> Please explain, because I find that difficult to appropriate to projects worked on by a single person.

<comment><USER12> For a single person? Well it depends where the requirements are coming from, and how often the checkin with that other person are coming to compare what is being done with what is expected to be done.

<comment><USER13> All bets are off for a single person project.</comment></comment></comment></comment>