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

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

Java primitive variable objects

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

Contents

  Java primitive variable objects Eric Douglas <e.d.programmer@gmail.com> - 2015-11-02 10:11 -0800
    Re: Java primitive variable objects Eric Sosman <esosman@comcast-dot-net.invalid> - 2015-11-02 14:15 -0500
      Re: Java primitive variable objects Eric Douglas <e.d.programmer@gmail.com> - 2015-11-02 13:03 -0800
        Re: Java primitive variable objects Eric Sosman <esosman@comcast-dot-net.invalid> - 2015-11-02 16:29 -0500
    Re: Java primitive variable objects Jan Burse <janburse@fastmail.fm> - 2015-11-02 22:46 +0100
      Re: Java primitive variable objects Jan Burse <janburse@fastmail.fm> - 2015-11-02 22:52 +0100
      Re: Java primitive variable objects Eric Sosman <esosman@comcast-dot-net.invalid> - 2015-11-02 17:47 -0500
    Re: Java primitive variable objects Joerg Meier <joergmmeier@arcor.de> - 2015-11-05 22:19 +0100
      Re: Java primitive variable objects Eric Douglas <e.d.programmer@gmail.com> - 2015-11-05 13:31 -0800
        Re: Java primitive variable objects Arne Vajhøj <arne@vajhoej.dk> - 2015-11-07 22:21 -0500
          Re: Java primitive variable objects Eric Douglas <e.d.programmer@gmail.com> - 2015-11-09 04:52 -0800
            Re: Java primitive variable objects Jerry Stuckle <jstucklex@attglobal.net> - 2015-11-09 08:54 -0500
              Re: Java primitive variable objects Eric Douglas <e.d.programmer@gmail.com> - 2015-11-09 07:27 -0800
                Re: Java primitive variable objects Jerry Stuckle <jstucklex@attglobal.net> - 2015-11-09 10:51 -0500
                  Re: Java primitive variable objects Eric Douglas <e.d.programmer@gmail.com> - 2015-11-09 08:28 -0800
                    Re: Java primitive variable objects Jerry Stuckle <jstucklex@attglobal.net> - 2015-11-09 11:57 -0500
                      Re: Java primitive variable objects Eric Douglas <e.d.programmer@gmail.com> - 2015-11-09 10:13 -0800
                      Re: Java primitive variable objects Eric Sosman <esosman@comcast-dot-net.invalid> - 2015-11-09 13:28 -0500
                        Re: Java primitive variable objects Jerry Stuckle <jstucklex@attglobal.net> - 2015-11-09 14:53 -0500
                        Re: Java primitive variable objects Nigel Wade <nmw@ion.le.ac.uk> - 2015-11-10 09:27 +0000
                      Re: Java primitive variable objects "Jeffrey H. Coffield" <jeffrey@digitalsynergyinc.com> - 2015-11-09 10:44 -0800
                      Re: Java primitive variable objects Martin Gregorie <martin@address-in-sig.invalid> - 2015-11-09 18:59 +0000
                        Re: Java primitive variable objects Jerry Stuckle <jstucklex@attglobal.net> - 2015-11-09 15:02 -0500
                          Re: Java primitive variable objects Martin Gregorie <martin@address-in-sig.invalid> - 2015-11-09 22:57 +0000
                            Re: Java primitive variable objects Jerry Stuckle <jstucklex@attglobal.net> - 2015-11-09 19:16 -0500
                      Re: Java primitive variable objects Arne Vajhøj <arne@vajhoej.dk> - 2015-11-09 20:55 -0500
                        Re: Java primitive variable objects Jerry Stuckle <jstucklex@attglobal.net> - 2015-11-09 22:13 -0500
                  Re: Java primitive variable objects Arne Vajhøj <arne@vajhoej.dk> - 2015-11-09 20:40 -0500
                    Re: Java primitive variable objects Jerry Stuckle <jstucklex@attglobal.net> - 2015-11-09 22:23 -0500
            Re: Java primitive variable objects Martin Gregorie <martin@address-in-sig.invalid> - 2015-11-09 14:00 +0000
              Re: Java primitive variable objects Eric Douglas <e.d.programmer@gmail.com> - 2015-11-09 07:18 -0800
                Re: Java primitive variable objects Arne Vajhøj <arne@vajhoej.dk> - 2015-11-09 20:43 -0500
            Re: Java primitive variable objects Arne Vajhøj <arne@vajhoej.dk> - 2015-11-09 19:38 -0500
              Re: Java primitive variable objects Jerry Stuckle <jstucklex@attglobal.net> - 2015-11-09 20:26 -0500
                Re: Java primitive variable objects Martin Gregorie <martin@address-in-sig.invalid> - 2015-11-10 02:10 +0000
                  Re: Java primitive variable objects Jerry Stuckle <jstucklex@attglobal.net> - 2015-11-09 22:12 -0500
                    Re: Java primitive variable objects Martin Gregorie <martin@address-in-sig.invalid> - 2015-11-10 13:01 +0000
                      Re: Java primitive variable objects Jerry Stuckle <jstucklex@attglobal.net> - 2015-11-10 12:23 -0500
                        Re: Java primitive variable objects Eric Douglas <e.d.programmer@gmail.com> - 2015-11-10 10:10 -0800
                          Re: Java primitive variable objects Arne Vajhøj <arne@vajhoej.dk> - 2015-11-10 22:08 -0500
                        Re: Java primitive variable objects Martin Gregorie <martin@address-in-sig.invalid> - 2015-11-10 20:05 +0000
                          Re: Java primitive variable objects Eric Douglas <e.d.programmer@gmail.com> - 2015-11-10 13:21 -0800
                            Re: Java primitive variable objects Martin Gregorie <martin@address-in-sig.invalid> - 2015-11-10 23:30 +0000
                            Re: Java primitive variable objects Jerry Stuckle <jstucklex@attglobal.net> - 2015-11-10 20:58 -0500
                            Re: Java primitive variable objects Gene Wirchenko <genew@telus.net> - 2015-11-10 22:30 -0800
                    Re: Java primitive variable objects Arne Vajhøj <arne@vajhoej.dk> - 2015-11-10 21:58 -0500
                Re: Java primitive variable objects Arne Vajhøj <arne@vajhoej.dk> - 2015-11-10 21:56 -0500
                  Re: Java primitive variable objects Jerry Stuckle <jstucklex@attglobal.net> - 2015-11-10 22:19 -0500
                    Re: Java primitive variable objects Arne Vajhøj <arne@vajhoej.dk> - 2015-11-10 22:42 -0500
                      Re: Java primitive variable objects Jerry Stuckle <jstucklex@attglobal.net> - 2015-11-10 23:07 -0500
              Re: Java primitive variable objects Eric Douglas <e.d.programmer@gmail.com> - 2015-11-10 06:06 -0800
    Re: Java primitive variable objects Lew <lewbloch@gmail.com> - 2015-11-16 14:47 -0800

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

