Whats the best language to learn...

"Gits" <hamza612@live.com> wrote in message
news:f31da84f-8ac6-4a45-82d2-55d71088636a@i76g2000hsf.googlegroups.com...
> What's the best language to learn as a beginner, for someone like I
> who has never programmed in any language before? I'm interested in
> learning python or c++, which would you say is the least complicated?

Lua

http://www.lua.org/

On 18 Aug., 07:22, Arto Viitanen <arto.viita...@microteam.fi> wrote:
> Mensanator kirjoitti:
>
> > On Aug 17, 12:12 pm, Gits <hamza...@live.com> wrote:
> >> What's the best language to learn as a beginner, for someone like I
> >> who has never programmed in any language before? I'm interested in
> >> learning python or c++, which would you say is the least complicated?
>
> > Python is a good choice, much less complicated
> > than c++.
>
> I checked Python once to see if it would be suitable language to teach
> as the first programming language, and it looked fine. We did not take
> it, but still..
>
> Boo might also be good choise: it has similar syntax to Python, but it
> uses .NET classes.

I recommend Python too ! Python code is "pseudo code that actually
runs",
the code is easy to read and the language is easy to learn.

http://www.python.org/about/ provides information about the Python
language.

Greetings, Uwe

Gits wrote:
> What's the best language to learn as a beginner, for someone like I
> who has never programmed in any language before? I'm interested in
> learning python or c++, which would you say is the least complicated?

Without attempting to qualify my answer with a definition of
'complicated', I'd say Python is less complicated than C++.

But based on experiences of learning myslef, and of teaching students,
I'd say that, as regards a language for learning programmin ---
especially if self-taught --- there are a great many practical criteria
that are more important than theoretical qualities of the language, even
its pedagogical qualities.

The main practical criteria I think of off the top of my head:

- free compiler or environment; C++, Python, Java all tick the box;

- good textbooks at your level; Java > C++ > Python, I think;
Incientally, would you fancy learning programming via /simple/ games
programming (I stress the simple), then there's a couple of books that
use Python and Pygame that look good; there's a Head First textbook for
Java that you might fancy; and one by Cay Horstmann.

- tame experts or resources available to help you learn, especially at
the beginning; for C++

alt . comp . lang . learn . c-c++

is a good resource for C++. I don't know about the equivalent for Java
and Python, but there are.

If you look at that n.g. you'll see that books on C++ by Glassborow and
(maybe more advanced) by Koenig and Moo are often recommended.

- my students think of CVs, and based on job adverts. and general
anecdote their motivation to learn programming via a particular language
can vary a lot; *you* need motivation.

Lastly. This is not going to be easy, so you've got to make a decision
quickly and decisively and get on with it and have faith in your
decision or in the advice yo receive.

You should set goals. Start off with a little program that you would
like to achieve. That's why I mentioned games --- with the Pygame books
I mentioned, you might expect to have thinks bouncing about the screen
and making sounds rather quickly. How quickly? On your own and working
three hours a day, you'd have something to show (a very simple
calculating program or one that creates string greetings) after a month
and could be looking for other challenges after three months. A mentor
(or a friendly n.g.) --- but learn to ask questions properly --- would
help a lot.

Oh, yea! Based on no knowledge of what interests you, I'd choose Java;
and that's because it seems to be the most popular introductory language
in educational establishments that I respect; consequently, there are
good ranges of textbooks and other resources.

Take advice on textbooks. You are unlikely to be able to choose properly
even after browsing in a bookshop.

Best regards,

Jon C.

cr88192 wrote:
> it depends on the person I think...

I said "the average person", I didn't say "everyone". Of course there
are always exceptions, but those are rarer.

>> A food recipe is the perfect example of this: A food recipe consists
>> of concepts (such as ingredients and measurements) and sequential steps
>> (a list of things what to do, in which order and how).
>>
> this example is almost a cliche, however...

However? Just because an example is used very often, does that make
the example wrong?

> it just so happens that many people who use C, are not so inclined towards
> OOP.

