The Artima Developer Community
Sponsored Link

Weblogs Forum
Hidden Variables

68 replies on 5 pages. Most recent reply: Sep 11, 2006 5:28 AM by Miguel Montenegro

Welcome Guest
  Sign In

Go back to the topic listing  Back to Topic List Click to reply to this topic  Reply to this Topic Click to search messages in this forum  Search Forum Click for a threaded view of the topic  Threaded View   
Previous Topic   Next Topic
Flat View: This topic has 68 replies on 5 pages [ « | 1 2 3 4 5 | » ]
Isaac Gouy

Posts: 527
Nickname: igouy
Registered: Jul, 2003

phenomenology Posted: Jul 10, 2006 12:53 PM
Reply to this message Reply
Advertisement
> > The main thesis is that laws that we consider
> > fundamental may just be collective effects of action at
> > smaller scales. Hidden variables may just be cases where
> > reductionism fails.
>
> Well, let me clarify what I have already stated. It's
> possible that hidden variables might exist but they are
> not detectable and are not required to produce accurate
> predictions and therefore are not part of science (at this
> point in time.) In other words, they could exist but they
> are not part of our experience i.e. our 'reality'.

In other words, we are concerned with phenomenology not ontology.

"In our description of nature the purpose is not to disclose the real essence of the phenomena but only to track down, so far as possible, relations between the mainfold aspects of our experience." Niels Bohr

"As software developers, we too, need not aim to disclose the real essence of the phenomena. We can deal with the phenomena as we experience them, as they appear to us and to our customers and the users of our systems." Michael Jackson

http://www.amazon.com/gp/product/0201877120/103-2665347-4015844?v=glance&n=283155

Bruce Eckel

Posts: 874
Nickname: beckel
Registered: Jun, 2003

Re: Hidden Variables Posted: Jul 10, 2006 1:05 PM
Reply to this message Reply
> http://alistair.cockburn.us/index.php/Characterizing_people
> _as_non-linear,_first-order_components_in_software_developm
> ent

This is an excellent article.

Isaac Gouy

Posts: 527
Nickname: igouy
Registered: Jul, 2003

A mile high looking down Posted: Jul 10, 2006 3:07 PM
Reply to this message Reply
Bruce Eckel wrote
The hardest thing to admit, I think, is that software development is the complete opposite of an assembly line, but is far more of an artistic endeavor like writing a novel or performing a play.

This is where I become somewhat boorish - afaict there are very different kinds of "software development" and there are very different kinds of "assembly line".

Geoff Sobering

Posts: 13
Nickname: geoffs
Registered: Apr, 2003

Re: Hidden Variables Posted: Jul 10, 2006 5:57 PM
Reply to this message Reply
> ... our professor of software engineering would often
> jokingly say: “Don’t expect any big advances in
> software engineering as long as us, the computer
> scientists are doing the research. We will see
> some breakthrough once we get more anthropologists
> and sociologists interested in the field.”

"...my chosen profession is that of a methodologist. That means that I study how people produce software..."

http://alistair.cockburn.us/index.php/Software_development_as_a_cooperative_game

It's been too long since I last visited Alistair's writings. Good stuff there.

Cheers,

Geoff S.

Achilleas Margaritis

Posts: 674
Nickname: achilleas
Registered: Feb, 2005

Re: Hidden Variables Posted: Jul 11, 2006 5:11 AM
Reply to this message Reply
> The problem is that there is an immense amount of
> reproducable empirical data that shows that there are no
> hidden variables. The computer you are using works based
> on quatum mechanics. Quantum mechanics can predict
> results with extreme accuracy. More so that classical
> mechanics or relativistic effects from what I am led to
> believe. I find that more convincing than a layman's
> hunch.

My computer does not work using or based on quantum mechanics, from what I know, and quantum mechanics can not predict anything but just propabilities. Since the jump from the micro to the macro world has not been made yet by science, please allow a little room for another level of physical reality existing beyond what we have seen so far.

> I guess you could call it that but that's not really what
> Einstein meant. He meant that there are extra properties
> which (if known) would eliminate the uncertanity and make
> results purely deterministic. The existence of extra
> spatial dimensions might explain how information can
> travel faster than the speed of light but doesn't remove
> any of the randomness from quantum mechanics.

But how are we not sure that the 'randomness' is not the result of the extra spatial dimensions?

James Watson

Posts: 2024
Nickname: watson
Registered: Sep, 2005

