December 26, 2016 at 9:04 pm
Comments posted to this topic are about the item Syntactic Sugar
December 27, 2016 at 2:41 am
I've read this article immediately after a piece on Professor John Yudkin, the author of Pure, White & Deadly. A man who had his reputation destroyed for his meticulous observations that sugar and other carbohydrates were the cause of obesity and the diseases related to obesity and not saturated fats and cholesterol.
Unfortunately professor Yudkin was right and diet authodoxy was wrong.
Back to syntactic sugar. MySql is jammed full of syntactic sugar and in my opinion it could have benefited with less of it in favour of robustness and some common sense for some of the features.
We know that SQL Server has millions of lines of code. Every line is a potential bug. If I want RegEx I either add it using SQLCLR or buy it in the form of Solomon Rutzky's SQL# http://www.sqlsharp.com.
I'd like Microsoft to focus on the core product but have a peer review panel for 3rd parties to add SQLCLR modules in much the same way as Apple allows apps through the Apple Store
December 27, 2016 at 6:34 am
I'd like Microsoft to focus on the core product but have a peer review panel for 3rd parties to add SQLCLR modules in much the same way as Apple allows apps through the Apple Store
I like that idea.
December 27, 2016 at 6:36 am
Syntactic sugar actually refers to the tokens added to make the *compiler's* job easier, like the ; in C to end lines. I think the term you're looking for is "bells and whistles".
Pedantry aside, my #1 wish is for MS to fix the elephant in the room, the fact that as a language T/SQL's performance (outside the optimizer/queries) is simply abyssmal. Granted RBAR can never be as fast as native set code (because that's been optimized to within an inch of its life and most of it is probably hand-tuned assembler anyway) but the performance difference is frankly an embarassment.
Of course T/SQL is kind of difficult to parse anyway, but still! Interpreters do not have to be as glacial as that, look at Java, .Net, or Python.
December 27, 2016 at 7:46 am
Outside of an ETL staging environment, the routine usage of RegEx expressions would indicate something is amiss in the data model design or data quality.
"Do not seek to follow in the footsteps of the wise. Instead, seek what they sought." - Matsuo Basho
December 27, 2016 at 8:01 am
Where do you need RegEx? LIKE is supporting it currently, so the only other point could be something like REPLACE (but I never needed it for REPLACE).
They already added some sugar in 2016 SP2 / vNext (as CREATE OR ALTER, DROP IF EXISTS, STRING_AGG, CONCAT_WS), but I still miss some easy-to-implement features as LEATEST / GREATEST (takes 2 to n parameters and returns the smallest / greatest non-NULL-parameter; could be currently done only with a ugly (SELECT MIN(x) FROM (VALUES ((p1), (p2), (p3), (pn)) tmp(x)).
Another (maybe more complex part) would be handling a BIT like an integer. Currently you can't (whyever) not use stuff like MIN(), MAX() or SUM() on a bit column (without an explicit convert). Furthermore there are some cases when a WHERE bit_column = 1 would not correctly use the index on bit_column.
God is real, unless declared integer.
December 27, 2016 at 8:08 am
Funny, the original article has a link to Wikipedia which gives a definition of "Syntactic Sugar" and still gets it wrong.
Syntactic sugar is for the benefit of the code writer, not the compiler. This is from the Wikipedia article:
In computer science, syntactic sugar is syntax within a programming language that is designed to make things easier to read or to express. It makes the language "sweeter" for human use: things can be expressed more clearly, more concisely, or in an alternative style that some may prefer.
...
Specifically, a construct in a language is called syntactic sugar if it can be removed from the language without any effect on what the language can do: functionality and expressive power will remain the same.
And for what it's worth, this is the definition I have always used for the term.
I agree completely regarding the abysmal performance of T-SQL!
December 27, 2016 at 8:16 am
Sam Bishop (12/27/2016)
Funny, the original article has a link to Wikipedia which gives a definition of "Syntactic Sugar" and still gets it wrong.Syntactic sugar is for the benefit of the code writer, not the compiler. This is from the Wikipedia article:
In computer science, syntactic sugar is syntax within a programming language that is designed to make things easier to read or to express. It makes the language "sweeter" for human use: things can be expressed more clearly, more concisely, or in an alternative style that some may prefer.
...
Specifically, a construct in a language is called syntactic sugar if it can be removed from the language without any effect on what the language can do: functionality and expressive power will remain the same.
And for what it's worth, this is the definition I have always used for the term.
I agree completely regarding the abysmal performance of T-SQL!
I'm pretty old school (mid-1970's), learned about syntax sugar from K&R's C manual. 🙂 Linguistic drift, perhaps?
December 27, 2016 at 9:26 am
Pedantically, I'm with Sam Bishop; I learned of "syntactic sugar" as having the definition in the Wikipedia article. So, being able to say "left OUTER join" or just "left join" in T-SQL would make the "OUTER" syntactic sugar.
That aside, historically, one of the big advantages of SQL Server was its approachability and usability. For me, at least. When I was getting into databases 15-20 years ago and didn't know a GROUP BY from a HAVING, it was just super easy to install SQL Server and start playing with it, doing training and tutorials against the ol' Northwinds and pubs sample databases. You make a product like that, you make it easy to develop against, you give it to universities super cheap, and I would expect you end up with a lot more market share in a decade or so. You've got to be playing the long game, though.
Every time a developer at my current job gets the obtuse "string or binary data would be truncated" error and has to spend an hour figuring out exactly which row and column(s) caused the problem, I feel like it pushes them slightly more in the direction of wanting to use a different data store when they have the choice.
Ultimately, I guess Microsoft have to decide their market priorities and where they fit in. There are multiple fronts to fight on: the heart and minds of developers, sure, ease of use, sure. But also performance, reliability, manageability... I don't envy them having to make these choices. But for their sake, I hope they've got a solid long-term vision that includes bringing new people into the fold.
December 27, 2016 at 10:09 am
roger.plowman (12/27/2016)
Syntactic sugar actually refers to the tokens added to make the *compiler's* job easier, like the ; in C to end lines. I think the term you're looking for is "bells and whistles".Pedantry aside, my #1 wish is for MS to fix the elephant in the room, the fact that as a language T/SQL's performance (outside the optimizer/queries) is simply abyssmal. Granted RBAR can never be as fast as native set code (because that's been optimized to within an inch of its life and most of it is probably hand-tuned assembler anyway) but the performance difference is frankly an embarassment.
Of course T/SQL is kind of difficult to parse anyway, but still! Interpreters do not have to be as glacial as that, look at Java, .Net, or Python.
I'm with you on the slow T-SQL business, but on the other hand, it would probably be a pretty big undertaking on Mirosoft's part, its wrapped up in how T-SQL runs and they'd have to pretty much turn the architecture inside out. For instance, how often would queries be "recompiled" when statistics change, when in fact, each iteration of a basic T-SQL loop would have to check for recompilation right? Its like running an audit for each iteration of your loop.
There is a need for fast RBAR in my opinion and again in my opinion I believe Microsoft has also come to this conclusion.
Notice that we finally got "compiled" procedures of a sort with the new in memory oltp stuff (yes I am probably talking about stuff I know nothing about but whatever). On their page, Microsoft explicitly allows that for instance:
Note that natively compiled stored procedures are not automatically recompiled if the data in the table changes.
So that's interesting that they no longer recompile stored procedures when stats change right?
I remember a while ago I posted some dumb code that would iterate a loop in T-SQL for fun, and compared it to dot.net.
create procedure testproc1
as
begin
DECLARE @X INT
DECLARE @Y INT
DECLARE @Z INT
SET @X = 1
SET @Z = 1
WHILE @X < 20000
BEGIN
SET @Y = 1
WHILE @Y < 1000
BEGIN
SET @Y = @Y + 1
SET @Z = @Z * 2
IF @Z > 10000
BEGIN
SET @Z = 1
END
END
SET @X = @X + 1
END
SELECT @Z
end
Yes its moronic, touches no tables and compares unfavorably to for instance a vb.net literal translation. Its pretty slow compared to a mathematically identical dot net version.
The interesting thing for me tho is comparing it to this version, stored in a memory optimized database:
CREATE procedure [dbo].[testproc1]
with native_compilation, schemabinding, execute as owner
as
begin atomic
with (transaction isolation level=snapshot, language=N'us_english')
DECLARE @X INT
DECLARE @Y INT
DECLARE @Z INT
SET @X = 1
SET @Z = 1
WHILE @X < 20000
BEGIN
SET @Y = 1
WHILE @Y < 1000
BEGIN
SET @Y = @Y + 1
SET @Z = @Z * 2
IF @Z > 10000
BEGIN
SET @Z = 1
END
END
SET @X = @X + 1
END
SELECT @Z
end
Much faster! But its interesting the things you give up (at least with 2014) to get compiled procedures which indicates to me that it took a really big architectural change to get faster RBAR but even more interesting to me is that Microsoft made the effort at all! I believe they recognize that there are situations where it would do some good to get fast and turing complete programming on a database server.
January 4, 2017 at 9:15 am
Brian J. Parker (12/27/2016)
...being able to say "left OUTER join" or just "left join" in T-SQL would make the "OUTER" syntactic sugar...
I know Brian has not expressed his preference, however, I will express mine.
I don't like these kind of shortcuts in languages. "LEFT OUTER JOIN" is clear whereas "LEFT JOIN" is ambiguous. Why care when we all know? Because maybe we don't ALL know. Also, it makes it harder for anyone learning the language. I have been asked what the difference is many times. Not by stupid people either. By people who care.
Having said that, I use parenthesis over precedence for reasons of clarity as well so you all possibly don't like the way I code.
Gaz
-- Stop your grinnin' and drop your linen...they're everywhere!!!
Viewing 11 posts - 1 through 10 (of 10 total)
You must be logged in to reply to this topic. Login to reply