You can catch garbage comments in code reviews just as easily as you can catch other forms of programming garbage during review. The fact that someone might make a lot of bad comments is not a good argument against commenting, it's a good argument against bad commenting.
I also think that if people are in the habit of having to comment it makes them more likely to document things like expected values of the input, what the return could be expected to be, and if there are any caveats.
If I wasn't going to get the benefit of my data automatically being distributed across servers, why would I use this? In many cases, NoSQL solutions seem to be a compromise that you make, giving up ACID (yes I know this has it) and other nice query features of databases and in return gaining the ability to scale to much larger amounts of data and having redundancy without needing to think about it.
In this case though, it's all embedded so I don't gain any of the benefits.
The point being that if you need a local data store, sometimes you would rather have a document-based one where you don't have to create the code to serialize your objects into (e.g.) a SQLite database, and to reconstitute them back.
A good example would be something like an address book data store. Especially if you want it to be dynamic so that the user can add/remove fields (e.g. allowing the user to attach as many phone numbers as they like to the contact, rather than just a static 5 numbers). If you have to implement this in SQLite, then you have to develop the schema for it, and the (de)serialization code. With a document-store, you can just do something like say "store these fields" and you're done with it.
| giving up ACID (yes I know this has it)
If you know that this has ACID, then why are you talking about giving up ACID? The fact that many NoSQL implementations give up ACID doesn't have any bearing on this discussion.
I wonder about that kind of argument. I find it super appealing because I would love to work a lot less and yet get more done. Unfortunately I've found that if I work more, I do get more done. Granted, there's a time for stepping back and thinking about a problem rather than continuing to brute force your way through it. And you can get to a point where you spin your wheels and it's better to stop. But generally, more time spent does mean more done, no?
I find that it can be really difficult to measure productivity some times, especially when long hours are involved. If I work 2x hours and I get stuff done all throughout that time (beginning, middle, and end) then I'll tend to think all of those hours were well spent. But when I spend the time and effort to really look at productivity I find that typically spending more hours only produces the illusion of greater productivity. Often times I'll easily forget the downsides of working more hours, such as poorer quality of work, less focus and ability to concentrate, more down time between periods of work, greater likelihood of being OK with partial or inferior solutions, etc.
Over time I've come to the conclusion that except for "it's broken, and time is money" or "I've found inspiration at midnight" situations it's pretty much never a good idea to consistently work long hours on software projects. It's better to work smarter and more efficiently and to have the resources available to do big refactoring / redesign / performance improvement projects when necessary than to just work flat out and always be in an "ok, that's good enough, moving on" state of mind.
Software development is a created process, like writing fiction. Imagine a fiction writer doing a 60 hour (or hell, even a 40 hour) work week to try and get more work done. It just won't work, certainly not long term.
But you do need to put in the practice time to be able to be productive when you need to be. If your process involves a lot of procrastinating with intermittent bursts of brilliance ,you won't be able to be relied upon when things get tough. Stephen King became the writer he did because his wife would tell him to write a story, the baby needs diapers, and he did.
So before you can work smart, you have to know how to work hard. Otherwise you're just goofing off.
Yes, it is a creative process. I think that a better analogy is to a scientist though. Sometimes, scientists spend a lot of time thinking about what an experimental result means and planning out their next set of experiments. But oftentimes, they also have to crank through a bunch of experiments that they've planned. The more time they spend at that point, the further they get.
Whether or not it was a good idea for Musk to respond to the review is almost aside the point. It seems as though that is just a part of his nature. If he wasn't the type of CEO who would respond like that, he likely would also not be the type of CEO who could run SpaceX and Tesla.
Right. It's a tricky line to walk. But the TedX name grants a certain level of mainstream acceptance to ideas. And it seems like they're trying to prevent people from taking advantage of that to pimp their latest miracle, effort free, libido enhancing, hair increasing, bicep growing treatment.
An earlier comment mentioned that it's a question of what's the right forum to debate new ideas. Going to direct to the public is probably not the right one. Another hallmark of these hoaxes tends to be the notion that "main stream scientists don't want you to know" etc... It's trash.
I wish the letter had ended by admitting that it's tough to exactly define bad science but it's a lot like porn, you know it when you see it.
Agreed. I use python a lot and I hadn't seen that dict comprehensions had been back-ported to 2.7. So while the rest of it wasn't super useful to me, that was.
This seems like a nice addition. I would love to see conditional writes eventually as well. I wonder if cassandra ends up evolving into something that looks kind of like a database. It's definitely taken some steps in that direction before this. I haven't read the paper yet, but Google's spanner gives me hope that at some point in the near? future I won't have to worry about the details of consistency myself anymore.
I haven't read the paper yet, but Google's spanner gives me hope that at some point in the near? future I won't have to worry about the details of consistency myself anymore.
That's a pretty concise way of expressing why we started building our product here at FoundationDB (http://foundationdb.com/). We're building a distributed key-value store with ACID transactions precisely so that developers building cool projects can stop worrying about all of the ins and outs of maintaining consistency by hand. If you'd like to give it a try, please feel free to sign up for our alpha -- it's just a quick form on our website (http://foundationdb.com/#get) and then you're welcome to download the software and check it out.
That argument doesn't make sense. My outlet for creativity is the content of my code not when new lines happen or how I indent. On the other hand, if everything in the codebase is formatted uniformly it's a lot easier to scan through and you don't end up with diffs filled with reformatting kruft as each team member walks over the others' formatting style.
If you're feeling extra creative, you could always change your font, font size, and syntax highlighting scheme. ;)
He could quote a better example, but I think the document goes deeper than just formatting style.
From the article's excerpt "Principles":
* Don't be "clever" — do the simplest thing that could possibly work properly.
* Be precise.
* Be concise.
* KISS — Keep It Simple, Stupid.
* Use the smallest hammer for the job.
---
They are indeed asking for uniformity against creativity. Which is not a bad thing for corporations (IBM have very strong guidelines for years) but definitely takes away that "hacker" aura that we gave to Google a few years ago.
> They are indeed asking for uniformity against creativity
Well, I mean you could argue that this is clever, creative and beautiful ( http://thedailywtf.com/Articles/Confessions-rachetingDateObj... ). To quote one of the comments "If I lean close enough to the PC's speaker, I can hear the tiny clicks of all those wheels spinning round - 'sbeautiful."
I don't think google is really arguing against creativity, rather saying "don't be creative for creativity's sake".
I remember having to install Quartz Scheduler so it would hit a single servlet every night at 1am. That's _ALL_ Quartz was used for. When I asked about using cron the response was "well that wont scale"... this application had been around for fifteen years and during that time there was only one batch process... clever indeed!
There always would be anecdotal cases and interpretations. That's why I asked an open question to a googler who could set the document into a context.
I also have cases of people doing a lot of ad-hoc code because it was easier (small hammer to the job) and then resulted in a pain code to read that could be prevented with a clever system. But I am agreed with you that the whole thing is arguable and subjective
Which of those principles is at odds with creativity? Is verbose code positively correlated with creativity? Code more complex than required? Ambiguous code?
I already told in another reply that it is subjective.
But when they say "KISS Keep it simple stupid" one programmer could interpreter that as "OK for this messages management system what is more simple than a huge list of if statements" and another one could interpreted the same principle as "Hmm OK, I will have a list of closures to reduce verbosity"
That says to not be creative just to entertain yourself. Be creative to solve problems. It is a polite way of saying "you aren't as smart as you think you are at 3am on a red bull binge". This advice was not invented by Google. Knuth or someone for one has a famous quote about it: debugging is harder than first draft, so how do you debug code that you wrote at peak cleverness?
From The Elements of Programming Style by Kernighan and Plauger: “Everyone knows that debugging is twice as hard as writing a program in the first place. So if you're as clever as you can be when you write it, how will you ever debug it?”
Agreed. It seems like you'd also want the ability to occasionally hook up to a bigger monitor. Do you find the 11" screen bothers you at all, or have you gotten used to it?
I'll be curious to see how he finds the surface keyboard. I'm dubious of the one that doesn't have physical keys on it. I find it really hard to type effectively without that physical feedback.
Great to read the year-after follow up, by the way. Really well done.
Me too, and if the surface is the same size as an iPad then the keyboard is not going to be fullsize. If I add the wireless Apple keyboard ontop of the iPad about 2 keys sticks out over the edge if I line it up on the other end.
I also think that if people are in the habit of having to comment it makes them more likely to document things like expected values of the input, what the return could be expected to be, and if there are any caveats.