f



regarding "perils of java schools"

i read Joel Spolsky's article "
http://www.joelonsoftware.com/articles/ThePerilsofJavaSchools.html"

i want to learn C++ *without* learning C. i have only 1 year at my
hands because of "financial constraints" & within this time-frame i
want to do network programming with C++ as most of jobs in my country
(INDIA) require:

"C++ & Network Programming experience &/OR Experience on UNIX".

( i did job search @ www.monsterindia.com). i am using Linux from last
1 year or so & i did some Common Lisp from
http://www.gigamonkeys.com/book/ . i want to know whether by doing
*only* C++ & not learning C:

1.) i will really miss that "part of brain"
2.) i will not able to know what is going "under the hood" & hence will
loose technical competency.

job, earning money is my only concern for the present.

any views? advice?

it is a genuine question i am asking, not a troll.

thanks

"arnuld"

0
arnuld3 (357)
9/21/2006 3:23:14 PM
comp.programming 11491 articles. 2 followers. Post Follow

24 Replies
564 Views

Similar Articles

[PageSpeed] 32

On 21 Sep 2006 08:23:14 -0700, "arnuld" <arnuld3@gmail.com> wrote:

>i read Joel Spolsky's article "
>http://www.joelonsoftware.com/articles/ThePerilsofJavaSchools.html"
>
>i want to learn C++ *without* learning C. i have only 1 year at my
>hands because of "financial constraints" & within this time-frame i
>want to do network programming with C++ as most of jobs in my country
>(INDIA) require:
>
>"C++ & Network Programming experience &/OR Experience on UNIX".
>
>( i did job search @ www.monsterindia.com). i am using Linux from last
>1 year or so & i did some Common Lisp from
>http://www.gigamonkeys.com/book/ . i want to know whether by doing
>*only* C++ & not learning C:
>
>1.) i will really miss that "part of brain"
>2.) i will not able to know what is going "under the hood" & hence will
>loose technical competency.
>
>job, earning money is my only concern for the present.
>
>any views? advice?
>
>it is a genuine question i am asking, not a troll.
>
>thanks
>
>"arnuld"

Learn C++ with the book: "Accelerated C++" by Koenig and Moo. You will
directly learn C++, you will need what you need to know of C from a
C++ point of view. And you will not miss it.

Zara
0
yorara (12)
9/21/2006 3:57:06 PM
arnuld wrote:

>i read Joel Spolsky's article "
> http://www.joelonsoftware.com/articles/ThePerilsofJavaSchools.html"

Joel is, to put it delicately, an expert at inspiring a response to his blog 
entries.

For example:

"When I was a kid, I learned to program on punched cards. If you made a 
mistake, you didn't have any of these modern features like a backspace key 
to correct it. You threw away the card and started over."

Dude, when you were a kid, you could use the Delete key to go back and punch 
thru all the dots. That's why delete is 0x7F; it's the one with all bits on 
(except the parity bit).

And so on - that's just from his warmup joke, not his corpus.

> i want to learn C++ *without* learning C.

Do it. Read /Accelerated C++/, and start using C++ as a high-level language. 
Avoid pointers, 'new', and raw arrays until you absolutely need them, and 
then instantly wrap them in high-level templates that constrain their C-like 
capacity for low-level bugs.

> i have only 1 year at my
> hands because of "financial constraints" & within this time-frame i
> want to do network programming with C++ as most of jobs in my country
> (INDIA) require:

Why not pick a softer language? If you learn Ruby, in a few weeks you can be 
writing complete websites from scratch, against databases, and you can be 
acceptance-testing web sites with Watir.

> "C++ & Network Programming experience &/OR Experience on UNIX".
>
> ( i did job search @ www.monsterindia.com). i am using Linux from last
> 1 year or so & i did some Common Lisp from
> http://www.gigamonkeys.com/book/ . i want to know whether by doing
> *only* C++ & not learning C:

Then Joel tells you: "Instead what I'd like to claim is that Java is not, 
generally, a hard enough programming language that it can be used to 
discriminate between great programmers and mediocre programmers."

He is telling us, with his usual whining about "gee good help is hard to 
find", that he will rate a programmer who picks a _hard_ language (like C) 
over a programmer who can pick an easy language!

Tip: Boost, and its network library asio, makes networking super-easy in 
C++, if you already know C++. However, we are not here to make things easy.

> 1.) i will really miss that "part of brain"
> 2.) i will not able to know what is going "under the hood" & hence will
> loose technical competency.

The primary reason you shouldn't use an even simpler networking tool (such 
as dRuby), is you won't find many employers who need that. Many employers 
these days have code written by programmers who followed Joel's advice, and 
pick a hard language like C "because we will need more ooomph, so a soft 
language won't do it." So you don't need to peek under the hood, you need to 
lay flat on your back under the engine with your nose to its oil pan!

Then their codebase gets old and crufty. What these people really need is 
unit tests, to make changes and cleanups safe. But neither the colleges nor 
Joel will tell you that!

-- 
  Phlip
  http://www.greencheese.us/ZeekLand <-- NOT a blog!!! 


0
phlipcpp (2771)
9/21/2006 4:06:16 PM
On Thu, 21 Sep 2006 16:06:16 UTC, "Phlip" <phlipcpp@yahoo.com> wrote:

