Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.java.programmer > #13616 > unrolled thread

Learning Java

Back to article view | Back to comp.lang.java.programmer

Contents

  Learning Java Steve Graham <jsgrahamus@yahoo.com> - 2012-04-17 15:03 -0600
    Re: Learning Java markspace <-@.> - 2012-04-17 14:33 -0700
      Re: Learning Java glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2012-04-17 21:50 +0000
        Re: Learning Java Arne Vajhøj <arne@vajhoej.dk> - 2012-04-17 19:21 -0400
        Re: Learning Java markspace <-@.> - 2012-04-17 16:47 -0700
          Re: Learning Java glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2012-04-18 02:30 +0000
            Re: Learning Java Arne Vajhøj <arne@vajhoej.dk> - 2012-04-28 21:56 -0400
        Re: Learning Java Arved Sandstrom <asandstrom3minus1@eastlink.ca> - 2012-04-17 21:07 -0300
          Re: Learning Java Arne Vajhøj <arne@vajhoej.dk> - 2012-04-17 22:06 -0400
            Re: Learning Java Arved Sandstrom <asandstrom3minus1@eastlink.ca> - 2012-04-18 07:11 -0300
              Re: Learning Java Leif Roar Moldskred <leifm@dimnakorr.com> - 2012-04-18 06:47 -0500
              Re: Learning Java Lew <lewbloch@gmail.com> - 2012-04-18 10:19 -0700
                Re: Learning Java Lew <lewbloch@gmail.com> - 2012-04-18 10:20 -0700
              Re: Learning Java glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2012-04-18 21:10 +0000
              Re: Learning Java Gene Wirchenko <genew@ocis.net> - 2012-04-18 15:01 -0700
              Re: Learning Java Arne Vajhøj <arne@vajhoej.dk> - 2012-04-28 22:11 -0400
                Re: Learning Java Arved Sandstrom <asandstrom3minus1@eastlink.ca> - 2012-04-29 11:00 -0300
                  Re: Learning Java Lew <noone@lewscanon.com> - 2012-04-29 11:44 -0700
                  Re: Learning Java markspace <-@.> - 2012-04-29 16:34 -0700
                    Re: Learning Java Arved Sandstrom <asandstrom3minus1@eastlink.ca> - 2012-04-30 20:52 -0300
                  Re: Learning Java Arne Vajhøj <arne@vajhoej.dk> - 2012-05-05 18:17 -0400
                    Re: Learning Java Arved Sandstrom <asandstrom3minus1@eastlink.ca> - 2012-05-06 15:49 -0300
                      Re: Learning Java Gene Wirchenko <genew@ocis.net> - 2012-05-07 09:50 -0700
        Re: Learning Java RedGrittyBrick <RedGrittyBrick@spamweary.invalid> - 2012-04-19 15:30 +0100
    Re: Learning Java Arne Vajhøj <arne@vajhoej.dk> - 2012-04-17 19:26 -0400
    Re: Learning Java Patricia Shanahan <pats@acm.org> - 2012-04-17 19:08 -0700
    Re: Learning Java Roedy Green <see_website@mindprod.com.invalid> - 2012-04-26 16:06 -0700
    Re: Learning Java Steve Graham <jsgrahamus@yahoo.com> - 2012-05-15 17:40 -0600

Page 2 of 2 — ← Prev page 1 [2]

#14300

