Joel Spolsky on languages for web programming

[Jonas Hartmann]

No, really, tell us how you REALLY feel about it. -).


FWIW, a friend of mine is a seasoned DB programmer who migrated
from Oracle to PostgreSQL a few years ago. He says similar things
about MySQL. Worse, however, he says that RoR is destined to be
saddled with MySQL workarounds far into the future. Consequently,
he dismisses Rails as a whole, which is a shame.

Given that RoR is extremely modular, I see no real reason why this
must be the case. If some folks that are sharp in both PostgreSQL
and Ruby (note: I am not one were willing to make the effort,
AR could be enhanced (or replaced, if need be) to provide clean DB
semantics.

Until that time, the AR/MySQL hegemony will continue to dominate
RoR practice. As they say, an ounce of implementation trumps a
pound of rhetoric...

-r

cant u run RoR with postgre sql adapter already? thought you could...

disadvantages?

regards
Jonas

 

[kate rhodes]

You beat me to it -- just as Rails implies the Ruby interpreter, so .NET
implies the CLR.

You guys are right but the point still stands. The entire .net
platform is still not something that can, in any reasonable way, be
compared to Rails. They're completely different things with completely
different purposes in life.

You can't write a web app in .net. It's not a language and it's not a
web framework. You *could* write an app in Django / TurboGears that
ran under /within .net and THAT would be comparable but not because
it's got anything to do with .net. It would be comparable because
Django and TurboGears are both web frameworks like Rails.

 

[Austin Ziegler]

cant u run RoR with postgre sql adapter already? thought you could...

disadvantages?

Sure you can. You can even run it with an Oracle adapter. But there
are design decisions made by the core Rails team based on the way that
MySQL does things -- and the way that MySQL does things is flat out
*wrong*. This isn't a matter of one technical opinion vs. another.
This is a matter of incorrect implementation and basing one's
preferred behaviour on that incorrect implementation.

IMO, DHH has an (illogical) opposition to foreign key handling in
Rails because MySQL can't do squat with it. (SQLite is no better on
that front, not even recording them as notes, but at least SQLite has
the excuse that it isn't trying to be a full SQL implementation. MySQL
has pretended to be that for years and has implemented a tiny fraction
of the standard to date.)

SQL databases suck, but MySQL implements SQL so badly that it
shouldn't even be called an SQL database.

Basically, you can use any database you want behind ActiveRecord, but
ActiveRecord itself is going to treat it as if it were MySQL. You'll
get none of the advanced features from your *real* database.

And that's a shame, because -- as I said -- ActiveRecord does so
*much* right and could do it even cleaner if it used the facilities in
the database. (For example, there's no built in way to create a
foreign key in migrations. This is inexcusable despite DHH's
opposition, because good database design demands foreign keys. Not
using them is a half-assed mockery of database design. On those
platforms which don't support foreign keys, like MySQL and SQLite,
make foreign key operations null.)

I'll use Rails, to be sure. I just used it this past weekend -- and I
used it on MySQL (long story again with no excusable reasons why I
couldn't have used something more intelligent). But MySQL is an
absolute dog that shouldn't be used if you want any kind of data
integrity.

-austin

 

[Tim Bray]

MySQL is a big sticking pile that should be left in the scrapheap.

Well, it's good enough to run major pieces of big public-facing web
sites, starting with Yahoo!, so it deserves a little respect I'd say -
Tim

 

[Keith Gaughan]

IME, it is something with MyISAM (which is still the most common
configuration because it offers pure speed) and it *does* affect
column names as well even though it shouldn't for the stupid reasons
that tables are affected.

Yup, that's what I said. I can't say I've had the same experience as you
with column names. Then again, I don't use MyISAM anymore, except when I
need fulltext search, don't need transactions and need COUNT(*) to work
quickly, or as a read cache. In practice, I find--and, of course, this is
anecdotal--that InnoDB's ability to do row-level locking more than compensates
for the performance difference between the two.

MySQL is a big sticking pile that should be left in the scrapheap.

If it works fine for a project, it's fine. Personally, I'd prefer to use
something like PostgreSQL, Firebird, or SQL Server, but sometimes MySQL is
just fine.

K.

 

[William Grosso]

Sure you can. You can even run it with an Oracle adapter. But there
are design decisions made by the core Rails team based on the way that
MySQL does things -- and the way that MySQL does things is flat out
*wrong*. This isn't a matter of one technical opinion vs. another.
This is a matter of incorrect implementation and basing one's
preferred behaviour on that incorrect implementation.

...

SQL databases suck, but MySQL implements SQL so badly that it
shouldn't even be called an SQL database.

I think we're running into a terminology issue here. If we think
of MySQL as a data persistence and retrieval mechanism, it has
certain properties and is optimized for certain types of
applications.

The fact that it's so widely used, and so effectively used by so
many people, argues that the design decisions embodied in MySQl
weren't completely wrong.

The fact that it's an incomplete realization of Codd's vision, and
has some interesting flaws from a data integrity perspective, means
that it isn't good for other applications.

Generic statements like "MySQL is a big sticking pile that should be left
in the scrapheap" aren't really useful at all.


William Grosso

 

[Chad Perrin]

Well, it's good enough to run major pieces of big public-facing web
sites, starting with Yahoo!, so it deserves a little respect I'd say -

Also including the full lineup of Wikimedia websites (Wikipedia,
Wikinews, Wikicities, et cetera).

 

[Austin Ziegler]

I think we're running into a terminology issue here. If we think
of MySQL as a data persistence and retrieval mechanism, it has
certain properties and is optimized for certain types of
applications.

You mean "applications where the integrity of the data is completely
irrelevant."

The fact that it's so widely used, and so effectively used by so
many people, argues that the design decisions embodied in MySQl
weren't completely wrong.

If you're trying to embody SQL database semantics, then said design
decisions are wrong. If you're just trying to have something that's
slightly more structured than flat files, then you're right -- they're
not wrong. Otherwise, MySQL is crap. Utter and complete crap for which
I have no respect for its developers.

The fact that it's an incomplete realization of Codd's vision, and
has some interesting flaws from a data integrity perspective, means
that it isn't good for other applications.

Stop. Right. There. (1) *NO* current SQL-based database realizes
Codd's vision. Some come closer than others, but SQL databases aren't
properly relational. See the discussions headed by Fabian Pascal and
Chris Date (of dbdebunk) for that. (2) MySQL doesn't even implement
SQL database semantics properly. They *pretend* to, but they don't
actually do it. Because they don't support it, (3) a lot of developers
have assumed that if MySQL does it, it must be right. It isn't. It
isn't even *close* to right. I would argue that 90%+ of all the open
source database schema produced to work with MySQL take advantage of
MySQLisms and aren't even first normal form.

There's a place for big piles of data. But *not* in a SQL database or
a schema implemented on top of that database. I personally want RoR
databases to be *well-designed* databases, not the piles of utter crap
that you see from 99% of PHP developers who couldn't tell data
modelling from a hole in the ground.

Yes, I have very strong opinions about data modelling. No, I don't
think you can be a good developer if you don't know data modelling
(more provocative: you can't make a good object model if you can't do
proper data modelling). Yes, I think you can create good databases
that will run on MySQL -- but you have to do so *despite* MySQL's
stupidities.

Generic statements like "MySQL is a big sticking pile that should be left
in the scrapheap" aren't really useful at all.

When they're accurate -- as "MySQL is a big stinking pile.." is,
they're quite useful. If you want to work with databases, work with a
real database. Postgres, for example. If you just need something
quick, use SQLite. Both will protect your data better than MySQL.

It's unfortunate that MySQL has become the "preferred" database for
web work, because it's complete crap.

-austin

 

[David Vallner]

You can't write a web app in .net.

Yes, you can. ASP.NET and the System.Web namespace are a web framework,
somewhat similar to Java's JSF. The approach is to make the controller
look more like you'd use when making a desktop app - it's event-driven,
as opposed to request-driven. .NET doesn't include ORM, that's actually
a trait that's not really common to web frameworks - Rails is the only
one I've had experience with that does do that. All those are part of
what you call .NET (although you need a .NET-capable webserver.

Your point does *not* stand, your previous posts didn't include a single
argument why it should.

David Vallner

 

[Phlip]

kate rhodes wrote:

Yes, you can. ASP.NET and the System.Web namespace are a web framework,
somewhat similar to Java's JSF.

You snipped the context. I suspect it said Ruby is a platform like .NET, so
Rails is a framework like ASP.NET.

Your point does *not* stand, your previous posts didn't include a single
argument why it should.

"I distort your argument, therefor it's wrong" is not a valid debate
technique.

 

[David Vallner]

cant u run RoR with postgre sql adapter already? thought you could...

disadvantages?

And this holiday season, the Grammar Nazi association gives you a
special Christmas present: a basket full of apostrophes, full words, and
complete sentences. Enjoy.

David Vallner

PS: Please try to keep the standards of communication at a reasonable
level. English correct to the best of your abilities will do. Kthxbai.

 

[David Vallner]

You snipped the context. I suspect it said Ruby is a platform like .NET, so
Rails is a framework like ASP.NET.

Quoting Kate Rhodes:

You can't compare .net and Rails. It's like comparing the JVM or
Parrot and Rails. It makes no sense.

.NET and the JVM and Parrot are just virtual machines that by themself
contribute absolutely nothing to the productivity of a web developer.

After being corrected on the above, the next argument was just that you
can't write a web application in .NET.

The mention of how (only) a Django / TurboGears app on IronPython would
be a webapp running on .NET, and even then wouldn't be a .NET webapp
made me presume the claim was that .NET flat out lacks the features to
write a webapp, as did the claims that .NET by itself won't increase
your productivity.

My personal guess is that Kate is ignorant of ASP.NET generally, of how
it would relate to Rails in purpose more so.

"I distort your argument, therefor it's wrong" is not a valid debate
technique.

Except I didn't distort it since there was no relevant argument stated.
Feel free to use the list archive to see for yourself.

David Vallner

 

[William Grosso]

You mean "applications where the integrity of the data is completely
irrelevant."

No, I meant exactly what I said.

Thanks for putting words in my mouth though.


William Grosso

 

[Austin Ziegler]

No, I meant exactly what I said.

Thanks for putting words in my mouth though.

MySQL is optimized for one thing: applications that don't give a damn
about data integrity. Like most PHP applications.

If you want something that actually protects your data, use something
else. Hell, SQLite is better than MySQL for that.

So, you may have meant what you said, but what you said was so
nonsensical that I was forced to make it clear what you actually
meant.

-austin

 

[Rimantas Liubertas]

MySQL is optimized for one thing: applications that don't give a damn

about data integrity. Like most PHP applications.

If you want something that actually protects your data, use something
else. Hell, SQLite is better than MySQL for that.

<...>

Ok, it is obvious that you don't like MySQL that much, but I am really
interested
in technical details why do you make such claims.
Can you provide some?


Regards,
Rimantas

 

[Philip Hallstrom]

MySQL is optimized for one thing: applications that don't give a damn

<...>

Ok, it is obvious that you don't like MySQL that much, but I am really
interested
in technical details why do you make such claims.
Can you provide some?

http://sql-info.de/mysql/gotchas.html

And to be fair...

http://sql-info.de/postgresql/postgres-gotchas.html

Don't know how up todate it still is, but you can read them to find out