IMO that's because the natural way of thinking in C is quite
non-object-oriented (because the language has next to no native support
for object-oriented programming).

Thus IMO it's so much that "people who don't think in terms of OOP
tend to use a language like C", but the other way around: "People who
are fluent in C, maybe because it was their first language, are not
inclined towards OOP". In other words, C teaches non-OOP thinking (which
IMO is often a bad thing).

> or, about OOP vs non-OOP, some problems naturally fit nicely into an
> OOP-like approach, and other problems fit rather poorly

Personally I like to make a distinction between modular programming
and object-oriented programming. People often use the term "OOP" when in
fact the term "modular programming" would be more fitting.

While modular programming is a more or less pure subset of OOP (or if
you want to think about it the other way around, OOP is an enhancement
of modular programming), I still think it's good to distinguish between
the two when discussing about programming paradigms. The term "OOP" is
much larger than "modular programming", and implies more. Yet often the
discussion is only about the modular part of OOP, not OOP as a whole.

When I say that people tend to think about things in "concepts", I was
really referring to modules and not so much about objects (as per OOP).
While it is true that people also naturally think in terms of objects
(for example "a dog is an animal", or in more general, "a <more concrete
concept> is a <more abstract concept>"), in practice most beginner
programs consist of modules and not inheritance hierarchies, and thus it
would be enough to learn the good use of modules at first.

IMO modules are one of the most important elements in programming
(regardless of the used programming paradigm!). They help dividing the
program into smaller parts in a natural and intuitive way, and they keep
the relationship between the different parts simple and clear (well, in
the optimally designed case at least).

Thus I believe that modular thinking is one of the most basic things a
beginner programmer should learn. Of course the most natural way of
doing this is to use a language with good support for modules. Nowadays
that would usually be some kind of object-oriented programming language.

Of course modules only take care of how the program is divided into
logical parts. It doesn't say anything about how the functionality of
the program is implemented. This is where the other natural way of
thinking of the average person kicks in: Usually people think in
sequential steps, and imperative programming is the most natural
reflection of this.

> (some problems are
> actually far more suited, for example, to stack-based processing or large
> parallel arrays of vectors or numbers).

Even if a sub-task of the program is more suitable for something
completely different than OOP, in the grand scale of things it's still
usually a good idea to try to divide the program into logical parts.
Modules are usually perfect for this.

> problem is that people who have been taught in the modern OO regime are made
> to believe that everything is an object, best hit over the head with classes
> and interfaces. it is also good to know when not to do this...

It is indeed very possible to over-modularize: To divide things into
too many too small modules. The more the different modules and the
smaller they are, especially if there's no logical hierarchy of modules,
the more counter-productive it becomes. The overall design can become a
big mess which is hard to understand and visualize.

(Of course having a huge amount of modules in a large project is not
automatically a symptom of a problematic design. If the modules form a
logical hierarchy so that they can be dealt in groups and subgroups of
modules (with maybe some modules hiding a bunch of sub-modules in their
private parts), then that may work as a design.)

The other extreme is under-modularizing: Creating one or just a few
enormous modules with just way too much stuff in them. This quickly
becomes unmaintainable spaghetti code.

> actually, another problem more specific to newbs and C++ is the
> overuse/abuse of certain heavy-weight features (namely operator overloading
> and templates)

Exactly how are they heavy-weight?

From the speed point of view templates usually produce faster code
than the alternatives (eg. compare std::sort to qsort), and overloaded
operators are just regular functions, nothing more, nothing less.

Maybe you were talking about some other point of view?

> where I think it is probably better if people first learn
> how to not make a big mess out of things by trying to get though problems
> via excessive use of operator overloading and templates.

"Excessive use of templates" sounds to me a bit like "excessive use of
variable names" or "excessive use of enums". Maybe I'm just biased.

Like variable names and enums, IMO templates are just a way to
abstract things. There's nothing inherently suboptimal about them.

> now, I do what I personally like, which tends to be more what "makes sense",
> which is more often more C-like (namely, source files one place, headers in
> another, and having a much smaller number of somewhat larger source files,
> typically 500-2000 LOC per file, ...).

Personally I try to put an upper limit of 1000 lines per source file
(it's a rather soft limit, but still). But that's just a personal
preference.

No lower limit. If the most logical design for something is to make it
a module, no matter how small, then so be it. There's no need to
artificially try to embed it somewhere it doesn't inherently belong.

> more so, there are many cases where there are good reasons to use C over C++
> as well (or for that matter, when it makes sense to use opaque procedural
> APIs between subsystems, ...).

The only thing I can think of is the linux kernel and maybe some
small, low-level drivers (which do not require the features provided by
C++ for anything).

On 18 Aug, 15:53, Juha Nieminen <nos...@thanks.invalid> wrote:
> cr88192 wrote:
> > it depends on the person I think...
>
> I said "the average person", I didn't say "everyone". Of course there
> are always exceptions, but those are rarer.
>
> >> A food recipe is the perfect example of this: A food recipe consists
> >> of concepts (such as ingredients and measurements) and sequential steps
> >> (a list of things what to do, in which order and how).
>
> > this example is almost a cliche, however...
>
> However? Just because an example is used very often, does that make
> the example wrong?
>
> > it just so happens that many people who use C, are not so inclined towards
> > OOP.
>
> IMO that's because the natural way of thinking in C is quite
> non-object-oriented (because the language has next to no native support
> for object-oriented programming).
>
> Thus IMO it's so much that "people who don't think in terms of OOP
> tend to use a language like C", but the other way around: "People who
> are fluent in C, maybe because it was their first language, are not
> inclined towards OOP". In other words, C teaches non-OOP thinking (which
> IMO is often a bad thing).
>
> > or, about OOP vs non-OOP, some problems naturally fit nicely into an
> > OOP-like approach, and other problems fit rather poorly
>
> Personally I like to make a distinction between modular programming
> and object-oriented programming. People often use the term "OOP" when in
> fact the term "modular programming" would be more fitting.
>
> While modular programming is a more or less pure subset of OOP (or if
> you want to think about it the other way around, OOP is an enhancement
> of modular programming), I still think it's good to distinguish between
> the two when discussing about programming paradigms. The term "OOP" is
> much larger than "modular programming", and implies more. Yet often the
> discussion is only about the modular part of OOP, not OOP as a whole.
>
> When I say that people tend to think about things in "concepts", I was
> really referring to modules and not so much about objects (as per OOP).
> While it is true that people also naturally think in terms of objects
> (for example "a dog is an animal", or in more general, "a <more concrete
> concept> is a <more abstract concept>"), in practice most beginner
> programs consist of modules and not inheritance hierarchies, and thus it
> would be enough to learn the good use of modules at first.
>
> IMO modules are one of the most important elements in programming
> (regardless of the used programming paradigm!). They help dividing the
> program into smaller parts in a natural and intuitive way, and they keep
> the relationship between the different parts simple and clear (well, in
> the optimally designed case at least).
>
> Thus I believe that modular thinking is one of the most basic things a
> beginner programmer should learn. Of course the most natural way of
> doing this is to use a language with good support for modules. Nowadays
> that would usually be some kind of object-oriented programming language.
>
> Of course modules only take care of how the program is divided into
> logical parts. It doesn't say anything about how the functionality of
> the program is implemented. This is where the other natural way of
> thinking of the average person kicks in: Usually people think in
> sequential steps, and imperative programming is the most natural
> reflection of this.
>
> > (some problems are
> > actually far more suited, for example, to stack-based processing or large
> > parallel arrays of vectors or numbers).
>
> Even if a sub-task of the program is more suitable for something
> completely different than OOP, in the grand scale of things it's still
> usually a good idea to try to divide the program into logical parts.
> Modules are usually perfect for this.
>
> > problem is that people who have been taught in the modern OO regime are made
> > to believe that everything is an object, best hit over the head with classes
> > and interfaces. it is also good to know when not to do this...
>
> It is indeed very possible to over-modularize: To divide things into
> too many too small modules. The more the different modules and the
> smaller they are, especially if there's no logical hierarchy of modules,
> the more counter-productive it becomes. The overall design can become a
> big mess which is hard to understand and visualize.
>
> (Of course having a huge amount of modules in a large project is not
> automatically a symptom of a problematic design. If the modules form a
> logical hierarchy so that they can be dealt in groups and subgroups of
> modules (with maybe some modules hiding a bunch of sub-modules in their
> private parts), then that may work as a design.)
>
> The other extreme is under-modularizing: Creating one or just a few
> enormous modules with just way too much stuff in them. This quickly
> becomes unmaintainable spaghetti code.
>
> > actually, another problem more specific to newbs and C++ is the
> > overuse/abuse of certain heavy-weight features (namely operator overloading
> > and templates)
>
> Exactly how are they heavy-weight?
>
> From the speed point of view templates usually produce faster code
> than the alternatives (eg. compare std::sort to qsort), and overloaded
> operators are just regular functions, nothing more, nothing less.
>
> Maybe you were talking about some other point of view?
>
> > where I think it is probably better if people first learn
> > how to not make a big mess out of things by trying to get though problems
> > via excessive use of operator overloading and templates.
>
> "Excessive use of templates" sounds to me a bit like "excessive use of
> variable names" or "excessive use of enums". Maybe I'm just biased.
>
> Like variable names and enums, IMO templates are just a way to
> abstract things. There's nothing inherently suboptimal about them.
>
> > now, I do what I personally like, which tends to be more what "makes sense",
> > which is more often more C-like (namely, source files one place, headers in
> > another, and having a much smaller number of somewhat larger source files,
> > typically 500-2000 LOC per file, ...).
>
> Personally I try to put an upper limit of 1000 lines per source file
> (it's a rather soft limit, but still). But that's just a personal
> preference.
>
> No lower limit. If the most logical design for something is to make it
> a module, no matter how small, then so be it. There's no need to
> artificially try to embed it somewhere it doesn't inherently belong.
>
> > more so, there are many cases where there are good reasons to use C over C++
> > as well (or for that matter, when it makes sense to use opaque procedural
> > APIs between subsystems, ...).
>
> The only thing I can think of is the linux kernel and maybe some
> small, low-level drivers (which do not require the features provided by
> C++ for anything).

The reasons the linux kernel was written in c++....

"The fact is, C++ compilers are not trustworthy. They were even worse
in
1992, but some fundamental facts haven't changed: 1) the whole C++
exception handling thing is fundamentally broken. It's _especially_
broken for kernels. 2) any compiler or language that likes to hide
things like memory allocations behind your back just isn't a good
choice for a kernel. 3) you can write object-oriented code (useful for
filesystems etc) in C, _without_ the crap that is C++." (LT)

....hold good for other applications as well. I have personally worked
on complex sytems where C was chosen
because it speed and explicit (=easily debuggable) memory allocations.

On 17 Aug, 18:12, Gits <hamza...@live.com> wrote:
> What's the best language to learn as a beginner, for someone like I
> who has never programmed in any language before? I'm interested in
> learning python or c++, which would you say is the least complicated?

A few tips:

Programming isn't just coding. Look into design, documentation,
testing, debugging and version control.

Don't overlook SQL. It may not be a fuly-fledged PL, but it is in huge
commercial demand.

99% of employers want programmer who can demosntrate teamwork. Try co-
operating on an open source
project or something like that once you have found your feet.

If you haven't already, install linux. It is a treasure-trove of
development tools.

On 18 Aug, 15:43, Jonathan Campbell <jg.campbell...@gmail.com> wrote:

> - free compiler or environment; C++, Python, Java all tick the box;

I'm finding it hard to think of a PL that doesn't have free
development tools nowadays. Even M$ offer
cut-down ones.

gremnebulin wrote:
> "The fact is, C++ compilers are not trustworthy. They were even worse
> in
> 1992, but some fundamental facts haven't changed: 1) the whole C++
> exception handling thing is fundamentally broken. It's _especially_
> broken for kernels. 2) any compiler or language that likes to hide
> things like memory allocations behind your back just isn't a good
> choice for a kernel. 3) you can write object-oriented code (useful for
> filesystems etc) in C, _without_ the crap that is C++." (LT)

