• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Ron McLeod
  • Paul Clapham
  • Devaka Cooray
  • Tim Cooke
Sheriffs:
  • Rob Spoor
  • Liutauras Vilda
  • paul wheaton
Saloon Keepers:
  • Tim Holloway
  • Tim Moores
  • Mikalai Zaikin
  • Carey Brown
  • Piet Souris
Bartenders:
  • Stephan van Hulst

Programming: Science or Art

 
Ranch Hand
Posts: 464
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
?
 
Ranch Hand
Posts: 305
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Chicken blood and black candles. No wait, that's communications! Doh!

I've always been of the opinion that creativity is the essential aspect of programming. You must have the technical knowledge, that's a given, however, without the ability to create solutions you're going no where in this business.

I've met a few well qualified programmers, all kinds of certifications, but no real talent. They lacked creativity. If the solution was not to be found in a manual they were lost.

Give me a person that is a good problem solver and I can make them into a programmer.
 
High Plains Drifter
Posts: 7289
Netbeans IDE VI Editor
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Yes it is.
 
Sheriff
Posts: 13411
Firefox Browser VI Editor Redhat
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Michael Ernest:
Yes it is.



but then... maybe not.
 
Ranch Hand
Posts: 1071
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
IMHO you can be a great programmer with minimal science and math background and very good problem solving (creative) abilities, but the reverse is not true. You can be a science and math genius, but without good problem solving skills you're sunk.

Of course there are exceptions where the math and science is really important, can't write a physics engine without some understanding of physics, but that is project specific.
 
Ranch Hand
Posts: 376
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
99% perspiration, 1% inspiration!
 
blacksmith
Posts: 1332
2
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
In my opinion, one can be a competent programmer without any creativity as long as one is careful and pays attention to detail. I've seen too many "programmers" with great creativity but little analytical skill, and they just create huge messes which compile only by luck and never run properly until someone else cleans it up. In contrast, the ones who aren't so creative can often keep plugging away at it and at least make progress.

It's best to have both, of course.
 
Ranch Hand
Posts: 1258
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Perhaps science itself is an art.
 
Steven Bell
Ranch Hand
Posts: 1071
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Just about any endevor becomes art once it reaches a high level of skill. You can teach somebody the mechanics of painting, and they can make good looking paintings, but they won't create any masterpieces.

Programming is the same way, you can teach anybody how to write code, but it takes a bit of unteachable skill to create really good programs.

Pick a field, you will end up with the same situation. There is a point that can be taugh to, then inate ability/experience/determination kicks in.
 
Ranch Hand
Posts: 502
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Actually, the question itself is a misnomer

Science usually means study or investigation of natural phenomena. Engineering means the practical application of certain principles. So the question should be. There is no such thing as "Science of Software", because Software is not a natural phenomena. You can't make empirical observations on Software and build theories around it. There is "Engineering of Software" aka "Software Engineering" which means applying principles to produce Software

So,
"Programming: Engineering or Art?"

Is it Engineering? Yes, in a sense that you have a set number of principles that you can apply to reach certain goals. No, in the sense that even if you apply the principles you dont know whther you have acheived your goals. ALmost all branches of Engineering have conflicting goals, as does Software Engineering. But, the problem with Software Engineering is that many goals cannot be measured. Say, you are designing a component, and you have 2 designs . One is more Maintanable and the other is more Reusable. Now, you cannot empirically measure whether design A is 20% more maintanable than B, or design B is 40% more reuasable than A.

That is where the "Art" part comes in. Most Engineering disciplines teach their students about several tools that will acheive their goals. Since, goals can be empirically measures, you can say for sure which tool is best for that set of goals. For example, an Architect has to make a 120-storey building. He knows what kind of stresses the building will bear, and can select materials that can handle those stresses. OTH, in Software Engineering, you can think of Design patterns as a set of tools that you can apply to solve the problem. However, selection of Design Patterns is an "Art". You cannot say that using a Facade pattern will increase maintainibility by X amount, or using Listener patter will increase Reusability by Y amount. It's mostly gut feel and experience
 
