Hilarious Article

  • Thread starter Thread starter Paulo
  • Start date Start date
P

Paulo

Disclaimer: I am NOT trying to slam VB.NET here. I found this funny because
it hits on the dumbing-down of VB terminology (which has been with us since
1.0!) that I have ranted about many times in the past. Sorry if this has
been posted before.

http://secretgeek.net/refactvb.asp
 
What terminology had been dumbed-down? I guess i must be dumb because I see
the article as nothing but a slam on VB.
 
Disclaimer: I am NOT trying to slam VB.NET here. I found this funny because
it hits on the dumbing-down of VB terminology (which has been with us since
1.0!) that I have ranted about many times in the past. Sorry if this has
been posted before.

http://secretgeek.net/refactvb.asp

Yeah, I've definitely seen that image before, and personally I found
it pretty funny.

I had forgotten about it for a while, but I rediscovered it while
trying to find a good program for refactoring support in Visual Basic
(I ended up choosing CodeRush from DevExpress)

Thanks,

Seth Rowe [MVP]
http://sethrowe.blogspot.com/
 
Terry Olsen said:
What terminology had been dumbed-down? I guess i must be dumb because I
see the article as nothing but a slam on VB.

Well, obviously VB programmers are so productive they do not need
refactoring because their implementations are perfect. In the time saved by
the lack of requirement for refactoring and the other productivity features
of VB, VB programmers can play solitaire in the time they have saved.

;-)
 
Well, obviously VB programmers are so productive they do not need
refactoring because their implementations are perfect.  In the time saved by
the lack of requirement for refactoring and the other productivity features
of VB, VB programmers can play solitaire in the time they have saved.

Herfried,

I'm terribly disappointed that you would write this rubish. We all
know that solitaire is a game you play by yourself, and all VB
programmers are perfect team players. Therefore you should know that
we play poker together while the C#'ers finished up their
refactorings!

:-)

Thanks,

Seth Rowe [MVP]
http://sethrowe.blogspot.com/
 
Terry,

Like I understand from Herfried, I agree with him that there is exactly
showed what is needed in in VB instead of refactor: buttons to start
solitair and things like that, because nothing is to be done anymore to a
program, which has a time calculation needed in other program languages, so
you need something to fill up the time.

Refactoring is consuming an entree after dinner. VB gives you a wide
assortment of posibilities to avoid refactoring, moreover, it does a lot of
things automaticly.

So in fact refactoring is cullprit in VB. The article shows exactly the
crapy thinking of developers who use tools who needs a wide range of
posibilities to refactor, while the problems are already known. In that time
the VB developer can play solitair, and because they want probably as well a
kind of gambling as with other program languases is done, play poker (by the
way I do bridge).

The image shows in my idea, although it is probably done by a very young
child, despite of the latter, good what a VB developer needs.

Cor




Like
 
So in fact refactoring is cullprit in VB. The article shows exactly the
crapy thinking of developers who use tools who needs a wide range of
posibilities to refactor,

I'll disagree here a bit. Refactoring isn't always a sign of poor
programming initially. Almost all projects will have the spec changed
at some point or a feature added / removed, which makes it impossible
for the program to be written correctly the first time. As a matter of
fact, this was one of the reasons that practices such as OOP, class
based programming, agile, XP, etc were created - to deal with change
instead of avoiding change. We try to program for the changes so that
when they come, we're ready for them.

Another reason that refactoring is actually a good sign of progress is
that you never understand the program completely, every minute you
work on it your knowledge increases. Therefore I firmly believe, along
with many others, that a program can never be correct (read:
production worthy) the first pass. There is always some "gotcha" that
was missed, or some piece of code that becomes deprecated, or some
other aspect that was missed.

