[stevoski]

The first (or second, maybe) line made me cringe...a specific object for MySQL, rather than a database-agnostic SQL engine, a la old-school ASP or middle-school JDBC.

Perhaps better:

    db = DatabaseConnection.new("MySQL", "localhost", "my-user", "s3cr3t");

[stevoski]

Another reason I cringed is the implicit creation of the db variable. This is just asking for beginners to bang their head against the table in frustration trying to work out why their variable alongvariablename is equal to 0, even though they just assigned it to alonggvariablename to 7.

"Oh, it was just an extra g, and I've been stuck for hours because of that? I hate computers!"

[bouk]

What? Ruby works the exact same way. Pretty sure Slash doesn't make variable have an implicit value like PHP does

[rst]

And it's the one thing I really dislike about Ruby. The problem with this is that the interpreter can't tell the difference between declaring a new variable, and misspelling the name of an existing one --- which means that there's a very common class of simple errors which it can't automatically check. Even Perl (with -w) gets this right, and it doesn't really make the language more verbose; declarations are preceded with a 'my ' which is useful punctuation. (Humans also find it useful to see when a new variable is being introduced.)

And you could come up with ways to preserve the distinction while making it even less obtrusive --- ':=' instead of '=' in a declaration, for example.

[klibertp]

It's the same in Python, and it's mostly solved by external static code analysis tools. The trick here is the assumption that misspelled variable will be used only once in a file - exactly where it got misspelled - and tools like pylint or pyflakes warn about such names. If you're running these tools sufficiently often and have them integrated with your editor (my Emacs runs pyflakes once in 3 seconds, after enter is pressed and on save, whichever comes first) this kind of error is essentially eliminated.

OTOH, having a language which doesn't need external tooling to eliminate such errors is an obvious win. Smalltalk, with it's code browsers, refactoring tools and similar does this really well, for example - if you use a new name inside a method definition you are asked if you want to declare new instance or block variable, or turn it into selector, or if you want to rename it (and then it gets renamed throughout the method) and so on. And that's at compile time!

[Kiro]

Not really. That's how it works in Python, Ruby and most other beginner friendly languages.

[stevoski]

I don't think it is beginner-friendly, except maybe for the first two lines of code they ever write. By the time they get to the third line there is a good chance they've mistyped their variable name...

[mattmanser]

Why?

I think pretending that there aren't massive and very specific differences between SQL implementations is pointless. I would far prefer a tight, concise DB specific object than an over-verbose generic one.

So in reality, what does it gain you?

I haven't heard anyone talking about DB agnosticism in web dev for years, it was an odd idea that popped up in the mid-2000s and died the pointless death it deserved. Not only that, you should invariably wrap any such driver in another object to cut the verbosity down, so what was the point? There are specific types of code base that need to be DB agnostic, and web apps is definitely not one of them.

I've migrated a non-trivial app (10,000-100,000 LOC) from MySQL to SQL Server in C#, the only SQL queries I didn't have to change were the basic SELECT statements. Took me about a week and it was actually super useful having DB specific objects as when I finally ripped out the MySQL library reference, I could be confident that I had migrated every path (although that obviously only worked because it was a statically typed language).

[stevoski]

> I haven't heard anyone talking about DB agnosticism in web dev for years, it was an odd idea that popped up in the mid-2000s and died the pointless death it deserved.

ODBC and JDBC are both older than that, and still alive and well and popular today.