Bacon
Ranch Hand
Posts: 305
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Nathaniel Stoddard:
Perhaps science itself is an art.



Math is not science and many consider it art. hmmmm
 
Ranch Hand
Posts: 581
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I 100% agree with Warren Dew.

If there has to be a choice between science and art, I'd favour science over art for programming. In the field of programming, still, analytical/logical thinking is the most crucial thing. Science is backed by solid math. Art reflects intuition with images, be it visual images or musical images or whatever. Sure, intuition could/should be involved in the programming, but one cannot _count on_ intuition in this field. If I were to hire programmers, I wouldn't care about her/his creativities at all. �bung macht den Meister, even creativities can be trained and improved. And, there are enough invented wheels, it's already dreamy enough for one to use them wisely. And, the more analytical one is, the stronger intuition she/he has for abstract/complex things. Okay, I'm only talking about programming, not anything _else_.
[ February 11, 2005: Message edited by: Ellen Zhao ]
 
Ellen Zhao
Ranch Hand
Posts: 581
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Ray Marsh:

I've always been of the opinion that creativity is the essential aspect of programming.


While I truely think good creativity is a big plus for a programmer, and it is a must for some cutting edge research, but dear Mr. Marsh I just cannot agree it is _essential_, for most of the real-world tasks. For me, "lack of creativity" in _programming_ is not too different from "haven't learnt enough" or "not diligent enought to learn more".

I've met a few well qualified programmers, all kinds of certifications, but no real talent. They lacked creativity. If the solution was not to be found in a manual they were lost.
No I don't think it's the creativity they lack. But dear Mr. Marsh I guess you know how most cert. questions look like. One doesn't have to understand the real spirit/backening philosophy of a technology to pass a cert exam. It's not the creativity they lack, instead, I'd imagine they probably couldn't analyse the problem in a logical way, or they haven't known wonderful algorithms for such problems which has existed for decades...
[ February 11, 2005: Message edited by: Ellen Zhao ]
 
town drunk
( and author)
Posts: 4118
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Programming is a craft, much as capentry is a craft. With apologies to Robert Pirsig:


Sometime look at a novice workman or a bad workman and compare his expression with that of a craftsman whose work you know is excellent and you'll see the difference. The craftsman isn't ever following a single line of instruction. He's making decisions as he goes along. For that reason he'll be absorbed and attentive to what he's doing even though he doesn't deliberately contrive this. His motions and the machine are in a kind of harmony. He isn't following any set of written instructions because the nature of the material at hand determines his thoughts and motions, which simultaneously change the nature of the material at hand. The material and his thoughts are changing together in a progression of changes until his mind's at rest at the same time the material's right."

"This divorce of art from technology is completely unnatural. It's just that it's gone on so long you have to be an archeologist to find out where the two separated
 
Bacon
Ranch Hand
Posts: 305
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Ellen Zhao:
I'd imagine they probably couldn't analyse the problem in a logical way, or they haven't known wonderful algorithms for such problems which has existed for decades...[ February 11, 2005: Message edited by: Ellen Zhao ]



Ellen... I am not discounting learning at all. Heaven knows I have a lot of programming books! You must have knowledge to be a programmer, no doubt. However, you cannot teach talent. If you have a small amount of talent you can develop it. If you have none, forget it, become something else that can get by on knowledge and/or effort alone. I went to school with a bright fellow that was just wrong for programming. I don't know how else to say it. I would help him with a concept and he could absorb the information and repeat it in an accurate manner. He could not, however, apply it.

There is an ability/talent... call it imagination, creativity, something else, that allows a person to be an exceptional programmer.
[ February 11, 2005: Message edited by: Ray Marsh ]
 
Rick Beaver
Ranch Hand
Posts: 464
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
My own opinion is that anyone can be taught how to use tools to realise their vision.

My perception is that programming is an art form. A gifted programmer is one that can take a problem and visualise a software solution. It is just an academic exercise to learn the tools to implement it.

