• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

Simple Question

 
Ranch Hand
Posts: 361
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hello all,

The private methods of a certain class can only be accessed by the following two categories :

A- The same methods inside the same object.
B- Another methods from another objects but are in the same class.

In my opinion only the methods that belong to the same object should access the object private data and that case B some how is considered a violation of the object oriented principles.Only the same object should access its own private data, and no other objects, even if they were belonging to the same class.

What do you think??
 
(instanceof Sidekick)
Posts: 8791
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I was a little surprised that B existed when I first encountered it, and have never (deliberately) taken advantage of it. I prefer to think of private as private to an instance, period, but the langauge doesn't enforce that as a design decision.
 
author and iconoclast
Posts: 24207
46
Mac OS X Eclipse IDE Chrome
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Some languages have "object-based encapsulation", which is what you're describing: Eiffel and Ruby, for example. Many others -- C++ and Java, for example -- have "class-based encapsulation." I don't think one is necessarily "better"; they're just different, and both have their advantages and disadvantages. For example, you might not have considered that efficient copy and compare methods are difficult to write in languages with object-based encapsulation.
 
author
Posts: 14112
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Khaled Mahmoud:

In my opinion only the methods that belong to the same object should access the object private data and that case B some how is considered a violation of the object oriented principles.



Which specific principle are you thinking of? What problems would be solved by not allowing B?
 
Khaled Mahmoud
Ranch Hand
Posts: 361
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Well, talking about Information hiding.Only the object alone, must be able to access its private data members.No other objects must do so.

I am not talking about specific advantages or disadvantages I am talking according to my common sense in Object Orientation.A great number of developers don't know the fact "B" and get surprised when they encounter it, exactly the same thing that happened to me when preparing for the Sun Certified Java Programmer Exam.
 
Sheriff
Posts: 7001
6
Eclipse IDE Python C++ Debian Java Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
To echo Ernest's point - I used option B just this afternoon when writing a "compareTo" method. Without option B I would have needed to either make all the member variables public/protected/default rather than private, or provide public/protected/default accessors for all of them. That seems a whole lot of unnecessary work, and potentially even more of a maintainance problem..
 
Ranch Hand
Posts: 131
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Privates can also be accessed by inner/nested/local classes.

What you may be observing is that the distinction between public and private is highly arbitrary. In Java, it is implemented lexically, which is why you can access private members of foreign objects.

Proper lexical encapsulation would make private data not even be part of the object. For example, from Common Lisp:

(defun new-counter ()
(let ((x 1))
(lambda () (incf x 1))))

new-counter is a function that sets a local variable, x, to 1, then returns a function that, when invoked, increments x, returning the result.

As in Java, local variables are allocated per function/method call, so this always returns a new counter. Also, x is not part of the function, but is only referred to by it. There's no need for private/public here.

There is no Java equivalent, because of the 'final' restriction on variables used from inner classes.

I can write a data holder, taking advantage of lexical scope, but I can't mutate the data without making it part of an object. The best I can do is make it part of an object that I'm not storing a reference to in any object that I'm giving out.

Here's the data holder:


This demonstrates (well, the Lisp does), that in a better language, such as Java 7, that you don't need public and private for encapsulation, and the fact that you can access private members of foreign objects shows the weakness of private.

The workaround for Java 6 and below is to program to interfaces, which is a poor abuse of abstraction when there's no abstraction to make.

That way you don't get access to the private members at all, for any other object, because all other objects are accessed via the interface type.

Ernest Friedman-Hill, you said: "you might not have considered that efficient copy and compare methods are difficult to write in languages with object-based encapsulation."

Why are they difficult to write?
 
Ilja Preuss
author
Posts: 14112
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Khaled Mahmoud:
Well, talking about Information hiding.Only the object alone, must be able to access its private data members.No other objects must do so.

I am not talking about specific advantages or disadvantages I am talking according to my common sense in Object Orientation.



I have a very pragmatic point of view on this: OO is not about common sense, nor about academical pureness etc. To me, it simply is a tool to manage dependencies in source code.

From this point of view, accessing private data of a different object of my own class is not a problem, because the the source code is the same. Accessing private fields doesn't increase coupling in a way that makes it harder to extend or maintain the code.
 
Ricky Clarkson
Ranch Hand
Posts: 131
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Ilja, if you had a modular system that didn't depend on objects, such as Pascal's 'interface' and 'implementation' sections, do you think you'd still use objects to achieve the same thing?

It seems to me that you're (ab?)using classes as both namespaces and containers that facilitate polymorphism. Fine, you have no choice in Java, but it's worth recognising that it might not be the ideal.
 
Ernest Friedman-Hill
author and iconoclast
Posts: 24207
46
Mac OS X Eclipse IDE Chrome
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Ricky Clarkson:

