St-Clock

By your standard, we should let the machines vote because that's a multiple choice question.

Ooohhh. Thank you, it makes sense! (I still stand by my criticism of their article though).

This article does not seem well thought out. It takes a condescending look on frameworks (and object-oriented programming) and contains many inaccuracies. For example, most ORM frameworks/libraries allow the developers to map an existing database schema with existing classes. They do not "force" you to follow only one type of mapping.

Now, what's the difference between a library and a framework? Hint: it's probably a continuum between no inversion of control and total inversion of control (not "reversion of control" btw). Many libraries provide some inversion of control mechanisms and "force" you to work their way (tyranny!!!). Is JQuery a library with all its callbacks and the use of $? Should you use JQuery then or "stay in control"?

As for: "So, our advice to you is to stay in control of the development path of your software and prefer libraries over frameworks for real-world projects."

Where is the nuance, the "it depends" in this conclusion? It depends on where you are in the product lifecycle, where your competitors are, how many developers you have, what your core features are vs. what features the frameworks can provide, etc.

For example, imagine that you invented a new programming language. Say clojure. Now you want to provide syntax highlighting, syntax checking, tab-completion, features that an IDE provide. Will you (1) write a completely new IDE or (2) write a plug-in/extension/script for vim/emacs/eclipse/netbeans? Are they, "real world projects"?

With postgresql, create index does not block read, only write. You can also use the CONCURRENTLY parameter and writes/updates won't be blocked, but the index creation takes longer (the db has to wait until no transaction potentially involving the index has stopped).

Not sure what other strategies exist to reliably build an index.

http://www.postgresql.org/docs/current/static/sql-createinde...

I am confused. How hard is it to create an index in MySQL? I don't have much experience with MySQL, but with PostgreSQL, it is very easy.

In addition, there are some "advanced" features that may not be provided by MongoDB: you can choose your index type, rebuild the index, update the stats that will help the query optimizer decide if the index should be used at all, etc.

"Relational databases were designed around the idea of minimizing storage footprint, and we have nearly infinite storage capacity"

Well, foreign keys are not just a way to minimize storage: it speeds up future updates. If you duplicate your data everywhere for faster read access, your write cost just increased.

This might not be fair in dialectic, but I assure you that attacking the ethos of an opponent in rhetoric is fair game. It can be tricky if you only focus on that though because it does not make the audience believe more in your point... But of course, forget about this silly rhetoric thing, Hacker News is all about pure logic :-)

Sure, but in Montreal :-)

Google seems to be busy in many challenging areas, and after a Ph.D. in C.S., technical challenges look like a rare commodity in Montreal.

One thing I may have missed from the documentation: is it possible to check post-conditions (side effects of the function and return value)?

Thanks to you and astine, I just learned today about per-user salts. I thought that you only needed a site-wide salt and after reading on the topic, I now understand why it's better to have a per-user salt stored in the db.

I was also confused by these frameworks (e.g., Django) that ask you for a secret key and I thought that the secret key was a site-wide salt. Fortunately, they knew better than me ;-)

Quick question, if you have the db but not the salt, does the speed of the hashing algorithm still matter?

"Overall, the experience was positive and I would seriously consider using Go for writing server side of web applications as it provides a right balance between speed and memory efficiency of the running code (much closer to C than to e.g. Python) and speed of development (much closer to Python than to C)."

It seems these days that there is a confusion between the web server (often a reverse-proxy), the web application and the thing in the middle (gateway/pipe/container/app server). While I would certainly consider Go for the implementation of a reverse-proxy or an app server, it isn't clear that Go is a good choice for the web application itself, especially when you consider that most of the time is spent in the DB and in the cache...

Anway, the article mostly talked about Go and not about Python...

"This assumes the end user is familiar with command line usage. The typical consumer of VPSes aren't"?