On the flip side somebody who knows the language inside out, can convert binary to hexidecimal in their sleep and could recite the JLS is not a programmer if they cannot visualise a solution to a problem.

Thinking about it though, perhaps a distinction should made between programmer and developer. Using what I have written above one could say that someone that knows the language inside out is a programmer, they can write very good code. Perhaps the artists are the developers, the ones who can apply their skills to develop a solution.
 
Ranch Hand
Posts: 1759
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Creativity is becoming crucial. One programmer might be the eagerest adopter of new tech, another the scaredest of new technology.

The first may not necessarily be the better employee.
The more creative (artistic) would be the better customiser. - for example Customer relationship management is becoming more automated.
The more scientific would be the better introducer or adopting new technology into a company, by being less scared of it.

You need both types of programmer, but they may not necessarily work together in the same location.

A creative programmer would provide the differentiation of what a scientific programmer has set down. My 2 cents worth.
[ February 12, 2005: Message edited by: Helen Thomas ]
 
Ben Souther
Sheriff
Posts: 13411
Firefox Browser VI Editor Redhat
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Max Habibi:
Programming is a craft, much as capentry is a craft. With apologies to Robert Pirsig:

[qb]Sometime look at a novice workman or a bad workman and compare his expression with that of a craftsman whose work you know is excellent and you'll see the difference. The craftsman isn't ever following a single line of instruction. He's making decisions as he goes along. For that reason he'll be absorbed and attentive to what he's doing even though he doesn't deliberately contrive this. His motions and the machine are in a kind of harmony. He isn't following any set of written instructions because the nature of the material at hand determines his thoughts and motions, which simultaneously change the nature of the material at hand. The material and his thoughts are changing together in a progression of changes until his mind's at rest at the same time the material's right."

"This divorce of art from technology is completely unnatural. It's just that it's gone on so long you have to be an archeologist to find out where the two separated[/QB]



Excellent choice, Max, but rather than apologize, maybe a plug for the book is in order?
http://www.amazon.com/exec/obidos/tg/detail/-/0060958324/qid=1108214546/sr=1-1/ref=sr_1_1/104-9548733-7352766?v=glance&s=books
[ February 12, 2005: Message edited by: Ben Souther ]
 
Ellen Zhao
Ranch Hand
Posts: 581
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
except from my latest blog entry:

...I�m not saying strong mathematic background and fundamental theory of computation are not important. Quite the opposite, truth is that they are essential, even for the most mundane, �stepped� computational tasks. All programs eventually talks to machines, no matter how high-level the programming language is. Machines don�t process information quite the way we humans do. Humans are so advanced, our logic can be fuzzy, we have great intuitions in various occasions. But machines can only process things in a stricktly mathematicised way. The logic which machine can understand and process has to be precise. For the time I�m blogging this piece, no matter how advanced a computer is, it is in fact a super Turing Machine in nature. That�s why all the greatest computer scientists strive to formalise everything to make our complex real-world machine-processable. IT field is constantly changing. I�ve seen way too many developers, who didn�t have a formal education in computer science, killing themselves to learn the newly popped technologies to make themselves marketable. However, whatever the trendy technologies are, there�s always something static behind the scene. Real computer scientists understand the way a technology abstracts things, can recognise a technology�s math pattern, can evaluate how effetively a technology can reduce the entropy of certain problem domain...



Dear Helen I think we are talking about programming but not marketing in this thread. Marketing deals with people. In marketing emotion counts, impulse counts. I could hardly imagine marketing would be totally automated. Let's take the fabulous personalised recommendation from amazon.com for example. How does amazon's system generate highly heart-crushing recommendations for you? It's not that difficult to imagine it, you don't have to be extroadinarily creative to point out that they collect user data and then do some really fancy statistics. But building the information analysing system does need solid knowledge and skill, which is scientific.
[ February 12, 2005: Message edited by: Ellen Zhao ]
 
