Comment by okaleniuk | Hacker News Reader

Comment by okaleniuk | Hacker News Reader

Parent Full thread

For instance, we choose Riak+LevelDB some 8 years ago as our data store. It doesn't support SQL but it's fast and easily scalable. And free. I'm not sure if we could achieve the same speed and fault tolerance with any SQL solution available at that point. So the deal is, you give up your time invested in learning SQL and get some advantages in return. This is reasonable.

But if it's only about language, no additional perks, then it just isn't worth investing your time.

If continue the parallel with programming languages, there are tons of C-killers nobody knows about. I think, roughly every third programmer in the world tried to write more ergonomical C at some point in their live. And there is Rust. Which is not about ergonomics really but about memory safety combined with comparable performance. No more buffer overflows, no more Heartbleed. People see what they are trading their time on Earth for and the language is getting traction because of that.

This is, of course, only my personal opinion but languages are just thin interfaces over technologies.

With respect, I think you're missing a lot. Sit with an expert SQL guy and you'll learn a great deal. Maybe not enough to change your mind but certainly enough to realise you're blocking out a really valuable technology.

> but languages are just thin interfaces over technologies

No. Not at all. SQL is derived from a mathematical basis. The principle came first, then the language and tech together developed to fulfil it.

But that doesn't contradict my point. The mathematical basis matters, sure, but the language on top of it (exactly because it derives from the math anyway) is mostly irrelevant.

I don't really care if I have to write SELECT or \forall or σ as long as they all have the same meaning. But I'd prefer to use SELECT because I already spent time learning how to work this way.

SQL as a language is fine. There is no real need to reinvent SQL unless you're going to reinvent the math behind it too.

2 points then;

1. Do you know SQL currently? Because your previous comments implied you don't

2. SQL is a bad implementation of the underlying relational model. And it's just bad in other ways. For one, it's bloody wordy:

  select * from people

but as SQL is an expression language, why not?

  people

From an answer of mine a few days ago (slightly modified here) to pick out differences:

  (
  select *
  from t1
  except
  select *  from t2
  )
  union 
  (
  select *
  from t2
  except
  select *
  from t1
  )

I'd prefer to write that crap as

(t1 \ t2) + (t2 \ t1)

or similar. If you write a lot of SQL, that matters.

SQL aggregates don't nest easily. Transactions are screwed up (https://news.ycombinator.com/item?id=23569513). SQL is poorly composable (https://news.ycombinator.com/item?id=23550420#23561301). For better or worse it has nulls therefore tristate logic. This causes errors! And more.

BTW. transactions don't work in the way you might think, atomically. Which is why MS added https://docs.microsoft.com/en-us/sql/t-sql/statements/set-xa... and I'm sure Pgres has similar. From the link:

"When SET XACT_ABORT is OFF, in some cases only the Transact-SQL statement that raised the error is rolled back and the transaction continues processing"

That peculiarity is from the standard BTW.

SQL is problematic. It could have been much better.

Reply on news.ycombinator.com