#33081

On Tue, 10 Nov 2015 12:23:26 -0500, Jerry Stuckle wrote:

> You can teach a person facts, but you cannot teach them to learn.  That
> can only come from one's self desire.
>
I'm not so sure. I think that, if you expose people to the techniques of 
picking the essentials out of a mass of detail, both by example and by 
giving them practical exercises in doing it you can give them the skills 
they need to analyse and solve problems and to generalise these solutions 
to related problems. This skill set, along with the ability to 
concentrate on the task in hand, has to be the basis of self-motivated 
learning. 

One thing's for sure: if you're not encouraged to pick up that skill set 
and get comfortable using it, then self-directed learning will be very 
much harder, and will probably be impossible if you can't or won't 
concentrate on what you're doing.

>>> For instance, when I was in college, there was no C, much less C++. 
>>> So how was my university supposed to teach it?
>>>
>> They weren't, but if they did turned out properly educated graduates,
>> they'd be equipped to learn new languages by themselves.
>> 
>> 
> Yes and no.  I used to teach in the corporate world (contract
> instructor).  Among the classes I taught were Java and C++.  And, of
> course, within those courses were OO techniques.  The syntax of the
> language was easy for most students to pick up.  OO concepts were much
> harder for most students.
> 
Thats sort of what I'm saying, I think. Learning the syntax of a language 
is pretty much rote learning and gets ingrained by repetitive use, while 
OO techniques are a higher level abstract skill set that can be much more 
widely employed.

> But you already had a similar language, so it wasn't much of a jump for
> you.
>
Yeah, but PL/9 wasn't much like anything I'd used previously - block 
structures and a vaguely Algol/Pascal-like set of reserved words was 
about it.

I'd previously used Algol 60 10-15 years previously and never since, and 
had picked up Algol 68 6 years previously and, err, that was about it. C, 
was well in the future. 