Ellen Zhao
Ranch Hand
Posts: 581
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Nick Leaver:
On the flip side somebody who knows the language inside out, can convert binary to hexidecimal in their sleep and could recite the JLS is not a programmer if they cannot visualise a solution to a problem.


Dear Mr. Leaver but I'm afraid converting binary to hexidecimal is not programming or software engineering. Nor is the reciting of JLS. Programming is all about how to process information.
[ February 12, 2005: Message edited by: Ellen Zhao ]
 
Ellen Zhao
Ranch Hand
Posts: 581
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Jayesh Lalwani:
You cannot say that using a Facade pattern will increase maintainibility by X amount, or using Listener patter will increase Reusability by Y amount. It's mostly gut feel and experience


Dear Mr. Lalwani but I'm afraid the efficiency of a system _can_ be measured this way. But how to measure it is just very difficult mathematics (but such math does exist), hardly any people really master it. So that people resort to gut feel from time to time. Here experience is very important. Experiences reveal certain facts for example this is more efficient that is not. But behind the this and that, in the field of programming, there is solid, beautiful but difficult math.
[ February 12, 2005: Message edited by: Ellen Zhao ]
 
Jayesh Lalwani
Ranch Hand
Posts: 502
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Ellen Zhao:

Dear Mr. Lalwani but I'm afraid the efficiency of a system _can_ be measured this way. But how to measure it is just very difficult mathematics (but such math does exist), hardly any people really master it. So that people resort to gut feel from time to time. Here experience is very important. Experiences reveal certain facts for example this is more efficient that is not. But behind the this and that, in the field of programming, there is solid, beautiful but difficult math.

[ February 12, 2005: Message edited by: Ellen Zhao ]



Efficiency is not the only goal of a software system. Efficiency is one of the goals that can be measured. Other important goals like maintainability, reusability, scalibility, etc cannot me measured.

Besides, in most projects, especially, those that require a lot of user interaction, efficiency takes a back seat over maintainability and reusability.
 
Ellen Zhao
Ranch Hand
Posts: 581
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Jayesh Lalwani:

Efficiency is not the only goal of a software system. Efficiency is one of the goals that can be measured. Other important goals like maintainability, reusability, scalibility, etc cannot me measured.

Besides, in most projects, especially, those that require a lot of user interaction, efficiency takes a back seat over maintainability and reusability.



Yes I totally agree with you. But I guess our concepts of efficiency are a bit different, there's some overlapping though. All the terms of "maintainability" and "reuseablity" can be _reducted_ to efficiency. The efficiency I am talking about is not how fastly the code can be generated or how hurrily a software-developing team should do, but how effectively a certain algorithm/design approach can reduce the information entropy of a problem domain. When a problem is to be solved, the initial entropy is very high, via certain information processing, entropy is reduced. Entropy can be reduced at many different places, People devide a software system into several independent layers in oder to focus on smaller entropy inside a certain layer, this way information is easier to process and problem is easier to solve. The common goal of maintainability and reusability and etc. etc. are all to reduce the entropy of a problem domain, thus save the resources which should be dedicated to solving this problem...Here by resource I mean time, money, human labour...
[ February 12, 2005: Message edited by: Ellen Zhao ]
 
Warren Dew
blacksmith
Posts: 1332
2
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Jayesh Lalwani:

You cannot say that using a Facade pattern will increase maintainibility by X amount, or using Listener patter will increase Reusability by Y amount.

Ellen Zhao:

Dear Mr. Lalwani but I'm afraid the efficiency of a system _can_ be measured this way. But how to measure it is just very difficult mathematics (but such math does exist), hardly any people really master it.

Yes. Measurement and analysis of these things really would qualify as science - since it involves observing and understanding parts of the world (specifically, programmers and what they do). It would be computer science - understanding how programming works - rather than software engineering - actually doing the programming.

Jayesh:

Efficiency is not the only goal of a software system. Efficiency is one of the goals that can be measured. Other important goals like maintainability, reusability, scalibility, etc cannot me measured.