Re: Hidden Variables Posted: Jul 11, 2006 9:47 AM
Reply to this message Reply
> > The problem is that there is an immense amount of
> > reproducable empirical data that shows that there are
> no
> > hidden variables. The computer you are using works
> based
> > on quatum mechanics. Quantum mechanics can predict
> > results with extreme accuracy. More so that classical
> > mechanics or relativistic effects from what I am led to
> > believe. I find that more convincing than a layman's
> > hunch.
>
> My computer does not work using or based on quantum
> mechanics,

Does your computer not contain trasnistors? I suspect it contains many millions. Transistors are a direct result of the study of quantum mechanics.

> > I guess you could call it that but that's not really
> what
> > Einstein meant. He meant that there are extra
> properties
> > which (if known) would eliminate the uncertanity and
> make
> > results purely deterministic. The existence of extra
> > spatial dimensions might explain how information can
> > travel faster than the speed of light but doesn't
> remove
> > any of the randomness from quantum mechanics.
>
> But how are we not sure that the 'randomness' is not the
> result of the extra spatial dimensions?

How are we not sure it's not the result of a giant chicken at the center of the universe? Do you wish to propose a mechanism through which extra dimensions might cause randomness?

James Watson

Posts: 2024
Nickname: watson
Registered: Sep, 2005

Re: Hidden Variables Posted: Jul 11, 2006 9:57 AM
Reply to this message Reply
> My computer does not work using or based on quantum
> mechanics, from what I know, and quantum mechanics can not
> predict anything but just propabilities. Since the jump
> from the micro to the macro world has not been made yet by
> science, please allow a little room for another level of
> physical reality existing beyond what we have seen so
> far.

I really don't know what you mean here. One of the great discoveries of Stephen Hawking was that black holes emit energy and the mechanism for this depends absolutely on quantum mechanics. Nuclear weapons are also a result of quantum mechanics. The way we understand the sun depends on quantum mechanics. Quntum mechanics is by far the most important advancement of science in the 20th century.

You don't really seem to have a good feel for the basics of quantum theory. A really good book for this is call "Quantum, A Guide for the Perplexed". I studied quatnum mechanics breifly but this book was what really cleared up the basic concepts for me.

One of the things that is very hard to accept for most people is that quantum mechanics is not just a trick and that our natural understanding of how the universe works is not complete.

Geoff Sobering

Posts: 13
Nickname: geoffs
Registered: Apr, 2003

Re: Hidden Variables Posted: Jul 11, 2006 10:28 AM
Reply to this message Reply
I'd suggest taking the (meta) physics component of this discussion over to sci.physics; this kind of thing seems to be their "bread and butter"... ;-)

http://groups.google.com/group/sci.physics

Cheers,

Geoff S.

James Watson

Posts: 2024
Nickname: watson
Registered: Sep, 2005

Re: Hidden Variables Posted: Jul 11, 2006 10:40 AM
Reply to this message Reply
> I'd suggest taking the (meta) physics component of this
> discussion over to sci.physics; this kind of thing seems
> to be their "bread and butter"... ;-)

Well it appears to be a bunch of kooks posting and then others replying to them about how crazy and stupid they are.

haluk guner

Posts: 4
Nickname: hag
Registered: Nov, 2005

Re: Hidden Variables Posted: Jul 11, 2006 12:18 PM
Reply to this message Reply
I think we are missing the point completely. When you look at the big picture, the real problem is that our so called software engineering discipline is not a proper engineering discipline. More specifically, we don't have a proper component model for software.

As stated by "Reuse-Based Software Engineering" book ( Mili et al), due to repeating functionality, up to %85 of a typical application can be built by reusable components (%15 generic + %65 domain specific). Which simply means that if we had a proper component model, most of our applications would be built, not developed, by the assembly of pre-built software components.

Tools and technologies that we are using today are still too low level that they put too much responsibility on developers in terms of learned skills, talent, experience and training in order to produce reliable systems in predictable time scales. Instead of raising the abstraction level of the tools and the technologies that we use, we are still trying to increase the (skill) level of developers with numerous methodologies. And this, in my opinion, is the wrong direction to take. I will try to make myself clear with the following example.

If we pick the assembly language as the tool and ask the entire developer population of the world to produce a non-trivial application, I think only 5 or 6 percent of them will be able to produce a decent enough usable system. This shouldn't come as a surprise since it requires so much concentration, talent and skill to get it right with such a low level tool. But, if we pick a much higher level tool instead, Smalltalk, Ruby or Python for instance, this percentage will be much higher; probably more than 60 or 70 percent. (Please note that these figures are rough guestimates in order to make my point, nothing to be taken seriously). By raising the level of technology we can get rid of the differences among developers and become less demanding on the level of skill that we expect from them. It should be clear from this example that by raising the level of the tool, we gain more ground and achieve much higher levels of productivity.