IIRC I was using TAL before I was fluent in C although I had a C compiler 
on my 8/16 bit 6809 box, but scarcely touched it because it was 
agonisingly slow compared with PL/9. Where the C the editor and all four 
compiler phases were separately loaded and run in sequence from floppy 
disk to do a compilation, the PL/9 editor,compiler,debugger, source and 
compiled code were all memory resident and so a small compilation took 
literally 1-2 seconds - or a bit longer if you were pulling in additional 
source files from disk, but still hugely faster than that C compiler. 

> No, *I* equipped myself to learn.  The university just taught me the
> sciences of the day.
>
I'd respeckfully suggest that by treating CS as a branch of science or 
engineering rather than arts, your college would have provided a good 
grounding in the abstractions and thought processes those disciplines use 
and that may have more influential that you may realise.



-- 
martin@   | Martin Gregorie
gregorie. | Essex, UK
org       |

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

#33082

On Tuesday, November 10, 2015 at 3:08:31 PM UTC-5, Martin Gregorie wrote:
> Thats sort of what I'm saying, I think. Learning the syntax of a language 
> is pretty much rote learning and gets ingrained by repetitive use, while 
> OO techniques are a higher level abstract skill set that can be much more 
> widely employed.

C++ language was horrible with pointers allowing people to write code that didn't do what they expected it to do.  The basic abstract OO concept that your variable is now a container which may have other variables inside it as well as methods to execute some code should be easy.  The trickier part would be recognizing that an instance variable is not an object but a pointer to that object, so if you pass an object variable into a method you get 2 pointers to the same container, and I did write one memory leak myself, keeping links to objects using private variables in other objects so I was unable to access the linked objects myself and they were unable to be garbage collected.

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

#33084

On Tue, 10 Nov 2015 13:21:44 -0800, Eric Douglas wrote:

> On Tuesday, November 10, 2015 at 3:08:31 PM UTC-5, Martin Gregorie
> wrote:
>> Thats sort of what I'm saying, I think. Learning the syntax of a
>> language is pretty much rote learning and gets ingrained by repetitive
>> use, while OO techniques are a higher level abstract skill set that can
>> be much more widely employed.
> 
> C++ language was horrible with pointers allowing people to write code
> that didn't do what they expected it to do.  The basic abstract OO
> concept that your variable is now a container which may have other
> variables inside it as well as methods to execute some code should be
> easy.  The trickier part would be recognizing that an instance variable
> is not an object but a pointer to that object, so if you pass an object
> variable into a method you get 2 pointers to the same container, and I
> did write one memory leak myself, keeping links to objects using private
> variables in other objects so I was unable to access the linked objects
> myself and they were unable to be garbage collected.

As I've said, I don't much like C++ for a number of reasons. Finding that

   #include <iostream> 

   int main()
   {
      std::cout << "\nHello, World\n";
   }

compiled to 800kB with Borland C3.0 while

   #include <stdio.h>

   int main(int argc, char **argv)
   {
      printf("Hello, World\n");
   }

was compiled to around 1400 bytes with the same compiler didn't exactly 
impress me. Things have moved on though: the figures for the current GNU 
compiler are much closer at 7684 and 7304 bytes respectively.

However, my main objections are that:

- like Python and Perl, it is only an optionally OO language. By that I
  mean that, as shown above, you can write an entirely non-OO program
  with it, and indeed none of the few large-scale C++ programs I've
  looked at defined any objects at all. They were all nothing but ANSI C
  with  "// comments" instead of "/* comments */" and .cpp source file
  extensions.

- I found its syntax somewhat contrived and over-complex. Java is much
  closer to the minimal approach of C than to the elaboration of C++ and
  is easier to read as a direct consequence.

- Since K&R's "The C Programming Language" is such an excellent book 
  as a teach-yourself C text, of course my first move was to get a copy of
  Stroustrup's "The C++ Programming Language". But I found it very poor: 
  not nearly as well organised, harder to read and with the concepts 
  not nearly as well described and illustrated.
 
Somewhat later I was introduced the Java: granted there doesn't seem to a 
Java book that can match K&R, but I found the one I got (Ivor Horton) to 
be considerably better and much more understandable than Stroustroup and, 
as a major plus, Java didn't introduce all those unmemorable operators.

So, that's my personal take on why I don't like C++ and prefer Java to 
the other OO languages I've looked at. 

Of course, it goes without saying that YMMV.
  

-- 
martin@   | Martin Gregorie
gregorie. | Essex, UK
org       |

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

#33087