I know why Torvalds hates C++ and loves C, but I still think his
arguments are completely fallacious, prejudiced and wrong.

(No, I'm not saying the linux kernel should be written in C++. I'm
saying Torvald's arguments why it shouldn't are BS.)

> ...hold good for other applications as well. I have personally worked
> on complex sytems where C was chosen
> because it speed and explicit (=easily debuggable) memory allocations.

Yeah, speed. We all know that C++ is somehow magically slower than C
even though the exact same compiler is generating the exact same code
regardless of whether the extension of the source file is .c or .cc.
It's just C++ so it must be slower.

More seriously, C++ is actually easier to make faster than C. For
example, the default memory allocator in linux libc is horribly slow and
can be easily sped up in C++: http://warp.povusers.org/FSBAllocator/

On 18 Aug, 17:05, Juha Nieminen <nos...@thanks.invalid> wrote:
> gremnebulin wrote:
> > "The fact is, C++ compilers are not trustworthy. They were even worse
> > in
> > 1992, but some fundamental facts haven't changed: 1) the whole C++
> > exception handling thing is fundamentally broken. It's _especially_
> > broken for kernels. 2) any compiler or language that likes to hide
> > things like memory allocations behind your back just isn't a good
> > choice for a kernel. 3) you can write object-oriented code (useful for
> > filesystems etc) in C, _without_ the crap that is C++." (LT)
>
> I know why Torvalds hates C++ and loves C, but I still think his
> arguments are completely fallacious, prejudiced and wrong.
>
> (No, I'm not saying the linux kernel should be written in C++. I'm
> saying Torvald's arguments why it shouldn't are BS.)
>
> > ...hold good for other applications as well. I have personally worked
> > on complex sytems where C was chosen
> > because it speed and explicit (=easily debuggable) memory allocations.
>
> Yeah, speed. We all know that C++ is somehow magically slower than C