Which direction would you take? Would you stay with the assembly language and try to increase the level of developers by methodologies and training, instead of creating tools that provide higher levels of abstraction? No matter how agile or extreme our methodology is, there is no way we can achieve the same results that we could obtain with higher level technologies.

Again, if we take these %60-70 Smalltalk, Ruby or Python applications and look for reliable, flexible and maintainable applications that are build out of independent, reusable, black-box components, the percentage will not be more than 5 or 6 percent. The reason for that is even our latest or best technologies of today, do almost nothing to help the developers produce independent, reusable, replaceable, black-box components out of which we can assemble most of our systems.

That is why, instead of wasting time with the human factor, we should try to create higher level technologies that will enable developers produce higher quality proper software components regardless of their level of skill, experience and training. And speaking from experience (I am doing research on the subject for number years), this is not an impossible task. It is just that most of the brain power is concentrated on the wrong or less effective solution.

Michael Feathers

Posts: 448
Nickname: mfeathers
Registered: Jul, 2003

Re: Hidden Variables Posted: Jul 11, 2006 12:33 PM
Reply to this message Reply
> I think we are missing the point completely. When you look
> at the big picture, the real problem is that our so called
> software engineering discipline is not a proper
> engineering discipline. More specifically, we don't have a
> proper component model for software.
>
> As stated by "Reuse-Based Software Engineering" book (
> Mili et al), due to repeating functionality, up to %85 of
> a typical application can be built by reusable components
> (%15 generic + %65 domain specific). Which simply means
> that if we had a proper component model, most of our
> applications would be built, not developed, by the
> assembly of pre-built software components.
>
> Tools and technologies that we are using today are still
> too low level that they put too much responsibility on
> developers in terms of learned skills, talent, experience
> and training in order to produce reliable systems in
> predictable time scales. Instead of raising the
> abstraction level of the tools and the technologies that
> we use, we are still trying to increase the (skill) level
> of developers with numerous methodologies. And this, in my
> opinion, is the wrong direction to take. I will try to
> make myself clear with the following example.
>
> If we pick the assembly language as the tool and ask the
> entire developer population of the world to produce a
> non-trivial application, I think only 5 or 6 percent of
> them will be able to produce a decent enough usable
> system. This shouldn't come as a surprise since it
> requires so much concentration, talent and skill to get it
> right with such a low level tool. But, if we pick a much
> higher level tool instead, Smalltalk, Ruby or Python for
> instance, this percentage will be much higher; probably
> more than 60 or 70 percent. (Please note that these
> figures are rough guestimates in order to make my point,
> nothing to be taken seriously). By raising the level of
> technology we can get rid of the differences among
> developers and become less demanding on the level of skill
> that we expect from them. It should be clear from this
> example that by raising the level of the tool, we gain
> more ground and achieve much higher levels of
> productivity.
>
> Which direction would you take? Would you stay with the
> assembly language and try to increase the level of
> developers by methodologies and training, instead of
> creating tools that provide higher levels of abstraction?
> No matter how agile or extreme our methodology is, there
> is no way we can achieve the same results that we could
> obtain with higher level technologies.
>
> Again, if we take these %60-70 Smalltalk, Ruby or Python
> applications and look for reliable, flexible and
> maintainable applications that are build out of
> independent, reusable, black-box components, the
> percentage will not be more than 5 or 6 percent. The
> reason for that is even our latest or best technologies of
> today, do almost nothing to help the developers produce
> independent, reusable, replaceable, black-box components
> out of which we can assemble most of our systems.
>
> That is why, instead of wasting time with the human
> factor, we should try to create higher level technologies
> that will enable developers produce higher quality proper
> software components regardless of their level of skill,
> experience and training. And speaking from experience (I
> am doing research on the subject for number years), this
> is not an impossible task. It is just that most of the
> brain power is concentrated on the wrong or less effective
> solution.

IMHO, that doesn't make the human factors go away at all, it just scuttles them to another corner.

Re the componentization of software, I think there are economic and physical reasons why componentization will never be a panacea. And, we can't say that it hasn't been attempted; it's been attempted countless times.

Geoff Sobering

Posts: 13
Nickname: geoffs
Registered: Apr, 2003

Re: Hidden Variables Posted: Jul 11, 2006 12:39 PM
Reply to this message Reply
To try and get th e discussion back on the rails... ;-)