On 11/10/2015 4:21 PM, Eric Douglas wrote:
> On Tuesday, November 10, 2015 at 3:08:31 PM UTC-5, Martin Gregorie wrote:
>> Thats sort of what I'm saying, I think. Learning the syntax of a language 
>> is pretty much rote learning and gets ingrained by repetitive use, while 
>> OO techniques are a higher level abstract skill set that can be much more 
>> widely employed.
> 
> C++ language was horrible with pointers allowing people to write code that didn't do what they expected it to do.  The basic abstract OO concept that your variable is now a container which may have other variables inside it as well as methods to execute some code should be easy.  The trickier part would be recognizing that an instance variable is not an object but a pointer to that object, so if you pass an object variable into a method you get 2 pointers to the same container, and I did write one memory leak myself, keeping links to objects using private variables in other objects so I was unable to access the linked objects myself and they were unable to be garbage collected.
> 

I've never had that problem with pointers.  But then I don't try to
misuse pointers.

Both C and C++ put more emphasis on the programmer and good coding
practices.  It results in smaller and more efficient code than languages
like Java.  At the same time, they are more efficient because they
aren't constantly checking for programmer errors.

Java has its uses, though, also.  Its biggest advantage is its platform
independence.  Another is that it doesn't demand as much of the
programmer, and is more forgiving of programmer errors.

-- 
==================
Remove the "x" from my email address
Jerry Stuckle
jstucklex@attglobal.net
==================

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

#33100

On 10 Nov 2015 23:31:10 GMT, ram@zedat.fu-berlin.de (Stefan Ram)
wrote:

[snip]

>  (I had a student in my class who said, »everyone in this room
>  knows what object-oriented programming is.« I asked him,
>  what it is, and he answered, »it's programming with windows«
>  (he referred to GUI programming, not Microsoft® Windows).)

     I had a similar thing thrown at me in a list.  I had referred to
various awkwardnesses with the GUI IDE and was asked why did I use the
particular language if I disliked OOP so much?  I replied that I liked
OOP just fine; what I did not like was the GUI IDE.

[snip]

Sincerely,

Gene Wirchenko

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

#33092

On 11/9/2015 10:12 PM, Jerry Stuckle wrote:
> On 11/9/2015 9:10 PM, Martin Gregorie wrote:
>> On Mon, 09 Nov 2015 20:26:53 -0500, Jerry Stuckle wrote:
>>> On 11/9/2015 7:38 PM, Arne Vajhøj wrote:
>>>> Universities are supposed to teach students something that will help
>>>> them through a career of 40-45 years.
>>>>
>>>>
>>> That's hard to do in any of the sciences today.  The world is changing
>>> too quickly.
>>>
>> Yes, but its what a *University* should be doing - and apparently a
>> number of US State universities weren't doing it in the 70s and haven't
>> changed their ways 20 years later, as confirmed by ED. The question is:
>> have they changed since then.
>
> It's hard for a university to teach students something that won't even
> exist for 20 years.  For instance, when I was in college, there was no
> C, much less C++.  So how was my university supposed to teach it?

Obviously they could not.

But maybe they should have taught Algol.

Also a very fine language for learning programming.

Arne

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

#33091

On 11/9/2015 8:26 PM, Jerry Stuckle wrote:
> On 11/9/2015 7:38 PM, Arne Vajhøj wrote:
>> On 11/9/2015 7:52 AM, Eric Douglas wrote:
>>> On Saturday, November 7, 2015 at 10:21:54 PM UTC-5, Arne Vajhøj wrote:
>>>> In the 90's you should have been taught Pascal and/or C++ (which
>>>> both has enums) if the school had been following trends.
>>>
>>> I've never heard of either of those being used for business applications.
>>> I went to college from 1993 to 1996.  Most companies were using COBOL.
>>> I did have one intro to C++ course.
>>
>> Universities are supposed to teach students something that will help
>> them through a career of 40-45 years.
>
> That's hard to do in any of the sciences today.  The world is changing
> too quickly.

Yes and no.

Specific stuff is changing very rapidly.

Basic concepts does not change.

Which is exactly my point - universities should teach the basic
concepts not the specific stuff that are obsolete next year.

>> At that time I think it both made sense and was common to use
>> Pascal or C++.
>>
>
> PASCAL has never been big in business.  C++ is to some extent, but still
> not as popular as C.

Yes.

But again - it is not the universities job to teach the languages
that the industry need this year or this decade - it is their job
to teach stuff that will remain useful.

Pascal and C++ was good languages for that at the time.

Today Java and Python would be more suited.