> arnuld wrote:
> 
> >i read Joel Spolsky's article "
> > http://www.joelonsoftware.com/articles/ThePerilsofJavaSchools.html"
> 
> Joel is, to put it delicately, an expert at inspiring a response to his blog 
> entries.
> 
> For example:
> 
> "When I was a kid, I learned to program on punched cards. If you made a 
> mistake, you didn't have any of these modern features like a backspace key 
> to correct it. You threw away the card and started over."
> 
> Dude, when you were a kid, you could use the Delete key to go back and punch 
> thru all the dots. That's why delete is 0x7F; it's the one with all bits on 
> (except the parity bit).
> 
> And so on - that's just from his warmup joke, not his corpus.
> 
> > i want to learn C++ *without* learning C.
> 
> Do it. Read /Accelerated C++/, and start using C++ as a high-level language. 
> Avoid pointers, 'new', and raw arrays until you absolutely need them, and 
> then instantly wrap them in high-level templates that constrain their C-like 
> capacity for low-level bugs.
> 
> > i have only 1 year at my
> > hands because of "financial constraints" & within this time-frame i
> > want to do network programming with C++ as most of jobs in my country
> > (INDIA) require:
> 
> Why not pick a softer language? If you learn Ruby, in a few weeks you can be 
> writing complete websites from scratch, against databases, and you can be 
> acceptance-testing web sites with Watir.
> 
> > "C++ & Network Programming experience &/OR Experience on UNIX".
> >
> > ( i did job search @ www.monsterindia.com). i am using Linux from last
> > 1 year or so & i did some Common Lisp from
> > http://www.gigamonkeys.com/book/ . i want to know whether by doing
> > *only* C++ & not learning C:
> 
> Then Joel tells you: "Instead what I'd like to claim is that Java is not, 
> generally, a hard enough programming language that it can be used to 
> discriminate between great programmers and mediocre programmers."
> 
> He is telling us, with his usual whining about "gee good help is hard to 
> find", that he will rate a programmer who picks a _hard_ language (like C) 
> over a programmer who can pick an easy language!
> 
> Tip: Boost, and its network library asio, makes networking super-easy in 
> C++, if you already know C++. However, we are not here to make things easy.
> 
> > 1.) i will really miss that "part of brain"
> > 2.) i will not able to know what is going "under the hood" & hence will
> > loose technical competency.
> 
> The primary reason you shouldn't use an even simpler networking tool (such 
> as dRuby), is you won't find many employers who need that. Many employers 
> these days have code written by programmers who followed Joel's advice, and 
> pick a hard language like C "because we will need more ooomph, so a soft 
> language won't do it." So you don't need to peek under the hood, you need to 
> lay flat on your back under the engine with your nose to its oil pan!
> 
> Then their codebase gets old and crufty. What these people really need is 
> unit tests, to make changes and cleanups safe. But neither the colleges nor 
> Joel will tell you that!

Ruby and other soft languages have their place.  As you've mentioned
they aren't always available or what the customer wants to use.  You
probably won't find Ruby in a cell phone or embedded system.

I agree with the statement about Joel prompting thought and feedback.
Those readers that can actually think generally get the idea.

For the OP, learn C++ and networking individually and for what you
think you might be able to get a position.  In other words why
worry about MS VC++ if your goal is to work in a non-MS shop
for embedded systems.  The "TCP/IP Reference" books are great
techical books.  Again, focus on what you think may be important.
TCP/IP may only be 1/100th of what they need your for or it could
be all they need.  In general we learn skills and hopefully find
positions where we can grow more skills.

David
0
9/21/2006 5:54:16 PM
arnuld wrote:
> i read Joel Spolsky's article "
> http://www.joelonsoftware.com/articles/ThePerilsofJavaSchools.html"
> 
> i want to learn C++ *without* learning C. i have only 1 year at my
> hands because of "financial constraints" & within this time-frame i
> want to do network programming with C++ as most of jobs in my country
> (INDIA) require:
> 
> "C++ & Network Programming experience &/OR Experience on UNIX".
> 
> ( i did job search @ www.monsterindia.com). i am using Linux from last
> 1 year or so & i did some Common Lisp from
> http://www.gigamonkeys.com/book/ . i want to know whether by doing
> *only* C++ & not learning C:
> 
> 1.) i will really miss that "part of brain"
> 2.) i will not able to know what is going "under the hood" & hence will
> loose technical competency.

With a few very minor exceptions, C++ is a superset of C.  So, to learn
C++, you will have to learn C anyway.

I think it's possible to learn C++ without worrying about understanding
C by itself, but I do not think there is any benefit to doing this, and
I don't think it would be significantly easier either.  It's almost like
saying "I want to learn to fly a jet without learning to fly a propeller
airplane first".

Also, please keep in mind that when an employer says "we want someone
who knows C++", they often really mean "we want someone with C and C++
skills".  It is not accurate, but people often fail to make a distinction
between "C and C++" and "just C++".  This is probably because most C++
programmers learn C somewhere along the way.

And in addition, there are still lots of software projects out there
which have a mixture of C and C++.  If you are going to maintain any
existing code (which is absolutely a requirement if you expect to have
a career as a developer), it's likely that at some point you'll work
with a system that is partially C and partially C++.  *Especially* if
you are working with Unix.

   - Logan
