Hacker News Reader

> It should be possible for an amateur to quickly write an SQL validator as a starting project

...why? SQL has been wildly paradigm-definingly useful for decades. It has driven hundreds of billions, perhaps trillions, of dollars of value. None of this hinges on the ability for an amateur to be able to write a validator for the language. It just seems like such a non-sequitur to me, such a strange thing to call out as a criticism.

SQL hasn't been wildly successful either because of or despite its syntax, it has been wildly successful because organizing data in the relational model and querying it declaratively is extremely powerful. The syntax is just not the interesting part. Any syntax that meets those criteria would do.

> It should be possible for an amateur to quickly write an SQL validator as a starting project

I think the point he is trying to make here is the same as the post was making concerning orthogonality. Having a smaller set of special syntax, and therefore an easier validator to write, means easier queries to write for the user. I don’t think he was implying that everyone who makes use of the language should know how to write a lexer for it.

> The syntax is just not the interesting part. Any syntax that meets those criteria would do.

I have to disagree with this. If this was the case we would still be programming everything in BASIC or C because they’re just another imperative programming language and it gets the job done. Having sugar syntax, a consistent language, etc.. all makes it easier for a programmer (or data analyst) to get the job he needs quicker (and therefore reduces cost), makes a program easier to maintain, and so on.

The syntax is not the interesting part for programming languages either. Programming languages now have better semantics - things like runtimes, concurrency, data encapsulation, etc. - in addition to better syntax. SQL is not a programming language, its semantics boil down to the relational model. Don't get me wrong, there is room for improvement in the syntax, I have plenty of gripes with it, I just don't agree that it is a fundamental problem. It's already super useful as it is.

Indeed semantics is what matter but I think for example lack of composability is semantic problem too.

<snarky> Ability to manage persistency and correctness of SQL engines is very usefull while language interface not so much. </snarky>

I second this emotion SO HARD. Is sql weird? sure. But (IMO) the hard part implementing|using a sql database is _not_ the syntax, it's the storage, query planning, consistency. Don't like SQL? use linq or one of the bazillion DSL libraries that "compile" to sql. SQL databases are so unbelievably extremely useful, and the minor syntax quirks between different DBs are a minor issue compared to the huge amount of commonality that they share.

Also FWIW, I'm not sure that writing a sql validator _is_ all that hard. The grammars for any dialect are readily available and really not so hard to turn into an AST with any of your favorite tools (ANTLR, lex/yacc/bison, any of a million PEG parser generators). In many cases you don't even need to, we do static analysis of spark SQL using their own parser, for postgres can use the parser straight out of libpg.

I guess the OPs point is that if you can validate it easily, you can understand it. I'm certain I could write a lisp parser in 10 minutes, but I don't think that would mean I immediately understand all Clojure code (which is often pretty obtuse). You still need to learn all the underlying concepts and data structures.

Your last paragraph is non sequitur. It is perfectly possible for the syntax to not be the interesting part, and for SQL to have been successful despite bad syntax. The underlying idea is brilliant, so the first syntax that exposed it sufficiently well got baked in as a path dependency, even though the syntax sucks.

The point I was trying to make was just that the syntax was irrelevant; it was neither a major advantage nor hindrance. I think this is the same as your point.

One thing I have experienced is that often times developers are coming from a world of object oriented programming, or just coming from a JavaScript world.

Then often the storage and retrieval of data is an after thought during the development of an application. This is definitely true for CRUD apps. Then maybe the person used a framework to handle database interactions and now after a year or so, it’s not scaling well because the data access was not really given priority during development. So then the problem is the database engine or the syntax instead of proper design and planning.

That’s not to say there are no drawbacks to writing most dialects of SQL. I just believe most of the hate over SQL is coming from a procedural mindset to a relational one.

>> It should be possible for an amateur to quickly write an SQL validator as a starting project

> ...why?

I don't know about amateurs, but if the typical intended user of the language does not have a good grasp of what is and is not valid, they will often be reduced to trying one thing after another until they hit upon something that seems to work, with no real understanding of what it does. This is not how robust, correct software is written.