>> C and C++ was already making serious inroads into business. And
>> everybody knew that OO would be the big thing - it was just
>> not clear what languages it would be besides C++.
>
> Not in the financial sector, it isn't - which includes banks, insurance
> companies, governments, and many, many more.  It still can't beat
> COBOL's packed decimal datatype for numeric operations.  And OO is good
> for a lot of things, but it's definitely not the answer to everything
> programming.

Sorry to burst your bubble, but try look at what banks are actual
looking for.

JP Morgan:

825 jobs requiring Java
22 jobs requiring COBOL

Bank of America:

99 jobs requiring Java
9 jobs requiring COBOL

Citigroup:

577 jobs requiring Java
14 jobs requiring COBOL

Banks seems to be doing fine with OO and Java

(I will assume that they typical use BigDecimal for money)

Arne

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

#33095

On 11/10/2015 9:56 PM, Arne Vajhøj wrote:
> On 11/9/2015 8:26 PM, Jerry Stuckle wrote:
>> On 11/9/2015 7:38 PM, Arne Vajhøj wrote:
>>> On 11/9/2015 7:52 AM, Eric Douglas wrote:
>>>> On Saturday, November 7, 2015 at 10:21:54 PM UTC-5, Arne Vajhøj wrote:
>>>>> In the 90's you should have been taught Pascal and/or C++ (which
>>>>> both has enums) if the school had been following trends.
>>>>
>>>> I've never heard of either of those being used for business
>>>> applications.
>>>> I went to college from 1993 to 1996.  Most companies were using COBOL.
>>>> I did have one intro to C++ course.
>>>
>>> Universities are supposed to teach students something that will help
>>> them through a career of 40-45 years.
>>
>> That's hard to do in any of the sciences today.  The world is changing
>> too quickly.
> 
> Yes and no.
> 
> Specific stuff is changing very rapidly.
> 
> Basic concepts does not change.
>

Incorrect.  For instance, OO and relational databases did not exist when
I was in college.  Basic concepts DO change.

> Which is exactly my point - universities should teach the basic
> concepts not the specific stuff that are obsolete next year.
> 
>>> At that time I think it both made sense and was common to use
>>> Pascal or C++.
>>>
>>
>> PASCAL has never been big in business.  C++ is to some extent, but still
>> not as popular as C.
> 
> Yes.
> 
> But again - it is not the universities job to teach the languages
> that the industry need this year or this decade - it is their job
> to teach stuff that will remain useful.
> 
> Pascal and C++ was good languages for that at the time.
> 
> Today Java and Python would be more suited.
> 

Neither Java nor Python score in the top programming languages wanted
today.  Java was more popular 20 years ago, but has fallen to some
extent.  And Python is really only popular for websites, and not that
much there.

>>> C and C++ was already making serious inroads into business. And
>>> everybody knew that OO would be the big thing - it was just
>>> not clear what languages it would be besides C++.
>>
>> Not in the financial sector, it isn't - which includes banks, insurance
>> companies, governments, and many, many more.  It still can't beat
>> COBOL's packed decimal datatype for numeric operations.  And OO is good
>> for a lot of things, but it's definitely not the answer to everything
>> programming.
> 
> Sorry to burst your bubble, but try look at what banks are actual
> looking for.
> 
> JP Morgan:
> 
> 825 jobs requiring Java
> 22 jobs requiring COBOL
> 
> Bank of America:
> 
> 99 jobs requiring Java
> 9 jobs requiring COBOL
> 
> Citigroup:
> 
> 577 jobs requiring Java
> 14 jobs requiring COBOL
> 
> Banks seems to be doing fine with OO and Java
> 
> (I will assume that they typical use BigDecimal for money)
> 
> Arne
> 
> 

Again, you think job listings on dice.com are an indication.  They are
not.  For instance - I used to have Bank of America as one of my
clients.  COBOL is very heavily used by them, and they have far more
COBOL programmers than anyone else.

The difference is - COBOL programmers at banks get good pay, good
benefits, and good retirement.  There is very little turnover of COBOL
programmers at large companies.

Your "evidence" more shows what isn't in much demand because the jobs
are short-term and unstable.

-- 
==================
Remove the "x" from my email address
Jerry Stuckle
jstucklex@attglobal.net
==================

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

#33096