0
lshaw-usenet (927)
9/22/2006 12:34:43 AM
Phlip wrote:

> Joel is, to put it delicately, an expert at inspiring a response to his blog 
> entries.
> 
> For example:
> 
> "When I was a kid, I learned to program on punched cards. If you made a 
> mistake, you didn't have any of these modern features like a backspace key 
> to correct it. You threw away the card and started over."
> 
> Dude, when you were a kid, you could use the Delete key to go back and punch 
> thru all the dots. That's why delete is 0x7F; it's the one with all bits on 
> (except the parity bit).

Sorry, Phlip, you're confusing punch cards with punched paper tape. 
Delete characters were used on 8-channel tape.

Actually, when I mispunched a card, I released it, then duplicated the 
previous card up to the mistake, so I didn't have to start from scratch. 
  To insert a character I could finesse the punch by holding down the 
prior card while punching the new character, thus causing the card 
advance to slip -- probably not the best for the punch!

If you look at the keypunch in the photo in Joel's article, you see two 
cards facing forward, the left one is normally the previously punched 
card that can be duplicated.  The one on the right is the new one in the 
punch station.  If you look closely, you can see the left card bent 
slightly forward.  Someone inserted that card explicitly for 
copying/editing.

Ah, the clatter of punches and smell of slightly oiled cards!

-- 
Thad
0
ThadSmith (1280)
9/22/2006 4:38:42 AM
Thad Smith <ThadSmith@acm.org> writes:

> Ah, the clatter of punches and smell of slightly oiled cards!

Punch cards were oiled?  Why?
-- 
"Let others praise ancient times; I am glad I was born in these."
--Ovid (43 BC-18 AD)
0
blp (3955)
9/22/2006 4:43:20 AM
Logan Shaw wrote:

> With a few very minor exceptions, C++ is a superset of C.  So, to learn
> C++, you will have to learn C anyway.

You are right as far as syntax goes, but there is more to the
distinction between c++ and C.  If the student gets too involved in C
exercises, it could affect the way he receives the idiomatic, Object
Oriented approach to programming when it is introduced.  I would say
that the syntax of the language is only a tiny part of learning it, in
the case of c++.  There are the much larger tasks of learning and
comprehending OO design, and then there is the truly monumental task of
learning how to use the STL -- which dwarfs the C standard library.


Too much "thinking like a C programmer" (not a bad thing), can seriously
impair the effort for learning C++.  They are quite different languages,
despite sharing most elements of the same grammar.

There is an old school of thought that holds it as appropriate to teach
C and then teach C++ as though it is an extension to C.  But the modern
approach is more along the lines of teaching design idioms, and choosing
a language appropriate to a given design methodology.  And today, that
means OODA, and so the language is often C++ or Java.

A typical first university course in C programming introduces the
language at the "Hello World!" level one week, and five weeks later, the
students are expected to be writing substantial code on their own.  A
typical first course in Object Oriented design starts by introducing the
design philosophy, covers UML and the GoF Design Patterns, spends a
little time introducing a programming language in this context, and sets
the students on a significant project that takes most of the term.

I know every curriculum is different, and no two schools offer the same
experience.  But what I have noted is quite typical today.

What I'm trying to suggest, on topic, is that it is no more necessary to
learn C in order to approach C++, than it is to learn Smalltalk in order
to approach Java.  In fact, in some ways, trying to learn C as a gateway
to learning C++ might end up being a handicap.


Just because us old farts learned C first and then C++ (because we were
present at the creation) does not mean that a neophyte must go through
the same process as though it is some sort of ritual.
0
jmcgill (426)
9/22/2006 6:32:15 AM
Thad Smith wrote:

> Phlip wrote:

>> Joel is, to put it delicately, an expert at inspiring a response to his 
>> blog entries.
>>
>> For example:
>>
>> "When I was a kid, I learned to program on punched cards. If you made a 
>> mistake, you didn't have any of these modern features like a backspace 
>> key to correct it. You threw away the card and started over."
>>
>> Dude, when you were a kid, you could use the Delete key to go back and 
>> punch thru all the dots. That's why delete is 0x7F; it's the one with all 
>> bits on (except the parity bit).
>
> Sorry, Phlip, you're confusing punch cards with punched paper tape. Delete 
> characters were used on 8-channel tape.

Phlip is, to put it delicately, an expert at inspiring a response to his 
posts.

-- 
  Phlip
  http://www.greencheese.us/ZeekLand <-- NOT a blog!!! 


0
phlipcpp (2771)
9/22/2006 1:24:01 PM
jmcgill wrote:
> Logan Shaw wrote:
> 
>> With a few very minor exceptions, C++ is a superset of C.  So, to learn
>> C++, you will have to learn C anyway.
> 
> You are right as far as syntax goes, but there is more to the
> distinction between c++ and C.  If the student gets too involved in C
> exercises, it could affect the way he receives the idiomatic, Object
> Oriented approach to programming when it is introduced.  I would say
> that the syntax of the language is only a tiny part of learning it, in
> the case of c++.

True, but there is more C in C++ than just the syntax.  Many of the
harder aspects of C have to be learned to use C++ effectively anyway.
How pointers and arrays work for example.  Or how types are converted.

