July 21, 2017 at 2:51 pm
sknox - Friday, July 21, 2017 11:34 AMZZartin - Friday, July 21, 2017 8:42 AMarchie flockhart - Friday, July 21, 2017 5:28 AMnLots of interesting points in the article. Case sensitive variable names are one of my pet hates. I've never seen a persuasive case that there is any advantage to being able to have distinct variables UserName, username, and Username ; but it introduces lots of potential errors and confusion.
I've also never seen a case for case insensitive 😀
...You never discuss your code verbally?
If you have objects which differ only in case, you cannot coherently speak to another person about them; you have to pepper your statement with descriptors and qualifiers to ensure they know which specific case-sensitive thing you're referring to.
Now how about a developer who loses their ability to physically type and has to dictate their code. Can you imagine having to dictate, say, proper camelCase of every singleObject every single time you have to refer to it?
One of the things I do lament is the declining quality of documentation.
I wanted to be sure about something to do with PowerShell yesterday, so I searched Microsoft's documentation site for the PowerShell grammar. What did I find? A blog post from over a decade ago with the developer begrudgingly providing a draft grammar because so many people had asked for it (which raises the question of how the language got as far as it had at that point without a grammar...). This was a plain text dump, incomplete, and now out-of-date. And that was it.
I know this isn't exactly the same thing but your reply reminded me of a documentation problem I don't like. Whenever I search the Internet with Bing/Google/your-search-engine-of-choice something I do not like at all is finding some website/blog that hasn't any date associated with it. I always consider more recent documentation to be higher than older documentation. But how can I tell there's no date? Maybe it was published a month ago. Maybe 15 years ago.
Kindest Regards, Rod Connect with me on LinkedIn.
July 21, 2017 at 6:19 pm
ZZartin - Friday, July 21, 2017 8:42 AMI've also never seen a case for case insensitive 😀
1. Lack of design standards by most people that do the designing.
2. Can you imagine having object_id, Object_id, Object_ID, and object_ID all in the same table?
3. Lousy downloads/imports that would require conversion to all upper, all lower, or something else just so you can find a something by name.
--Jeff Moden
Change is inevitable... Change for the better is not.
July 22, 2017 at 5:56 pm
ZZartin - Friday, July 21, 2017 10:09 AMChris Harshman - Friday, July 21, 2017 9:28 AMn.ryan - Friday, July 21, 2017 4:34 AMAs for error handling: religious wars and arguments about the use of the comic sans typeface are right up there with error handling compared to exception handling. While my preference is that expected errors should be handled cleanly and neatly and everything else is, well, an exception, it really doesn't matter as long as it's documented well enough. This ties right in back to the point about the (lack of) documentation.What I hate is when people try to do too much error handling, but do it poorly, and their code ends up swallowing or obfuscating the actual error that happened, making it harder to troubleshoot.
What's annoying is when different groups can't agree on what should be a hard error and what should be some kind of return message to be handled by the calling party. Working on a project now and several different groups of coders handle errors in spectrum from throw a hard error, some kind of error code in the returns, to success with all negative return values, to success with an obscure nested message indicating something might be wrong to simply success regardless of what happened :angry:
Heh... you forgot about just letting SQL Server handle the errors, which is normally well enough.
This is why we have standards where I work. Saves a whole lot on arguments especially when new folks enter the house. The rule is, if you have a better idea, let's talk about it and, if it's a good thing, we'll implement it and change the standards. In the meantime, follow the standards.
--Jeff Moden
Change is inevitable... Change for the better is not.
July 24, 2017 at 12:24 pm
Jeff Moden - Friday, July 21, 2017 2:13 PMSteve Jones - SSC Editor - Friday, July 21, 2017 12:16 PMKGERBR - Friday, July 21, 2017 10:21 AMCan you imagine having to go thru all your SQL code and change = to == ... but only for comparisons and not for assignments?
LOL
No, but I'd love to have this being a refactoring point across a decade. Add == and in SQL Server 2028, remove = for comparisons.
== is just stupid, IMHO. In this day and age of all this talk about AI and machine learning, if the compiler can't figure out the difference between relational comparisons and assignments, then you might want to avoid the compiler.
Its a bit worse than stupid actually, for example in c, the construct "if (a=b) { whatever } is not a syntax error, but in reality its an assignment, and assignment statements return a value that can evaluate to a Boolean. Been bit by that one a few times.
July 24, 2017 at 12:53 pm
Jeff Moden - Saturday, July 22, 2017 5:55 PMZZartin - Friday, July 21, 2017 10:09 AMChris Harshman - Friday, July 21, 2017 9:28 AMn.ryan - Friday, July 21, 2017 4:34 AMAs for error handling: religious wars and arguments about the use of the comic sans typeface are right up there with error handling compared to exception handling. While my preference is that expected errors should be handled cleanly and neatly and everything else is, well, an exception, it really doesn't matter as long as it's documented well enough. This ties right in back to the point about the (lack of) documentation.What I hate is when people try to do too much error handling, but do it poorly, and their code ends up swallowing or obfuscating the actual error that happened, making it harder to troubleshoot.
What's annoying is when different groups can't agree on what should be a hard error and what should be some kind of return message to be handled by the calling party. Working on a project now and several different groups of coders handle errors in spectrum from throw a hard error, some kind of error code in the returns, to success with all negative return values, to success with an obscure nested message indicating something might be wrong to simply success regardless of what happened :angry:
Heh... you forgot about just letting SQL Server handle the errors, which is normally well enough.
This is why we have standards where I work. Saves a whole lot on arguments especially when new folks enter the house. The rule is, if you have a better idea, let's talk about it and, if it's a good thing, we'll implement it and change the standards. In the meantime, follow the standards.
I think the new standard for getting the date and time in all SQL code should be a data entry box that someone monitors 24x7x365 and the instant it comes up on their screen they have to enter the current time (accurate to 1/1000 of a second) by hand.
So lets change those standards!
July 24, 2017 at 1:05 pm
I'm not terribly bothered by case sensitivity. Once your objects are declared, and you don't have identically spelled objects that differ only in case, most of the disadvantages go away in my opinion, and even with case sensitive languages, having objects of the same type named the same but cased differently seems to be considered a code smell.
Even with the instances I see in c# (type in camel case, instances in lower case) really don't seem to be all that difficult even to talk about. I've chatted about c# before and you only run into laborious conversations if the programmer(s) are absolute beginners and you're spelling things out for them and need to tell them something is a class or an instance or trying to put together a syntactically correct statement or something along those lines.
Its probably an instance of experience having to do with how well you handle case sensitive languages.
July 24, 2017 at 1:26 pm
jasona.work - Monday, July 24, 2017 12:53 PMI think the new standard for getting the date and time in all SQL code should be a data entry box that someone monitors 24x7x365 and the instant it comes up on their screen they have to enter the current time (accurate to 1/1000 of a second) by hand.So lets change those standards!
And, as an aside, let's change the way people use 24*7*365 to mean one year, when it should mean seven 😉
The absence of evidence is not evidence of absence.
Martin Rees
You can lead a horse to water, but a pencil must be lead.
Stan Laurel
July 24, 2017 at 7:09 pm
jasona.work - Monday, July 24, 2017 12:53 PMJeff Moden - Saturday, July 22, 2017 5:55 PMZZartin - Friday, July 21, 2017 10:09 AMChris Harshman - Friday, July 21, 2017 9:28 AMn.ryan - Friday, July 21, 2017 4:34 AMAs for error handling: religious wars and arguments about the use of the comic sans typeface are right up there with error handling compared to exception handling. While my preference is that expected errors should be handled cleanly and neatly and everything else is, well, an exception, it really doesn't matter as long as it's documented well enough. This ties right in back to the point about the (lack of) documentation.What I hate is when people try to do too much error handling, but do it poorly, and their code ends up swallowing or obfuscating the actual error that happened, making it harder to troubleshoot.
What's annoying is when different groups can't agree on what should be a hard error and what should be some kind of return message to be handled by the calling party. Working on a project now and several different groups of coders handle errors in spectrum from throw a hard error, some kind of error code in the returns, to success with all negative return values, to success with an obscure nested message indicating something might be wrong to simply success regardless of what happened :angry:
Heh... you forgot about just letting SQL Server handle the errors, which is normally well enough.
This is why we have standards where I work. Saves a whole lot on arguments especially when new folks enter the house. The rule is, if you have a better idea, let's talk about it and, if it's a good thing, we'll implement it and change the standards. In the meantime, follow the standards.
I think the new standard for getting the date and time in all SQL code should be a data entry box that someone monitors 24x7x365 and the instant it comes up on their screen they have to enter the current time (accurate to 1/1000 of a second) by hand.
So lets change those standards!
Heh... careful now... some people might think that's somehow a good idea. 😉
--Jeff Moden
Change is inevitable... Change for the better is not.
August 2, 2017 at 6:46 pm
paul s-306273 - Friday, July 21, 2017 3:05 AM'The one thing I do wish was in all languages is a standard way of handling data types and comparing them.'
I wish the standard was to look like Algol 60, but can't imagine I'll get may backers for that.
(R looks a bit like Algol though.)
I'd rather see it look like Algol 68 than Algol 60 - but looking like Algol 60 woud certainly be better that looking like C or C++.
Tom
August 2, 2017 at 6:55 pm
n.ryan - Friday, July 21, 2017 5:08 AMpaul s-306273 - Friday, July 21, 2017 4:54 AMAs Tony Hoare said :
"...The view that documentation is something that is added to a program after it has been commissioned seems to be wrong in principle and counterproductive in practice. Instead,documentation must be regarded as an integral part of the process of design and coding. ..."Exactly 🙂
Actually I think CARH got that one wrong - an important part of documentation is the description of what the software is required to do, and that has to be written down clearly and understandably before any design or coding begins. Although he didn't actually get it wrong when he needed to solve the problem of not having done it - just when he summarised part of the real story about documentation and forgot to include the front end.
Tom
August 2, 2017 at 7:01 pm
funbi - Friday, July 21, 2017 5:43 AMarchie flockhart - Friday, July 21, 2017 5:28 AMLots of interesting points in the article. Case sensitive variable names are one of my pet hates. I've never seen a persuasive case that there is any advantage to being able to have distinct variables UserName, username, and Username ; but it introduces lots of potential errors and confusion.
Case sensitivity does more good than harm
Consider a string type vs a String type in C# for example
Case is an indication of scope (if you choose it to be), and case sensitive variable names improve code readability
Compiler has less work to do if case sensitivity is enforced
i'm with archie f. I want everything to be case insensitive unles it is explicitly stated by the coder or the language to be case sensitive and they provide a decent justification for introducing case sensitivity. And when the language designer or the coder introduces stupidity like "string type" being something other that "String type" that's a nice demonstration that whichever or them did it is an idiot who isn't awake enough to realise that we sometimes want to speak and hear our code, rather that write it and read it.
So funbi has given us, without realising it, a nice example of how the designers of C# got it wrong (of course starting from C++ was already more than wrong enough).
Tom
August 3, 2017 at 5:39 am
chrisn-585491 - Friday, July 21, 2017 7:03 AMfunbi - Friday, July 21, 2017 4:32 AMWait till you have to add === into the mix 😉And there's always := and =>
😛
These problem are caused by the lack of foresight of early language designers, and their willingness to accept text input devices that had an appallingly small character repertoire. Way back in 1967 I found the contrast between the input repertoire of the typewriter my thesis was typed on and the repertoire of computer languages (a full range of mathematical symbols, plus Latin alphabet with full set of accented and umplauted vowels and also marked consonants - things like "less than or equals" (≤) and "not equal" and "is not in" were all single characters, plus full Greek and Hebrew alphabets when I was writing mathematics, and all multiple characters on which there was no agreement between Fortran and Algol and other anguages so that I had to remember half a dozen different strings for simple operators and pick the right one for whichever programming language I was using when I was doing anything with computers). I guess the decision to use 7 bit (plus parity check) characterssome time in the mists of history was the cause of programming languages going down the wrong track.
Tom
August 3, 2017 at 6:15 am
Jeff Moden - Friday, July 21, 2017 8:23 AMFrom the article:
One of the things I do lament is the declining quality of documentation.Not only documentation but I also lament the serious decline in the quality of code (never enough time to do it right but always enough time to patch it... again, and again, and again), the lack of intuitive interfaces, the ever increasing number of clicks (especially in MS Office products) that it takes to get to the same lame menus as before, the deprecation/discontinuation of features because some out of touch committee made the decision to do so, the release of partial features such as what they originally did with ROW_NUMBER() etc, the current sorry condition of PIVOT and SPLIT_STRING() (for example) and FORMAT, extremely short-sighted implementations such as DATETIME2, DATE, and TIME (doesn't meet the ANSI standard of @EndDate-@StartDate=Duration, like DATETIME always has), the lack of response by the same out of touch committee that has not seen the benefit of providing a Tally-Table-Like-Function for more than a decade now, and the ridiculous notions that things like SSMS and BOL should be treated like separate products.
And then there are certain forums that used to work beautifully that get updated and functionality and quality died on the vine and some committee made the conscious decision to not support things like Internet Explorer but also didn't make things work for other browsers like they used to. 😉
While I agree that code quality is declining (probably because the ration of incompetent to competent programmers and designers has increased, partly, I think, as a result of far more having to be recruited and partly because most employers don't think they should provide any training) I would say that documentation quality has deteriorated more than code quality has. Part of the decline is because management generally doesn't care about quality, only about release dates (which is why test-based development isn't a remedy for the deterioration of code quality - test based development doesn't improve quality when a failed test doesn't lead a fix because it's better to release a broken product on time than release a working problem late) and the reason that documentation quality has deteriorated more that code quality is partly the management caresless about documentation than about code and partly because many of the people who should do teh documentation think documentation is a boring menial task beneath their dignity and really not worth doing at all, let alone doing properly.
Tom
August 3, 2017 at 6:17 am
TomThomson - Wednesday, August 2, 2017 7:01 PMfunbi - Friday, July 21, 2017 5:43 AMarchie flockhart - Friday, July 21, 2017 5:28 AMLots of interesting points in the article. Case sensitive variable names are one of my pet hates. I've never seen a persuasive case that there is any advantage to being able to have distinct variables UserName, username, and Username ; but it introduces lots of potential errors and confusion.
Case sensitivity does more good than harm
Consider a string type vs a String type in C# for example
Case is an indication of scope (if you choose it to be), and case sensitive variable names improve code readability
Compiler has less work to do if case sensitivity is enforcedi'm with archie f. I want everything to be case insensitive unles it is explicitly stated by the coder or the language to be case sensitive and they provide a decent justification for introducing case sensitivity. And when the language designer or the coder introduces stupidity like "string type" being something other that "String type" that's a nice demonstration that whichever or them did it is an idiot who isn't awake enough to realise that we sometimes want to speak and hear our code, rather that write it and read it.
So funbi has given us, without realising it, a nice example of how the designers of C# got it wrong (of course starting from C++ was already more than wrong enough).
The other day I was given someone's code to debug. I had given them some examples to follow a few weeks ago but they had found that you could be case insensitive. It made it quite hard to read especially as the case used appeared to be random! I blame all this texting myself!
August 3, 2017 at 7:08 am
bdcoder - 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! There are already languages called SPL - one is Space Programming Language (the langage controlled and released by the USAF's JOVIAL Pogram Office, originally a dialect of JOVIAL - see http://oai.dtic.mil/oai/oai?verb=getRecord&metadataPrefix=html&identifier=AD0679136 for a brief note about a fairly early variant of the language - it has been the subject of at least 2 MIL standards since then). Another is Spatial Programming Language (which is about yet another approach to large-scale small-grain parallelism, I think), see http://www.openspl.org/what-is-openspl/ for the "OPEN" version. Then there's Shakespeare Programming Language which, according to its inventors, combines the expresiveness of BASIC with the user-friendliness of Assembler.
I don't think any of those would be helpful for most programming (although SPL/Jovial was quite used for military aircraft on-plane softwre and for parts of the US space program so is clearlu useful for some programming - although they're now converting most of what's still needed of that code to C, a really low-level language which invites you to write horrible bugs because its type system can't work as it can't type references).
Tom
Viewing 15 posts - 31 through 45 (of 78 total)
You must be logged in to reply to this topic. Login to reply