|
I've always shown (quite deliberately) ruffle feathers whenever the science are not considered art. They live off of creativity; not all are skilled enough to excel in their usage; (etc.);
How, then, are they any different than painting? than music? than pottery making.
Particularly, these days, when my craw is annoyed by such terms as artisan bread and it's trendy ilk.
One difference is that, in a culture that still makes fun of academic achievement, there is no thought of teaching an appreciation for the creativity involved in science and technology. Oddly, they teach courses in "art appreciation" and "music appreciation" - but then, if they were so self-evident, would the courses be needed?
It's a distinction - nay - a discrimination - which must be righted.
As a chemist (in real life) - I would always point out to people: "Look around you. What was not made by a chemist? Even the wood has its beauty enhanced and surface protected by stains and coatings"
"Condemnant quod non intellegunt"
"The difference between genius and stupidity is that genius has its limits." - Albert Einstein | "As far as we know, our computer has never had an undetected error." - Weisert | "If you are searching for perfection in others, then you seek disappointment. If you are seek perfection in yourself, then you will find failure." - Balboos HaGadol Mar 2010 |
|
|
|
|
|
|
I would call this, as many have, a grotesque over simplification.
Although, abstraction is so vague as to cover my counter argument (deleted).
Since you can abstract Higher or Lower from the system you are reviewing.
So, we take complex things, and either break them down, or abstract a box for
them to exist in neatly. When we open the box, we again, take the pieces, and
apply this.
Hmmm... I would argue, that if the implication was NOT that we ONLY have those 2 methods.
And it said, we tend to utilize 2 core methods... Then I would potentially buy this.
Easily, upon introspection, this hits the 80/20 rule. As long as abstraction covers "ignoring,
and praying it works after I recompile<grin>"
|
|
|
|
|
|
No, I don't agree. There's also pattern matching.
And I don't agree that this is simply personal philosophy. Managing complexity is key to maintainability. The more techniques you have for doing so, the more maintainable your code is.
We can program with only 1's, but if all you've got are zeros, you've got nothing.
|
|
|
|
|
I prefer to stand at Olympian heights and look down at the problem to look for similarities the closer view hides with complexities.
For example, I once had a manager hand me a 15 page flowchart she wanted implemented. I looked at it from 30,000 feet and saw that it could be implemented in one page, the special cases could all be reduced to "fill in the blank" when it came to processing and I moved all the special behavior to database entries that would fill in the blanks as needed.
Essentially a programmable program which was able to have a default, fail soft behavior, it conditions did not match. That mode of operation was a real saver because the department we wrote the program for changed conditions without informing us. Months later I found the program behaving in default mode and contacted the department to see what had changed.
A few database entries later, and it was back to optimal performance.
I suppose you could call that abstraction with a divide and conquer behavior.
Psychosis at 10
Film at 11
Those who do not remember the past, are doomed to repeat it.
Those who do not remember the past, cannot build upon it.
|
|
|
|
|
It seems that human mind cannot handle "a lot" of complexity, only 7 things at once, more or less (+/- 2)
[^], Cheers
|
|
|
|
|
If you take that sentence out of its context in the book, and assume that's a kind of "uber truth" about software design ... rather than an "aside" reflecting one of the author's probably many casual statements; although, if the author actually said "humans ... have only two methods," that's pretty grandiose.
Then I think that sentence "fails:" it doesn't do justice to the wealth of "formalisms" ... patterns and practices ... that have evolved in what you might loosely call "computer science."
For example: step-wise refinement; object-oriented design, design patterns, analysis of algorithmic complexity: those would go on my list along with many other concepts/ideas/practices/philosophies.
In 1996, the ideas about many aspects of software design and coding in this multi-author book organized by Stanford's Terry Winograd gave me a lot to think about, and it's on-line now, free: [^].
«What we observe is not nature itself, but nature exposed to our method of questioning» Werner Heisenberg
|
|
|
|
|
|
done, the latest copy is in 'pending approval' stage, so once it gets approved you'll see it - I put it under 'Miscellaneous'
hope that helps
Garth
|
|
|
|
|
Thank you so much, that was very kind of you. If you're ever in southern parts of Sweden, drop me a line, I'll buy you a beer
|
|
|
|
|
tack I was in Stockholm for a week a few years back - loved it - wished I could have spent more time and seen more
|
|
|
|
|
Ingen fara Stockholm is nice, but I prefer the south - Skåne[^]
As for the article on CodeProject - I have no clue how that would work out and who I would need to approach to write the article, but it would definitely help get a few more devs interested in the project and perhaps get them to contribute.
|
|
|
|
|
|
Thanks for the tips. I will check that out and see if I can put something together.
|
|
|
|
|
you are welcome
M.D.V.
If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about?
Help me to understand what I'm saying, and I'll explain it better to you
Rating helpful answers is nice, but saying thanks can be even nicer.
|
|
|
|
|
btw - why isn't that posted as a full article in its own right here on CP ?
just sayin
|
|
|
|
|
BTW, added my approval.
/ravi
|
|
|
|
|
|
Only one more approve vote needed. (Mine was #4)
What do you get when you cross a joke with a rhetorical question?
---
The metaphorical solid rear-end expulsions have impacted the metaphorical motorized bladed rotating air movement mechanism.
---
Do questions with multiple question marks annoy you???
|
|
|
|
|
Thank you for your vote, I appreciate it.
|
|
|
|
|
It is already approved
M.D.V.
If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about?
Help me to understand what I'm saying, and I'll explain it better to you
Rating helpful answers is nice, but saying thanks can be even nicer.
|
|
|
|
|
Thanks Nelek. I don't see the changes, so I'm guessing it will take a few days until approved changes appear.
|
|
|
|
|
I am working on making the GNU Coreutils build with MinGW-w64. So far so good.
I have:
* base64
* basename
* cksum
* cp
* cut
* date
* dirname
* echo
* env
* expand
* expr
* false
* fold
* getlimits
* head
* join
* link
* ln
* logname
* md5sum
* mkdir
* mkfifo
* mknod
* mktemp
* mv
* nl
* nproc
* numfmt
* paste
* pathchk
* pr
* printenv
* printf
* pwd
* readlink
* realoath
* rm
* rmdir
* runcon
* seq
* sha{1,224,256,384,512}sum
* shuf
* sleep
* stdbuf
* sum
* sync
* tac
* tail
* tee
* test
* touch
* tr
* true
* truncate
* tsort
* uname
* unexpand
* uniq
* unlink
* wc
* yes
I haven't tested all of them, but I know the following work:
* cp
* echo
* false
* head
* mv
* mkdir
* md5sum
* pwd
* rm
* rmdir
* seq
* sha*sum
* tail
* touch
* uniq
* uname
* true
* wc
* yes
What do you get when you cross a joke with a rhetorical question?
---
The metaphorical solid rear-end expulsions have impacted the metaphorical motorized bladed rotating air movement mechanism.
---
Do questions with multiple question marks annoy you???
|
|
|
|
|
Is this from a good bug-free (Oh! what in the world did I wish! source?
If it works can you send it to me
I'm just too lazy to build one copy for myself...
Beauty cannot be defined by abscissas and ordinates; neither are circles and ellipses created by their geometrical formulas.
Carl von Clausewitz
Source
|
|
|
|