> Just because us old farts learned C first and then C++ (because we were
> present at the creation) does not mean that a neophyte must go through
> the same process as though it is some sort of ritual.

I can't argue with that.  There could be some value in taking C++ on its
own and not learning to do things the C way.  On the other hand, the
original poster said they want to learn C++ because it's what is required
for a lot of jobs out there.  If that's the motivation (rather than just
to learn how to program), I think there would still be significant
benefit in learning C first, if just for the simple reason that one
day they're going to be working on some "C++" software, and they're
going to be asked to add a feature or fix a significant bug in a
section of the code, and they're going to see that the file's name
ends in ".c".  At that point, you have to know how to read and write
straight C.

   - Logan
0
lshaw-usenet (927)
9/22/2006 2:12:26 PM
>jmcgill wrote:

>> One reason many schools
>> teach a course in Java, is that Java happens to be (arguably) simpler to
>> learn to the point where the focus can be placed on Object Oriented
>> design principles, and not on detailed mechanics of the language being
>> used.  The grammar of Java can be learned in a matter of hours; in a few
>> days, enough of the Java library API can be learned to enable its use as
>> the vehicle by which a design methodology course can be taught.  This,
>> together with the Java's platform independence, motivates many schools
>> to use it.  I see no argument that can be made for "perils", however.

If you believe that, then clearly you have never taught Java to a class
of raw first year undergraduates.  Yes, maybe the total effort is just
"a matter of hours", but it takes several months, if not a year, to get
across the points you mention.  Or "in a matter of 200 hours".


>Universities teach Java because it is mainstream.

Then how do you pigeonhole universities that were teaching Java before it
became mainstream?

Universities teach Visual Basic because it is mainstream.
Why else would anyone teach it?

-- 
Chris.
0
chris16 (579)
9/22/2006 4:27:14 PM
"Ben Pfaff" <blp@cs.stanford.edu> wrote in message
news:87fyekqzo7.fsf@benpfaff.org...
> Thad Smith <ThadSmith@acm.org> writes:
>
> > Ah, the clatter of punches and smell of slightly oiled cards!
>
> Punch cards were oiled?  Why?

Kept the metal bits nice and shiny (and sharp in the case
of punches). Paper tape is available oiled as well.

I just checked an 80-col card I'm using as a book mark and
I don't think it's oiled. May have been optional for cards
as well as tape.

-Wm


0
reply34 (475)
9/22/2006 4:35:43 PM
Logan Shaw wrote:
> True, but there is more C in C++ than just the syntax.  Many of the
> harder aspects of C have to be learned to use C++ effectively anyway.
> How pointers and arrays work for example.  Or how types are converted.

what value do they have?

> I can't argue with that.  There could be some value in taking C++ on its
> own and not learning to do things the C way.  On the other hand, the
> original poster said they want to learn C++ because it's what is required
> for a lot of jobs out there.  If that's the motivation (rather than just
> to learn how to program),

so what benefit C brings to the mind of a Software Developer (except of
maintaining/fixing "legacy code")


> I think there would still be significant
> benefit in learning C first, if just for the simple reason that one
> day they're going to be working on some "C++" software, and they're
> going to be asked to add a feature or fix a significant bug in a
> section of the code, and they're going to see that the file's name
> ends in ".c".  At that point, you have to know how to read and write
> straight C.

i can do this later in my life, present focus is on "getting start to
earn"


"arnuld"

0
arnuld3 (357)
9/22/2006 5:35:45 PM
Dear Arnuld;

If I were interviewing you for a job, it would work against you strongly
if you only knew one programming language -- even if you were a C++ expert.

Despite my earlier comments, which are more in terms of education theory
than about working in a production environment, I would expect anyone
who promotes himself as an experienced C++ developer to be very strong
in certain areas:

1.  He would be able to give examples of at least a half dozen GoF
design patterns.   This is not language-specific, it is related to
design.  It would be acceptable (and somewhat expected) to be told that
Design Patterns are overrated.  I love it when I hear that, but I expect
a good argument as to why.  To make such an argument against a design
paradigm, one must at least be familiar with it.

2.  Beyond the C++ language itself, I expect a programmer to have more
than a passing familiarity with at least one STL implementation.  Do not
underestimate the magnitude of the task of "learning" STL.  There is far
more to learn in the Libraries than in the language itself, and in a
production environment, you will be completely lost without it.

3.  A C++ expert should be able to comprehend C, and should know at
least the main parts of the C Standard Library.  In particular, a C++
programmer who is experienced with a given platform should know how to
approach a problem which involves linkage between software being
developed in C++, and libraries which are coded in C.

4.  Problem solving and software design are generally done in a manner
which is distinct from programming.  It is quite important to also study
discrete structures and algorithms, and to study principles of design.
Without this knowledge, you will find it difficult to communicate with
customers, managers, and other developers.  One reason many schools
teach a course in Java, is that Java happens to be (arguably) simpler to
learn to the point where the focus can be placed on Object Oriented
design principles, and not on detailed mechanics of the language being
used.  The grammar of Java can be learned in a matter of hours; in a few
days, enough of the Java library API can be learned to enable its use as
the vehicle by which a design methodology course can be taught.  This,
together with the Java's platform independence, motivates many schools
to use it.  I see no argument that can be made for "perils", however.