On 11/10/2015 10:19 PM, Jerry Stuckle wrote:
> On 11/10/2015 9:56 PM, Arne Vajhøj wrote:
>> On 11/9/2015 8:26 PM, Jerry Stuckle wrote:
>>> On 11/9/2015 7:38 PM, Arne Vajhøj wrote:
>>>> On 11/9/2015 7:52 AM, Eric Douglas wrote:
>>>>> On Saturday, November 7, 2015 at 10:21:54 PM UTC-5, Arne Vajhøj wrote:
>>>>>> In the 90's you should have been taught Pascal and/or C++ (which
>>>>>> both has enums) if the school had been following trends.
>>>>>
>>>>> I've never heard of either of those being used for business
>>>>> applications.
>>>>> I went to college from 1993 to 1996.  Most companies were using COBOL.
>>>>> I did have one intro to C++ course.
>>>>
>>>> Universities are supposed to teach students something that will help
>>>> them through a career of 40-45 years.
>>>
>>> That's hard to do in any of the sciences today.  The world is changing
>>> too quickly.
>>
>> Yes and no.
>>
>> Specific stuff is changing very rapidly.
>>
>> Basic concepts does not change.
>
> Incorrect.  For instance, OO and relational databases did not exist when
> I was in college.  Basic concepts DO change.

No.

New basic concepts get added.

The old ones are still relevant.

>> Which is exactly my point - universities should teach the basic
>> concepts not the specific stuff that are obsolete next year.
>>
>>>> At that time I think it both made sense and was common to use
>>>> Pascal or C++.
>>>>
>>>
>>> PASCAL has never been big in business.  C++ is to some extent, but still
>>> not as popular as C.
>>
>> Yes.
>>
>> But again - it is not the universities job to teach the languages
>> that the industry need this year or this decade - it is their job
>> to teach stuff that will remain useful.
>>
>> Pascal and C++ was good languages for that at the time.
>>
>> Today Java and Python would be more suited.
>
> Neither Java nor Python score in the top programming languages wanted
> today.

Java is the most used programming language today.

>        Java was more popular 20 years ago,

Java was not officially released 20 years ago!

>>>> C and C++ was already making serious inroads into business. And
>>>> everybody knew that OO would be the big thing - it was just
>>>> not clear what languages it would be besides C++.
>>>
>>> Not in the financial sector, it isn't - which includes banks, insurance
>>> companies, governments, and many, many more.  It still can't beat
>>> COBOL's packed decimal datatype for numeric operations.  And OO is good
>>> for a lot of things, but it's definitely not the answer to everything
>>> programming.
>>
>> Sorry to burst your bubble, but try look at what banks are actual
>> looking for.
>>
>> JP Morgan:
>>
>> 825 jobs requiring Java
>> 22 jobs requiring COBOL
>>
>> Bank of America:
>>
>> 99 jobs requiring Java
>> 9 jobs requiring COBOL
>>
>> Citigroup:
>>
>> 577 jobs requiring Java
>> 14 jobs requiring COBOL
>>
>> Banks seems to be doing fine with OO and Java
>>
>> (I will assume that they typical use BigDecimal for money)

> Again, you think job listings on dice.com are an indication.

Not dice.com - the banks own web site.

>                                                                They are
> not.  For instance - I used to have Bank of America as one of my
> clients.  COBOL is very heavily used by them, and they have far more
> COBOL programmers than anyone else.

That is just another anecdotal story.

(and from a guy that claim Java was more popular before it got
release than now)

> The difference is - COBOL programmers at banks get good pay, good
> benefits, and good retirement.  There is very little turnover of COBOL
> programmers at large companies.

Nice hypothesis.

But not likely to be true.

If we look at the entire job market not just banks then the facts
tell a very different story.

Indeed.com tracks salary levels:

Java - 102 K$ average
Cobol - 78 K$ average

So does itjobwatch in the UK:

Java - 52.5 K£ average
COBOL - 45 K£ average

> Your "evidence" more shows what isn't in much demand because the jobs
> are short-term and unstable.

There is no evidence to support that.

But even if it were true, then it would not matter. No need to
train for well paid jobs that never become available.

Arne

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

#33097