With the above two assertions, and the benefits of refactoring tools
to TDD, I urge people to look into refactoring software, both for
large scale refactoring and micro-refactoring (such as renaming
private variables). While Visual Studio has many of these functions
built in (more so in C#) I personally feel that they could be greatly
improved. One terrific piece of software I swear by is CodeRush /
Refactor! Pro by DevExpress, and I encourage everyone to try it out.
CodeRush isn't the only one out there either, another by JetBrains is
Resharper. After working with IDE productivity tools like CodeRush and
Resharper, it's extremely difficult to imagine working without them.
Their sites are below:

http://devexpress.com/Products/Visual_Studio_Add-in/Coding_Assistance/
http://devexpress.com/Products/Visual_Studio_Add-in/Refactoring/
http://www.jetbrains.com/resharper/index.html

Thanks,

Seth Rowe [MVP]
http://sethrowe.blogspot.com/
 
Terry,

Like I understand from Herfried, I agree with him that there is exactly
showed what is needed in in VB instead of refactor: buttons to start
solitair and things like that, because nothing is to be done anymore to a
program, which has a time calculation needed in other program languages, so
you need something to fill up the time.

Refactoring is consuming an entree after dinner. VB gives you a wide
assortment of posibilities to avoid refactoring, moreover, it does a lot of
things automaticly.

So in fact refactoring is cullprit in VB. The article shows exactly the
crapy thinking of developers who use tools who needs a wide range of
posibilities to refactor, while the problems are already known. In that time
the VB developer can play solitair, and because they want probably as well a
kind of gambling as with other program languases is done, play poker (by the
way I do bridge).

The image shows in my idea, although it is probably done by a very young
child, despite of the latter, good what a VB developer needs.

Cor

I couldn't disagree more. Herfried's response was in gest. All
developers regardless of language can benefit from a comprehensive
suite of refactoring tools. VB only has the rename option.
Fortunately, that is the one that is used most often. Although C#
does have more options I think there is still room for improvement.
 
Seth,

May message was based on the showed article (did you see that?)

However it is true that I seldom refactor, I have seen to many persons doing
nothing else there whole live with the first program the made. (I try to
make code direct perfect as far as my limits permits me to do that)

However, as always, as everybody always agrees, the world would be a borring
place.

Cor
 
Cor Ligthert said:
May message was based on the showed article (did you see that?)

However it is true that I seldom refactor, I have seen to many persons
doing nothing else there whole live with the first program the made. (I
try to make code direct perfect as far as my limits permits me to do that)

Well, I was joking with my statement that VBers do not need refactoring.
Personally I use refactorings occasionally, especially when prototyping
interfaces (members of classes, etc., not user interfaces) directly in VB.

Nevertheless, it's a matter of the software development method. If most of
the interfaces are defined prior to writing code, refactorings are often not
thus important as in the case where code is written without a lot of
planning. Recently I found a website of a software firm (I won't post the
name here) claiming to write "perfectly refactored code". I wonder in which
way this should be an advantage of code. Only bad code needs refactoring,
and most code does not need refactorings at all when following the
philosophy that interfaces are set in stone once defined.
 
Well, I was joking with my statement that VBers do not need refactoring.
Personally I use refactorings occasionally, especially when prototyping
interfaces (members of classes, etc., not user interfaces) directly in VB.
How long do you know me now online?

I was luckily suprised to see this perfect answer from you written in a
joking way.

And as Seth made an aswer, I could not stay behind.

However, there is a lot of truth in.

:-)

Cor
 
Nevertheless, it's a matter of the software development method.  If most of
the interfaces are defined prior to writing code, refactorings are often not
thus important as in the case where code is written without a lot of
planning.  Recently I found a website of a software firm (I won't post the
name here) claiming to write "perfectly refactored code".  I wonder in which
way this should be an advantage of code.  Only bad code needs refactoring,
and most code does not need refactorings at all when following the
philosophy that interfaces are set in stone once defined.

I don't know. It's not always easy to create the perfect architecture
at the beginning. Requirements change in ways that no one could have
predicted leaving the initial design in a suboptimal state.

IMHO, The rename operation is of critical importance in the realm of
refactoring. A lot can be said for a good name. Without the rename
operation you'd have to resort to search and replace operations.
Those can get tricky and cumbersome especially if the rename is
complex enough to require regular expressions. I remember doing it a
lot in VS 2003. It's nice to be able to rename an identifier in a few
seconds. And I happen to do that *very* frequently.

In addition, there are many other aspects of refactoring that aren't
really tied to the design or architecture of code. A lot of
refactoring techniques involve modifying the implementation of methods
in a way that makes them more efficient and readable without changing
the API. Or as you go through the process of optimizing the memory or
speed of an application you are, by definition, refactoring it.

To me refactoring is a perfectly acceptable practice. In fact, I'll
go even further and claim that it is necessary in the development
cycle of large projects. The more tools you have to assist you the
better off you'll be :)
 
Back
Top