It seems to me all these things can in fact be measured. Observe how many programmer hours are required to maintain a system for a few years; that's a measure of maintainability. Observe how many times a particular module is reused; that's a measure of reusability. Scale up the use of the system and see when it breaks to measure scalability.

These things may be expensive and difficult to measure, and that's indeed why they aren't often measured. Also, the measures may not be perfect - no measurement is. But making such measurements is possible, and can be useful in certain circumstances.
 
Jayesh Lalwani
Ranch Hand
Posts: 502
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Warren Dew:
Jayesh Lalwani:

You cannot say that using a Facade pattern will increase maintainibility by X amount, or using Listener patter will increase Reusability by Y amount.

Ellen Zhao:

Dear Mr. Lalwani but I'm afraid the efficiency of a system _can_ be measured this way. But how to measure it is just very difficult mathematics (but such math does exist), hardly any people really master it.

Yes. Measurement and analysis of these things really would qualify as science - since it involves observing and understanding parts of the world (specifically, programmers and what they do). It would be computer science - understanding how programming works - rather than software engineering - actually doing the programming.


Computer Science is a very broad subject that includes everything from building of computers, to maintenance of computers to programming computers. Parts of it like building electronic circuitry are based on pure science. But, there's nothing like Software Science or Programming Science.


Jayesh:

Efficiency is not the only goal of a software system. Efficiency is one of the goals that can be measured. Other important goals like maintainability, reusability, scalibility, etc cannot me measured.

It seems to me all these things can in fact be measured. Observe how many programmer hours are required to maintain a system for a few years; that's a measure of maintainability. Observe how many times a particular module is reused; that's a measure of reusability. Scale up the use of the system and see when it breaks to measure scalability.

These things may be expensive and difficult to measure, and that's indeed why they aren't often measured. Also, the measures may not be perfect - no measurement is. But making such measurements is possible, and can be useful in certain circumstances.



I think it's impossible to measure the effect of using a certain pattern on maintanibility or reusability. The problem is that you cannot isolate design elements and measure their individual effect on maintainibility/reusability. To go back to my example of a Civil Engineering, the strengths of individual materials used in construction of a tower are well-known. So, when a civil engineer has to design a tower, he calculates the stresses that will be experienced by the building and selects the materials that can withstand the stress. Software Engineers cannot do that. Saying that we should measure the software after software is built is a bit like saying that a civil engineer should build a tower first and then wait and see how many people can stand together on the tower. Not only is that dangerous but it's very unproductive, because once the tower collapses, the engineer will have to sort through the hundreds of differrent parts of the building and find those that failed. Also, it would be impossible to measure how strong each part is because you are testing the entire product not each element on it's own.

But, unfortunately, that is exactly what we do when we build software. We keep on piling code on top of code until the project becomes a monstrosity. Then we go in and "refactor" the code. If we could calculate how maintainable/reusable/efficient a particular design is going to be before we actually implement the code, then there will be no need to refactor the code.
 
Ellen Zhao
Ranch Hand
Posts: 581
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Jayesh Lalwani:
Parts of it like building electronic circuitry are based on pure science.


Strictly speaking, building electronic circuitry is the business of department of Elektrotechnik (Electrical Engineering in English?).

But, there's nothing like Software Science or Programming Science.


In the department of Kerninformatik(Core Computer Science) where I studied, we paid most attention to Software Science and/or Programming Science.

Formal methods and Deduction
Foundations of Computer Science
Foundations of Programming
Algorithmic Learning
Numerical Algorithms
...

Very difficult maths. Much more difficult than the math applied in general electrical physics. And it's tedious, so tedious that it's even very hard to memorize...
[ February 12, 2005: Message edited by: Ellen Zhao ]
 
Warren Dew
blacksmith
Posts: 1332
2
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Jayesh Lalwani:

I think it's impossible to measure the effect of using a certain pattern on maintanibility or reusability. The problem is that you cannot isolate design elements and measure their individual effect on maintainibility/reusability. To go back to my example of a Civil Engineering, the strengths of individual materials used in construction of a tower are well-known. So, when a civil engineer has to design a tower, he calculates the stresses that will be experienced by the building and selects the materials that can withstand the stress.

