it's called a heirarchicial DBMS, and they've long been known to be inferior tools.
Agreed.
People try to use those descriptive properties to generate applications which use XML stored on disk to store data within the stored file, but that's a waste. It's like trying to turn a car into a boat when you could just easily go obtain a boat. Sure, you can do it, but it's inefficient, error prone, and doesn't actually have any pros associated with it in 99.999999999% of all cases.
I still can't quite get your point. OpenDocument is XML on disk which described data within a stored file. This kind of thing is invaluable for situations like document archives or auditing information - and there are major benefits to XML as a format in itself. Also, XML is not error prone - it is designed to be easily retrievable and validatable.
That's fair enough; your comments elsewhere had lead me to believe you were more critical of the technique as a whole.
No, not at all... I have worked in the past with MD people and seen some fantastic work done. My only concern with this particular project is the way it is being publicised - the idea that it is really simulating a virus accurately is a bit too much for me; it seems more like a 'look what we can do' sort of thing rather than good science. When I was doing molecular simulation researchers were still struggling to model things accurately at far smaller scale - even things like relatively dilute solutions of metal ions proved a problem. I can't believe things have changed that much in a few years.
In other words, it's a transfer medium to translate the plain-text data to an actual office document, nothing more.
Well I accept that XML in itself is not a database engine, but it is more that just a transfer medium. It is the format of the plain text data.
XML has nothing to do with storing data. An XML file is not a "storage tool"
You are getting two things very mixed up. Not actually being a storage mechanism does not mean that it has nothing to do with storing data.
Would you say that a Linux Filesystem is not a storage tool? After all, the Ext3 file system (for example) is just a way of labelling information; it doesn't actually store data - the disc controller does that.
XML is a good format in which some data can be stored. This means, obviously, that it has something to do with storing data, and is vastly more that just a column delimiter.
No; XML was designed to be a general extensible markup for textual information. There was no intention to limit its use to data exchange.
XML/XSLT is more work than it is worth because it is forcing the squre block into the round hole with a hammer.
A strange analogy, as XML is general purpose. It is neither <round> or <square> it is anything. Usefully, it is validatable, so if you typed <squre> this could be checked:)
XSLT is for converting somebody else's XML into the XML your application wants to consume.
Or updating your legacy XML to a new format.
If you have a limited number of users of your raw data, you can just as easily talk to them and give them a simple CSV or TSV file and move on with live.
Until a user then comes up with the requirement for an additional column, which you then can't insert without breaking the existing format. In that case, you can't move on with life until you have updated the data handling process for those users. XML is designed to handle just this situation.
XML is not for "storing data". I can't believe people still find that confusing in this day and age. XML is for describing data.
Wrong. XML is a combination of metadata and data. It is an excellent way of storing hierarchical data. If XML is not for storing data, then why is the OpenDocument format XML? Is that not "storing data"?
It's little more than a loosely built, glorified file format. It serves no more purpose to data than tabs seperating "columns" in a text file do.
This is probably why you misunderstand what XML is for - because you misunderstand XML. It is far more than this, and it was designed with some significant goals:
1). When data is stored in XML, it should be human readable, so as to prevent loss of legacy data through the use of binary formats.
2). XML should be very simple to parse via software (simplicity does not imply efficiency!).
3). XML should be easily extensible, so that you don't lose data or meaning when you have to add new types of information to a file or combine different file formats.
4). XML should be able to store data in international formats.
5). XML should be easy to validate in terms of format, and (optionally) easy to validate in terms of structure (e.g. DTDs, Schemas).
You say "of course it is going to be realistic", but isn't that the point?
Well, yes, but I was trying to counter statements of surprise that the results were indeed realistic. I am not critical of MD. My point is that one should not be surpised if the simulation is realistic - it is designed to be! That is a good thing - there would not be much point in running it otherwise.
Yes, you are right. The individual calculations were for femtosecond timesteps. However, significant changes in individual protein structures can take thousands of times longer that the length of time of this simulation.
Huh? How does that follow. We haven't modeled protein folding yet we can model car crashes fine. Just because we can't get a good answer at a very small scale does not mean that we can't get a good one at a larger scale with more loosly defined criteria. I mean even after we model a large protein folding we still won't necessarily understand what is happening at the quark level in that same simulation but it won't make the results any less valid.
This is true, but my point is that you have to be very careful (and modest) what you say when you announce you have 'simulated a virus'. (Especially when an article includes terms which are nonsense in the context, like 'reverse engineering'). What you have done is to simulate something which you are kludging together some approximations of atoms which you have already tuned in a way that will give you close to the right answer for this kind of information.
To show how crude this is - we haven't even yet got a truly accurate model for the salt water surrounding the virus - or even of water itself!
In order to get the more "trustable" simulations to produce something in the ballpark of remotely representing reality, you have to know "the answer" before you do the simulation and then teach the model to reproduce that "answer"... then you can write a paper and show that you're model "get's the answer" - and that's about the limit of "insight" that's often gained from these sort of simulations.
You are, of course, absolutely right. Things haven't changed since I started to do this kind a long time (20 years) ago. However, you can gain some sort of insights, as you can find out which interactions (even thought they are simplified) can matter in the real world. By trying to simulate the real world, you can find out more about it, even if you aren't able to make many predictions.
By the way, this study at least didn't use long range electrostatic cutoffs; they use a (fairly common, now) technique that allows calculation of full electrostatics of a system in N log N time as long as it is periodic.
So save me looking this up, could you let me know what this is? When I was doing molecular simulation, the issue of long-range electrostatic interactions was a major one. I would be interested to know how things have advanced (though my systems were not periodic, so it might not apply).
No, a scientist; and one who has worked in this area
Parameters are developed to reproduce very basic and general properties of molecules. Nothing is changed to go from one system to the next. So results that are reached are indeed unique and interesting and were certainly not built in to the system prior.
Nonsense. There are a range of parameter sets you use depending on the simulation you want to perform. For example, there are a wide range of models that are used for water alone! (such as SPC, TIP4 etc.) Each gives different results depending on the type of simulation, and things like the scale you are operating at. Then there are the different parameter sets you can choose to represent the protein surfaces.
If you want to do a large-scale model of a virus in water, you pick the parameter sets that you already know from similar simulations (large protein clusters in water etc.) that will give good results. So, of course it is going to be realistic.
The folding problem is the one of the hardest ones.
I agree.
So don't get all blustery about it not being a solved problem. Cancer hasn't been cured yet either.
My point was that if you can't deal with the folding of even a moderately complex single protein, then to say you have modelled an entire virus to any significant extent is to mislead.
Plenty of proteins have been modeled using QM/MM and had the results validated by empirical studies.
Sorry, but as far as I know there has not been a single successful simulation of protein folding. Simulation the general behaviour of a complete protein is not the same as completely understanding the interactions and structure.
Also, if you read the actual journal article (Structure, not Nature) you'll note that everything that was found in this study is consistent with experimental results.
Of course it is. I have worked in this field. When you do this kind of thing, you set up the parameters so that you already know that almost everything about it is going to be consistent with experimental results. There are other approaches - called 'ab initio' - in which you make no assumptions, but that involved a phenomenal amount of computing for very small systems. The point of this kind of thing is to set almost everthing to be realistic, with all sorts of approximations and fine-tunings, in order to test your assumptions about small parts of the model.
Evolution can only progress from point to point in the space of possible life forms in very small increments, when measured appropriately. (Earth evolution only, for instance, uses DNA, so Earth evolution can be measured fairly accurately by "DNA distance", but technically that's just a small part of the life-form space.)
This doesn't apply so simply to microbes - they can evolve very fast indeed and in big jumps by DNA exchange.
It is entirely possible that a "grey goo" machine, which would fulfill most definitions of life, can't be incrementally evolved to, yet it could still exist. It is also possible that it could be evolved to, but simply hasn't yet.
Not really. The point is that life has a common ancestry, so microbes would only have to evolve to digest a relatively narrow range of biological material. But it hasn't happened. The closest we have seen is 'flesh-eating' bacteria (Necrotizing fasciitis).
So let me get this straight the EU wants Microsoft to Document there propietary protocols because Microsoft does a great job of integrating all of there technologies, and making it easy for Admins and users alike to use them.
No, that is not why. The reason is that Microsoft has a sufficiently large proportion of desktop systems (usually through bundling arrangements with PC companies) that, if it keeps these proprietary protocols private, it can force sales of server systems above the level that might be sold if others could provide adequate alternatives.
This is the point - this is using a monopoly in one market (desktop OSes) to gain an advantage in another (server OSes).
There is nothing wrong in itself with having a total or near-monopoly in one market, if that is obtained by fair means. The legal problem is if you use that position to block competition in other markets.
Correct me if I'm wrong but couldn't Novell, or Red Hat, or Unix, Mac all try there hand at integrating all of there services and products just like Microsoft. The problem is Linux, Unix, and Mac cannot compete with Microsoft because they do not integrate there technologies as well.
Unix and Mac have always had extremely well integrated technologies. I work with companies that have Linux on both desktops and servers and they work wonderfully well together.
But that is not the point. This is a minority situation. These companies need to be able to integrate with Windows on the desktop to compete. The EU says that Microsoft's dominance of the desktop along with the fact that it keeps certain protocols private and undocumented prevents this.
I'm so sorry. I wasn't paying attention. I really shouldn't post here when I'm tired:)
It happens:)
Caring for his brother's offspring would confer an evolutionary advantage for most of his genes, but not all of them, since his brother's selfish personality traits get passed on instead of his kindness.
So regarding passing on genetic material, breeding is always preferrable I guess. Nature favours the selfish.
It really isn't that simple. This has been worked out in great mathematical detail, especially in the work of W. D. Hamilton. Nature favours the selfish gene, and not always passing on genetic material yourself. If you assist with the raising of offspring of more than one sibling (or the offspring of many, many cousins), or help your mother raise lots of offspring, the math gets very interesting.
I have told you there have been numerous studies that show the productivity gain from functional and dynamic languages. You simply have chosen to ignore those studies.
I have told you that there have been numerous studies over decades that disagree with that conclusion. You simply have chosen to ignore this. As I said, this is a highly complex issue. This debate was going on intensely in the 80s, with Pascal and C++ vs Smalltalk and LISP. Let me repeat - there was no winner! Both sides had good arguments. The same arguments are being put forward with C++ and Java vs Ruby and Python - nothing has changed, and there are no new arguments. There are major issues about maintainability and testability (both negative and positive) regarding static and dynamic languages; there have been unmaintainable coding disasters in both types of language, raising the issue of what developer productivity actually means for long-term projects. There have been reports showing how some constructs in some dynamic languages mean that unit tests can fail to provide coverage of certain things, and major functional tests are required (which typically take a lot longer in dynamic languages). There have been reports showing how many important refactorings simply can't be done in some dynamic languages. As I said, this is complicated, and simply quoting a few studies just doesn't do the debate justice.
I am happy that after a decade of fiddling XML files while the rest of us were busy coding you have finally caught up.
Firstly, XML has a significant and important place as part of coding. Secondly, it has been widely used by dynamic languages with some of the best implementations of parsers being in Smalltalk.
I predict in another decade you will no longer have to type everything three times as in Customer myCustomer = new Customer() and that's the shortcut. I have seen the same thing typed as much as five times depending on the complexity of the lookup and the injection.
Customer myCustomer = new Customer();
Is not a shortcut. It is a very well-established requirement of static typing. Why repeat the type here? Because of the possibility of inheritance....
Customer myCustomer = new CustomerSubclass(); Is also allowed.
So why define the type of 'myCustomer'? Why can't it be implied?
Because you then always know in the code what the type is, allowing type-safety and a whole range of refactorings.
If you prefer dynamic development, you don't need this, but if you want to use the full features of static typing, it is neither verbose nor repetetive.
You may have seen declarations of variables done three times, but it that is way out of date. Modern Java use means you don't have to type anything three times right now; you really, really don't. For example, I am currently developing using a Java ORM. I declare my field in one place in the class, and all the accessors, configuration and schema are maintained for me automatically. I use the DRY principle and get what I consider to be the major advantages of type safety.
If you want to keep bashing static languages based on how they were five years ago, fine (the fact that many developers still use them like that does not help, I admit).
I realise that keeping up to date with these developments is hard, but it is worth it! Things have moved on!
Well, there's quite a lot that's determined by genetics. Like a large part of your personality. This personality determines your outlook in life, and thus your susceptibility to certain memes. Things like ego and self-image probably play a role in this; that's clearly genetic (just look at your siblings, if any).
True, but I can't see how this relates to the argument.
Yes and they were and are still true. Smalltalk, lisp, ruby, pyton etc are all more productive then java.
Sorry to let you in on the secret.
Don't you read posts before replying? As I said, this has been a matter of debate for decades, and to say that the argument has been won one way or another is simplistic. But, I guess you don't mind being simplistic.
But hey don't mind me, go ahead and fiddle with your XML config files. No skin off of my teeth.
Why some developers have such a strange revulsion for XML files is beyond me. However, if you do suffer from this weird affliction, you may want to educate yourself and find out that modern Java APIs don't need them - the language has been extended to allow configuration information as annotations.
Somebody else on this topic has already linked to several studies that show how much programmer productivity increases with dynamic languages.
Yes, I have seen such studies. I have seen the same sort of studies 10 years ago. And 20 years ago. There is nothing new about them. To say that 'programmer productivity increases with dynamic languages' is a naive oversimplification of a very complex issue. There are major advantages to dynamic languages. There are also major advantages to statically typed languages. There is no simple answer as to which is more productive, and anyone who says there is has not researched the subject enough.
As a Java advocate I know you are neither interested in studies nor testimonials from anybody so I won't bother hunting the post down or giving a half a dozen links. Needless to say Google is your friend and show you lots of those.
Google is also our friend and will show how static typic is a real benefit for long-term maintainability, how it allows a wider range of refactorings of code and how it assists with group development.
I am not a Java advocate (I am also a Ruby and Smalltalk user), and even if I were, to suggest I am not interested in studies or testimonials is condescending. I am an advocate of a mature and practical approach to development. It is rather amusing to see developers putting forward the same old arguments about dynamic languages as if they had discovered something new:) You haven't. The same arguments were put forward for the use of LISP and Smalltalk 20 years ago.
If you want to do web apps in ruby in that style, you should try Nitro + Og.
Exactly! That is a far better approach. However, it is still missing out on the portable query language capability of other ORMs, but it is a far more modern and sensible approach than Rails.
Slashdot Mirror
it's called a heirarchicial DBMS, and they've long been known to be inferior tools.
Agreed.
People try to use those descriptive properties to generate applications which use XML stored on disk to store data within the stored file, but that's a waste. It's like trying to turn a car into a boat when you could just easily go obtain a boat. Sure, you can do it, but it's inefficient, error prone, and doesn't actually have any pros associated with it in 99.999999999% of all cases.
I still can't quite get your point. OpenDocument is XML on disk which described data within a stored file. This kind of thing is invaluable for situations like document archives or auditing information - and there are major benefits to XML as a format in itself. Also, XML is not error prone - it is designed to be easily retrievable and validatable.
That's fair enough; your comments elsewhere had lead me to believe you were more critical of the technique as a whole.
No, not at all... I have worked in the past with MD people and seen some fantastic work done. My only concern with this particular project is the way it is being publicised - the idea that it is really simulating a virus accurately is a bit too much for me; it seems more like a 'look what we can do' sort of thing rather than good science. When I was doing molecular simulation researchers were still struggling to model things accurately at far smaller scale - even things like relatively dilute solutions of metal ions proved a problem. I can't believe things have changed that much in a few years.
In other words, it's a transfer medium to translate the plain-text data to an actual office document, nothing more.
Well I accept that XML in itself is not a database engine, but it is more that just a transfer medium. It is the format of the plain text data.
XML has nothing to do with storing data. An XML file is not a "storage tool"
You are getting two things very mixed up. Not actually being a storage mechanism does not mean that it has nothing to do with storing data.
Would you say that a Linux Filesystem is not a storage tool? After all, the Ext3 file system (for example) is just a way of labelling information; it doesn't actually store data - the disc controller does that.
XML is a good format in which some data can be stored. This means, obviously, that it has something to do with storing data, and is vastly more that just a column delimiter.
XML is designed to be an exchange format.
:)
No; XML was designed to be a general extensible markup for textual information. There was no intention to limit its use to data exchange.
XML/XSLT is more work than it is worth because it is forcing the squre block into the round hole with a hammer.
A strange analogy, as XML is general purpose. It is neither <round> or <square> it is anything. Usefully, it is validatable, so if you typed <squre> this could be checked
XSLT is for converting somebody else's XML into the XML your application wants to consume.
Or updating your legacy XML to a new format.
If you have a limited number of users of your raw data, you can just as easily talk to them and give them a simple CSV or TSV file and move on with live.
Until a user then comes up with the requirement for an additional column, which you then can't insert without breaking the existing format. In that case, you can't move on with life until you have updated the data handling process for those users. XML is designed to handle just this situation.
XML is not for "storing data". I can't believe people still find that confusing in this day and age. XML is for describing data.
Wrong. XML is a combination of metadata and data. It is an excellent way of storing hierarchical data. If XML is not for storing data, then why is the OpenDocument format XML? Is that not "storing data"?
It's little more than a loosely built, glorified file format. It serves no more purpose to data than tabs seperating "columns" in a text file do.
This is probably why you misunderstand what XML is for - because you misunderstand XML. It is far more than this, and it was designed with some significant goals:
1). When data is stored in XML, it should be human readable, so as to prevent loss of legacy data through the use of binary formats.
2). XML should be very simple to parse via software (simplicity does not imply efficiency!).
3). XML should be easily extensible, so that you don't lose data or meaning when you have to add new types of information to a file or combine different file formats.
4). XML should be able to store data in international formats.
5). XML should be easy to validate in terms of format, and (optionally) easy to validate in terms of structure (e.g. DTDs, Schemas).
Somewhat more that column separation, perhaps?
You say "of course it is going to be realistic", but isn't that the point?
Well, yes, but I was trying to counter statements of surprise that the results were indeed realistic. I am not critical of MD. My point is that one should not be surpised if the simulation is realistic - it is designed to be! That is a good thing - there would not be much point in running it otherwise.
Yes, you are right. The individual calculations were for femtosecond timesteps. However, significant changes in individual protein structures can take thousands of times longer that the length of time of this simulation.
The folding process can take place over microseconds of time.
Exactly. So modelling a 'virus' (or rather a model of a virus) on a scale of mere femtoseconds isn't going to give you a clear idea of anything.
Huh? How does that follow. We haven't modeled protein folding yet we can model car crashes fine. Just because we can't get a good answer at a very small scale does not mean that we can't get a good one at a larger scale with more loosly defined criteria. I mean even after we model a large protein folding we still won't necessarily understand what is happening at the quark level in that same simulation but it won't make the results any less valid.
This is true, but my point is that you have to be very careful (and modest) what you say when you announce you have 'simulated a virus'. (Especially when an article includes terms which are nonsense in the context, like 'reverse engineering'). What you have done is to simulate something which you are kludging together some approximations of atoms which you have already tuned in a way that will give you close to the right answer for this kind of information.
To show how crude this is - we haven't even yet got a truly accurate model for the salt water surrounding the virus - or even of water itself!
In order to get the more "trustable" simulations to produce something in the ballpark of remotely representing reality, you have to know "the answer" before you do the simulation and then teach the model to reproduce that "answer"... then you can write a paper and show that you're model "get's the answer" - and that's about the limit of "insight" that's often gained from these sort of simulations.
You are, of course, absolutely right. Things haven't changed since I started to do this kind a long time (20 years) ago. However, you can gain some sort of insights, as you can find out which interactions (even thought they are simplified) can matter in the real world. By trying to simulate the real world, you can find out more about it, even if you aren't able to make many predictions.
By the way, this study at least didn't use long range electrostatic cutoffs; they use a (fairly common, now) technique that allows calculation of full electrostatics of a system in N log N time as long as it is periodic.
So save me looking this up, could you let me know what this is? When I was doing molecular simulation, the issue of long-range electrostatic interactions was a major one. I would be interested to know how things have advanced (though my systems were not periodic, so it might not apply).
You're an idiot.
No, a scientist; and one who has worked in this area
Parameters are developed to reproduce very basic and general properties of molecules. Nothing is changed to go from one system to the next. So results that are reached are indeed unique and interesting and were certainly not built in to the system prior.
Nonsense. There are a range of parameter sets you use depending on the simulation you want to perform. For example, there are a wide range of models that are used for water alone! (such as SPC, TIP4 etc.) Each gives different results depending on the type of simulation, and things like the scale you are operating at. Then there are the different parameter sets you can choose to represent the protein surfaces.
If you want to do a large-scale model of a virus in water, you pick the parameter sets that you already know from similar simulations (large protein clusters in water etc.) that will give good results. So, of course it is going to be realistic.
Folding is only one aspect of understanding proteins.
True, but if you can't understand that, you can truly say you have modelled a protein in detail.
The folding problem is the one of the hardest ones.
I agree.
So don't get all blustery about it not being a solved problem. Cancer hasn't been cured yet either.
My point was that if you can't deal with the folding of even a moderately complex single protein, then to say you have modelled an entire virus to any significant extent is to mislead.
Plenty of proteins have been modeled using QM/MM and had the results validated by empirical studies.
Sorry, but as far as I know there has not been a single successful simulation of protein folding. Simulation the general behaviour of a complete protein is not the same as completely understanding the interactions and structure.
Also, if you read the actual journal article (Structure, not Nature) you'll note that everything that was found in this study is consistent with experimental results.
Of course it is. I have worked in this field. When you do this kind of thing, you set up the parameters so that you already know that almost everything about it is going to be consistent with experimental results. There are other approaches - called 'ab initio' - in which you make no assumptions, but that involved a phenomenal amount of computing for very small systems. The point of this kind of thing is to set almost everthing to be realistic, with all sorts of approximations and fine-tunings, in order to test your assumptions about small parts of the model.
Evolution can only progress from point to point in the space of possible life forms in very small increments, when measured appropriately. (Earth evolution only, for instance, uses DNA, so Earth evolution can be measured fairly accurately by "DNA distance", but technically that's just a small part of the life-form space.)
This doesn't apply so simply to microbes - they can evolve very fast indeed and in big jumps by DNA exchange.
It is entirely possible that a "grey goo" machine, which would fulfill most definitions of life, can't be incrementally evolved to, yet it could still exist. It is also possible that it could be evolved to, but simply hasn't yet.
Not really. The point is that life has a common ancestry, so microbes would only have to evolve to digest a relatively narrow range of biological material. But it hasn't happened. The closest we have seen is 'flesh-eating' bacteria (Necrotizing fasciitis).
I went to an English "Public School" and am now over 40. I only know my weight in kilogrammes. We went metric a long time ago!
If only we had. There are miles to go yet before we have fully.....
So let me get this straight the EU wants Microsoft to Document there propietary protocols because Microsoft does a great job of integrating all of there technologies, and making it easy for Admins and users alike to use them.
No, that is not why. The reason is that Microsoft has a sufficiently large proportion of desktop systems (usually through bundling arrangements with PC companies) that, if it keeps these proprietary protocols private, it can force sales of server systems above the level that might be sold if others could provide adequate alternatives.
This is the point - this is using a monopoly in one market (desktop OSes) to gain an advantage in another (server OSes).
There is nothing wrong in itself with having a total or near-monopoly in one market, if that is obtained by fair means. The legal problem is if you use that position to block competition in other markets.
Correct me if I'm wrong but couldn't Novell, or Red Hat, or Unix, Mac all try there hand at integrating all of there services and products just like Microsoft. The problem is Linux, Unix, and Mac cannot compete with Microsoft because they do not integrate there technologies as well.
Unix and Mac have always had extremely well integrated technologies. I work with companies that have Linux on both desktops and servers and they work wonderfully well together.
But that is not the point. This is a minority situation. These companies need to be able to integrate with Windows on the desktop to compete. The EU says that Microsoft's dominance of the desktop along with the fact that it keeps certain protocols private and undocumented prevents this.
I'm so sorry. I wasn't paying attention. I really shouldn't post here when I'm tired :)
:)
It happens
Caring for his brother's offspring would confer an evolutionary advantage for most of his genes, but not all of them, since his brother's selfish personality traits get passed on instead of his kindness.
So regarding passing on genetic material, breeding is always preferrable I guess. Nature favours the selfish.
It really isn't that simple. This has been worked out in great mathematical detail, especially in the work of W. D. Hamilton. Nature favours the selfish gene, and not always passing on genetic material yourself. If you assist with the raising of offspring of more than one sibling (or the offspring of many, many cousins), or help your mother raise lots of offspring, the math gets very interesting.
I have told you there have been numerous studies that show the productivity gain from functional and dynamic languages. You simply have chosen to ignore those studies.
I have told you that there have been numerous studies over decades that disagree with that conclusion. You simply have chosen to ignore this. As I said, this is a highly complex issue. This debate was going on intensely in the 80s, with Pascal and C++ vs Smalltalk and LISP. Let me repeat - there was no winner! Both sides had good arguments. The same arguments are being put forward with C++ and Java vs Ruby and Python - nothing has changed, and there are no new arguments. There are major issues about maintainability and testability (both negative and positive) regarding static and dynamic languages; there have been unmaintainable coding disasters in both types of language, raising the issue of what developer productivity actually means for long-term projects. There have been reports showing how some constructs in some dynamic languages mean that unit tests can fail to provide coverage of certain things, and major functional tests are required (which typically take a lot longer in dynamic languages). There have been reports showing how many important refactorings simply can't be done in some dynamic languages. As I said, this is complicated, and simply quoting a few studies just doesn't do the debate justice.
I am happy that after a decade of fiddling XML files while the rest of us were busy coding you have finally caught up.
Firstly, XML has a significant and important place as part of coding. Secondly, it has been widely used by dynamic languages with some of the best implementations of parsers being in Smalltalk.
I predict in another decade you will no longer have to type everything three times as in Customer myCustomer = new Customer() and that's the shortcut. I have seen the same thing typed as much as five times depending on the complexity of the lookup and the injection.
Customer myCustomer = new Customer();
Is not a shortcut. It is a very well-established requirement of static typing. Why repeat the type here? Because of the possibility of inheritance....
Customer myCustomer = new CustomerSubclass(); Is also allowed.
So why define the type of 'myCustomer'? Why can't it be implied?
Because you then always know in the code what the type is, allowing type-safety and a whole range of refactorings.
If you prefer dynamic development, you don't need this, but if you want to use the full features of static typing, it is neither verbose nor repetetive.
You may have seen declarations of variables done three times, but it that is way out of date. Modern Java use means you don't have to type anything three times right now; you really, really don't. For example, I am currently developing using a Java ORM. I declare my field in one place in the class, and all the accessors, configuration and schema are maintained for me automatically. I use the DRY principle and get what I consider to be the major advantages of type safety.
If you want to keep bashing static languages based on how they were five years ago, fine (the fact that many developers still use them like that does not help, I admit).
I realise that keeping up to date with these developments is hard, but it is worth it! Things have moved on!
Well, there's quite a lot that's determined by genetics. Like a large part of your personality. This personality determines your outlook in life, and thus your susceptibility to certain memes. Things like ego and self-image probably play a role in this; that's clearly genetic (just look at your siblings, if any).
True, but I can't see how this relates to the argument.
Yes and they were and are still true. Smalltalk, lisp, ruby, pyton etc are all more productive then java.
Sorry to let you in on the secret.
Don't you read posts before replying? As I said, this has been a matter of debate for decades, and to say that the argument has been won one way or another is simplistic. But, I guess you don't mind being simplistic.
But hey don't mind me, go ahead and fiddle with your XML config files. No skin off of my teeth.
Why some developers have such a strange revulsion for XML files is beyond me. However, if you do suffer from this weird affliction, you may want to educate yourself and find out that modern Java APIs don't need them - the language has been extended to allow configuration information as annotations.
Somebody else on this topic has already linked to several studies that show how much programmer productivity increases with dynamic languages.
:) You haven't. The same arguments were put forward for the use of LISP and Smalltalk 20 years ago.
Yes, I have seen such studies. I have seen the same sort of studies 10 years ago. And 20 years ago. There is nothing new about them. To say that 'programmer productivity increases with dynamic languages' is a naive oversimplification of a very complex issue. There are major advantages to dynamic languages. There are also major advantages to statically typed languages. There is no simple answer as to which is more productive, and anyone who says there is has not researched the subject enough.
As a Java advocate I know you are neither interested in studies nor testimonials from anybody so I won't bother hunting the post down or giving a half a dozen links. Needless to say Google is your friend and show you lots of those.
Google is also our friend and will show how static typic is a real benefit for long-term maintainability, how it allows a wider range of refactorings of code and how it assists with group development.
I am not a Java advocate (I am also a Ruby and Smalltalk user), and even if I were, to suggest I am not interested in studies or testimonials is condescending. I am an advocate of a mature and practical approach to development. It is rather amusing to see developers putting forward the same old arguments about dynamic languages as if they had discovered something new
If you want to do web apps in ruby in that style, you should try Nitro + Og.
Exactly! That is a far better approach. However, it is still missing out on the portable query language capability of other ORMs, but it is a far more modern and sensible approach than Rails.