That seems like a completely different point. (Unless I misunderstand what a "SQL validator" is, which is definitely possible.)

I do think this way of utilizing SQL is a problem, but I would lay the blame for it at the feet of a lamentably widespread anti-intellectualism in the field. It is true that the relational model is not trivial and must be learned before SQL makes much sense. But it is not too much to expect from someone who wants to be a practitioner in this field.

I agree that someone who wants to be a practitioner in this field should understand the relational model, but the issue here is that SQL introduces inconsistencies and complications that are not inherent in the relational model, and, to some extent are avoidable. A justifiable emphasis on professionalism does not absolve SQL of these faults and does not render irrelevant attempts to find better language choices.

Sure, I don't disagree. My point is that the perfect is the enemy of the good, and SQL is the good.

>It has driven hundreds of billions, perhaps trillions, of dollars of value.

The same can (almost) be said for Javascript. A language with a lot of foibles can still be successful if it is the only realistic mechanism to interact with the system.

No disagreement from me there! Though I personally like SQL more :)

> all the syntax decided on before there was a community that really understood what good syntax is

Here you got me thinking: do we even understand that now? There was quite a bit of contemplating about of semantics, data types and different kinds of abstractions in the programming languages for the last couple of generations already, but the general consensus about the syntax is that "nice syntax is nice, but it isn't really that important". Most modern languages loosely follow either something C-like or Algol-like, most people like what they are familiar with. There are sometimes claims that a good syntax should be successfully parsed by some relatively simple parser (which is totally not obvious, TBH, because while it is clear why C++ is a good counter-example, we don't really have that many good examples: classic LR-parsers or something like that are really not that powerful, and most real-world programming languages implement something very non-generic of their own). Some people claim that "good syntax is no syntax" (Lisp), and some say that Haskell has a good syntax (ikr). The bottom line being that this is just a matter of taste, unlike most of what we can say about types and data structures.

So, to summarize: I never actually heard a compelling general theory of good syntax.

This is completely offtopic, BTW, I agree that SQL is trash and it is even kinda funny that somebody tries to defend it like that, since for a long time it was sort of a textbook example of "why a language created with the idea to be used by non-technical people is a failure from the very beginning".

> So, to summarize: I never actually heard a compelling general theory of good syntax.

I started to think along these lines when I got serious about learning a foreign language. Humans appear to have some innate language ability that’s reflected, among other things, in commonalities between disparate languages. As far as I can tell, there’s been no serious effort to design a computer language to take advantage of this.

My pet theory about why the object.method(args) call syntax won is that it really is the most natural to read, as evidenced by the fact that most human languages follow subject-verb-object word order.

The commonality you are referring to sounds like Chomsky's concept of Universal Grammar [1].

The object.method(args) "won" because it is a low barrier to entry from English to Programming indeed, but as you become more and more experienced and you shake off the imperative way of thinking in favour of declarative thinking functional languages becomes more expressive than imperative languages. They become better at managing complexity because they allow you to build higher and higher towers of abstraction.

And then homoiconicity [2] shines because of its 'universally grammatic' property.

1. https://en.wikipedia.org/wiki/Universal_grammar

2. https://en.wikipedia.org/wiki/Homoiconicity

I was thinking on a more basic level than UG; just the presence of linguistic universals [1]. I agree that functional languages are in a certain way more expressive than imperative ones, but that seems mostly orthogonal to the syntax of the language.

I’m thinking about basic stuff like improper nouns, denoting a clause’s role by inflection or adposition instead of word order, and having a clearly defined spoken representation- none of this is specific to which abstract structures the language is describing.

https://en.wikipedia.org/wiki/Linguistic_universal

>The object.method(args) "won" because it is a low barrier to entry from English to Programming indeed

BASIC and C didn't have a concept of objects* , which didn't seem to hinder adoption at all. object.method() became popular when OOP languages became popular, and that was because IDEs offered better autocompletion with that syntax.

* We could emulate objects with C in some gnarly ways. Almost no one did at the time, excluding C-with-classes/C++.

It's not that simple, D has UFCS (Uniform Function Call Syntax), which makes object.method(args) and method(object, args) equivalent calls.

Also there's a non-language related advantage of dot notation. Type the name of the object, press dot and IDE will show you what things you can do with that object. You don't have that with other notations.

Why is dot special? Fortran uses % (if I remember properly) IDE's can complete after a % as well as after a dot.

Dot is not special. Putting the receiver objects first is special, because it allows the IDE to only show verbs (methods) that pertain to that object. If you put the verb first, code completion lacks context, so it would necessarily have to show you all verbs that can apply to any object that could conceivably be acted on in that scope.

That assumes a very OO mindset. method(object, args)/function(data, parameters) works better in other languages, and IDEs can handle this quite well without dot syntax.

Which goes to your point-- form follows function, in syntax as with many other things.

Though I program in languages that most follow the obj.method(args) pattern, I really prefer the args |> function |> function pattern and I wish it was the norm in every programming language.

In what language is that used? It reminds me of pipes in bash. I can see it being useful in circumstances where you have lots of function calls and fewer arguments (just like pipes), but I think it would look really ugly and hard to parse with a long arg list.

Elixir for one.

Yes it works best when you have one argument to pass, as the first argument is passed implicitly.

https://hexdocs.pm/elixir/Kernel.html#%7C%3E/2

It's a common functional thing. I know F# has both `|>` and `<|` to go both directions. It also has `||>` and `|||>` variants which take two- or three-value tuples and spread them to arguments.

https://docs.microsoft.com/en-us/dotnet/fsharp/language-refe...

See also Clojure's threading macros: https://clojure.org/guides/threading_macros

Julia supports it, too:

https://docs.julialang.org/en/v1/base/base/#Base.:|%3E

These are two different use cases. In the first case, which method the call actually dispatches to depends on obj, so it kinda makes sense for it to be syntactically distinct from other args. The pipeline syntax is normally used with free-standing functions that are statically dispatched.

Now, yes, there are languages with multimethods, where the distinction is less obvious. For those that always dispatch on all arguments, a uniform syntax makes more sense. CLOS is a good example.

> My pet theory about why the object.method(args) call syntax won is that it really is the most natural to read, as evidenced by the fact that most human languages follow subject-verb-object word order.

Most western languages maybe, but according to wikipedia[1] the most common is actually SOV rather than SVO.

[1] https://en.wikipedia.org/wiki/Word_order#Distribution_of_wor...

Most common by number of languages maybe, but if we look at most common by number of people who speak the language, the top 3 most popular languages in the world(Mandarin, Spanish, English) are all SVO.

> [...] as evidenced by the fact that most human languages follow subject-verb-object word order.

Nope. [1]

[1] https://wals.info/chapter/81 (Note that while this is the language count only, the same comment applies to the population using such word order as a native tongue: SOV and SVO are both common.)

> SQL is messy because all the syntax was decided on before there was a community that really understood what good syntax is.

It's not that they didn't understand it. There are languages predating SQL that have better syntax.

But SQL was one of the so-called "4th generation programming languages", that were supposed to be operating at a much higher level. And because of that, there was the notion that, if they also have a more "natural" syntax, it would allow people who are not programmers to use them effectively. Hence why SQL was originally SEQUEL - Structured English Query Language. It was meant to be written by domain experts, not database experts.

Of course, that failed (like countless other similar attempts since then), and so now we're stuck with this syntax for no good reason whatsoever.

Please use pivot_wider and pivot_longer instead of gather and spread. The true horror, even admitted by the the dplyr team ...

Oh, they're new. Great. Thanks for the tip.

As a point of minor historic curiosity, the pipe operator in R actually predates dplyr and was invented independently multiple times by various people who noticed that the Unix model translates well to data transformations in R (F# also has a pipe but I'm not aware of anybody using F# as an inspiration for the pipe in R).

Except that dplyr is horribly slow and memory inefficient, and (if you were minded to actually put R code into production) it more or less forces you to do data prep in a database anyway.