4 ms·

SQL is declarative, statically typed but with an incredible type-inference system, and does an amazing amount of optimization behind the scenes. If it weren't s

SQL is declarative, statically typed but with an incredible type-inference system, and does an amazing amount of optimization behind the scenes. If it weren't so domain-specific, it would be the holy grail of languages. It amazes me how many developer hours of effort has been put into this global quest to completely avoid SQL. It is starting to remind me of all the people I work with that would rather write 10k lines of VBA for some unmaintainable Excel spreadsheet than learn to write 300 lines of Python/Ruby/Lua/Whatever that can accomplish exactly the same task. I can understand some hesitation to learn something new, especially when there are so many new things to learn and the value of learning them is not always apparent...but I would assume that the benefits of knowing SQL would be readily apparent. I'm not even a developer and I would feel like a quadriplegic without it.

romaniv 14y ago
It's not hesitance to learn something new. People avoid SQL for a variety of fairly rational reasons. For me, the biggest one is that most general-purpose programming languages encourage you to solve large problems by splitting them up into manageable chunks. SQL, on the other hand, encourages you to lump different problems together (for performance reasons). It also has remarkably poor tools for code reuse and abstraction. Have you ever worked with SPs that dynamically generate SQL code? I see it daily. Not only that, it's code written by professional database administrators.
pwang 14y ago
> If it weren't so domain-specific, it would be the holy grail of languages. That's relatively true of many languages. The reason SQL has been able to be optimized so heavily (and the reason why it's been adopted so broadly) is because it is so domain specific. More specifically, it is optimized for expression set algebraic operations, and certain kinds of kernels to apply to resultant sets. It is most definitely NOT suited for most array or otherwise metrically-oriented data series, which is why you never see it used in HPC to express timeseries transformations or, say, 3D PDE diffusion simulations. For those applications, people have come up with different kinds of specialized languages which are rooted in an more appropriate data abstraction than merely set operations.

romaniv 14y ago

It's not hesitance to learn something new. People avoid SQL for a variety of fairly rational reasons. For me, the biggest one is that most general-purpose programming languages encourage you to solve large problems by splitting them up into manageable chunks. SQL, on the other hand, encourages you to lump different problems together (for performance reasons). It also has remarkably poor tools for code reuse and abstraction. Have you ever worked with SPs that dynamically generate SQL code? I see it daily. Not only that, it's code written by professional database administrators.

pwang 14y ago

> If it weren't so domain-specific, it would be the holy grail of languages. That's relatively true of many languages. The reason SQL has been able to be optimized so heavily (and the reason why it's been adopted so broadly) is because it is so domain specific. More specifically, it is optimized for expression set algebraic operations, and certain kinds of kernels to apply to resultant sets. It is most definitely NOT suited for most array or otherwise metrically-oriented data series, which is why you never see it used in HPC to express timeseries transformations or, say, 3D PDE diffusion simulations. For those applications, people have come up with different kinds of specialized languages which are rooted in an more appropriate data abstraction than merely set operations.