From Bruce's original post:
> And we certainly cannot admit that the road to success may be primarily in the realm of human
> interactions, and that successful projects will stack the odds in their favor by hiring the
> "best" team possible, where the meaning of "best" varies with far too many variables to control,
> and so can be quite different for different situations.

I have to admit that perhpas the most significant aspect of the "agile methodoliges", and the discourse that's risen up around them, is the empahasis on interpersonal (and team) interactions. I think it's significant that the first item on the Agile Manifesto is: "[we have come to value] Individuals and interactions over processes and tools".

After recognizing that the human-factors are an important (dominant?) issue in a project's success, an inevitable conclusion (IMO) is that the notion of "the one methodology to control them all" is intrisically fallacious. The agile guys said it pretty well: "[we value] Responding to change over following a plan".

If we take a page from the "Continuous Quality Improvement" and even the CMM (shudder...), then we realize the methodology end-game isn't "the one perfect process", but rather the ability to adjust/adapt the process to each project's specific instantaneous circumstances.

"A Methodology Per Project" describes this better than I ever could:
http://alistair.cockburn.us/index.php/Methodology_per_project

The "Manifesto for Agile Software Development" is at: http://www.agilemanifesto.org/

Cheers,

Geoff S.

Dino Octavian

Posts: 15
Nickname: dinoo33
Registered: Jul, 2006

Re: Hidden Variables Posted: Jul 11, 2006 2:29 PM
Reply to this message Reply
> And as long as we cling to these thoughts of
> determinism, we are blinded to potentially better
> approaches.

Determinism is an illusion because it assumes that the future and the past are the same. Acting on such grounds is delusional. It is backwards thinking: it worked in the past, therefore it will work in the future. This does nothing else but creates a negative feedback over the past - in reversed time arrow, ironically the same to a positive feedback in normal time arrow. In other words, our attempts to create a deterministic future is what creates the uncertainty.

The solution is to drop determinism entirely and find out at every moment what works and what doesn't.

Dino Octavian

Posts: 15
Nickname: dinoo33
Registered: Jul, 2006

Re: Hidden Variables Posted: Jul 11, 2006 3:24 PM
Reply to this message Reply
> ... More specifically, we don't have a
> proper component model for software.

I found this idea first time in Schroedinger and Penrose book "What is Life? : With Mind and Matter" when they were analyzing genetics as a science. All human sciences are statistical. They are based on long sequences of repeatable experiences which obey the law of large numbers. And we can build statistics only on populations of equivalent objects (they can be interchanged without changing the system, just like molecules in a perfect gas). Individuality breaks the law of large numbers and prevents our understanding of things. Yes, our understanding is fundamentally statistical.

Genetics is one such domain were our understanding is crippled by individuality. Although a DNA chain contains billions of atoms, they are not equal, they cannot be interchanged randomly without changing the system. We (statistically) mapped the human genome and we (statistically) know that a certain gene does this or that, but we cannot "program" the DNA for a new species because we have no actual understanding of what the DNA is.

Programming is somewhat similar: in a program we cannot randomly interchange any two instructions without changing the system. Some changes will crash the program. Since Turing, we have a model for programs. But he also stated there is a limit to what we can do with that model (the turing halting problem, which is a continuation of Goedel's work on formal systems). G. Chaitin takes things even further and tells us exactly where that limit is. So we program computers, but programming is an art and cannot be automated for mass production because we don't know of any way to mass produce it. We're programming without knowing exactly how we're doing it.

Achilleas Margaritis

Posts: 674
Nickname: achilleas
Registered: Feb, 2005

Re: Hidden Variables Posted: Jul 12, 2006 4:10 AM
Reply to this message Reply
> Does your computer not contain trasnistors? I suspect it
> contains many millions. Transistors are a direct result
> of the study of quantum mechanics.

I thought transistors were a result of the science of electronics. Please show me a link where the study of quantum mechanics led to the invention of the transistor.

> How are we not sure it's not the result of a giant chicken
> at the center of the universe? Do you wish to propose a
> mechanism through which extra dimensions might cause
> randomness?

Ok, we don't know what causes the randomness, I agree with that. But exactly because of that, we can not say that randomness has no explanation and that nature is random by itself.

We simply do not know what causes randomness.

Flat View: This topic has 68 replies on 5 pages [ « | 1  2  3  4  5 | » ]
Topic: Hidden Variables Previous Topic   Next Topic Topic: Online Programming Lanugage Discussions


Sponsored Links



Google
  Web Artima.com   

Copyright © 1996-2014 Artima, Inc. All Rights Reserved. - Privacy Policy - Terms of Use - Advertise with Us