On 11/10/2015 10:42 PM, Arne Vajhøj wrote:
> On 11/10/2015 10:19 PM, Jerry Stuckle wrote:
>> On 11/10/2015 9:56 PM, Arne Vajhøj wrote:
>>> On 11/9/2015 8:26 PM, Jerry Stuckle wrote:
>>>> On 11/9/2015 7:38 PM, Arne Vajhøj wrote:
>>>>> On 11/9/2015 7:52 AM, Eric Douglas wrote:
>>>>>> On Saturday, November 7, 2015 at 10:21:54 PM UTC-5, Arne Vajhøj
>>>>>> wrote:
>>>>>>> In the 90's you should have been taught Pascal and/or C++ (which
>>>>>>> both has enums) if the school had been following trends.
>>>>>>
>>>>>> I've never heard of either of those being used for business
>>>>>> applications.
>>>>>> I went to college from 1993 to 1996.  Most companies were using
>>>>>> COBOL.
>>>>>> I did have one intro to C++ course.
>>>>>
>>>>> Universities are supposed to teach students something that will help
>>>>> them through a career of 40-45 years.
>>>>
>>>> That's hard to do in any of the sciences today.  The world is changing
>>>> too quickly.
>>>
>>> Yes and no.
>>>
>>> Specific stuff is changing very rapidly.
>>>
>>> Basic concepts does not change.
>>
>> Incorrect.  For instance, OO and relational databases did not exist when
>> I was in college.  Basic concepts DO change.
> 
> No.
> 
> New basic concepts get added.
> 
> The old ones are still relevant.
>

The old ones are still relevant - but new ones are developed.  The basic
concepts *DO CHANGE*.

>>> Which is exactly my point - universities should teach the basic
>>> concepts not the specific stuff that are obsolete next year.
>>>
>>>>> At that time I think it both made sense and was common to use
>>>>> Pascal or C++.
>>>>>
>>>>
>>>> PASCAL has never been big in business.  C++ is to some extent, but
>>>> still
>>>> not as popular as C.
>>>
>>> Yes.
>>>
>>> But again - it is not the universities job to teach the languages
>>> that the industry need this year or this decade - it is their job
>>> to teach stuff that will remain useful.
>>>
>>> Pascal and C++ was good languages for that at the time.
>>>
>>> Today Java and Python would be more suited.
>>
>> Neither Java nor Python score in the top programming languages wanted
>> today.
> 
> Java is the most used programming language today.
> 
>>        Java was more popular 20 years ago,
> 
> Java was not officially released 20 years ago!
> 

Actually, it was - the first alpha and beta releases were in 1995.  The
first stable release was January, 1996 - 20 years less two months ago.
Close enough.

>>>>> C and C++ was already making serious inroads into business. And
>>>>> everybody knew that OO would be the big thing - it was just
>>>>> not clear what languages it would be besides C++.
>>>>
>>>> Not in the financial sector, it isn't - which includes banks, insurance
>>>> companies, governments, and many, many more.  It still can't beat
>>>> COBOL's packed decimal datatype for numeric operations.  And OO is good
>>>> for a lot of things, but it's definitely not the answer to everything
>>>> programming.
>>>
>>> Sorry to burst your bubble, but try look at what banks are actual
>>> looking for.
>>>
>>> JP Morgan:
>>>
>>> 825 jobs requiring Java
>>> 22 jobs requiring COBOL
>>>
>>> Bank of America:
>>>
>>> 99 jobs requiring Java
>>> 9 jobs requiring COBOL
>>>
>>> Citigroup:
>>>
>>> 577 jobs requiring Java
>>> 14 jobs requiring COBOL
>>>
>>> Banks seems to be doing fine with OO and Java
>>>
>>> (I will assume that they typical use BigDecimal for money)
> 
>> Again, you think job listings on dice.com are an indication.
> 
> Not dice.com - the banks own web site.
>

Again, you confuse job listings with current employment.  Bad data is
worse than none at all.  How about real figures - like the number of LOC
each one generates in each language each year?

>>                                                                They are
>> not.  For instance - I used to have Bank of America as one of my
>> clients.  COBOL is very heavily used by them, and they have far more
>> COBOL programmers than anyone else.
> 
> That is just another anecdotal story.
> 

Of course it is - because it conflicts with your fantasies.

> (and from a guy that claim Java was more popular before it got
> release than now)
> 

As I said above.

>> The difference is - COBOL programmers at banks get good pay, good
>> benefits, and good retirement.  There is very little turnover of COBOL
>> programmers at large companies.
> 
> Nice hypothesis.
> 
> But not likely to be true.
> 

Your proof?

> If we look at the entire job market not just banks then the facts
> tell a very different story.
> 
> Indeed.com tracks salary levels:
> 
> Java - 102 K$ average
> Cobol - 78 K$ average
> 
> So does itjobwatch in the UK:
> 
> Java - 52.5 K£ average
> COBOL - 45 K£ average
> 
>> Your "evidence" more shows what isn't in much demand because the jobs
>> are short-term and unstable.
> 
> There is no evidence to support that.
> 
> But even if it were true, then it would not matter. No need to
> train for well paid jobs that never become available.
> 
> Arne
> 