That's the easy stuff; that's like measuring how much memory and processing power your computer program will require, which can also be done in a relatively straightforward manner. Yes, there will be a margin for error, but civil engineering also uses a (large) safety factor.

Maintainability is more complex. How quickly will a reinforced concrete bridge degrade? It depends on a lot of things - not just the attributes of the materials used, but also construction techniques and, crucially, the conditions the structure is exposed to. These factors are sufficiently difficult to calculate in advance that building owners typically resort to periodic inspections, or even just waiting until something breaks to fix it, just like for software.

The difference is that civil engineering has been around a lot longer, so civil engineers have a lot more empirical data built up about how things behave. They know an asphalt roof can be expected to last 20 or so years on a house, not because they've calculated it, but because when they observe how long it takes before the roofs start leaking, that's the typical lifetime. That's the kind of data the software engineering industry should be collecting, too, so that we'll better understand the impact of the engineering decisions we make when writing the code.

But, unfortunately, that is exactly what we do when we build software. We keep on piling code on top of code until the project becomes a monstrosity. Then we go in and "refactor" the code.

I agree that's how most software projects are managed. I'm sure plenty of early buildings were built that way, too (Tower of Babel, anyone?). Even medieval cathedrals, and likely the Egyptian pyramids, were built based on expert engineering judgement rather than explicit stress calculations.

But just because current practices are bad, doesn't mean we can't use better ones if we really want to.

If we could calculate how maintainable/reusable/efficient a particular design is going to be before we actually implement the code, then there will be no need to refactor the code.

That's why I advocate collecting more data on how maintainable, reusable, and efficient various designs are - so we'll have better data when we're making future design decisions on new projects.
[ February 12, 2005: Message edited by: Warren Dew ]
 
(instanceof Sidekick)
Posts: 8791
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
A man who works with his hands is a laborer; a man who works with his
hands and his brain is a craftsman; but a man who works with his hands
and his brain and his heart is an artist.
-- Louis Nizer (1902-1994) English lawyer

I put my heart into my work (sometimes) but I just haven't seen that much source code hanging in museums.

I stick with craft.
 
Ranch Hand
Posts: 1907
1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I think programming or software building is more of art.Its history shows that there were many successful people without formal training in computer science(Computer Science is definitely bigger than Programming) but architect without formal training but designing houses? or some Civil engineering genius who never went to school but found some new way of designing multistory building/Dam? never.
So programming is not definitely a 100% engineering descipline.Main difference is basic material of building in traditional engineering sciences has been different than basic material of building software,thats program.You raze the wall of one room of big building,building does not come down.You uncomment/mess up with few lines of program in software ,and the whole thing does not work.So art is more essential than required in engineering sciences.
so programming = some engineering+some art+some vision.
My 2 Rs.
 
Warren Dew
blacksmith
Posts: 1332
2
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Arjun Shastry:

You raze the wall of one room of big building,building does not come down.

No?

http://archives.cnn.com/2000/US/07/13/manhattan.collapse.02/

"workers were trying to open a new doorway in a structural wall on the ground floor of the building and the wall caved in. This triggered the collapse of the building's entire back wall and all four floors."

