"Design patterns exist largely because of the major shortcomings of OOP languages. Many of them simply become irrelevant in other paradigms. It's not obvious how inheritance is a good thing in itself. Abstraction, encapsulation and modularity are not exclusive to OOP, but exist in most paradigms. Similarly, most paradigms have some form of polymorphism."
"The need for DesignPatterns should be considered a LanguageSmell"
http://c2.com/cgi/wiki?AreDesignPatternsMissingLanguageFeatures
*yawn*
You may just skip my messages & continue your work. Like most, no problem.
Mr Bronco Oostermeijer (the liker of previous message), I pitty you. What a frustrations you must have.
Rom. His mate in hate. LOL! :-)
The quality contentwise of these reactions compared to those on stackoverflow etc. (see the link sent in my first mail) and the lack of keen reactions of others gives one to think about the strengths and future chances of at least the openedge product branch of psc.
--
Kind regards,
Stefan Houtzager
Houtzager ICT consultancy & development
www.linkedin.com/in/stefanhoutzager
I really thought of writing a decent reply to this, but why waste the time and energy on something negative, while at the same time I can be productive and write good OO code using design patterns and common sense...
"Waste time"? Who is being negative?!! The criticism is meant as a call for improvements in the 4GL. I assume, am almost 100% sure that you don't want to dig deeper into the critics to understand them (or are you a marketeer with really deep knowledge of informatics? No.). That is ok, it would be time consuming. But again: just skip the message then. Don't pretend you know better, that it's a piece of cake for you with your "*yawn*" [for the record 20/9: two messages have been removed, in the one from LdF the text was no more than *yawn*]. Ditto for the likers of your message. I've experienced their shortcomings before. Patterns are tied to languages, the GoF was aware of that too. Maybe some of the patterns you use are the best solution in object-oriented oe as it is now, but would not be needed anymore with new language constructs. You could, clumsily, say that you "implement the design pattern" more elegantly by using the new construct. Don't ask me to make this clear for you, you can find things out for yourself if you are really interested. I'm not going to "waste my time", I have more interesting things to do.
And in common on OO: If even someone with the stature of Edsger Dijkstra has questionmarks on it's elegance it could be worth to find some things out.
--
Kind regards,
Stefan Houtzager
Houtzager ICT consultancy & development
www.linkedin.com/in/stefanhoutzager
I'm going to follow your advice to ignore your messages from now on. Have a great life, bye!
I am not sure the point you are trying to make here but Design Patterns are a valuable tool for communicating and understanding design strategies. They are not there to address short comings of OOP, but to enrich communication and problem solving. Think of them as a recipe book without quantities - they provide guidance on how to solve common problems, but leave the detail to the Designer.
Through use of a common vocabulary - the design patterns - time is saved and risk and ambiguity reduced.
I'm familiar with design patterns and oo (abl), they are valuable when you use oo abl. Agreed on that. I see them (as the GoF themselves and others) as dependent on the language used. They were written with smalltalk in mind iirc. For the rest see f.e. en.wikipedia.org/.../Software_design_pattern, the criticism chapter.
> They are not there to address short comings of OOP
Yes they are!
If - after reading this chapter - you are interested in more
watch f.e. www.infoq.com/.../Are-We-There-Yet-Rich-Hickey and
www.youtube.com/watch (uncle Bob aka robert C. Martin).
My point is that the 4GL could be improved with the functional paradigm. Microsoft is doing that with C# (see other recent messages of me in this communitygroup).
--
Kind regards,
Stefan Houtzager
Houtzager ICT consultancy & development
OK, so nothing to do with Design Patterns at all then!
"Only" with the 4GL as it is now. ;-)
jaxenter.com/foul-mouthed-developers-which-community-curses-most-108053.html
The winners in the positive sense are the users of a functional language. ;-)
My present of the day for the lovers of OO design patterns:
http://stackoverflow.com/questions/327955/does-functional-programming-replace-gof-design-patterns
with lots of pointers to other reading material.
My present of today on the subject of the (oo, gof) iterator design pattern (reference below, excerpt above).
G. WHY USE MAPPERS INSTEAD OF ITERATORS?
The major problem with iterators is that they are non-functional
functions--they depend upon an internal state and side-effects to
operate. It is very difficult to prove anything about functions with
state, and therefore such functions inhibit most compiler
optimizations. But the most damning criticism of iterators occurs in
the context of multitasking and parallel threads. When using parallel
threads, all side-effects must be protected by locks, in order to
ensure the consistency of interpretation of the contents of shared
objects with state. While most iterators in C++ are locally-defined
for a particular loop, and therefore not shared with any parallel
process, it is difficult for a compiler to prove this. As a result,
one is either left with an inefficient program, or a potentially
dangerous program, depending upon whether the compiler inserts locks
to be on the safe side, or leaves them out in the name of efficiency.
These problems do not arise with the higher-order mapping functions.
As we have shown, mapping functions can be completely functional
(i.e., they have no shared state or assignments), even for complex
iterations like those for comparing the fringes of non-isomorphic
trees. This means that an arbitrary number of mappers can
transparently access the same collections without interference--at
least so long as the collections are not updated. If the collections
are also read-only, or functional, then there is no possibility of
interference under any circumstances. Mappers create function closures
during their operation, and these temporary objects hold the "state"
of the iteration, much as iterator objects do in C++. The difference
is that these closure objects are created automatically during the
execution of the mapping functions, rather than having to be
explicitly created by the programmer, as in C++, and the
side-effect-free nature of mappers is obvious to a compiler based on a
cursory syntactic scan.
---------------------------
??
The problem with the iterator pattern is recognized by others also, solutions proposed are with generic programming in java (homepages.ecs.vuw.ac.nz/.../thesis.pdf).
web.cse.ohio-state.edu/.../02HPS.pdf (problem named, I have not looked at solutions).
In functional languages mappers are used. See f.e. www.braveclojure.com/.../
your thesis paper gets me "403 Permission Denied"
As for the problem with the iterator pattern, that's not what the article was about. It purported that mappers were superior if the collection was read-only vs iterators which were not if the collections were updated. An apples vs oranges comparison if ever there was one.
> your thesis paper gets me "403 Permission Denied"
Apparently you have to remove the ")." that are included with the URL when you click it.
The thesis seems to discuss some extension to Java to keep track of ownership for iterators.
I haven't read the pape yet, other than the introduction, but I notice that when the C++ Core Guidelines were presented at the recent CppCon, it too included generic features and new lint style utilities for checking ownership of pointers (including iterators).
For me it is about a problem with this pattern. For the writer of the article also if the title "Iterators: Signs of Weakness in Object-Oriented Languages" should cover the load. Still don't understand your point. In any case the read-only collection is read (only) with mappers, and the result is not written to the same collection / physical memory.
It's not apples to oranges. Allas, the problem is not easy to explain and solve (however? this piece is a good non-academic intro: https://www.fpcomplete.com/blog/2012/04/the-downfall-of-imperative-programming ). Here is another less academic piece about Project Lambda from oracle/java. "Hardware trends – the future is parallel", "We must learn to write software that parallelizes gracefully".
jcp.org/.../2011-01_JCP_EC_ProjectLambda.pdf
other academic pieces for those interested:
www.cs.ox.ac.uk/.../iterator.pdf
http://www.ccs.neu.edu/home/turon/thesis.pdf
some more less academic pieces:
julesjacobs.github.io/.../the-best-collections-library-design-2.html
etorreborre.blogspot.nl/.../essence-of-iterator-pattern.html
--
Kind regards,
Stefan Houtzager
Houtzager ICT consultancy & development
www.linkedin.com/in/stefanhoutzager
having written concurrent programs for my entire programming life, i don't see how most programmers will be able to "learn to write software that parallelizes gracefully". to do it well requires having brain damage.
gus
> On Oct 14, 2015, at 11:35 AM, ske wrote:
>
> Update from Progress Community [https://community.progress.com/]
>
> ske [https://community.progress.com/members/ske]
>
>> your thesis paper gets me "403 Permission Denied"
>
> Apparently you have to remove the ")." that are included with the URL when you click it.
>
> The thesis seems to discuss some extension to Java to keep track of ownership for iterators.
>
> I haven't read the pape yet, other than the introduction, but I notice that when the C++ Core Guidelines were presented at the recent CppCon, it too included generic features and new lint style utilities for checking ownership of pointers (including iterators).
>
> View online [https://community.progress.com/community_groups/openedge_general/f/26/p/20215/73295#73295]
>
> You received this notification because you subscribed to the forum. To unsubscribe from only this thread, go here [https://community.progress.com/community_groups/openedge_general/f/26/t/20215/mute].
>
> Flag [https://community.progress.com/community_groups/openedge_general/f/26/p/20215/73295?AbuseContentId=add6660c-a5b9-41a7-b27f-f3b35a8daab4&AbuseContentTypeId=f586769b-0822-468a-b7f3-a94d480ed9b0&AbuseFlag=true] this post as spam/abuse.
And you know how it's done in functional languages.
There have been studies on the subject. F.e. www.researchgate.net/.../227236102_Comparing_Parallel_Functional_Languages_Programming_and_Performance
"The potential advantages of purely functional programming languages for prototyping and developing parallel programs have long been recognised [8]."