Ernest Friedman-Hill, you said: "you might not have considered that efficient copy and compare methods are difficult to write in languages with object-based encapsulation."

Why are they difficult to write?



... because no one chunk of code has access to the member data in both objects? Seems rather self-explanatory. As Frank says in his post, the only obvious way to write such functions then is to either expose the members directly by making them non-private (which you don't want to do, that's the whole point) or indirectly with accessors (which you may not want to do, if internal state really shouldn't be part of the interface exposed by the class.)

The non-obvious way is to provide a method like "compare yourself to this data", and have one object pass its member data to the other as part of the comparison, which is quite convoluted and hard to understand -- but that's why I said "difficult" rather than "impossible".
 
Ricky Clarkson
Ranch Hand
Posts: 131
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
So, Ernest, when you said that efficient copy and compare methods were difficult to write, I think what you meant was that those methods are difficult to write if they depend on private data or data that isn't actually part of the object (like 'x' in my counter example from Lisp).

I don't think that's a bad thing. If I'm going to sort a collection of items, I'm going to do it on public data. E.g., I have 10 coins in my pocket, and I'm going to sort them based on the year printed on them (public data).

It doesn't make sense to sort them based on the temperature at their cores (i.e., private data), even if I make a Coin class that can obtain the core temperature for an instance. One Coin wouldn't logically know the temperature at the core of another.

Of course, because the data is part of the object, and stored privately, in Java that would be quite possible, but it doesn't logically make sense. Why would one object need to get access to the non-interface portions of another?
 
Ernest Friedman-Hill
author and iconoclast
Posts: 24207
46
Mac OS X Eclipse IDE Chrome
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Ricky Clarkson:
Why would one object need to get access to the non-interface portions of another?



See Ilja's last post above. Arguments about what models the real world most closely don't move me. Preventing the objects of a class from accessing each other's data does not simplify my code, reduce coupling, or ease maintainence in any way, so it's not a feature I get excited about.
 
Ilja Preuss
author
Posts: 14112
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Ricky Clarkson:
Ilja, if you had a modular system that didn't depend on objects, such as Pascal's 'interface' and 'implementation' sections, do you think you'd still use objects to achieve the same thing?



I'm not sure I understand the question. If you are asking whether I'd want to make use of polymorphism, then the answer is yes. If it was something else, please retry.


It seems to me that you're (ab?)using classes as both namespaces and containers that facilitate polymorphism. Fine, you have no choice in Java, but it's worth recognising that it might not be the ideal.



You are right that to me the defining property of an OO language is polymorphism.

I'm quite open to the idea that there might be other concepts that are even more powerful. In fact I'd love to use Lisp at some time.

I don't see any advantage in just not making private data accessible to other objects of the same class in Java, though. In the very seldom cases that it was in my way, it was so easy to refactor to access through methods that it wouldn't be worth a single brain cell to think about alternatives...
 
Ricky Clarkson
Ranch Hand
Posts: 131
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Ernest:

Arguments about what models the real world most closely don't move me. Preventing the objects of a class from accessing each other's data does not simplify my code, reduce coupling, or ease maintainence in any way



I'm not arguing that the language should prevent it, but that it doesn't make sense to take advantage of the feature. If arguments based on reality don't help, then how about you post your own example, based on some real code that you wrote, or dealt with?

Using reality as an analogy is often useful, unless your code differs from reality in a large way, which is a bad sign.

Ilja:

I'm not sure I understand the question. If you are asking whether I'd want to make use of polymorphism, then the answer is yes.



Ok. You said: "OO is not about common sense, nor about academical pureness etc. To me, it simply is a tool to manage dependencies in source code."

To me, that means that OO is a module system to you. That's not what OO is about, but that's what ends up happening in Java. If Java supported a non-OO module system, such as Pascal's interface/implementation sections, as well as the OO we all know about, would you do anything differently?
 
Ilja Preuss
author
Posts: 14112
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Ricky Clarkson:
Ok. You said: "OO is not about common sense, nor about academical pureness etc. To me, it simply is a tool to manage dependencies in source code."

To me, that means that OO is a module system to you.



No.

The point of OO is that polymorphism allows us to inverse dependencies by introducing abstractions. My code doesn't depend on the database driver of a specific vendor - they both depend on JDBC. Languages that directly support polymorphism make this "pattern" so easy to implement that it becomes the standard way of working.

See http://www.infoq.com/presentations/principles-agile-oo-design
 
Ricky Clarkson
Ranch Hand
Posts: 131
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

The point of OO is that polymorphism allows us to inverse dependencies by introducing abstractions. My code doesn't depend on the database driver of a specific vendor - they both depend on JDBC.



That's exactly the same as coding to the interface portion in a non-OO module system, such as Pascal, and the same code being able to work with multiple implementations. That's not about objects.

Objects do, however, provide a convenient way of being able to cope with more than one implementation at a time. There is another way:

Global variables, more accurately called special variables, have an interesting property in Lisp; they can be temporarily bound to a new value. Consider the following Java code that captures the output of a method that's written to output to System.out:



Here's the corresponding Lisp code, except that in Lisp the changed variable is also thread-local (yes, the same as Java's ThreadLocal, except less tedious to use):



