Congratulations, Xen; this is more reasoned, less frantic, than your normal responses :-) On 09/28/2015 06:40 AM, Xen wrote:
What she means is that poor designs cause more work, the way I have been saying.
I would agree but only of there is a "can" in that statement. you later go on to quote the use of older, primitive, less designed cars in fringe areas, where because of their simplicity of design, they are more maintainable than a more sophisticated design. I gave the example of the DC9 similarly. The term "poor" is incorrect. I would be much more likely to grant you an agreement if you guys used the term 'inadequate'. There are plenty of 'quick and dirty' designs that are perfectly adequate. Myself, Linda, many here have enough experience to throw together a quick shell script on line, no need for a file, or a perl/sed/awk one line that gets the job done. No need for hours of thought or hours of development. "Use once, throw away". We come from a UNIX generation where the CLI is natural; people coming from a GUI world like Windows (or possibly the MAC) don't naturally think that way, don't naturally see a quick solution. Constructing an application with the GUI takes more thought,effort and time. Perhaps that's the basis for your estimations. As I keep saying Context is Everything
If you spend 30 hours designing something and then 60 building it, you will in the end have a vastly more efficient system than if you spend 2 hours designing it (or not even) and then 30 building it. The reason is because the better system is going to save you time.
I can't see the reasoning behind that. Perhaps if you don't have the experience and have to sweat it all out; perhaps if you are doing things as a GUI. I really can't see it. Is this the way they are teaching at schools and colleges now?
Often software requires an investment, it pays off in the long run. Perhaps "better" is subjective as you have been indicating.
There's no "perhaps" about it. Many people here are quite clear that the software set and environment we call Linux is better FOR THEM than using the software set that we call Windows. You can call it a religion, but most people on each side simply don't want to get into a religious war or a pizzing match. They have something that works FOR THEM and that OK. Often the investment is not in the specific software, as many people selling courses on each upgrade of MS-Office would have you believe, but in attitude and technique.
In that case a more objective statement would be that in general the more time you spend in advance, the more time you will save later on.
As a more general statement that is a good one, but it should not be applied in the way you are trying to apply it here. I've often quoted http://www.zdnet.com/article/why-many-mcses-wont-learn-linux/ This isn't about right or wrong. Its about different styles and attitudes. Just as there are different attitudes towards sports, mathematics and science in North America, Europe, Russia and China, that are often difficult to express. The time I've spend in my youth learning how UNIX works, pouring over the manuals, experimenting, working my way through the examples in the White books, has paid off, yes. it means I can quickly make design decisions. I don't need the 30 hours/60hour. I can quickly eliminate many of the less functional design decisions, the time that would be wasted on trying out or coding 'dead ends' and focusing on getting results that can later be refined. This 'first to market' approach is a valuable skill. While you might see it as fail, that is because you don't have the experience that I'm talking about to avoid the things that would be a !FAIL! in the first product. Benz, the Wright brothers, the Dodge bothers and many more were not neophytes; they were experienced engineers when they built their first models.
But the more people work together, or products are created that follow designs that are more elegant but require more time to build, the more in the end time is used more efficiently and also more effectively across the board.
Again, you come close to the mark. The issue when you are doing work with a team is that it is how they are managed that determined how effective they are. Having a team of geniuses is more problematic than having a team of mid-levels who can be kept focused together on the one objective and keep the scope constrained. The geniuses are like a herd of cats, each with their own brilliant ideas, each trying to go their own way. Its why campaniles like Microsoft and IBM and others can Get Things Done on large scales. There is nothing new about this: The Roman legions were effective against hoards of powerful barbarians because of organization and discipline; the British armies in Africa and India ditto. The British "Raj" was actually a very small group but managed a huge country. Its not about right or wrong; its about being effective. You may say that the attrition in this cases was wasteful and hence not efficient but that depends on your POV and objectives.
This is then what we call "good design" or "better design".
Good and better are subjective and context dependent.
But if these solutions do not exist and you need something working in 2 days (or less), then obviously it won't be "better" to start designing a long-term system.
And once again, we come to the 'use once and throw away' capability that the UNIX/Linux CLI permits, something that you simply don't have with a GUI based system. Another property that emerges from the White books is the component-ware attitude of pipes and filters, once again a CLI issue. Many of these one-liners can be put in a file and that file made executable. As far as the system is concerned they execute just like anything else. The hash-bang convention allows for any scripting language. So the executable can be called and used with pies and filters and cron and other automation tools. UNIX/Linux is easily extensible. Once upon a time in the V6/V7 and early BSD days, UNIX fit on a 5 megabyte RLO1 or perhaps a 10M RLO2. I must admit that i had a liking for the smaller capacity more 'flying saucer' http://www.pdp8.net/rk05/pics/small/pack.jpg that was a precursor, perhaps, to the Millennium falcon :-) This limited disk space meant that many of the utilities we no have as binaries were implemented as scripts. They took up less space, even with the old V7 file system, which wasn't nearly as space efficient as more modern file systems. They made the system viable. You can argue that the binaries are faster. Its a bit of a weak argument since the is the load a go overhead, whereas with the script the shell was already loaded. You can certainly argue that replacing the script with a binary requires more hours of thought in design and hours of coding. But when do you get to the turnover point where that time is actually paid back by the "more efficient' execution of a binary rather than a script? *IF* you take a business view, of you are in the closed source business, then having a binary rather than a script makes sense. I met that with some UNIX applications in the SCO days. The Progress Database system was a scriptable set-up but the scripts could be complied, which was faster. Some vendors supplied pre-compiled packages with no source but a useful or at least usable set of documentation of the "hooks". From a business POV this was more 'efficient' than giving away the source, they reasoned. However it also mean that they had to offer a level of technical support that giving away the source might have obliviated. The context here is difficult to determine; perhaps a conflict between the older attitudes towards towards software and the "open" attitudes of UNIX.
I mean, I agree with that Anton. The reason I do so much scripting myself is because I sense and see that the ready made solutions are often stuff or things I disagree with and that take time learning.
You have that freedom with Linux. Its a freedom that the greybeards grew up with, and that has driven a slice of software (and hardware) development for more than half a century. Its why UNIX and later Linux has been a prototyping and development platform for so many things in that time.
Better then to use the 'primitive' tools that I already know, and I can whip up something myself faster than it takes to learn the tools I disagree with.
You have that freedom. Its a stage many of us go though. David Rankin, for example, has a huge library of shell aliases. Talk to him about that approach.
And the benefit of that is that: a) I get something that is perfect onto me,
As in it meets your specific context. That is important because Context is Everything
But that doesn't really negates, but rather informs or reinforces the fact that proper thinking in advance of construction may yield rewards later on.
I doubt very much that the designers of the DC9, those classic Mercedes and Range Rovers in use three quarters of a century later, maintained by skilled and imaginative "natives" with primitive tool shops and parts, ever thought about that. They designed to solve an immediate problem, often cheap and easy mass production. perhaps the success of those mechanisms was the sheer *LACK* of thought that went into the design!
Just think of any computer game. You can't design or build a computer game in incremental steps. It's gotta have ONE release. It needs to be thought out in advance, completely designed, and then built. There is no time or even a reason to do it in any other way.
Contrariwise I've seen the original text based 'Adventure' that I played on a PDP-11 in the 1970s, Written in FORTRAN, later converted to C to make it more maintainable, evolve step by step into a more sophisticated model with 'plug-in' mazes; later to have a "maze creation language"; then evolve into an on-line version and eventually to have a GUI, well first block/icon graphics interface on the old PC. If you've missed how some games evolve they you've missed out on a wonder!
its no a poor design, its either adequate or not.
I keep saying Context is Everything and it is. My context is not yours.
If "poor" is subjective and relates to good/bad/better/worse, then perhaps you might be right. But the word is used in a sense of an implicit context. It is assumed (and rightly so, I believe) that the needs of many users converge to a single point.
Yes, that's an assumption that large monolithic companies like Microsoft, GM and more make. They focus on a single product line. Once, Chrysler tied out having options. Someone calculated that the option package would allow for more variations that there were people lining in the USA at that time. if you look at the road, there is not much variation in the cars you see; they fall into a number of modalities where the overall shape is similar; the variations in body colour are few and are often in the outliers. And this is a capitalist country! Turn the clock back and look at the variation in products in the old communist regimes of Russia and China before they were broken out of their State Socialist Economies and forced to trade with the world. Even fewer variations in products like cars and other consumer goods. If you are right about the 'convergence' than its frightening.
Given then, a common interest, or a shared need across many people, we can call one design poor and the other good.
All you are doing here is agreeing with me Context is Everything
But "poor" is less subjective than "good". Poor also means the opposite of rich.
Its not "poor", its "inappropriate".
Perhaps a car that can only run for 10 miles is adequate to your needs (or at least you think it is) but that doesn't define it as "rich".
Disagree. There's an old Harry Harrison short story from the 1970s, the first oil crisis. The basic theme is this family that appears "rich" because they have a big car that goes "vroom vroom" when everyone else cannot afford the price of gas. Then, behind the scene, you learn that the car is clockwork driven and it takes all week to wind it up for that one trip to the grocery store where they impress that neighbours. Yes, the car would only run for 10 miles on clockwork. The clockwork powered the recording of the "vroom, vroom". The family appeared "rich" to their neighbours. The car did the job for which it was intended.
Richness is then a measure of complexity and feature-abundance.
No. You've defined richness that way. But we're getting into philosophy and epistemology here which is so incredibly OT that we should cease.
If you always design incrementally, you may run into a necessity of constantly redesigning your system because you didn't realise beforehand or take into account higher level needs.
Not so. The basic Apache server was intended to be designed, implemented incrementally in a very pick-and-choose manner. It was about "Deferred Design". Of all I can think of, web services are probably the most spectacular example of DD around. The original design didn't take into account PHP, Rails, Struts or a host of other things.
A richer design is also a simpler design, and because of its simplicity it can do more.
Be careful here, you are shifting your definition. Simpler means less features. There are many simple designs that are not extensible the way Apache is.
It has less obstacles or hindrances embedded in its design.
To do that it must have fewer features. q.v.above.
You can say that car that can do a 10 miles is adequate to your needs (at least today) but you might have been mistaken about that and realize that the next day you need it to be able to do 15 miles, and now you have a problem because you need to redesign and rebuild the thing, whereas if you had been less indigent you would be enjoying the fruits of a richer labour.
Yes, if the assumption that the car is for travel rather than impressing the neighbours.
This is what Linda calls poor and rich design, if I may be so bold. It is really a quite general assumption or idea. I don't think many people would disagree with it.
I'm disagreeing mostly because it is inadequately stated.
Take care that you are not limiting yourself in what you want to do because or just because you feel your current system *should* be good enough for you. This DVD system... one day you may start feeling annoyed by it but you feel it "should" be adequate. 5GB file systems is also a pretty big concession (or even sacrifice, if I may be so) to make. You have basically designed your filesystem/computer setup/structure around the /SIZE of DVDs/. That is VERY odd thing to do. That constitutes to me as "poor" and that is not something subjective.
It is subjective simply because it fits the work-flow I have on my home system. It is effective because it makes backups easy; they get done, which is more than i can say about most people I know an their home systems! Work is another matter. Work, variously, has carousels of tapes, big SAN. Effectively unlimited 'cloud' bandwidth. Regular budget. Regulatory constraints and demands. Paying customers. Contractual obligations. That's the work context. I have none of those. My home machine is effectively a 'hobby' machine. That makes it easy to design around those constraints. I never take more than 5G on any one photo project. If I factor out projects, I see that I never have more than 5G of random photos in any one year. My music I organize primarily by genre and origin, and that allows a similar constraint. Email is IMAP and stored on my ISP and they give me effectively unlimited mail archive space. The overpowering "good" of this design is that it allows easy and regular backups. I think if I polled most of the people I know and asked them how often, ho easily they did backups of their home system I'd get quite a few embarrassed responses. Its why Apple, Amazon, Dropbox and so forth are making backup of portable devices so easy *AND* *TRANSPARENT*. Most people don't think about backups, don't see it as part of their work-flow. So they simply don't do backups. It has to be done for them. Or they don't do it at all. If you say designing a home system so that backups is an easy and convenient part of the work-flow is not "good" then I think you are naive and foolish. I get them done because they are easy. I think this is a Good Thing(tm). hence my design is Good For Me. Context is Everything It is relative to other
things that are "less poor" but it is still objective even if it is not absolute. In the absolute, everything is all thing. In the absolute, a thing is both poor AND rich. But in relative terms, to me this comes across as 'poor'. Because it requires you to make so much concessions.
So just to be quick I will say that context determines good/bad but it does not determine poor/rich. Relation to other designs determines poor/rich. Adequate is related to needs. Needs may change over time. You may also lie to yourself about your needs and accept a lesser solution than you could have had (based on your experience and what is possible to experience). A poor solution may also keep you stuck in a situation where progressively, or increasingly, your needs are not or not longer met. But it can also mean that you have a reason to deny that your solution is poor.
It's the same with many solutions these days -- some through faster processors and more space at solutions to avoid the cost of better design. They get what they pay for.
There you go again, assuming that 'efficient' means 'speed'.
Actually she is saying or appears to be saying that "speed" causes "inefficiency" to be less noticable. That does not mean speed and efficiency are the same thing, although in this case efficiency IS related to the time it costs you.
-- A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting frowned upon? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org