|
If I wanted my hand held I would have learned VB.
"Real programmer program in assembly."
Sound familiar?
Paul.
Have fun,
Paul Westcott.
|
|
|
|
|
At risk of stating the obvious, when I had an Apple ][ and the OS was written in assembler, I used assembler because it gave me the greatest speed. Now my OS is written in C, C++ is the best tool for speed and direct access to the way my platform operates.
By all means use VB to write a simple database, or something that is not demanding. I don't because I don't write such things and when I do I am better able to use C++ due to my familiarity with it. VB is certainly a tool, so is .Net. The former has never been for me, and the jury is still out on the latter.
Christian
The content of this post is not necessarily the opinion of my yadda yadda yadda.
To understand recursion, we must first understand recursion.
|
|
|
|
|
From the looks of it, dot net is really an OS (virtual machine, "execution engine", whatever they want to call it!), and they say that it has mainly been written in c# since being bootstrapped, so maybe your comments are very apt =)
By all means use VB to write a simple database, or something that is not demanding
Although I don't personally use VB much at all, I think it has received more of a bad rap that it deserves because of the laxness of many of the developers rather than its failing. As for "not demanding", well, the vast majority of what keeps us all employed is "not demanding" I would argue. Complex maybe to some degree, but not demanding. And if you CHOOSE to structure VB you can - but let us not concern ourselves with VB, as I haven't used it enough to really be arguing its virtues! (I don't think it has that many, I just believe that it isn't THAT bad).
Have fun,
Paul Westcott.
|
|
|
|
|
I'm not afraid of change (or .NET). But i'm resiting .NET because MS has a horrible record of changing the hot new technology every three months. I have almost no idea what DNA or COM+ or DCOM are and i know it doesn't matter. MS will abandon all of them in a year or so.
-c
|
|
|
|
|
Yeah... the evolution of software development is a real pain in the #$%&*@!!!, but it keeps things interesting.
|
|
|
|
|
I agree that things do change way too quickly, but this is hardly MS's fault. If you go back and look at Mary Kirkland's (sp?) article from 95? 96? 97? about where COM was going you will find that the vision looked remarkably like what dot net is delivering.
Okay, so it's not COM. Why? Because Java changed the technology playing field (how dare a company bring out a new technology!) and MS instead of being stubborn and trying to fit the shoe onto the wrong foot saw that the basic structure was a better plan of the future, so they changed direction (how dare they change to something [at least analysed as] better?)
Oh, I agree that technologies come and go, and that "silver bullet" keeps changing (COM, Java, Design Patterns, UML, XML, COM+, dot net, to name a few!). The trick is just to have at least a passing glance at all of them so that you know when to use them. In my passing glance at dot net I have seen a gem which I will be panning for.
Its a tough life, keeping up, but if you don't like change, why be a software engineer? Retrain in civ eng and build some bridges if you don't want the technology to change with every day... God knows, thats probably want I'll be wanting to do after another 10 years of this  !!
Have fun,
Paul Westcott.
|
|
|
|
|
all true.
but, there is a lot more to programming than chasing MS around. I consider myself to be a "programmer", not a student of MS's various silver bullets.
-c
|
|
|
|
|
I'm surprised by the number of people who say "definetly not" (currently 62%).
Is this because you don't want to learn a new technology?
...because you don't believe the hype?
...because you don't think it could be any better than what we currently have?
Personally I am waiting with baited breath for a project to jump to dot net. I have been programming c++ w/ COM for a fair while now, and I find it "makes sence" but when I try to teach other people I realize that there are just so many "gotchas" that I went through, but have now forgotten (ie. I avoid them with my eyes closed), and I think its time to move on. (Example: playing between ASCII/UNICODE/BSTRs - something that should be a total no brainer, just takes too much effort.)
I think dot net is simplifying a lot of things which have become too complex, I see it as the equivalent step as the multiple memory models of 3.1 to the flat memory model of Win32. I mean if you were used to programming under the old memory model, you got used to it, and could do it, but it was a whole lot of wasted effort.
I don't like chance for the sake of change, but I think that it's not that at all.
Have fun,
Paul Westcott.
|
|
|
|
|
I believe it's the same reason as not admitting VB as a programming tool - mostly snobbism. . Believe me, you can write 80% of almost any application as efficiently in VB as in C++ if you understand what is going on behind the scene, but you'll spend much less time on writing type conversion code, etc. I've talked with a Microsoft's guy from the compiler group some time ago and he told me a sad story how they improved efficiency of the compiled code by 30% but the overall impact was negligible - any call to memory management subsystem eats for breakfast any compiler level improvements.
I understand that a lot of people just don't have a choice - you can't write device drivers in VB or C-sharp - but if you are writing server side code then CLR should be as good as Java. And some people just don't realize that there is no difference between managed C++, C-sharp and VB in the CLR environment. Paul is absolutely right - it's just different runtime model (or different C runtime library, or different virtual machine if you wish) and if you are going to use it depends entirely on your needs and trade-offs between safety, speed, availability and time to market.
BTW, in some (many?) situations CLR's memory management will be even more efficient then conventional heap-based memory management - it's very fast in the allocation phase.
|
|
|
|
|
I said definitely not, but I meant I may well one way, but not by choice. I am always wary of change for it's own sake, change to something that sounds dodgy to me, change to something that is unproven. If we are to assume that everything Microsoft touches turns to gold, could I have a show of hands for all those people using BOB ?
Christian
The content of this post is not necessarily the opinion of my yadda yadda yadda.
To understand recursion, we must first understand recursion.
|
|
|
|
|
or MSN (as it originally was supposed to be)...
I agree with you that one can't just look at MS as a god handing out gifts, but what I do ask is that you look at how much plaque has built up on programming Windows with C++.
It hurts. It hurts bad. I love Windows programming with C++, I love COM but it is just too top heavy (check out Comet for a good implementation of COM in C++). Dot net seems to be addressing these issues these difficult issues.
To me what is on the plate is a lot of value add.
Have fun,
Paul Westcott.
|
|
|
|
|
OK, this is obviously your POV. In what way do you propose that .Net is improving Windows programming ? Speed, or ease of use ? Because I work on a 3D visualisation tool, and a 2D paint program. How will .Net help me to do these things better and faster ?
Christian
The content of this post is not necessarily the opinion of my yadda yadda yadda.
To understand recursion, we must first understand recursion.
|
|
|
|
|
Obvious ease of use.
3D visualization? A 3D library should get stuff done in hardware, so you shouldn't be accessing it directly. 2D paint program? I would say math library routines should be quicker than any code that you could write, because (such as the intel one) are written to be processor specific. These libraries will be accessable from dot net as they are in c++.
Most stuff has been done before, it hurts, I know, I like getting my fingers dirty, but ease of programming, and speed of development, are market factors. I believe (yes, only believe, I could never say "know") that dot net is giving you these. It looks like it cleans up a lot of the grunt work, which in turn allows you to express more complex ideas - there is no sacrific, there is just a paradigm shift that must go on in ones head as to what is "fun".
When I first did a project with Java Swing classes, it was a dream compared to MFC. Even though I was new to it, I preformed at least to the performance level of a GUI product with MFC, and I believe that this would have improved with more familiarity with the product. As dot net has ripped off the Java stuff, I assume that this stuff will be there. Just an example of what can be done to speed the software development process - scrape that plaque away!
Have fun,
Paul Westcott.
|
|
|
|
|
Yes, but keeping track of items being drawn, what to render, changes to items, etc. is going to be done on the fly by our code. Is this going to happen faster through the CLR ?
Processor specific math routines ? So it morphs to benefit Intel or AMD ?
I am glad we agree .Net is ripping off Java.
Christian
The content of this post is not necessarily the opinion of my yadda yadda yadda.
To understand recursion, we must first understand recursion.
|
|
|
|
|
Obviously you wouldn't want Intel's library to be processing for AMD chips! I was just bring it up as an example, as I know intel had a maths library with fourier transforms and sorts of shite that upon loading would choose which dll to use and then use those entry points (no magic morphing!) [such as COM using different objects which have the same interfaces, although the Intel library didn't use COM. I don't know if it still exists, etc. I'm just using it as an example!!]
Keeping track of items to render? Probably not, but is it the bottleneck in your code ? (maybe it is, I don't know)
Have fun,
Paul Westcott.
|
|
|
|
|
A 3D library should get stuff done in hardware, so you shouldn't be accessing it directly.
A 3D visualization library must do a lot of processor-intensive stuff before the data is in a form to send to accelerated (e.g., OpenGL) hardware. Look at The Visualization Toolkit. This is a library for 3D visualization that takes good advantage of accelerated hardware, but still runs about 25 MB of executables (almost 900,000 lines of C++) all to prepare the data for the hardware.
VTK is a cross-platform library developed by General Electric and used extensively for medical imaging as well as data visualization in computational fluid dynamics, earth science, etc. The importance of cross-platform work (there's a lot of work going into parallelizing vtk to run on Beowulf clusters) means that .NET would not be interesting to its developers until there is a .NET for UNIX, but an interesting kind of question that someone like me (I'm not on the vtk team, but handle similar kinds of problems) would ask is "How do I factor a new project of this sort into parts that are well-suited for .NET and which require C++? How hard is it to write a .NET wrapper to interface with my hard-core C and C++ code? How do I make a .NET application friendly for UNIX clients?
He was allying himself to science, for what was science but the absence of prejudice backed by the presence of money? --- Henry James, The Golden Bowl
|
|
|
|
|
fairy snuff.
And the answer probably is that dot net is not for this kind of thing. But doing this type of stuff is a small part of the whole market I would think, not the large part (now 51.39%) who sail "definety not".
Really hard core stuff maybe shouldn't even be using c++ though should they?
Have fun,
Paul Westcott.
|
|
|
|
|
Really hard core stuff maybe shouldn't even be using c++ though should they?
Good C++ is as efficient at runtime as anything other than hand-tuned assembler, and it's much easier to design and maintain. 3D data visualization is a great place for C++ and OO design, since you can think of a visualization process as a pipeline with polymorphous fittings. C++ allows you to easily mix and match pipes and adapters at runtime without any great performance hit.
The interesting question becomes how you take this hard-core stuff, which is definitely not appropriate for .NET, and then interface it efficiently to .NET front-ends. After all, even if .NET were an appropriate technology with respect to performance questions, no sane person would port almost a million lines of C++ to C#. Is there any source of informantion and advice on refactoring existing applications to integrate them with .NET?
He was allying himself to science, for what was science but the absence of prejudice backed by the presence of money? --- Henry James, The Golden Bowl
|
|
|
|
|
I have yet to interface to prior code, but there are two mechanisms that I know of.
The first is P/Invoke (of which Don Box wrote "P/Invoke works similarly to J/Direct from the old MSJVM. Very simple to use, yet fairly flexible and extensible.") which is for invoking exisitng Win32 functions, but I assume that it is for accessing any dll functions (but I could be wrong).
The second is COM Interoperability which treats COM objects as if the were dot net objects.
I agree that you probably don't want to port a million lines of code, and that is why these backward compatibility mechanisms do exists. If I find some information on the web of the methods listed I will post the address.
Have fun,
Paul Westcott.
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
