Uncontrolled vocabularies
"I try my best to make *all* my posts nice, even when I feel upset" -- Philippe Maquet
Uncontrolled vocabularies
"I try my best to make *all* my posts nice, even when I feel upset" -- Philippe Maquet
to quotes from books which often seem to be taken out of context.
Quotes always are taken out of context, by definition.
It seems to me that Mr. Bloch basically said that composition is in all ways superior to inheritance, the only disadvantage is that it precludes callback functionality.
Does that mean we get rid of inheritance now? It would simplify the language greatly.
Here I am going far out of competence, so hopefully somebody will correct me if I missed something.
First, we get rid of class-object distinction, since the only purpose of "instantiating" a class as an objects was to call super-class' constructor
we get rid of constructors. If we need to provide initialization, simple assignment will work. PL/1-like structures will do the job. Or are there other benefits of using constructors?
Hierarchy of interfaces is here, because through interfaces we are getting polymorphical calls.
There are mountains of problems we are freed ourselves from (default non-argument constructor and what will happen if superclass doesn't have one, constructors must not invoke overridable methods, etc etc etc.)
I am going to walk through an example to see if this will work, for not to be too theoretical... Ilja, you do not have to respond, if you think it's too theoretical and you are not interested, maybe somebody else will.
Why my posts are always so long, I have no idea...
The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus
Originally posted by Mapraputa Is:
[QB]Currently it is my impression that you *don't have* any experience.
"*don't have* any experience with OOP" - almost true, not any serious experience anyway, but with "*don't have* any experience" I would utterly disagree.
Part of misunderstanding seem stem from the fact that I had different kind of experience, and from this my alternative viewpoint OOP seem overcomplicated. Too much craft and too little science. I do not know what kind of experience you have other than OOP
I was surprised that you found it natural that fundamentals get revisioned.
What would you say if someone claimed he has better understanding of multiplication table every time he use it?
Well, relational normalization does only normalize data, so it seems to me. A big part of the OOP movement is the goal to also normalize behaviour. You are right that till now there isn't a mechanical way to do that, so we have to resort to patterns, refactorings and other design principles to guide us until we find one (if there even *is* one to find).
Relational model defines data as well as queries and updates on data. What is left out?
The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus
Originally posted by Mapraputa Is:
Map, I don't see why you keep quoting Bloch to make a point -- he doesn't agree with you at all.
This is an interesting theore... ah, sorry, interesting practical problem. Is "agreement" symmetric, i.e. does
M a B => B a M
Or its's Ok when M a B but B not a M?
In case of OOP (I should probably say more careful "Java version" of OOP) it stroke me that you get problems even if you do not do anything disadvised. And some problems got discovered later, so creators of Java API think they are doing perfectly good things, yet later their classes exhibit "erratic behavior", as Bloch put it, or, in other words are incorrect.
I worked with relational databases and had very satisfying experience, I've been missing SQL functionality ever since. Part of my rant against OOP stem from its apparent desire to do in a very complicated way what could be done with DB with far less efforts.
Particularly, because I tend to trust people who can explain things in such a clear and strict manner, rather than define fundamental concepts as "something with responsibilities".
The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus
Originally posted by Frank Carver:
I'm always a little wary of stepping into someone else's battle, but I have been thinking about this for the last few days and come to a few tentatitve thoughts. Feel free to laugh, shout, throw things, etc.
Ilja, you seem to be concentrating on programming as the actual process of development, which starts from nothing, and produces systems to meet and contiue to meet evolving requirements and environments. (I shall call this the "dynamic" view).
The dynamic view embraces the idea that producing software is about solving real world problems in a "good enough" way. The assumption is that any workable solution is better than no solution or a late solution.
Now, on to the subject at hand. While relational data modelling may be both theoretically and practically powerful, it does have one immense drawback. Changing such a model is not something that can be done lightly. If you've ever had to maintain and update a complex relational data model, and all the supporting code which assumes its structure you'll know what I mean.
The well-known "third normal form" is a great way to model a fully-understood problem. But if that problem changes, then huge swathes of table definitions and data will probably also need to change. If you decide to plan for that sort of change, you may decide to choose one of the less-specific higher normal forms, but these come with an overhead of less understandability and decreased performance.
The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus
Uncontrolled vocabularies
"I try my best to make *all* my posts nice, even when I feel upset" -- Philippe Maquet
Originally posted by Frank Carver:
Ilja wrote: I don't think that "good enough" really is good enough.
I guess this is an example of problems with communication. In purely grammatical terms, "good enough" is always good enough :-they are the same words! I didn't intend any slur, but somehow, "good enough" seems to have taken on aspects of an insult.
OTOH, *there are* some principles I like to apply rather stringently when doing OOP. http://www.objectmentor.com/resources/listArticles?key=topic&topic=Design%20Principles is a good resource in this regard.
Looks interesting. I shall spend some time studying that list.
The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus
Originally posted by David Weitzman:
OO code can be proven to work, and in fact they kept making me do these awful proofs by structural induction all summer long. OO need not be limited to experimentation and 'good enough'.
The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus
Originally posted by Frank Carver:
How do you, personally, know when to stop refactoring and move on to new functionality? Any answer other than "I never stop" (which I wouldn't believe anyway), shows you have some sort of "enough" for that "good".
How do you know when to stop writing unit tests for a piece of new functionality and deliver the code?
And so on.
The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus
Uncontrolled vocabularies
"I try my best to make *all* my posts nice, even when I feel upset" -- Philippe Maquet
Uncontrolled vocabularies
"I try my best to make *all* my posts nice, even when I feel upset" -- Philippe Maquet
Uncontrolled vocabularies
"I try my best to make *all* my posts nice, even when I feel upset" -- Philippe Maquet
Originally posted by Mapraputa Is:
[b]"Another problem of design patterns is that they allow for adaptability, but only if the need for certain adaptability was anticipated and the appropriate design patterns were applied in the design phase. This is referred to as "the preplanning problem."
Krzysztof Czarnecki, Ulrich W. Eisenecker, "Generative programming", p. 295
- I read this only today and was puzzled how it is different from all this hype that "patterns allow for changes" or something. Definitely some critical approach wouldn't hurt our industry
So in this sense Thomas Paul was very right when he said about up-front design.
Later the book shows that "the preplanning problem" doesn't exist in Smalltalk because of its wonderful reflection system.
Ilja blamed college education and said he expects students to actively look for better information. How many will, do you think? Top 10%? My impression is that OOP is really for top 10% of programmers; rest will only bring havoc...
The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus
Originally posted by Mapraputa Is:
My main problem with OOP languages is they apparently do not fit any of the categories above.
Their abstractions are too far from basic, not specific to any particular domain, and too abstract (=unnatural) to people's way of thinking.
The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus
I think he said that it is superior *in flexibility*. OTOH, if you don't need that flexibility, inheritance can in fact be superior to composition in complexity (don't know wether he mentions that).
It doesn't look so to me... There is a whole section about what to do if you decided to allow inheritance, definitely doesn't look "simpler" to me, not from developer's side anyway. For a client of the class it *is* easier to say "extends" and get all instance methods "for free" rather then to copy method definitions and insert method calls, [...]
but if we decided to get rid of inheritance, I suppose we could redefine "extends" clause semantics so it would do all this automatically.
There are such thing as CDATA section in XML, which according to specification must not be parsed and must be sent to an application basically "as is". CDATA are often used to hold JavaScripts, so we want our parser to perform a check whether JavaScript syntax is correct :roll:
That I am not sure how DOM parsers work should definitely help :roll:
No, the purpose of instantiating a class is to create an entity which represents a state. In a typical program, we have a fixed number of classes, but need a variable number of entities. Therefore we can't get rid of instantiating in some form.
A state of what? Class? Why variables cannot represent it?
And why do we need a variable number of entities?
I don't know about PL/1 structures and it seems hard to find something on the net - can you provide a small example?
Just named combinations of other variables, which can be arrays or other structures. Finkel gives this definition:
"Structured types are built out of other types. Arrays, records, and pointers are structured types.
record
Third: character;
Fourth: integer;
Fifth : (Apple, Durian, Coconut, Sapodilla,
Mangosteen)
end;"
We can get rid of that, too - as all the dynamically typed languages show. You can resolve polymorphic method calls simply by matching method signatures.
Actually this was my initial idea, but then I though interfaces can serve as a level of indirectness, isolating from knowing concrete implementation. Instead of referring to methods by classes they belong to, we refer by interfaces, so implementations can vary independently. Not sure I understood you right, but it seems that "resolving polymorphic method calls simply by matching method signature" doesn't provide this effect.
For example, how do you resolve duplicated logic in queries/updates? (I am thinking of the type of logic as in your while-matches example here.)
What is "duplicated logic"? Ah, you mean if I have a query and I want to use its result in other queries?
The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus
Originally posted by Mapraputa Is:
IMO, the OO solution is very clean for this problem. It's certainly much harder in Java - but just because it *isn't* a fully OO language; blocks aren't objects, for example.
Not sure if this should be considered a part of a fully OOP language...
The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus
Originally posted by Frank Carver:
Well, when I am working on already well factored code, I stop when I don't see any more ways to improve it. I don't stop because I think it shouldn't be improved more, but because I don't know how to do it. Of course, possibly this is because it *is* in the best possible state, but how should I know? In fact, that is probably not the way to bet, anyway
So, you admit that you stop refactoring when you reach some personal limit.
I didn't really want to get into a definition match with this. My intended contrast was between the sort of practical approach which admits that sometimes you must stop before perfection in order to proceed, and the converse, that perfection is a more important end in itself.
Maybe it's just that I've seen too many projects repeatedly delayed by people fussing with models based on abstract principles rather than learning by doing.
That is a little bit more tricky - I have to think about it
If it helps, the stock answer from the XP folks seems to be "keep writing tests until fear turns to boredom". It's very subjective, but illustrates the point, I guess.
The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus
Associate Instructor - Hofstra University
Amazon Top 750 reviewer - Blog - Unresolved References - Book Review Blog
Associate Instructor - Hofstra University
Amazon Top 750 reviewer - Blog - Unresolved References - Book Review Blog
Uncontrolled vocabularies
"I try my best to make *all* my posts nice, even when I feel upset" -- Philippe Maquet
Uncontrolled vocabularies
"I try my best to make *all* my posts nice, even when I feel upset" -- Philippe Maquet
Originally posted by Thomas Paul:
Well, when I am working on already well factored code, I stop when I don't see any more ways to improve it.
Yikes! I don't want you working on my systems.
Managers have to worry about real life things like time and money that get in the way of producing little gems of code that programmers like to write. I write code that passes QA and is the best that I can produce given the restraints of time and budget.
OOP helps here because my code is much more likely to be maintainable if I use standard OOP techniques.
The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus
Uncontrolled vocabularies
"I try my best to make *all* my posts nice, even when I feel upset" -- Philippe Maquet
Uncontrolled vocabularies
"I try my best to make *all* my posts nice, even when I feel upset" -- Philippe Maquet
Originally posted by Thomas Paul:
I just wanted to comment on Date's article. I think that Date is looking for generalities where application dependent implementations are called for. The ELLIPSE - CIRCLE debate is interesting but purely academic and meaningless. Whether CIRCLE should inherit from ELLIPSE depends on the business requirements more than anything else. Do I actually need to implement a CIRCLE object? Do my business requirements say that all CIRCLE objects must be treated differently than ELLIPSE objects? (For example, every CIRCLE must be green and centered on the page.) If not, why even have a CIRCLE object? Isn't a CIRCLE simply an ELLIPSE that has two variables equal?
All this stuff is rather amusing but last I checked, we write applications for real users with real business requirements. Don't their requirements get factored into our application design? Or are we all just too advanced to worry about real-life implemetations?
The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus
Associate Instructor - Hofstra University
Amazon Top 750 reviewer - Blog - Unresolved References - Book Review Blog
Originally posted by Frank Carver:
[QB]Ilja wrote: (about knowing when to stop refactoring)Yes, but it is a limit I find in *me*, not in the code...
Really, that doesn't matter. From a philosophical point of view "the code" doesn't actually exist. It's just a bundle of characters. "the code" as a concept only exists in the understanding of the person working with it (which is why readability, unambiguity and clarity are so important).
Ilja wrote: (about knowing when to stop writing unit tests) Someone thinking that "good enough" software is sufficient probably doesn't fear bugs as much as I think he should.
I still feel we have a basic difference of opinion of what "good enough" means. You still seem to be using "good enough" to mean something like "not really good", or "partially good", or "good only in some aspects".
The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus
I have lots of code that I know I can improve. But it's already gone to QA and if I make a change now it will cost thousands of dollars to retest it. And for what? The code produces the results the users want, performs well, and is stable. Sure I could have written it better had I more time and more upfront knowledge about the changes that would be required as we moved along the development path. But the code is good enough. It does exactly what it is supposed to do and the users are happy. Can it be refactored to make it better? Absolutely. And my comments left in the code explain exactly how I would make it better if I had the time and money. Next time the code is worked on maybe we can squeeze those changes in.Originally posted by Ilja Preuss:
For me, "good enough" is implying that I can reach a state where I no longer have to think about improving the quality of the code - why should I do if it already is good enough?
It also seems to imply to me that you could say something like "the code would be even better if we did XYZ, but it is already 'good enough', so we don't have to do it". Probably sometimes I fall into this trap, but it isn't something I would advise.
Associate Instructor - Hofstra University
Amazon Top 750 reviewer - Blog - Unresolved References - Book Review Blog
Originally posted by Mapraputa Is:
[QB]Inner rant: "Experience considered harmful"
1. Experience is fragmentary. For example, you are talking that "it's easy to refactor" from POV of developer who probably doesn't create API's for broad public consumption. Joshua Bloch creates APIs for broad public consumption and I observe his notion of inheritance is different.
2. Experience can be misleading. We all have experience that the Sun rotates around the Earth, but...
3 It's unclear how much experience is enough. I did wrote a lot of small programs, but I guess it's not enough. How long should I experience it? How big the project should be?
4. Experience, being personal, makes is biased. We are talking about the mechanism, why do I need to experience consequences?
5. "Learning by experiencing" is dangerous. I
found it tremendously useful to get an idea of what language features are before actually using them. All my previous life I did otherwise and learnt "how it should be done" after the project was finished.
6. Experience helps to understand each other only if we have similar experience. Otherwise we can argue forever what is easier to maintain, OO program or RM.
7. Solid theory is free of this shortcomings. It encompasses different kinds of experiences and systematizes it, finds hidden regularities and thus simplifies routines, provides common language and common conceptual frame to discuss different kinds of experience...
The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus
Associate Instructor - Hofstra University
Amazon Top 750 reviewer - Blog - Unresolved References - Book Review Blog
Originally posted by Thomas Paul:
But the code is good enough.
The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus
Associate Instructor - Hofstra University
Amazon Top 750 reviewer - Blog - Unresolved References - Book Review Blog
In the renaissance, how big were the dinosaurs? Did you have tiny ads?
Gift giving made easy with the permaculture playing cards
https://coderanch.com/t/777758/Gift-giving-easy-permaculture-playing
|