What? I thought it was the opposite, i.e., that typical VPS customers were familiar with a command line or had to get familiar pretty quickly :-) Do you have any data or experience to back this claim (I ask because I don't have any data to back my perception)? Maybe you are referring to managed VPS as opposed to unmanaged VPS?

Btw, the article is 2 yrs old so (should have been in the summary...).

Yes, SourceForge sat on their "monopoly" and did not innovate. Yes, they got complacent. But they were so ahead of their time! If I remember correctly, SourceForge even used to offer a compiler farm so you could try to compile your library/program under different environments.

Their mistakes benefited to all new services and competitors. If GitHub had been the first to offer this kind of service, they may have committed some of SF mistakes.

"Another mistake that many libraries make is that they make a generic 'FooLibraryException' and subclass all their exceptions from there, instead of from where it makes sense (IoError, KeyError, MemoryError ...)"

Actually, this isn't black and white. When I need to create more than one exception class for a library, I prefer to avoid subclassing standard exceptions to prevent that kind of confusing situation:

  try:
    afile = open('myfile.txt')
    content = afile.read()
    my_library.do_something(content)
  except IOError:
    # recover from afile.read() failure

If my_library was returning a IOError, you would not know if the problem came from your code or the library code. Moreover, this would leak implementation detail.

Of course, you can always get around this by wrapping each library call within a try/catch block, but that does not scale well if you make many calls interspersed with your code.

Errr... With a typical RDBMS, doing a full table scan depends on the current stats (e.g., number of rows, are the stats current, state of the index, possibility to use an index, presence of cached data, previous query performance etc.). It does not depend only on the query and the data structure, so it is near impossible at development time to be certain that a table scan will occur during production. In fact, a table scan might occur today and not tomorrow for the same query, but with different data.

Many developers have been burned by trying to optimize their queries and indexes too early. The query planner, although sometimes unpredictable, is generally better than developers at predicting the performance of a particular execution plan. Table scans are also preferable in certain situations.

Relying on the fact that RDBMS have sophisticated query planner (as opposed to MongoDB) is not a sign of "reactive development". It just means that you should test your queries (and your indexes) with close-to-production data, and, as the data grows and evolves, continue to test, because the best execution plan might change.

The first part of your post made sense until you said "The right way to look at it, imo, is to see RDBMS as specialized systems".

RDBMS have a lot more features and support many more usage scenarios out of the box than any NoSQL systems and SQL offers more features as a query language than any other NoSQL query languages.

Of course, NoSQL query languages are simpler than SQL by design because the programmer is expected to write a program or a script for complex queries instead of using the query language. But then, you have to write your own execution plan, and think about atomicity and consistency, etc.

NoSQL are clearly the specialized systems, not the general ones.

Sure, but the relatively short link to your reply, http://news.ycombinator.com/item?id=2492783, is already 44 characters, so I'm only left with 96 characters on a twitter message.

With bit.ly, the link is much shorter with 21 characters, http://bit.ly/j8IpC8, and I'm left with 119 characters to describe the link in a twitter message.

Oh, and I'll know how many people clicked on my bit.ly link. I've become addicted to that feature.

The idea of using a table to represent a function implementation was proposed by Parnas, but in the context of software documentation.

This is quite nice if you can choose which function to represent with a table (as opposed to having to represent all functions as tables).

A recent publication on this:

Parnas D., Document based rational software development, Journal of Knowledge-Based Systems, 22(3):132-141, 2009. http://dx.doi.org/10.1016/j.knosys.2008.11.001

I don't know because I thought your comment was insightful. But since this is one of the worst threads I have read since I joined HN, in terms of FUD and signal-to-noise ratio, it is not impossible that someone who misunderstood the situation downvoted you.

The fact that comments like "Man you guys are dumb." (http://news.ycombinator.com/item?id=2482925) wasn't voted down is indicative of the health of this thread.

I believe github is doing exactly this "Powered by the Dedicated Servers and Cloud Computing of Rackspace Hosting®"

You might also be interested in gitli (excellent for single-developer projects, good-enough for small teams):

https://github.com/bartdag/gitli

Try various commands on their cli for some interesting feedback (e.g., vim, emacs, rm -rf).

Btw, someone downvoted a previous poster who said exactly that. The post was deleted though :-(

At its core, Spring provides some niceties such as dependency injection, resource location, validation, and data binding, all for POJOs: you can use these features in a regular app or in a web app. For other features such as persistence, you can see Spring as a meta-framework wrapping other frameworks (e.g., hibernate).

Spring Framework thus go way beyond web frameworks.

Disclaimer: I'm not a huge fan of Spring and I don't like "meta-frameworks", but to qualify it as a "web framework" is diminutive at best.

I just bought the ebook version and it appears as is on the preface.

Not that I bought the book for the preface...

"4) The GAE design patterns in python are ugly. I find our current Sinatra-based implementation cleaner and easier to understand. Python + django is verbose, its templating system is obtuse, and its testing framework is, well, I don't know because I've never seen it. This point is a religious one, so I'll leave it be"

Should Python programmers write the unofficial guide to migrating off of heroku?

That was exactly my thought.

No NoSQL. And they use transactions for write queries.

They use apache (not even nginx!).

Only 25% of their servers are pure (no snapshot) caching servers (not 50% or 75%).

They prefer vertical partitioning over sharding (but they still use sharding).

I understand they are looking at redis for some of their features, but really, their main stack is traditional and proven. Very enlightening.

Next (desired) feature in the pipeline: online vim on top of github.

And no, I don't think Bespin/Skywriter/Ace is good enough right now.

"And that startup time of JVM is orders of magnitude worse than pretty much anything else."

Sure, let's throw out of the window all the optimizations the VM can do at runtime because it takes a whole second to start the VM.

And you need to actually compile the source file before executing it!

Those server applications should all be written in bash because it's instantaneous!

Kidding aside, one prof at my university once told me that she wished students should still have to compile and wait for a program to start. When there is such a delay, it pays to read your code and try to understand it before running it (as opposed to run-and-see-what-happens).

+1 for "you almost always learn tenacity". I've seen many good and bad Ph.D. students, but in the end, the ones who got their Ph.D. were the tenacious ones, not necessarily the best or brightest ones.