August 3, 2017 at 7:45 am
TomThomson - Thursday, August 3, 2017 7:08 AMbdcoder - Friday, July 21, 2017 8:31 AMExcellent points brought up by the author of 40 Years of Programming ! I don't think he or she was wanting paper documentation to come back -- all they wanted was meaningful documentation -- which I agree, is sorely lacking these days!I also agree that we should have a set of (syntax) standards for common tasks in programming, as mentioned in the article. Hopefully, a large software company such as Google or Microsoft might read the article, and who knows, maybe in another 40 years we will have SPL! It would be a much better world indeed.
Did anyone translate the binary at the end of the article? -- it translates to:
Good luck to you all!
SPL?! Heaven help us! ...
I think the authors point was to have a standard with regard to common tasks in the programming world; as mentioned in the article, loops, conditionals, data types, etc -- who cares what the standard is called -- just have a standard ! I agree completely with the author, why do we need a dozen or more symbols to denote something like "equal to"? Choose one and be done with it.
August 3, 2017 at 9:03 am
bdcoder - Thursday, August 3, 2017 7:45 AMTomThomson - Thursday, August 3, 2017 7:08 AMbdcoder - Friday, July 21, 2017 8:31 AMExcellent points brought up by the author of 40 Years of Programming ! I don't think he or she was wanting paper documentation to come back -- all they wanted was meaningful documentation -- which I agree, is sorely lacking these days!I also agree that we should have a set of (syntax) standards for common tasks in programming, as mentioned in the article. Hopefully, a large software company such as Google or Microsoft might read the article, and who knows, maybe in another 40 years we will have SPL! It would be a much better world indeed.
Did anyone translate the binary at the end of the article? -- it translates to:
Good luck to you all!
SPL?! Heaven help us! ...
I think the authors point was to have a standard with regard to common tasks in the programming world; as mentioned in the article, loops, conditionals, data types, etc -- who cares what the standard is called -- just have a standard ! I agree completely with the author, why do we need a dozen or more symbols to denote something like "equal to"? Choose one and be done with it.
Yeah... just choose the right one! 😉
That's the problem with so-called "standards". The same idiotic notions made by some language designers will appear in "The Standard". Other idiot's (language purists, mostly) will make decisions like "The UPDATE statement will not have a FROM clause" simply because certain people don't understand what it can do other than causing bad data if you don't actually know the proper way to use it. In the process, they would kill some rather remarkable flexibility and atypical but necessary use cases. If you want other examples of bad standards, look at all the so-called "Best Practices" that people have come up with for SQL Server/T-SQL. Some are great... some are just plain stupid and are born from lack of understanding, inexperience, bad experience, old wives tales, and visceral fear based on hearsay of all the preceding.
Further, standards are useless unless they can be enforced. If you look at the ANSI standards for SQL concerning temporal data types, it states that @EndDateTime-@StartDatetime=Interval and that works great for the DATETIME data type in T-SQL... and, yet, thanks to so-call "Best Practice" zealots and a lack of understanding on possible usage by them and Microsoft, they elected to make it impossible to do such direct temporal math in the DATETIME2() data type. They know they made that mistake because they came out with the DATEDIFF_BIG() function to try make up for the shortcoming.
--Jeff Moden
Change is inevitable... Change for the better is not.
August 3, 2017 at 9:14 am
Jeff Moden - Thursday, August 3, 2017 9:03 AMbdcoder - Thursday, August 3, 2017 7:45 AMTomThomson - Thursday, August 3, 2017 7:08 AMbdcoder - Friday, July 21, 2017 8:31 AMExcellent points brought up by the author of 40 Years of Programming ! I don't think he or she was wanting paper documentation to come back -- all they wanted was meaningful documentation -- which I agree, is sorely lacking these days!I also agree that we should have a set of (syntax) standards for common tasks in programming, as mentioned in the article. Hopefully, a large software company such as Google or Microsoft might read the article, and who knows, maybe in another 40 years we will have SPL! It would be a much better world indeed.
Did anyone translate the binary at the end of the article? -- it translates to:
Good luck to you all!
SPL?! Heaven help us! ...
I think the authors point was to have a standard with regard to common tasks in the programming world; as mentioned in the article, loops, conditionals, data types, etc -- who cares what the standard is called -- just have a standard ! I agree completely with the author, why do we need a dozen or more symbols to denote something like "equal to"? Choose one and be done with it.
Yeah... just choose the right one! 😉
Perhaps that is why the author mentioned a vote. Those of us in the trenches might have more say than the so-called "language purists" 🙂
August 4, 2017 at 3:09 pm
bdcoder - Thursday, August 3, 2017 9:14 AMJeff Moden - Thursday, August 3, 2017 9:03 AMbdcoder - Thursday, August 3, 2017 7:45 AMTomThomson - Thursday, August 3, 2017 7:08 AMbdcoder - Friday, July 21, 2017 8:31 AMExcellent points brought up by the author of 40 Years of Programming ! I don't think he or she was wanting paper documentation to come back -- all they wanted was meaningful documentation -- which I agree, is sorely lacking these days!I also agree that we should have a set of (syntax) standards for common tasks in programming, as mentioned in the article. Hopefully, a large software company such as Google or Microsoft might read the article, and who knows, maybe in another 40 years we will have SPL! It would be a much better world indeed.
Did anyone translate the binary at the end of the article? -- it translates to:
Good luck to you all!
SPL?! Heaven help us! ...
I think the authors point was to have a standard with regard to common tasks in the programming world; as mentioned in the article, loops, conditionals, data types, etc -- who cares what the standard is called -- just have a standard ! I agree completely with the author, why do we need a dozen or more symbols to denote something like "equal to"? Choose one and be done with it.
Yeah... just choose the right one! 😉
Perhaps that is why the author mentioned a vote. Those of us in the trenches might have more say than the so-called "language purists" 🙂
If you consider how some alleged "Best Practices" are born, I'll pass on the voting thing.
--Jeff Moden
Change is inevitable... Change for the better is not.
August 4, 2017 at 5:57 pm
Jeff Moden - Friday, August 4, 2017 3:09 PMbdcoder - Thursday, August 3, 2017 9:14 AMJeff Moden - Thursday, August 3, 2017 9:03 AMbdcoder - Thursday, August 3, 2017 7:45 AMTomThomson - Thursday, August 3, 2017 7:08 AMbdcoder - Friday, July 21, 2017 8:31 AMExcellent points brought up by the author of 40 Years of Programming ! I don't think he or she was wanting paper documentation to come back -- all they wanted was meaningful documentation -- which I agree, is sorely lacking these days!I also agree that we should have a set of (syntax) standards for common tasks in programming, as mentioned in the article. Hopefully, a large software company such as Google or Microsoft might read the article, and who knows, maybe in another 40 years we will have SPL! It would be a much better world indeed.
Did anyone translate the binary at the end of the article? -- it translates to:
Good luck to you all!
SPL?! Heaven help us! ...
I think the authors point was to have a standard with regard to common tasks in the programming world; as mentioned in the article, loops, conditionals, data types, etc -- who cares what the standard is called -- just have a standard ! I agree completely with the author, why do we need a dozen or more symbols to denote something like "equal to"? Choose one and be done with it.
Yeah... just choose the right one! 😉
Perhaps that is why the author mentioned a vote. Those of us in the trenches might have more say than the so-called "language purists" 🙂
If you consider how some alleged "Best Practices" are born, I'll pass on the voting thing.
Given that the electorate would be the developers anddbas and managers who have participated in the reduction of standards in both code quality and documentation and have brought us to the point where the vast majority of people applying for 6 figure salary jobs requiring SQL Server expertise don't even know how to get the current date and time, let alone write useful queries or describe a sane backup and recovery strategy, it seems to me that the majority of voters would make horribly wrong choices. So I'm 100% with you here, Jeff.
On top of that, I'm amazed to see people thinking that the Unknown Programmer's rant (the document the editorial links to) is all good. While his objection to the deterioration of documentation standards his and dislike of the pointless churn of procedural programming languages and related tools are well founded (indeed they are something we should all regard as good and agree with) the nonsense statement that we all write loops is just that: pure nonsense. I can see the reason for writing loops in procedural languages - indeed in every language with control flow that I know, although some control-flow languages (eg SQL) minimise the need for them (despite many writers in those languages thinking loops are the answer to everything, a cause of much bad code in those languages). But I can't imagine why anyone thinks that people writing in declarative languages (functional languages, logic languages, maybe some others) will write loops - after all, these languages don't have any control flow constructs at all, - control flow is determined either at compile time or at run time, not at coding time. I guess the Unknown Programmer has never used a declarative language.
So excessive standardisation is likely to be a bad thing. There are a lot of requirements that would be extremely expensive to meet using control flow languages, and much less expensive to meet using declarative languages. For example the first decent constraint resolution tool commercially released (way back in the 1980s) was written in Prolog (I know about that one because it was me that was handed the task of evaluating the research project and deciding whether to invest in commercialising it or not). Any standardisation by popular voting to determine the individual pieces of a new single universal programming language is bound to result in an appallingly bad control-flow-oriented monstrosity wiith vast freedom to get things wrong - perhaps we'd end up with something as awful as C++ or perhaps we'd be unlucky and end up with something even worse.
Tom
August 4, 2017 at 7:27 pm
TomThomson - Friday, August 4, 2017 5:57 PMJeff Moden - Friday, August 4, 2017 3:09 PMbdcoder - Thursday, August 3, 2017 9:14 AMJeff Moden - Thursday, August 3, 2017 9:03 AMbdcoder - Thursday, August 3, 2017 7:45 AMTomThomson - Thursday, August 3, 2017 7:08 AMbdcoder - Friday, July 21, 2017 8:31 AMExcellent points brought up by the author of 40 Years of Programming ! I don't think he or she was wanting paper documentation to come back -- all they wanted was meaningful documentation -- which I agree, is sorely lacking these days!I also agree that we should have a set of (syntax) standards for common tasks in programming, as mentioned in the article. Hopefully, a large software company such as Google or Microsoft might read the article, and who knows, maybe in another 40 years we will have SPL! It would be a much better world indeed.
Did anyone translate the binary at the end of the article? -- it translates to:
Good luck to you all!
SPL?! Heaven help us! ...
I think the authors point was to have a standard with regard to common tasks in the programming world; as mentioned in the article, loops, conditionals, data types, etc -- who cares what the standard is called -- just have a standard ! I agree completely with the author, why do we need a dozen or more symbols to denote something like "equal to"? Choose one and be done with it.
Yeah... just choose the right one! 😉
Perhaps that is why the author mentioned a vote. Those of us in the trenches might have more say than the so-called "language purists" 🙂
If you consider how some alleged "Best Practices" are born, I'll pass on the voting thing.
Given that the electorate would be the developers anddbas and managers who have participated in the reduction of standards in both code quality and documentation and have brought us to the point where the vast majority of people applying for 6 figure salary jobs requiring SQL Server expertise don't even know how to get the current date and time, let alone write useful queries or describe a sane backup and recovery strategy, it seems to me that the majority of voters would make horribly wrong choices. So I'm 100% with you here, Jeff.
On top of that, I'm amazed to see people thinking that the Unknown Programmer's rant (the document the editorial links to) is all good. While his objection to the deterioration of documentation standards his and dislike of the pointless churn of procedural programming languages and related tools are well founded (indeed they are something we should all regard as good and agree with) the nonsense statement that we all write loops is just that: pure nonsense. I can see the reason for writing loops in procedural languages - indeed in every language with control flow that I know, although some control-flow languages (eg SQL) minimise the need for them (despite many writers in those languages thinking loops are the answer to everything, a cause of much bad code in those languages). But I can't imagine why anyone thinks that people writing in declarative languages (functional languages, logic languages, maybe some others) will write loops - after all, these languages don't have any control flow constructs at all, - control flow is determined either at compile time or at run time, not at coding time. I guess the Unknown Programmer has never used a declarative language.
So excessive standardisation is likely to be a bad thing. There are a lot of requirements that would be extremely expensive to meet using control flow languages, and much less expensive to meet using declarative languages. For example the first decent constraint resolution tool commercially released (way back in the 1980s) was written in Prolog (I know about that one because it was me that was handed the task of evaluating the research project and deciding whether to invest in commercialising it or not). Any standardisation by popular voting to determine the individual pieces of a new single universal programming language is bound to result in an appallingly bad control-flow-oriented monstrosity wiith vast freedom to get things wrong - perhaps we'd end up with something as awful as C++ or perhaps we'd be unlucky and end up with something even worse.
Heh... you mean like EDI, XML, JSON, and PowerShell? 😉
--Jeff Moden
Change is inevitable... Change for the better is not.
August 4, 2017 at 10:33 pm
TomThomson - Friday, August 4, 2017 5:57 PMJeff Moden - Friday, August 4, 2017 3:09 PMbdcoder - Thursday, August 3, 2017 9:14 AMJeff Moden - Thursday, August 3, 2017 9:03 AMbdcoder - Thursday, August 3, 2017 7:45 AMTomThomson - Thursday, August 3, 2017 7:08 AMbdcoder - Friday, July 21, 2017 8:31 AMExcellent points brought up by the author of 40 Years of Programming ! I don't think he or she was wanting paper documentation to come back -- all they wanted was meaningful documentation -- which I agree, is sorely lacking these days!I also agree that we should have a set of (syntax) standards for common tasks in programming, as mentioned in the article. Hopefully, a large software company such as Google or Microsoft might read the article, and who knows, maybe in another 40 years we will have SPL! It would be a much better world indeed.
Did anyone translate the binary at the end of the article? -- it translates to:
Good luck to you all!
SPL?! Heaven help us! ...
I think the authors point was to have a standard with regard to common tasks in the programming world; as mentioned in the article, loops, conditionals, data types, etc -- who cares what the standard is called -- just have a standard ! I agree completely with the author, why do we need a dozen or more symbols to denote something like "equal to"? Choose one and be done with it.
Yeah... just choose the right one! 😉
Perhaps that is why the author mentioned a vote. Those of us in the trenches might have more say than the so-called "language purists" 🙂
If you consider how some alleged "Best Practices" are born, I'll pass on the voting thing.
Given that the electorate would be the developers anddbas and managers who have participated in the reduction of standards in both code quality and documentation and have brought us to the point where the vast majority of people applying for 6 figure salary jobs requiring SQL Server expertise don't even know how to get the current date and time, let alone write useful queries or describe a sane backup and recovery strategy, it seems to me that the majority of voters would make horribly wrong choices. So I'm 100% with you here, Jeff.
On top of that, I'm amazed to see people thinking that the Unknown Programmer's rant (the document the editorial links to) is all good. While his objection to the deterioration of documentation standards his and dislike of the pointless churn of procedural programming languages and related tools are well founded (indeed they are something we should all regard as good and agree with) the nonsense statement that we all write loops is just that: pure nonsense. I can see the reason for writing loops in procedural languages - indeed in every language with control flow that I know, although some control-flow languages (eg SQL) minimise the need for them (despite many writers in those languages thinking loops are the answer to everything, a cause of much bad code in those languages). But I can't imagine why anyone thinks that people writing in declarative languages (functional languages, logic languages, maybe some others) will write loops - after all, these languages don't have any control flow constructs at all, - control flow is determined either at compile time or at run time, not at coding time. I guess the Unknown Programmer has never used a declarative language.
So excessive standardisation is likely to be a bad thing. There are a lot of requirements that would be extremely expensive to meet using control flow languages, and much less expensive to meet using declarative languages. For example the first decent constraint resolution tool commercially released (way back in the 1980s) was written in Prolog (I know about that one because it was me that was handed the task of evaluating the research project and deciding whether to invest in commercialising it or not). Any standardisation by popular voting to determine the individual pieces of a new single universal programming language is bound to result in an appallingly bad control-flow-oriented monstrosity wiith vast freedom to get things wrong - perhaps we'd end up with something as awful as C++ or perhaps we'd be unlucky and end up with something even worse.
I don't think the author was trying to standardize ALL languages, just some of the common tasks programmers (not necessarily SQL developers) use. Loops may not have a place in the SQL syntax world -- but in the programming world (compiled or interpreted) -- your damn right they do -- and I for one would LOVE to see a common syntax for loops, data types and conditional operators. Like the author said, if just those few points were addressed, everyone's life would be easier. But alas, just looking at all the comments the article has generated proves the point that the programming world will remain wild.
August 4, 2017 at 10:58 pm
bdcoder - Friday, August 4, 2017 10:33 PMTomThomson - Friday, August 4, 2017 5:57 PMJeff Moden - Friday, August 4, 2017 3:09 PMbdcoder - Thursday, August 3, 2017 9:14 AMJeff Moden - Thursday, August 3, 2017 9:03 AMbdcoder - Thursday, August 3, 2017 7:45 AMTomThomson - Thursday, August 3, 2017 7:08 AMbdcoder - Friday, July 21, 2017 8:31 AMExcellent points brought up by the author of 40 Years of Programming ! I don't think he or she was wanting paper documentation to come back -- all they wanted was meaningful documentation -- which I agree, is sorely lacking these days!I also agree that we should have a set of (syntax) standards for common tasks in programming, as mentioned in the article. Hopefully, a large software company such as Google or Microsoft might read the article, and who knows, maybe in another 40 years we will have SPL! It would be a much better world indeed.
Did anyone translate the binary at the end of the article? -- it translates to:
Good luck to you all!
SPL?! Heaven help us! ...
I think the authors point was to have a standard with regard to common tasks in the programming world; as mentioned in the article, loops, conditionals, data types, etc -- who cares what the standard is called -- just have a standard ! I agree completely with the author, why do we need a dozen or more symbols to denote something like "equal to"? Choose one and be done with it.
Yeah... just choose the right one! 😉
Perhaps that is why the author mentioned a vote. Those of us in the trenches might have more say than the so-called "language purists" 🙂
If you consider how some alleged "Best Practices" are born, I'll pass on the voting thing.
Given that the electorate would be the developers anddbas and managers who have participated in the reduction of standards in both code quality and documentation and have brought us to the point where the vast majority of people applying for 6 figure salary jobs requiring SQL Server expertise don't even know how to get the current date and time, let alone write useful queries or describe a sane backup and recovery strategy, it seems to me that the majority of voters would make horribly wrong choices. So I'm 100% with you here, Jeff.
On top of that, I'm amazed to see people thinking that the Unknown Programmer's rant (the document the editorial links to) is all good. While his objection to the deterioration of documentation standards his and dislike of the pointless churn of procedural programming languages and related tools are well founded (indeed they are something we should all regard as good and agree with) the nonsense statement that we all write loops is just that: pure nonsense. I can see the reason for writing loops in procedural languages - indeed in every language with control flow that I know, although some control-flow languages (eg SQL) minimise the need for them (despite many writers in those languages thinking loops are the answer to everything, a cause of much bad code in those languages). But I can't imagine why anyone thinks that people writing in declarative languages (functional languages, logic languages, maybe some others) will write loops - after all, these languages don't have any control flow constructs at all, - control flow is determined either at compile time or at run time, not at coding time. I guess the Unknown Programmer has never used a declarative language.
So excessive standardisation is likely to be a bad thing. There are a lot of requirements that would be extremely expensive to meet using control flow languages, and much less expensive to meet using declarative languages. For example the first decent constraint resolution tool commercially released (way back in the 1980s) was written in Prolog (I know about that one because it was me that was handed the task of evaluating the research project and deciding whether to invest in commercialising it or not). Any standardisation by popular voting to determine the individual pieces of a new single universal programming language is bound to result in an appallingly bad control-flow-oriented monstrosity wiith vast freedom to get things wrong - perhaps we'd end up with something as awful as C++ or perhaps we'd be unlucky and end up with something even worse.
I don't think the author was trying to standardize ALL languages, just some of the common tasks programmers (not necessarily SQL developers) use. Loops may not have a place in the SQL syntax world -- but in the programming world (compiled or interpreted) -- your damn right they do -- and I for one would LOVE to see a common syntax for loops, data types and conditional operators. Like the author said, if just those few points were addressed, everyone's life would be easier. But alas, just looking at all the comments the article has generated proves the point that the programming world will remain wild.
They have a common syntax for "loops" in SQL... SELECT, INSERT, UPDATE, and DELETE. In DOS, they have ForFiles and several other wonders. And it's a real shame that SQL isn't compiled except for a minor brush with compiled code in SQL Server 2016. Imagine the possibilities.
Heh... now, if we could just get them to write a useful splitter. 😉
--Jeff Moden
Change is inevitable... Change for the better is not.
August 6, 2017 at 6:45 am
bdcoder - Friday, August 4, 2017 10:33 PMI don't think the author was trying to standardize ALL languages, just some of the common tasks programmers (not necessarily SQL developers) use. Loops may not have a place in the SQL syntax world -- but in the programming world (compiled or interpreted) -- your damn right they do -- and I for one would LOVE to see a common syntax for loops, data types and conditional operators. Like the author said, if just those few points were addressed, everyone's life would be easier. But alas, just looking at all the comments the article has generated proves the point that the programming world will remain wild.
No, loops and GOTOs and all the associated control flow stuff in Procedural languages have NO place in programming at any level above assembly which directly expresses machine code. Since the late 60s we've had languages that are Turing-complete (ie are capable of expresing any imaginable computation) without using any of that control-flow crap. A lot of programming has been done in Functional languages (various dialects of ML, Miranda, and so on - and recently quite a lot in Haskell) and in Logic languages (mostly variants of Prolog and Parlog) and it has been clearly demonstrated for most application areas that developers writing in these languages manage to write far fewer bugs than developers writing in procedural languages. Too many computer professionals are blind to this, either not sufficiently interested in learning anything about computing beyond the minimum they can get away with, or believing they have a vested interest in procedural languages they have learnt, or having been "educated" in programming by professors whose knowledge is sadly restricted (and hence have a vested interest in teaching the procedural languages that they know).
I guess the continued general developer preference for rather horrible procedural languages is part of the contimuing wildness of the programming world, and it will be long time before common sense prevails. of course there are some signs that things are getting better, for example Microsoft's production of F# (which has some functional structure mixed in with procedural stuff).
Tom
August 6, 2017 at 9:31 am
TomThomson - Sunday, August 6, 2017 6:45 AMbdcoder - Friday, August 4, 2017 10:33 PMI don't think the author was trying to standardize ALL languages, just some of the common tasks programmers (not necessarily SQL developers) use. Loops may not have a place in the SQL syntax world -- but in the programming world (compiled or interpreted) -- your damn right they do -- and I for one would LOVE to see a common syntax for loops, data types and conditional operators. Like the author said, if just those few points were addressed, everyone's life would be easier. But alas, just looking at all the comments the article has generated proves the point that the programming world will remain wild.No, loops and GOTOs and all the associated control flow stuff in Procedural languages have NO place in programming at any level above assembly which directly expresses machine code. Since the late 60s we've had languages that are Turing-complete (ie are capable of expresing any imaginable computation) without using any of that control-flow crap. A lot of programming has been done in Functional languages (various dialects of ML, Miranda, and so on - and recently quite a lot in Haskell) and in Logic languages (mostly variants of Prolog and Parlog) and it has been clearly demonstrated for most application areas that developers writing in these languages manage to write far fewer bugs than developers writing in procedural languages. Too many computer professionals are blind to this, either not sufficiently interested in learning anything about computing beyond the minimum they can get away with, or believing they have a vested interest in procedural languages they have learnt, or having been "educated" in programming by professors whose knowledge is sadly restricted (and hence have a vested interest in teaching the procedural languages that they know).
I guess the continued general developer preference for rather horrible procedural languages is part of the contimuing wildness of the programming world, and it will be long time before common sense prevails. of course there are some signs that things are getting better, for example Microsoft's production of F# (which has some functional structure mixed in with procedural stuff).
Agreed -- but you have to admit, IF we did have some sort of standard within our soup of procedural languages, everyone lives would have been so much better -- THAT is what I think the author was trying to get across; and I agree with him or her.
August 6, 2017 at 10:35 am
bdcoder - Sunday, August 6, 2017 9:31 AMTomThomson - Sunday, August 6, 2017 6:45 AMbdcoder - Friday, August 4, 2017 10:33 PMI don't think the author was trying to standardize ALL languages, just some of the common tasks programmers (not necessarily SQL developers) use. Loops may not have a place in the SQL syntax world -- but in the programming world (compiled or interpreted) -- your damn right they do -- and I for one would LOVE to see a common syntax for loops, data types and conditional operators. Like the author said, if just those few points were addressed, everyone's life would be easier. But alas, just looking at all the comments the article has generated proves the point that the programming world will remain wild.No, loops and GOTOs and all the associated control flow stuff in Procedural languages have NO place in programming at any level above assembly which directly expresses machine code. Since the late 60s we've had languages that are Turing-complete (ie are capable of expresing any imaginable computation) without using any of that control-flow crap. A lot of programming has been done in Functional languages (various dialects of ML, Miranda, and so on - and recently quite a lot in Haskell) and in Logic languages (mostly variants of Prolog and Parlog) and it has been clearly demonstrated for most application areas that developers writing in these languages manage to write far fewer bugs than developers writing in procedural languages. Too many computer professionals are blind to this, either not sufficiently interested in learning anything about computing beyond the minimum they can get away with, or believing they have a vested interest in procedural languages they have learnt, or having been "educated" in programming by professors whose knowledge is sadly restricted (and hence have a vested interest in teaching the procedural languages that they know).
I guess the continued general developer preference for rather horrible procedural languages is part of the contimuing wildness of the programming world, and it will be long time before common sense prevails. of course there are some signs that things are getting better, for example Microsoft's production of F# (which has some functional structure mixed in with procedural stuff).Agreed -- but you have to admit, IF we did have some sort of standard within our soup of procedural languages, everyone lives would have been so much better -- THAT is what I think the author was trying to get across; and I agree with him or her.
I'm not so sure about that. One of the quickest ways to stifle innovation is to establish standards and "Best Practices". If you remove the opportunity to fail, you also remove the opportunity for success.
--Jeff Moden
Change is inevitable... Change for the better is not.
August 6, 2017 at 10:51 am
Jeff Moden - Sunday, August 6, 2017 10:35 AMbdcoder - Sunday, August 6, 2017 9:31 AMTomThomson - Sunday, August 6, 2017 6:45 AMbdcoder - Friday, August 4, 2017 10:33 PMI don't think the author was trying to standardize ALL languages, just some of the common tasks programmers (not necessarily SQL developers) use. Loops may not have a place in the SQL syntax world -- but in the programming world (compiled or interpreted) -- your damn right they do -- and I for one would LOVE to see a common syntax for loops, data types and conditional operators. Like the author said, if just those few points were addressed, everyone's life would be easier. But alas, just looking at all the comments the article has generated proves the point that the programming world will remain wild.No, loops and GOTOs and all the associated control flow stuff in Procedural languages have NO place in programming at any level above assembly which directly expresses machine code. Since the late 60s we've had languages that are Turing-complete (ie are capable of expresing any imaginable computation) without using any of that control-flow crap. A lot of programming has been done in Functional languages (various dialects of ML, Miranda, and so on - and recently quite a lot in Haskell) and in Logic languages (mostly variants of Prolog and Parlog) and it has been clearly demonstrated for most application areas that developers writing in these languages manage to write far fewer bugs than developers writing in procedural languages. Too many computer professionals are blind to this, either not sufficiently interested in learning anything about computing beyond the minimum they can get away with, or believing they have a vested interest in procedural languages they have learnt, or having been "educated" in programming by professors whose knowledge is sadly restricted (and hence have a vested interest in teaching the procedural languages that they know).
I guess the continued general developer preference for rather horrible procedural languages is part of the contimuing wildness of the programming world, and it will be long time before common sense prevails. of course there are some signs that things are getting better, for example Microsoft's production of F# (which has some functional structure mixed in with procedural stuff).Agreed -- but you have to admit, IF we did have some sort of standard within our soup of procedural languages, everyone lives would have been so much better -- THAT is what I think the author was trying to get across; and I agree with him or her.
I'm not so sure about that. One of the quickest ways to stifle innovation is to establish standards and "Best Practices". If you remove the opportunity to fail, you also remove the opportunity for success.
I think (like the author mentioned in the article) if the programming world had a bit more stability in it like the SQL world does (i.e: SELECT / FROM / WHERE has not been "stiffled" in any way over the years and those same small three words are a de-facto standard) things would have been much better; and there would have been even more opportunities for "success". 🙂
August 6, 2017 at 11:28 am
bdcoder - Sunday, August 6, 2017 10:51 AMJeff Moden - Sunday, August 6, 2017 10:35 AMbdcoder - Sunday, August 6, 2017 9:31 AMTomThomson - Sunday, August 6, 2017 6:45 AMbdcoder - Friday, August 4, 2017 10:33 PMI don't think the author was trying to standardize ALL languages, just some of the common tasks programmers (not necessarily SQL developers) use. Loops may not have a place in the SQL syntax world -- but in the programming world (compiled or interpreted) -- your damn right they do -- and I for one would LOVE to see a common syntax for loops, data types and conditional operators. Like the author said, if just those few points were addressed, everyone's life would be easier. But alas, just looking at all the comments the article has generated proves the point that the programming world will remain wild.No, loops and GOTOs and all the associated control flow stuff in Procedural languages have NO place in programming at any level above assembly which directly expresses machine code. Since the late 60s we've had languages that are Turing-complete (ie are capable of expresing any imaginable computation) without using any of that control-flow crap. A lot of programming has been done in Functional languages (various dialects of ML, Miranda, and so on - and recently quite a lot in Haskell) and in Logic languages (mostly variants of Prolog and Parlog) and it has been clearly demonstrated for most application areas that developers writing in these languages manage to write far fewer bugs than developers writing in procedural languages. Too many computer professionals are blind to this, either not sufficiently interested in learning anything about computing beyond the minimum they can get away with, or believing they have a vested interest in procedural languages they have learnt, or having been "educated" in programming by professors whose knowledge is sadly restricted (and hence have a vested interest in teaching the procedural languages that they know).
I guess the continued general developer preference for rather horrible procedural languages is part of the contimuing wildness of the programming world, and it will be long time before common sense prevails. of course there are some signs that things are getting better, for example Microsoft's production of F# (which has some functional structure mixed in with procedural stuff).Agreed -- but you have to admit, IF we did have some sort of standard within our soup of procedural languages, everyone lives would have been so much better -- THAT is what I think the author was trying to get across; and I agree with him or her.
I'm not so sure about that. One of the quickest ways to stifle innovation is to establish standards and "Best Practices". If you remove the opportunity to fail, you also remove the opportunity for success.
I think (like the author mentioned in the article) if the programming world had a bit more stability in it like the SQL world does (i.e: SELECT / FROM / WHERE has not been "stiffled" in any way over the years and those same small three words are a de-facto standard) things would have been much better; and there would have been even more opportunities for "success". 🙂
Several stifling attempts have been made in the world of SQL. For example, there is and has been a move underfoot to make the UPDATE statement more like that of Oracle in that they want to remove the FROM clause from the SQL Server version because it allows people to make a mistake. There's also the stifling "Best Practice", touted by many, to never do direct date math even though the ANSI Standards specifically state that EndDateTime-StartDateTime shall result in a period (interval). Same goes for a "variable overlay" because "it's unreliable", which is only true if you use it the wrong way and people frequently do while others use it with great success when using it within its limitations.
--Jeff Moden
Change is inevitable... Change for the better is not.
August 6, 2017 at 12:01 pm
Jeff Moden - Sunday, August 6, 2017 11:28 AMbdcoder - Sunday, August 6, 2017 10:51 AMJeff Moden - Sunday, August 6, 2017 10:35 AMbdcoder - Sunday, August 6, 2017 9:31 AMTomThomson - Sunday, August 6, 2017 6:45 AMbdcoder - Friday, August 4, 2017 10:33 PMI don't think the author was trying to standardize ALL languages, just some of the common tasks programmers (not necessarily SQL developers) use. Loops may not have a place in the SQL syntax world -- but in the programming world (compiled or interpreted) -- your damn right they do -- and I for one would LOVE to see a common syntax for loops, data types and conditional operators. Like the author said, if just those few points were addressed, everyone's life would be easier. But alas, just looking at all the comments the article has generated proves the point that the programming world will remain wild.No, loops and GOTOs and all the associated control flow stuff in Procedural languages have NO place in programming at any level above assembly which directly expresses machine code. Since the late 60s we've had languages that are Turing-complete (ie are capable of expresing any imaginable computation) without using any of that control-flow crap. A lot of programming has been done in Functional languages (various dialects of ML, Miranda, and so on - and recently quite a lot in Haskell) and in Logic languages (mostly variants of Prolog and Parlog) and it has been clearly demonstrated for most application areas that developers writing in these languages manage to write far fewer bugs than developers writing in procedural languages. Too many computer professionals are blind to this, either not sufficiently interested in learning anything about computing beyond the minimum they can get away with, or believing they have a vested interest in procedural languages they have learnt, or having been "educated" in programming by professors whose knowledge is sadly restricted (and hence have a vested interest in teaching the procedural languages that they know).
I guess the continued general developer preference for rather horrible procedural languages is part of the contimuing wildness of the programming world, and it will be long time before common sense prevails. of course there are some signs that things are getting better, for example Microsoft's production of F# (which has some functional structure mixed in with procedural stuff).Agreed -- but you have to admit, IF we did have some sort of standard within our soup of procedural languages, everyone lives would have been so much better -- THAT is what I think the author was trying to get across; and I agree with him or her.
I'm not so sure about that. One of the quickest ways to stifle innovation is to establish standards and "Best Practices". If you remove the opportunity to fail, you also remove the opportunity for success.
I think (like the author mentioned in the article) if the programming world had a bit more stability in it like the SQL world does (i.e: SELECT / FROM / WHERE has not been "stiffled" in any way over the years and those same small three words are a de-facto standard) things would have been much better; and there would have been even more opportunities for "success". 🙂
Several stifling attempts have been made in the world of SQL. For example, there is and has been a move underfoot to make the UPDATE statement more like that of Oracle in that they want to remove the FROM clause from the SQL Server version because it allows people to make a mistake. There's also the stifling "Best Practice", touted by many, to never do direct date math even though the ANSI Standards specifically state that EndDateTime-StartDateTime shall result in a period (interval). Same goes for a "variable overlay" because "it's unreliable", which is only true if you use it the wrong way and people frequently do while others use it with great success when using it within its limitations.
Good points, but I would still rather live (and work) in the SQL world than the "procedural programming" world of today! I, like the author, have always found the SQL world contains many more "standards" than other areas of computing! All the best!
August 6, 2017 at 4:37 pm
bdcoder - Sunday, August 6, 2017 12:01 PMJeff Moden - Sunday, August 6, 2017 11:28 AMbdcoder - Sunday, August 6, 2017 10:51 AMJeff Moden - Sunday, August 6, 2017 10:35 AMbdcoder - Sunday, August 6, 2017 9:31 AMTomThomson - Sunday, August 6, 2017 6:45 AMbdcoder - Friday, August 4, 2017 10:33 PMI don't think the author was trying to standardize ALL languages, just some of the common tasks programmers (not necessarily SQL developers) use. Loops may not have a place in the SQL syntax world -- but in the programming world (compiled or interpreted) -- your damn right they do -- and I for one would LOVE to see a common syntax for loops, data types and conditional operators. Like the author said, if just those few points were addressed, everyone's life would be easier. But alas, just looking at all the comments the article has generated proves the point that the programming world will remain wild.No, loops and GOTOs and all the associated control flow stuff in Procedural languages have NO place in programming at any level above assembly which directly expresses machine code. Since the late 60s we've had languages that are Turing-complete (ie are capable of expresing any imaginable computation) without using any of that control-flow crap. A lot of programming has been done in Functional languages (various dialects of ML, Miranda, and so on - and recently quite a lot in Haskell) and in Logic languages (mostly variants of Prolog and Parlog) and it has been clearly demonstrated for most application areas that developers writing in these languages manage to write far fewer bugs than developers writing in procedural languages. Too many computer professionals are blind to this, either not sufficiently interested in learning anything about computing beyond the minimum they can get away with, or believing they have a vested interest in procedural languages they have learnt, or having been "educated" in programming by professors whose knowledge is sadly restricted (and hence have a vested interest in teaching the procedural languages that they know).
I guess the continued general developer preference for rather horrible procedural languages is part of the contimuing wildness of the programming world, and it will be long time before common sense prevails. of course there are some signs that things are getting better, for example Microsoft's production of F# (which has some functional structure mixed in with procedural stuff).Agreed -- but you have to admit, IF we did have some sort of standard within our soup of procedural languages, everyone lives would have been so much better -- THAT is what I think the author was trying to get across; and I agree with him or her.
I'm not so sure about that. One of the quickest ways to stifle innovation is to establish standards and "Best Practices". If you remove the opportunity to fail, you also remove the opportunity for success.
I think (like the author mentioned in the article) if the programming world had a bit more stability in it like the SQL world does (i.e: SELECT / FROM / WHERE has not been "stiffled" in any way over the years and those same small three words are a de-facto standard) things would have been much better; and there would have been even more opportunities for "success". 🙂
Several stifling attempts have been made in the world of SQL. For example, there is and has been a move underfoot to make the UPDATE statement more like that of Oracle in that they want to remove the FROM clause from the SQL Server version because it allows people to make a mistake. There's also the stifling "Best Practice", touted by many, to never do direct date math even though the ANSI Standards specifically state that EndDateTime-StartDateTime shall result in a period (interval). Same goes for a "variable overlay" because "it's unreliable", which is only true if you use it the wrong way and people frequently do while others use it with great success when using it within its limitations.
Good points, but I would still rather live (and work) in the SQL world than the "procedural programming" world of today! I, like the author, have always found the SQL world contains many more "standards" than other areas of computing! All the best!
Absolutely agreed on the "where to live and work" notion. I gave up on the front end world of programming at the end of 2002 and haven't looked back since for many of the reasons stated and more. But SQL isn't "standard" by any means... not even for SELECT. In SQL Server, I can do variable overloading. In Oracle, I cannot ()just as one example). In SQL Server (not including the 4 letter words like SSIS, SSRS, SSAS, etc), I get all of what is available whether it's "standard" SQL or some of the proprietary functionality. In Oracle, you have to change the way you code because you have "standard" and PL-SQL they don't really play well with each other.
--Jeff Moden
Change is inevitable... Change for the better is not.
Viewing 15 posts - 46 through 60 (of 78 total)
You must be logged in to reply to this topic. Login to reply