On 4/29/2012 10:00 AM, Arved Sandstrom wrote:
> On 12-04-28 11:11 PM, Arne Vajhøj wrote:
>> On 4/18/2012 6:11 AM, Arved Sandstrom wrote:
>>> On 12-04-17 11:06 PM, Arne Vajhøj wrote:
>>>> On 4/17/2012 8:07 PM, Arved Sandstrom wrote:
>>>>> On 12-04-17 06:50 PM, glen herrmannsfeldt wrote:
>>>>>> markspace<-@.>    wrote:
>>>>>>> On 4/17/2012 2:03 PM, Steve Graham wrote:
>>>>>>>> I've been a programmer for 3 decades working in mostly procedural
>>>>>>>> languages, although I have done some work with a couple of
>>>>>>>> object-oriented ones.
>>>>>>
>>>>>>>> Which book would you recommend that I read to learn Java?
>>>>>>>> Obviously, I
>>>>>>>> don't want to read a beginning programming book, nor do I want to
>>>>>>>> study
>>>>>>>> one which presupposes I know something about Java or a lot about OO
>>>>>>>> concepts.
>>>>>>
>>>>>> You can do procedural programming in Java. You might find it easier
>>>>>> to start that way, to get used to Java, and then learn the OO stuff.
>>>>>
>>>>> I suspect that a cold, hard analysis of all Java code written in the
>>>>> past 15 years would show that the large majority of it _is_ procedural.
>>>>>
>>>>> Fact is, Java and Objective-C and C++, to name a few OOP languages, are
>>>>> generally used to write substantially imperative code, where procedures
>>>>> appear as object methods. We may as well not ignore that, it's what
>>>>> most
>>>>> OO programmers do.
>>>>>
>>>>> Having said that, the advantage of objects and OOP shouldn't be
>>>>> discounted. We simply shouldn't pretend that modern OOP isn't still
>>>>> largely imperative/procedural code. If we advise the OP to learn proper
>>>>> OO - and I certainly do - the fact is that in his studies he's going to
>>>>> come across a stupendous amount of imperative Java. I recommend that
>>>>> the
>>>>> OP keep this in mind. There are fine resources available for learning
>>>>> the principles and theory of OOP; one simply has to remember that much
>>>>> real-world code deviates substantially.
>>>>
>>>> OOP is supposed to be imperative, so I do not see much point in that
>>>> argument.
>>>
>>> OOP isn't "supposed" to be imperative at all, it just happens that most
>>> mainstream OO languages are. C++, Objective-C, Java etc, those are
>>> imperative OO languages. But you can and do have languages that are
>>> functional and use OO, even some that are logical and have elements of
>>> OO.
>>>
>>> To the extent that OO != imperative I don't withdraw my use of the term
>>> "imperative". But I really meant "procedural", and should have used that
>>> across the board.
>>>
>>> However, let's stick to the imperative OO languages here. My argument is
>>> that a great deal of actual (non-teaching) Java code strays
>>> substantially from best-practice OO, and is best characterized as
>>> "procedural" and/or "structured" and/or "modular". It doesn't really
>>> have those extra features that distinguish good OO code.
>>>
>>> That is the main argument I am making. And it's about "what is", as a
>>> caution to the OP, not a reflection on the best Java or even decent Java
>>> that can be written by a programmer who is reasonably well-grounded in
>>> proper OO. I am pointing out what we often see.
>>>
>>>> How big a portion of Java code that is procedural will depend a
>>>> bit on where you put the bar.
>>>>
>>>> If we put the bar relative low:
>>>>     procedural = all static methods
>>>>     OOP = use of interfaces, private fields public methods
>>>> then the majority of Java code is not procedural.
>>>>
>>> That's a very low bar, and it's selected to make a lot of Java and C#
>>> real-world code look good. By that criterion all those large instance
>>> methods out there that gather in a multitude of behavior-anemic objects
>>> and perform algorithms on them are OOP. Well, of course they are
>>> technically OOP.
>>>
>>> What's the most classic "procedure" that Java has? The "main" method in
>>> a main class. That's even one by your definition. Often what people do
>>> in "main" is call the constructor of the main class, and invoke an
>>> instance method on it that is the top-level "procedure". Not too much
>>> really OO-like about that at all.
>>>
>>> Let's consider Java EE. No small number of web apps have a fat "service"
>>> or "application" layer that teems with procedural code. Session beans
>>> and managed beans are loaded with large methods that, despite being
>>> instance methods, are "procedures" that assemble a variety of
>>> data-holder objects (not really interesting domain objects at all, not
>>> by classic domain/model design they're not) and invoke logic on those
>>> objects in an algorithmic way: mostly logic that ought to have been in
>>> the "domain" objects. Even where some of the "procedural" code has been
>>> subdivided to make it appear more OO-like, and is parcelled out to
>>> "domain" objects to make them look better, it's awkward and forced.
>>>
>>> Your definition would have it that all the instance code in this latter
>>> category is non-procedural. Again, _technically_ it's OO. But that's
>>> really stretching it.
>>
>> I wrote:
>>     procedural = all static methods
>>     OOP = use of interfaces, private fields public methods
>>
>> It seems as if you are mostly arguing based on:
>>     procedural = some static methods
>>
>> I don't think the presence of some static methods is anti-OO.
>> Several patterns from the GoF book uses static methods.
>
> You're pushing me too far over to one side when you characterize my
> arguments. So far I've said little about static methods - I've been
> noting the misuse of instance methods. I've focused deliberately on
> instance methods because it is easier to disguise their misuse.
>
> As far as static methods go, I don't think the use of *some* static
> methods is bad either. They are inherently procedural, however. You
> acknowledged that to some degree when you equated 'procedural = all
> static'. I happen to think that the bar should be lower, that the more
> of your code that you've jammed into static methods the more procedural
> your code has become. There's no 0/100 black/white here.
>
> I prefer static methods that are non-business-logic implementation
> details, if you've got to use them at all. Like static factory methods.
>
>> And I do not agree with the service methods plus data classes
>> not being OOP argument either.
>
> It's OOP. It's _technically_ OOP. More discussion below.
>
>> Back in the 90's good OOP was rich classes with both methods
>> and data.
>
> Not always "good" OOP. Let's just call that "1990's OOP" or "1990's
> accepted OOP".
>
>> Today good OOP is more focused on the encapsulation aspects
>> (which was my second bullet point).
>>
>> The 90's good OOP is now called "rich domain model".
>>
>> One of the main drivers behind the change IMHO is that it became
>> clear that not everything was a good fit for traditional model. There
>> are simply needs for different focus on data versus method: some
>> classes are method heavy, some classes are a more even mix
>> and some classes are data heavy.
>
> That's exactly right: it became clear that the "emergent" premise behind
> the rich domain model typically failed. People invariably had a
> difficult time deciding where to put all their logic, because much of it
> did not neatly belong to any one domain class. That led either to
> abstract and dubious domain classes for the purpose of holding methods
> that had no better home, or drove that change you referred to above (and
> which I've criticized): creating lots of service classes in an
> application layer, where this difficult-to-place logic gets put as
> instance methods.
>
> As a short-term response to the flaws inherent in the rich domain model
> I have no serious problems with that change. A great deal of logic _is_
> procedural, and you should code it up that way. But let's not call it
> OO. My argument is just that, that a lot of Java code is procedural. I'm
> not saying it's awful. When I previously used language like "ought to
> have been", I'm saying that in reference to what you'd strive for with
> classic, rich domain model OO.
>
> This is my point exactly: that this change to lots of procedural, for
> basically good reasons, has happened in Java (and other class-oriented
> languages like C#). What is a problem is that people continue to insist
> that this procedural code isn't.

My point is that it did not change to procedural - it changed
to a different type of OO.

OO is not a synonym for a rich domain model.

http://en.wikipedia.org/wiki/Object-oriented_programming#Fundamental_features_and_concepts

http://www.purl.org/stefan_ram/pub/doc_kay_oop_en

does not seem to conflict with what you call procedural.

Arne

[toc] | [prev] | [next] | [standalone]

#14341

On 12-05-05 07:17 PM, Arne Vajhøj wrote:
> On 4/29/2012 10:00 AM, Arved Sandstrom wrote:
>> On 12-04-28 11:11 PM, Arne Vajhøj wrote:
>>> On 4/18/2012 6:11 AM, Arved Sandstrom wrote:
>>>> On 12-04-17 11:06 PM, Arne Vajhøj wrote:
>>>>> On 4/17/2012 8:07 PM, Arved Sandstrom wrote:
>>>>>> On 12-04-17 06:50 PM, glen herrmannsfeldt wrote:
>>>>>>> markspace<-@.>    wrote:
>>>>>>>> On 4/17/2012 2:03 PM, Steve Graham wrote:
>>>>>>>>> I've been a programmer for 3 decades working in mostly procedural
>>>>>>>>> languages, although I have done some work with a couple of
>>>>>>>>> object-oriented ones.
>>>>>>>
>>>>>>>>> Which book would you recommend that I read to learn Java?
>>>>>>>>> Obviously, I
>>>>>>>>> don't want to read a beginning programming book, nor do I want to
>>>>>>>>> study
>>>>>>>>> one which presupposes I know something about Java or a lot
>>>>>>>>> about OO
>>>>>>>>> concepts.
>>>>>>>
>>>>>>> You can do procedural programming in Java. You might find it easier
>>>>>>> to start that way, to get used to Java, and then learn the OO stuff.
>>>>>>
>>>>>> I suspect that a cold, hard analysis of all Java code written in the
>>>>>> past 15 years would show that the large majority of it _is_
>>>>>> procedural.
>>>>>>
>>>>>> Fact is, Java and Objective-C and C++, to name a few OOP
>>>>>> languages, are
>>>>>> generally used to write substantially imperative code, where
>>>>>> procedures
>>>>>> appear as object methods. We may as well not ignore that, it's what
>>>>>> most
>>>>>> OO programmers do.
>>>>>>
>>>>>> Having said that, the advantage of objects and OOP shouldn't be
>>>>>> discounted. We simply shouldn't pretend that modern OOP isn't still
>>>>>> largely imperative/procedural code. If we advise the OP to learn
>>>>>> proper
>>>>>> OO - and I certainly do - the fact is that in his studies he's
>>>>>> going to
>>>>>> come across a stupendous amount of imperative Java. I recommend that
>>>>>> the
>>>>>> OP keep this in mind. There are fine resources available for learning
>>>>>> the principles and theory of OOP; one simply has to remember that
>>>>>> much
>>>>>> real-world code deviates substantially.
>>>>>
>>>>> OOP is supposed to be imperative, so I do not see much point in that
>>>>> argument.
>>>>
>>>> OOP isn't "supposed" to be imperative at all, it just happens that most
>>>> mainstream OO languages are. C++, Objective-C, Java etc, those are
>>>> imperative OO languages. But you can and do have languages that are
>>>> functional and use OO, even some that are logical and have elements of
>>>> OO.
>>>>
>>>> To the extent that OO != imperative I don't withdraw my use of the term
>>>> "imperative". But I really meant "procedural", and should have used
>>>> that
>>>> across the board.
>>>>
>>>> However, let's stick to the imperative OO languages here. My
>>>> argument is
>>>> that a great deal of actual (non-teaching) Java code strays
>>>> substantially from best-practice OO, and is best characterized as
>>>> "procedural" and/or "structured" and/or "modular". It doesn't really
>>>> have those extra features that distinguish good OO code.
>>>>
>>>> That is the main argument I am making. And it's about "what is", as a
>>>> caution to the OP, not a reflection on the best Java or even decent
>>>> Java
>>>> that can be written by a programmer who is reasonably well-grounded in
>>>> proper OO. I am pointing out what we often see.
>>>>
>>>>> How big a portion of Java code that is procedural will depend a
>>>>> bit on where you put the bar.
>>>>>
>>>>> If we put the bar relative low:
>>>>>     procedural = all static methods
>>>>>     OOP = use of interfaces, private fields public methods
>>>>> then the majority of Java code is not procedural.
>>>>>
>>>> That's a very low bar, and it's selected to make a lot of Java and C#
>>>> real-world code look good. By that criterion all those large instance
>>>> methods out there that gather in a multitude of behavior-anemic objects
>>>> and perform algorithms on them are OOP. Well, of course they are
>>>> technically OOP.
>>>>
>>>> What's the most classic "procedure" that Java has? The "main" method in
>>>> a main class. That's even one by your definition. Often what people do
>>>> in "main" is call the constructor of the main class, and invoke an
>>>> instance method on it that is the top-level "procedure". Not too much
>>>> really OO-like about that at all.
>>>>
>>>> Let's consider Java EE. No small number of web apps have a fat
>>>> "service"
>>>> or "application" layer that teems with procedural code. Session beans
>>>> and managed beans are loaded with large methods that, despite being
>>>> instance methods, are "procedures" that assemble a variety of
>>>> data-holder objects (not really interesting domain objects at all, not
>>>> by classic domain/model design they're not) and invoke logic on those
>>>> objects in an algorithmic way: mostly logic that ought to have been in
>>>> the "domain" objects. Even where some of the "procedural" code has been
>>>> subdivided to make it appear more OO-like, and is parcelled out to
>>>> "domain" objects to make them look better, it's awkward and forced.
>>>>
>>>> Your definition would have it that all the instance code in this latter
>>>> category is non-procedural. Again, _technically_ it's OO. But that's
>>>> really stretching it.
>>>
>>> I wrote:
>>>     procedural = all static methods
>>>     OOP = use of interfaces, private fields public methods
>>>
>>> It seems as if you are mostly arguing based on:
>>>     procedural = some static methods
>>>
>>> I don't think the presence of some static methods is anti-OO.
>>> Several patterns from the GoF book uses static methods.
>>
>> You're pushing me too far over to one side when you characterize my
>> arguments. So far I've said little about static methods - I've been
>> noting the misuse of instance methods. I've focused deliberately on
>> instance methods because it is easier to disguise their misuse.
>>
>> As far as static methods go, I don't think the use of *some* static
>> methods is bad either. They are inherently procedural, however. You
>> acknowledged that to some degree when you equated 'procedural = all
>> static'. I happen to think that the bar should be lower, that the more
>> of your code that you've jammed into static methods the more procedural
>> your code has become. There's no 0/100 black/white here.
>>
>> I prefer static methods that are non-business-logic implementation
>> details, if you've got to use them at all. Like static factory methods.
>>
>>> And I do not agree with the service methods plus data classes
>>> not being OOP argument either.
>>
>> It's OOP. It's _technically_ OOP. More discussion below.
>>
>>> Back in the 90's good OOP was rich classes with both methods
>>> and data.
>>
>> Not always "good" OOP. Let's just call that "1990's OOP" or "1990's
>> accepted OOP".
>>
>>> Today good OOP is more focused on the encapsulation aspects
>>> (which was my second bullet point).
>>>
>>> The 90's good OOP is now called "rich domain model".
>>>
>>> One of the main drivers behind the change IMHO is that it became
>>> clear that not everything was a good fit for traditional model. There
>>> are simply needs for different focus on data versus method: some
>>> classes are method heavy, some classes are a more even mix
>>> and some classes are data heavy.
>>
>> That's exactly right: it became clear that the "emergent" premise behind
>> the rich domain model typically failed. People invariably had a
>> difficult time deciding where to put all their logic, because much of it
>> did not neatly belong to any one domain class. That led either to
>> abstract and dubious domain classes for the purpose of holding methods
>> that had no better home, or drove that change you referred to above (and
>> which I've criticized): creating lots of service classes in an
>> application layer, where this difficult-to-place logic gets put as
>> instance methods.
>>
>> As a short-term response to the flaws inherent in the rich domain model
>> I have no serious problems with that change. A great deal of logic _is_
>> procedural, and you should code it up that way. But let's not call it
>> OO. My argument is just that, that a lot of Java code is procedural. I'm
>> not saying it's awful. When I previously used language like "ought to
>> have been", I'm saying that in reference to what you'd strive for with
>> classic, rich domain model OO.
>>
>> This is my point exactly: that this change to lots of procedural, for
>> basically good reasons, has happened in Java (and other class-oriented
>> languages like C#). What is a problem is that people continue to insist
>> that this procedural code isn't.
> 
> My point is that it did not change to procedural - it changed
> to a different type of OO.
> 
> OO is not a synonym for a rich domain model.
> 
> http://en.wikipedia.org/wiki/Object-oriented_programming#Fundamental_features_and_concepts
> 

Believe me, I know. I experiment with Self a lot, have for a few years.
My first exposure to OOP - as in seriously thinking about it - was
actually Prograph about 20 years ago, followed by Smalltalk and C++ and
Perl 5 OOP shortly after. Add into that Javascript and Ruby and so
forth, and I think I have probably been more an object-oriented OO guy
rather than a class-oriented OO guy right from the gitgo. When you think
objects, even in a language like C# or Java that wants you to think of
class instances, you tend to not have a rich/anemic domain mindset in
the first place.

None of these languages really made me think about rich domain objects;
I didn't start reading about that until Java had been around for a
while...it seems like the OOP pundits wrote some of the more well-known
rich-domain model articles (like Fowler's article about anemic domain
models in 2003) after the evidence was starting to amass that rich
domain was actually problematic.

I won't say that I have written either predominantly rich or anemic
domain classes, I think over the past few decades it's been a mix as
required.

Fowler and his adherents, and the DDD people, would never have pushed
their ideas if there weren't a lot of folks who *never* bought into the
rich domain model in the first place. In other words, there have always
been a lot of OO programmers who write procedural.

> http://www.purl.org/stefan_ram/pub/doc_kay_oop_en
> 
> does not seem to conflict with what you call procedural.
> 
> Arne

No, I don't think it does either. As you may have gathered from the
above, I'm very comfortable in a object-based OO environment as opposed
to a class-based OO environment, and I like the way Kay minimalizes what
is really essential.

I think of OO as being about objects - period - and to me an object is a
bundle of data that can do stuff to itself. That a great deal of teh
overall program code might be non-object, and simply call upon objects
when necessary, is not a concept I have an issue with.

AHS
-- 
Never interrupt your enemy when he is making a mistake.
--Napoleon

[toc] | [prev] | [next] | [standalone]

#14364

On Sun, 06 May 2012 15:49:29 -0300, Arved Sandstrom
<asandstrom3minus1@eastlink.ca> wrote:

[snip]

>I think of OO as being about objects - period - and to me an object is a
>bundle of data that can do stuff to itself. That a great deal of teh
>overall program code might be non-object, and simply call upon objects
>when necessary, is not a concept I have an issue with.

     You had to tell them that the emperor is wearing no clothes!

     I agree with you.  OOP is useful, but my toolbox is much bigger.

     Forks are very useful for eating with, but I also use spoons and
knives.  And chopsticks.  And.

Sincerely,

Gene Wirchenko

[toc] | [prev] | [next] | [standalone]

#13660

On 17/04/2012 22:50, glen herrmannsfeldt wrote:
> markspace<-@.>  wrote:
>> On 4/17/2012 2:03 PM, Steve Graham wrote:
>>> I've been a programmer for 3 decades working in mostly procedural
>>> languages, although I have done some work with a couple of
>>> object-oriented ones.
>
>>> Which book would you recommend that I read to learn Java? Obviously, I
>>> don't want to read a beginning programming book, nor do I want to study
>>> one which presupposes I know something about Java or a lot about OO
>>> concepts.
>
> You can do procedural programming in Java. You might find it easier
> to start that way, to get used to Java, and then learn the OO stuff.

I'd strongly advise against this. An awful lot of Java programming 
consists of using the standard libraries. To do so effectively I really 
think you have to start by learning Java OO.

There is an O'Reilly book called "Learning Java". I found it helpful. 
The online resources referred to by others are also good for initial 
learning. The other books suggested (Effective Java, Java Concurrency) 
are very good but I'd suggest not starting with them (don't delay 
reading them too long either)

Just my ¤0.02 worth.

-- 
RGB

[toc] | [prev] | [next] | [standalone]

#13620

On 4/17/2012 5:03 PM, Steve Graham wrote:
> I've been a programmer for 3 decades working in mostly procedural
> languages, although I have done some work with a couple of
> object-oriented ones.
>
> Which book would you recommend that I read to learn Java? Obviously, I
> don't want to read a beginning programming book, nor do I want to study
> one which presupposes I know something about Java or a lot about OO
> concepts.

I think you need a book like this one:

http://www.wrox.com/WileyCDA/WroxTitle/Professional-Java-JDK-6-Edition.productCd-0471777102.html

Note that I do not know the specific book, but other of
Wrox'es "Professional Xxxxx" are good.

Arne

[toc] | [prev] | [next] | [standalone]

#13625

On 4/17/2012 2:03 PM, Steve Graham wrote:
> I've been a programmer for 3 decades working in mostly procedural
> languages, although I have done some work with a couple of
> object-oriented ones.
>
> Which book would you recommend that I read to learn Java? Obviously, I
> don't want to read a beginning programming book, nor do I want to study
> one which presupposes I know something about Java or a lot about OO
> concepts.

I sometimes find a beginner book or tutorial works best, especially if
the programming language I'm learning requires a change of mindset.

When I do that, I have a definite procedure for each section. I first
read it very quickly, skipping details and trying to find out what it is
about.

If I think it is something I understand, I go on to the programming
exercises for that section. If I can do them quickly, I really did
understand it, and can go on to the next section.

If I have trouble with the programming exercises or if the content looks
unfamiliar on a quick scan, I read it properly before (re)attempting the
exercises.

The key is to do the programming exercises. That both checks that I'm
not skipping anything I need to read fully, and gets the basics of the
language into my fingers.

Patricia

[toc] | [prev] | [next] | [standalone]

#13935

On Tue, 17 Apr 2012 15:03:07 -0600, Steve Graham
<jsgrahamus@yahoo.com> wrote, quoted or indirectly quoted someone who
said :

>I've been a programmer for 3 decades working in mostly procedural 
>languages, although I have done some work with a couple of 
>object-oriented ones.

see http://mindprod.com/jgloss/gettingstarted.html
-- 
Roedy Green Canadian Mind Products
http://mindprod.com
When you were a child, if you did your own experiment
to see if it was better to put to cocoa into your cup first
or the hot milk first, then you likely have the programmer gene..

[toc] | [prev] | [next] | [standalone]

#14557

Steve Graham wrote:
> I've been a programmer for 3 decades working in mostly procedural
> languages, although I have done some work with a couple of
> object-oriented ones.
>
> Which book would you recommend that I read to learn Java? Obviously, I
> don't want to read a beginning programming book, nor do I want to study
> one which presupposes I know something about Java or a lot about OO
> concepts.
>
> Thanks, Steve

Thank you all for your suggestions.  Steve

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

Back to top | Article view | comp.lang.java.programmer

csiph-web