What could more intuitive than a Makefile containing:
target1: dependency1 dependency2 action1 action2
target2: etc
Yep, that's intuitive. It is also extremely rare to see such a simple makefile in a real-life project. Your example does not cater for:
Debug versus release builds.
Mixed environments. Very common when doing embedded stuff.
Multi-platform builds with same source code.
I don't think "scons" is better than "make"; it comes with all the inelegance and messy syntax you'd expect of a script language.
I agree with you here. I've never got my head around scons either.
IMO a good build tool must address the following problem areas in a such a way that each can be addressed more or less separately:
What? Which files go into the build and which files should come out of it? (BTW, that is what your example does)
Where?. The location of source and target files should be configurable. Essential if you do debug and release builds with incompatible comiler options.
As a simple example, take 'if (!ptr)' instead of 'if (ptr==NULL)'
A better way is:
if (0==ptr)
Not all C/C++ compilers have Lint-like features, especially not those used for embedded software. Putting the constant first will transform those nasty unintended assignemnents into syntax errors.
You want a wearable computer?
on
Whereables?
·
· Score: 1
But if you want wearable computing in 2005, it seems you must build your own system. Why, after all this time and attention, are wearables still not commercially available?
I'd say you've raised the potential market by about 10%.
As for myself, I get along very nicely with my PDA and my GSM phone.
Has anyone seen an application that has a UI that made you sit up and stare in amazement at the simplicity and effectiveness of it?
No, and neither will you. The sign of a real good user interface is that you don't notice it, you just use it.
The problem is that it takes a lot of very hard work to get that far and most application developers (Open source as well as commercial) don't bother and/or lack the skills to do it.
But the most important book is Software Project Survival Guide by the same author. This is exactly what you need. Get it and read from cover to cover. Repeat that once a year until the people manage can finish your quotes from it.
Hah! That's exactly what I told a friend of mine back in 1991. She had started her own business and needed a computer. She was also computer phobic. So I told her to get a Mac because I knew nothing about them except that they were supposed to be easy to use - and I knew from experience that the then current version of Windows wasn't.
She bought a Mac and all I ever heard about it was that she was very happy with it. Problem solved.
There is a very funny Danish website (Note, it's in Danish) on answering telemarketers. I'll translate one of them:
Telemarketer (T): I'd like to speak with the person who is responsible for buying telephone equipment.
Secretary (S): We don't use telephony in our company.
T: Well, how do make phonecalls?
S: We never make phonecalls - we're just a couple of girls who sit in the office all day.
T: Okay. How do other people call you?
S: That never happens.
T: I'm sorry to have disturbed you. Goodbye.
Basically, the tactic is to tell the telemarketer "We don't use that around here" - no matter what they are trying to push on you. If they try to sell you, say, toiletpaper, you say "We don't use that around here" - and wait for their answer.
TimeTTracker from RF Consulting" to keep track on how much time I use on what and whom. I work as freelancer and this program alone has paid not only for itself but also for the Pocket PC and all the gadgets associated with it.
Wisbar Advance 1.3.2.2 from Lake Ridge Software. This is the older freeware version that does not work with Windows Mobile 2003 SE. The version that does is payware.
nPOPw freeware email program that can delete mails from the POP3-server, something that the built-in version cannot do. I use it for checking email when I'm on the road.
No, it hasn't. Some of the C++ standard libraries (especially STL) have hidden allocations all over. So don't use those libraries. Problem solved.
The real question is- what does C++ give you that C doesn't?
In my experience:
Much cleaner code design leading to code that is much easier to maintain. Remember, the objective is not to make code that works. It's to make code that keeps working.
When inheritance is done right it means less code to write, meaning faster time-to-market.
And yes, I write embedded real-time software too - in C++.
is the fact that C++ implies the existence of an intrinsic memory management behaviour (new/delete)
C++ implies no such thing and if you'd ever used it seriously, you' know that.
I have written loads of embedded realtime C++ code including code for a heart defibrillator where a half second delay may mean the difference between reviving a patient and killing him. And yes, if I were that patient, I'd gladly trust my life with that defibrillator.
Nothing will come out of it, for the simple reason that C++ does not belong in any kernel. In a kernel, all the code needs to be transparent, and you definitely don't want to hide implementation and the usual abstractions.
Having used C++ for embedded real-time programming for over five years, I can say that this is absolutely untrue. You have to know what you are doing (as in "don't use libraries that do something behind your back") but programming in C instead of C++ does not give any advantages at all. I for one am not willing to downgrade to C if I can avoid it.
Also, if abstractions and implementation hiding are detrimental to program design, we should all use assembly language. After all, optimizing compilers can't be trusted.
It does - and as long as there is no clear decision on what that infrastructure should be, the US will have lousy coverage.
Sparsely populated countries like Finland and Sweden have exellent coverage because they - like the rest of Europe - have standardized on GSM. This hase several consequences that are all to the benefit of the users:
There is a huge market and several manufacturers of GSM base-station equipment.
There is nowhere near as much service provider lock-in because although there are several networks, they are all GSM so once you have bought a mobile phone (and had it unlocked) you can use it with any network.
Being able to use your mobile phone anywhere in Europe means that they are much more useful when travelling.
And finally, not having to pay when you receive text messages (SMS) have made texting unbelievably popular, especially among young people. In fact, SMSes are the major cash cow for most service providers in Europe.
All this is possible because the infrastructure is standardized by the governments.
In the US however, it was decided that the market should determine which standard should be the winning one. Unfortunately no clear winner has emerged so the US service providers simply don't have the same kind of uniform market. This means that there is less money to be made and hence less money for extending coverage.
Sometimes government mandated standards are a Good Thing (TM).
"No funny key combinations."
why not? as long as it's in addition to the Gui.
As long as they are an addition, it's OK. They become a problem if they are the only way to control a program.
That gives people a choice.
frankly, I suspect Apples study is invalid. Every data user person I have ever written code for is a lot faster using keys then the mouse.
Key combinations may be faster once you have learned them. However, until that point is reached, they are much slower.
When a computer is used by multiple people, there can be scenerio where you want the user to be sure they want to do an 'undoable' action. Like putting someting in the trash.
What do you mean here?
"The user should never have to tell the computer something it already knows. "
This may very mean the computer has to make an assumption.
If the computer knows something, it's a damn bad programmer that makes the computer assume something else.
Also a database is more difficult for a user to understand then a flat file.
The purpose of any program using a database is to isolate the user from it. If the user has to understand databases to use a program, the UI is very badly designed. Unless it's a database program of course:-)
"Anything that can get itself into a bad state must be able to get itself out of that state."
Nice, but unrealistic. Sometimes the 'bad state' is the rollback mechinism.
Rollback failure is usually much more rare than program failure, because rollback is only used when the program fails and then it mostly works. Always attack the bigger problem first.
Modal dialogs should be used sparingly, and only when the user can have no other reason to look for something in the app. Nothing worse then having a damn modal dialog asking you a question, and the answer is in the app.
Exactly: "The user should never have to tell the computer something it already knows. "
I once considered starting a project that designed application interfaces for tasks that were needed in hopes that some coder would come along behind and actually write them.
Right now I'm part of a project where we work just like that. The company I work for have hired a UI consultant that really knows his stuff. He has created a one of the best specialized GUIs I have ever seen. It is then up to us progrmmaer to create the code behind the pretty pictures.
This works extremely well. If/when I get on another project that involves a GUI, this is the method that I will recommend ad nauseam.
Slashdot Mirror
This works only until someone decides to "optimize" the code:
Yep, that's intuitive. It is also extremely rare to see such a simple makefile in a real-life project. Your example does not cater for:
- Debug versus release builds.
- Mixed environments. Very common when doing embedded stuff.
- Multi-platform builds with same source code.
I don't think "scons" is better than "make"; it comes with all the inelegance and messy syntax you'd expect of a script language.I agree with you here. I've never got my head around scons either.
IMO a good build tool must address the following problem areas in a such a way that each can be addressed more or less separately:
A better way is:
Not all C/C++ compilers have Lint-like features, especially not those used for embedded software. Putting the constant first will transform those nasty unintended assignemnents into syntax errors.I'd say you've raised the potential market by about 10%.
As for myself, I get along very nicely with my PDA and my GSM phone.
No, and neither will you. The sign of a real good user interface is that you don't notice it, you just use it.
The problem is that it takes a lot of very hard work to get that far and most application developers (Open source as well as commercial) don't bother and/or lack the skills to do it.
- The Mythical Man-Month
By Frederick P. Brooks.- Code Complete
- Rapid Development
By Steve McConnell.But the most important book is Software Project Survival Guide by the same author. This is exactly what you need. Get it and read from cover to cover. Repeat that once a year until the people manage can finish your quotes from it.
Hah! That's exactly what I told a friend of mine back in 1991. She had started her own business and needed a computer. She was also computer phobic. So I told her to get a Mac because I knew nothing about them except that they were supposed to be easy to use - and I knew from experience that the then current version of Windows wasn't.
She bought a Mac and all I ever heard about it was that she was very happy with it. Problem solved.
- For friends and family the rate is a home-cooked meal per incident.
- Everbody else pay my standard hourly rate which is around USD 120.
This has worked out very well over the years.I've just discovered that the website I mentioned does have a version in English.
Telemarketer (T): I'd like to speak with the person who is responsible for buying telephone equipment.
Secretary (S): We don't use telephony in our company.
T: Well, how do make phonecalls?
S: We never make phonecalls - we're just a couple of girls who sit in the office all day.
T: Okay. How do other people call you?
S: That never happens.
T: I'm sorry to have disturbed you. Goodbye.
Basically, the tactic is to tell the telemarketer "We don't use that around here" - no matter what they are trying to push on you. If they try to sell you, say, toiletpaper, you say "We don't use that around here" - and wait for their answer.
And when you've read that, get Software Project Survival Guide by the same author and read it once - a year.
No, it hasn't. Some of the C++ standard libraries (especially STL) have hidden allocations all over. So don't use those libraries. Problem solved.
The real question is- what does C++ give you that C doesn't?
In my experience:
- Much cleaner code design leading to code that is much easier to maintain. Remember, the objective is not to make code that works. It's to make code that keeps working.
- When inheritance is done right it means less code to write, meaning faster time-to-market.
And yes, I write embedded real-time software too - in C++.Except that in C++, you'd write:
and not have any problems at all.
C++ implies no such thing and if you'd ever used it seriously, you' know that.
I have written loads of embedded realtime C++ code including code for a heart defibrillator where a half second delay may mean the difference between reviving a patient and killing him. And yes, if I were that patient, I'd gladly trust my life with that defibrillator.
Having used C++ for embedded real-time programming for over five years, I can say that this is absolutely untrue. You have to know what you are doing (as in "don't use libraries that do something behind your back") but programming in C instead of C++ does not give any advantages at all. I for one am not willing to downgrade to C if I can avoid it.
Also, if abstractions and implementation hiding are detrimental to program design, we should all use assembly language. After all, optimizing compilers can't be trusted.
Amen to that. A local store has begun carrying a few of Brooklyn Brewery's beers. They are very, very good.
BTW I live in Denmark :-)
FYI: Quite a few of the CVS developers have gone on to develop SVN.
It does - and as long as there is no clear decision on what that infrastructure should be, the US will have lousy coverage.
Sparsely populated countries like Finland and Sweden have exellent coverage because they - like the rest of Europe - have standardized on GSM. This hase several consequences that are all to the benefit of the users:
- There is a huge market and several manufacturers of GSM base-station equipment.
- There is nowhere near as much service provider lock-in because although there are several networks, they are all GSM so once you have bought a mobile phone (and had it unlocked) you can use it with any network.
- Being able to use your mobile phone anywhere in Europe means that they are much more useful when travelling.
- And finally, not having to pay when you receive text messages (SMS) have made texting unbelievably popular, especially among young people. In fact, SMSes are the major cash cow for most service providers in Europe.
All this is possible because the infrastructure is standardized by the governments.In the US however, it was decided that the market should determine which standard should be the winning one. Unfortunately no clear winner has emerged so the US service providers simply don't have the same kind of uniform market. This means that there is less money to be made and hence less money for extending coverage.
Sometimes government mandated standards are a Good Thing (TM).
And it is even better when it is aged for a couple of years.
Another excellent beer is "La Fin Du Monde" (The End of the World) from UNIBROUE in Quebec. Their brewmaster used to work for Chimay...
I a word: slavery.
Making it possible to see all the pictures without paying would do the trick.
As long as they are an addition, it's OK. They become a problem if they are the only way to control a program.
Key combinations may be faster once you have learned them. However, until that point is reached, they are much slower.
What do you mean here?
If the computer knows something, it's a damn bad programmer that makes the computer assume something else.
The purpose of any program using a database is to isolate the user from it. If the user has to understand databases to use a program, the UI is very badly designed. Unless it's a database program of course :-)
Rollback failure is usually much more rare than program failure, because rollback is only used when the program fails and then it mostly works. Always attack the bigger problem first.
Exactly: "The user should never have to tell the computer something it already knows. "
Right now I'm part of a project where we work just like that. The company I work for have hired a UI consultant that really knows his stuff. He has created a one of the best specialized GUIs I have ever seen. It is then up to us progrmmaer to create the code behind the pretty pictures.
This works extremely well. If/when I get on another project that involves a GUI, this is the method that I will recommend ad nauseam.
Emaca actually provides a GUI: Geek User Interface