Your original message also mentioned "Network programming."  Again,
there is a huge universe of discoures encapsulated in "Network
programming."  In my part of the Real World, "Network programming"
means, TCP/IP on various flavors of Unix.  In order to do my job, I have
had to become as proficient as anyone in the industry, with the core
TCP/IP infrastructure and *many* related protocols, with Unix systems
programming, with integration between several different systems, and I
have had to follow an enormous list of standards which are moving
targets.  This is a common experience in the network programming world.
 It is difficult to tell you where to start.  However, much of the
literature is targetted at an audience of C programmers - and indeed, a
substantial amount of the infrastructure has been developed in C.

Back to C++ network programming though.  In my shop, we have had a great
deal of success using C++ and ACE.  ACE is a lot of things, but in
general it's a framework that lets us design applications which use
networks, by describing them in a standard way.  We barely use any of
the ACE wrappers (I doubt many use more than a smallish subset).

But I would not expect someone who is "just" a C++ programmer to be able
to pick up ACE documentation, and given access to our code repository,
to become productive.  Just understanding the concepts of the space
where ACE lives, requires a solid grasp of the template library
organization of C++, and at least a passing familiarity with the
nomenclature of and the motivations of the "Design Patterns" methodology.

The details of the *language* used become vanishingly unimportant
compared to the magnitude of the *design considerations.*


Well, I see I am ranting a bit into a specific direction that isn't
really on topic for your question.  But I hope I am painting a picture
for you, to help you understand that learning the programming language
isn't really the big part of the job ahead of you.  You should be able
to learn this language, and six more, without a great deal of
difficulty.  Since the time you posted your first message and now, you
should already be writing some C++ programs.  And you should have
absorbed at least enough of the concepts that would be the "C" language,
 at least as far as basic types, and functions with parameters passed
by-value.  I think you should get that far in a matter of hours, and at
that point would be having questions about pointers, about structs, and
about some of the more confusing syntax.

I don't mean to sound condescending!  I want to encourage you to look
beyond the relatively small task of "learning languages", so that you
will stop thinking in terms of "spending a year" learning C++ "instead
of" C.  The languages are not so complex!  The *applications* of those
languages, can be *very* complex, and you really learn design concepts
as a separate discipline from programming.

> i can do this later in my life, present focus is on "getting start to
> earn"

So get started!

Have I made any book recommendations?

Few C++ programmers' bookshelves are without all the following:

Accelerated C++: Practical Programming by Example, Koening & Moo
The C++ Programming Language (any edition), Stroustrup
The C++ Standard Library, Josuttis

Design Patterns, Gamma, Helms, Johnson, Vlissides


I rarely meet anyone who does network programming for Unix, that does
not have well-worn copies of practically everything written by the late
W. Richard Stevens.  In particular,
TCP Illustrated,
Unix Network Programming vol. 1,
and
Advanced Programming in the Unix Environment

are nearly universally regarded as required reading.

This is a *LOT* of material.  Please do not interpret my comments as a
suggestion to go spend a thousand dollars on books.  Take it a step at a
time.  If you are motivated, in a years' time I have no doubt you can
get where you want to be.



Kind regards,

James McGill
Secretary, University of Arizona ACM Chapter
<jamesmcgill@acm.org>
0
jmcgill (426)
9/22/2006 6:40:21 PM
jmcgill wrote:

>
> One reason many schools
> teach a course in Java, is that Java happens to be (arguably) simpler to
> learn to the point where the focus can be placed on Object Oriented
> design principles, and not on detailed mechanics of the language being
> used.  The grammar of Java can be learned in a matter of hours; in a few
> days, enough of the Java library API can be learned to enable its use as
> the vehicle by which a design methodology course can be taught.  This,
> together with the Java's platform independence, motivates many schools
> to use it.  I see no argument that can be made for "perils", however.
>

No those are exactly the reason why the people that introduce
programming with Scheme say they choose it over Java.

<quote> Scheme is different. "If you want to say that the
relationship between 'x' and 'y' is 'f,' that's two lines
in algebra. It's also two lines in Scheme. In Java, you have to add
'public, static, void, main, left paren, String args, left bracket,
right bracket, right paren, left brace, right brace' before you say
anything else. Is that making it clear?" he says, slapping down the
marker for emphasis.</quote>

http://www.numag.neu.edu/0301/programming.html

Universities teach Java because it is mainstream. Once that no longer
applies they will stop teaching it just like they stopped teaching
COBOL. There are ample opportunities for picking up Java skills
vocationally, it's ubiquity in university curriculums is a function of
the number of schools that have succumbed to the expectation of
students to be taught in languages that they perceive will "help them
get jobs". Even if OO is your paradigm of choice there are better
pedagogic vehicles than Java for teaching it.

0
wookiz (347)
9/22/2006 6:59:13 PM
wooks wrote:
> Universities teach Java because it is mainstream. Once that no longer
> applies they will stop teaching it just like they stopped teaching
> COBOL. 

I know of at least two universities that still require a course in
COBOL, and one of them also requires an IBM 370 assembly language course
on a VMS-clone that was developed there.

But I get your point.

Scheme isn't mainstream.

> here are ample opportunities for picking up Java skills
> vocationally, it's ubiquity in university curriculums is a function of
> the number of schools that have succumbed to the expectation of
> students to be taught in languages that they perceive will "help them
> get jobs". 