I didn't say anythign of the kind. Speed is the reason we don't avoid
memory leaks by writing in GC languages.

Juha Nieminen wrote:
> gremnebulin wrote:
>> "The fact is, C++ compilers are not trustworthy. They were even worse
>> in
>> 1992, but some fundamental facts haven't changed: 1) the whole C++
>> exception handling thing is fundamentally broken. It's _especially_
>> broken for kernels. 2) any compiler or language that likes to hide
>> things like memory allocations behind your back just isn't a good
>> choice for a kernel. 3) you can write object-oriented code (useful for
>> filesystems etc) in C, _without_ the crap that is C++." (LT)
>
> I know why Torvalds hates C++ and loves C, but I still think his
> arguments are completely fallacious, prejudiced and wrong.
>
> (No, I'm not saying the linux kernel should be written in C++. I'm
> saying Torvald's arguments why it shouldn't are BS.)
>
>> ...hold good for other applications as well. I have personally worked
>> on complex sytems where C was chosen
>> because it speed and explicit (=easily debuggable) memory allocations.
>
> Yeah, speed. We all know that C++ is somehow magically slower than C
> even though the exact same compiler is generating the exact same code
> regardless of whether the extension of the source file is .c or .cc.
> It's just C++ so it must be slower.
>
> More seriously, C++ is actually easier to make faster than C. For
> example, the default memory allocator in linux libc is horribly slow and
> can be easily sped up in C++: http://warp.povusers.org/FSBAllocator/

Even just regular code with no allocation.

A long time ago,
Dann Corbit once showed me a C++ template version
of some sorting code that I had written in C.
He said that the C++ template versions were a little faster,
and when I raced them,
the C++ template versions were a little faster.

He might have explained why they were faster,
but I don't remember.

--
pete