May 23, 2013 at 11:49 am
vliet (5/13/2013)
Developers think row-based. They cannot work with set-based algorithms. Everyone who tells you otherwise hasn't worked together with developers.
That is pure unadulterated drivel. I'm a developer. I've been a developer since the 60s, at a time when there were NO set-oriented languages out there. I designed set-oriented solutions, message-oriented solutions, list-oriented solutions, functional solutions, and logic-oriented solutions according to what was needed without regard for the language I would have to implement those solutions in - because the right algorithm is the right algorithm whether you are programming in assembly language or in a procedural language or in an object language or in a logic language or in a list-processing language or in a functional language or in anything else. Most of my colleagues over the years had the same attitude. I know very well that a lot of developers are fully capable of thinking in terms of sets.
vliet (5/13/2013)
Most programmers like to call themselves developers. Most companies want to hire developers while paying only a programmers salary.
Distinguishing between a programmer and a developer is a strange game - it's not generally a useful distinction. Maybe you are thinking of someone who takes someone else's detailed design instructions, type specifications, and flow diagrams and turns them into Basic? That's not a programmer, that's a coder - and it's getting on for 50 years since I last came across one of those, because they are a silly idea - they cost money and don't save the someone else any time. There is a useful distinction between scientists and engineers on the one hand and non-scientist non-engineer developers on the other hand, but that distinction is about having acquired formal recognition (which developers who are incapable of thinking like engineers or scientists should in theory never acquire - the practise isn't always in line with the theory)
vliet (5/13/2013)
Most errors will only surface after the solution has been deployed. The use of inefficient techniques are no exception to that rule.
Most errors, including performance issues, should be eliminated long before development by good unit testing and fixing the problems detected there; most of the rest should be eliminated by good system testing and fixing; most of the small proportion that remain should be caught by final quality validation. If most Errors are found after release the development testing and release people are a bunch of incompetents.
vliet (5/13/2013)
Good programmers are hard to find, good developers even harder. Would you be able to learn those so-called developers how to implement their solutions with those efficient techniques? If not, please stop complaining ...
Over the years I've taught a lot of people set-oriented techniques and how to program in a set oriented manner in declarative languages whether process/message oriented, functional, or logic-oriented or non-declarative languages like SQL. I complain about the appallingly bad SQL I see, and often just complaining has produced a remarkable improvement in performance. I complain about University computing courses which teach micky-mouse languages like Pascal or horrendous abominations like C++ and no computing science, no engineering good practise, no functional algebra, no logic calculi, no set-oriented thinking, no list-oriented language, no process-oriented thinking. I complain about people who call themselves developers but haven't a clue how to develop anything and can't be bothered to acquire a clue (haven't had much to do with such, fortunately), those who haven't a clue but think they have and can't be dissuaded are even worse. People who want to be developers and are willing to learn are fine - they are easy to teach.
I've seen dozens of posts in the forums here where developers have said how much they've enjoyed some of Jeff's articles and the ensuing discussions, and how much they have learned from them. Rather obviously those are developers who can do set-oriented thinking, some of them because Jeff's articles have taught them how to think that way. The idea that programmers can't be taught set-oriented thinking is nonsense. Teaching them about schema normalisation and/or three-valued logic and/or real security can be a bit more difficult, though.
Tom
May 23, 2013 at 11:54 am
Gary Varga (5/22/2013)
It cannot be forgotten that sometimes maintainability must take an equal footing to performance. For some, being able to adjust a system to ever changing business rules is as important as getting the results quickly.As always there is not one single facet of systems delivery that has an overriding lead in business requirements. As such, compromise often needs to be found. Having said that, the compromise must be an educated choice i.e. proactively choosing a design that is maintainable but slightly slower that encompasses efficient algorithms will probably satisfy the requirements for an enterprise application. Of course that leads us to the differing emphasis various systems have...
Only too true. And as well as causing a flexibility versus performance conflict those same ever-changing rules can mean that what is a performant algorithm today will have terrible performance (in fact it won't even work) next week because a changed business rule will have forced a schema change.
Tom
May 23, 2013 at 6:32 pm
vliet (5/13/2013)
Developers think row-based. They cannot work with set-based algorithms. Everyone who tells you otherwise hasn't worked together with developers. LINQ is a beautiful integrated query tool on sets, but most developers still prefer those old-school For Each loops. If your lucky they understand the benefits of joins and use them appropriately. They're good at other things but they're no good at databases. Efficient algorithms are at the base of efficient code, but for most developers getting the job done without subtle flaws or hidden 'features' is already hard enough. I know a lot of performance tuning on many aspects of applications, but I'm generally called AFTER an application becomes too slow to be useful.
I absolutely support your post. I just have to pitch in with my 2 cents which isn't probably worth that. I constantly see row by row processing with incredibly bad results. On the other hand, I can't talk intelligently with DBAs on _why_ set based coding is so fast (or rather why T-SQL is so slow), and even now, I would not be able to get a developer to take the pitfalls of update SQL using preparations based on NOLOCK seriously. Developers don't take DBAs seriously and vice versa and on average I DON'T BLAME EITHER ONE OF THEM A BIT. Actual knowledge means nothing, its not the facts you present, its the illusion you get away with. What is happening is an across the board collapse in credibility and the entire industry is becoming filled with uneducated crap frosted on top with some of the most blatant posturing possible, sprinkled with alphabet soup bought and paid for.
Most programmers like to call themselves developers. Most companies want to hire developers while paying only a programmers salary. Most errors will only surface after the solution has been deployed. The use of inefficient techniques are no exception to that rule. Good programmers are hard to find, good developers even harder. Would you be able to learn those so-called developers how to implement their solutions with those efficient techniques? If not, please stop complaining ...
LOL I think the bottom line is nobody believes anybody knows anything, and in most cases they're probably right!
December 19, 2016 at 7:12 am
dmbaker (5/13/2013)
vliet (5/13/2013)
Developers think row-based. They cannot work with set-based algorithms. Everyone who tells you otherwise hasn't worked together with developers.Really? That's a pretty broad brush you're using there. I don't claim to be an expert by any means, but as a SQL Server developer I think I know "set-based algorithms". But then, I guess I'm just fooling everyone...I am a developer after all.
🙂
Very funny
December 19, 2016 at 8:04 am
Nothing seems to have changed. Certainly not in my opnion. And the shock of Tom agreeing with me even more so :w00t:
Last day at work so Merry Christmas all.
Gaz
-- Stop your grinnin' and drop your linen...they're everywhere!!!
December 19, 2016 at 8:55 am
It's 2016, and folks are still coding really bad T-SQL. The problem is that many organizations see T-SQL coding simply as an extension of C# or Java coding. Those of us who know T-SQL are only brought in to do damage control when the code starts impacting the health of the entire server, and they desperately need someone to figure out what's going on and "fix it".
Well, let's check back again in 2020.
"Do not seek to follow in the footsteps of the wise. Instead, seek what they sought." - Matsuo Basho
December 19, 2016 at 9:19 am
Eric M Russell (12/19/2016)
...Well, let's check back again in 2020.
Just got out of the DeLorean. No change.
Gaz
-- Stop your grinnin' and drop your linen...they're everywhere!!!
December 19, 2016 at 12:23 pm
Gary Varga (12/19/2016)
Eric M Russell (12/19/2016)
...Well, let's check back again in 2020.Just got out of the DeLorean. No change.
I don't know much about how those time traveling DeLoreans work, but that seemed like a quick trip. Any chance you also noticed how the stock market was doing or who won the 2020 US presidential election?
"Do not seek to follow in the footsteps of the wise. Instead, seek what they sought." - Matsuo Basho
January 5, 2017 at 12:59 am
Eric M Russell (12/19/2016)
Gary Varga (12/19/2016)
Eric M Russell (12/19/2016)
...Well, let's check back again in 2020.Just got out of the DeLorean. No change.
I don't know much about how those time traveling DeLoreans work, but that seemed like a quick trip. Any chance you also noticed how the stock market was doing or who won the 2020 US presidential election?
It's all about the flux capacitor!!!
Who won the 2020 US presidential election? Big assumption that there was/will be one. :ermm:
Gaz
-- Stop your grinnin' and drop your linen...they're everywhere!!!
January 15, 2017 at 6:12 pm
I agree with you quite often, Gary. I don't always bother to say so, because sometimes I've nothing useful to add to what you said. I guess I've disagreed with you sometimes too - but can't remember. Except this time at least one thing has changed - I don't see any of vliet's anti-developer nonsense, and that's a change for the better.
Actually, I think some other things have changed in the last few years. I can't be certain, because I'm not really in touch with the way companies are working these days, or what the new guys fresh from a CS or IT course and looking for a first job actually know, but there are some good signs in the press and on the web - more people seem to be giving up on the nonsense that makes the quality or validation team into a bunch of destructive know-it-alls, creates walls between dbas and developers and sysops, more walls between development and production, and hatred between customer support people and everyone else. Of course somethings have changed for the worse: where a job-advert used to ask for 5 years commercial experience of something that was made available as a beta release to a few privileged customers ony 6 months ago, it will now ask for 5 years of that experience, and where a company wanted significant experience and skills that would take 15 years full time work to acquire for a pay rate that would be barely acceptableto someone in their early 20s they now want even more skills and experience for even less (all part of the ongoing emasculation of traditional personal departments who worked with the recruiting managers by the shift towards using recruitment agents who (a) haven't a clue what's actually required because (b) they don't listen to the recruiting managers).
Tom
January 16, 2017 at 2:03 am
TomThomson - Sunday, January 15, 2017 6:12 PMNothing seems to have changed. Certainly not in my opnion. And the shock of Tom agreeing with me even more so :w00t:Last day at work so Merry Christmas all.I agree with you quite often, Gary. I don't always bother to say so, because sometimes I've nothing useful to add to what you said. I guess I've disagreed with you sometimes too - but can't remember. Except this time at least one thing has changed - I don't see any of vliet's anti-developer nonsense, and that's a change for the better.
Actually, I think some other things have changed in the last few years. I can't be certain, because I'm not really in touch with the way companies are working these days, or what the new guys fresh from a CS or IT course and looking for a first job actually know, but there are some good signs in the press and on the web - more people seem to be giving up on the nonsense that makes the quality or validation team into a bunch of destructive know-it-alls, creates walls between dbas and developers and sysops, more walls between development and production, and hatred between customer support people and everyone else. Of course somethings have changed for the worse: where a job-advert used to ask for 5 years commercial experience of something that was made available as a beta release to a few privileged customers ony 6 months ago, it will now ask for 5 years of that experience, and where a company wanted significant experience and skills that would take 15 years full time work to acquire for a pay rate that would be barely acceptableto someone in their early 20s they now want even more skills and experience for even less (all part of the ongoing emasculation of traditional personal departments who worked with the recruiting managers by the shift towards using recruitment agents who (a) haven't a clue what's actually required because (b) they don't listen to the recruiting managers).
I guessed as much Tom. I assume that it is similar for most of us.
You are so right: the current state of employment is just shocking.
Gaz
-- Stop your grinnin' and drop your linen...they're everywhere!!!
Viewing 11 posts - 16 through 25 (of 25 total)
You must be logged in to reply to this topic. Login to reply