Maybe civil engineers are just smarter about realizing that mucking with small pieces of a structure is likely to break the whole thing. (Maybe they aren't, always, as this article illustrates.)
[ February 13, 2005: Message edited by: Warren Dew ]
 
Arjun Shastry
Ranch Hand
Posts: 1907
1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I think it was old building.Atleast fifty years old.So it must be load bearing structure.In such cases walls take the load.Reinforced Concrete Cement Structure would not had collapsed as frame of beams and columns are constructed followed by brick walls.So if wall is razed,nothing (should) happen as weight of structure is completely taken by beams,passed on to columns and then to foundation.
From which material the walls of residential buildings in New York state made up of? Is it brick or wood? In Ca,TN I never saw brivk wall apartment.
[ February 13, 2005: Message edited by: Arjun Shastry ]
 
Ranch Hand
Posts: 1241
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Science is the application of order to chaos. Art is the application of chaos to order. Both on their own are sterile, and it is in the coming together of the two that things are achieved. Just about everything that people do has aspects of both order and chaos, and similarly most things we do comprise of at least some science and at least some art. Quite often the balance is skewed towards one or the other, but the science and the art is always there in what we do.

In programming there is most definitely art - programmers can look at a solution and see it as elegant. This elegance comes in part from a scientific point of view - efficiency, ease of use etc, but there is also an X factor that makes some code more attractive then others, and that factor is the art in the programme.

Another way of putting it - the art in programming is everything that "goto" isn't.
 
Helen Thomas
Ranch Hand
Posts: 1759
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Dave, that's a very good observation.

Take SQL - you can boil it down to maths(relational algebra) and you can describe and interact with the universe (or parts of it ) with SQL. But it requires different arts and sciences to be able to do so effectively.

I'm still looking for the math for design patterns - guess no one has written the book.

Christopher Alexander studied Mathematics and Architecture.
[ March 01, 2005: Message edited by: Helen Thomas ]
 
Helen Thomas
Ranch Hand
Posts: 1759
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
The perception of the whole or gestalt is probably the most difficult thing to communicate in systems development.

How much room should be given to fail is directly proportional to the amount of creativity input.

That is, highly creative projects are more likely to fail unless more share the same vision.

Systems Thinking , Systems Practise is a good book worth re-visiting. Unfortunately I chucked my copy out to a charity shop.

Food for thought : Really well-designed "gestaltic" sytems may not have waiting queues. Some systems create more problems than they solve.
e.g. The National Health Service - the mass production approach to health care appears to be on the wane , less waiting lists and hopefully less bugs.
[ March 01, 2005: Message edited by: Helen Thomas ]
 
Ellen Zhao
Ranch Hand
Posts: 581
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Dave Lenton:
Science is the application of order to chaos.
Dear Mr. Lenton I am so, so provoked.
In my humble opinion, science is the application of chaos to order. It describes the objective world. While art, as I had said, it's the reflection of human's intuition, be the image is skillfully presented or not. There are common principles for good art, but one cannot formalise art with formal logic. The object of art is "beauty". In the universe of art, people care only about "is it beautiful or not" but not other things. A program can look good and seemingly working, but if it's proven to be mathematically invalid, it has to be thrown away or modified.

In programming there is most definitely art
Sorry dear Mr. Lenton but I'm afraid in programming there is most definitely science, no matter how well the science therein is encapsulated into things like design patterns, enterprise architechtures...so that it's unseen to most programmers, but it's still _science_. The inventors/founders of modern programming: Alonzo Church and Alan Turing are both brightest mathematicans of 20th century. A great artist without going really far into highly abstract mathematics, would never establish a solid foundation for modern programming.

Another way of putting it - the art in programming is everything that "goto" isn't.
All programs, no matter what programming language they are in, can be mapped into 100% equivalent Turing program. What's for addressing in Turing program? Only _goto_ but nothing else. People don't see _goto_ in most high level programming languages because the compiler in the bottom takes the _goto_ job for programmers. Boilt down, programming is computation is science. The quality of a program/software project can be mathematically/formally examed and proved. Many researchers are on such business...

Here is a really good book by prof. Michael Sipser (MIT):
Introduction to the Theory of Computation
Among the books on theoretical computer science I've read, this book is the most readable/understandable. Highly recommend! On preface page XV, Mr. Mark Herschberg was mentioned as one of the acknowledgements.
[ March 01, 2005: Message edited by: Ellen Zhao ]

 
author
Posts: 14112
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
What difference does it make?
 
Ellen Zhao
Ranch Hand
Posts: 581
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Not so much difference would it make to _most_ programming tasks. Without knowing all those headache-causing stuff one can still be an excellent programmer. But that doesn't mean programming is not science, it's just a kind of science a little bit different from science like physics or chemistry, in which, one could essentially do nothing if not knowing the foundations. The original topic was discussing about whether programming is science or art, so that I was digging down to the bottom.
[ March 01, 2005: Message edited by: Ellen Zhao ]
 
Helen Thomas
Ranch Hand
Posts: 1759
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Ilja Preuss:
What difference does it make?



Not many would be able to share ,say, a mathematical vision and a direct application would hardly be likely other than in compilers and scientific applications.
[ March 01, 2005: Message edited by: Helen Thomas ]
 
Dave Lenton
Ranch Hand
Posts: 1241
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Ellen Zhao:

In my humble opinion, science is the application of chaos to order. It describes the objective world. While art, as I had said, it's the reflection of human's intuition, be the image is skillfully presented or not. There are common principles for good art, but one cannot formalise art with formal logic. The object of art is "beauty". In the universe of art, people care only about "is it beautiful or not" but not other things. A program can look good and seemingly working, but if it's proven to be mathematically invalid, it has to be thrown away or modified.


By saying that science is the application of order to chaos, what I meant was the way in which it alters our conception of the universe. Things that we don't understand appear chaotic to us - they don't appear to act in a way that follows rules or patterns, and seem most illogical to us. As science slowly reveals the hidden heart beat at the centre of the unknown thing, we come to view it in a different way - now it is something logical and ordered. In this way science acts to change our view of something from being chaotic to being ordered.

Art to me seems to be the opposite. Artists often take the mundane and ordinary (and this is the essence of order), and make something fantastic and beautiful out of it. Beauty, wonder and interest in something do not sit that well with the idea of a logical and ordered universe. The art brings a little flavour of chaos back to the ordered view point of the world, putting back a bit of awe and fantasy that science takes away from things when it explains them.

Again I'm not talking about chaos and order as fundamental forces, but more as the way we conceive of reality.


In programming there is most definitely art
Sorry dear Mr. Lenton but I'm afraid in programming there is most definitely science, no matter how well the science therein is encapsulated into things like design patterns, enterprise architechtures...so that it's unseen to most programmers, but it's still _science_. The inventors/founders of modern programming: Alonzo Church and Alan Turing are both brightest mathematicans of 20th century. A great artist without going really far into highly abstract mathematics, would never establish a solid foundation for modern programming.


I totally agree - within programming there is a lot of science. I was pointing out that there is art along side that science. Most things, as far as I can see, have a mixture of science and art. A lot of people see programming as being one of the things that isn't a mix, they see it as purely science... but I disagree - there's a bit of art hiding in there somewhere


All programs, no matter what programming language they are in, can be mapped into 100% equivalent Turing program. What's for addressing in Turing program? Only _goto_ but nothing else. People don't see _goto_ in most high level programming languages because the compiler in the bottom takes the _goto_ job for programmers. Boilt down, programming is computation is science. The quality of a program/software project can be mathematically/formally examed and proved. Many researchers are on such business...



I know, I know. Like a lot of programmers I went through university having the continuous idea "goto is bad, goto is bad" hammered into me. Now its ingrained at an almost instinctive level. It gives me the willies to see it in a programme, even though I know that my lovely loops and ifs are being changed into gotos at some point.

Gotos are a bit like sewers - we know they are used underneath the surface somewhere, but we don't like to smell them
[ March 02, 2005: Message edited by: Dave Lenton ]
 
Helen Thomas
Ranch Hand
Posts: 1759
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
In some respect programs are designed to fail just as in almost all manufactured products.

If programs / toys were made to work forever they'd never be superceded. So usually "good enough" is good enough. Can't say the same for art.
[ March 02, 2005: Message edited by: Helen Thomas ]
 
Well THAT's new! Comfort me, reliable tiny ad:
Smokeless wood heat with a rocket mass heater
https://woodheat.net
reply
    Bookmark Topic Watch Topic
  • New Topic