[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Book questions



On Tuesday 14 April 2015 03:35:50 Petter Adsen wrote:
> On Mon, 13 Apr 2015 16:36:44 -0500
>
> David Wright <deblis@lionunicorn.co.uk> wrote:
> > Quoting Petter Adsen (petter@synth.no):
> > > On Mon, 13 Apr 2015 20:21:49 +0300
> > >
> > > Reco <recoverym4n@gmail.com> wrote:
> > > > Let's see as I didn't have OS design in mind. Something like:
> > > >
> > > > Exit codes and their value in real life.
> > > > Strings handling, memory allocation.
> > > > Process control and daemonisation (sp?).
> > > > Signal handling.
> > > > Inter-process communication (sockets, pipes).
> > > > IP protocol use and abuse.
> > > > Shared memory.
> > > > Threads.
> > > > Libraries and their usage.
> > >
> > > Just to pipe in here, these are among the things that I want an
> > > understanding of - especially numbers 3, 4, 5, 6 and 9. With extra
> > > focus on 9 and 6b :) Also things like communication between
> > > processes and devices, file systems, etc. I want to learn how to
> > > find out why things work the way they do, if that makes sense.
> >
> > If you want to understand the basics, there is any number of
> > tutorials on the web. If you want to play with them, then pick a
> > language and go to a web page like
> > https://docs.python.org/3/library/index.html and write some toy
> > programs. Most of these facilities have wrappers that save you
> > having to write C code to create, say, a couple of sockets that talk
> > to each other. If you try this in C and it doesn't work, it might
> > take you half a day to decide whether you've misunderstood the
> > socket concept or just made a programming error.
>
> I can understand that.
>
> > As Reco said,
> >
> > > > [...], and for the complex program you'll probably want
> > > > something else as by today's standards C has poor result/effort
> > > > ratio.
>
> That I can also accept. I see that a lot of people advice me on going
> with something other than C, and I can understand that there are good
> reasons for this advice. While I still want to learn C at some point,
> I'm beginning to think that it might be wise to consider getting a
> good foundation in another language first.
>
> Would Python be appropriate? I see a lot of software these days that
> is written in Python, so it would be helpful in that way. The person I
> am most likely to go to for help knows Python, so that's a bonus. And
> on the subject of books, what would be a good introduction?
>
> Petter

If I can interject a bit here, if one has come up thru the ranks of 
assembly, C is the next logical step above working in that cpu's native 
language. Its functions are basically a core group of assembly language 
functions contained in the various libraries one links in to get the  
job at hand done. For smaller cpu's that is.  I do 99% of my coding on a 
6809/6309 based machine in assembly.  And I am still doing it.

My understanding of the quad core phenom in this machine at that assembly 
level will never happen, so a higher level language that handles all the 
nitty's and gritty's, the greasy side of getting the job done is 
required in order to get anything of consequence done.  So much as I 
hate to say it, C is not my first choice to write a background task 
handler in.

Python would appear to be a good choice but I don't understand it well 
enough to be "productive" in it, so my choice was something a bit more 
conventional, so I'll plead guilty to having bash scripts doing even 
obscure background daemon work here.  Except for large number 
(double-double or double-float) math, it is entirely adequate for the 
jobs I ask it to do.

My point, if there is one, is that the language used, needs to be on a 
scale that allows the job to be done, with few or no "surprises" if one 
is to be productive in terms of getting the job done.  In some senses, 
the higher level lanuages also limit you, by offering only "canned" 
functions unless you can add to the libraries as needed.

Those languages that do such limits on the coder tend to be 5 year 
flashes in the pan and the repos are polluted with them. BUT, they do 
work well for what they do or they would never have gained any traction.  

Python I believe, has more than amply proved that it CAN do the job 
regardless of the versatility the coder asks it to do...

The name given to that language is completely arbitrary.  Python, from 
the greasy side, may well be the best parts of each mix of languages 
that start with bash/lisp and going upward until we have the next great 
thing.

Have we a next great thing waiting in the wings? I am reminded of that 
old saying about beauty being defined in the eye of the beerholder. ;-)  

Besides there is probably a Python 4 waiting to pounce on any upstarts 
that are in effect a wash, rinse, and repeat of an old language. ;-)

Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page <http://geneslinuxbox.net:6309/gene>


Reply to: