MySQLBlog - Comments

Roland Bouman: The web application is a mess

nospam@example.com (Roland Bouman) — Wed, 17 May 2006 14:49:06 -0700

"SQL and HTML are "declarative": they let you state what you want, and the browser (for HTML) or database (for SQL) has to decide how to cook it up for you. This makes them easy languages for people to grasp; it also ensures that the browser and database server will be exceptionally large and complex pieces of software."

mmm, don't think I agree. In my experience, a lot of people find it easy to grasp HTML, whereas most people I know (including programmers) find SQL quite difficult to grasp.

"...And apparently programmers are never really satisfied with declarative languages, so database servers grew stored procedures and browsers got Javascript..."

Does that really have to do with the declarative nature of these languages? HTML has a very basic and, for most applications, inadequate vocabulary for specifying interaction: the link, the input element and that's about it.

Suppose the element would've had an attribute to specify a regular expression to which the contents should be matched, or an attribute that would verify if entering a value is optional - very declarative and very powerful, and probably features that would make browser scripting less necessary especially in the early days where javascript was used mainly to validate forms.

O Rylin: The web application is a mess

nospam@example.com (O Rylin) — Wed, 17 May 2006 13:40:54 -0700

While I'll agree that web apps aren't as good as desktop apps, they're a great complement (think Outlook Web Access).

I'm fairly sure the popular stacks won't get a much-needed cleanup because of the Microsoft syndrome - popularity requires a fair bit of backwards compatibility.

The way I see it is two things happening (which have also happened historically):
A huge mashup (hey, you can do backend and frontend with ASP/VBScript - though I wouldn't recommend it).
Strict mode.

I'd much prefer the latter (as I believe in the *IX idea - use many tools that perform their own tasks extremely well), as it provides supposed painkiller-less solutions for organisation and cleanliness of everything related to a project.

Simplyfying the stacks right now would probably push us towards more and more solutions based solely on Flash (one "language" for displaying and manipulating data) and its ilk - not a very comforting thought.

J.D. Duncan: Message API beta release

nospam@example.com (J.D. Duncan) — Thu, 13 Apr 2006 17:06:08 -0700

Spread runs on Windows, and MySQL runs on Windows, so the Message API code should definitely be able to run on Windows, too. However, I personally don't have a Windows development or test machine or any experience with Windows development. I would be happy if someone could contribute some expertise in this area.

Roland Bouman: Message API beta release

nospam@example.com (Roland Bouman) — Thu, 13 Apr 2006 16:29:37 -0700

Sorry to ask, but am I right concluding that the code you provided is nix-only?

J.D. Duncan: Message API beta release

nospam@example.com (J.D. Duncan) — Thu, 06 Apr 2006 16:24:19 -0700

Yes, I think the layer that handles the content of messages is probably best written in SQL. It seems so far like the best path is for me to provide sample stored procedure code, and let people modify the samples to suit their particular table structures.

Roland Bouman: Message API beta release

nospam@example.com (Roland Bouman) — Thu, 06 Apr 2006 15:22:05 -0700

Hi!

I think a saw a few posts concerning Spread in the nearby past.

I just took a look, and I must say it looks promising. Are there any plans for building a layer that can do something with the content of messages?

Roland