Underwhelm by VS2005

[CMM]

I think this thread has gone way OT. My experience with Java IDE's is dated
and I didn't mean to imply that they weren't useful or innovative in their
own ways.... only that they (and Java apps in general) tend to lack a
"polished" consistent "Windows Standards" quality. But, then again so do
many of the corporate apps created in VB that I've had the pleasure of
upgrading. ;-)

I wouldn't trade VS 2003 or 2005 for Eclipse. I just lament that 2005 wasn't
as revolutionary (in IDE usability terms) as I expected after 2 to 3 years
of development by Microsoft.. and indeed seems to have taken a couple of
small steps back in the usability department.

 

[Pieter]

I know I was nitpicking... I love VS.... I just don't see the great leap
forward that everyone expected... the hype, I mean. We still don't have a
good pure Remoting infrastructure (c'mon a prebuilt Template at least!)
that doesn't rely on IIS or DCOM (I know, I know, wait for Vista). We
finally get real XP Themed capable controls (why did it take 4 years???).
But, we still can't create a solid Windows app without 3rd party controls.

I mean... for sheesh-sake... masked edit control just made their
appearance. Ooooh. Ahhh. These guys have been around since Windows 3.1.

I guess that's what the 3rd party market is for... I guess. Though some
things just seem to me to be so rudimentary that they should be available
out-the-box. Fancy spreadsheet-Excel-grids... sure, good candidate for a
3rd party control. Masked edit box... no way!

I totally agree with that! There are too many controls that should be
standard, but aren't...
Think of the DataGrid that improved nopw with the DataGridView, but the
DataGridView still is a very limited product. Even worse: They used degraded
versions of the combobox, pictures, and buttons for their column styles.

Does this mean that they actually did an effort to make things worse???????

 

[Jon Skeet [C# MVP]]

You forgot another important point:

VS supports VB.NET, Ecplise doesn't. This is a big plus for VS .

Well, it is for VB.NET programmers. On the other hand, VS *doesn't*
support Java (real Java, not J#), which gives Eclipse a big "plus" when
I'm writing Java, obviously...

 

[Jon Skeet [C# MVP]]

Regulars here know how you make programs and what you like and not.

A lot of effort in VS is in by instance the Visual part and for VB Net
especial the debugger and the background compilation plus of course the
integrated WebDesign and code behind.

Is your opinion that Eclipse is better in those things than VS as well?

Eclipse is *fabulous* at incremental compilation. It compiles every
time you hit save, as well as performing a lot of checking on-the-fly.
It also has a lot of "quick fixes" which just do the right thing -
creating methods that you've used but not actually written yet, etc.
It's got *brilliant* auto-completion, for instance if I write
foo.setName( and hit ctrl-space, and I've got an incoming method
parameter or local variable with the right type, it'll suggest that as
the parameter for the setName call, favouring variables with close
names to "name".

It will also generate getters and setters for you, along with
contructors which populate member variables, taking into account your
own personal preference for variable naming, etc.

Its refactoring is way ahead of VS 2005.

Its navigation is way ahead of VS 2005 - really simple things like
holding down control and clicking on virtually anything (a type name,
method name, variable name etc) to get to the declaration. Can't easily
find the file a particular type is in? Ctrl-Shift-T, start typing in
the name, and you're there. Can't find a particular resource? Ctrl-
Shift-R.

It's got unit testing built-in (and really nicely integrated) which is
more than can be said for VS 2005, unfortunately. (From what I've seen
of Team System, the Eclipse UI is rather nicer anyway - why no
red/green bar in VS?)

I can't remember the last time I had to type in a Java import
statement, as Organize Imports works so well. (Other than for static
imports - there's some work to do there. I've registered a feature
request though, so it shouldn't be too long.)

It's really painful coming back to VS.NET 2003 after using Eclipse.
It'll be better when we use VS 2005, but I'll still miss many of the
features that make *plain old coding* so much easier.

I haven't used it for web design or UI design, and frankly I prefer to
do those without designers anyway, so as to get maintainable code, but
I suspect that's where more work has gone into VS. I know that there
*is* now a UI designer in Eclipse which can work with different back-
ends (to generate SWT code, Swing code etc) but I wouldn't like to
comment on the quality, not having used it.

 

[Jon Skeet [C# MVP]]

Why not sell it to help other people. This way you
can stick around and keep on keeping on. If you
give it away, you give (it) up -- and nearly all who
do, do just that. Hopefully, someone else will take
it on for the next year or so, and so on it goes.
I can tell you the reason -- because it's a lot easier
to give something away than to sell it. haha

It takes effort to sell something, yes. A company which sells content
security products (as the one I work for does) isn't in the business of
mock object libraries, or build tools, or anything like that - why
would we want to lose focus trying to sell that instead of selling what
we know how to sell, and giving away code that we don't need to sell
but which will help other people.

And yes, sometimes people do lose interest - and someone else takes
things on. I was a committer in the Ant project for a while, I then
didn't do any Java development for a couple of years, and now I'm back
working with Ant. I haven't submitted any patches yet, but I may well
do so in the future. I couldn't possibly sell my individual
contributions - do you think I should just keep them to myself?

 

[John A. Bailo]

I have shifted from using DataSets to using in memory XML documents.

XPathQuery gives me far greater search within the 'dataset' than the
DataReader.

 

[John A. Bailo]

Also, most developers write 1000x more ASP.NET than winForms.

And, in that arena there is high competition from technologies such as
AJAX, php, apache, tomcat, eclipse and so on.

 

[Guest]

JS- [Mon, 21 Nov 2005 23:16:31 -0000]:

contributions - do you think I should just keep them to myself?

I, like practically everyone else in this universe,
don't care what you do with it. If it's not any
good, then yes, you should tuck it away on a CD
somewhere. If it is any good, you should sell it.
At least make the effort. Lots and lots of bad
stuff is already out there. Why add to it?

 

[Jon Skeet [C# MVP]]

JS- [Mon, 21 Nov 2005 23:16:31 -0000]:

contributions - do you think I should just keep them to myself?

I, like practically everyone else in this universe,
don't care what you do with it. If it's not any
good, then yes, you should tuck it away on a CD
somewhere. If it is any good, you should sell it.
At least make the effort. Lots and lots of bad
stuff is already out there. Why add to it?

Why do you assume that anything which is given away for free is bad? By
not putting effort into selling it, I can put more effort into making
the software good to start with.

Furthermore, by releasing it with an open source licence, others can
improve it still further.

 

[Cor Ligthert [MVP]]

Jon,

Well, it is for VB.NET programmers. On the other hand, VS *doesn't*
support Java (real Java, not J#), which gives Eclipse a big "plus" when
I'm writing Java, obviously...

Good catch on Herfrieds one, however that was not mine (although I agree
with him of course).



Cor

 

[Guest]

This sort of GUI tool (that is, a GUI tool for developing business
components) is primarily for beginners. Advanced users may make use of it,
but what you refer to as "kludging" is simply the process of tweaking
auto-generated code for specific purposes. When an advanced user uses such a

The problem with tweaking that code is that it looks as it was designed by a
VB.NET guy with zero-flat knowledge about how things work in C#... and
without taking a look at how similar problems were solved in the form
designer.

I mean:

1- The constructor for a table adapter now belongs to the auto-generated
code. This makes too hard to make any sensible change to the class from a
partial class fragment. The Windows Forms designer generates an
InitializeComponent, but the constructor is located in the class fragment
that the programmer can modify.

2- Think what happens now if you want to hook an event handler to some table
or column event: hard, isn't it? Why? Because the designer of this "feature"
was thinking in the VB.NET "handles" clause for autowiring event handlers.

3- The whole concept is hostile to multitier applications, since you have to
carry on with the SQL access code even when you're writing the presentation
layer. Of course, you could ignore those SQL classes, but then...

4- If you move type datasets and table adapters to a separate project, you
loose the ability of drag&dropping data source parts into a form designer,
which was the best thing about this whole class framework.

Problems, indeed, can be traced to the very notion of data-source: a design
time concept with no direct equivalent at run time. This is a strange turn
from one of the most important ideas in .NET: pervasive reflection.

But then, things get worse: as you said, this was intended to be used by
beginners, isn't it? Then, why did they hide SqlDataAdapter and the like from
the programmer? Actually, I have read in a blog from one of the authors that
they decided to hide the all classes to "protect" programmers from the old
klunky programming style. Oh, my, how sweet and caring...

Ian

 

[CMM]

I'm a "VB.NET" guy, but I agree with your comments about the new datasets.
They're almost worthless. It's like they took the whole (great) idea of the
standalone, db-agnostic, multi-tier friendly dataset and took 8 years worth
of steps backwards to the ol' DAO/ADO recordsets paradigm.

Truth be told however... not many people "got" datasets. Not many people
really understood the notion that a dataset has nothing to do with a
"database." You don't need a database to use them... and if you do, the
datasets don't even have to "look" like the database tables that fill them.
That's what the DataAdapter and its mapping classes are for. Thus the whole
"argument" about DataSets vs. Entity Objects. DataSets ARE "Entity
Objects".... or rather a full-featured "Collection" of EntityObjects!

These new DataSets and TableAdapter objects will encourage the same lazy and
horrible and dumb "2-tiered" db coding practices that gave VB.Classic a bad
reputation.

Alas....

 

[Guest]

I'm a "VB.NET" guy, but I agree with your comments about the new datasets.
Pardon me if it sounded offensive, it was not my intention My point was:
when you are responsible of the design of a class library for .NET, you
should understand at least two of the major programming languages, let's say,
VB.NET & C#.

Thus the whole "argument" about DataSets vs. Entity Objects. DataSets ARE "Entity
Objects".... or rather a full-featured "Collection" of EntityObjects!

Absolutely right. And, as you said in the root message, I should add that I
really like VS2k5 and .NET 2.0 too.

Ian