No, most don't. You need an emulation layer to run the most flexible development tools; those found in UNIX. Because windows lacks basic automation powers outside of normal user processing, the developer has to write "helper programs" that on UNIX are already written, to do basic transformations.
No pipelines, no universal application interface, I'd say windows doesn't have any of the things that I use regularly in my development.
The interop argument is silly. If you're writing code for interop you can do it just as easily on Windows as any other platform.
No you can't. It's certainly much easier to build and develop on a unixish system than on a Windows system.
My schism tracker project builds automatically for Win32, x86/Linux, and ppc/MacOSX all from the same source tree, all in parallel, and at one point, all from the same machine.
I do not see for a minute how it is even possible to do this on Windows unless I either (a) do an awful lot of work, or (b) use a UNIX environment on Windows and do slightly less than an awful lot of work.
If you're writing stuff for Windows, you have the support of some of the best frameworks available today.
If you mean to say, writing software _on_ windows gives you access to some of the best frameworks available, I have to tell you you're wrong. Most Windows frameworks have very poor accessibility outside of C++, or possibly VB.
If you mean to say writing _targetting_ windows gives you access to some of the best frameworks available, I still have to say you're wrong. The win32 frameworks don't mesh well with any other systems' development model.
Seriously, Free software means that _this_ is what the people want. They want it so bad, they're making it themselves.
Very few people actually use windows- you ask them what kind of computer they have, and you'll hear "Dell" or "Packard Bell" or "Gateway" - maybe even an "IBM". These people have no idea what they're using or if anything might do what they want better.
Leaving out the fact that this is Free software is trollish- if you don't qualify any comparison with "This is what the people who actually have to use it want to use", then you're just feeding this FUD machine that zero-charge software equals lower-quality- because OF COURSE there's something available for Windows that isn't available for my Free operating system.
Doesn't mean I miss it in the slightest.
And by the way, I have no problems using tax preparation software on Linux, or converting things to and from PDF. I also have no problems watching DVDs legally- as my DVD player and software predate the DCMA.
I have no interest in Visio, Framemaker or Photoshop, or rather any other software that doesn't want me to use it. I may be interested in performing some of the tasks that are possible with these programs- but I've already got adequate Free software, that works and does things the way _I_ want to.
On my FreeBSD I compile almost everything from ports. That way you have maximum control about the options and CFLAGS with wich your app is compiled.
Whoopy. You've managed to take the worst aspects of FreeBSD (that fewer people use it) and combine it with the fact nobody is QAing your CFLAGS but you.
Thanks for putting untested configurations on the Internet!
On Linux I think that Gentoo's portage comes closest.
Portage is much more stupid than FreeBSD's ports. With FreeBSD's ports- just about everything is QA's and available in binary form elsewhere. the/usr/ports tree makes it very easy to get to those things- so what if they use make to do it? It's _exactly_ the same thing as rpm/rpmbuild.
Don't think for a moment "compiling all your programs" - or "custom tailoring CFLAGS" isn't costing you something very significant.
yum/rpm/rpmbuild or apt/dpkg/debuild are perfectly fine for tuning compile-time operations without busting the QA group. They do _exactly_ what/usr/ports and Gentoo portage do, they're just an awful lot more polished, faster, and all around better.
The big benefits of precompiling are that you don't need to support 1500 different sets of libraries in your development environments, and that the package will generally work right with minimum fuss.
No. The benefits of sharing a binary is greater than that. You get to take advantage of all the QA the packager has done, and all the QA everyone else using that package has done.
Libraries aren't even related.
The big benefits of source-based distros are the ability to tailor packages to each install (ie the ability to compile certain features in or out), to choose optimizations on each package (do you want -Os, -O2, -03, or are you really daring -ffast-math?).
No. There are no benefits to source-based distros. Or if there are, it's not because they're "source-based".
There are however, numerous drawbacks: They're slower, they have a QA-size of one, and they waste time, just to name a few.
For what it's worth: I have no problem "tailoring" binary packages for other distributions, and its helpful that other people have tailored them the same way- I get the ability to turn on or off certain compile-time flags, while still taking advantage of a large QA pool.
In my field, ten percent is everything. If I could increase performance by ten percent, I'd get a 100% bonus for the year. My servers need to handle so much data and are always backlogged (and adding more on is exensive!) Don't trivialize ten percent.
I hope that the point is that you cannot increase performance of your servers by 10% by recompiling your software, just decrease YOUR performance by 200% or more by attempting to do so.
Recompiling someone elses software is usually foolish. You lose support, your QA department becomes YOU (instead of all the other people using a distribution), and for what? Have you measured it? Is the increase signficant? Why aren't those shiny new CFLAGS in -O2 by default? What doesn't your distribution do it for you?
Don't trivialize 200%. It's an awful lot of upfront work, and you will never see a return on it.
Compare, say, setting up apache on a typical Linux distribution with configuring IIS on Windows. The difference is night and day.
Completely agreed.
Setting up 2000 web sites and virtual directories across 20 machines requires no additional programming on Linux, but either requires a significant amount of programming or a significant amount of effort to do the same on Windows.
This is how I define ease of use- by how easy it is to use, not by how easy it makes already easy things.
it's that kind of myopic outlook ("it works for me, you must be too stupid") that makes it so difficult for Linux to gain acceptance.
Well, I would imagine that's because they do it alphabetically. 'Bush' is pretty high, alphabetically.
Hah, I only wish that were true.
In actuality the incumbant is listed first, failing that the incumbants party. Except in some states where it's the governer's party, or failing that, whoever the governer^H^H^H^H^H^H^H^H^Helectoral collage representative (chosen by the governer) damn well chooses
Bull. All of the work should go over smoothly. I ported several mid sized applications over, and they went just fine. you'll get some warning as you'll likely be using some depreciated classes, but you can continue to use them just fine.
We're using different definitions. Mid-sized projects take a few months. Large projects are the ones than span years.
The point behind this is that you cannot be using deprecated classes, because if you were, you'd still be targetting.NET 1.1
Or to put this another way- the author isn't asking how they can compile their code with the.NET 2.0 toolchain, but how they can "keep up" with the changes that were introduced with.NET 2.0.
That 10 year old code may still be working, but I'll be I can add new features alot easier in my C# code than you could in plain C.
I didn't say working, I said it's in production and development. That means it's still maintained, improved, and etc, to keep up with the growing demands from our customers.
Come see me in 8 more years, and we'll be able to compare some 10 year old C with 10 year old C#.
Funny how whenever these black box voting machines "just don't work", they error in favor of republicans.
Or at least it would be if RNC contributors weren't the same people who lobbied for the machines.
Or if several of the RNC offices hadn't told registered Republicans to cast absentee ballots because of "machine malfunction"
Or if the Republican positions on the ballot weren't at the top (enum 0)
Or if it weren't a combination of all of these events that just plain look suspicious.
This was Republican districts pushing for these machines in Democrat (read Black) neighborhoods and then urging their own to not use them.
When it turns out the Republicans were right and the machines aren't to be trusted, there's some legitimate suspicion as to exactly why these machines would all vote Republican.
Yeah, every app should be done in C. Why bothering with C++, C#, Java, Python, Perl, PHP, ML, Haskell, Erlang, Lisp etc? what can be done in those languages can easily be done in C anyway...
Mostly right. Of the languages you listed, there are some gems:
* perl4 code stills runs in perl5 interpreters. Perl6 promises to run perl5 and perl4 code.
* Lisp too has remained unchanged [incompatibly] for decades.
* Erlang was deliberately designed for language-feature durability
Of course, C++, C#, Java, Python, and PHP have all been moving targets (incompatibly I might add, although Java and Python certainly show signs of getting better). ML has long since been fragmented needlessly, and Haskell is too new for me to comment.
I might add that Objective-C, FORTRAN and COBOL are excellent, durable languages as well. The Objective-C framework has demonstrated that it's extremely durable as well.
But don't confuse my point: Durability is [certainly] not the most important thing in a language or a framework, but it IS important, and basing so much of your company on something that has demonstrated that durability is not important at all is dangerous.
Bottom line: If the poster actually wants durability, they shouldn't be looking at.NET at all.
That's not to say.NET or C++ won't become durable- maybe in five or ten years we can make that decision. Surely code will have to be written in the meantime, and that will find faults in its overall design.
You can take 10 year old code, run it through Visual C++, and it runs on Windows XP.
Actually, this is something to attribute to Microsoft. By breaking the C++ standard in so many places for so long, they've really made their own version of C++ (which they actually tried to submit to ECMA recently as "C++/CIL" if I recall correctly)
It's not C++ that's stable- far from it, C++0x breaks things again. Subtle things, but important things. Microsoft has at least done well at making MSC++ stable.
Customers don't want to muck with migrations every 1 or 2 years, they want some decent ROI.
So this question is more analogous to "I'm moving from Gtk 1.2 to Gtk 2.0. What's likely to break?".
It's not similar to that at all.
Try doing that without any code changes. Your fancy, schmancy C language doesn't help you at all.
That's not the point. He's been writing this code for two years, and maybe they're just getting to the point where they can do something with it and BAMMO they need to start thinking about where they're going next.
If you're looking for a good analogy it's something like this:
Vendor gives you fancy shiny new SQL interface, so you begin porting your entire enterprise to it (after adequate testing of course). It takes two years and you start seeing some benefits. Vendor decides after two years that they've made some things better but in order to get ANY of it, you need to redo the last two years AGAIN.
The point is what's to stop this cycle?
(A) the vendor gets it right and stops. (B) the customer gets it right and stops.
I work in embedded systems. I don't care how "standard" C is--it's only the source code that's standard. When we move to a new processor or the compiler upgrades, we spend weeks chasing subtle bugs out of the code.
You do of course realize that those bugs were already there.
Never mind complex stuff like trying to port our stuff to a new RTOS or trying to integrate thousands+ of lines of purchased source code into our product.
I think that's a little different.
You at least know you're porting to a new kernel with slightly different semantics, and you'll also know when you're trying to purchase infrastructure.
The problem is upgrading to something to get some futures benefit- like converting your application to your own private RTOS- an emulation layer that runs between your POSIX-like application and whatever else you want to run on. It doesn't have any immediate benefit to you (after all, most RTOS are either fairly similar, or not really a good target to port to), but it just might.
Here's a group that wants upgrades. They don't know why- it's clearly "for futures stuff", but it's going to break things, and you know, just by the time they get done, they might have to start back up all over again for.NET 3.0
As I programmer myself, I realize you're talking about code that's pretty self-contained and algorithmic in nature.
No, I'm not.
Other coding projects, though, need to interface with hardware and other commercial software (like databases) all of which evolve over time... and if you want to take advantage of any new advancements they might provide then your code will have to evolve as well. Sometimes you don't even have a choice (a database company might drop support entirely for an old package) so updating code is part of the job.
I have no difficulty interfacing with hardware or commercial software in C. I have no problem _writing database servers_ in C.
And not to put to fine a point on it, but if your database company dropped support for something your business depended on, you made a horrible mistake in picking that database company.
Yes, upgrading is wrong. If your vendor makes you upgrade, it's because THEY made a mistake by shipping buggy code, or YOU made a mistake by picking them. Whether the upgrade is better or worse than the previous version is for ME, the user, or the developer to decide, and not my vendor.
In any event, you missed my point: C# and.NET is an immature moving target. A company or an individual that puts so much of themselves into such a beast gets what they deserve when Microsoft says "nononono, we didn't mean that, here's what we REALLY meant. just in time for people to start deploying" and deprecates all your hard work.
I am not saying that there is never a place for C# or.NET or C++ or anything even remotely similar to that. I'm saying that if you have to build out a bunch of technologies that are supposed to last, and "ah" suprise- what's to stop Microsoft from doing this again in two years?
I have C code both in production and development that's over 10 years old at this point, and at no point do we have to find a "upgrade strategy" as the foundations set up by K&R were good 30 years ago, and they're still good now.
Meanwhile, you're looking at how to deprecate a big chunk of your company's development value after only two years- and although you haven't said it, I wonder if you've even gotten your value back from all that work?
I'd say to find out how you can make sure you won't do this again in another two years. Start migrating to something else- anything else.
Regarding the extra argument, it should not be required for a good allocator implementation. Look up Alexandrescu's online articles on small object allocators, although he does not address the relocation issue.
The key here is not a good [general purpose] allocator, or a small object allocator, but a very specialized allocator implementation- one that handles very large cache "objects" made up of many smaller objects.
Managed languages solve this by relocating pointers- or by using indirect pointers (where the target can be relocated safely). Modern operating systems that support paging often give applications the ability to manipulate pages, which means that pages can simply be "discarded" out of order as the underlying hardware is providing the indirect pointer.
The problem with paging is that languages aren't designed for paging, and malloc()/new interfaces cannot get enough information for some tasks.
Pool-allocators DO work well with paging, but they require information that malloc()/new don't provide- hence the "extra" argument.
You would use a class-specific operator new, no? That way you would not need an additional argument to specify the pool.
That would work if you had a class like BigCachedObject that all of your big cached objects could derive from (each being their own pool) but nobody does this in practice. Instead you've got a very small HTMLView object that contains an HTMLDomNode tree that's a bunch of pretty small objects linked together, a HTMLRenderedBlock tree which is a bunch of pretty small objects linked together and so on.
If you had a class specific new that used mmap() for HTMLDomNode or HTMLRenderedBlock, then you'd be making a big mistake as each of those objects are below the system page size and your performance would suffer greatly. On the other hand, a class specific new on HTMLView wins nothing either.
Worse still is if you create a bunch of temporary HTMLView objects within scope that you free before leaving the current scope (or parent), so the heap (or even the stack!) is much more appropriate.
Instead you'd need a way to specify a class specific new "when assigning the allocated object to a member of an instance of class X"- something C++ simply cannot do (as new has no idea what it's being assigned to).
In this situation, I suggest people use a class static method like HTMLRenderedBlock::newRenderedBlock(PoolManager*po ol=0), but that's not "new" now is it?
I wouldn't know about C, but this statement is utterly false as applied to C++. Replacing the default new and delete routines is perhaps not for the inexperienced C++ programmer, but to say that there's an complete lack of compiler support is simply wrong. It is true that out-of-the-box C++ does not have a compacting garbage collecter, but one can certainly be written (and used, of course) with any conformant compiler.
What you'd need to be able to do is move an object in memory and yet make all of the pointers that referenced the object in the original place still work. C++'s object system pretty much makes this as close to impossible as can be.
You need assistance from something greater than your language, and it just so happens with many C libraries, this can be done very easily- simply use mmap() for allocating your chunks instead of malloc() for "large objects". You wouldn't want to do it everywhere (i.e. you wouldn't want to replace new/delete with it) because performance would suffer greatly.
In order for C++ to do it with anything resembling "reasonable" performance, you'd need to derive your new/delete from a pooled allocator. This'd mean an additional argument to new/delete to specify the pool and would not be transparent or compatible, or really even very much like C++ programming at all.
Interestingly enough, Objective-C does use pools, and when using an autopromoting realloc, all this page-level compacting already happens automatically.
You can decommit the page, but keep it reserved. This frees RAM, decreasing the process's memory usage, but still takes up some of its address space. You MUST coalesce free heap blocks in this case, because all data in those pages is lost. This also requires extra housekeeping.
mmap() can do this, but on many systems [s]brk() cannot. brk() is also alot faster than mmap().
This is really moot on most systems; don't do a lot of little allocations that you're going to keep around for a while and DO use pooled allocators that can use mmap(). It requires planning, but it really does pay off for applications that need an awful lot of memory in stages.
This is (by the way), why many C compilers are implemented in "stages", so that they don't have to worry about crap like this. Allocate as needed, and the next stage exec() will automatically compact and garbage collect any pages used in the previous stage that aren't needed here (that weren't passed to the next process using mmap or pipes).
Sorry, but I was much more apt with Graffiti than with Graffiti 2 or any other "handwriting recognition" system.
Why? Because two strokes is slower than one. When writing longhand I allow for a certain amount of illegibility that I can fix up later- but with multi-stroke "handwriting recognition" I have to do each glyph separately. With Graffiti (1) writing out meant lifting the stylus briefly between letters. Less lifting, faster writing.
So much so that I copied the Graffiti library from my Palm V to my newer Palm. Works great.
But wait -- what about the phone? Forget it. While some people do use the phone to replace the palm, most never do much but store phone numbers. Further, people are used to a phone being replaced every two years - for free. That is a market that pays for itself in the marketing of minutes. Not a good place to play.
Yeah, that's because things like the TREO are good at everything except being a phone.
If someone really could figure out how to marry a phone to a PDA I'd be the first in line to get one, but nobody has figured out how to do that yet.
I suspect when bluetooth IP becomes more popular, the "phone" will simply be the little transmitter knob in the pocket; the PDA will be the dialing and web browsing interface, and the earpiece will be, well, the earpiece:)
Not only is it wrong for Microsoft to extend Java, it's wrong for SUN to extend Java (incompatibly). The fact that some JRE1.1 applications cannot run on JRE1.5 is a bug, and it's why some people don't develop on Java- because it simply isn't a stable platform.
Of course you do. Enjoy your Betamax and Edison record collection.
Meanwhile, the rest of reality requires that once people start using GetDiskFreeSpace() that it should always yield useful results, even when you really want people to start using GetDiskFreeSpaceEx() unless you want people with disks that have 30GB free to get "out of disk space errors" when they try to install a 300K application.
See, standards are about usage. Once it's out there; once the API is published for use, the inventor gives up their "right" to change it.
Slashdot Mirror
Really? Windows has excellent development tools
That's debatable...
almost all 3rd party tools run on Windows
No, most don't. You need an emulation layer to run the most flexible development tools; those found in UNIX. Because windows lacks basic automation powers outside of normal user processing, the developer has to write "helper programs" that on UNIX are already written, to do basic transformations.
No pipelines, no universal application interface, I'd say windows doesn't have any of the things that I use regularly in my development.
The interop argument is silly. If you're writing code for interop you can do it just as easily on Windows as any other platform.
No you can't. It's certainly much easier to build and develop on a unixish system than on a Windows system.
My schism tracker project builds automatically for Win32, x86/Linux, and ppc/MacOSX all from the same source tree, all in parallel, and at one point, all from the same machine.
I do not see for a minute how it is even possible to do this on Windows unless I either (a) do an awful lot of work, or (b) use a UNIX environment on Windows and do slightly less than an awful lot of work.
If you're writing stuff for Windows, you have the support of some of the best frameworks available today.
If you mean to say, writing software _on_ windows gives you access to some of the best frameworks available, I have to tell you you're wrong. Most Windows frameworks have very poor accessibility outside of C++, or possibly VB.
If you mean to say writing _targetting_ windows gives you access to some of the best frameworks available, I still have to say you're wrong. The win32 frameworks don't mesh well with any other systems' development model.
Sadly, that seems to be intentional...
How about the fact most people develop for Windows.
Is it a fact?
I wouldn't say what most of those people are doing is "development".
Seriously, Free software means that _this_ is what the people want. They want it so bad, they're making it themselves.
Very few people actually use windows- you ask them what kind of computer they have, and you'll hear "Dell" or "Packard Bell" or "Gateway" - maybe even an "IBM". These people have no idea what they're using or if anything might do what they want better.
Leaving out the fact that this is Free software is trollish- if you don't qualify any comparison with "This is what the people who actually have to use it want to use", then you're just feeding this FUD machine that zero-charge software equals lower-quality- because OF COURSE there's something available for Windows that isn't available for my Free operating system.
Doesn't mean I miss it in the slightest.
And by the way, I have no problems using tax preparation software on Linux, or converting things to and from PDF. I also have no problems watching DVDs legally- as my DVD player and software predate the DCMA.
I have no interest in Visio, Framemaker or Photoshop, or rather any other software that doesn't want me to use it. I may be interested in performing some of the tasks that are possible with these programs- but I've already got adequate Free software, that works and does things the way _I_ want to.
That's easy: Chrono Trigger is the only quest-oriented RPG that has ever sucked more than 150 hours of my life away.
Unless, of course, you count nethack...
On my FreeBSD I compile almost everything from ports. That way you have maximum control about the options and CFLAGS with wich your app is compiled.
/usr/ports tree makes it very easy to get to those things- so what if they use make to do it? It's _exactly_ the same thing as rpm/rpmbuild.
/usr/ports and Gentoo portage do, they're just an awful lot more polished, faster, and all around better.
Whoopy. You've managed to take the worst aspects of FreeBSD (that fewer people use it) and combine it with the fact nobody is QAing your CFLAGS but you.
Thanks for putting untested configurations on the Internet!
On Linux I think that Gentoo's portage comes closest.
Portage is much more stupid than FreeBSD's ports. With FreeBSD's ports- just about everything is QA's and available in binary form elsewhere. the
Don't think for a moment "compiling all your programs" - or "custom tailoring CFLAGS" isn't costing you something very significant.
yum/rpm/rpmbuild or apt/dpkg/debuild are perfectly fine for tuning compile-time operations without busting the QA group. They do _exactly_ what
The big benefits of precompiling are that you don't need to support 1500 different sets of libraries in your development environments, and that the package will generally work right with minimum fuss.
No. The benefits of sharing a binary is greater than that. You get to take advantage of all the QA the packager has done, and all the QA everyone else using that package has done.
Libraries aren't even related.
The big benefits of source-based distros are the ability to tailor packages to each install (ie the ability to compile certain features in or out), to choose optimizations on each package (do you want -Os, -O2, -03, or are you really daring -ffast-math?).
No. There are no benefits to source-based distros. Or if there are, it's not because they're "source-based".
There are however, numerous drawbacks: They're slower, they have a QA-size of one, and they waste time, just to name a few.
For what it's worth: I have no problem "tailoring" binary packages for other distributions, and its helpful that other people have tailored them the same way- I get the ability to turn on or off certain compile-time flags, while still taking advantage of a large QA pool.
In my field, ten percent is everything. If I could increase performance by ten percent, I'd get a 100% bonus for the year. My servers need to handle so much data and are always backlogged (and adding more on is exensive!) Don't trivialize ten percent.
I hope that the point is that you cannot increase performance of your servers by 10% by recompiling your software, just decrease YOUR performance by 200% or more by attempting to do so.
Recompiling someone elses software is usually foolish. You lose support, your QA department becomes YOU (instead of all the other people using a distribution), and for what? Have you measured it? Is the increase signficant? Why aren't those shiny new CFLAGS in -O2 by default? What doesn't your distribution do it for you?
Don't trivialize 200%. It's an awful lot of upfront work, and you will never see a return on it.
Compare, say, setting up apache on a typical Linux distribution with configuring IIS on Windows. The difference is night and day.
Completely agreed.
Setting up 2000 web sites and virtual directories across 20 machines requires no additional programming on Linux, but either requires a significant amount of programming or a significant amount of effort to do the same on Windows.
This is how I define ease of use- by how easy it is to use, not by how easy it makes already easy things.
it's that kind of myopic outlook ("it works for me, you must be too stupid") that makes it so difficult for Linux to gain acceptance.
Well, I would imagine that's because they do it alphabetically. 'Bush' is pretty high, alphabetically.
Hah, I only wish that were true.
In actuality the incumbant is listed first, failing that the incumbants party. Except in some states where it's the governer's party, or failing that, whoever the governer^H^H^H^H^H^H^H^H^Helectoral collage representative (chosen by the governer) damn well chooses
Bull. All of the work should go over smoothly. I ported several mid sized applications over, and they went just fine. you'll get some warning as you'll likely be using some depreciated classes, but you can continue to use them just fine.
.NET 1.1
.NET 2.0 toolchain, but how they can "keep up" with the changes that were introduced with .NET 2.0.
We're using different definitions. Mid-sized projects take a few months. Large projects are the ones than span years.
The point behind this is that you cannot be using deprecated classes, because if you were, you'd still be targetting
Or to put this another way- the author isn't asking how they can compile their code with the
That 10 year old code may still be working, but I'll be I can add new features alot easier in my C# code than you could in plain C.
I didn't say working, I said it's in production and development. That means it's still maintained, improved, and etc, to keep up with the growing demands from our customers.
Come see me in 8 more years, and we'll be able to compare some 10 year old C with 10 year old C#.
Funny how whenever these black box voting machines "just don't work", they error in favor of republicans.
Or at least it would be if RNC contributors weren't the same people who lobbied for the machines.
Or if several of the RNC offices hadn't told registered Republicans to cast absentee ballots because of "machine malfunction"
Or if the Republican positions on the ballot weren't at the top (enum 0)
Or if it weren't a combination of all of these events that just plain look suspicious.
This was Republican districts pushing for these machines in Democrat (read Black) neighborhoods and then urging their own to not use them.
When it turns out the Republicans were right and the machines aren't to be trusted, there's some legitimate suspicion as to exactly why these machines would all vote Republican.
Yeah, every app should be done in C. Why bothering with C++, C#, Java, Python, Perl, PHP, ML, Haskell, Erlang, Lisp etc? what can be done in those languages can easily be done in C anyway...
.NET at all.
.NET or C++ won't become durable- maybe in five or ten years we can make that decision. Surely code will have to be written in the meantime, and that will find faults in its overall design.
Mostly right. Of the languages you listed, there are some gems:
* perl4 code stills runs in perl5 interpreters. Perl6 promises to run perl5 and perl4 code.
* Lisp too has remained unchanged [incompatibly] for decades.
* Erlang was deliberately designed for language-feature durability
Of course, C++, C#, Java, Python, and PHP have all been moving targets (incompatibly I might add, although Java and Python certainly show signs of getting better). ML has long since been fragmented needlessly, and Haskell is too new for me to comment.
I might add that Objective-C, FORTRAN and COBOL are excellent, durable languages as well. The Objective-C framework has demonstrated that it's extremely durable as well.
But don't confuse my point: Durability is [certainly] not the most important thing in a language or a framework, but it IS important, and basing so much of your company on something that has demonstrated that durability is not important at all is dangerous.
Bottom line: If the poster actually wants durability, they shouldn't be looking at
That's not to say
Not as familiar with C, but as for C++, they take great efforts to be careful about language and library changes breaking compatibility,
Really? This program used to compile in G++:
#include <iostream>
int main(int argc, char *argv[]) { cout << "Hello World" << endl; }
And yet, now it doesn't. Why? Namespaces.
You can take 10 year old code, run it through Visual C++, and it runs on Windows XP.
Actually, this is something to attribute to Microsoft. By breaking the C++ standard in so many places for so long, they've really made their own version of C++ (which they actually tried to submit to ECMA recently as "C++/CIL" if I recall correctly)
It's not C++ that's stable- far from it, C++0x breaks things again. Subtle things, but important things. Microsoft has at least done well at making MSC++ stable.
Customers don't want to muck with migrations every 1 or 2 years, they want some decent ROI.
Agreed.
So this question is more analogous to "I'm moving from Gtk 1.2 to Gtk 2.0. What's likely to break?".
It's not similar to that at all.
Try doing that without any code changes. Your fancy, schmancy C language doesn't help you at all.
That's not the point. He's been writing this code for two years, and maybe they're just getting to the point where they can do something with it and BAMMO they need to start thinking about where they're going next.
If you're looking for a good analogy it's something like this:
Vendor gives you fancy shiny new SQL interface, so you begin porting your entire enterprise to it (after adequate testing of course). It takes two years and you start seeing some benefits. Vendor decides after two years that they've made some things better but in order to get ANY of it, you need to redo the last two years AGAIN.
The point is what's to stop this cycle?
(A) the vendor gets it right and stops.
(B) the customer gets it right and stops.
I work in embedded systems. I don't care how "standard" C is--it's only the source code that's standard. When we move to a new processor or the compiler upgrades, we spend weeks chasing subtle bugs out of the code.
.NET 3.0
You do of course realize that those bugs were already there.
Never mind complex stuff like trying to port our stuff to a new RTOS or trying to integrate thousands+ of lines of purchased source code into our product.
I think that's a little different.
You at least know you're porting to a new kernel with slightly different semantics, and you'll also know when you're trying to purchase infrastructure.
The problem is upgrading to something to get some futures benefit- like converting your application to your own private RTOS- an emulation layer that runs between your POSIX-like application and whatever else you want to run on. It doesn't have any immediate benefit to you (after all, most RTOS are either fairly similar, or not really a good target to port to), but it just might.
Here's a group that wants upgrades. They don't know why- it's clearly "for futures stuff", but it's going to break things, and you know, just by the time they get done, they might have to start back up all over again for
As I programmer myself, I realize you're talking about code that's pretty self-contained and algorithmic in nature.
.NET is an immature moving target. A company or an individual that puts so much of themselves into such a beast gets what they deserve when Microsoft says "nononono, we didn't mean that, here's what we REALLY meant. just in time for people to start deploying" and deprecates all your hard work.
.NET or C++ or anything even remotely similar to that. I'm saying that if you have to build out a bunch of technologies that are supposed to last, and "ah" suprise- what's to stop Microsoft from doing this again in two years?
No, I'm not.
Other coding projects, though, need to interface with hardware and other commercial software (like databases) all of which evolve over time... and if you want to take advantage of any new advancements they might provide then your code will have to evolve as well. Sometimes you don't even have a choice (a database company might drop support entirely for an old package) so updating code is part of the job.
I have no difficulty interfacing with hardware or commercial software in C. I have no problem _writing database servers_ in C.
And not to put to fine a point on it, but if your database company dropped support for something your business depended on, you made a horrible mistake in picking that database company.
Yes, upgrading is wrong. If your vendor makes you upgrade, it's because THEY made a mistake by shipping buggy code, or YOU made a mistake by picking them. Whether the upgrade is better or worse than the previous version is for ME, the user, or the developer to decide, and not my vendor.
In any event, you missed my point: C# and
I am not saying that there is never a place for C# or
Why not just avoid the whole mess?
I hate to say it, but you get what you deserve!
I have C code both in production and development that's over 10 years old at this point, and at no point do we have to find a "upgrade strategy" as the foundations set up by K&R were good 30 years ago, and they're still good now.
Meanwhile, you're looking at how to deprecate a big chunk of your company's development value after only two years- and although you haven't said it, I wonder if you've even gotten your value back from all that work?
I'd say to find out how you can make sure you won't do this again in another two years. Start migrating to something else- anything else.
Regarding the extra argument, it should not be required for a good allocator implementation. Look up Alexandrescu's online articles on small object allocators, although he does not address the relocation issue.
The key here is not a good [general purpose] allocator, or a small object allocator, but a very specialized allocator implementation- one that handles very large cache "objects" made up of many smaller objects.
Managed languages solve this by relocating pointers- or by using indirect pointers (where the target can be relocated safely). Modern operating systems that support paging often give applications the ability to manipulate pages, which means that pages can simply be "discarded" out of order as the underlying hardware is providing the indirect pointer.
The problem with paging is that languages aren't designed for paging, and malloc()/new interfaces cannot get enough information for some tasks.
Pool-allocators DO work well with paging, but they require information that malloc()/new don't provide- hence the "extra" argument.
You would use a class-specific operator new, no? That way you would not need an additional argument to specify the pool.
o ol=0), but that's not "new" now is it?
That would work if you had a class like BigCachedObject that all of your big cached objects could derive from (each being their own pool) but nobody does this in practice. Instead you've got a very small HTMLView object that contains an HTMLDomNode tree that's a bunch of pretty small objects linked together, a HTMLRenderedBlock tree which is a bunch of pretty small objects linked together and so on.
If you had a class specific new that used mmap() for HTMLDomNode or HTMLRenderedBlock, then you'd be making a big mistake as each of those objects are below the system page size and your performance would suffer greatly. On the other hand, a class specific new on HTMLView wins nothing either.
Worse still is if you create a bunch of temporary HTMLView objects within scope that you free before leaving the current scope (or parent), so the heap (or even the stack!) is much more appropriate.
Instead you'd need a way to specify a class specific new "when assigning the allocated object to a member of an instance of class X"- something C++ simply cannot do (as new has no idea what it's being assigned to).
In this situation, I suggest people use a class static method like HTMLRenderedBlock::newRenderedBlock(PoolManager*p
I wouldn't know about C, but this statement is utterly false as applied to C++. Replacing the default new and delete routines is perhaps not for the inexperienced C++ programmer, but to say that there's an complete lack of compiler support is simply wrong. It is true that out-of-the-box C++ does not have a compacting garbage collecter, but one can certainly be written (and used, of course) with any conformant compiler.
What you'd need to be able to do is move an object in memory and yet make all of the pointers that referenced the object in the original place still work. C++'s object system pretty much makes this as close to impossible as can be.
You need assistance from something greater than your language, and it just so happens with many C libraries, this can be done very easily- simply use mmap() for allocating your chunks instead of malloc() for "large objects". You wouldn't want to do it everywhere (i.e. you wouldn't want to replace new/delete with it) because performance would suffer greatly.
In order for C++ to do it with anything resembling "reasonable" performance, you'd need to derive your new/delete from a pooled allocator. This'd mean an additional argument to new/delete to specify the pool and would not be transparent or compatible, or really even very much like C++ programming at all.
Interestingly enough, Objective-C does use pools, and when using an autopromoting realloc, all this page-level compacting already happens automatically.
You can decommit the page, but keep it reserved. This frees RAM, decreasing the process's memory usage, but still takes up some of its address space. You MUST coalesce free heap blocks in this case, because all data in those pages is lost. This also requires extra housekeeping.
mmap() can do this, but on many systems [s]brk() cannot. brk() is also alot faster than mmap().
This is really moot on most systems; don't do a lot of little allocations that you're going to keep around for a while and DO use pooled allocators that can use mmap(). It requires planning, but it really does pay off for applications that need an awful lot of memory in stages.
This is (by the way), why many C compilers are implemented in "stages", so that they don't have to worry about crap like this. Allocate as needed, and the next stage exec() will automatically compact and garbage collect any pages used in the previous stage that aren't needed here (that weren't passed to the next process using mmap or pipes).
Other than a full license to Graffiti
:)
Sorry, but I was much more apt with Graffiti than with Graffiti 2 or any other "handwriting recognition" system.
Why? Because two strokes is slower than one. When writing longhand I allow for a certain amount of illegibility that I can fix up later- but with multi-stroke "handwriting recognition" I have to do each glyph separately. With Graffiti (1) writing out meant lifting the stylus briefly between letters. Less lifting, faster writing.
So much so that I copied the Graffiti library from my Palm V to my newer Palm. Works great.
But wait -- what about the phone? Forget it. While some people do use the phone to replace the palm, most never do much but store phone numbers. Further, people are used to a phone being replaced every two years - for free. That is a market that pays for itself in the marketing of minutes. Not a good place to play.
Yeah, that's because things like the TREO are good at everything except being a phone.
If someone really could figure out how to marry a phone to a PDA I'd be the first in line to get one, but nobody has figured out how to do that yet.
I suspect when bluetooth IP becomes more popular, the "phone" will simply be the little transmitter knob in the pocket; the PDA will be the dialing and web browsing interface, and the earpiece will be, well, the earpiece
It should be noted that no application is secure enough
Except qmail.
Meanwhile the rest of the world thinks that they have to choose between functionality and security and manage to get neither particularly well.
So was it wrong for microsoft to extend java?
Not only is it wrong for Microsoft to extend Java, it's wrong for SUN to extend Java (incompatibly). The fact that some JRE1.1 applications cannot run on JRE1.5 is a bug, and it's why some people don't develop on Java- because it simply isn't a stable platform.
This isn't relevant however.
i think the inventor should set the standards.
Of course you do. Enjoy your Betamax and Edison record collection.
Meanwhile, the rest of reality requires that once people start using GetDiskFreeSpace() that it should always yield useful results, even when you really want people to start using GetDiskFreeSpaceEx() unless you want people with disks that have 30GB free to get "out of disk space errors" when they try to install a 300K application.
See, standards are about usage. Once it's out there; once the API is published for use, the inventor gives up their "right" to change it.