And how many of those jobs are long term?  What benefits do they have?
and what is the basis for their figures - job listings at dice.com?
Mine comes from personal experience working with large companies and
their programmers for almost 40 years.

Sorry, Arne, once again you've shown your ignorance of the real world.

-- 
==================
Remove the "x" from my email address
Jerry Stuckle
jstucklex@attglobal.net
==================

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

#33075

On Monday, November 9, 2015 at 7:38:32 PM UTC-5, Arne Vajhøj wrote:
> Universities are supposed to teach students something that will help
> them through a career of 40-45 years.
> 
> At that time I think it both made sense and was common to use
> Pascal or C++.
> 
> Even though COBOL was still very popular at that time, then it
> was obvious that it would not stay that way.
> 
> C and C++ was already making serious inroads into business. And
> everybody knew that OO would be the big thing - it was just
> not clear what languages it would be besides C++.

Certainly when a university asks area businesses what they're looking for in hiring college graduates the businesses aren't going to tell them something they won't be using by the time the next batch of freshmen graduate.  The university and the businesses are both looking at the future.  When they say they change it up according to needs, they're not going to change their core teaching.

I graduated in 1996 so this was before Java and web stuff took off.  I had 3 courses in COBOL, one in C++, one for RPGIII, one for CICS/DB2... more importantly every computer course had a hands on lab, where you could write and run your own code with people around to help if you didn't understand.  They might still be teaching COBOL if businesses in the area are still looking for COBOL programmers, probably added Java and bumped something to make room, but graduates should understand the basics of some languages plus know enough to learn on their own.  I worked with a guy who said he had a BS in computers but didn't know how to write code without someone holding his hand, apparently his college only taught theories of coding.

Decades later there are still a lot of companies using COBOL because it would be too costly to rewrite their systems, and "if it ain't broke don't fix it", so it only makes sense to write new code if it will save money somehow or they need new functionality.  Are new companies getting into COBOL?  Apparently it is still an active language, as I'd hear about object oriented COBOL in college and it seems they did that and just last year added ability to overload methods?
https://en.wikipedia.org/wiki/COBOL#Object-oriented_programming

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

#33138

On Monday, November 2, 2015 at 10:11:25 AM UTC-8, Eric Douglas wrote:
> I just discovered something which created a minor problem in my class.  What would be the best way to solve it?
> 
> I have some constant values defined such as this
> public static final int AVALUE = 1;
> 
> some methods in the class have conditions defined such as this
> if (myValue == MyClass.AVALUE) {
> 
> I'm passing in myValue as Integer with a possibility it could be null.
> I hadn't tested these methods with the null value so I didn't realize it actually gets an error.
> 
> This code
>           Integer x = 1;
>           Integer o = 1;
>           if (x == o) {
>                System.out.println("equal");
>           } else {
>                System.out.println("not");
>           }
> prints "equal".
> This code
>           Integer x = new Integer(1);
>           Integer o = 1;
>           if (x == o) {
>                System.out.println("equal");
>           } else {
>                System.out.println("not");
>           }
> prints "not".
> This code
>           Integer x = new Integer(1);
>           int o = 1;
>           if (x == o) {
>                System.out.println("equal");
>           } else {
>                System.out.println("not");
>           }
> prints "equal".
> This code
>           Integer x = null;
>           int o = 1;
>           if (x == o) {
>                System.out.println("equal");
>           } else {
>                System.out.println("not");
>           }
> gets a NullPointerException on the if.
> Of course Eclipse at this point knows x is null and shows a warning on the if, but if you break it out as the real code would be, it compiles without error and just crashes when you run.
> 
>      public static void main(String[] args) {
>           Integer x = null;
>           checkThis(x);
>      }
>      public static void checkThis(final Integer checkMe) {
>           int o = 1;
>           if (checkMe == o) {
>                System.out.println("equal");
>           } else {
>                System.out.println("not");
>           }
>      }
> 
> Solutions?
> 1) Change all the constants to objects
> public static final Integer AVALUE = 1;
> 
> 2) Add null checks to all conditions
> if (checkMe != null && checkMe == o) {
> 
> Is there a third option?  Is there a difference in declaring static int constants versus Integers for memory use, performance?

Strictly speaking, 'static final Integer' does not define a constant.

-- 
Lew

[toc] | [prev] | [standalone]

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

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

csiph-web