From: Ajay Kalra on 26 Feb 2010 13:24
> But the younger engineers use the IDE and I am not going to discourage
> them. They are amazed at how fast I program and how fast I swap things
> around with macros, but but its foreign to them. They really don't
> know the difference and they think it (IDE) is normal and I believe
> that is what Microsoft is thinking is the market too.
The trouble with this logic you are comparing an exprienced person,
such as yourself with others who are rookies with IDE. IDE is very
very powerful. You can have define any macros you want to do whatever
you want. I have customized my keys to whatever I want, inclusing auto-
checkout, comparisons, code insertions, debugging, code view etc. I
would be surprised if IDE cant do what you do in the other tool.
In C#, there is a tool called Resharper which is designed for such
things. Equivalent to some extent in VC is Whole Tomato's product.
From: Hector Santos on 26 Feb 2010 13:45
Ajay Kalra wrote:
> I used MFC for 10 years and have been using C#/.Net for over 4 years.
> Startup time is probably an issue(not if you use NGEN) but thats no
> reason to dismiss it. .Net is significantly ahead of older
> technologies. Our apps are trading apps in real world where
> performance is of extreme importance and it works fine.
I did some work with TradeStation (Omega Research ) during the early
90s. Familiar with them?
If I understand your usage, it is useful (become feasible today) to
implement a "p-code", "jit" or scripting environment even for
graphics. Scripting environments, as well as managed environments
has become more feasible today, of course, because of the faster
machines, including higher bandwidths for remote client/server
frameworks. Of course, when selling a commercial product , it makes
even more sense to have this level of flexibility.
I think the world is still in a transition. To get a feel of the
evolution, just look at our product history where we offered the
following to access the mail system:
- Console/Text based with ANSI/VT100 displays if enabled
- Telnet or dialup (same interface)
- RIP, now deprecated, it predated HTML and was considered
the front runner when introduced and was the darling
of trade shows. RIP was a ICON/GLYPH based tokens
language that allow RIP terminals to show GUI.
- MAPI Exchange, this allowed Outlook to display our
group forums as folders on user machines.
- Native GUI frontend with an MFC applet, still available
- RFC based NNTP protocol, POP3, IMAP
- Online Web Mail
- Flat Views
- Threaded Views
- Topical Views
What I believe you will see more is a trend for vendors to provide
their own Native GUI frontends for many times, including tech support
services. This time they will use client-side technology such as
Flash, FLEX and SilverLight and browsers HTML5. I am confident Google
is moving this with with Chrome using a Chome OS based on V8
the mobile side is .NET so WP7 Apps will be .NET based instead of
There is another major reason for vendors to produce proprietary
frontends - EOLAS has obtained a frivilous patent on "WEB 2.0" and has
already began to sue major WEB 2.0 web sites.
Its a crazy frivolous patent, but if companies are not going to waste
time fighting it, there only choose is to move to proprietary
frontends and non-WEB 2.0 technology, such as FLEX, SilverLight, WPF.
Of course, in the future this is not going to help the industry to
single source their "Viewer" - like a browser with HTML does today.
A new standardization is required by the big boys. HTML5 is suppose
to provide this hope but I am not sure how the EOLAS patent relates to
this. I have recently read a "blab" for a call for standardization
on the Flex, SilverLight like front because it is pretty sure that the
future will move more of the power requirements to the client - i.e.
offline technology, which BTW, IBM has many patents already in the
area of cached storage of the "resources." :)
From: Hector Santos on 26 Feb 2010 14:21
Ajay Kalra wrote:
>> But the younger engineers use the IDE and I am not going to discourage
>> them. They are amazed at how fast I program and how fast I swap things
>> around with macros, but but its foreign to them. They really don't
>> know the difference and they think it (IDE) is normal and I believe
>> that is what Microsoft is thinking is the market too.
> The trouble with this logic you are comparing an exprienced person,
> such as yourself with others who are rookies with IDE. IDE is very
> very powerful. You can have define any macros you want to do whatever
> you want. I have customized my keys to whatever I want, inclusing auto-
> checkout, comparisons, code insertions, debugging, code view etc. I
> would be surprised if IDE cant do what you do in the other tool.
> In C#, there is a tool called Resharper which is designed for such
> things. Equivalent to some extent in VC is Whole Tomato's product.
Don't get me wrong. I agree with you. I'm among the exception than the
rule. I am not a cut and dry person. Everyone has their reasons so I
am trying to indicate one way is bad or the other. Personally
personal. I do use the IDE more than I said I do. But its not my
principle programming tool and only because I want things done fast.
For example, if I wanted to write a quicky, maybe as an example for a
post here, I pop up Qedit, hit ctrl ], and a C/C++ console outline.
Type whatever, hit F9 compile and done. This is far slower than
loading the IDE and a small hassle just to get a single file compile
and link. I think now with the VS200x, if you do this, it wants to
create project files, solutions files, output files, etc, just alot of
Maybe there a way around that, I don't recall if I found that, but I
haven't fully embraced VS200x to know for one main reason, we are not
ready to complete to .NET. Everything we have is RPC, WIN32 and MFC.
Millions of dollars invested over the years, including the packaging.
Sure, we can put a label over the requirements copy on the box (.NET
required), but overall the revamping is a major investment and in my
MS did show signs of neglect towards long time developers. I
personally believe Ray Ozzie is the blame and thats only probably
because I have to blame someone :)
Yes, I did like the C# editor features over the VB features. I love
the idea of refactoring, or what that called "reshaper?" Same thing?
Yes, the macros are possible with the IDE and I have used it. I guess
probably if anything, is not wanting yet to retool the IDE with my
long time productivity preferences especially since I wasn't fully
committed to it.
What didn't help was:
- VS2005 was really slow in compiling. I spent a lot of time
trying to figure that one out.
- Intellsense was really slow, yes, got the old patch, I don't
- Not having MFC class wizard support,
- the Online Help was BROKEN, and thats probably because
- I was FUMING with the idea that a IDE was not a "social
networking tool" and I removed a DLL that was invoked for
this in the IDE. I forget what dll it was, but its
documented in the net as a way to effectively disable
this "spy ware"
The latter is extremely personal to me as a highly ethical engineer
that has designed software that addressed high ethicals in social
engineering and have probably lost millions if not billions because I
am such a stickler for such strong engineering and privacy issues. I
will probably say that this VS issue alone of having this "social
help" thing in the IDE was the #1 reason I stayed around from VS and .NET.
It bothers me a lot but I also grown weary and apathetic to the
reality that users today don't care - its the "new normal." In fact,
that apathy is shown by the fact that I began to install things,
including VS2005 again to just LET It do its thing and not try to
inference in how it suppose to work. That new "attitude" is needed
today because many things today do not work without having what is
expected enabled - like a web site that totally breaks done if you
company to be pinged!
From: Joseph M. Newcomer on 26 Feb 2010 14:45
On Fri, 26 Feb 2010 13:05:40 -0500, Hector Santos <sant9442(a)nospam.gmail.com> wrote:
>David Lowndes wrote:
>>> Or the fact that they basically re-implemented what was already a flawed design.
>> From a couple of the issues I noticed, I have a suspicion they
>> reimplemented it from an early version before bugs were fixed (a long
>> time ago).
>Personally, I have held off from upgrading from VS2005 and was
>"excited" to hear that VS2010 was the new "VC6", that microsoft took
>notice of the long time investments in MFC and long time developer
>neglect during the last decade.
>But it seems the same of issues (and possible worst) has continued. I
>read the project manager blog and I believe he was misguided taking
>"reviews" from testers who I honestly believe they don't really want
>to tell him the bad news, so they tell him "its better than the beta"
>and believes thats OK! I don't think that is the real test.
>I'm a speed demon, power programmer. I really only used the IDE to
>design the GUI and outline of events. From there, I use my trusted
>Qedit (renamed to TSE) power programmer editor
>(http://www.semware.com) of 30 years - the BEST in the world. :) I
>need fast loading, no slow downs in typing, and fast macro programming
>for patterns. I don't need intellisense slowing me down - its terrible.
I'm with you on that. We can debate whether qedit (which I've never used) or Epsilon
(which I've used for 22 years) is the "best" editor, but the key thing Microsoft
COMPLETELY overlooked: editors are not a technology, they are a religion. The ONLY sane
approach was to provide an editor-friendly API to encourage third parties to produce
editors. This includes all the Intellisense, highlighting, etc. features. They simply
don't understand this rather simple point, which everyone else has deeply understood for
YEARS. You like qedit. I like Epsilon. People actually think vi is a text editor. It
DOESN'T MATTER! Key here is that Microsoft is largely clueless about what constitutes a
text editor, thinking that what they have is the only editor that could make sense. They
I use the VS IDE editor for debugging, for making trivial syntax changes (misplaced comma,
missing or extra right paren, fixing my SetWindowTxet and GetWIndowText typos, and THAT'S
IT! I would NEVER consider using it to create a program! It is so weak as to be nearly
unusable, and it is not user-extensible in the way a truly user-extensible editor MUST be
to be acceptable!
When I teach classes, I keep vim (the open source VI editor) on a USB key, and anyone who
wants to use it, I plug the key in and install it for them. A nontrivlal number of my
students like this fact.
No matter WHAT the build, it will not be acceptable to the people who know what REAL text
editors look like. I'll trade off ALL of the syntax checking and Intellinonsense for the
power of my editor. [Actually, I already do that].
>But the younger engineers use the IDE and I am not going to discourage
>them. They are amazed at how fast I program and how fast I swap things
>around with macros, but but its foreign to them. They really don't
>know the difference and they think it (IDE) is normal and I believe
>that is what Microsoft is thinking is the market too.
I find the attitude that "we know best how you should use your primary interface to the
computer, and screw you for believing otherwise" to be inappropriate.
>I personally believe a big part of the slow down has to do with
>security related stuff and all the new layers of dlls and sub-systems.
>VS2005 compiles 50%-250% slower for the same code. I dug into this
>with depends and found that during compile it the Crypto sub-system is
>ALWAYS invoked and this is where there are compiler delays. But
>surprisingly, when I called this with VC6, it did the same thing but
Part of the problem of VS2005 was it was the first really-first-rate C++ language
implementation. They had a few problems with the compiler, including its performance, and
most of those were fixed by VS2008, which is what I mostly use today.
One reason VS6 was faster was that it was both incomplete and wrong. It couldn't compile
even its 1998-contemporary C++ language (serious conformance issues, especially in
templates). Those fixes did cost performance. But Microsoft has been very sensitive to
this issue and has addressed this problem, very intensely, in subsequent releases. They
also have ported some 64-bit compiler components back to the 32-bit world (read the VS2010
"What's new in VS2010" and these represent performance improvements as well.
VS2005 was definitely a slow compiler compared to VS6. I have not done the measures with
VS2008 or VS2010, but I know that performance is a continuing issue and will continue to
>I just did a quick timing test with a 1 line hello world:
> XP box source code across the LAN:
> VC6 : ~700ms
> VS2005: ~1600ms
These times are too small to matter, and the source example is too small to matter. Key
performance comes with looking at 100SLOC-sized apps. For example, separate compilation
overhead in VS2005 is substantially higher, but when amortized over 500 source files it
doesn't show up as badly. Part of this is a richer .pch format necessary to support
templates properly, or so I was told.
But right now, even for large systems, 2005 is measurably slower than VS6.
>When I first encounter this, I had a 1G XP box. I was seeing 1:5
>compiler speeds. Adding another gig (2GIG total) with some registry
>changes to fine tune the Paging system, it was more acceptable now,
>but still slower.
The VS2005 compiler is also substantially larger than the VS6 compiler. The price of
doing C++ right.
>When I measured the time differences via DEPENDS, the time was only
>lost with the crypto sub-system which was invoked for some reason, all
>other times were the basically the same.
The use of the crypto subsystem is definitely weird. I wonder what they are checking?
Llicense validity? No idea.
Joseph M. Newcomer [MVP]
MVP Tips: http://www.flounder.com/mvp_tips.htm
From: Joseph M. Newcomer on 26 Feb 2010 14:50
OpenGL is a contemporary standard, and unlike DirectX, is both platform-independent and
has a large body of non-Microsoft users who are expert in it. The last I looked at driver
certification, a device driver had to support GDI, DirectX and OpenGL to get logo
..NET doesn't solve the 3D problem if you are trying to port your visualization software
across. Far too slow. I know some people who are implementing parts of their rendering
software with the 3DNow! (AMD) extensions as replacement modules in some of the OpenGL
None of these people, who are desperately concerned with graphics performance, would
consider WPF or .NET a suitable replacement.
[Note: I really like programming in C#, but I don't have a customer base that uses it]
On Fri, 26 Feb 2010 09:43:20 -0800 (PST), Ajay Kalra <ajaykalra(a)yahoo.com> wrote:
>On Feb 26, 12:21�pm, "James Juno" <j...(a)noplace.fake> wrote:
>> Funny thing. �My shop specializes in scientific data visualization using
>> OpenGL. �We've replaced some of the MFC controls with in-house (and
>> superior) equivalents rendered in an OpenGL context. �I guess in a sort of
>> bastardized way, this is similar to WPF. �Still, we're unlikely to consider
>> using WPF anytime in the near future. �Our toolset is too highly integrated
>> into the more battle-tested and mature (or, depending on your agenda,
>> "legacy and obsolete") technology.
>I am certain I will call OpenGL as obsolete technology(May DirectX is
>now better; dont know). There is no agenda here but for vanilla UI
>apps not requring any specialization, .Net is far superior IMO. Even
>with apps requiring specialization, .Net can coexist comfortably.
>The problem is not about embracing a newer technology, its about the
>cost of migrating over existing system to newer one. Normally there is
>no reason to do it and its a waste of resources without any real
>benefits. However for new apps, these rules dont apply.
Joseph M. Newcomer [MVP]
MVP Tips: http://www.flounder.com/mvp_tips.htm