|
It's unfortunately not our BTM, but our client's. We have no say in that. 
In order to understand stack overflow, you must first understand stack overflow.
|
|
|
|
|
Reminds me of a user I was helping some 20 years ago.
He told me that whenever he pressed a certain key on his keyboard his machine would restart.
So he demonstrated and the machine did indeed restart.
I also noticed that he had a ring binder folder on the desk and every time he would lean forwards to press the key, the binder would move forwards and the right corner of it would press the restart button on the box.
I really should have just kept my mouth shut and not pointed out to him what was going on 
“That which can be asserted without evidence, can be dismissed without evidence.”
― Christopher Hitchens
modified 3-Aug-18 3:15am.
|
|
|
|
|
Poor guy 
In order to understand stack overflow, you must first understand stack overflow.
|
|
|
|
|
Very similar situation: A lady at church complained that every time she started Word, it opened dozens of windows; on observation, I noticed that the heel of her palm was pressing the Enter key on the keypad.
Also, in the early days of PCs, the highest score on a simple game in our office was held by the office stapler which was leant against the space bar.
|
|
|
|
|
I like it! Nothing uncovers weirdness like random inputs. I have never had a tree available so I used to ask the cleaning lady to try things if I was working really late. She was practically random in her inputs and her testing did help us robustify things. I'm not sure if that's actually a word. What ever.
|
|
|
|
|
Rule #1: If the cleaning lady cannot crash it, release it.
... such stuff as dreams are made on
|
|
|
|
|
It has worked me quite well. Actually, I find it very useful to have someone test software who has virtually no knowledge of it because they do the most unexpected things.
|
|
|
|
|
|
Hahahaha...
And it's the first time you encounter such code hey?
Welcome to the club!
It seems to me that most code written by junior has such silly "exception handling"...
|
|
|
|
|
i have dealt with many madness in engineering. But this ticked me off. I cordially asked the engineer to fix. But he does not see the issue. but One good thing is he agreed to change the way i think it is okay
I do not fear of failure. I fear of giving up out of frustration.
|
|
|
|
|
maybe he doesn't know about "return" statement or "finally" clause?
|
|
|
|
|
But do you know about the "fault" clause?
It's like "finally", but only executes when an Exception was thrown.
It's basically like:
catch
{
throw;
}But faster since the Exception isn't actually caught and rethrown.
I guess it would look like:
fault
{
}The compiled MSIL code supports it, C# does not (which doesn't mean you can't use it[^]  ) 
|
|
|
|
|
wow, you got me there pal! 
|
|
|
|
|
Well, at first it seems that a simple if statement would do… However, if the condition should not occurs, it might be easier to find the problem during debugging if the debugger stop on exception or write something to the output log.
But let assume that some other code might also throw an Exception and if that case, you want to execute the code in catch clause too, then it might be acceptable after all if that code should not be executed if no exception are thrown.
As shown in the above example, all code can be removed as nothing else is done. In real code, it would not be the case! And the cleanest code to write directly depends on what missing code do and if some other code could throw or not.
Philippe Mori
|
|
|
|
|
You have an excellent point. But this is not the case. I would have understand the point very much if there were other codes that might have thrown exception. There is none  that's why the frustration.
I do not fear of failure. I fear of giving up out of frustration.
|
|
|
|
|
I wish this were weird, but one of the OOAD commandments I was taught was: "Thou shalt not use exceptions for flow control." Clearly all too common.
"Never attribute to malice that which can be explained by stupidity."
- Hanlon's Razor
|
|
|
|
|
OOAD commandments: "Thou shalt not use exceptions for flow control."
Right. Because exceptions used for flow control are gotos.
The code jumps to the exception handling routine on error, just as a goto jumps to another place.
|
|
|
|
|
This evening I've been looking at the "MASTER IGNITION ROUTINE" written by Peter Adler and Don Eyles at NASA circa 1968-1969. BURN_BABY_BURN--MASTER_IGNITION_ROUTINE.agc Apollo-11[^]. It's absolutely amazing what they were able to accomplish with that hardware. They were obviously proud of their work and left two notable comments in the source code:
"Shame on anyone who thinks evil of it" at Line 66: "Honi soit qui mal y pense" also the motto of the Order of the Garter[^].
"Touch me not" at Line 72: Noli me tangere[^]
They were working with the 16 bit Apollo Guidance Computer[^] with no floating point instructions and that was all they needed to get to the moon.
- 3840 bytes of RAM
- 69120 byte ROM
- 85,000 CPU instructions executed per second.
I'm writing this post from my development workstation:
- 34,359,738,368 bytes of RAM
- Quad-core Xeon capable of performing over 3 billion operations per second.
The hardware has become so much better... but I somehow feel that something is wrong with the way we write software today.
Best Wishes,
-David Delaune
|
|
|
|
|
Quote: I somehow feel that something is wrong with the way we write software today
I blame the abundance of languages: there are literally too many languages going around, cutting into the learning part that is (or rather was) to shorten code, shorten the number of statements to execute, shorten the time of execution, etc.
IMHO there should only ever be 8 languages:
1. Assembly.
2. C/(maybe)C++ One that you can use to build apps.
3. One from either (Java/C#). This one may or may not be needed much.
4. One language to design webpages HTML/HTML5/CSS.
5. Front End scripting language (JavaScript/TypeScript)
6. Backend Language (PHP/Node.JS/Python).
7. Database Querying language SQL.
8. Maybe I'm missing something.
The reason I chose a limited number of languages contrary to popular beliefs are:
1. Bring quality into the fold when learning.
2. Stop coders from getting jobs just because they can write a few lines of code in some lesser known language.
3. Standardization: this will make data transfers between apps faster.
4. Stop Big Companies especially Google from thinking they can ask consumers to upgrade their hardware specs when they make an update on their software.
Sadly this scheme will never be implemented because most of the companies would lose monopoly over the products that require a specific tech stack.
P.S. Slashes (/) represent exclusive OR not inclusive.
|
|
|
|
|
You only need one - machine language.
|
|
|
|
|
Yeah, one...for each machine. And there are hundreds.
|
|
|
|
|
I agree with your assessments, with one or two exceptions. One would be to get rid of JavaScript altogether since using a back-end language such as C# on the front-end such as what is being done with Micrsoft's Blazer and its use of Web-Assembly makes more sense than having to rely on a broken-down scripting language such as JavaScript.
I would also add VB.NET to this list. It is as fast as C#, since it compiles to the CLR just like its more popular sibling. Having Java, C#, and VB.NET as options will fit all the personalities that tend to code all forms of business applications.
Back-end languages should be the same as the front-end as just noted since the use of a single language would substantially reduce defects all around as well as the time it takes to produce a quality product.
I would also eliminate PHP and Node.js.
PHP is in decline and cannot be used as a general purpose language forcing a developer to know an additional language for other work. Node.js is JavaScript and such frameworks are more problems than they are worth.
During the mainframe days we all used a limited but similar tool-set no matter where we worked. This allowed us to always concentrate on application development design and their requirements.
Today, everyone is concentrating on tools and so the entire business end of the profession has become a complete mess with everyone creating their own tools and frameworks as the #MeToo meme has taken substantial hold in the field.
Finally, I would suggest a movement to return to the development of client\server applications. They are far more efficient to develop for small and medium sized applications that will have limited use. Web development is not need for many applications today and comes with a substantial amount of complexity that increase costs of development and maintenance substantially. Though more difficult in Java, the Microsoft .NET environments are perfect platforms for such development and there are several options to create the necessary tiers for such development; Windows Communication Foundation (WCF), Service-Stack, and ZeroC's magnus opus, ICE.
Less, in our work, always means more. However, you are correct to assume that such suggestions will never win out among the technical masses since so many have personal investments in the way the profession has become structured in the past 10 years or so...
Steve Naidamast
Sr. Software Engineer
Black Falcon Software, Inc.
blackfalconsoftware@ix.outlook.com
|
|
|
|
|
Quote: One would be to get rid of JavaScript altogether
I agree on that point, but I added it for two reasons
1. I've been told that I have some personality differences with JavaScript.
&
2. Weather anyone (including me) likes to admit or not, JavaScript has over the years become the mainstream language on almost every platform for almost everyone.
So I just included it in secret hopes of someone saying exactly that.
Quote: I would also add VB.NET to this list
I considered it and then excluded it in favor of C# due to lack of existing developer-base (the same reason I included JavaScript). Also I have never written a line in VB.Net, C# on the other hand I've used many times for smaller problems and school problems, while professionally I've stuck with Java.
Yeah I'm not as old as you. Mainframes? I some times wish I could see one in person.
Quote: PHP is in decline and cannot be used as a general purpose language
True but just as my earlier points it is widely used and understood.
Agree with all of your other points wholeheartedly.
|
|
|
|
|
I could Possibly not agree with you more.
|
|
|
|
|
Steve Naidamast wrote: I would also add VB.NET to this list. It is as fast as C#, since it compiles to the CLR just like its more popular sibling. Having Java, C#, and VB.NET as options will fit all the personalities that tend to code all forms of business applications.
I went in the opposite direction. Starting with VB.NET, I quickly shifted to C# for two fundamental reasons.
- Triple-slash comments on classes and their properties and methods that become IntelliSense help.
- C# code looks more like the mathematical expressions that are its underpinnings.
- Succinctness of expression that requires less typing to accomplish the same result. For example, IF Expression THEN becomes if ( expression ) {, while END IF becomes }. Likewise, the right bracket replaces the word NEXT in FOR and FOREACH loops, WEND in WHILE loops, etc.
Although I am a good touch typist, I am not as fast a typist as many of my colleagues; this is the result of a subtle birth defect that impedes my hand-eye coordination. Hence, accomplishing a test with fewer keystrokes is to my advantage.
My appreciation of the closer resemblance of C# source code to mathematical expressions may have its roots in the fact that my first programming language was FORTRAN.
David A. Gray
Delivering Solutions for the Ages, One Problem at a Time
Interpreting the Fundamental Principle of Tabular Reporting
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