For the duration (actually the duration, not the lexical scope) of the code between the ( and ) shown there, the global variable *standard-output* will be the other stream. And then afterwards, the original value is used.

In Scheme, you can do the same for functions - just assign the function you want right now to the name that the calling code binds it to. I don't yet know how you do that for Common Lisp, without explicitly making a variable refer to a function (in Scheme, variables and functions are in the same namespace).

That's an interesting way of allowing one codebase to be called, by one program, and use more than one implementation of some library. It makes Java DI solutions look like the overkill that they are.
 
Ilja Preuss
author
Posts: 14112
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Ricky Clarkson:
That's exactly the same as coding to the interface portion in a non-OO module system, such as Pascal, and the same code being able to work with multiple implementations. That's not about objects.



If OO were purely about objects, we wouldn't need to distinguish it from object *based* languages.


Objects do, however, provide a convenient way of being able to cope with more than one implementation at a time.



If you mean by this that we can change which implementation to use at runtime, I fully agree.

There is another way:



There are an endless number of ways. So what?


That's an interesting way of allowing one codebase to be called, by one program, and use more than one implementation of some library. It makes Java DI solutions look like the overkill that they are.



I don't know what DI means, but I agree that in Java some things are more complicated than they needed to be. Hopefully closures will reduce that overhead somewhat in future versions.

There still is something about the Strategy design pattern that is missing from this discussion: a Strategy can consist of more than one method/function.

I'm not saying that therefore Strategy is obviously always superior, or that Java is the best language ever - far from it. But it's not as easy as saying "design patterns are always a hint that the language is missing something".
 
Frank Carver
Sheriff
Posts: 7001
6
Eclipse IDE Python C++ Debian Java Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I don't have much time right now to join in here, but I can respond to Ilja's confusion: "I don't know what DI means"

In this case DI refers to "dependency injection", a.k.a "inversion of control". See http://www.martinfowler.com/articles/injection.html
 
Stan James
(instanceof Sidekick)
Posts: 8791
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I'm never sure what the point is in these discussions. Different languages have different features. I'm happy enough to just use what's there most of the time. If someone describes something in language x that will help me write better Java, I'll take the time to study up. If it's just how x is different, not of much interest today.

I really liked Pascal's interface and implementation sections. Borland's flavor of object pascal, introduced with Turbo 5 I think, was a very smooth transition. They added a few new keywords and the only new concept was inheritance. Seemed like a logical convergence of concepts to me.

Polymorphism wasn't new or unique to OO. I wrote "system exits" in 370 assembler and pluggable COBOL programs years with and without DI before I heard of OO. They fit exactly the same model of abstraction and different behavior for the same stimulus. Again, about all that felt really new with OO was inheritance, but some other paradigms supported that without objects, too.

In one sense, OO is just another way to organize code; you might say another modularization technique but I think "module" is not a helpful word. To agree with Ilja, careful dependency management is the magic sauce that makes it work best. In another sense it turns all of structured programming completely upside down. (That either means you "get it" or "drank the Kool-Aid." I prefer to believe the former.)

In short OO offers some neat ways to do things, and particularly facilitates good dependency management if you care to try. I choose it over my other choices - some of those other languages are still in my toolbox - for almost all coding work nowadays. I'll hapilly admit there may be better choices out there, but I don't have the energy or the incentive to learn them today.

What was the disagreement about?
 
Ricky Clarkson
Ranch Hand
Posts: 131
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

If OO were purely about objects, we wouldn't need to distinguish it from object *based* languages.



That distinction is fairly arbitrary. OO doesn't actually depend on classes, it just turns out that classes are quite convenient. In the words of Alan Kay:

"OOP to me means only messaging, local retention and protection and hiding of state-process, and extreme late-binding of all things."

That's probably why the Wikipedia articles on it are so small and out of date.

There are an endless number of ways. So what?



So some are better than others. Yes, the qualifiers for 'better' vary, but mine is simple - the lesser the better, all else being equal.

The tone of "So what?" is quite harsh in English. If I have offended you, it is not on purpose. It might be a tone gained by accident in translation (from German?).

There still is something about the Strategy design pattern that is missing from this discussion: a Strategy can consist of more than one method/function.



