There's actually quite a lot to be said for asking certain questions when an app starts rather than at installation time.
The questions you ask at installation time should be the ones that sysadmins can answer, like where do you want me to put the app and which components do you want to install.
The questions you ask when a user starts the app (for the first time) are questions that the user's answer. An easy way to work out which category a particular choice falls in is whether or not the setting is per user or one setting for the entire machine.
The default browser is a per user setting and the choice should be offered when a user starts the app for the first time.
Presumably what Mozilla have done is to set the default browser for the user performing the installation. This seems somewhat perverse.
Of course Mozilla has little penetration in corporations where these issues are more relevant. And it won't ever get any such penetration until there are good tools for packaging Firefox + add-ons in an MSI. Before anyone flames about MSI being Windows only, corporations overwhelmingly use Windows on the desktop. And even for non-corp users I'll bet Firefox gets more use in Windows than the other OSs combined.
Volunteers are more motivated than paid employees You need to find a better employer.
There are many eyeballs to spot code problems There can be, or in the case of Debian OpenSSL for example there may not be. Open Source does not automatically imply many eyeballs.
There are no marketing pressures to deliver substandard work Open source has no marketing pressures? Ubuntu fixed release dates are just one obvious example to counter that.
Developers are geographically dispersed and can't communicate easily Well, lots of commercial development is switching to offshore developers so I don't see this problem being the preserve of open source.
Ultimately, I don't believe in the religious wars over commercial vs open source. My guess is that good software is developed by clever people in environments that allow them to thrive. That be just as easily be commercial or open source. It's probably easier for the clever people if they get paid since that does grease the skids, but being paid or otherwise is not the key point.
It's interesting that the collection of geeks and nerds here talk mostly about the technical side of this problem. Yes there's a horrible security flaw and yes it's been patched, albeit somewhat slowly.
But the parent post seems to me to touch on the real issue and that is the process of software development and packaging. It seems to me that the very nature of the bazaar makes this sort of process failure if not inevitable then very hard to avoid. There are many aspects of security and trust is a key one. Is it really the case that Linux distros are developed in this way? Downstream packagers make changes without getting those changes reviewed by the upstream experts? That is quite astonishing if it is the norm. My trust has just evaporated.
Why do you think that I don't care about my customers? Without them my business would not exist.
It's a good point though that there are more software markets available on Linux and Mac.
As for me, my business is writing finite element (FE) software for offshore engineers, 99% of whom use Windows. Obviously it doesn't take much imagination to decide which platform to support.
As for the APIs, what APIs? We use Delphi, the best kept secret of Windows desktop writing and the VCL does a pretty good job of hiding the low level stuff. And of course it's native code so the numerical FE stuff runs quickly too.
I personally find that food and shelter costs money and as a writer of desktop applications that means I like to target a platform that has some users. And that's where the debate ends for me.
Anyone who writes commercial desktop apps and decides which platform to use for any other reason than that is plain crazy.
I think that's just what I said. Sure the mindset difference is important. But my main point was that WEB/CWEB whatever cannot generate your program. You still have to write it yourself. But you don't seem to be able to read what I actually say in my posts.
Now, writing the documentation first helps you work your specification out and therefore allow you to code a system that actually does what the users want. TDD devotees would argue that TDD does the same. All these arguments about which processes work best are rather pointless. What works for one person may not work for the next person. But what will always work is clever people thinking about what they are doing and trying to do it better. Knuth knows this and says that whilst literate programming makes him tick it may not for others. So be it.
My point is that generating the program from the documentation is somewhat misleading. You still write the code, but it's annotated with the documentation. Or, if you prefer, you write some documentation but annotate it with code. Either way you then run programs that strip either code or doc and are left with the other to feed into the next stage of the tool chain.
And that's essentially the same as Doxygen or Javadoc or whatever. Literate programming isn't WEB or CWEB or tangle/weave, it's the mindset. It's just ridiculous to suggest that you can write documentation and then get CWEB to generate the program as the original post said.
He said, "CWEB and similar tools take a documentation and generate a program." How exactly does CWEB generate the program? I don't think stripping out the documentation is really best described as "generating" a program. You still have to write the program yourself don't you?
What, so I just write the documentation and then get CWEB to turn it into a program? How on earth did I spend 15 years writing software without hearing about this revolution? Or perhaps you are talking rot!
It was TDD that he was having talking about rather than unit tests. And what he actually said was that he didn't find TDD appropriate for the sort of things he did.
But why let the facts get in the way of a sensationalised headline here on Slashdot, the respectable face of tabloid technology journalism!
The thing about having GC is not that it makes it easier to avoid memory problems, it is that it makes writing code more enjoyable. Contrast writing something in Python, say, with writing it in C. In Python you can concentrate on the job at hand. In C you spend all your time doing the book keeping. Obviously there's a place for C and C++, and Java, C#, Python, Ruby, Fortran, Delphi etc. etc. etc., but people will work with what they enjoy. And that means that when you get to choose between C/C++ and a higher level language then the HLL will win.
Slashdot Mirror
Piss people off? By trying to fit in and be accommodating of other peoples preferences?
I guess you are right though. Your strategy of forcing you personal preferences on all your co-workers is sure to be less irritating!
Well, good luck in your work career!
That will only work if the others are prepared to use Gliffy, or something else. If they aren't then he's stuck with Visio.
Unless of course he wants to stop collaborating with his co-workers, but of course that might have other consequences.
He doesn't need an alternative to Visio since he is collaborating with other users that use Visio.
There's actually quite a lot to be said for asking certain questions when an app starts rather than at installation time.
The questions you ask at installation time should be the ones that sysadmins can answer, like where do you want me to put the app and which components do you want to install.
The questions you ask when a user starts the app (for the first time) are questions that the user's answer. An easy way to work out which category a particular choice falls in is whether or not the setting is per user or one setting for the entire machine.
The default browser is a per user setting and the choice should be offered when a user starts the app for the first time.
Presumably what Mozilla have done is to set the default browser for the user performing the installation. This seems somewhat perverse.
Of course Mozilla has little penetration in corporations where these issues are more relevant. And it won't ever get any such penetration until there are good tools for packaging Firefox + add-ons in an MSI. Before anyone flames about MSI being Windows only, corporations overwhelmingly use Windows on the desktop. And even for non-corp users I'll bet Firefox gets more use in Windows than the other OSs combined.
Er, I think you'll find that MS had a decent C/C++ compiler long before .NET. What do you think it built all those versions of Windows with?
So, who's the current world record holder? I'd ask Norris McWhirter but he died.
Well, we at least understand how to queue!
As I thought, Bugzilla. The use of Bugzilla like this essentially makes submitting bug reports the preserve of the expert. Perhaps that's by design!
How does one do that?
Ultimately, I don't believe in the religious wars over commercial vs open source. My guess is that good software is developed by clever people in environments that allow them to thrive. That be just as easily be commercial or open source. It's probably easier for the clever people if they get paid since that does grease the skids, but being paid or otherwise is not the key point.
It's interesting that the collection of geeks and nerds here talk mostly about the technical side of this problem. Yes there's a horrible security flaw and yes it's been patched, albeit somewhat slowly.
But the parent post seems to me to touch on the real issue and that is the process of software development and packaging. It seems to me that the very nature of the bazaar makes this sort of process failure if not inevitable then very hard to avoid. There are many aspects of security and trust is a key one. Is it really the case that Linux distros are developed in this way? Downstream packagers make changes without getting those changes reviewed by the upstream experts? That is quite astonishing if it is the norm. My trust has just evaporated.
Why do you think that I don't care about my customers? Without them my business would not exist.
It's a good point though that there are more software markets available on Linux and Mac.
As for me, my business is writing finite element (FE) software for offshore engineers, 99% of whom use Windows. Obviously it doesn't take much imagination to decide which platform to support.
As for the APIs, what APIs? We use Delphi, the best kept secret of Windows desktop writing and the VCL does a pretty good job of hiding the low level stuff. And of course it's native code so the numerical FE stuff runs quickly too.
I personally find that food and shelter costs money and as a writer of desktop applications that means I like to target a platform that has some users. And that's where the debate ends for me.
Anyone who writes commercial desktop apps and decides which platform to use for any other reason than that is plain crazy.
I think that's just what I said. Sure the mindset difference is important. But my main point was that WEB/CWEB whatever cannot generate your program. You still have to write it yourself. But you don't seem to be able to read what I actually say in my posts.
Now, writing the documentation first helps you work your specification out and therefore allow you to code a system that actually does what the users want. TDD devotees would argue that TDD does the same. All these arguments about which processes work best are rather pointless. What works for one person may not work for the next person. But what will always work is clever people thinking about what they are doing and trying to do it better. Knuth knows this and says that whilst literate programming makes him tick it may not for others. So be it.
My point is that generating the program from the documentation is somewhat misleading. You still write the code, but it's annotated with the documentation. Or, if you prefer, you write some documentation but annotate it with code. Either way you then run programs that strip either code or doc and are left with the other to feed into the next stage of the tool chain.
And that's essentially the same as Doxygen or Javadoc or whatever. Literate programming isn't WEB or CWEB or tangle/weave, it's the mindset. It's just ridiculous to suggest that you can write documentation and then get CWEB to generate the program as the original post said.
Well, my question stands, how exactly does CWEB generate the program? You still have to write it yourself. CWEB does not generate it.
He said, "CWEB and similar tools take a documentation and generate a program." How exactly does CWEB generate the program? I don't think stripping out the documentation is really best described as "generating" a program. You still have to write the program yourself don't you?
What, so I just write the documentation and then get CWEB to turn it into a program? How on earth did I spend 15 years writing software without hearing about this revolution? Or perhaps you are talking rot!
It was TDD that he was having talking about rather than unit tests. And what he actually said was that he didn't find TDD appropriate for the sort of things he did.
But why let the facts get in the way of a sensationalised headline here on Slashdot, the respectable face of tabloid technology journalism!
Javadoc, doxygen, python docstrings, these are all literate programming tools. Everyone's heard of it, they just don't know the name.
Are you saying that TeX is the first thing that Knuth wrote?
The thing about having GC is not that it makes it easier to avoid memory problems, it is that it makes writing code more enjoyable. Contrast writing something in Python, say, with writing it in C. In Python you can concentrate on the job at hand. In C you spend all your time doing the book keeping. Obviously there's a place for C and C++, and Java, C#, Python, Ruby, Fortran, Delphi etc. etc. etc., but people will work with what they enjoy. And that means that when you get to choose between C/C++ and a higher level language then the HLL will win.
Should have used my Google Docs grammar checker right?
Google didn't hardly delivered Docs in the cloud first, it bought Upstartle and inherited Writely which then was rebranded as Docs.