I don't completely disagree, and I'm fortunate to be plugged into a
university where people tend to be genuinely interested in Computer
Science.  The barriers to entry just for declaring the major are
relatively high, and I believe this helps.  Those who do not want to
bother with that, can go for a different major that goes into more
engineering practicum than computer science.


0
jmcgill (426)
9/22/2006 10:34:26 PM
jmcgill wrote:
> Dear Arnuld;
>
> If I were interviewing you for a job, it would work against you strongly
> if you only knew one programming language -- even if you were a C++ expert.
>
> Despite my earlier comments, which are more in terms of education theory
> than about working in a production environment, I would expect anyone
> who promotes himself as an experienced C++ developer to be very strong
> in certain areas:
>
> 1.  He would be able to give examples of at least a half dozen GoF
> design patterns.   This is not language-specific, it is related to
> design.  It would be acceptable (and somewhat expected) to be told that
> Design Patterns are overrated.  I love it when I hear that, but I expect
> a good argument as to why.  To make such an argument against a design
> paradigm, one must at least be familiar with it.
>
> 2.  Beyond the C++ language itself, I expect a programmer to have more
> than a passing familiarity with at least one STL implementation.  Do not
> underestimate the magnitude of the task of "learning" STL.  There is far
> more to learn in the Libraries than in the language itself, and in a
> production environment, you will be completely lost without it.
>
> 3.  A C++ expert should be able to comprehend C, and should know at
> least the main parts of the C Standard Library.  In particular, a C++
> programmer who is experienced with a given platform should know how to
> approach a problem which involves linkage between software being
> developed in C++, and libraries which are coded in C.
>
> 4.  Problem solving and software design are generally done in a manner
> which is distinct from programming.  It is quite important to also study
> discrete structures and algorithms, and to study principles of design.
> Without this knowledge, you will find it difficult to communicate with
> customers, managers, and other developers.  One reason many schools
> teach a course in Java, is that Java happens to be (arguably) simpler to
> learn to the point where the focus can be placed on Object Oriented
> design principles, and not on detailed mechanics of the language being
> used.  The grammar of Java can be learned in a matter of hours; in a few
> days, enough of the Java library API can be learned to enable its use as
> the vehicle by which a design methodology course can be taught.  This,
> together with the Java's platform independence, motivates many schools
> to use it.  I see no argument that can be made for "perils", however.
>
> Your original message also mentioned "Network programming."  Again,
> there is a huge universe of discoures encapsulated in "Network
> programming."  In my part of the Real World, "Network programming"
> means, TCP/IP on various flavors of Unix.  In order to do my job, I have
> had to become as proficient as anyone in the industry, with the core
> TCP/IP infrastructure and *many* related protocols, with Unix systems
> programming, with integration between several different systems, and I
> have had to follow an enormous list of standards which are moving
> targets.  This is a common experience in the network programming world.
>  It is difficult to tell you where to start.  However, much of the
> literature is targetted at an audience of C programmers - and indeed, a
> substantial amount of the infrastructure has been developed in C.
>
> Back to C++ network programming though.  In my shop, we have had a great
> deal of success using C++ and ACE.  ACE is a lot of things, but in
> general it's a framework that lets us design applications which use
> networks, by describing them in a standard way.  We barely use any of
> the ACE wrappers (I doubt many use more than a smallish subset).
>
> But I would not expect someone who is "just" a C++ programmer to be able
> to pick up ACE documentation, and given access to our code repository,
> to become productive.  Just understanding the concepts of the space
> where ACE lives, requires a solid grasp of the template library
> organization of C++, and at least a passing familiarity with the
> nomenclature of and the motivations of the "Design Patterns" methodology.
>
> The details of the *language* used become vanishingly unimportant
> compared to the magnitude of the *design considerations.*
>
>
> Well, I see I am ranting a bit into a specific direction that isn't
> really on topic for your question.  But I hope I am painting a picture
> for you, to help you understand that learning the programming language
> isn't really the big part of the job ahead of you.  You should be able
> to learn this language, and six more, without a great deal of
> difficulty.  Since the time you posted your first message and now, you
> should already be writing some C++ programs.  And you should have
> absorbed at least enough of the concepts that would be the "C" language,
>  at least as far as basic types, and functions with parameters passed
> by-value.  I think you should get that far in a matter of hours, and at
> that point would be having questions about pointers, about structs, and
> about some of the more confusing syntax.
>
> I don't mean to sound condescending!  I want to encourage you to look
> beyond the relatively small task of "learning languages", so that you
> will stop thinking in terms of "spending a year" learning C++ "instead
> of" C.  The languages are not so complex!  The *applications* of those
> languages, can be *very* complex, and you really learn design concepts
> as a separate discipline from programming.
>
> > i can do this later in my life, present focus is on "getting start to
> > earn"
>
> So get started!
>
> Have I made any book recommendations?
>
> Few C++ programmers' bookshelves are without all the following:
>
> Accelerated C++: Practical Programming by Example, Koening & Moo
> The C++ Programming Language (any edition), Stroustrup
> The C++ Standard Library, Josuttis
>
> Design Patterns, Gamma, Helms, Johnson, Vlissides
>
>
> I rarely meet anyone who does network programming for Unix, that does
> not have well-worn copies of practically everything written by the late
> W. Richard Stevens.  In particular,
> TCP Illustrated,
> Unix Network Programming vol. 1,
> and
> Advanced Programming in the Unix Environment
>
> are nearly universally regarded as required reading.
>
> This is a *LOT* of material.  Please do not interpret my comments as a
> suggestion to go spend a thousand dollars on books.  Take it a step at a
> time.  If you are motivated, in a years' time I have no doubt you can
> get where you want to be.