One way of doing that with the generic methods approach is to make the method return an object that has references to two functions. Or you could just implement a one-method strategy twice.

But it's not as easy as saying "design patterns are always a hint that the language is missing something".



I've yet to come across a design pattern worthy of its name. That sounds very harsh, but what I mean is that, with the right refactoring and programming language, design patterns get reduced into a single method/function quite often, or get replaced by a language feature, such as Scala's inbuilt singleton support (you can declare a global object - it is a singleton still, but it's so trivial to use that it's not even worth calling it a singleton - it's a global object).

Still, I think Lisp's special variables are a better replacement for singletons, and they predate the term 'singleton' as used today.
 
Ricky Clarkson
Ranch Hand
Posts: 131
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

I'm never sure what the point is in these discussions. Different languages have different features. I'm happy enough to just use what's there most of the time. If someone describes something in language x that will help me write better Java, I'll take the time to study up. If it's just how x is different, not of much interest today.



If there were no problems in software today, I'd agree wholeheartedly. Walking is a pretty much solved problem - so I don't discuss which foot goes first, or how to go around corners. Software engineering is still an unsolved problem.

When I started programming, in 1986, on a Spectrum 48K, I knew no other programmers, and had no other documentation (despite looking in my local library) than the Spectrum's manual. For years I emulated functions by using GOSUB and RETURN - without ever knowing what functions were.

Later I programmed in a version or two of BASIC with functions, and one with NEWTYPE (effectively a struct). I started to emulate OOP, then found out what it was and started to use it in languages that supported it more explicitly (I was actually hardcoding type IDs into functions to achieve polymorphism).

I did the same with functional programming. Discussing and learning about features from other languages can help us to realise what we are doing; that we are not doing anything new; that the same things we are thinking about having already been thought about, and we can benefit from the results of those thoughts.

Further, if we are well-placed to affect the future of the language we're using, it is of direct use in improving the language. It is also of direct use in making us more willing to choose the right language and tools for the job.
 
Bartender
Posts: 2968
6
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Stan James:
I'm never sure what the point is in these discussions. Different languages have different features. I'm happy enough to just use what's there most of the time. If someone describes something in language x that will help me write better Java, I'll take the time to study up. If it's just how x is different, not of much interest today.
...
What was the disagreement about?



It seems that at regular intervals some programmers get to a competency level were they challenge themselves to learn a functional language and then find out what Lutz Prechelt, Erann Gat and Peter Norving have known for a while: functional languages can be more expressive and can make some programmers more productive.
Peter Norvig: Lisp as an alternative to Java
Article (PDF): Lisp as an alternative to Java

Of course to exploit this new found knowledge in the current economic environment you either have to be in a position like Paul Graham or work for someone who is.
Paul Graham: Beating the Averages

The above article makes the following conclusion:


Lisp is often considered an esoteric AI language. Our results suggest that it might be worthwhile to revisit this view. Lisp provides nearly all of the advantages that make Java attractive, including automatic memory management, dynamic object-oriented programming, and portability. Our results suggest that Lisp is superior to Java and comparable to C++ in runtime, and it is superior to both in programming effort and variability of results. This last item is particularly significant because it translates directly into reduced risk for software development.



In a sense that conclusion almost suggests that software engineering might be a lot better off if functional languages would become more mainstream. However the studies seem to be unable to separate how much of the "benefit of functional languages" lies with the languages themselves and how much is contributed by the people who are capable of working with and choosing to work with these languages.

"20-to-1 Productivity Rule: One out of 20 programmers is 20 times more productive than the average programmer".
(? Bell D., Morrey I., Pugh J.: Software engineering. Prentice Hall, 1987 ?)
Could it be that programmers who are inherently more productive gravitate towards functional languages? If functional languages make great programmers more productive, does it follow that they would make average programmers more productive? Or is the price of admission simply too high for average programmers? If that is true then there may be too much programming work on this planet to be tackled by those great programmers using functional languages, so in order to access more labor 'more accessible' languages are used (even with the associated inefficiencies and risks).

Even Paul Grahams work fell victim to this kind of thinking. Yahoo Stores was re-written in Perl and C++ after he sold it. The bean counters figured that all programmers are exchangeable; Perl and C++ programmers were plentiful and cheap while Lisp programmers were not. Sony's reaction to Naughty Dog's GOAL was similar.
Bill Clementson: Lisp is for Entrepreneurs

John Hughes: Why Functional Programming matters
Philip Wadler: Why no one uses functional languages (PDF)
Philip Wadler: An Angry Half Dozen

I'm surprised there hasn�t been more talk about functional programming in the agile quarter. They focused on making the process and the people more productive - I figured that they would be turning their attention to tools and languages at some point of time. Many of the early agilistas came from a Smalltalk background; they had to settle on Java - it was better than C++ and wasn't perceived as too much of a risk by their clients. It seems that current favorites are Squeak and Ruby.

Many programmers who have forayed into functional programming believe that it had a strong positive impact on their 'regular' programming. Maybe this is why MIT's first year programming course uses Scheme (Structure and Interpretation of Computer Programs; maybe it also helps them weed out students)

Peter Seibel has made his book Practical Common Lisp and the Lispbox environment available on-line if you want to have a go at it.

Just be careful that you don't go of and fulfill [url=http://en.wikipedia.org/wiki/Greenspun%27s_Tenth_Rule]Greenspun's Tenth Rule[/url] in your regular work.
 
Stan James
(instanceof Sidekick)
Posts: 8791
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Well, if all this was a disguised invitation to learn Lisp, I guess I'm passing. At this point in my life I will probably take up a new programming language only if paid to. I don't do enough extra-curricular coding to make it worth using the next most wonderful thing since sliced CPU time. If I were going to seriously devote myself to wrapping my head around something totally new and different, it would more likely be guitar or Italian.

So what's been the value of all this to a Java guy? They do it better in Lisp, functional languages kick butt, and ...
 
Ricky Clarkson
Ranch Hand
Posts: 131
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Stan, I assumed that people who spend some of their time talking on JavaRanch actually are interested in programming.

Learning some music theory helps people to compose and play better guitar music. Of course, some of it won't be used, like sight-reading musical notation, as guitarists have their own notation, 'tab', and rhythm guitar players only need to know the chord names.

Learning some Latin helps people who speak and write those languages that are influenced by it. For example, in Spanish, 'mano', which is 'hand', is a feminine word, unusually, so you say 'las manos', not 'los manos'. Most Spanish-speaking people don't know why it is feminine - it is because it is derived from a Latin word that was usually used in a brief form. A friend of mine struggles to remember the word 'mano', so I tell him it has the same roots as 'manicure', and he remembers it.. for a while. I imagine that when you learn Italian you'll come across similar artefacts. It does seem odd to go to an Italian hotel and ask for a camera for the night.

Well, if all this was a disguised invitation to learn Lisp, I guess I'm passing. At this point in my life I will probably take up a new programming language only if paid to. I don't do enough extra-curricular coding to make it worth using the next most wonderful thing since sliced CPU time



It's the other way around - Lisp predates sliced CPU time. So what you're telling us is that you will not pick the best tool for the job, on the grounds that your life/career is nearly over? I'm sorry to hear that, truly. Personally I'm not trying to encourage anyone to learn Lisp, except myself. I am only making the point that design patterns are just a halfway point until you have a reusable solution that you can reference, rather than repeat.
 
Peer Reynders
Bartender
Posts: 2968
6
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Stan James:
So what's been the value of all this to a Java guy? They do it better in Lisp, functional languages kick butt, and ...



For the longest time this was a major drawback of the Java-centric environment - it was all about Java. That was one of the latent promises of .NET - it wasn't going to focus on one single language; whether the VM is up to the task of actually supporting multiple programming paradigms efficiently is another question (F sharp).

However Sun seems to have loosened it's vision up a bit recently and seems more open to adding support for other languages within the JVM (I wonder if Ruby had anything to do with that). Ruby isn't a functional language but it borrows some concepts from functional languages and combines that with its dynamic language environment - which some say makes for a productive environment (This is further enhanced in Rails by the use of "common sense defaults and conventions" combined with some good code generators).

In many ways Groovy tries to copy the (vocal) success of Ruby. The "agile dynamic language for the Java Platform" can be used in the Java environment and seems to allow the application of some concepts that are typically found in functional languages that are just too tedious to implement in plain Java. At the same time you already have access to the large number of Java libraries. So you could initially use Groovy to implement any project automation scripts that you may need on a day to day basis. If you like what you see, feel that you are getting things done faster, you may consider using Groovy inside of a project.
(Richard Monson-Haefel "instigated" Groovy
(2004)).

Thinking in terms of a functional language can also be helpful when you are working with XML or more specifically XSLT. XML is commonplace but often XML documents need to be transformed from one format to another. XSLT (possibly in combination with JAXP(TraX)) is The Right Tool For The Job, rather than using Java (with SAX, DOM, STAX) code to break down the first format and then rebuilding the document in the second format.
The Functional Programming Language XSLT - A proof through examples

Frankly, a lot of Java coders would benefit from breaking out of the imperative programming domain, period. Many of these people have to work directly with relational databases every day but often code solutions in the Java (imperative programming in the object oriented) domain, when a SQL (declarative programming in the relational domain) solution is more a appropriate. They simply stick with what they are more comfortable with and never deepen their SQL skills beyond the very basics.

Originally posted by Ricky Clarkson:
I am only making the point that design patterns are just a halfway point until you have a reusable solution that you can reference, rather than repeat.



Especially if you are using Lisp.


It may still be worth skimming since several posts show some insight into Lisp's real problem, namely that the patterns required for Lisp's effective use are slow to spread outside pocket communities and that people within those communities are so used to this problem that they discount any pattern originating outside these pockets. -- Ward Cunningham


Why We Hate Lisp
Lisp Sucks

Productive and expressive Lisp is usually about meta-programming.
Generics were only introduced in Java 5. People comfortable with the use of Generic types are not necessarily comfortable creating Generic types. Java and .NET's Generic capabilities are severely constrained compared to C++ templates (Loki). Meanwhile C++ template meta-programming cannot hold a candle to Lisp meta-programming. Can your "average programmer" wield that kind of power effectively? Or will it simply lead to humongous messes that will make you look forward to the next batch of spaghetti code?

The sad truth is that a significant portion of people who are paid to write code for a living can't be bothered to apply the DRY principle.
Bruce Eckel: The Ideal Programmer
So raising awareness about design patterns (when to use them, when to ignore them, how to communicate with them) in the entire community is not as simple as any particular individual learning about them. For many people learning Lisp is just about as tempting as (re-)learning calculus and differential equations.

Granted, I think it would improve many IT oriented curricula if they included a functional programming course simply to ensure that the student can deal with concepts outside of the imperative programming paradigm. For now you have to either enter an AI program or at least take an AI course (though that didn't work in my case because I had a choice between Lisp and Prolog. I chose Prolog - it looked shinier back then).
 
Stan James
(instanceof Sidekick)
Posts: 8791
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
To Ricky's comments ...

I shouldn't have been so dismissive of the value of learning different langauges and paradigms. I've championed such things many times over the years.

So what you're telling us is that you will not pick the best tool for the job, on the grounds that your life/career is nearly over?



I have two quibbles with that. I get to define "the job" for myself. Using another langauge is not an option in my career context. It's a good way to expand one's horizons, but the ROI doesn't match other opportunities.

And "nearly over" doesn't feel right. I've got 28 years in AD and plan on maybe another 10. I just moved teams to shake things up rather than cruise along doing what I've been doing for the last 10.

I'd expect at least one more major technology shift, eg Java to something else, and I'll make every effort to be on the front edge, when it hits my company. I've been there a half dozen times before.

Stan, I assumed that people who spend some of their time talking on JavaRanch actually are interested in programming.



I'd say that's a good assumption. And a rather snarky remark. Hang around and see what I'm interested in.

Your other examples were interesting ... latin and music theory are a couple of my favorite bits of my education.
 
Stan James
(instanceof Sidekick)
Posts: 8791
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
To Peer's ...

For the longest time this was a major drawback of the Java-centric environment - it was all about Java.



Somehow that doesn't sit well with me, but I can't say quite why. If people want to, they can grow and learn quite a lot in Java.

The sad truth is that a significant portion of people who are paid to write code for a living can't be bothered to apply the DRY principle.



That sure rings true. I read an awful lot of code and get the feeling that many folks come out of school with some ability in the language syntax, but no interest in learning to use it well. They generate a lot of write-only code and love copy paste above all. There are worse things ... I'm now finding a lot of 300-400 line methods. We need a barfing smiley.

So raising awareness about design patterns (when to use them, when to ignore them, how to communicate with them) in the entire community is not as simple as any particular individual learning about them.



I'm less interested in design patterns than the principles that led to them. Patterns are good to know when your problem fits one of them, but day to day coding without the basics will eternally suck. Getting the word out is challenging as you say. I'm big on the word "community." This is a pretty wonderful one. I wrote a BBS that powered a great one in our mainframe COBOL world, and I know how much effort (and luck) is required to fire up a new one, just because we haven't succeeded again.

They simply stick with what they are more comfortable with and never deepen their SQL skills beyond the very basics.



Oh, that might be me. I learned SQL from the first edition of the Date book. I leave the flashy stuff there to others, but I do save off some of this guy's SQL tricks.
 
Ilja Preuss
author
Posts: 14112
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Stan James:
I'm less interested in design patterns than the principles that led to them. Patterns are good to know when your problem fits one of them, but day to day coding without the basics will eternally suck.



I find patterns also to be good inspirations on how to apply the principles. And they also serve as a language tool - it's so much easier to say "would it help if we used a Template Method" than to always explain in detail what you are getting at.
 
Ilja Preuss
author
Posts: 14112
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Peer Reynders:

Granted, I think it would improve many IT oriented curricula if they included a functional programming course simply to ensure that the student can deal with concepts outside of the imperative programming paradigm.



When I studied computer science, functional programming was a required course. I certainly thought that it was important. In fact it is my opinion that a professional developer should be interested in learning as many different programming paradigms as possible.
 
Ilja Preuss
author
Posts: 14112
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Ricky Clarkson:
Stan, I assumed that people who spend some of their time talking on JavaRanch actually are interested in programming.



Ricky, please remember our "be nice" rule. Implying that your discussion partners are not interested, or not open-minded, is not a constructive discussion style.

While we are at it, I appologize for my use of "so what?" - I will explain what I meant in a seperate post.
 
Ilja Preuss
author
Posts: 14112
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Ricky Clarkson:
I am only making the point that design patterns are just a halfway point until you have a reusable solution that you can reference, rather than repeat.



That sounds more like what I'd call Implementation Patterns to me. To the amount that patterns are code templates intended to be copied and pasted, I actually agree.

That's not the core of what design patterns are about, though (even if they are often used that way, especially from developers new to patterns). Design patterns are about design *ideas* to recurring design problems. I will say it once again: a design pattern is intended to be adapted to the situation at hand, and to be coded in a slightly different way each time you apply it.

I don't think that it would be possible, let alone desirable, to design a programming language where every design problem is totally unique, so that we can't use prior experiences to handle it. And that's the whole point about design patterns - giving us a terminology to talk about - and reuse - that experience in a big community.
 
Ilja Preuss
author
Posts: 14112
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Peer Reynders:
I'm surprised there hasn�t been more talk about functional programming in the agile quarter. They focused on making the process and the people more productive - I figured that they would be turning their attention to tools and languages at some point of time.



I guess one of the reasons is that the used programming language will always only have a second order effect on the success of a project, compared with the importance of people and how they interact.
 
Ilja Preuss
author
Posts: 14112
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Ricky Clarkson:
quote:
--------------------------------------------------------------------------------
If OO were purely about objects, we wouldn't need to distinguish it from object *based* languages.
--------------------------------------------------------------------------------

That distinction is fairly arbitrary. OO doesn't actually depend on classes, it just turns out that classes are quite convenient.



Then I don't understand how you could use the phrase "That's not about objects" to reject my notion that OO was about polymorphism...


In the words of Alan Kay:

"OOP to me means only messaging, local retention and protection and hiding of state-process, and extreme late-binding of all things."



And polymorphism is about late-binding. Sounds to me like he is basically making my point...

The tone of "So what?" is quite harsh in English. If I have offended you, it is not on purpose. It might be a tone gained by accident in translation (from German?).



I'm sorry - what I actually wanted to communicate is confusion about what you are trying to get at. I now see how it could easily be misleading.

quote:
--------------------------------------------------------------------------------
There still is something about the Strategy design pattern that is missing from this discussion: a Strategy can consist of more than one method/function.
--------------------------------------------------------------------------------



One way of doing that with the generic methods approach is to make the method return an object that has references to two functions.



Sounds to me like a Strategy-Factory then. So instead of getting rid of the pattern, it sounds to me like you would in fact introduce another one - and one that doesn't really serve a purpose (-> unnecessary indirection). Why not simply pass the object directly?

Or you could just implement a one-method strategy twice.



When the strategy doesn't need to share any state between the two methods, yes. In cases where the two methods are strongly correlated, I wouldn't feel very comfortable with that solution, though.


I've yet to come across a design pattern worthy of its name.



I'm curious: when would a design pattern be worthy its name, in your opinion?

And how many of the GoF patterns, for example, do you know?

what I mean is that, with the right refactoring and programming language, design patterns get reduced into a single method/function quite often, or get replaced by a language feature, such as Scala's inbuilt singleton support (you can declare a global object - it is a singleton still, but it's so trivial to use that it's not even worth calling it a singleton - it's a global object).



Well, I agree that design patterns can be language specific, and that some can be quite simple. I don't see how it directly follows that they don't have value, though.


Still, I think Lisp's special variables are a better replacement for singletons, and they predate the term 'singleton' as used today.



I don't know about special variables, but I have a very strong dislike for the Singleton pattern, anyway. They are just globals in disguise - with all their typical problems.
 
Peer Reynders
Bartender
Posts: 2968
6
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Sometimes confusion arises because some people fail to disambiguate between idioms, which are closer to the implementation and often specific to a programming language (or a family of programming languages), and design patterns which are supposed to be more abstract.

However it seems that Peter Norvig claims that he can eliminate the need for 16 of the 23 GoF patterns in Lisp or Dylan which would effectively relegate them to idioms for imperative languages (Design Patterns in Dynamic Programming).
 
Stan James
(instanceof Sidekick)
Posts: 8791
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
If examining a zillion Lisp programs would not reveal the GoF patterns, would it reveal a whole different set of patterns? Patterns are just common solutions to common problems. I'd rather expect to see Lisp gurus around the world solving similar problems in similar ways that could be written up in the GoF style pattern language. Do patterns show up a weakness in the language, or show off its strengths?

Or maybe some language has reached the place where every line of code sings of the business domain. I'd much rather write and read code about insurance and call centers than http sessions and strategy factories. I strive to improve that business to noise ratio, but it's never all that great.
 
Peer Reynders
Bartender
Posts: 2968
6
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Stan,

I think you are misunderstanding. If anything, Lisp is much more about patterns, however at a more abstract level than what you see in the GoF patterns. Norvig argues in Design Patterns in Dynamic Programming that the majority of the GoF patterns are already supported by the language itself or are so 'simple' that they are in the idiomatic arsenal of any competent Lisp programmer (i.e. what is all the fuss about? These 'patterns' are 'no big deal'). If you can simply pass in functions (or closures) as objects then what is the big deal with the Strategy pattern?

He claims that dynamic languages can dispense with a lot of patterns because they don't force you to do the sort of housekeeping that you may have to do with strongly typed languages.

Originally posted by Stan James:
Somehow that doesn't sit well with me, but I can't say quite why. If people want to, they can grow and learn quite a lot in Java.



Can't argue with that - some say there is too much to learn as there are so many libraries. However Norvig would call Java "Object-Obsessed". C++ with all its warts has one thing going for it (which can be abused); the support for global functions, objects and generic programming allows for Multi-Paradigm Design (James O. Coplien's Thesis, Multi-Paradigm Design for C++). Lisp isn't a pure functional language, as far as I can tell it's a functional/dynamic language that supports objects (CLOS) - so it is truly Multi-Paradigm (with all the attendant risks).

