As for the balance between popularising science and actual research, you should obtain a copy of Isaac Asimov's "View From a Height".
In his introduction he makes the case for both kinds of scientists. After he obtained his degree, his doctorate, etc, he found that he had to specialise too much. He really liked to be able to know a little bit of everything instead of a whole lot of one thing. Its unfortunate that he only had a very narrow channel to popularise science.
His essays are invaluable material to read to understand the mind set of scientists and engineers.
They weren't smoking anything. They were told to do it, in order to provide a consistent interface across all Windows.
I know from experience that there are processes which look like each other superficially. Management then wants to push a unified interface. The domain where I met this problem was in doing the version control for a product and its associated subsystems. These are developed separately. The integration phase (product) is just different from the development phase (subsystems). However, there are people who think that they are the same because they just see builds and baselines. However, the underlying logic is different, because for subsystems one needs to take into account more build problems, while for the product integration phase, fast releases are the prerequisite. Trying to build the same interface just ends up in a double bloated system.
Anyway, the same goes for these products. You have desktop/laptop use, pad/pod use and server use. These are different use cases, which should lead to different analyses, and which should lead to different solutions for the final user.
To use a shoe analogy: it would be like trying to design a shoe which is fit for promenading in the city, trekking and combat use.
You should read up on control theory. Brains form a whole lot of feedback loops. One of the things in feedback loops is that when the amplification is increased, unstability issues pop up.
Welk Nederlands jeugdboek uit de jaren '80 maakte daar al eens melding van? Ik dacht dat het er een van Jan Terlouw was, maar ik vind het niet in zijn bibliografie (inhoud: Groen komt aan de macht en dit leidt tot een (idealistische) dictatuur).
If you have used these, then you Perl background is enough to learn also Python or Ruby.
What I do not understand in your question is this. You have programmed for about 35 years, and yet your question seems to indicate that you have not found out yet that all programming languages are in essence the same. Someone experienced like you should have the basics of Perl and Ruby under the knee in less than a week, and then invest yet another week to know what the possibilities by working through the documentation to see what libraries are standard available.
That could also be the because the organic farmer chooses a tomato plant not based upon marketing and optimisation of the growing to delivery life cycle.
One of the main benefits of organic producing is that all things get the time to reach their optimal taste, while in standard procedures everything is harvested too early, be it vegetable or animal.
Because it is expensive, management does not want to hear that they made the wrong decision and threw away money
Management does not use the expensive software themselves
Only the people who use it know how bad the software is, but they cannot reverse the decision
I have another, less known example: Continuus/CM/Synergy. A VCS which is very expensive, and needs expensive servers to run on, but which has been surpassed in capacity by open source version control and issue systems a long time ago.
You can still change everything in place. Then you can run the script and get feedback. When it works, you commit. When it doesn't, you remove the problem, check and commit.
Or you can make your changes, review them and commit them, then do a run. When you have a problem, you commit again.
It is not because you use a versioning system that you need extra formality. You can still work the way you used to, but now you have an extra safety measure due to the versioning system.
Using trac is a way to better organise your problems. The main thing I can say about using trac effectively is that you always need to have a browser window open on it, and when you have an idea, or notice something, or have problem, then enter it immediately. Afterwards, take your time to look at new and open problems, classify them and process them.
Or the former Deutsche Democratische Republik (with the Iron Curtain of the TSA between the US and the rest of the world)
That was also my first idea: powered by the gas of Ballmer!
The KISS principle is the best engineering principle
As for the balance between popularising science and actual research, you should obtain a copy of Isaac Asimov's "View From a Height".
In his introduction he makes the case for both kinds of scientists. After he obtained his degree, his doctorate, etc, he found that he had to specialise too much. He really liked to be able to know a little bit of everything instead of a whole lot of one thing. Its unfortunate that he only had a very narrow channel to popularise science.
His essays are invaluable material to read to understand the mind set of scientists and engineers.
So what is really meant is that they need a proper qualitative development process, guided by lean principles.
Yeah, well, wasn't that horse already beaten to death by Apple?
They weren't smoking anything. They were told to do it, in order to provide a consistent interface across all Windows.
I know from experience that there are processes which look like each other superficially. Management then wants to push a unified interface. The domain where I met this problem was in doing the version control for a product and its associated subsystems. These are developed separately. The integration phase (product) is just different from the development phase (subsystems). However, there are people who think that they are the same because they just see builds and baselines. However, the underlying logic is different, because for subsystems one needs to take into account more build problems, while for the product integration phase, fast releases are the prerequisite. Trying to build the same interface just ends up in a double bloated system.
Anyway, the same goes for these products. You have desktop/laptop use, pad/pod use and server use. These are different use cases, which should lead to different analyses, and which should lead to different solutions for the final user.
To use a shoe analogy: it would be like trying to design a shoe which is fit for promenading in the city, trekking and combat use.
You should read up on control theory. Brains form a whole lot of feedback loops. One of the things in feedback loops is that when the amplification is increased, unstability issues pop up.
Welk Nederlands jeugdboek uit de jaren '80 maakte daar al eens melding van? Ik dacht dat het er een van Jan Terlouw was, maar ik vind het niet in zijn bibliografie (inhoud: Groen komt aan de macht en dit leidt tot een (idealistische) dictatuur).
GREETINGS!
You write much phishing e-mails? Or are you trying to win the buzzword bingo?
Cheers!
If you have used these, then you Perl background is enough to learn also Python or Ruby.
What I do not understand in your question is this. You have programmed for about 35 years, and yet your question seems to indicate that you have not found out yet that all programming languages are in essence the same. Someone experienced like you should have the basics of Perl and Ruby under the knee in less than a week, and then invest yet another week to know what the possibilities by working through the documentation to see what libraries are standard available.
Cats do not need protection from PETA, because the cat owns you.
Clams, oysters, scallops and mussels are also mollusks, and very tasty!
I presume that these things were not that secret at the time.
At the end of the story it is revealed that the flying saucer is made by Avro Canada.
George Adamski's UFO also looks somewhat like this design.
+1 Insightful
+a story everyone should read!
That could also be the because the organic farmer chooses a tomato plant not based upon marketing and optimisation of the growing to delivery life cycle.
One of the main benefits of organic producing is that all things get the time to reach their optimal taste, while in standard procedures everything is harvested too early, be it vegetable or animal.
Recipe for a Planet
See also 'Project Mohole'
Everything in MP3 is either a storage format (C structs), or is based upon the orthogonality property of linear algebra.
The problem with expensive software:
I have another, less known example: Continuus/CM/Synergy. A VCS which is very expensive, and needs expensive servers to run on, but which has been surpassed in capacity by open source version control and issue systems a long time ago.
My take on things is that this film is really made to show something else. 'Innocence' can also be explained as 'naivety'.
If we see this film, then we most probably react with a facepalm. 'Plan 9 from outer space' probably has more going for it.
Yet (some) Muslims react violently. These actions come more from naivety than from knowledge.
For me, it is like this film has been made to show how naive some Muslims are, and that is also what I think that the title stands for.
You can still change everything in place. Then you can run the script and get feedback. When it works, you commit. When it doesn't, you remove the problem, check and commit.
Or you can make your changes, review them and commit them, then do a run. When you have a problem, you commit again.
It is not because you use a versioning system that you need extra formality. You can still work the way you used to, but now you have an extra safety measure due to the versioning system.
Using trac is a way to better organise your problems. The main thing I can say about using trac effectively is that you always need to have a browser window open on it, and when you have an idea, or notice something, or have problem, then enter it immediately. Afterwards, take your time to look at new and open problems, classify them and process them.
OS X Felix Domesticux
umedvirk in addition!
Indeed, Jerry Pournelle did this twenty years ago under his shower, with standard keyboards.