G
Guest
Joe said:
that's not a matter of quality but marketing
that's not a matter of quality but marketing
S
Sean Hederman
SnakeByte said:
And one of those points of marketing is the guarantee that the software you
bought years ago will still work on the operating system you buy tommorrow.
I've seen someone running Quattro Pro on an XP machine!
G
Guest
Did anyone know that MOST OF THE CODES OF AVALON IN MICROSOFT WINDOWS
LONGHORN IS WRITTEN IN C# (C# is one of the .net Language).
LONGHORN IS WRITTEN IN C# (C# is one of the .net Language).
A
Alvin Bruney [ASP.NET MVP]
What is your source of this.
--
Regards,
Alvin Bruney
[Shameless Author Plug]
The Microsoft Office Web Components Black Book with .NET
available at www.lulu.com/owc
--
Regards,
Alvin Bruney
[Shameless Author Plug]
The Microsoft Office Web Components Black Book with .NET
available at www.lulu.com/owc
B
Bob Grommes
Joe,
Amen to that. The marketplace can only absorb so much, so fast --
especially when there is no business reason to do so, or far more pressing
business reasons to do other things.
Having said that, there does eventually come a time and place where it
becomes compelling to rewrite any code base, even in the absence of
motivators like new technology platforms, changing requirements, difficulty
in locating or developing expertise, or the winds of politics. Any body of
code that has been through enough revisions can benefit tremendously from a
complete rewrite, lest it become like a bedroom closet full of miscellaneous
add-ons and false starts. The larger the body of code, and the more people
who have worked on it, and the less satisfactory the original architectural
decisions were, the truer this is. The trick is always how to decide where
that tipping point is.
--Bob
Amen to that. The marketplace can only absorb so much, so fast --
especially when there is no business reason to do so, or far more pressing
business reasons to do other things.
Having said that, there does eventually come a time and place where it
becomes compelling to rewrite any code base, even in the absence of
motivators like new technology platforms, changing requirements, difficulty
in locating or developing expertise, or the winds of politics. Any body of
code that has been through enough revisions can benefit tremendously from a
complete rewrite, lest it become like a bedroom closet full of miscellaneous
add-ons and false starts. The larger the body of code, and the more people
who have worked on it, and the less satisfactory the original architectural
decisions were, the truer this is. The trick is always how to decide where
that tipping point is.
--Bob
J
Joe
I agree. As to whether that requires 100MB of code while Delphi and VB
presented a highly productive OO interface to the underlying
procedural Win32 API in a couple of megabytes...
Joe.
G
Guest
In an excellent article by Richard Grimes,
http://www.ddj.com/documents/s=9211/ddj050201dnn/, the ex-Microsoft guru
lambasts MS' seriousness to .NET and VB.NET as a redundant language. Truth
hurts.
At the same time, .NET isn't going away, it's just C++ remains superior for
destkop applications.
http://www.ddj.com/documents/s=9211/ddj050201dnn/, the ex-Microsoft guru
lambasts MS' seriousness to .NET and VB.NET as a redundant language. Truth
hurts.
At the same time, .NET isn't going away, it's just C++ remains superior for
destkop applications.
S
Sean Hederman
Joe said:
The Framework is not 100MB. The install is 25MB and once installed they're
about 65 MB I believe.
Our figures indicate that our developer productivity has gone up by 50%
since switching to .NET. Given an average developer salary of 25,000 South
African Rands and 4 developers that indicates a one-year saving of R600,000.
No contest as far as I'm concerned.
S
Sean Hederman
i"TheBain said:
And many of his points have been refuted, even he concedes as much in the
comments in http://weblogs.asp.net/danielfe/archive/2005/02/22/378343.aspx.
In any case his main thrust seems to be that VB.NET was just a marketing
ploy to get VB developers working on the .NET Framework. This is a point I
heartily agree with. However I see this as a good thing, since it has helped
spur adoption of the Framework. In addition he praises the C# language, his
only "complaint" being that it's remarkably similar to Java. This would be
no real surprise since both C# and Java are C-family languages targetting a
managed execution environment.
He does raise some good points about parts of the Framework having being
rushed though. Nonetheless his comments that MS is not using .NET to write
major revenue generating software seems to be incorrect (see
http://blogs.msdn.com/danielfe/archive/2004/11/02/251254.aspx)
Truth? I didn't see anywhere in his article where he claimed he was
delivering truth. In fact he goes out of his way to say that this is merely
his opinion, several times. In addition, you say "ex-Microsoft guru", and
all I see is that he's stopping work in .NET, not on Microsoft products.
Which desktop applications exactly? In what way do you think C++ is superior
to .NET for these? Are you referring to speed? If so, then I can't disagree.
If you're referring to developer productivity then I can. If you're
referring to security and reliability, again, I disagree. Whilst *some* C++
developers are reliably able to write code that doesn't result in memory
leaks, dangling pointers and buffer overruns, their numbers are few indeed.
J
Joe
Thanks for the correction. But still, it's _humongous_ compared to the
VB or Delphi runtimes.
Right, something VB and Delphi users have know all alolong
Joe.
S
Sean Hederman
Joe said:
Yes, but...
- With VB you generally have to distribute many large OCX's with your
application.
- With Delphi the libraries are compiled into your application.
- The .NET libraries are FAR more comprehensive than the VB libraries.
It's a tricky path to walk. On the one side MS could offer a scaled down
version of the Framework, excluding things like System.Messaging,
System.Web, System.EnterpriseServices, System.Management and suchlike. The
thing is that then your programs that relied on those components would
sometimes work and sometimes not. People would have to know whether to
download the "Lite", "Regular", or Enterprise frameworks, depending on which
programs they wanted to run. I can just see people downloading the 15MB
"Lite", then being informed by one application that they need "Regular",
bang goes another 20MB download. A week later they get told by some other
app that it won't work without the 25MB "Enterprise".
The point that I'm trying to make is that the Framework provides a
completely reliable environment. If your programming is running on the right
version, all the services that your program uses are guaranteed to be there.
V
Vyacheslav Lanovets
Hello, Bob!
You wrote on Tue, 8 Mar 2005 10:07:26 -0700:
BG> Having said that, there does eventually come a time and place where it
BG> becomes compelling to rewrite any code base, even in the absence of
BG> motivators like new technology platforms, changing requirements,
BG> difficulty in locating or developing expertise, or the winds of
BG> politics. Any body of code that has been through enough revisions can
BG> benefit tremendously from a complete rewrite, lest it become like a
BG> bedroom closet full of miscellaneous add-ons and false starts. The
BG> larger the body of code, and the more people who have worked on it, and
BG> the less satisfactory the original architectural decisions were, the
BG> truer this is. The trick is always how to decide where that tipping
BG> point is.
I agree with you but not completely From one point of view, complete
rewrite is cool - it's interesting to use new technologies from the latest
MSDN Magazine / C++ Users Journal issues The system developed looks like
Christmas Tree with all of the different stuff on it Then, when it
becomes too overloaded and new technologies become old and are going to die,
there is a time for complete rewrite.
But, besides of all obvious economical reasons not to spend time on complete
rewrite there are some more points from my developer's point of view.
One is that sometimes the greatest value of the code is not the code itself
but _what_ was coded - the logic and the algorithms. If some algorithm's
implementation in C was fine 10 years ago, still fine now, and will be fine
in 10 years, why it should be implemented in VB.Net? Reason of this is that
nobody made complete rewrite of linear algebra or discrete math recently
The second one is refactoring. I saw many projects where developers did only
what they were said to do. And in most straightforward way. On the top of
this some of them tried to use brand new technologies (just from recent MSDN
Mag issue). But I saw projects where developers tried to refactor to some
extent - in this case each revision added not only features but code
quality. While I understand why first projects should be completely
rewritten, second ones usually can live without it.
And the third one - after several revisions during _normal_ development
process the software becomes near-to-perfect. I mean it's hard to make it
better from the first try, particularly in new language and under new
platform.
I think about this every time when we find a bug in the code which worked
and was tested for years! With every new bug found the system becomes more
and more perfect, I can not believe it's possible to write such from
scratch.
So, when you say that revisions only make product worse then it means that
something wrong with development. The problem of such software products
where revisions just spoil the code lies in relationship between developers
and management. From my experience, it's enough to have several (10-20%)
good developers or good PM to avoid this.
For instance, I always note what files changed when I check out files from
VCS, and if I see incorrect decision made by my colleague, and this code
relates to my responsibilities, and I do not have time at the moment, then I
add new item to my Tasks in Outlook - to not to forget to fix that.
I would agree, that there are times when there is a need in complete
_refactor_ but not rewrite.
With best regards, Vyacheslav Lanovets. E-mail: xentrax_umail.ru
You wrote on Tue, 8 Mar 2005 10:07:26 -0700:
BG> Having said that, there does eventually come a time and place where it
BG> becomes compelling to rewrite any code base, even in the absence of
BG> motivators like new technology platforms, changing requirements,
BG> difficulty in locating or developing expertise, or the winds of
BG> politics. Any body of code that has been through enough revisions can
BG> benefit tremendously from a complete rewrite, lest it become like a
BG> bedroom closet full of miscellaneous add-ons and false starts. The
BG> larger the body of code, and the more people who have worked on it, and
BG> the less satisfactory the original architectural decisions were, the
BG> truer this is. The trick is always how to decide where that tipping
BG> point is.
I agree with you but not completely
From one point of view, completerewrite is cool - it's interesting to use new technologies from the latest
MSDN Magazine / C++ Users Journal issues
The system developed looks likeChristmas Tree with all of the different stuff on it
Then, when itbecomes too overloaded and new technologies become old and are going to die,
there is a time for complete rewrite.
But, besides of all obvious economical reasons not to spend time on complete
rewrite there are some more points from my developer's point of view.
One is that sometimes the greatest value of the code is not the code itself
but _what_ was coded - the logic and the algorithms. If some algorithm's
implementation in C was fine 10 years ago, still fine now, and will be fine
in 10 years, why it should be implemented in VB.Net? Reason of this is that
nobody made complete rewrite of linear algebra or discrete math recently
The second one is refactoring. I saw many projects where developers did only
what they were said to do. And in most straightforward way. On the top of
this some of them tried to use brand new technologies (just from recent MSDN
Mag issue). But I saw projects where developers tried to refactor to some
extent - in this case each revision added not only features but code
quality. While I understand why first projects should be completely
rewritten, second ones usually can live without it.
And the third one - after several revisions during _normal_ development
process the software becomes near-to-perfect. I mean it's hard to make it
better from the first try, particularly in new language and under new
platform.
I think about this every time when we find a bug in the code which worked
and was tested for years! With every new bug found the system becomes more
and more perfect, I can not believe it's possible to write such from
scratch.
So, when you say that revisions only make product worse then it means that
something wrong with development. The problem of such software products
where revisions just spoil the code lies in relationship between developers
and management. From my experience, it's enough to have several (10-20%)
good developers or good PM to avoid this.
For instance, I always note what files changed when I check out files from
VCS, and if I see incorrect decision made by my colleague, and this code
relates to my responsibilities, and I do not have time at the moment, then I
add new item to my Tasks in Outlook - to not to forget to fix that.
I would agree, that there are times when there is a need in complete
_refactor_ but not rewrite.
With best regards, Vyacheslav Lanovets. E-mail: xentrax_umail.ru
G
Guest
Java tried that route with swing. Look where it got them. Java fist started
with an AWT which used the native OS API directly. Then Sun came out with
swing, which is a pure java implementation of the UI. Have you ever seen what
a swing app looks like? Believe me it’s not something to brag about. Almost
everybody I talk to that is currently using java is switching to SWT which is
once again an API developed using the native OS UI API.
Also,
Why wouldn't Microsoft want to take advantage of the underlying Win32 API?
If the OS shell ever changes (hint Windows XP and themes), the .Net framework
would be consistent out of the box.
Therefore, having the .Net framework utilize the Win32 API will give us a
consistent look and feel. Whereas having a pure managed implementation might
give us a consistent UI but would certainly have to be changed with every
release of the OS and framework version.
That is the beauty of the framework. It allows you to easily interop with
Win32 and COM.
with an AWT which used the native OS API directly. Then Sun came out with
swing, which is a pure java implementation of the UI. Have you ever seen what
a swing app looks like? Believe me it’s not something to brag about. Almost
everybody I talk to that is currently using java is switching to SWT which is
once again an API developed using the native OS UI API.
Also,
Why wouldn't Microsoft want to take advantage of the underlying Win32 API?
If the OS shell ever changes (hint Windows XP and themes), the .Net framework
would be consistent out of the box.
Therefore, having the .Net framework utilize the Win32 API will give us a
consistent look and feel. Whereas having a pure managed implementation might
give us a consistent UI but would certainly have to be changed with every
release of the OS and framework version.
That is the beauty of the framework. It allows you to easily interop with
Win32 and COM.
G
Guest
Anf that is why there is not a wrapper API for DDE. What is the harm of
supporting existing APIs and moving forward?
supporting existing APIs and moving forward?
A
alejandro lapeyre
So, it is important for the framework to include a ListBox.
Or, is it important for the framework to wrap the win32 api ListBox?
Against wrapped controls:
There are two controls that provide list support: the ListView and the
ListBox. The ListBox can handle rows of different height, something the
ListView does not. But the maximum row height is only 256 pixels. The update
routines for the ListBox are horrible (lots of flashing).
So i think it is good candidate for replacement.
We have been in this wrapping path for a very lon time (At least from vb3).
And there have *allways* been a lot of wrapping errors, missing features,
etc. And, I dont like to see a a hundred of internal calls just to add an
item to a ListBox.
Yes, we can write new controls, and that is very easy now! (compared to what
is was in VB5 or VB6). So can do framework. In case we need those wrappers,
we could also build them. So, what is neccesary: a wrapper to a win32
ListBox or a ListBox?
<
Therefore, having the .Net framework utilize the Win32 API will give us a
consistent look and feel. Whereas having a pure managed implementation might
give us a consistent UI but would certainly have to be changed with every
release of the OS and framework version.
Note that updates to the underlying win32 implementation will not be
magicaly implemented in a previous framework wrapped control. If you care
about the fancy drawing details, then the framework could define a new class
that would wrap the painting of the controls (and you get the "system"
painting).
But I know there is a more important question here, what do I want the
framework to be? what do you? and finally what wants Microsoft?
I am happy that I can write programs using the .NET. And using Lutz Roeder's
Reflector I can (almost) allways see what the framework code is doing. For
me it is great advance over VB5 (or VB5.1 = VB6).
I have not read the full code for the framework. But the only thing I can
remember that was in the win32 api and was not wrapped is the URL class. So
there is at least something that is not wrapped (and could have been)!
Best Regards,
Alejandro Lapeyre
"palang" <[email protected]> escribió en el mensaje
Java tried that route with swing. Look where it got them. Java fist started
with an AWT which used the native OS API directly. Then Sun came out with
swing, which is a pure java implementation of the UI. Have you ever seen
what
a swing app looks like? Believe me it's not something to brag about. Almost
everybody I talk to that is currently using java is switching to SWT which
is
once again an API developed using the native OS UI API.
Also,
Why wouldn't Microsoft want to take advantage of the underlying Win32 API?
If the OS shell ever changes (hint Windows XP and themes), the .Net
framework
would be consistent out of the box.
Therefore, having the .Net framework utilize the Win32 API will give us a
consistent look and feel. Whereas having a pure managed implementation might
give us a consistent UI but would certainly have to be changed with every
release of the OS and framework version.
That is the beauty of the framework. It allows you to easily interop with
Win32 and COM.
Or, is it important for the framework to wrap the win32 api ListBox?
Against wrapped controls:
There are two controls that provide list support: the ListView and the
ListBox. The ListBox can handle rows of different height, something the
ListView does not. But the maximum row height is only 256 pixels. The update
routines for the ListBox are horrible (lots of flashing).
So i think it is good candidate for replacement.
We have been in this wrapping path for a very lon time (At least from vb3).
And there have *allways* been a lot of wrapping errors, missing features,
etc. And, I dont like to see a a hundred of internal calls just to add an
item to a ListBox.
Yes, we can write new controls, and that is very easy now! (compared to what
is was in VB5 or VB6). So can do framework. In case we need those wrappers,
we could also build them. So, what is neccesary: a wrapper to a win32
ListBox or a ListBox?
<
Therefore, having the .Net framework utilize the Win32 API will give us a
consistent look and feel. Whereas having a pure managed implementation might
give us a consistent UI but would certainly have to be changed with every
release of the OS and framework version.
Note that updates to the underlying win32 implementation will not be
magicaly implemented in a previous framework wrapped control. If you care
about the fancy drawing details, then the framework could define a new class
that would wrap the painting of the controls (and you get the "system"
painting).
But I know there is a more important question here, what do I want the
framework to be? what do you? and finally what wants Microsoft?
I am happy that I can write programs using the .NET. And using Lutz Roeder's
Reflector I can (almost) allways see what the framework code is doing. For
me it is great advance over VB5 (or VB5.1 = VB6).
I have not read the full code for the framework. But the only thing I can
remember that was in the win32 api and was not wrapped is the URL class. So
there is at least something that is not wrapped (and could have been)!
Best Regards,
Alejandro Lapeyre
"palang" <[email protected]> escribió en el mensaje
Java tried that route with swing. Look where it got them. Java fist started
with an AWT which used the native OS API directly. Then Sun came out with
swing, which is a pure java implementation of the UI. Have you ever seen
what
a swing app looks like? Believe me it's not something to brag about. Almost
everybody I talk to that is currently using java is switching to SWT which
is
once again an API developed using the native OS UI API.
Also,
Why wouldn't Microsoft want to take advantage of the underlying Win32 API?
If the OS shell ever changes (hint Windows XP and themes), the .Net
framework
would be consistent out of the box.
Therefore, having the .Net framework utilize the Win32 API will give us a
consistent look and feel. Whereas having a pure managed implementation might
give us a consistent UI but would certainly have to be changed with every
release of the OS and framework version.
That is the beauty of the framework. It allows you to easily interop with
Win32 and COM.
B
Bob Grommes
Vyacheslav Lanovets said:
Nah, not in VB.NET, in C#.
Seriously, though, when I say "complete rewrite", I don't mean that so
literally that every single line of code will be rewritten. For example,
come the year 2020, let us suppose that Microsoft has decided that C# is a
thing of the past and we should use D# or E Flat or whatever they come up
with for Visual Studio 2020 and the Quantum.NET Framework running under
Windows HyperServer 2020 for AMD 256 bit processors. Now if I did a rewrite
of a project originally concieved way back in 2005, and I had a general
purpose routine in the original C# code that does matrix addition or token
parsing or something of a very basic nature, and I could call the old code
without a significant penalty, I would in most cases leave that code
completely alone. It's usually no individual routines that are the problem
so much as higher level things like where they are in the object hierarchy
and how objects are composited at runtime and the contracts they have with
each other.
It's true that all things being equal, each subsequent system is better,
stabler, and longer-lasting than the previous one. But organizational,
budgetary, technological and political realities tend to conspire against
this. In my experience over more than two decades, taken as a whole, every
system is built with some compromises, some bad assumptions, and some lack
of anticipating what direction things are going to evolve in, no matter how
much talent, care and foresight is applied. Such systems acquire what I
call "system lint". These are regrettable artifacts that start out as
insignificant annoyances and slowly evolve into roadblocks. They will never
really go away without extensive revision or rewriting. Of course you have
to be careful not to introduce new problems in the same process!
Then, too, projects sometimes push the limits of current technology
platforms. I'm put in mind of a classic ASP project that evolved into a
painful mass of nested #includes and Response.Write statements and would be
able to be implemented so much cleaner and maintained so much more cheaply
in ASP.NET. But to do this would require an extensive rewrite.
I'm also currently working on a project that is itself a complete rewrite of
a FoxPro 2.6 application from 1991 or so; we're re-doing it in VB.NET and
SQL Server. Fox 2.x is pre-OOP, and porting it to FoxPro 9.0 would have
been quite a project, and then there is always the fear that all the
prophecies about the demise of Fox that have continued decade after decade
will finally become self-fulfilling one day soon, so we decided it was no
more work to just move it over to .NET. You can barely get the Fox 2.x
runtime to function under Win32, and the UI is sort of Win 3.1 in appearance
and rather atypical in the details of its behavior even aside from visuals.
The software is sold commercially to a vertical market. It's an
embarrassment to the client, and that's why they want to bring it up to
date. That, and have a code base that will take them through the next
couple of decades (or more if possible).
As we've reworked this application we have many times asked the client, why
does feature X work this way? Isn't that a little inconsistent? Well yes,
but we just didn't think of that at the time and it's been a problem ever
since -- by all means change it. What about feature Y, isn't Z a better
way? Sure, sure, use Z. We just couldn't do Z back in those days. It
wasn't available / didn't work / was too hard. So along the way, the
product is getting considerably better from a usability standpoint, yet with
minimal retraining issues for the user. These are all "WOW, this is a big
improvement / much more intuitive" kind of things.
If an application is feature complete and stable and won't change much, yes.
But most applications evolve constantly as business needs change. Even when
they don't, technology changes can be a problem. For example, a text-based,
80 column by 24 line user interface written in COBOL may be perfectly
serviceable, but it's also a very atypical environment for users, it may not
integrate well with other technologies, and it may be expensive and
difficult to find or develop COBOL talent when it does need to be tweaked.
But I don't say that revisions only make a product worse -- especially
individual revisions, taken individually. I only say that the overall
design becomes out of sync with current realities and becomes increasingly
expensive to maintain.
And please remember, I'm talking about time frames much longer than most
people contemplate in their IT planning. I'm talking about 10, 15, 20 year
old systems. Maybe in rare cases, 5 year old systems. I've been
architecting systems for 22 years; it tends to make me take a longer view of
things.
Best,
--Bob
G
Guest
Who cares about a ListBox if .NET allows me to write my apps faster since a
bunch of stuff is done for me by the FRAMEWORK.
It could be written or wrap whatever for all I care...
bunch of stuff is done for me by the FRAMEWORK.
It could be written or wrap whatever for all I care...
J
Joe
Good points. Thx
Joe.
G
Guest
The SQL Server 2005 Beta I have has certain amount of .NET integration and
requires the framework. Next year (hopefully) will be Longhorn. We're talking
about PRETTY BIG projects. I guess Exchange and Office go after that.
requires the framework. Next year (hopefully) will be Longhorn. We're talking
about PRETTY BIG projects. I guess Exchange and Office go after that.
R
recoil
I would like to post a big round of thanks to Delphi developers. For
creating products that rely on a framework/ runtime that does not make
the upgrade from one major os change to the next. Therefore migrating
customers from a windows 98/pre 2k era to an xp/2k3 era is extremely
painful as one runs into major bugs that running 100 application
compatability wizards and patches is unable to solve. Thank you
developers for creating software that was not only crappy and bloated
but had a limited life cycle and had to be rebuilt.
creating products that rely on a framework/ runtime that does not make
the upgrade from one major os change to the next. Therefore migrating
customers from a windows 98/pre 2k era to an xp/2k3 era is extremely
painful as one runs into major bugs that running 100 application
compatability wizards and patches is unable to solve. Thank you
developers for creating software that was not only crappy and bloated
but had a limited life cycle and had to be rebuilt.