I agree with everything you say. Good upfront design saves a huge amount down the track. I guess I am trying to balance that against the fact that problems that are not anticipated in the disgn will arise while coding.
at best, incremental improvements over previous versions, although they are touted as 'revolutionary', eg Win 2k vs Win X
Or not improvements at all. I recently installed a new machine with XP and actually watched the installer at work (which I cannot normally be bother to do). During the install it was touting a fantastic new feature: autoplay of devices (USB, CD etc). This is a dead lightbulb feature. Why would I want my thumb drive (which could contain anything), to "autplay"? How do you autoplay a word document?
Anyway, it a feature that should never have seen the light of day (yes I know how to switch it off). What was rather funny about it is that it was actually advertised as a feature.
This is interesting. One question, why did Microsoft fragment the kernel of the workstation and server OSes? It never made sense to me. Having created a stable core with 2000 and finally killed off the DOS based OSes (I'd include Me in with that, even though it wasn't DOS based), why were they thinking of fragmenting again? Surely it makes it harder to build and maintain? Harder to keep APIs and interfaces the same? Or was it originally Microsoft's intention to build their server OSes off the Vista kernel?
Just as a matter of interest, are you a programmer? You say you aren't a C programmer, do you program in other languages?
Anyway, what the parent says squares with my experience as a programmer (in C and other languages). The problem with what you are saying is that designing everything up front doesn't always work, because some problems only become apparent once the application is built. For example, you might not be aware of where the bottlenecks will be when you are designing the application. Having built it, it may become immediately apparent. Sure with more information and more experience, design improves, but even then, you can run into unforseen problems.
Advocating that all design happens up front is returning to the waterfall model of software development. The only problem is that it doesn't work. You might as well demand that all the specifications are accurate up front.
So, while I might not advocate rewriting every program, for smaller applications it can be a good idea. It is also quicker to write the second time because you are more familiar with the problem. In general I'd advocate rewriting it bit by bit rather than tearing it to the ground and rebuilding it each time.
I've heard this again and again. That is that labels can at a minimum be a replacement for folders. I mean, arguably, a folder is just an attribute. The problem comes with hierachical folder structures. And yes this is still an issue for email. I am on quite a few mailing lists and I like to group them in folders 2 deep. Labels do not replace folders. This is equally true for all the meta-data fanboys who suggest that with Spotlight|WinFS|whatever, folders will no longer be necessary.
Or to pick another influential work that relates to Iraq:
"For, although one may be very strong in armed forces, yet in entering a province one has always need of the goodwill of the natives" Machiavelli, "The Prince"
This is being played out in Iraq, as it was in Vietnam. On that note, as the old adage says: "Those who do not understand history are condemned to repeat it"
If your webapp is a few years old, then it's probably about time that it was rewritten anyway, just to incorporate CSS/XHTML and other stuff which didn't exist / wasn't mature enough when the project started.
These can be selectively and incremenetally rolled in.
Also, if it's a webapp, it's probably a bunch of hacks thrown together anyway - why not take version 1 as a "write one to throw away" prototype, and rewrite the entire thing, using the lessons learned?
Some sections are hacks, most aren't.
If you're doing that, there's no pain (and potential gain, if you choose the right language) in switching languages at the same time.
We aren't on the same planet are we. No PAIN? What the hell do you think you are saying? There is a huge amount of pain. You go to your customers and say: "Uhh we are going to change the underlying technology of the website. No it won't offer any new features. No it won't really be any different. It also means that there will be no new features for the next 9 months, and we aren't even sure of that figure. It could be more".
You are telling me to be realistic?
Allow me to quote from someone else who expresses it well: So you've got the Windows API, you've got VB, and now you've got.NET, in several language flavors, and don't get too attached to any of that, because we're making Avalon, you see, which will only run on the newest Microsoft operating system, which nobody will have for a loooong time. And personally I still haven't had time to learn.NET very deeply, and we haven't ported Fog Creek's two applications from classic ASP and Visual Basic 6.0 to.NET because there's no return on investment for us. None. It's just Fire and Motion as far as I'm concerned: Microsoft would love for me to stop adding new features to our bug tracking software and content management software and instead waste a few months porting it to another programming environment, something which will not benefit a single customer and therefore will not gain us one additional sale, and therefore which is a complete waste of several months, which is great for Microsoft, because they have content management software and bug tracking software, too, so they'd like nothing better than for me to waste time spinning cycles catching up with the flavor du jour, and then waste another year or two doing an Avalon version, too, while they add features to their own competitive software. Riiiight. source
I am interested in upgrades. I am almost never interested in upgrades that dump what you have a start again. I am interested in incremental upgrades.
There is a reason I am migrating the site to.Net. There is also a reason why I am doing it in stages.
My training is as an engineer. One thing I learnt from my degree was that anyone can walk into a plan and tell them to raze it to the ground and build a more efficient, better plant. This is not a useful solution. However if you can tell them how that can adapt what they have to produce a more efficient, better solution, then you have something of interest.
The lack of.Net applications is largely (IMO) Microsoft's fault..Net was supposed to be the replacement of the Win32 API. However Microsoft has not made any reasonable attempt to ensure it gets rolled out on desktops. This could certainly be done using Windows update.
The effect of this is that you cannot depend on any client having the.Net framework installed. This means you must either redistribute it, or direct people to download it. Neither option is particularly good.
The reason I like it that I write C# for a living. I maintain a web application. Originally this was written in classic asp. It is currently a hybrid with some classic asp and some.Net (about 50-50), running SQL Server as a backend.
With mono there is the possibility that I can port this to run under Linux. Postgress being the replacement for SQL Server. Now I haven't looked at this in depth yet, but in a year or so (by which time the migration to.Net will be complete), this is a viable option.
Mono offers a practical upgrade path. The only other options are a clean rewrite in another language. The would take a minimum of 9 months, during which time no features would be added to the product.
No. If the browser does not respect the fonts sepcified by the page, then any presentation issues relating to the change in font size are the browser's problem.
That and/or the user who decided to override the changes.
Regarding iterating through vectors: First off, items 2 and 3 are effectively the same. As are items 4 and 5. Caching values is a standard part of any well featured programming language, this is not a new concept. So we are down to 4 distinct methods.
Looking at those 4, I see each of those ways to iterate through a vector and I intuitively understand them. 4-5 and 6 might be a little more difficult to someone who is new to C++, however iterators are increasingly becoming part of other programming languages. std::for_each is also something that intuitively makes sense (syntax and operation), and equally this is common in other languages.
Looking at your list of options to return from a function, 3-5 of the variations relate to pointers (yes I do understand the nuances between the different options). 2 and 3 are also pretty close to identical. I'd agree this is one area (pointers) where things get complications, which leads to variation.
Perl does things its own way, which I have found generally less intuitive.
C++ shows TIMTOWTDI done right. Perl does it wrong. Don't believe me?
Off the top of my head (I don't write a whole lot of perl, so I don't have a whole stack more available immediately):
Can you explain why there are so many different ways to quote a string?
ditto for regexes
Why are you able to modify an instance class (by adding member values) so that it is not the same as declared?
What if your way to do it didn't fit with the vision of whoever chose the one or two ways to do it?
In that case there can be a later revison to the language. Or it would be a case for the person coding to write around the issue.
If you're working on a multi-person project that's a mixture of many different styles and techniques, then the problem is with the development process, not the language.
Every environment is a multi-person project. As someone else has quipped, there are always a minimum of two people working on any project: myself and myself in 6 months time.
Until someone invents a language where there's one true formatting style, one true symbol naming style...
You and I both know that this language does not exist and will never exist.
I realise that there is a conflict. On one hand, when designing the language you cannot envisage every situation in which that language will be used. But on the other hand if you create a multiplicity of means of doing the same thing, it quickly becomes close to unmaintainable. I also consider that there are different languages for a reason, use them in the siuations where they are most appropriate.
You will notice that I said at most *2* ways of doing things. I have no problem with having 2 ways to do things, it is just that perl takes this to extremes. It is also interesting that perl is pretty much the only major language that goes to these extremes. I think that in itself is pretty telling.
There are many other things relating to perl I could whinge about (classes for one), but at the core I take issue with the underlying philosophy.
I've said this before many times, but perl is pecularly well suited to obfuscation. It is a lanugage that is harder to read than any other language that is frequently in use, at least than any other language I am aware of.
This comes back to the core of perl itself. TMTOWTDI. There shouldn't be. At most there should be two ways to do it. If there is more than one way to do it, you get people using each of the different ways, and the amount of variation makes the code harder to read which means harder to debug which means harder to code.
TMTOWTDI is a huge mistake.
I code some perl, but I force myself to use a small subset of the language.
While governments put their welfare ahead your personal welfare however they put the welfare of their citizens ahead of its own existance. This is still mostly true in the west.
The way I can tell the government cares is that it puts our welfare ahead of its own.
That is one way to look at it. Another is to see it as the ultimate act of selfishness. We do not live in a vacuum and our actions have consequences for those around us.
Also bringing this down to the level of the state being annoyed at being deprived of a taxpayer is a rather strange way of looking at things. It assumes that the state runs like a business that is only concerned with making profits, by way of taxes. It assumes that the state does not care for its citizens.
I like choices, that is why I want to buy an OS that gives me choices. This means buying an OS that I "choose" to limit my options at the start. I don't like that. I can understand differentiating the server and workstation lines, but outside that I don't see the point.
Well I've never has problems syncing (mind you I use some custom software to do it), and while I don't use it as a bluetooth modem, I have used it with a bluetooth hands free extensively without any trouble.
The one problem I have had is that it someones switches to using Line 2, seemingly at random. When it does it also adds the link to switch lines into the quick link list (left button).
I used to own a Nokia 3210. After the battery went I replaced it with a Motorola T720, which was a top of the line phone at that time. The T720 was slow, counter-intuitive and buggy. It needed a firmware upgrade within 4 months. Even after that it used to regularly crash (5-10 times/week), including during phone calls. Above all the interface sucked hugely. It was not responsive. You got stupid animations for every single little action, which just make life harder. This is before the issues I had with the software I used to sync the contacts with my palm.
The one thing I will say for the phone is that it looked cool, and the physical form factor was pretty good. I do like the flip phone style: bigger screen, bigger keypad, smaller phone.
That said, the interface was so bad that I decided I didn't want a motorola under any circumstances.
So I bought a nokia 6230, which I am very happy with. I also bought that phone because everyone I spoke to who owned one thought it was a good phone. Also with my previous (good) experience for the nokia phones, I wanted to go with them again for their interface.
Incidentally my brother-in-law bought a brand new top of the line Motorola phone about 6 months ago. He also wants to dump it.
Maybe the V3 was good, but my experience of the current crop of motorola phones is very negative.
The capacity on the ROKR sucks. 100 songs? That's less then 512mb.
Exactly. I own a Nokia 6230. I can plug a 512 Mb card into my phone for $70 (AUS) and have a 512Mb MP3 player. What is more, my phone doesn't need to be a brick to do it.
I can't comment on the hardware side of things, but Motorolla's software is rubbish. Counter-intuitive, slow and annoying. I owned a T720, which I was very happy to drop for a Nokia 6230.
I thought it was just me, but my brother-in-law has the same experience with his new motorolla phone. Having spent the money to buy a top of the line Motorolla phone, he wants to dump it for something that has a usable interface.
Slashdot Mirror
Yes, C++ is my language of choice
Cool mine too.
I agree with everything you say. Good upfront design saves a huge amount down the track. I guess I am trying to balance that against the fact that problems that are not anticipated in the disgn will arise while coding.
at best, incremental improvements over previous versions, although they are touted as 'revolutionary', eg Win 2k vs Win X
Or not improvements at all. I recently installed a new machine with XP and actually watched the installer at work (which I cannot normally be bother to do). During the install it was touting a fantastic new feature: autoplay of devices (USB, CD etc). This is a dead lightbulb feature. Why would I want my thumb drive (which could contain anything), to "autplay"? How do you autoplay a word document?
Anyway, it a feature that should never have seen the light of day (yes I know how to switch it off). What was rather funny about it is that it was actually advertised as a feature.
This is interesting. One question, why did Microsoft fragment the kernel of the workstation and server OSes? It never made sense to me. Having created a stable core with 2000 and finally killed off the DOS based OSes (I'd include Me in with that, even though it wasn't DOS based), why were they thinking of fragmenting again? Surely it makes it harder to build and maintain? Harder to keep APIs and interfaces the same? Or was it originally Microsoft's intention to build their server OSes off the Vista kernel?
Just as a matter of interest, are you a programmer? You say you aren't a C programmer, do you program in other languages?
Anyway, what the parent says squares with my experience as a programmer (in C and other languages). The problem with what you are saying is that designing everything up front doesn't always work, because some problems only become apparent once the application is built. For example, you might not be aware of where the bottlenecks will be when you are designing the application. Having built it, it may become immediately apparent. Sure with more information and more experience, design improves, but even then, you can run into unforseen problems.
Advocating that all design happens up front is returning to the waterfall model of software development. The only problem is that it doesn't work. You might as well demand that all the specifications are accurate up front.
So, while I might not advocate rewriting every program, for smaller applications it can be a good idea. It is also quicker to write the second time because you are more familiar with the problem. In general I'd advocate rewriting it bit by bit rather than tearing it to the ground and rebuilding it each time.
I've heard this again and again. That is that labels can at a minimum be a replacement for folders. I mean, arguably, a folder is just an attribute. The problem comes with hierachical folder structures. And yes this is still an issue for email. I am on quite a few mailing lists and I like to group them in folders 2 deep.
Labels do not replace folders. This is equally true for all the meta-data fanboys who suggest that with Spotlight|WinFS|whatever, folders will no longer be necessary.
Or to pick another influential work that relates to Iraq:
"For, although one may be very strong in armed forces, yet in entering a province one has always need of the goodwill of the natives"
Machiavelli, "The Prince"
This is being played out in Iraq, as it was in Vietnam. On that note, as the old adage says:
"Those who do not understand history are condemned to repeat it"
Nipick: The current thinkpads have a rubberised coating. The spray paint might not hold too well.
Be realistic.
.NET, in several language flavors, and don't get too attached to any of that, because we're making Avalon, you see, which will only run on the newest Microsoft operating system, which nobody will have for a loooong time. And personally I still haven't had time to learn .NET very deeply, and we haven't ported Fog Creek's two applications from classic ASP and Visual Basic 6.0 to .NET because there's no return on investment for us. None. It's just Fire and Motion as far as I'm concerned: Microsoft would love for me to stop adding new features to our bug tracking software and content management software and instead waste a few months porting it to another programming environment, something which will not benefit a single customer and therefore will not gain us one additional sale, and therefore which is a complete waste of several months, which is great for Microsoft, because they have content management software and bug tracking software, too, so they'd like nothing better than for me to waste time spinning cycles catching up with the flavor du jour, and then waste another year or two doing an Avalon version, too, while they add features to their own competitive software. Riiiight.
.Net. There is also a reason why I am doing it in stages.
I am.
If your webapp is a few years old, then it's probably about time that it was rewritten anyway, just to incorporate CSS/XHTML and other stuff which didn't exist / wasn't mature enough when the project started.
These can be selectively and incremenetally rolled in.
Also, if it's a webapp, it's probably a bunch of hacks thrown together anyway - why not take version 1 as a "write one to throw away" prototype, and rewrite the entire thing, using the lessons learned?
Some sections are hacks, most aren't.
If you're doing that, there's no pain (and potential gain, if you choose the right language) in switching languages at the same time.
We aren't on the same planet are we. No PAIN? What the hell do you think you are saying? There is a huge amount of pain. You go to your customers and say: "Uhh we are going to change the underlying technology of the website. No it won't offer any new features. No it won't really be any different. It also means that there will be no new features for the next 9 months, and we aren't even sure of that figure. It could be more".
You are telling me to be realistic?
Allow me to quote from someone else who expresses it well:
So you've got the Windows API, you've got VB, and now you've got
source
I am interested in upgrades. I am almost never interested in upgrades that dump what you have a start again. I am interested in incremental upgrades.
There is a reason I am migrating the site to
My training is as an engineer. One thing I learnt from my degree was that anyone can walk into a plan and tell them to raze it to the ground and build a more efficient, better plant. This is not a useful solution. However if you can tell them how that can adapt what they have to produce a more efficient, better solution, then you have something of interest.
Hmmm, good point. I had always assumed that C# offered overloading based on return type. Now I test it I find it doesn't. Sorry about that.
Two words: Function overloading.
BTW, where's the big wave of .NET applications?
.Net applications is largely (IMO) Microsoft's fault. .Net was supposed to be the replacement of the Win32 API. However Microsoft has not made any reasonable attempt to ensure it gets rolled out on desktops. This could certainly be done using Windows update.
.Net framework installed. This means you must either redistribute it, or direct people to download it. Neither option is particularly good.
The lack of
The effect of this is that you cannot depend on any client having the
I like what Miguel is doing with mono.
.Net (about 50-50), running SQL Server as a backend.
.Net will be complete), this is a viable option.
The reason I like it that I write C# for a living. I maintain a web application. Originally this was written in classic asp. It is currently a hybrid with some classic asp and some
With mono there is the possibility that I can port this to run under Linux. Postgress being the replacement for SQL Server. Now I haven't looked at this in depth yet, but in a year or so (by which time the migration to
Mono offers a practical upgrade path. The only other options are a clean rewrite in another language. The would take a minimum of 9 months, during which time no features would be added to the product.
No. If the browser does not respect the fonts sepcified by the page, then any presentation issues relating to the change in font size are the browser's problem.
That and/or the user who decided to override the changes.
Looking at those 4, I see each of those ways to iterate through a vector and I intuitively understand them. 4-5 and 6 might be a little more difficult to someone who is new to C++, however iterators are increasingly becoming part of other programming languages. std::for_each is also something that intuitively makes sense (syntax and operation), and equally this is common in other languages.
Looking at your list of options to return from a function, 3-5 of the variations relate to pointers (yes I do understand the nuances between the different options). 2 and 3 are also pretty close to identical. I'd agree this is one area (pointers) where things get complications, which leads to variation.
Perl does things its own way, which I have found generally less intuitive.
C++ shows TIMTOWTDI done right. Perl does it wrong. Don't believe me?
Off the top of my head (I don't write a whole lot of perl, so I don't have a whole stack more available immediately):
What if your way to do it didn't fit with the vision of whoever chose the one or two ways to do it?
In that case there can be a later revison to the language. Or it would be a case for the person coding to write around the issue.
If you're working on a multi-person project that's a mixture of many different styles and techniques, then the problem is with the development process, not the language.
Every environment is a multi-person project. As someone else has quipped, there are always a minimum of two people working on any project: myself and myself in 6 months time.
Until someone invents a language where there's one true formatting style, one true symbol naming style...
You and I both know that this language does not exist and will never exist.
I realise that there is a conflict. On one hand, when designing the language you cannot envisage every situation in which that language will be used. But on the other hand if you create a multiplicity of means of doing the same thing, it quickly becomes close to unmaintainable. I also consider that there are different languages for a reason, use them in the siuations where they are most appropriate.
You will notice that I said at most *2* ways of doing things. I have no problem with having 2 ways to do things, it is just that perl takes this to extremes. It is also interesting that perl is pretty much the only major language that goes to these extremes. I think that in itself is pretty telling.
There are many other things relating to perl I could whinge about (classes for one), but at the core I take issue with the underlying philosophy.
No, if not for TIMTOWDI I woudn't have to force myself.
Bill Gates:
So Google is not offering development capabilities yet.
Is he missing something?
I've said this before many times, but perl is pecularly well suited to obfuscation. It is a lanugage that is harder to read than any other language that is frequently in use, at least than any other language I am aware of.
This comes back to the core of perl itself. TMTOWTDI. There shouldn't be. At most there should be two ways to do it. If there is more than one way to do it, you get people using each of the different ways, and the amount of variation makes the code harder to read which means harder to debug which means harder to code.
TMTOWTDI is a huge mistake.
I code some perl, but I force myself to use a small subset of the language.
While governments put their welfare ahead your personal welfare however they put the welfare of their citizens ahead of its own existance. This is still mostly true in the west.
The way I can tell the government cares is that it puts our welfare ahead of its own.
That is one way to look at it. Another is to see it as the ultimate act of selfishness. We do not live in a vacuum and our actions have consequences for those around us.
Also bringing this down to the level of the state being annoyed at being deprived of a taxpayer is a rather strange way of looking at things. It assumes that the state runs like a business that is only concerned with making profits, by way of taxes. It assumes that the state does not care for its citizens.
I like choices, that is why I want to buy an OS that gives me choices. This means buying an OS that I "choose" to limit my options at the start. I don't like that. I can understand differentiating the server and workstation lines, but outside that I don't see the point.
Well I've never has problems syncing (mind you I use some custom software to do it), and while I don't use it as a bluetooth modem, I have used it with a bluetooth hands free extensively without any trouble.
The one problem I have had is that it someones switches to using Line 2, seemingly at random. When it does it also adds the link to switch lines into the quick link list (left button).
Well let me put forward my experiences.
I used to own a Nokia 3210. After the battery went I replaced it with a Motorola T720, which was a top of the line phone at that time. The T720 was slow, counter-intuitive and buggy. It needed a firmware upgrade within 4 months. Even after that it used to regularly crash (5-10 times/week), including during phone calls. Above all the interface sucked hugely. It was not responsive. You got stupid animations for every single little action, which just make life harder. This is before the issues I had with the software I used to sync the contacts with my palm.
The one thing I will say for the phone is that it looked cool, and the physical form factor was pretty good. I do like the flip phone style: bigger screen, bigger keypad, smaller phone.
That said, the interface was so bad that I decided I didn't want a motorola under any circumstances.
So I bought a nokia 6230, which I am very happy with. I also bought that phone because everyone I spoke to who owned one thought it was a good phone. Also with my previous (good) experience for the nokia phones, I wanted to go with them again for their interface.
Incidentally my brother-in-law bought a brand new top of the line Motorola phone about 6 months ago. He also wants to dump it.
Maybe the V3 was good, but my experience of the current crop of motorola phones is very negative.
The capacity on the ROKR sucks. 100 songs? That's less then 512mb.
Exactly. I own a Nokia 6230. I can plug a 512 Mb card into my phone for $70 (AUS) and have a 512Mb MP3 player. What is more, my phone doesn't need to be a brick to do it.
Motorola makes some excellent kit
I can't comment on the hardware side of things, but Motorolla's software is rubbish. Counter-intuitive, slow and annoying. I owned a T720, which I was very happy to drop for a Nokia 6230.
I thought it was just me, but my brother-in-law has the same experience with his new motorolla phone. Having spent the money to buy a top of the line Motorolla phone, he wants to dump it for something that has a usable interface.