(Aside: Coplien also talked back then about commonality-variability analysis which I think is a cornerstone of Object-Oriented Design).
 
Ilja Preuss
author
Posts: 14112
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Peer Reynders:
Sometimes confusion arises because some people fail to disambiguate between idioms, which are closer to the implementation and often specific to a programming language (or a family of programming languages), and design patterns which are supposed to be more abstract.



I agree that design patterns are more abstract than idioms. The GoF design patterns are certainly *OO* design patterns, though, so it's not surprising to me that they don't fully translate to languages with other paradigms. The design problems and there solutions are certainly different in, say, LISP.

However it seems that Peter Norvig claims that he can eliminate the need for 16 of the 23 GoF patterns in Lisp or Dylan



Which slide(s) do you get that from?

which would effectively relegate them to idioms for imperative languages



I don't agree. I think it's unrealistic to expect any pattern to be applyable in every language.
 
Ilja Preuss
author
Posts: 14112
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Stan James:
Or maybe some language has reached the place where every line of code sings of the business domain. I'd much rather write and read code about insurance and call centers than http sessions and strategy factories. I strive to improve that business to noise ratio, but it's never all that great.



I think an important part of software development is building such a language for your project - using the low level tools of the language (or existing libraries/frameworks) to build a domain specific language which you then use to build your application (incrementally and iteratively, of course).

