Hacker News Reader

Comment by protomyth | Hacker News Reader

This looks more like a cool vs uncool list. SQL and HTML are "Dreaded"? Frankly, anyone who has the actual opportunity to program in Assembly should thank their lucky stars.

View on HN

SQL and HTML are on both lists. Presumably because they can be great or terrible depending on the quality of the existing code you’re dealing with

Also they can only dread what they use. The question SO uses specifically asks only about things that you use extensively. That is what makes this interesting to me. It isn't people dreading APL because it looks funny, its people dreading something are using it day to day.

Html has a lot of flaws, but it's easy to learn, so it totally tracks to me that it could be in both categories. I wouldn't want to write a sizeable app in vanilla html, but I can't think of a simpler way to create cross-platform UIs

I'd consider Assembly a lot better language than SQL. You can't get proper testing framework what makes SQL hard - hundreds of lines queries with unknown amounts of joins/unions and not-well-defined relations.

It's not that's inherently dreaded, it just leans itself to a hard to follow one.

I've wondered sometimes if it's possible to quantify what I hate about hacking SQL so much, but it's hard. The language lacks something that I've taken to fuzzily call "localized mutation..." When I have to change someone's existing SQL, it usually involves jumping around in the text buffer a lot (i.e. wrapping an existing statement in parens to use it as a clause in a bigger statement, or having to split a clause that is now complicated enough into a separate WITH clause... These operations involve mutating text that can be dozens of lines separated, and all those mutations need to be coordinated.

It feels like a harder language to refactor than most I use.

Indeed, it's difficult to be isolated and split into smaller blocks (functions/classes/whatever). Effectively it's one massive statement with different clauses and data that's entirely publicly accessible in all aspects, no encapsulation and so on.

As a cheap excuse, I have come to think that 'loving' SQL does require a different mindset.

I love SQL.

I think you're spot on that it takes a different mindset. I treat it like a disposable expression of data, not a program. Essentially, I have data in one form, and I need to translate to this form, what is the logical representation of such a transformation?

If the results of an SQL are not as expected, I have no problem rewriting the entire thing rather than doing a "bug fix."

> I've wondered sometimes if it's possible to quantify what I hate about hacking SQL so much, but it's hard.

In my experience the "problem" is how detached it is from the underlying computational model. Even more so when you're working with columnar stores, querying Vertica with SELECT FROM WHERE is kind of weird.

Probably it's because I don't have a lot of experience with it, but I feel like I have to EXPLAIN every other query, I'm never confident what I said is what I mean.

  > I've wondered sometimes if it's possible to quantify what I hate about hacking SQL so much, but it's hard...

For me, any time I have to write any SQL statements it's the totally and utterly unhelpful error messages:

  >ERROR 1064 (42000): You have an error in your SQL syntax; check the manual that corresponds to your DB server version for the right syntax to use near <insert really long SQL query>

...which, as far as I can see, haven't changed an iota in their total and utter vagueness since I first wrote an SQL query about 20 odd years ago.

For me, any time I have to write any SQL statements it's the totally and utterly unhelpful error messages:

  >ERROR 1064 (42000): You have an error in your SQL syntax; check the manual that corresponds to your DB server version for the right syntax to use near <insert really long SQL query>

...which, as far as I can see, haven't changed an iota in their total and utter vagueness since I first wrote an SQL query about 20 odd years ago.

How are people doing SQL without looking at query plans and table statistics? I just don't understand the problems people have with SQL or stored procedures. Writing queries and proper table design are not that problematic.

Heck, we wrote a program at one point that dumped the operation being done by running queries. SQL is so much easier than a lot of other languages.

SQL is one of those languages that found its way outside of developer circles. My father-in-law knows SQL, and he's just about as far as you can get from your stereotypical developer. SQL is much easier than a lot of other languages, but it means people who have no experience with the ins-and-outs of software development are going to use it. These users are guaranteed to employ the language in ways that are not "proper" but instead ad-hoc and problematic.

Well, if they write one-off queries, it doesn’t really matter. The problem is when developers write bad queries that are often executed.

Reply on news.ycombinator.com