Re: How should learning to program in c++ be approached, if learning objectives are sought to be customised?
Hey Rajib,
Your questions to the list have been well answered already, but a couple
more points may be helpful. I'm a part-time programmer who's learnt C
and Python, and I'm currently learning Rust.
On 31/05/22 05:21, debian-user-digest-request@lists.debian.org wrote:
Hello!
You said, "... C++ would be much easier to learn once you understand C ..."
I learnt c, but didn't like it, as I didn't find a list of specific
(As already mentioned, C++ would be harder to learn than C, since you
have to learn C first....)
modules (or reusable example code-snippets) to achieve an objective.
The header files are very, very complex and they can't be understood.
The header files use machine language and push those obscure portions
into tiny little black boxes, under the carpet, away from our sight. I
used cscope to read the header files and understand them, but in vain.
To me, c appears as a hodge podge of low level and high level
programming languages. Not a complete programming language in itself.
c language appears to encourage a complex ecosystem of numerous
programmers coming from diverse fields, all working as individual
parts of a very complex machinery.
But c ecosystem appears to discourage a complete programmer who has a
complete idea of the entire machinery and its individual components. A
slight imbalance in super-specialisation could bring down an entire
system.
To master a language for practical purposes, you have to learn the
libraries. I found the same problem as you did when learning Python and
Rust. I had the basics of the language, but wasn't sure how to take the
next steps. E.g. opening and reading/writing to files.
The standard library documentation for both Python and Rust are
comprehensive, but until you build up some fluency with the
documentation and the language concepts that are being used, they are
incomprehensible, and/or difficult to find the right documentation to
look at. With Python in particular, it took me many years (of part time
programming) to become familiar enough to be really comfortable.
I think you are experiencing the same thing with C. (I probably did too
but it's so long ago I don't remember.)
Part of the problem is also the platform you are programming for. At
the same time as learning a language, you also need to learn the
platform. For Debian/Linux/UNIX, the book "Advanced Programming in the
UNIX Environment" by Rago and Stevens will apparently help (I never had
it, but it is well recommended.)
...
back. Java isn't used for building device drivers for the industry, so
far as I have gathered.
Regarding my note, "... had a programming language been developed
that could address both the lowest microprocessor(machine)-level to
the most advanced user level programming, reading, comprehension and
application ...", you said, "... Python should be your choice! ..."
Is it supposed to mean that theoretically, an entire OS could be built
up from scratch using Python? Including device drivers?
You said, "... there is even MicroPython for microcontrollers ...". So
according to your comment, python should be able to build a device
driver as well as an OS. And there already exist such implementations.
As already said, the language best used for device drivers depends on
the kernel you are writing for. C for Debian (linux) etc.
If you write your own kernel, you can write it in any language you like.
Writing a kernel in Python is possible, but you need to also write
some support code in another language (indeed the same for C or rust).
You have the problem of bootstrapping your python interpreter early in
boot. And being interpreted and with a garbage collector, it may be
difficult to write code in python that performs well in real-time. This
may limit what your OS can do. But the point is an OS kernel could be
written in any language, normally you would write your device drivers in
the same language as the kernel or at least a compatible one.
I often wonder aloud why c wasn't re-built to have the modularity and
OOP structure of Java. It would definitely have helped. Yes, I know
that the demand wasn't there, when programmers thought that 1024KB
would address all problems of the world.
But a language could be re-built to incorporate every programming
need. Then aided by a huge library of code snippets, functions,
objects, etc., like Oracle Java repository. But to reach the lowest
level possible.
Something that suits every need is impossible. I think they tried that
with Ada.
I began learning python, but I am not sure if python could be used in
place of Assembly (or machine) Language, addressing programming needs
from the lowest to the highest level. Perhaps your notes answer my
doubts. Would like to know more.
Indeed, python is not the best language for an OS kernel, even if it's
possible. And it can't do everything Assembly can do, if you want speed
and closeness to the hardware.
If you really want a language that lets you access the machine at the
lowest level while allowing some modern high-level language constructs
and a reasonably comprehensive standard library, you should learn Rust.
It's not a language targeted at beginners, though.
In terms of difficulty of learning between C, Python and Rust, I would
say Python is the easiest, C would be in the middle and Rust the
hardest. However both Python and Rust have active communities who will
help learners.
You probably wouldn't be the first novice to attempt to write an OS
kernel as your first serious project, but in the unlikely event that you
succeed you probably would be the first. In other words writing an OS
kernel is not a great first project for a novice.
If you want to be a good programmer (you would need to be to write an OS
kernel), you should learn several languages. If you insist on learning
only one and you want to be able to program OS kernels and device
drivers as well as higher level tasks, then you should learn Rust. But
Python is a more practical staring language as a novice, and you can
move to Rust later.
And yes some AI might take over all programming tasks one day, but I
think there are still some more years for human programmers. I love
programming, it is not a chore. So I'd still do it even if a machine
could do it. But more likely AI will produce tools, and the best
programming will still be done by humans with AI tools to help them.
Cheers,
Alex King
Reply to: