July 20, 2017 at 9:29 pm
Comments posted to this topic are about the item Looking Back
July 21, 2017 at 2:28 am
In my day it was all fields round here etc etc ...
I definitely would not want to go back to learning techniques from paper magazines that circulate that's for sure.
While we do often have too trust the magic you do find that unless your careful getting someone else's project and trying to edit it still just doesn't work. That's where the real understanding is needed, to make stuff that reliably translates from system to system.
July 21, 2017 at 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.)
July 21, 2017 at 4:32 am
Wait till you have to add === into the mix 😉
July 21, 2017 at 4:34 am
Well, I don't have 40 years... but I certainly agree with many of these points. Particularly those about documentation (or more accurately, the total lack of it) and error handling.
I appreciate how a lot of developers don't like writing or updating documentation, I have to admit that I am one of these because documentation takes me longer to do than other steps in the development process because I can never quite get it good enough, in my view, first time and therefore have to keep tinkering with it which wastes time. On the other hand, I fully understand the value and importance of good documentation and the lack of it in many projects wastes a considerable amount of time (money) and often introduces bugs through unintended consequences. My particular ire is reserved for developers whose response to "where is the documentation?" is "read the source code" or those who are under the ridiculous impression that videos of a developer droning on about functions and point and clicking to demonstrate their use is in any way documentation - it's rarely even useful training.
As 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.
July 21, 2017 at 4:54 am
As 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. ..."
July 21, 2017 at 5:08 am
paul 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 🙂
July 21, 2017 at 5:28 am
Lots 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.
July 21, 2017 at 5:43 am
archie 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
July 21, 2017 at 5:53 am
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
Nothing stops you from using upper and lower case for readability , even if the language treats both of them the same.
July 21, 2017 at 6:11 am
funbi - Friday, July 21, 2017 4:32 AMWait till you have to add === into the mix 😉
Have you been using that nasty JavaScript? And there is also !==
The lack of any standards in programming languages is an irritation; having to switch between C and Python ( can catch myself out. Whilst I try and make my code legible by layout, meaningful identifiers and sometimes extra brackets for clarity I often find myself debugging others "horrible" code!
July 21, 2017 at 6:59 am
I agree with the original article writer on many issues, mainly because I've got 35 years of computer use under my belt. (That explains my waist line!)
July 21, 2017 at 7:03 am
funbi - Friday, July 21, 2017 4:32 AMWait till you have to add === into the mix 😉
And there's always := and =>
😛
July 21, 2017 at 7:42 am
Regarding the observation that the pace or quality of documentation often doesn't keep up with the pace of software development, one factor is that documentation is often left up to someone who is not really a system analyst or technical writer by profession. It's just someone from the business or maybe QA who gets assigned the task because there is noone else to do it. It's a one-time event; probably the first and last time they'll ever write up a requirements document or system documentation.
"Do not seek to follow in the footsteps of the wise. Instead, seek what they sought." - Matsuo Basho
July 21, 2017 at 8:23 am
From 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. 😉
--Jeff Moden
Change is inevitable... Change for the better is not.
Viewing 15 posts - 1 through 15 (of 78 total)
You must be logged in to reply to this topic. Login to reply