I think the reason for building *generic* domain specific languages typically failing is that it hampers creativity. When you can't use the low tech tools of the language any longer, you are very constraint in being innovative - the more you are removed from the low level details, the more applications will look alike. (To some amount that's even desirable, but somewhere there is a point where our customers actually want something *new*, something that hasn't been done before.)
 
Ilja Preuss
author
Posts: 14112
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Peer Reynders:
If you can simply pass in functions (or closures) as objects then what is the big deal with the Strategy pattern?



Good question - thanks for asking!

I think the answer is in that a pattern is more than just a code template.

For example, a pattern also comes with a motivation. The Strategy pattern is not only about passing in functions, it is about doing so to customize the details of how an algorithm works. This becomes more obvious when you see take a look at other patterns that can be implemented in exactly the same way, but with sligthly different (or more specific) motivations: Abstract Factory, Observer etc.

Another important part is the name - patterns simply give us a vocabulary to more easily communicate design ideas. Compare "can we use a Strategy there" with "can we pass in a function there that gets called inside the algorithm so that we can customize it?"

Of course Strategy is a very basic, simple pattern. And of course there will be patterns that simply don't make sense in a functional language. In fact I would expect there to be a lot of value for the functional programming community to build their own set of design patterns.
 
Stan James
(instanceof Sidekick)
Posts: 8791
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Ilja said everything I thought to say last night.

Passing functions or closures may just be an implementation of Strategy in a language that GoF didn't happen to study. If it's a one-line implementation, that's very cool. Even one-line techniques may be worth naming. Or not.
 
reply
    Bookmark Topic Watch Topic
  • New Topic