your thoughts & experience really put a big impact on my thinking. i
have decided to learn C++, to learn C++ the way it is & from now on
will dive into it. do you recommend any book?

P.S.  "Accelerated C++" & "C++ Primer 4/e" both are not available in
India. i have "C++ Primer 3/e" but trust me it is utterly
incomprehensible.

thanks

"arnuld"

0
arnuld3 (357)
9/24/2006 3:42:33 PM
arnuld wrote:

> P.S.  "Accelerated C++" & "C++ Primer 4/e" both are not available in
> India. 

Apologies for my short response -- busy.

But I wanted to express my surprise that, in this age of global commerce
and instantaneous communications, that it is possible for technical
books to be unavailable to an entire subcontinent.

I realize that I am very spoiled -- I live in a place where one finds
technical books even on bookshelves in grocery stores.  I'm only
exaggerating slightly.

That said, I am reluctant to make too many book recommendations.

I would recommend:  The C++ Programming Language by Bjarne Stroustrup
		    The C++ Standard Library - A Tutorial and Reference
  by Nicolai Josuttis

Those two books will be at hand long after you have "learned the
language" and you will reference them as you develop software -- for the
rest of your career.

Others may make book recommendations for introductory texts.  I will say
that these two books are worth owning, even if it is difficult to have
them sent to you.


Regards,

James
0
jmcgill (426)
9/27/2006 1:34:10 AM
Chris McDonald wrote:

> If you believe that, then clearly you have never taught Java to a class
> of raw first year undergraduates.  Yes, maybe the total effort is just
> "a matter of hours", but it takes several months, if not a year, to get
> across the points you mention.  Or "in a matter of 200 hours".

A two-semester course is just over 80 hours total, but spread out over
months.  I'll grant you that not everyone can learn to program from a
cold start in a single pass through the material.  Most who aspire to be
Comp Sci majors have no problem doing that, though.  I suppose the
difference between schools is that some are perfectly willing to do
brutal and cynical weeding out.  (Comp Sci majors are not even accepted
in the program if they have below a "B" in any CS or Math course!)

At the school I am thinking of, the "raw first-year undergraduates" get
a course in MIPS assembly language (by the Henessy and Patterson book).
 Those that aren't weeded out in that, or the first term of Discrete
Math, go on to an OO design and development course, that currently, is
taught in Java.  The students learn the language and then spend a few
weeks in a pair-programming project, where most develop a graphical game
of some sort.

After this course, they take Unix systems programming where they learn C
rapidly and develop some fairly substantial programs.  Then a
comparative languages course that deals with ML and Ruby and a variety
of others.  Then there are the electives, including a course in MacOSX
development in Objective-C.

While all this is going on, they also have to take discrete math, more
discrete math, algorithms, automata, and can take more theory electives.

Somewhere along they way they need Calculus up to and optionally
including Vector Calc, plus Linear Algebra if they want to do Graphics
(which uses OpenGL today, and C++ which you pretty much needed to have
learned on your own).



0
jmcgill (426)
9/27/2006 3:14:29 AM
jmcgill <jmcgill@email.arizona.edu> writes:

>Chris McDonald wrote:

>> If you believe that, then clearly you have never taught Java to a class
>> of raw first year undergraduates.  Yes, maybe the total effort is just
>> "a matter of hours", but it takes several months, if not a year, to get
>> across the points you mention.  Or "in a matter of 200 hours".

>At the school I am thinking of, the "raw first-year undergraduates" get
>a course in MIPS assembly language (by the Henessy and Patterson book).
> Those that aren't weeded out in that, or the first term of Discrete
>Math, go on to an OO design and development course, that currently, is
>taught in Java.  The students learn the language and then spend a few
>weeks in a pair-programming project, where most develop a graphical game
>of some sort.

Thanks for the info;  yes, it's certainly as case of willingness/ability
to cull potential majors,  perhaps a different between private and
state-funded schools, too.

One big factor, too, is the students not learning OO programming in their
1st semester/term at university.  Your assembly language students are also
being culled by their introductions to freedom, sex, drugs, and alcohol.
The OO students appear to have "passed" those exams.

______________________________________________________________________________ 
Dr Chris McDonald                          E: chris@csse.uwa.edu.au
Computer Science & Software Engineering    W: http://www.csse.uwa.edu.au/~chris
The University of Western Australia, M002  T: +618 6488 2533
Crawley, Western Australia, 6009           F: +618 6488 1089
0
chris16 (579)
9/27/2006 3:37:49 AM
jmcgill wrote:
> arnuld wrote:
>
> > P.S.  "Accelerated C++" & "C++ Primer 4/e" both are not available in
> > India.
>
> Apologies for my short response -- busy.

no problem :-)

> But I wanted to express my surprise that, in this age of global commerce
> and instantaneous communications, that it is possible for technical
> books to be unavailable to an entire subcontinent.

