If I created a class with a private attribute, in Ruby or Python, can I add a method in runtime to fetch that value? If I understood you correctly, you're speaking of altering classes in runtime.
Python doesn't have private elements, but yes, you can quite easily add a method to a class or object at runtime:
class SomeClass:
value = "Hello world"
def foobar(self):
print self.value
SomeClass.foobar = foobar
a = SomeClass() a.foobar()
Ruby does have private methods, but it too can add methods to classes at runtime:
class SomeClass
@@value = "Hello world" end
class SomeClass
def foobar
puts @@value
end end
a = SomeClass.new a.foobar
Ruby and Python have slightly different attitudes to classes, but the end result is the same.
If so, doesn't it break the "encapsulation" from OO?
Both Ruby and Python take the approach that if the user really wants to do something, then they should allow him or her to do it. So yes, thinking about it, you're correct in asserting that there's no strict enforcement of OO encapsulation.
But this is an unavoidable tradeoff. If classes are objects, and objects can be altered at runtime, then there isn't a way to enforce encapsulation without drawing a line between class and object, as both Java and C# do. Which method is best is up to the programmer.
I wouldn't class code signing as DRM. Code signing doesn't stop the user from using unsafe code if they really want to, whilst DRM is designed to restrict what the user can do.
Groupthink and incorrect data. The experiments in the article were conducted upon individuals, who were given accurate, impartial information and asked to extrapolate results. In such a situation, human intelligence works very well.
Democracy involves giving groups of people information of varying accuracy. People thus make their decisions based on what other people think, and upon incorrect and subjective data. Unsurprisingly, this works out less well.
Re:Dynamic typing
on
Beyond Java
·
· Score: 2, Interesting
Both languages can load classes dynamically - a good example would be Apache Derby which translates SQL queries into compiled java classes, which can then of course be jitted at some point.
Yeesss... It is possible to combine class loading and dynamic bytecode generation to achieve similar results. But this appears to me to be akin to using a sledgehammer to do a screwdriver's job.
Recently, I wanted to convert Pygame's event system into something more usable, by wrapping each event type in a python class. (Unfortunately, due to a lack of reflection in Pygame's C interface, I had to specify the methods in each class, myself).
def PygameEvent(name, methods):
def __init__(self, event):
for method in methods:
setattr(self, method, getattr(event, method))
return type(name, (), {'__init__' = __init__})
Given this four-line function, creating a new class is a one line job:
A ready-made wrapper for pygame.event.Event objects. I don't know of a fast way to do this in Java. Either I'd have to define a whole new class for each event type:
public class KeyDown extends Event {
private String unicode;
private int mod;
private char key;
public KeyDown(pygame.Event event)
{
unicode = event.getParameter("unicode");
mod = event.getParameter("mod");
key = event.getParameter("key");
}
public String getUnicode()
{
return unicode;
}
public int getMod()
{
return mod;
}
public char getKey()
{
return key;
} }
Or I'd have to devise some more complicated JIT compiling alternative, which would take more time than going through the long process of creating all of the classes myself.
This, of course, is a trivial example. But there are other times when dynamic typing and class generation opens up avenues of design that aren't available otherwise.
It's a problem with all statically typed languages. In a statically typed OO language, there's a limit to how object-like classes can be. An object can have it's values altered at runtime, but you cannot alter the values of a class, because that would invalidate type safety. Thus, there is a limit to how complete the object model can be in a statically typed language.
A dynamically typed language, such as Ruby or Python, has no such restriction. Just as you can create new objects at runtime, so too can you create new classes. This leads into the territory of metaclasses and dynamic class factories, which is beyond the scope of languages like Java or C#.
Re:Dynamic typing is idiotic
on
Beyond Java
·
· Score: 1
But the key to this is having even the smallest components be verifiably correct. And the only realistic way you can do this is by having each bit of the system have a contract between input and output. "If you give me this as the input, I'll give you that as the output." You build the entire system based on these contracts.
Static typing doesn't do this. Oh, it ensures the types match, but it does nothing more than this. In order to ensure the input and output are correct, you need preconditions and postconditions. Java doesn't explicitly support these, and I can't think of a reasonable way they could be implemented at compile time. Fortunately, unit testing and assertions can go some way to making up for this.
In a dynamic typed language, these contracts become a mess. The function could receive an input of any value, of any type! The only way to enforce contracts in that is to put type-checking code at the start of every function. So you get all the disadvantages of a staticly typed language and all the disadvantages of dynamic typing at the same time.
You seem to be a little confused. There wouldn't be any point in putting type-checking code at the start of functions in a strongly dynamic language, because the types would still be checked at runtime - which they are by default, anyway. The reason static typing is useful is because it happens at compile time. But it is of limited use. It only catches type errors, which is a very small subset of ensuring programming correctness.
Type errors, even in dynamic programming languages, are rare. I program in Python often, yet I can't recall the last time I came across a type error. Nor have I ever come across anyone who programs in a dynamic language that views type errors as a common problem. Case in point is the original poster you replied to. I believe he pointed out the same thing; that type errors simply aren't that big a problem.
The only way to ensure that all components of a system work together, is either to be extremely methodical and justify every line of your code with a mathematical proof (ala Z), or to unit test as much as humanly possible. I don't see the former as being practical in any large system, which leaves only the latter. And Java has no intrinsic unit testing advantage over Python.
Re:Dynamic typing
on
Beyond Java
·
· Score: 3, Interesting
I honestly prefer having types. I prefer people thinking ahead of time about what they are doing, rather than just using a generic object or variant type thing. It's like the databases we have at work where the identifiers are varchar but are for the most part filled with numbers.
That sounds more an example of weak dynamic typing, rather than strong dynamic typing, such as in Python or Ruby.
I think your whole argument could go the other way. That proponents of dynamic type checking probably having used anything else and just can't recognize the terribly costs that dynamic typing places on their system.
I'm a Java programmer professionally, so I use static typing all the time. However, I also doubt it's that beneficial. Static typing puts a limit on what you can do with a language. In an object orientated programming, it limits the OO model by having a solid distinction between classes and objects; classes are defined at compile time, objects at runtime. In a language such as Python or Ruby, classes are objects, so there is no such distinction. This in turn gives the programmer access to greater layers of abstraction, which can often be a very good thing.
Re:Dynamic typing is idiotic
on
Beyond Java
·
· Score: 1
That is idiotic!
Yes, it is true that if you have an idiotic coder, he's going to make more mistakes in a dynamically typed language than a statically typed one. However, it's generally not a good idea to hire idiots anyway. Yes, dynamic typing gives the programmer more rope to hang himself, but an intelligent programmer will make use of that extra length in ways other than creating a noose.
The answer is to not abandon good programming language design, but rather to come up with toolkits or designers that help automatically generate the right code
Code generation has it's limits, and only goes part way to making up for the disadvantages of static typing. Personally, I prefer a language that is flexible enough not to require code generation. But that's merely my opinion.
I don't understand as a developer what dynamic typing does to help a language, and what real world advantages it offers the developer.
Dynamic typing allows for classes and functions to be created and altered on the fly. This opens the way to various metaprogramming techniques, which can be extremely useful at cutting down on repetition that can't be solved through static methods or inheritance.
For instance, I recently wanted to integrate Pygame's event objects into a more general event handling system. In Java, I'd have to create define a new class, plus getter and setter methods, for each event type. In Python, I can create a class factory function that can dynamically generate the new classes for me dependant on a small set of arguments I give it. So instead of needing 15 class files, I can achieve the same result in 15 lines.
The point is: When theory A contradicts theory B, this rarely makes the adherents of either side change their views. They are not going to say, "Oh, some person in another field of science thinks I'm wrong. Better pack it in then, I reckon." No, they are more likely to say, "Well, really either of us could be mistaken. So I think he's the wrong one."
That's what evidence is for. The theory of relativity and the theory of luminiferous ether contradict each other. Relativity states that light in a vacuum moves at a constant speed regardless of the motion of the observer. Ether theory states that light travels at a constant speed relative to an all pervading 'ether'. The Michelson-Morley experiment is very strong evidence that ether theory is wrong, which is why that theory has fallen into the wastebin of history, and relativity has survived to this day.
With regards to the geological age of the earth debate, there obviously wasn't compelling evidence to prove either theory wrong up until radioactivity was discovered, and this evidence showed that people like Lord Kelvin were incorrect in their theories on how old the Earth was.
The problem is that some hypotheses are more valid than others. The hypothesis that a giant, invisible monkey lives inside Jupiter is considerably less useful, and less scientific, than the theory that photons are particles that always travel at a constant speed, regardless of the motion of the observer. The former makes no predictions, and cannot be disproved. The latter makes a great number of predictions, and can be trivially disproved.
If some hypotheses hold more weight than others, then by implication, some ways of thinking are more valid than others. If a particular way of thinking leads a person to be correct more often than another person who has a different way of thinking, whose method of thinking would be preferable? The scientific method is a way of thinking that, amongst other things, has been more successful than any other in keeping humans alive. This rates it pretty highly in my book.
As to being "a ton of science that points to an intelligent creator", it rather depends on what you mean. An omnipotent creator is not scientific, so I presume you're talking about some manner of limited intelligence of exterrestrial origin being responsible for creating life upon this world. Whilst this may very well be the case, there's considerably more evidence that life evolved over billions of years.
The comment "ID is not science" is such a dishonest statement.
The theory of evolution can be disproved by observational evidence. For instance, if all the radiological studies on Earth showed that no rock was over 4000 years old, and that all telescopes showed that no star was further than 4000 light years away, then we could safely conclude that evolution is not a valid theory, because 4000 years does not give enough time for all observed living creatures to have evolved.
If ID is science, then it must be also disprovable by observational evidence. Please provide an example of evidence that could disprove the validity of ID.
If you cannot believe that a complex Universe could not exist without a creator, why do you believe an even more complex God does not Himself need a creator?
I feel comfortable saying there's not much difference in supporting evolution compared to supporting a creation belief, from a proof stand point. When it comes down to it, it's where you're putting your faith. Both topics require quite a bit of it. People get all pissy when I say that, but it's true.
There's a large difference. Scientists postulate theories, which they then try to prove wrong. The longer a theory survives, the more popular it becomes, and the more people try to dig up evidence to prove it wrong. If a theory is discovered to be wrong, it's thrown away. Theories like electromagnetism, relativity and evolution, have all been around a considerably long time, and this is why scientists have confidence in them. These theories are considered to be probably right, because no-one has yet managed to disprove them. But that's not to say that tomorrow, some evidence might crop up that would require rewriting all the textbooks.
Religions don't do this. You don't find priests proposing disprovable theories, and then setting about to disprove them. You don't find many religions who are continually rewriting their holy book to fit the evidence. Religions rely on abstract faith, whilst science revolves around methodical skepticism. There's a big difference between the two, and this should be immediately clear from what they produce. Religions and faith deal in the immaterial and supernatual, science deals with the natural and produces the technological.
If evolution is scientifically sound, can't you present sufficient evidence in the classroom to prove it?
No scientific theory can be proved. That include gravity, electromagnetism, atomic theory, relativity, quantum theory... Everything. Why should evolution be singled out?
Just because you can't disprove something, doesn't mean you have to believe in it, or consider that it's existance may be a possibility. I can't disprove that there isn't a giant monkey hiding in the centre of Jupiter, but just because I can't disprove it, doesn't mean that I can't dismiss such a belief out of hand.
There is no clear idea as to what observation(s) could falsify the General Theory of Evolution.
Yes there are. If astronomers observed that every astrological body they could see was a mere 4000 light years away from us, then that would be some pretty damning evidence against evolution. If geologists radiologically dated every rock on earth to 4000 years old, that would be evidence against evolution. If there was no common DNA molecule, and every animal used their own unique system for blueprinting cellular growth, then that would be evidence against evolution. If the tectonic plates of the Earth spelt out "Made by God", then that would be pretty damning evidence.
I could go on for a very long time like this. Needless to say that there are millions of possible observations that could disprove evolution; that no-one's ever observed such things in nearly 150 years, tends to suggest that evolution might be a pretty strong theory. It's been around longer than relativity or quantum theory, and I'd wager it'll be around far longer still.
The theory of evolution comprises more than natural selection. I don't believe that there exists any empirical evidence for the origin of everything. It's great that we can see some propogation of beneficial traits, but where did it all begin? With a "big bang"? Really?!
The theory of evolution doesn't deal with events that occurred before the Earth was formed, or the stars in our galaxy ignited. That's what astronomy is for.
If you are a scientist, you must acknowledge the law of conservation of matter.
Maybe if the year were 1748, but science has moved on considerably since that time. Relativity and quantum theory do away with this antiquated idea.
Additionally, it's interesting that you mention other areas of science, which are soundly proven.
No area of science is "soundly proven". Scientific theories cannot be proved, only disproved.
The fact is that evolution flies in the face of the second law of thermodynamics, which makes it very much unlike any other accepted area of science.
This old chestnut? I'd wager this was disproven, dead and buried before either of us were even born. The second law of thermodynamics states only that the total amount of entropy in a closed system will never decrease. Earth is not a closed system. Entropy is not equivalent to disorder. The second law only deals with the total entropy; it says nothing about entropy being decreased in a localised area.
Not at all. When a survey contradicts one's own experience, it's natural to be skeptical. Especially when you consider how easy it is to bias the survey questionaire to provide the result of your choosing.
I'd like to see the questions they asked for the survey. It's all too easy to get the results you want with carefully worded questions. I can't think of anyone I know who believes in such nonsense, so I'm taking this with significantly large grain of salt.
Encryption and anonymity are two different problems, I'm afraid. You're correct in saying that encrypted links have relatively little overhead in terms of bandwidth, and computers are now fast enough to encrypt realtime data on the fly. Skype VoIP and Google messenger are encrypted by default, and many websites use https for their logins, so encryption is relatively widespread.
Anonymity is more problematic. In order to disguise where a signal originated from, you really need to route it through several intermediate hosts (or just one intermediate host that you trust implicitly), all of which adds latency and reduces bandwidth. Whilst the encryption problem was solved by powerful, public domain encryption algorithms and increasing CPU power, I suspect the anonymity problem will be solved by increases in bandwidth and routing algoritms.
Slashdot Mirror
Both Ruby and Python take the approach that if the user really wants to do something, then they should allow him or her to do it. So yes, thinking about it, you're correct in asserting that there's no strict enforcement of OO encapsulation.
But this is an unavoidable tradeoff. If classes are objects, and objects can be altered at runtime, then there isn't a way to enforce encapsulation without drawing a line between class and object, as both Java and C# do. Which method is best is up to the programmer.
I wouldn't class code signing as DRM. Code signing doesn't stop the user from using unsafe code if they really want to, whilst DRM is designed to restrict what the user can do.
Groupthink and incorrect data. The experiments in the article were conducted upon individuals, who were given accurate, impartial information and asked to extrapolate results. In such a situation, human intelligence works very well.
Democracy involves giving groups of people information of varying accuracy. People thus make their decisions based on what other people think, and upon incorrect and subjective data. Unsurprisingly, this works out less well.
Recently, I wanted to convert Pygame's event system into something more usable, by wrapping each event type in a python class. (Unfortunately, due to a lack of reflection in Pygame's C interface, I had to specify the methods in each class, myself).Given this four-line function, creating a new class is a one line job:A ready-made wrapper for pygame.event.Event objects. I don't know of a fast way to do this in Java. Either I'd have to define a whole new class for each event type:Or I'd have to devise some more complicated JIT compiling alternative, which would take more time than going through the long process of creating all of the classes myself.
This, of course, is a trivial example. But there are other times when dynamic typing and class generation opens up avenues of design that aren't available otherwise.
It's a problem with all statically typed languages. In a statically typed OO language, there's a limit to how object-like classes can be. An object can have it's values altered at runtime, but you cannot alter the values of a class, because that would invalidate type safety. Thus, there is a limit to how complete the object model can be in a statically typed language.
A dynamically typed language, such as Ruby or Python, has no such restriction. Just as you can create new objects at runtime, so too can you create new classes. This leads into the territory of metaclasses and dynamic class factories, which is beyond the scope of languages like Java or C#.
Static typing doesn't do this. Oh, it ensures the types match, but it does nothing more than this. In order to ensure the input and output are correct, you need preconditions and postconditions. Java doesn't explicitly support these, and I can't think of a reasonable way they could be implemented at compile time. Fortunately, unit testing and assertions can go some way to making up for this.
You seem to be a little confused. There wouldn't be any point in putting type-checking code at the start of functions in a strongly dynamic language, because the types would still be checked at runtime - which they are by default, anyway. The reason static typing is useful is because it happens at compile time. But it is of limited use. It only catches type errors, which is a very small subset of ensuring programming correctness.
Type errors, even in dynamic programming languages, are rare. I program in Python often, yet I can't recall the last time I came across a type error. Nor have I ever come across anyone who programs in a dynamic language that views type errors as a common problem. Case in point is the original poster you replied to. I believe he pointed out the same thing; that type errors simply aren't that big a problem.
The only way to ensure that all components of a system work together, is either to be extremely methodical and justify every line of your code with a mathematical proof (ala Z), or to unit test as much as humanly possible. I don't see the former as being practical in any large system, which leaves only the latter. And Java has no intrinsic unit testing advantage over Python.
That sounds more an example of weak dynamic typing, rather than strong dynamic typing, such as in Python or Ruby.
I'm a Java programmer professionally, so I use static typing all the time. However, I also doubt it's that beneficial. Static typing puts a limit on what you can do with a language. In an object orientated programming, it limits the OO model by having a solid distinction between classes and objects; classes are defined at compile time, objects at runtime. In a language such as Python or Ruby, classes are objects, so there is no such distinction. This in turn gives the programmer access to greater layers of abstraction, which can often be a very good thing.
Yes, it is true that if you have an idiotic coder, he's going to make more mistakes in a dynamically typed language than a statically typed one. However, it's generally not a good idea to hire idiots anyway. Yes, dynamic typing gives the programmer more rope to hang himself, but an intelligent programmer will make use of that extra length in ways other than creating a noose.
Code generation has it's limits, and only goes part way to making up for the disadvantages of static typing. Personally, I prefer a language that is flexible enough not to require code generation. But that's merely my opinion.
I like Lisp, but I've never really been too fond of CLOS. It just seems ugly :(
Python's generally faster than Ruby. And Groovy isn't really anymore ad-hoc than Ruby is, really.
Dynamic typing allows for classes and functions to be created and altered on the fly. This opens the way to various metaprogramming techniques, which can be extremely useful at cutting down on repetition that can't be solved through static methods or inheritance.
For instance, I recently wanted to integrate Pygame's event objects into a more general event handling system. In Java, I'd have to create define a new class, plus getter and setter methods, for each event type. In Python, I can create a class factory function that can dynamically generate the new classes for me dependant on a small set of arguments I give it. So instead of needing 15 class files, I can achieve the same result in 15 lines.
It was never about processing power. Unix commands are short because they're faster to type.
That's what evidence is for. The theory of relativity and the theory of luminiferous ether contradict each other. Relativity states that light in a vacuum moves at a constant speed regardless of the motion of the observer. Ether theory states that light travels at a constant speed relative to an all pervading 'ether'. The Michelson-Morley experiment is very strong evidence that ether theory is wrong, which is why that theory has fallen into the wastebin of history, and relativity has survived to this day.
With regards to the geological age of the earth debate, there obviously wasn't compelling evidence to prove either theory wrong up until radioactivity was discovered, and this evidence showed that people like Lord Kelvin were incorrect in their theories on how old the Earth was.
The problem is that some hypotheses are more valid than others. The hypothesis that a giant, invisible monkey lives inside Jupiter is considerably less useful, and less scientific, than the theory that photons are particles that always travel at a constant speed, regardless of the motion of the observer. The former makes no predictions, and cannot be disproved. The latter makes a great number of predictions, and can be trivially disproved.
If some hypotheses hold more weight than others, then by implication, some ways of thinking are more valid than others. If a particular way of thinking leads a person to be correct more often than another person who has a different way of thinking, whose method of thinking would be preferable? The scientific method is a way of thinking that, amongst other things, has been more successful than any other in keeping humans alive. This rates it pretty highly in my book.
As to being "a ton of science that points to an intelligent creator", it rather depends on what you mean. An omnipotent creator is not scientific, so I presume you're talking about some manner of limited intelligence of exterrestrial origin being responsible for creating life upon this world. Whilst this may very well be the case, there's considerably more evidence that life evolved over billions of years.
The theory of evolution can be disproved by observational evidence. For instance, if all the radiological studies on Earth showed that no rock was over 4000 years old, and that all telescopes showed that no star was further than 4000 light years away, then we could safely conclude that evolution is not a valid theory, because 4000 years does not give enough time for all observed living creatures to have evolved.
If ID is science, then it must be also disprovable by observational evidence. Please provide an example of evidence that could disprove the validity of ID.
If you cannot believe that a complex Universe could not exist without a creator, why do you believe an even more complex God does not Himself need a creator?
There's a large difference. Scientists postulate theories, which they then try to prove wrong. The longer a theory survives, the more popular it becomes, and the more people try to dig up evidence to prove it wrong. If a theory is discovered to be wrong, it's thrown away. Theories like electromagnetism, relativity and evolution, have all been around a considerably long time, and this is why scientists have confidence in them. These theories are considered to be probably right, because no-one has yet managed to disprove them. But that's not to say that tomorrow, some evidence might crop up that would require rewriting all the textbooks.
Religions don't do this. You don't find priests proposing disprovable theories, and then setting about to disprove them. You don't find many religions who are continually rewriting their holy book to fit the evidence. Religions rely on abstract faith, whilst science revolves around methodical skepticism. There's a big difference between the two, and this should be immediately clear from what they produce. Religions and faith deal in the immaterial and supernatual, science deals with the natural and produces the technological.
No scientific theory can be proved. That include gravity, electromagnetism, atomic theory, relativity, quantum theory... Everything. Why should evolution be singled out?
Just because you can't disprove something, doesn't mean you have to believe in it, or consider that it's existance may be a possibility. I can't disprove that there isn't a giant monkey hiding in the centre of Jupiter, but just because I can't disprove it, doesn't mean that I can't dismiss such a belief out of hand.
Yes there are. If astronomers observed that every astrological body they could see was a mere 4000 light years away from us, then that would be some pretty damning evidence against evolution. If geologists radiologically dated every rock on earth to 4000 years old, that would be evidence against evolution. If there was no common DNA molecule, and every animal used their own unique system for blueprinting cellular growth, then that would be evidence against evolution. If the tectonic plates of the Earth spelt out "Made by God", then that would be pretty damning evidence.
I could go on for a very long time like this. Needless to say that there are millions of possible observations that could disprove evolution; that no-one's ever observed such things in nearly 150 years, tends to suggest that evolution might be a pretty strong theory. It's been around longer than relativity or quantum theory, and I'd wager it'll be around far longer still.
The theory of evolution doesn't deal with events that occurred before the Earth was formed, or the stars in our galaxy ignited. That's what astronomy is for.
Maybe if the year were 1748, but science has moved on considerably since that time. Relativity and quantum theory do away with this antiquated idea.
No area of science is "soundly proven". Scientific theories cannot be proved, only disproved.
This old chestnut? I'd wager this was disproven, dead and buried before either of us were even born. The second law of thermodynamics states only that the total amount of entropy in a closed system will never decrease. Earth is not a closed system. Entropy is not equivalent to disorder. The second law only deals with the total entropy; it says nothing about entropy being decreased in a localised area.
Not at all. When a survey contradicts one's own experience, it's natural to be skeptical. Especially when you consider how easy it is to bias the survey questionaire to provide the result of your choosing.
An devilish demonstration of unscrupulous surveying!
I'd like to see the questions they asked for the survey. It's all too easy to get the results you want with carefully worded questions. I can't think of anyone I know who believes in such nonsense, so I'm taking this with significantly large grain of salt.
Encryption and anonymity are two different problems, I'm afraid. You're correct in saying that encrypted links have relatively little overhead in terms of bandwidth, and computers are now fast enough to encrypt realtime data on the fly. Skype VoIP and Google messenger are encrypted by default, and many websites use https for their logins, so encryption is relatively widespread.
Anonymity is more problematic. In order to disguise where a signal originated from, you really need to route it through several intermediate hosts (or just one intermediate host that you trust implicitly), all of which adds latency and reduces bandwidth. Whilst the encryption problem was solved by powerful, public domain encryption algorithms and increasing CPU power, I suspect the anonymity problem will be solved by increases in bandwidth and routing algoritms.