Re: Checking for A Blank String

"Herfried K. Wagner [MVP]" <hirf-spam-me-here@xxxxxx> wrote...

This is not a discussion about basing preferences on ideology. I have
given technical reasons why I avoid using 'String.IsNullOrEmpty'
currently.

Yes and in this case you pointed out a bug. But how many other very similar
discussions have we had about the VB compatibility library?

If it was available in VB6 Herfried prefers to use it in VB.Net.

Again, completely wrong. Although I am currently only active in the
English VB group, I use VB.NET, VB6, C#, and some other programming
languages equally. When using VB.NET, I use VB.NET, not only the .NET
Framework, as I do with other programming languages.

Completely wrong? It doesn't seem like that to me based upon your postings
covering some 5+ years. We've discussed topics in the VB6 newsgroup and now
in the VB.Net newsgroups but I don't recall reading or responding to any of
your posts on a C# newsgroup. Be that as it may I'm not stating that you
don't know another language I wrote quite plainly if you run into VB6 stuff
which is available in VB.Net you tend to choose the VB-compatible option.

I understand that along with your reasons I am addressing those who
are on the fence. Those who may not consider themselves VB gurus
and who might one day like to develop software (and be
employable) in more than one language.

Again I do not see the relation to the topic because nobody claims that
he/she "speaks" VB only.

The topic is not the Len() function, it is simply the example that sparked
the thread. The reality is there are people reading these messages that are
just learning VB and those that can write code in another but are pretty
unlikely to write an entire application in say Java. I often address
message to those groups to get them to consider that other languages
implement constructs which can be of use the VB.Net developer. That if (for
instance) there was no linked list that one couldn't be written.

In the words of Herfried: "Well, then I suggest you specify more clearly
what you are talking about."

Tom, in contrast to you I do not blame you for making mistakes. Everybody
makes them, I make them and even you make them.

I have never written "Well, then I suggest you specify more clearly what you
are talking about." to you or anybody else that I'm aware of with the
exception of my quoting you this time. Now you're contrasting me to the
person who wonders how I write software and suggests that I might learn to
write more clearly so they get their made up attributions correct.

I wrote:

| Trying to avoid the use of VB's intrinsic functions is like trying to
use a
| screwdriver to screw in a nail although there is a hammer in the toolbox
for
| the reason that "a screwdriver is a more professional tool than a
hammer."

Yes that's what you wrote. The .Net Framework is not "more professional"
any more than the Windows API is more professional. And you clearly wrote
"using a screwdriver to screw in a nail." So people who do it are in
essence "stupid" or are you now claiming that using a screwdriver to screw
in a nail is sometimes a reasonable solution? You aren't of course because
it isn't. If using the wrong tool is the same as using a "different" tool
it's time to go back to Logic 101.

Professionals often discuss various ways to solve a problem if somebody
posts "Yeah, or we could all just plink away on Amigas or something" (1) it
is an indication of their insincerity or lack of knowledge on the subject.

(1) from "Things to Say When You're Losing a Technical Argument"

It seems that you negatively connotate the term "low-level", which is not
what I do.

Calling functions in function library has never been considered low-level to
anyone I've known in the computer industry. But if you will agree we can
settle on Wikipedia's definition:
http://en.wikipedia.org/wiki/Low-level_programming_language. How does
String.IsNullOrEmpty (or other Framework methods) fall into the context as
expressed there? Are they close to the hardware and do they provide little
or no abstraction from a computer's microprocessor? The answer as you will
find through a little diligence is no, of course not.

And here is a definition from Answers.com that seems even further from what
you claim low-level means.
http://www.answers.com/topic/low-level-language

Rather than my applying a negative connotation doesn't it appear more likely
that you misused the term "low-level" to make people think it was harder to
use the .Net Framework?

You understand the difference between buying (for instance) a Sony TV
which develops a problem and proclaiming "Sony TVs suck" and the
statement "I bought a Sony once and it had a problem."

Does that really matter here? If there are problems associated with the
function, regardless of their actual reason, why would I want to prefer it
over another method that doesn't suffer from the problem and has been used
for years?

It only matters when you insist that your misapplication of the screwdriver
analogy along with your misuse of the term low-level combined with your
insistence that there are fewer letters to type in the function name Len()
matters. You can write "I hit that bug" if you in fact hit that bug and
everybody would consider that a heads-up warning. Alternatively you can
scour your friend's blogs for rarely encountered bugs to support your
position. One is real, one is artificial. If I post a bug report there is
every reason to believe another developer writing reasonable code would
encounter it as well. If I write "VB.Net sucks" because I encounter a bug
I'd appreciate it people just told me to keep my unsupportable opinions to
myself.

I am currently working in another domain, not using .NET at all, but I
would not have a problem to do my work in C# if this was decided for a
project.

In that case what would you do if you needed need to test if a string was
IsNullOrEmpty? There is a bug in the JIT optimizer you know?



.

Relevant Pages

  • Re: [PATCH 1/2] LogFS proper
    ... Do enums have a significant ... Reason enough to use it for the simple cases. ... why are function and line included in BUG() then? ... More than in other filesystems simply because LogFS is younger. ...
    (Linux-Kernel)
  • Re: Security researchers organization
    ... > The Sardonix.org security auditing web site was designed to ... Sardonix provides: ... prevent last year's Chunked Encoding bug? ... -> this provides a reason for individual team members to share their ...
    (NT-Bugtraq)
  • Re: disable a memory block from swapping to hard disk
    ... That was the reason I am looking if it is possible to get a memory block ... Clearly this is a driver bug, so you should report it to the vendor along ... with the dump file generated at the time of BSOD. ...
    (microsoft.public.vc.language)
  • Re: "Pocket Printserver" Dongle doesnt work with (64 bit) Fedora 6
    ... Aaron Konstam wrote: ... For some reason, now it doesn't. ... I've filed the bug report, which apparently gets handled by Tim. ... I don't normally use this printer for anything but photographic work, and have yet to implement a solution for dealing with Nikon raw files so I'm in no hurry to get this working under Fedora. ...
    (Fedora)
  • Re: Preempt-RT patch for 2.6.25
    ... So please fix this bug in your refactoring of the queue, ... maintainers to accept buggy contributions. ... for no good reason. ...
    (Linux-Kernel)