this is exact the situation here in India.

> I realize that I am very spoiled -- I live in a place where one finds
> technical books even on bookshelves in grocery stores.  I'm only
> exaggerating slightly.
>
> That said, I am reluctant to make too many book recommendations.
>
> I would recommend:  The C++ Programming Language by Bjarne Stroustrup
> 		    The C++ Standard Library - A Tutorial and Reference
>   by Nicolai Josuttis

Stroustrup's books is available but not of Josuttis's. In India there
is no book on C++ Standard Library, even  thers is no book on C
Standard Library. we dont have FreeBSD handbook too, not even
"Programming Ruby" & many other precious books :-(

> Those two books will be at hand long after you have "learned the
> language" and you will reference them as you develop software -- for the
> rest of your career.

i came across this phrase so many times :-) , next month i will buy
Stroustrup's book.

> Others may make book recommendations for introductory texts.  I will say
> that these two books are worth owning, even if it is difficult to have
> them sent to you.

i really feel painful as i can not have "Josuttis".

thanks James

"arnuld"

0
arnuld3 (357)
9/27/2006 4:07:42 AM
arnuld wrote:

> Stroustrup's books is available but not of Josuttis's. 

Josuttis is quite advanced material.  It's a Standard Library reference.
 You are not yet at a level where you need it.  I hope I was clear --
I'm trying to help you understand a place you need to go, because I'm
not really able to help you get started on the road to get there.  I think
you need a tutorial book to get you started (and I can't really
recommend one), and maybe a reference book -- O'Reilly Practical C++
Programming, maybe?  (I think there is an online version of that book).


> i came across this phrase so many times :-) , next month i will buy
> Stroustrup's book.

It's heavy reading, but it is very thorough and complete.

> i really feel painful as i can not have "Josuttis".

You are not ready for the material -- it would confuse you to try to
start with STL material, not knowing the language fairly well.
0
jmcgill (426)
9/27/2006 4:37:41 AM
jmcgill wrote:
> arnuld wrote:
> Josuttis is quite advanced material.  It's a Standard Library reference.
>  You are not yet at a level where you need it.  I hope I was clear --

yes, you were "clear".

> I'm trying to help you understand a place you need to go, because I'm
> not really able to help you get started on the road to get there.  I think
> you need a tutorial book to get you started (and I can't really
> recommend one), and maybe a reference book -- O'Reilly Practical C++
> Programming, maybe?  (I think there is an online version of that book).

i checked ACCU, they have bad review of this book.


> It's heavy reading, but it is very thorough and complete.

Hmmm... I was able to understand "Thinking in C++" but there was heavy
use of C, so i abandoned it. So, for me, as a tutorial, Will Stroustrup
work?

can you tell me whether Stroustrup teaches about pointers or if he
assumes reader already knows about pointers.

> You are not ready for the material -- it would confuse you to try to
> start with STL material, not knowing the language fairly well.

OK, got it.

0
arnuld3 (357)
9/27/2006 6:52:03 AM
arnuld wrote:
> 
.... snip ...
> 
> Hmmm... I was able to understand "Thinking in C++" but there was
> heavy use of C, so i abandoned it. So, for me, as a tutorial, Will
> Stroustrup work?

That sounds extremely foolish.  C++ is built on C, and TiC++ is a
well respected book, also available on line.

-- 
 Some informative links:
   <news:news.announce.newusers
   <http://www.geocities.com/nnqweb/>
   <http://www.catb.org/~esr/faqs/smart-questions.html>
   <http://www.caliburn.nl/topposting.html>
   <http://www.netmeister.org/news/learn2quote.html>
   <http://cfaj.freeshell.org/google/>

0
cbfalconer (19194)
9/27/2006 11:03:37 AM
CBFalconer wrote:

> That sounds extremely foolish.  C++ is built on C, and TiC++ is a
> well respected book, also available on line.

this is not foolish.  I did not say it is a bad book. it is one of my
favourites if i want to recommend it to a C programmer. this is the
book where i felt i am developing a "framework" in my mind gradually &
when i will see a problem then i can feed that to my framework & deduce
the answer. for me, trouble is he asks substantial amount of experience
with C, which i do not possess & i dont want to.

In chapter 4 "Data Abstraction", Eckel shows a C Library written with
some C++ syntax then for nearly all of his subsequent chapters he uses
that C library to explain most features of C++ which  think is not OK.
He does not even tell why "fetch" is a pointer to function & why
"cleanup" is  not. (but i think he already made clear that as this is
the book for C programmer not for a programmer from other language.
only one thing that does not make sense is that ha says: "if you dont
know C then just do chapter 3 & "Thinking in C cd" then you will
understand his book" which of course does not work.) take a look at his
C library in chapter 4 & read what he says there.


even "C++ Primer" 3/e asks too much for arrays in chapter 2 where he
assumes implicitly that reader has a good amount of "programming"
experience when he starts doing dynamic arrays  & in chapter 3 he uses
"extern int pow(int, int)" without giving any hint what does this
buzzword mean.


I prefer "Thinking in C++" . i really did not like C++ Primer 3/e (but
i have heard that 4/e is a huge improvement).

"arnuld"

0
arnuld3 (357)
9/27/2006 12:51:27 PM
Reply: