subject:"Re\: What's the easiest and\/or simplest part of Linux Kernel\?"

Not in any way disputing your basic premise that it's hard, or 
impossible, to do polymorphism and inheritance in C, with which I agree.


And not to weigh in on whether an object is a machine or vice versa 
(though a pretty good arguement can be made that objects can be viewed 
as finite state machines - and you can find such arguements in the 
literature)..


And also not to weigh in (much) about what's actually important about 
OOP (Alan Kay has more than once pointed out that it's message passing 
and isolation that are important, polymorphism and inheritance are just 
what seem to get the attention.)  By the way: really nice discussion of 
the state of OOP at

http://www.infoq.com/interviews/johnson-armstrong-oop
(on a completely un-related matter, I happened to be looking at Erlang 
from an OO perspective and stumbled across this rather nice interview 
with Rolph Johnson and Joe Armstrong - of Design Patterns and Erlang 
fame, respectively).


Jerry Stuckle wrote:


And no, I did NOT refer to reading a few pages on wikipedia and 
writing a little php.  I do not consider either to be reliable. 
Rather, I referred to recognized experts in the field such as Booch, 
Rumbaugh and Stroustrup.


Kind of flip-flopping to cite recognized experts after dismissing guys 
like  Donovan, Saltzer and Corbato as But they never were that highly 
regarded except in academia - when discussing operating systems and 
systems programming.


And then to cite Booch, Rumbaugh and Stroustrup re. OO programming (ok, 
Stroustrup wrote C++) - but if you want to cite experts - how about Dahl 
and Nygaard (Simula, pretty much invented software objects) and Alan Kay 
(Smalltalk, pretty much invented OOP).  Maybe Joe Armstrong (Erlang) for 
a countervailing view.


But you're too caught up in your own little world to even try to 
understand REAL experts.  Your mantra is I have my mind made up and 
no one will change it.



Sounds more like you're describing yourself, Jerry.

First, you've got to understand who the real experts are, rather than 
finding ones who simply backstop your pre-defined opinion (and.. experts 
are nothing without citations).  Beyond that, why is it that you always 
seem to draw from narrow confines of IBM (or, where  Booch and Rumbaugh 
are concerned, Rational, now part of IBM).  IBM is an important part of 
the computing universe, no contest; but the field, and it's leading 
edge, are much broader than just IBM.


Miles Fidelman

--
In theory, there is no difference between theory and practice.
In practice, there is.    Yogi Berra


--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Archive: http://lists.debian.org/526cf0d0.8070...@meetinghouse.net

Re: What's the easiest and/or simplest part of Linux Kernel?


On 10/27/2013 6:54 AM, Miles Fidelman wrote:

Not in any way disputing your basic premise that it's hard, or
impossible, to do polymorphism and inheritance in C, with which I
agree.

And not to weigh in on whether an object is a machine or vice versa
(though a pretty good arguement can be made that objects can be viewed
as finite state machines - and you can find such arguements in the
literature)..



Sure, you can find all kinds of arguments in literature.  But the 
discussion was not about finite state machines.  And, of course, you can 
call ANYTHING a finite state machine.


But it is also not call finite state machine oriented programming 
because object oriented programming is more appropriate.



And also not to weigh in (much) about what's actually important about
OOP (Alan Kay has more than once pointed out that it's message passing
and isolation that are important, polymorphism and inheritance are just
what seem to get the attention.)  By the way: really nice discussion of
the state of OOP at
http://www.infoq.com/interviews/johnson-armstrong-oop
(on a completely un-related matter, I happened to be looking at Erlang
from an OO perspective and stumbled across this rather nice interview
with Rolph Johnson and Joe Armstrong - of Design Patterns and Erlang
fame, respectively).



That is Alan Kay's opinion, nothing more, nothing less.  Others consider 
inheritance and polymorphism to be quite important.  But then those are 
people who have actually used polymorphism and inheritance effectively.


But then such is the opinion of another academic who has had no (or very 
little) real-world business experience.


Academics get paid to write papers.  Business people get paid to do work.


Jerry Stuckle wrote:


And no, I did NOT refer to reading a few pages on wikipedia and
writing a little php.  I do not consider either to be reliable.
Rather, I referred to recognized experts in the field such as Booch,
Rumbaugh and Stroustrup.


Kind of flip-flopping to cite recognized experts after dismissing guys
like  Donovan, Saltzer and Corbato as But they never were that highly
regarded except in academia - when discussing operating systems and
systems programming.



Yes, all academics who have never (AFAIK) done any business programming.


And then to cite Booch, Rumbaugh and Stroustrup re. OO programming (ok,
Stroustrup wrote C++) - but if you want to cite experts - how about Dahl
and Nygaard (Simula, pretty much invented software objects) and Alan Kay
(Smalltalk, pretty much invented OOP).  Maybe Joe Armstrong (Erlang) for
a countervailing view.


Booch and Rumbaugh also were real world programmers, not just academics. 
 Separately they created OO design patters which were later merged into 
UML - the most commonly used design pattern today.


Others are academics.

And BTW, it isn't limited to programming where the business world thinks 
little of academics.  It goes for many professions.




But you're too caught up in your own little world to even try to
understand REAL experts.  Your mantra is I have my mind made up and
no one will change it.


Sounds more like you're describing yourself, Jerry.

First, you've got to understand who the real experts are, rather than
finding ones who simply backstop your pre-defined opinion (and.. experts
are nothing without citations).  Beyond that, why is it that you always
seem to draw from narrow confines of IBM (or, where  Booch and Rumbaugh
are concerned, Rational, now part of IBM).  IBM is an important part of
the computing universe, no contest; but the field, and it's leading
edge, are much broader than just IBM.

Miles Fidelman



Sure.  Real experts have real experience in the field, using the tools 
to write real programs.  They get paid to do things which make the 
company money.  They don't just sit around and write papers and maybe 
teach a class now and then.


I would love to see some of your experts in a real-world business 
environment.  My bet is they would all fall flat on their faces.


Jerry


--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Archive: http://lists.debian.org/526d19e7.3080...@attglobal.net

Re: What's the easiest and/or simplest part of Linux Kernel?


Jerry Stuckle wrote:



And also not to weigh in (much) about what's actually important about
OOP (Alan Kay has more than once pointed out that it's message passing
and isolation that are important, polymorphism and inheritance are just
what seem to get the attention.)  By the way: really nice discussion of
the state of OOP at
http://www.infoq.com/interviews/johnson-armstrong-oop
(on a completely un-related matter, I happened to be looking at Erlang
from an OO perspective and stumbled across this rather nice interview
with Rolph Johnson and Joe Armstrong - of Design Patterns and Erlang
fame, respectively).



That is Alan Kay's opinion, nothing more, nothing less.  Others 
consider inheritance and polymorphism to be quite important.  But then 
those are people who have actually used polymorphism and inheritance 
effectively.


But then such is the opinion of another academic who has had no (or 
very little) real-world business experience.


Hmm... so the INVENTOR of object oriented programming is not an expert?  
Won the ACM Turing award.  That sort of thing.


Academics get paid to write papers.  Business people get paid to do work.


Sounds like your idea of an expert is some grunt who wrote financial 
software for mainframes.  Mine is more like people who push the state of 
the art, and those who get hired to help make big decisions.



Jerry Stuckle wrote:


And no, I did NOT refer to reading a few pages on wikipedia and
writing a little php.  I do not consider either to be reliable.
Rather, I referred to recognized experts in the field such as Booch,
Rumbaugh and Stroustrup.


Kind of flip-flopping to cite recognized experts after dismissing guys
like  Donovan, Saltzer and Corbato as But they never were that highly
regarded except in academia - when discussing operating systems and
systems programming.



Yes, all academics who have never (AFAIK) done any business programming.


You sure don't know Donovan - he was pretty much the goto guy for 
executive suite consulting in IT.  Cambridge Technology Group was (may 
still be) the go to MIS consulting firm - Donovan made a mint.


On the more general side - if I'm interested in operating systems, guys 
who do business programming are not where I'd look for expertise.  I'd 
look for guys who built large time sharing systems.


Your personal level of ignorace is pretty staggering - you really don't 
seem to have any credibility for deciding who is and isn't an expert.





And then to cite Booch, Rumbaugh and Stroustrup re. OO programming (ok,
Stroustrup wrote C++) - but if you want to cite experts - how about Dahl
and Nygaard (Simula, pretty much invented software objects) and Alan Kay
(Smalltalk, pretty much invented OOP).  Maybe Joe Armstrong (Erlang) for
a countervailing view.


Booch and Rumbaugh also were real world programmers, not just 
academics.  Separately they created OO design patters which were later 
merged into UML - the most commonly used design pattern today.


Well.. perhaps the most talked about.


Others are academics.

And BTW, it isn't limited to programming where the business world 
thinks little of academics.  It goes for many professions.




But you're too caught up in your own little world to even try to
understand REAL experts.  Your mantra is I have my mind made up and
no one will change it.


Sounds more like you're describing yourself, Jerry.

First, you've got to understand who the real experts are, rather than
finding ones who simply backstop your pre-defined opinion (and.. experts
are nothing without citations).  Beyond that, why is it that you always
seem to draw from narrow confines of IBM (or, where  Booch and Rumbaugh
are concerned, Rational, now part of IBM).  IBM is an important part of
the computing universe, no contest; but the field, and it's leading
edge, are much broader than just IBM.

Miles Fidelman



Sure.  Real experts have real experience in the field, using the tools 
to write real programs.  They get paid to do things which make the 
company money.  They don't just sit around and write papers and maybe 
teach a class now and then.


I would love to see some of your experts in a real-world business 
environment.  My bet is they would all fall flat on their faces.


An awful lot of the academics I know have also started quite successful 
high tech firms (or joined academica after retiring from same). (Granted 
that MIT and Harvard professors aren't run-of-the mill academics).







--
In theory, there is no difference between theory and practice.
In practice, there is.    Yogi Berra


--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Archive: http://lists.debian.org/526d242b.5020...@meetinghouse.net

Re: What's the easiest and/or simplest part of Linux Kernel?


On 10/27/2013 10:33 AM, Miles Fidelman wrote:

Jerry Stuckle wrote:



And also not to weigh in (much) about what's actually important about
OOP (Alan Kay has more than once pointed out that it's message passing
and isolation that are important, polymorphism and inheritance are just
what seem to get the attention.)  By the way: really nice discussion of
the state of OOP at
http://www.infoq.com/interviews/johnson-armstrong-oop
(on a completely un-related matter, I happened to be looking at Erlang
from an OO perspective and stumbled across this rather nice interview
with Rolph Johnson and Joe Armstrong - of Design Patterns and Erlang
fame, respectively).



That is Alan Kay's opinion, nothing more, nothing less.  Others
consider inheritance and polymorphism to be quite important.  But then
those are people who have actually used polymorphism and inheritance
effectively.

But then such is the opinion of another academic who has had no (or
very little) real-world business experience.


Hmm... so the INVENTOR of object oriented programming is not an expert?
Won the ACM Turing award.  That sort of thing.


He was not the INVENTOR of object oriented programming.  He is only 
one of many who contributed to the concept.




Academics get paid to write papers.  Business people get paid to do work.


Sounds like your idea of an expert is some grunt who wrote financial
software for mainframes.  Mine is more like people who push the state of
the art, and those who get hired to help make big decisions.


My idea of an expert is one who gets paid for doing the work.  They are 
not grunts - and I'll bet most of your experts would fail in the 
real world.  I would love to see them working in a 200+ person-year 
project, i.e. 50+ programmers working together for 2+ years.





Jerry Stuckle wrote:


And no, I did NOT refer to reading a few pages on wikipedia and
writing a little php.  I do not consider either to be reliable.
Rather, I referred to recognized experts in the field such as Booch,
Rumbaugh and Stroustrup.


Kind of flip-flopping to cite recognized experts after dismissing guys
like  Donovan, Saltzer and Corbato as But they never were that highly
regarded except in academia - when discussing operating systems and
systems programming.



Yes, all academics who have never (AFAIK) done any business programming.


You sure don't know Donovan - he was pretty much the goto guy for
executive suite consulting in IT.  Cambridge Technology Group was (may
still be) the go to MIS consulting firm - Donovan made a mint.



Not really.  A few C-level executives would hire them, mainly to cover 
their butts.  But not IT departments, where the real work is done.



On the more general side - if I'm interested in operating systems, guys
who do business programming are not where I'd look for expertise.  I'd
look for guys who built large time sharing systems.



Changing the subject again?


Your personal level of ignorace is pretty staggering - you really don't
seem to have any credibility for deciding who is and isn't an expert.



Ah, once again the personal attacks.  OK, here's one for YOU.  You 
obviously are no more than another academic, trying to justify your 
position in a world where you are shunned by people who do the real work.





And then to cite Booch, Rumbaugh and Stroustrup re. OO programming (ok,
Stroustrup wrote C++) - but if you want to cite experts - how about Dahl
and Nygaard (Simula, pretty much invented software objects) and Alan Kay
(Smalltalk, pretty much invented OOP).  Maybe Joe Armstrong (Erlang) for
a countervailing view.


Booch and Rumbaugh also were real world programmers, not just
academics.  Separately they created OO design patters which were later
merged into UML - the most commonly used design pattern today.


Well.. perhaps the most talked about.


And the most commonly used - which you would know if you did any 
real-world programming.




Others are academics.

And BTW, it isn't limited to programming where the business world
thinks little of academics.  It goes for many professions.



But you're too caught up in your own little world to even try to
understand REAL experts.  Your mantra is I have my mind made up and
no one will change it.


Sounds more like you're describing yourself, Jerry.

First, you've got to understand who the real experts are, rather than
finding ones who simply backstop your pre-defined opinion (and.. experts
are nothing without citations).  Beyond that, why is it that you always
seem to draw from narrow confines of IBM (or, where  Booch and Rumbaugh
are concerned, Rational, now part of IBM).  IBM is an important part of
the computing universe, no contest; but the field, and it's leading
edge, are much broader than just IBM.

Miles Fidelman



Sure.  Real experts have real experience in the field, using the tools
to write real programs.  They get paid to do things which make the
company money.  They don't just sit around and write papers and maybe
teach a class

Re: What's the easiest and/or simplest part of Linux Kernel?


Jerry Stuckle wrote:

On 10/27/2013 10:33 AM, Miles Fidelman wrote:

Jerry Stuckle wrote:



And also not to weigh in (much) about what's actually important about
OOP (Alan Kay has more than once pointed out that it's message passing
and isolation that are important, polymorphism and inheritance are 
just
what seem to get the attention.)  By the way: really nice 
discussion of

the state of OOP at
http://www.infoq.com/interviews/johnson-armstrong-oop
(on a completely un-related matter, I happened to be looking at Erlang
from an OO perspective and stumbled across this rather nice interview
with Rolph Johnson and Joe Armstrong - of Design Patterns and Erlang
fame, respectively).



That is Alan Kay's opinion, nothing more, nothing less. Others
consider inheritance and polymorphism to be quite important. But then
those are people who have actually used polymorphism and inheritance
effectively.

But then such is the opinion of another academic who has had no (or
very little) real-world business experience.


Hmm... so the INVENTOR of object oriented programming is not an expert?
Won the ACM Turing award.  That sort of thing.


He was not the INVENTOR of object oriented programming.  He is only 
one of many who contributed to the concept.


He is widely credited for both creating the term and as the father of 
object oriented programming - pretty much first instantiated in Smalltalk.


He won the ACM Turing Award For pioneering many of the ideas at the 
root of contemporary object-oriented programming languages, leading the 
team that developed Smalltalk, and for fundamental contributions to 
personal computing.


Note that the notion of software objects is usually associated with 
the Simula Team.







Academics get paid to write papers.  Business people get paid to do 
work.


Sounds like your idea of an expert is some grunt who wrote financial
software for mainframes.  Mine is more like people who push the state of
the art, and those who get hired to help make big decisions.


My idea of an expert is one who gets paid for doing the work. They are 
not grunts - and I'll bet most of your experts would fail in the 
real world.  I would love to see them working in a 200+ person-year 
project, i.e. 50+ programmers working together for 2+ years.


Oh, you mean a team with incredible amounts of top-down breakdown of 
work down to individual modules written by code monkeys?


Let's see, I believe I included Jerry Saltzer as an o/s expert. Well, in 
addition to being a team leader on Multics, he was the author of RUNOFF, 
the predecessor of pretty much all typesetting programs - and one of the 
primary contributors to PC/IP (first TCP/IP stack for the IBM PC) and 
Kerberos.


But, let's see - by your definition Ken Thompson and Dennis Ritchie 
would not be the pre-eminent experts on Unix (even though they wrote 
it),  and Dennis Ritchie would not be the preeminent expert on C (even 
though he wrote it).  After all, they weren't working on huge 
programming projects, and Bell Labs was kind of academic.  And Linus 
Torvalds wouldn't be an expert in Linux.


Or what about Vint Cerf and Bob Kahn - they authored TCP/IP, and pretty 
much made the Internet happen - but they were academics at the time, so 
that doesn't count?


What about Donald Knuth - only the world's pre-eminent expert on 
algorithms.  What, he doesn't count?  After all, he's just an academic.  
Doesn't count that The Art of Computer Programming is to programming 
what the CRC handbook is to math.


I might also point out that most of those writing financial software are 
buiding it on top of Oracle, or SAP, or PeopleSoft or some other fairly 
complicated platform.  Now the folks who wrote Oracle are certainly 
experts in database technology.  Writing forms and reports on top of 
Oracle, on the other hand, is not rocket science.







Jerry Stuckle wrote:


And no, I did NOT refer to reading a few pages on wikipedia and
writing a little php.  I do not consider either to be reliable.
Rather, I referred to recognized experts in the field such as Booch,
Rumbaugh and Stroustrup.


Kind of flip-flopping to cite recognized experts after dismissing 
guys

like  Donovan, Saltzer and Corbato as But they never were that highly
regarded except in academia - when discussing operating systems and
systems programming.



Yes, all academics who have never (AFAIK) done any business 
programming.


You sure don't know Donovan - he was pretty much the goto guy for
executive suite consulting in IT.  Cambridge Technology Group was (may
still be) the go to MIS consulting firm - Donovan made a mint.



Not really.  A few C-level executives would hire them, mainly to cover 
their butts.  But not IT departments, where the real work is done.


Says you, based on what?



On the more general side - if I'm interested in operating systems, guys
who do business programming are not where I'd look for expertise.  I'd
look for guys who built large time sharing systems.



Changing

Re: What's the easiest and/or simplest part of Linux Kernel?

2013-10-27 Thread David Guntner

Miles Fidelman grabbed a keyboard and wrote:

[tl;dr]

Can you guys PLEASE take this off-topic discussion somewhere else?
Like, maybe, the off-topic list (which, oddly enough, was created for
topics like this)

  --Dave




smime.p7s
Description: S/MIME Cryptographic Signature

Re: What's the easiest and/or simplest part of Linux Kernel?

2013-10-27 Thread Cybe R. Wizard

On Sun, 27 Oct 2013 16:51:48 -0400
Miles Fidelman mfidel...@meetinghouse.net wrote:

 No, most business would NOT hire them as programmers - they couldn't 
 afford them.

From an outside layman (but very interested) perspective the argument
boils down to which is more important, the use of tools or the
invention of tools  

I content that, without tools, no work of any significance can be
done.

Invention trumps work.   ~Always.~   It is self-evident in the fact that
invention always precedes work.  Without invention we would still be
stacking sticks and scooping mud by hand.

Academics rule, or should.

Cybe R. Wizard
-- 
Nice computers don't go down.
Larry Niven, Steven Barnes
The Barsoom Project


--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/2013102717.30be24a6.cybe_r_wiz...@earthlink.net

Re: What's the easiest and/or simplest part of Linux Kernel?


On 10/27/2013 4:51 PM, Miles Fidelman wrote:

Jerry Stuckle wrote:

On 10/27/2013 10:33 AM, Miles Fidelman wrote:

Jerry Stuckle wrote:



And also not to weigh in (much) about what's actually important about
OOP (Alan Kay has more than once pointed out that it's message passing
and isolation that are important, polymorphism and inheritance are
just
what seem to get the attention.)  By the way: really nice
discussion of
the state of OOP at
http://www.infoq.com/interviews/johnson-armstrong-oop
(on a completely un-related matter, I happened to be looking at Erlang
from an OO perspective and stumbled across this rather nice interview
with Rolph Johnson and Joe Armstrong - of Design Patterns and Erlang
fame, respectively).



That is Alan Kay's opinion, nothing more, nothing less. Others
consider inheritance and polymorphism to be quite important. But then
those are people who have actually used polymorphism and inheritance
effectively.

But then such is the opinion of another academic who has had no (or
very little) real-world business experience.


Hmm... so the INVENTOR of object oriented programming is not an expert?
Won the ACM Turing award.  That sort of thing.


He was not the INVENTOR of object oriented programming.  He is only
one of many who contributed to the concept.


He is widely credited for both creating the term and as the father of
object oriented programming - pretty much first instantiated in Smalltalk.

He won the ACM Turing Award For pioneering many of the ideas at the
root of contemporary object-oriented programming languages, leading the
team that developed Smalltalk, and for fundamental contributions to
personal computing.

Note that the notion of software objects is usually associated with
the Simula Team.



As I said - he is only ONE of several who worked on Object oriented 
programming.  He may have created the term - but he did not originate 
the idea.


And who cares about the ACM Turing Award?  It's really not all that 
meaningful - except in the academic world.









Academics get paid to write papers.  Business people get paid to do
work.


Sounds like your idea of an expert is some grunt who wrote financial
software for mainframes.  Mine is more like people who push the state of
the art, and those who get hired to help make big decisions.


My idea of an expert is one who gets paid for doing the work. They are
not grunts - and I'll bet most of your experts would fail in the
real world.  I would love to see them working in a 200+ person-year
project, i.e. 50+ programmers working together for 2+ years.


Oh, you mean a team with incredible amounts of top-down breakdown of
work down to individual modules written by code monkeys?

Let's see, I believe I included Jerry Saltzer as an o/s expert. Well, in
addition to being a team leader on Multics, he was the author of RUNOFF,
the predecessor of pretty much all typesetting programs - and one of the
primary contributors to PC/IP (first TCP/IP stack for the IBM PC) and
Kerberos.

But, let's see - by your definition Ken Thompson and Dennis Ritchie
would not be the pre-eminent experts on Unix (even though they wrote
it),  and Dennis Ritchie would not be the preeminent expert on C (even
though he wrote it).  After all, they weren't working on huge
programming projects, and Bell Labs was kind of academic.  And Linus
Torvalds wouldn't be an expert in Linux.

Or what about Vint Cerf and Bob Kahn - they authored TCP/IP, and pretty
much made the Internet happen - but they were academics at the time, so
that doesn't count?

What about Donald Knuth - only the world's pre-eminent expert on
algorithms.  What, he doesn't count?  After all, he's just an academic.
Doesn't count that The Art of Computer Programming is to programming
what the CRC handbook is to math.

I might also point out that most of those writing financial software are
buiding it on top of Oracle, or SAP, or PeopleSoft or some other fairly
complicated platform.  Now the folks who wrote Oracle are certainly
experts in database technology.  Writing forms and reports on top of
Oracle, on the other hand, is not rocket science.



Gee, you sure know how to drop names, don't you?  And how to post as 
many different subjects in one paragraph as you can.


Typical when you don't have a real answer to the discussion.






Jerry Stuckle wrote:


And no, I did NOT refer to reading a few pages on wikipedia and
writing a little php.  I do not consider either to be reliable.
Rather, I referred to recognized experts in the field such as Booch,
Rumbaugh and Stroustrup.


Kind of flip-flopping to cite recognized experts after dismissing
guys
like  Donovan, Saltzer and Corbato as But they never were that highly
regarded except in academia - when discussing operating systems and
systems programming.



Yes, all academics who have never (AFAIK) done any business
programming.


You sure don't know Donovan - he was pretty much the goto guy for
executive suite consulting in IT.  Cambridge

Re: What's the easiest and/or simplest part of Linux Kernel?


On 10/27/2013 5:02 PM, David Guntner wrote:

Miles Fidelman grabbed a keyboard and wrote:

[tl;dr]

Can you guys PLEASE take this off-topic discussion somewhere else?
Like, maybe, the off-topic list (which, oddly enough, was created for
topics like this)

   --Dave




Dave,

Don't worry - I'm through with this troll.

Jerry


--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Archive: http://lists.debian.org/526dc01d.8000...@attglobal.net

Re: What's the easiest and/or simplest part of Linux Kernel?


On 10/27/2013 6:55 PM, Cybe R. Wizard wrote:

On Sun, 27 Oct 2013 16:51:48 -0400
Miles Fidelman mfidel...@meetinghouse.net wrote:


No, most business would NOT hire them as programmers - they couldn't
afford them.


 From an outside layman (but very interested) perspective the argument
boils down to which is more important, the use of tools or the
invention of tools

I content that, without tools, no work of any significance can be
done.

Invention trumps work.   ~Always.~   It is self-evident in the fact that
invention always precedes work.  Without invention we would still be
stacking sticks and scooping mud by hand.

Academics rule, or should.

Cybe R. Wizard



Cybe,

And who do you think wrote the tools such as Windows, Linux, C++ 
compilers, Oracle Database and more?  Hint: NONE of them were written by 
academics.


Jerry


--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Archive: http://lists.debian.org/526dc07d.9080...@attglobal.net

Re: What's the easiest and/or simplest part of Linux Kernel?

2013-10-27 Thread David Guntner

Jerry Stuckle grabbed a keyboard and wrote:
 On 10/27/2013 5:02 PM, David Guntner wrote:
 Miles Fidelman grabbed a keyboard and wrote:

 [tl;dr]

 Can you guys PLEASE take this off-topic discussion somewhere else?
 Like, maybe, the off-topic list (which, oddly enough, was created for
 topics like this)
 
 Dave,
 
 Don't worry - I'm through with this troll.

What I, and I suspect a number of people here, would actually prefer
would be for you and the others continuing it to be done with the whole
damn OFF TOPIC thread.  If you want to continue it, please take it to
the off-topic list.

 --Dave





smime.p7s
Description: S/MIME Cryptographic Signature

Re: What's the easiest and/or simplest part of Linux Kernel?


Jerry Stuckle wrote:

On 10/27/2013 5:02 PM, David Guntner wrote:

Miles Fidelman grabbed a keyboard and wrote:

[tl;dr]

Can you guys PLEASE take this off-topic discussion somewhere else?
Like, maybe, the off-topic list (which, oddly enough, was created for
topics like this)

   --Dave




Dave,

Don't worry - I'm through with this troll.

Jerry




Gee change the name, and my reaction entirely.

--
In theory, there is no difference between theory and practice.
In practice, there is.    Yogi Berra


--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Archive: http://lists.debian.org/526dc862.3040...@meetinghouse.net

Re: What's the easiest and/or simplest part of Linux Kernel?

2013-10-26 Thread Jerry Stuckle


On 10/25/2013 10:46 PM, Zenaan Harkness wrote:

On 10/26/13, Jerry Stuckle jstuc...@attglobal.net wrote:

On 10/25/2013 9:59 PM, Zenaan Harkness wrote:

On 10/26/13, Jerry Stuckle jstuc...@attglobal.net wrote:

On 10/25/2013 8:59 PM, Zenaan Harkness wrote:



Anyway, from an onlookers perspective you are being excessively
pedantic and hung up on different terms which are simply intended to
convey some meaning - and you have done so without saying _why_
'machine' is a 'bad' term to use to describe the properties of an
'object' in OOP.


Machine is a bad term because it is not Machine Oriented
Programming.  It is Object Oriented Programming - because it emulates
real world objects - not machines.


Here I should have said thank you for providing your reason.



Sorry I came across a bit harsh - but I'm tired of experts who have 
maybe read a couple of pages on the internet and think they know 
everything about OOP, but have never written any REAL OO code (even 
though they claim they have).  Thinks like not using encapsulation 
because it's work to write all of those setters and getters, only 
validating the contents of the object when it is stored in a database 
(what if it's used to make decisions before being stored - or isn't 
stored at all, as a business object?) or claiming you can do inheritance 
and/or polymorphism in C.  Most of these experts have limited 
experience in database (i.e. FoxPro, DBase) or web (usually PHP) 
programming.  And unfortunately, some of these people have put up web 
pages, promoting these misunderstanding which others use in their 
arguments.


The one thing they have in common is none of them have worked with a 
real OO language such as SmallTalk or Java (they may have worked with 
C++, but they use it more as a functional programming language rather 
than use the OO features).


I don't claim to be an expert in the field, but I have been doing OO 
since the mid 80's, starting with SmallTalk.  And I learned from real 
experts - reading their books and attending forums where they were 
speaking.  I've also worked on several large projects over the years, 
both as a programmer and a project manager.



And a machine is not a real-world object?


All machines are objects.  But not all objects are machines.


I agree.


Are you saying that I should refrain from using the term machine as
an analogy to help explain OOP, because some recognized experts did
not use that term?


Only if you don't want to look like an idiot.  People who make up their
own terms for something most of the rest of the world accept look that way.


Oh.

Dear me.

Guess I better just stick to Object then. Don't want to look like an
idiot. I shall submit myself to most of the rest of the world's
acceptance.

I guess I should appreciate that you are trying to stop some of us
from looking like idiots. There is possibly some worth in that
intention. I however be not tooo worried about others' think ... can
lead to certain - unproductive? - outcomes.



Another thing I see often is people misusing terms - it's quite common 
and I get pretty tired of that end, also.  I'm not a purist, but one 
thing I've found when working on large projects - it is very important 
that *everyone* use the same terminology and *everyone* understand what 
that terminology means.  When people start using other terms it rapidly 
leads to a dangerous lack of communications - or worse yet, 
miscommunication.





Besides, my point is not to attack object as being a useful term nor
to attack object as being the preferred/accepted/sanctioned term.
Can you see my point?


Nope.


/shrug Someone's loss?



No, I just don't see the point you're trying to make.




My point was simply that machine is (in my opinion, and evidently in
the opinions of others), useful to help describe or explain OOP.


As I said before - not all objects are machines.


True. Very true. I agree. I really do agree.



I did not ask you if machine was the best term. I humbly disagree with
you, if what you are saying is that machine is a bad term to help
describe or teach the object part of OOP to those trying to
understand it.


Feel free to disagree.  You're the one not using the commonly recognized
terminology, not me.


I wrote an article back in the day for my university newsletter, using
a tree as an analogy to explain Objects - I did have much to learn,
but in hindsight, machine, or engine, would likely have been a better
analogy. I think I was trying to point out that _anything_ can be
modeled as an Object.

Anyway, as long as there's a good crucifixion under way for crimes
against terminology ... popcorn anyone?



Differences in terminology lead to differences in understanding.  This 
leads to miscommunication.





Terminology junkies are welcome to their terms. Some on this list have
graciously ceded to _your_ preferred terms, in an endeavour to attempt
to maintain actual communication. I think that is a wise thing.


I just go by what recognized

Re: What's the easiest and/or simplest part of Linux Kernel?

2013-10-26 Thread Joel Rees

On Sat, Oct 26, 2013 at 10:59 AM, Zenaan Harkness z...@freedbms.net wrote:
 On 10/26/13, Jerry Stuckle jstuc...@attglobal.net wrote:
[...]
 Machine is a bad term because it is not Machine Oriented
 Programming.  It is Object Oriented Programming - because it emulates
 real world objects - not machines.

 And a machine is not a real-world object?

 [...]

 Terminology junkies are welcome to their terms. Some on this list have
 graciously ceded to _your_ preferred terms, in an endeavour to attempt
 to maintain actual communication. I think that is a wise thing.

 Good luck,
 Zenaan

Thanks for your efforts, Zeenan.

However, don't misinterpret the silence. I've just run out of time to
argue with Jerry.

I mean, yeah, when he trivialized my whole career into a bit of
reading a few pages on wikipedia and writing a little php, that got my
back up. But satisfying my ego is not going to put bread on my
family's table. I have more important things to do.

-- 
Joel Rees

Be careful where you see conspiracy.
Look first in your own heart.


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/CAAr43iP1JqH54ovbS12JEMKnMwqMGo=z5klgcfn4uetdkzb...@mail.gmail.com

Re: What's the easiest and/or simplest part of Linux Kernel?

2013-10-26 Thread Jerry Stuckle


On 10/26/2013 1:12 PM, Joel Rees wrote:

On Sat, Oct 26, 2013 at 10:59 AM, Zenaan Harkness z...@freedbms.net wrote:

On 10/26/13, Jerry Stuckle jstuc...@attglobal.net wrote:
[...]

Machine is a bad term because it is not Machine Oriented
Programming.  It is Object Oriented Programming - because it emulates
real world objects - not machines.


And a machine is not a real-world object?

[...]

Terminology junkies are welcome to their terms. Some on this list have
graciously ceded to _your_ preferred terms, in an endeavour to attempt
to maintain actual communication. I think that is a wise thing.

Good luck,
Zenaan


Thanks for your efforts, Zeenan.

However, don't misinterpret the silence. I've just run out of time to
argue with Jerry.

I mean, yeah, when he trivialized my whole career into a bit of
reading a few pages on wikipedia and writing a little php, that got my
back up. But satisfying my ego is not going to put bread on my
family's table. I have more important things to do.



What you don't understand is YOU are the only one who can trivialize 
YOUR career.  No one else can.


And no, I did NOT refer to reading a few pages on wikipedia and writing 
a little php.  I do not consider either to be reliable.  Rather, I 
referred to recognized experts in the field such as Booch, Rumbaugh and 
Stroustrup.


But you're too caught up in your own little world to even try to 
understand REAL experts.  Your mantra is I have my mind made up and no 
one will change it.


Such is the life of those who will not learn.


--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Archive: http://lists.debian.org/526c7506.5000...@attglobal.net

Re: What's the easiest and/or simplest part of Linux Kernel?

On 8/29/13, Jerry Stuckle jstuc...@attglobal.net wrote:
On 8/29/2013 12:45 AM, Joel Rees wrote:
(I really don't have time to do this.)

On Thu, Aug 29, 2013 at 12:17 PM,
[Somebody replied to somebody, arguing that C can't do objects.]

The syntax does become obtuse, unfun, cluttered, etc., but it can be
done.

I didn't say C can't do objects. I said it can't do Object Oriented
Programming. Two entirely different things.

(To get the neurons connecting, think about early objective-C, when
the object stuff was done with a special purpose pre-processor.

Shoot. Don't forget that C++ itself was once a pre-processor for C.)

That's like saying C is a preprocessor for assembler. Sure, the
original C++ tools were preprocessors. However, they were preprocessors
which provided the tools necessary to do OOP.

Good start.

Admittedly, the object syntax becomes a separate syntax and language
from the C part when you do OOP in unadorned C. You have to leave the
basic operators (+-*/%, etc.) out of the object-oriented language and
syntax. (Which is part of the reason it becomes unfun.)

Please show how you can do inheritance and polymorphism in C.

Not so good finish. Looking at the above, we could say use an
old/original preprocessor? Or do that preprocessors work by hand?

And why
do you need to leave the basic operators out? They are inherent to both
languages.

You have to use #include skillfully, and you have to explicitly put
function pointers in structures. It kind of turns things upside down,
a bit, and a little inside-out. It'll make even seasoned C programmers
seasick. And the syntax is not as flexible as C++.

Again, please show how to do inheritance and polymorphism in C.

As above ...

Which is all why C++ was written as a separate language.

But it can be done.

Once again, please show how to do inheritance and polymorphism in C.

Next you'll be saying you can't do functional or modular programming
in machine code...

By the way, mathematically speaking, objects are machines.

Maybe mathematically speaking, but we're talking programming here. In
programming, variables have state. Functions have behavior. Objects
have both state and behavior.

Mathematically, we make ... declarations or assertions :)

0A This byte of ram we shall call a variable.
0B This byte of ram we shall call a pointer.
0C This byte of ram shall be the program start instruction.

It is not only reasonable, but useful to some people learning, to say
that a programming object ... is like a machine.

So let me fix the statement:
Mathematically speaking, objects are machines; programmatically
speaking, objects are like machines.

That wasn't so hard was it?

Lets be flexible in our understanding of each other, when doing so
causes no problem,
Zenaan

--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive:
http://lists.debian.org/CAOsGNSQpQbrXeBfUS=s10zwwbchdpn2ebcxcaxklizha34-...@mail.gmail.com

Re: What's the easiest and/or simplest part of Linux Kernel?

On 8/29/13, Jerry Stuckle jstuc...@attglobal.net wrote:
On 8/28/2013 7:52 PM, berenger.mo...@neutralite.org wrote:

Here is the important part: Each object can be viewed as an independent
machine with a distinct role or responsibility..
Nothing forbid to do that in C. I took the example of the SDL,
previously. Does not it really match to that phrase?
When I use SDL in a C++ program, I create 1 class with a constructor
which call SDL_CreateSurface, while the destructor calls
SDL_FreeSurface. I simply use the automated RAII stuff, which is the
feature C lacks. Well... at least, in C, you can use RAII, by hand. Not
only with Java or C#, or at least, not as easily (those languages are
designed to use a garbage collector...can be useful sometimes.).

It is not a machine. It is an object. That's why it is called Object
Oriented Programming.

Well. We of the firm assertions disposition often fall fatally to
... firm assertions.

Jerry, perhaps you might soften your insistence that others use
JERRY'S DEFITION as THE ONLY TRUE DEFINITION OF THIS COMPUTERY
TERM!!!

How warm and encouraging would it be if you had instead said something
like I would prefer that the term object were not conflated with
'machine' for the following reasons ...

Anyway, from an onlookers perspective you are being excessively
pedantic and hung up on different terms which are simply intended to
convey some meaning - and you have done so without saying _why_
'machine' is a 'bad' term to use to describe the properties of an
'object' in OOP.

Regards,
Zenaan

--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive:
http://lists.debian.org/CAOsGNSStTBrooj0qtFd-ZwJdhOVk=pY3wpe7qdG=9rwvtqz...@mail.gmail.com

Re: What's the easiest and/or simplest part of Linux Kernel?

2013-10-25 Thread Jerry Stuckle


On 10/25/2013 8:59 PM, Zenaan Harkness wrote:

On 8/29/13, Jerry Stuckle jstuc...@attglobal.net wrote:


Please show how you can do inheritance and polymorphism in C.


Not so good finish. Looking at the above, we could say use an
old/original preprocessor? Or do that preprocessors work by hand?



Then you should easily be able to show how you can do inheritance and 
polymorphism in C.



And why
do you need to leave the basic operators out?  They are inherent to both
languages.


You have to use #include skillfully, and you have to explicitly put
function pointers in structures. It kind of turns things upside down,
a bit, and a little inside-out. It'll make even seasoned C programmers
seasick. And the syntax is not as flexible as C++.



Again, please show how to do inheritance and polymorphism in C.


As above ...



Still can't do it?


Which is all why C++ was written as a separate language.

But it can be done.


Once again, please show how to do inheritance and polymorphism in C.


Next you'll be saying you can't do functional or modular programming
in machine code...



Don't put words in my mouth.


By the way, mathematically speaking, objects are machines.


Maybe mathematically speaking, but we're talking programming here.  In
programming, variables have state.  Functions have behavior.  Objects
have both state and behavior.


Mathematically, we make ... declarations or assertions :)

0A This byte of ram we shall call a variable.
0B This byte of ram we shall call a pointer.
0C This byte of ram shall be the program start instruction.

It is not only reasonable, but useful to some people learning, to say
that a programming object ... is like a machine.

So let me fix the statement:
Mathematically speaking, objects are machines; programmatically
speaking, objects are like machines.

That wasn't so hard was it?

Lets be flexible in our understanding of each other, when doing so
causes no problem,
Zenaan




No, objects are not machines or like machines.  A ball is an object. 
 Would you call it a machine?  How about a can of dog food?


But both are objects, and can be emulated in OO programming.

Jerry


--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Archive: http://lists.debian.org/526b1b46.2040...@attglobal.net

Re: What's the easiest and/or simplest part of Linux Kernel?

2013-10-25 Thread Jerry Stuckle


On 10/25/2013 8:59 PM, Zenaan Harkness wrote:

On 8/29/13, Jerry Stuckle jstuc...@attglobal.net wrote:

On 8/28/2013 7:52 PM, berenger.mo...@neutralite.org wrote:



Here is the important part: Each object can be viewed as an independent
machine with a distinct role or responsibility..
Nothing forbid to do that in C. I took the example of the SDL,
previously. Does not it really match to that phrase?
When I use SDL in a C++ program, I create 1 class with a constructor
which call SDL_CreateSurface, while the destructor calls
SDL_FreeSurface. I simply use the automated RAII stuff, which is the
feature C lacks. Well... at least, in C, you can use RAII, by hand. Not
only with Java or C#, or at least, not as easily (those languages are
designed to use a garbage collector...can be useful sometimes.).



It is not a machine.  It is an object.  That's why it is called Object
Oriented Programming.


Well. We of the firm assertions disposition often fall fatally to
... firm assertions.

Jerry, perhaps you might soften your insistence that others use
JERRY'S DEFITION as THE ONLY TRUE DEFINITION OF THIS COMPUTERY
TERM!!!



That is not MY definition.  It is the definition put forth by recognized 
experts in OO programming such as Booch, Rumbaugh and Stroustrup.  If 
you want to argue definitions, I suggest you argue with them.



How warm and encouraging would it be if you had instead said something
like I would prefer that the term object were not conflated with
'machine' for the following reasons ...



Maybe to you.  I follow the experts' definitions.


Anyway, from an onlookers perspective you are being excessively
pedantic and hung up on different terms which are simply intended to
convey some meaning - and you have done so without saying _why_
'machine' is a 'bad' term to use to describe the properties of an
'object' in OOP.

Regards,
Zenaan




Machine is a bad term because it is not Machine Oriented 
Programming.  It is Object Oriented Programming - because it emulates 
real world objects - not machines.


Jerry


--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Archive: http://lists.debian.org/526b1c39.8080...@attglobal.net

Re: What's the easiest and/or simplest part of Linux Kernel?

On 10/26/13, Jerry Stuckle jstuc...@attglobal.net wrote:
On 10/25/2013 8:59 PM, Zenaan Harkness wrote:
On 8/29/13, Jerry Stuckle jstuc...@attglobal.net wrote:
On 8/28/2013 7:52 PM, berenger.mo...@neutralite.org wrote:

Here is the important part: Each object can be viewed as an
independent
machine with a distinct role or responsibility..
Nothing forbid to do that in C. I took the example of the SDL,
previously. Does not it really match to that phrase?
When I use SDL in a C++ program, I create 1 class with a constructor
which call SDL_CreateSurface, while the destructor calls
SDL_FreeSurface. I simply use the automated RAII stuff, which is the
feature C lacks. Well... at least, in C, you can use RAII, by hand. Not
only with Java or C#, or at least, not as easily (those languages are
designed to use a garbage collector...can be useful sometimes.).

It is not a machine. It is an object. That's why it is called Object
Oriented Programming.

Well. We of the firm assertions disposition often fall fatally to
... firm assertions.

Jerry, perhaps you might soften your insistence that others use
JERRY'S DEFITION as THE ONLY TRUE DEFINITION OF THIS COMPUTERY
TERM!!!

That is not MY definition. It is the definition put forth by recognized
experts in OO programming such as Booch, Rumbaugh and Stroustrup. If
you want to argue definitions, I suggest you argue with them.

How warm and encouraging would it be if you had instead said something
like I would prefer that the term object were not conflated with
'machine' for the following reasons ...

Maybe to you. I follow the experts' definitions.

Regards,
Zenaan

Machine is a bad term because it is not Machine Oriented
Programming. It is Object Oriented Programming - because it emulates
real world objects - not machines.

And a machine is not a real-world object?

Are you saying that I should refrain from using the term machine as
an analogy to help explain OOP, because some recognized experts did
not use that term?

Besides, my point is not to attack object as being a useful term nor
to attack object as being the preferred/accepted/sanctioned term.
Can you see my point?

My point was simply that machine is (in my opinion, and evidently in
the opinions of others), useful to help describe or explain OOP.

I did not ask you if machine was the best term. I humbly disagree with
you, if what you are saying is that machine is a bad term to help
describe or teach the object part of OOP to those trying to
understand it.

Good luck,
Zenaan

--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive:
http://lists.debian.org/CAOsGNSSKXPxZG6nh-Lkdwu9o=6bnE7CZhPHb3j1uct0mKsm=0...@mail.gmail.com

Re: What's the easiest and/or simplest part of Linux Kernel?

2013-10-25 Thread Jerry Stuckle


On 10/25/2013 9:59 PM, Zenaan Harkness wrote:

On 10/26/13, Jerry Stuckle jstuc...@attglobal.net wrote:

On 10/25/2013 8:59 PM, Zenaan Harkness wrote:

On 8/29/13, Jerry Stuckle jstuc...@attglobal.net wrote:

On 8/28/2013 7:52 PM, berenger.mo...@neutralite.org wrote:



Here is the important part: Each object can be viewed as an
independent
machine with a distinct role or responsibility..
Nothing forbid to do that in C. I took the example of the SDL,
previously. Does not it really match to that phrase?
When I use SDL in a C++ program, I create 1 class with a constructor
which call SDL_CreateSurface, while the destructor calls
SDL_FreeSurface. I simply use the automated RAII stuff, which is the
feature C lacks. Well... at least, in C, you can use RAII, by hand. Not
only with Java or C#, or at least, not as easily (those languages are
designed to use a garbage collector...can be useful sometimes.).



It is not a machine.  It is an object.  That's why it is called Object
Oriented Programming.


Well. We of the firm assertions disposition often fall fatally to
... firm assertions.

Jerry, perhaps you might soften your insistence that others use
JERRY'S DEFITION as THE ONLY TRUE DEFINITION OF THIS COMPUTERY
TERM!!!



That is not MY definition.  It is the definition put forth by recognized
experts in OO programming such as Booch, Rumbaugh and Stroustrup.  If
you want to argue definitions, I suggest you argue with them.


How warm and encouraging would it be if you had instead said something
like I would prefer that the term object were not conflated with
'machine' for the following reasons ...



Maybe to you.  I follow the experts' definitions.


Anyway, from an onlookers perspective you are being excessively
pedantic and hung up on different terms which are simply intended to
convey some meaning - and you have done so without saying _why_
'machine' is a 'bad' term to use to describe the properties of an
'object' in OOP.

Regards,
Zenaan




Machine is a bad term because it is not Machine Oriented
Programming.  It is Object Oriented Programming - because it emulates
real world objects - not machines.


And a machine is not a real-world object?



All machines are objects.  But not all objects are machines.


Are you saying that I should refrain from using the term machine as
an analogy to help explain OOP, because some recognized experts did
not use that term?



Only if you don't want to look like an idiot.  People who make up their 
own terms for something most of the rest of the world accept look that way.



Besides, my point is not to attack object as being a useful term nor
to attack object as being the preferred/accepted/sanctioned term.
Can you see my point?



Nope.


My point was simply that machine is (in my opinion, and evidently in
the opinions of others), useful to help describe or explain OOP.



As I said before - not all objects are machines.


I did not ask you if machine was the best term. I humbly disagree with
you, if what you are saying is that machine is a bad term to help
describe or teach the object part of OOP to those trying to
understand it.



Feel free to disagree.  You're the one not using the commonly recognized 
terminology, not me.



Terminology junkies are welcome to their terms. Some on this list have
graciously ceded to _your_ preferred terms, in an endeavour to attempt
to maintain actual communication. I think that is a wise thing.

Good luck,
Zenaan




I just go by what recognized experts say - not some yoyo who puts up a 
web page.


If you want to use the correct terminology, you should be reading 
recognized experts in the field.


Jerry


--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Archive: http://lists.debian.org/526b2589.3090...@attglobal.net

Re: What's the easiest and/or simplest part of Linux Kernel?

On 10/26/13, Jerry Stuckle jstuc...@attglobal.net wrote:
On 10/25/2013 9:59 PM, Zenaan Harkness wrote:
On 10/26/13, Jerry Stuckle jstuc...@attglobal.net wrote:
On 10/25/2013 8:59 PM, Zenaan Harkness wrote:

Machine is a bad term because it is not Machine Oriented
Programming. It is Object Oriented Programming - because it emulates
real world objects - not machines.

Here I should have said thank you for providing your reason.

And a machine is not a real-world object?

All machines are objects. But not all objects are machines.

I agree.

Are you saying that I should refrain from using the term machine as
an analogy to help explain OOP, because some recognized experts did
not use that term?

Only if you don't want to look like an idiot. People who make up their
own terms for something most of the rest of the world accept look that way.

Oh.

Dear me.

Guess I better just stick to Object then. Don't want to look like an
idiot. I shall submit myself to most of the rest of the world's
acceptance.

I guess I should appreciate that you are trying to stop some of us
from looking like idiots. There is possibly some worth in that
intention. I however be not tooo worried about others' think ... can
lead to certain - unproductive? - outcomes.

Besides, my point is not to attack object as being a useful term nor
to attack object as being the preferred/accepted/sanctioned term.
Can you see my point?

Nope.

/shrug Someone's loss?

My point was simply that machine is (in my opinion, and evidently in
the opinions of others), useful to help describe or explain OOP.

As I said before - not all objects are machines.

True. Very true. I agree. I really do agree.

Feel free to disagree. You're the one not using the commonly recognized
terminology, not me.

I wrote an article back in the day for my university newsletter, using
a tree as an analogy to explain Objects - I did have much to learn,
but in hindsight, machine, or engine, would likely have been a better
analogy. I think I was trying to point out that _anything_ can be
modeled as an Object.

Anyway, as long as there's a good crucifixion under way for crimes
against terminology ... popcorn anyone?

I just go by what recognized experts say - not some yoyo who puts up a
web page.

If you were to put some sincere effort in attempting to explain
something, and you used a term other than the primary sanctioned term,
I would not consider you a yoyo, nor stupid, etc, but would consider
your attempt genuine, to use additional terms to assist in the
listeners understanding of your point.

However, for an encyclopaedia I think that is a useful approach you
have. Say, I seem to remember there's a wikipedia page or two on OOP
that could really use a little of your expert love on this matter...

If you want to use the correct terminology, you should be reading
recognized experts in the field.

Each human, like it or not, is the authority regarding their own intentions.

This list is about communication, sometimes even related to Debian.

The job of experts, teachers, and those who wish to raise the quality
of discourse, ought be to discern and assist in the teasing out of the
communication intents of others on this list, preferably in a
supportive and encouraging manner.

Good luck
Zenaan

--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive:
http://lists.debian.org/CAOsGNSQoFXgdc0ECXj=b8HqOWty=w3zq64+jorcvnv+zz3b...@mail.gmail.com

Re: What's the easiest and/or simplest part of Linux Kernel?

2013-08-30 Thread Joel Rees

On Fri, Aug 30, 2013 at 10:48 AM, Jerry Stuckle jstuc...@attglobal.net wrote:
 On 8/29/2013 8:25 PM, Joel Rees wrote:

 [...]
 3. Inheritance: the ability to extend an existing class, to provide
 additional or different functionality via additional messages in the derived
 class.  Inheritance takes advantage of the similarities in the base an
 derived classes.  The base class has no knowledge of the derived class and,
 in fact, may not even know it is being used as a base class.  Additional
 classes can be derived from the original base and derived classes with no
 change to the existing code.  This cannot be done in C.

 4. Polymorphism: the ability to send messages to a derived class object when
 you believe you have an object of the base class.  This allows functions to
 operate on any class in the derived hierarchy, while only having to worry
 about the messages defined in the base class.  This also cannot be done in
 C.

 As I said - you can emulate Object Based programming in C, although it is
 messy.  You cannot create Object Oriented programs in C.

Okay, so, for you, supporting inheritance and polymorphism at run-time
rather than at compile time is not sufficiently OOP.

And I don't particularly care about that distinction.

I'm fine with ending the discussion there.

--
Joel Rees


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/caar43ipotuj7bcqvss_ektoiok8pwlotfgtc_dntsyk_evb...@mail.gmail.com

Re: What's the easiest and/or simplest part of Linux Kernel?

2013-08-30 Thread Jerry Stuckle


On 8/30/2013 1:53 AM, Zenaan Harkness wrote:


As I said - you can emulate Object Based programming in C, although it
is messy.  You cannot create Object Oriented programs in C.


Are you saying you can NOT emulate inheritance in C?

Are you saying you can NOT emulate polymorphism in C?

Again, albeit with clunkyness, syntactic ugliness,
non-compiler-enforcement but only policy enforcement of visibility
constraints etc etc?

So again, are you saying that you are not merely splitting hairs over
terminology here?

If so, can you please explain why not, in terms that a non-C
programmer can understand?

Thank you
Zenaan




No, I am not splitting hairs.  There is a difference between Object 
Based Programming, which supports encapsulation and message passing, and 
Object Oriented Programming, which also supports Inheritance and 
Polymorphism.


You can emulate OBP in C, although it's not very pretty or very nice 
(and quite prone to bugs).  But you cannot do Inheritance or 
Polymorphism in C.  The tools just aren't there.


Jerry


--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Archive: http://lists.debian.org/52209968.5050...@attglobal.net

Re: What's the easiest and/or simplest part of Linux Kernel?

2013-08-30 Thread Jerry Stuckle


On 8/30/2013 2:00 AM, Joel Rees wrote:


Okay, so, for you, supporting inheritance and polymorphism at run-time
rather than at compile time is not sufficiently OOP.

And I don't particularly care about that distinction.

I'm fine with ending the discussion there.

--
Joel Rees




You keep claiming it can be done, but have done nothing to show how it 
can be done.  So all I can assume is you cannot support your statement, 
because it can't be done.


Don't worry - I've heard similar statements over the years from others 
who don't understand OOP.  None of them have been able to support their 
statements, either.


Jerry


--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Archive: http://lists.debian.org/522099e9.2030...@attglobal.net

Re: What's the easiest and/or simplest part of Linux Kernel?

2013-08-30 Thread Jerry Stuckle


On 8/30/2013 10:44 AM, berenger.mo...@neutralite.org wrote:



Le 30.08.2013 15:11, Jerry Stuckle a écrit :

On 8/30/2013 2:00 AM, Joel Rees wrote:


Okay, so, for you, supporting inheritance and polymorphism at run-time
rather than at compile time is not sufficiently OOP.

And I don't particularly care about that distinction.

I'm fine with ending the discussion there.

--
Joel Rees




You keep claiming it can be done, but have done nothing to show how
it can be done.  So all I can assume is you cannot support your
statement, because it can't be done.

Don't worry - I've heard similar statements over the years from
others who don't understand OOP.  None of them have been able to
support their statements, either.

Jerry



Here is what you defined for inheritance and polymorphism:

3. Inheritance: the ability to extend an existing class, to provide
additional or different functionality via additional messages in the
derived class.  Inheritance takes advantage of the similarities in the
base an derived classes.  The base class has no knowledge of the derived
class and, in fact, may not even know it is being used as a base class.
Additional classes can be derived from the original base and derived
classes with no change to the existing code.  This cannot be done in C.

4. Polymorphism: the ability to send messages to a derived class object
when you believe you have an object of the base class.  This allows
functions to operate on any class in the derived hierarchy, while only
having to worry about the messages defined in the base class.  This also
cannot be done in C.


Note that we agree on those definitions.

Now, can you explain why the link I provided does not meet those
requirements?



I agree the link emulates a kind of polymorphism in the limited case it 
shows.  However, it does not show inheritance (a basic requirement for 
polymorphism), and quickly falls apart when you get into real-world code.


For instance, let's say you try to emulate inheritance in C.  What 
happens the derived class needs to call the base class member of the 
same name?  Sure, you can use the emulated vtable - but you have to know 
what offset the base class is in the vtable.  Say you have a case like this:


struct employee
  struct manager

Now you need to add contractors.  Rather than create a new class 
hierarchy, you change your existing one to:


struct person
  struct employee
 struct manager
  struct contractor

Now the entire vtable has changed - and if manager calls the function in 
vtable[0], it will call the one in person, not employee.


Or, taking the second hierarchy again: say person has member xyz, but 
employee doesn't.  When manager calls xyz, it needs to know to call the 
one in person, not employee.  But later, you go back to change employee 
to also have a member xyz.  Now you have to change manager to call 
employee's xyz instead of the one in person.


The result is a change in a base struct or the base struct hierarchy 
results in changes to all of the derived struct - even though the base 
struct public interface has not changed.


OO languages eliminate these problems by handling everything themselves. 
 In any of the above cases, all that needs to be done in C++ is 
recompile the program(s).  The compiler takes care of everything else.



For now, except saying to everyone that 1) they do not understand OOP
and 2) you teach it from 25 years, you never gave any example of things
we could do in any OOP language that we could not make in C according to
your definition of OOP (on which I agree, again) not you destroyed the
source code pointed by the link I gave.



I didn't comment on your example extensively because I thought you 
understood the limitations.  And these are just the start - I could 
continue on.



Oh, and, you also said something which implied that I said that SDL is a
language, which is something I never said. Well, to be more precise, the
functions and structures I referred to where obviously owned by
libsdl1.2-dev (to write the Debian package's name) which is a library.
So, you avoided replying to real arguments with yours, and you even used
a straw man to discredit me?



Sorry if you think I implied SDL is a language.  I meant no such thing. 
 But I don't see where SDL implements any form of OO programming.



I will refrain my envy of irony here, instead I will be direct: I have
seen people which were using a lot the argument of being older than me
to convince me that I was wrong. They never convinced reality, when what
they did failed, why my solutions were working fine. Wisdom and
knowledge are not only a matter of age and teaching. Including teachers.
This is the reason why I rarely accept an argument if it is not
correctly built: explanation + example, so that it can be countered or not.



One thing I have learned over the years.  You cannot teach those who 
will not learn.



While I am at it, let me say you that, a machine, in common

Re: What's the easiest and/or simplest part of Linux Kernel?

2013-08-30 Thread berenger . morel




Le 30.08.2013 15:11, Jerry Stuckle a écrit :

On 8/30/2013 2:00 AM, Joel Rees wrote:


Okay, so, for you, supporting inheritance and polymorphism at 
run-time

rather than at compile time is not sufficiently OOP.

And I don't particularly care about that distinction.

I'm fine with ending the discussion there.

--
Joel Rees




You keep claiming it can be done, but have done nothing to show how
it can be done.  So all I can assume is you cannot support your
statement, because it can't be done.

Don't worry - I've heard similar statements over the years from
others who don't understand OOP.  None of them have been able to
support their statements, either.

Jerry



Here is what you defined for inheritance and polymorphism:

3. Inheritance: the ability to extend an existing class, to provide
additional or different functionality via additional messages in the
derived class.  Inheritance takes advantage of the similarities in the
base an derived classes.  The base class has no knowledge of the 
derived

class and, in fact, may not even know it is being used as a base class.
Additional classes can be derived from the original base and derived
classes with no change to the existing code.  This cannot be done in C.

4. Polymorphism: the ability to send messages to a derived class object
when you believe you have an object of the base class.  This allows
functions to operate on any class in the derived hierarchy, while only
having to worry about the messages defined in the base class.  This 
also

cannot be done in C.


Note that we agree on those definitions.

Now, can you explain why the link I provided does not meet those 
requirements?


For now, except saying to everyone that 1) they do not understand OOP 
and 2) you teach it from 25 years, you never gave any example of things 
we could do in any OOP language that we could not make in C according to 
your definition of OOP (on which I agree, again) not you destroyed the 
source code pointed by the link I gave.


Oh, and, you also said something which implied that I said that SDL is 
a language, which is something I never said. Well, to be more precise, 
the functions and structures I referred to where obviously owned by 
libsdl1.2-dev (to write the Debian package's name) which is a library.
So, you avoided replying to real arguments with yours, and you even 
used a straw man to discredit me?


I will refrain my envy of irony here, instead I will be direct: I have 
seen people which were using a lot the argument of being older than me 
to convince me that I was wrong. They never convinced reality, when what 
they did failed, why my solutions were working fine. Wisdom and 
knowledge are not only a matter of age and teaching. Including teachers.
This is the reason why I rarely accept an argument if it is not 
correctly built: explanation + example, so that it can be countered or 
not.


While I am at it, let me say you that, a machine, in common language 
(I'm not very good with mathematics), have internal states that you do 
not need to know to use it's function. I have no idea about all the 
states of my car when I am driving. For example, I do not know, or need 
to know, the states of the spark plugs.



--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/a505a5a67ef41d7132e262f4cf0e2...@neutralite.org

Re: What's the easiest and/or simplest part of Linux Kernel?

2013-08-29 Thread Ralf Mardorf

On Thu, 2013-08-29 at 07:06 +0200, Ralf Mardorf wrote:
 On Thu, 29 Aug 2013 02:02:11 +0200, berenger.mo...@neutralite.org wrote:
 
 
 
  Le 29.08.2013 01:13, Cousin Stanley a écrit :
  Ralf Mardorf wrote:
 
  
  Assembler always is optimized code.
 
Not always  :-)
 
One can also write stinky code in assembler.
 
Like any programming language,
some programmers are better at it
than others 
 
 
  --
  Stanley C. Kitching
  Human Being
  Phoenix, Arizona
 
  This is something I understood very recently, and the reason for which I  
  stopped to aggressively disdain Java and C#. The problem is not the  
  language, it's the language's user. Always. If eclipse is slow, huge and  
  buggy (in my experience, 2 years ago, it was.), it's not because it's  
  written in Java, there are very good programs written in Java, and in  
  Debian, you can find games with graphics of 90s, written in C or C++,  
  which are slow as hell on a modern computer.
 
  And nowadays compilers can make code better optimized than you could,  
  too. The question is, what is real optimization? Speed? Size? How many  
  of one? Or of both?
 
  Before that, I learn that it was not windows itself which was buggy, but  
  the softwares I was using. I discovered that last one when I discovered  
  linux, and had some crashes ;)
  Sounds like it's easy to say it's the language/OS 's fault, and never  
  the programmer's one. Probably easy, but so often wrong.
 
  I think time made me wiser on those points. (funny to notice that when I  
  was a windows users, I was used to write window$ and M$ and other  
  insulting transformations which are far worse. Stopped that by  
  discovering another OS.)
 
 I guess a high level language like C, Pascal, Basic etc. is harder to  
 learn than Assembler, while there for sure are reasons that you nowadays  
 program in C. Optimal optimization are speed, size, functionality and  
 stability. Sure, first steps can be easier done with high level languages,  
 but the result usually will be spaghetti code.
 
 Clear formatted, easy to understand, but insane:
 
 Output_to_screen_command Hel
 jump_to label_x
 label_y
Output_to_screen_command world
jump_to_label_z
 label_x
Output_to_screen_command lo 
jump_to label_y
 label_z
finish_program_command
 
 So you learned how to make your computer say Hello world and how to jump  
 in R.A.L.F., but you did not learn when it's useful and when it's insane  
 to use the jump command in R.A.L.F. ;).

PS:

A coder can be aware that for a multiplication e.g. only integer
multiples of 2 without overflow could happen, so the code for the
multiplication only will be rolling bits and not including a rout, that
is able to do any kind of multiplication. If a coder would use a high
level language and use x * y the code isn't optimized anymore, but
instead it's unneeded bloated.



-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/1377760121.684.7.camel@archlinux

Re: What's the easiest and/or simplest part of Linux Kernel?

2013-08-29 Thread Ralf Mardorf

On Thu, 2013-08-29 at 09:08 +0200, Ralf Mardorf wrote:
 On Thu, 2013-08-29 at 07:06 +0200, Ralf Mardorf wrote:
  On Thu, 29 Aug 2013 02:02:11 +0200, berenger.mo...@neutralite.org wrote:
  
  
  
   Le 29.08.2013 01:13, Cousin Stanley a écrit :
   Ralf Mardorf wrote:
  
   
   Assembler always is optimized code.
  
 Not always  :-)
  
 One can also write stinky code in assembler.
  
 Like any programming language,
 some programmers are better at it
 than others 
  
  
   --
   Stanley C. Kitching
   Human Being
   Phoenix, Arizona
  
   This is something I understood very recently, and the reason for which I  
   stopped to aggressively disdain Java and C#. The problem is not the  
   language, it's the language's user. Always. If eclipse is slow, huge and  
   buggy (in my experience, 2 years ago, it was.), it's not because it's  
   written in Java, there are very good programs written in Java, and in  
   Debian, you can find games with graphics of 90s, written in C or C++,  
   which are slow as hell on a modern computer.
  
   And nowadays compilers can make code better optimized than you could,  
   too. The question is, what is real optimization? Speed? Size? How many  
   of one? Or of both?
  
   Before that, I learn that it was not windows itself which was buggy, but  
   the softwares I was using. I discovered that last one when I discovered  
   linux, and had some crashes ;)
   Sounds like it's easy to say it's the language/OS 's fault, and never  
   the programmer's one. Probably easy, but so often wrong.
  
   I think time made me wiser on those points. (funny to notice that when I  
   was a windows users, I was used to write window$ and M$ and other  
   insulting transformations which are far worse. Stopped that by  
   discovering another OS.)
  
  I guess a high level language like C, Pascal, Basic etc. is harder to  
  learn than Assembler, while there for sure are reasons that you nowadays  
  program in C. Optimal optimization are speed, size, functionality and  
  stability. Sure, first steps can be easier done with high level languages,  
  but the result usually will be spaghetti code.
  
  Clear formatted, easy to understand, but insane:
  
  Output_to_screen_command Hel
  jump_to label_x
  label_y
 Output_to_screen_command world
 jump_to_label_z
  label_x
 Output_to_screen_command lo 
 jump_to label_y
  label_z
 finish_program_command
  
  So you learned how to make your computer say Hello world and how to jump  
  in R.A.L.F., but you did not learn when it's useful and when it's insane  
  to use the jump command in R.A.L.F. ;).
 
 PS:
 
 A coder can be aware that for a multiplication e.g. only integer
 multiples of 2 without overflow could happen, so the code for the
 multiplication only will be rolling bits and not including a rout, that
 is able to do any kind of multiplication. If a coder would use a high
 level language and use x * y the code isn't optimized anymore, but
 instead it's unneeded bloated.

PPS: Even for x * 2, x * (2 * 2) etc., while x is defined as integer,
since a compile couldn't be aware, if there is or isn't the need to take
care for overflows.


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/1377763440.684.26.camel@archlinux

Re: What's the easiest and/or simplest part of Linux Kernel?

2013-08-29 Thread Jerry Stuckle


On 8/29/2013 12:45 AM, Joel Rees wrote:

(I really don't have time to do this.)

On Thu, Aug 29, 2013 at 12:17 PM,

[Somebody replied to somebody, arguing that C can't do objects.]


The syntax does become obtuse, unfun, cluttered, etc., but it can be done.



I didn't say C can't do objects.  I said it can't do Object Oriented 
Programming.  Two entirely different things.



(To get the neurons connecting, think about early objective-C, when
the object stuff was done with a special purpose pre-processor.

Shoot. Don't forget that C++ itself was once a pre-processor for C.)



That's like saying C is a preprocessor for assembler.  Sure, the 
original C++ tools were preprocessors.  However, they were preprocessors 
which provided the tools necessary to do OOP.



Admittedly, the object syntax becomes a separate syntax and language
from the C part when you do OOP in unadorned C. You have to leave the
basic operators (+-*/%, etc.) out of the object-oriented language and
syntax. (Which is part of the reason it becomes unfun.)



Please show how you can do inheritance and polymorphism in C.  And why 
do you need to leave the basic operators out?  They are inherent to both 
languages.



You have to use #include skillfully, and you have to explicitly put
function pointers in structures. It kind of turns things upside down,
a bit, and a little inside-out. It'll make even seasoned C programmers
seasick. And the syntax is not as flexible as C++.



Again, please show how to do inheritance and polymorphism in C.


Which is all why C++ was written as a separate language.

But it can be done.



Once again, please show how to do inheritance and polymorphism in C.


By the way, mathematically speaking, objects are machines.



Maybe mathematically speaking, but we're talking programming here.  In 
programming, variables have state.  Functions have behavior.  Objects 
have both state and behavior.



None of which has anything to do with the simplest part of the Linux
kernel for a newbie to try to drown in.

--
Joel Rees






--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Archive: http://lists.debian.org/521f3550.1000...@attglobal.net

Re: What's the easiest and/or simplest part of Linux Kernel?

2013-08-29 Thread Joel Rees

On Thu, Aug 29, 2013 at 8:49 PM, Jerry Stuckle jstuc...@attglobal.net wrote:
 On 8/29/2013 12:45 AM, Joel Rees wrote:

 (I really don't have time to do this.)

 On Thu, Aug 29, 2013 at 12:17 PM,

 [Somebody replied to somebody, arguing that C can't do objects.]


 The syntax does become obtuse, unfun, cluttered, etc., but it can be done.


 I didn't say C can't do objects.  I said it can't do Object Oriented
 Programming.  Two entirely different things.

End of argument, if you could just see what you just said.

 (To get the neurons connecting, think about early objective-C, when
 the object stuff was done with a special purpose pre-processor.

 Shoot. Don't forget that C++ itself was once a pre-processor for C.)


 That's like saying C is a preprocessor for assembler.  Sure, the original
 C++ tools were preprocessors.  However, they were preprocessors which
 provided the tools necessary to do OOP.

The originals were pretty primitive. The current state is somewhat
improved, but incomplete.

 Admittedly, the object syntax becomes a separate syntax and language
 from the C part when you do OOP in unadorned C. You have to leave the
 basic operators (+-*/%, etc.) out of the object-oriented language and
 syntax. (Which is part of the reason it becomes unfun.)


 Please show how you can do inheritance and polymorphism in C.

You do understand that in C can be read two or three ways.

But do you understand that not everyone agrees that the assertion of
within the unadorned syntax of C is the important one?

Not going as far as writing the compilers (or the
compilers-by-pre-processing) in C, there is still a way of using
unadorned C to induce a metalanguage of objects on C.

 And why do
 you need to leave the basic operators out?  They are inherent to both
 languages.

I'm not talking about using an unadorned C compiler to compile either
C++ or objective-C.

I'm talking about programming OOP in C. The OOP operators might look like this:

obj1-plus( obj2-neg() );

plus() and neg() would be the operators, and the OOP language is
projected onto C function call syntax.

If you have complaints about calling methods operators, do you
understand Lisp? (or FORTH, ...)

 You have to use #include skillfully, and you have to explicitly put
 function pointers in structures. It kind of turns things upside down,
 a bit, and a little inside-out. It'll make even seasoned C programmers
 seasick. And the syntax is not as flexible as C++.

 Again, please show how to do inheritance and polymorphism in C.

If you understand what I mean by using function pointers in
structures, you should be able to see that inheritance and
polymorphism are simply matters of providing certain functionality in
support libraries, and adding appropriate pointers in the structures
that define the objects.

 Which is all why C++ was written as a separate language.

 But it can be done.

 Once again, please show how to do inheritance and polymorphism in C.

You're going to have to intuit the libraries that I am implicitly
inferring have been written and are being linked in, appropriate
headers being included, etc., and not even trying to provide any
syntactic sugar:


struct my_object_s
{
   pfii_f constructor, destructor;
   pfiv_o inherited_context, local_context; /* local_context is for
polymorphism. */
   pfam_f method1;
   pfam_f method2;
   ...
} my_object_o;
-

I assume you will complain that I'm just talking about providing the
functionality without the syntax of objects, and you'd be sort of
right. And you should complain that the convention of ending method
type declarations with _f and object type declarations with _o is
unenforceable (and ask whether the convention is anywhere explicitly
documented).

 By the way, mathematically speaking, objects are machines.

 Maybe mathematically speaking, but we're talking programming here.

Is programming somehow independent of mathematics?

  In
 programming, variables have state.  Functions have behavior.  Objects have
 both state and behavior.

And that is different from mathematical automata how?

OOP is a paradigm, a set of rules for projecting certain aspects of
automata onto existing programming tools. The paradigm has a lot of
implicit rules that are not well documented. If you understand the OOP
class of paradigms, you may use the tools effectively. Or not
effectively. Or not at all.

I think I understand the paradigms, but I find myself feeling like I'm
in a straitjacket when trying to use them. Most of the programs I
write do not project well onto the OOP paradigm. I suppose that may
have something to do with being spoiled by an early introduction to
assembler and FORTH, and with learning C at the same time as I was
learning m4 and lisp.

 None of which has anything to do with the simplest part of the Linux
 kernel for a C newbie to try to drown in.

--
Joel Rees


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject

Re: What's the easiest and/or simplest part of Linux Kernel?

2013-08-29 Thread Jerry Stuckle


On 8/29/2013 8:25 PM, Joel Rees wrote:

On Thu, Aug 29, 2013 at 8:49 PM, Jerry Stuckle jstuc...@attglobal.net wrote:

On 8/29/2013 12:45 AM, Joel Rees wrote:


(I really don't have time to do this.)

On Thu, Aug 29, 2013 at 12:17 PM,


[Somebody replied to somebody, arguing that C can't do objects.]



The syntax does become obtuse, unfun, cluttered, etc., but it can be done.



I didn't say C can't do objects.  I said it can't do Object Oriented
Programming.  Two entirely different things.


End of argument, if you could just see what you just said.



Yep, because you obviously don't understand the difference between 
objects and object oriented programming.



(To get the neurons connecting, think about early objective-C, when
the object stuff was done with a special purpose pre-processor.

Shoot. Don't forget that C++ itself was once a pre-processor for C.)



That's like saying C is a preprocessor for assembler.  Sure, the original
C++ tools were preprocessors.  However, they were preprocessors which
provided the tools necessary to do OOP.


The originals were pretty primitive. The current state is somewhat
improved, but incomplete.


Admittedly, the object syntax becomes a separate syntax and language
from the C part when you do OOP in unadorned C. You have to leave the
basic operators (+-*/%, etc.) out of the object-oriented language and
syntax. (Which is part of the reason it becomes unfun.)



Please show how you can do inheritance and polymorphism in C.


You do understand that in C can be read two or three ways.

But do you understand that not everyone agrees that the assertion of
within the unadorned syntax of C is the important one?

Not going as far as writing the compilers (or the
compilers-by-pre-processing) in C, there is still a way of using
unadorned C to induce a metalanguage of objects on C.



Again, please show how you can do inheritance and polymorphism in C.


And why do
you need to leave the basic operators out?  They are inherent to both
languages.


I'm not talking about using an unadorned C compiler to compile either
C++ or objective-C.

I'm talking about programming OOP in C. The OOP operators might look like this:

obj1-plus( obj2-neg() );

plus() and neg() would be the operators, and the OOP language is
projected onto C function call syntax.

If you have complaints about calling methods operators, do you
understand Lisp? (or FORTH, ...)



Then show how to do inheritance and polymorphism in C.  And yes, I did 
FORTH in the early 80's and Lisp a bit later.  Haven't used either for 
years, though.



You have to use #include skillfully, and you have to explicitly put
function pointers in structures. It kind of turns things upside down,
a bit, and a little inside-out. It'll make even seasoned C programmers
seasick. And the syntax is not as flexible as C++.


Again, please show how to do inheritance and polymorphism in C.


If you understand what I mean by using function pointers in
structures, you should be able to see that inheritance and
polymorphism are simply matters of providing certain functionality in
support libraries, and adding appropriate pointers in the structures
that define the objects.



Then you should easily be able to show how to do inheritance and 
polymorphism in C.



Which is all why C++ was written as a separate language.

But it can be done.


Once again, please show how to do inheritance and polymorphism in C.


You're going to have to intuit the libraries that I am implicitly
inferring have been written and are being linked in, appropriate
headers being included, etc., and not even trying to provide any
syntactic sugar:


struct my_object_s
{
pfii_f constructor, destructor;
pfiv_o inherited_context, local_context; /* local_context is for
polymorphism. */
pfam_f method1;
pfam_f method2;
...
} my_object_o;
-

I assume you will complain that I'm just talking about providing the
functionality without the syntax of objects, and you'd be sort of
right. And you should complain that the convention of ending method
type declarations with _f and object type declarations with _o is
unenforceable (and ask whether the convention is anywhere explicitly
documented).



That is neither inheritance nor is it polymorphism.  It is simply a set 
of pointers to functions within a structure.



By the way, mathematically speaking, objects are machines.


Maybe mathematically speaking, but we're talking programming here.


Is programming somehow independent of mathematics?


  In
programming, variables have state.  Functions have behavior.  Objects have
both state and behavior.


And that is different from mathematical automata how?



In programming, objects are not machines.  About the only machine 
concept I can think of is the old state machine from the 70's.



OOP is a paradigm, a set of rules for projecting certain aspects of
automata onto existing programming tools. The paradigm has a lot of

Re: What's the easiest and/or simplest part of Linux Kernel?

2013-08-29 Thread Zenaan Harkness

On 8/30/13, Jerry Stuckle jstuc...@attglobal.net wrote:
 On 8/29/2013 8:25 PM, Joel Rees wrote:
 On Thu, Aug 29, 2013 at 8:49 PM, Jerry Stuckle jstuc...@attglobal.net
 wrote:
 On 8/29/2013 12:45 AM, Joel Rees wrote:
 (I really don't have time to do this.)

 On Thu, Aug 29, 2013 at 12:17 PM,
 [Somebody replied to somebody, arguing that C can't do objects.]

 The syntax does become obtuse, unfun, cluttered, etc., but it can be
 done.

 I didn't say C can't do objects.  I said it can't do Object Oriented
 Programming.  Two entirely different things.

 End of argument, if you could just see what you just said.

 Yep, because you obviously don't understand the difference between
 objects and object oriented programming.

 Admittedly, the object syntax becomes a separate syntax and language
 from the C part when you do OOP in unadorned C. You have to leave the
 basic operators (+-*/%, etc.) out of the object-oriented language and
 syntax. (Which is part of the reason it becomes unfun.)


 Please show how you can do inheritance and polymorphism in C.

 You do understand that in C can be read two or three ways.

 But do you understand that not everyone agrees that the assertion of
 within the unadorned syntax of C is the important one?

 Not going as far as writing the compilers (or the
 compilers-by-pre-processing) in C, there is still a way of using
 unadorned C to induce a metalanguage of objects on C.


 Again, please show how you can do inheritance and polymorphism in C.

 And why do
 you need to leave the basic operators out?  They are inherent to both
 languages.

 I'm not talking about using an unadorned C compiler to compile either
 C++ or objective-C.

 I'm talking about programming OOP in C. The OOP operators might look like
 this:

 obj1-plus( obj2-neg() );

 plus() and neg() would be the operators, and the OOP language is
 projected onto C function call syntax.

 If you have complaints about calling methods operators, do you
 understand Lisp? (or FORTH, ...)


 Then show how to do inheritance and polymorphism in C.  And yes, I did
 FORTH in the early 80's and Lisp a bit later.  Haven't used either for
 years, though.

 You have to use #include skillfully, and you have to explicitly put
 function pointers in structures. It kind of turns things upside down,
 a bit, and a little inside-out. It'll make even seasoned C programmers
 seasick. And the syntax is not as flexible as C++.

 Again, please show how to do inheritance and polymorphism in C.

 If you understand what I mean by using function pointers in
 structures, you should be able to see that inheritance and
 polymorphism are simply matters of providing certain functionality in
 support libraries, and adding appropriate pointers in the structures
 that define the objects.


 Then you should easily be able to show how to do inheritance and
 polymorphism in C.

 Which is all why C++ was written as a separate language.

 But it can be done.

 Once again, please show how to do inheritance and polymorphism in C.

 You're going to have to intuit the libraries that I am implicitly
 inferring have been written and are being linked in, appropriate
 headers being included, etc., and not even trying to provide any
 syntactic sugar:

 
 struct my_object_s
 {
 pfii_f constructor, destructor;
 pfiv_o inherited_context, local_context; /* local_context is for
 polymorphism. */
 pfam_f method1;
 pfam_f method2;
 ...
 } my_object_o;
 -

 I assume you will complain that I'm just talking about providing the
 functionality without the syntax of objects, and you'd be sort of
 right. And you should complain that the convention of ending method
 type declarations with _f and object type declarations with _o is
 unenforceable (and ask whether the convention is anywhere explicitly
 documented).

 That is neither inheritance nor is it polymorphism.  It is simply a set
 of pointers to functions within a structure.

I am not a C programmer (just Java), but do you say that you are _not_
splitting hairs here?

A quick google search gives:
http://www.codeproject.com/Articles/10900/Polymorphism-in-C
http://www.codeproject.com/Articles/108830/Inheritance-and-Polymorphism-in-C

Yes clunky, yes not fun, yes not supported with inbuilt syntax,
but wasn't that Joel's point all along?

 By the way, mathematically speaking, objects are machines.

 Maybe mathematically speaking, but we're talking programming here.

 Is programming somehow independent of mathematics?

   In
 programming, variables have state.  Functions have behavior.  Objects
 have
 both state and behavior.

 And that is different from mathematical automata how?


 In programming, objects are not machines.  About the only machine
 concept I can think of is the old state machine from the 70's.

 OOP is a paradigm, a set of rules for projecting certain aspects of
 automata onto existing programming tools. The paradigm has a lot of
 implicit rules that are

Re: What's the easiest and/or simplest part of Linux Kernel?

2013-08-28 Thread berenger . morel


Le 28.08.2013 03:36, guojzzz a écrit :

The reason why I choose some *formal* projects is that I think codes
are clear and there are less bugs.
I will see on Github and some other projects.


The assumption that clean code is bug-free is wrong. Try to read any 
source code of any program you think bug-free. It may be clean, or it 
may be a damned unreadable mess, especially if the project is old.


And if the project is recent, it will not have a long history of bugs 
and fixes, and so may have tons of bugs, known or not by the users or 
authors, but, since the project is young, it will have less zombi code, 
coding style will be more unified, and modern programming techniques are 
more likely to be used, like OOP*.


Another problem with code probably written by gurus, or which run in 
environments were high speed and stability is required, is that the code 
will be highly optimized, maybe with non-standard features, probably 
with lot of compilation options, etc etc. All of those things makes code 
more efficient, but harder to understand. Like macros, that most C 
programmers tend to avoid. And because I have learn C as my first 
language, I can tell you, that they are true to avoid them, they makes 
things hard to read and maintain. But they makes things fast, so I would 
not be surprised if there were a lot of them. And not childish ones 
like the one I made.


So, either start your project, or contribute to small projects first, 
if you want to learn. Something that you can understand in less than 2 
weeks, and start to hack.


* which is doable in C. People saying that C can not do OOP are 
incompetent or lie. I do not really like C programming, but paradigm 
have nothing related to syntax, only with writer's minds.
Some people may not like OOP, and they will be true, it is not always 
good to use it.



--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/eef863b1434a4ded43faecc5ae89e...@neutralite.org

Re: What's the easiest and/or simplest part of Linux Kernel?


On 8/28/2013 2:44 PM, berenger.mo...@neutralite.org wrote:
snip


Another problem with code probably written by gurus, or which run in
environments were high speed and stability is required, is that the code
will be highly optimized, maybe with non-standard features, probably
with lot of compilation options, etc etc. All of those things makes code
more efficient, but harder to understand. Like macros, that most C
programmers tend to avoid. And because I have learn C as my first
language, I can tell you, that they are true to avoid them, they makes
things hard to read and maintain. But they makes things fast, so I would
not be surprised if there were a lot of them. And not childish ones
like the one I made.



While I agree with much of what you said, I definitely disagree with 
your comments on macros.  C was probably the 10th or so language I 
learned, close to 30 years ago.  I found macros, when PROPERLY used, can 
be quite helpful in making code clearer and more understandable.  The 
trick is to know when to use them and when not, to document them well, 
and most important, pick good names for the macros.  Also, the 
convention of using all caps for macro names is good; it tells the 
reader this is a macro being used, and not a function call.


snip


* which is doable in C. People saying that C can not do OOP are
incompetent or lie. I do not really like C programming, but paradigm
have nothing related to syntax, only with writer's minds.
Some people may not like OOP, and they will be true, it is not always
good to use it.




Definitely NOT doable in C - you just don't have the tools.  While you 
can do some parts of object based programming like message passing (i.e. 
calling functions to operate on structure members instead of accessing 
them yourself), and can even use tricks to hide structure members 
(i.e. the known interface is just a dummy char[appropriate_size] while 
the real structure is hidden), this can be sensitive to compilers and in 
some cases even compiler options.


You can't even define constructors and destructors for structures in C, 
and have to take extra steps to ensure structures are constructed and 
destroyed properly.


And there is no way you can do inheritance or polymorphism in C.

But I also agree OOP is not always the best choice.  Even though I've 
been doing C++ for around 25 years, I still do a lot of stuff in C where 
appropriate.


Jerry


--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Archive: http://lists.debian.org/521e6259.2050...@attglobal.net

Re: What's the easiest and/or simplest part of Linux Kernel?

2013-08-28 Thread Ralf Mardorf

On Wed, 28 Aug 2013 22:49:29 +0200, Jerry Stuckle jstuc...@attglobal.net  
wrote:
While I agree with much of what you said, I definitely disagree with  
your comments on macros.  C was probably the 10th or so language I  
learned, close to 30 years ago.  I found macros, when PROPERLY used, can  
be quite helpful in making code clearer and more understandable.  The  
trick is to know when to use them and when not, to document them well,  
and most important, pick good names for the macros.  Also, the  
convention of using all caps for macro names is good; it tells the  
reader this is a macro being used, and not a function call.


+1

I programmed 65xx Assembler with and without macro editor and I suspect  
that somebody who know what (s)he does when programming in C, can use  
macros to optimize C code, while for Assembler, it simply is less to type,  
less to think about, when using macros, Assembler always is optimized code.



--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Archive: http://lists.debian.org/op.w2jo28qiqhadp0@suse11-2

Re: What's the easiest and/or simplest part of Linux Kernel?

2013-08-28 Thread Cousin Stanley

Ralf Mardorf wrote:

 
 Assembler always is optimized code.

  Not always  :-)

  One can also write stinky code in assembler. 

  Like any programming language,
  some programmers are better at it 
  than others 


-- 
Stanley C. Kitching
Human Being
Phoenix, Arizona


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/kvm07a$frr$1...@dont-email.me

Re: What's the easiest and/or simplest part of Linux Kernel?

2013-08-28 Thread berenger . morel




Le 28.08.2013 22:49, Jerry Stuckle a écrit :

* which is doable in C. People saying that C can not do OOP are
incompetent or lie. I do not really like C programming, but paradigm
have nothing related to syntax, only with writer's minds.
Some people may not like OOP, and they will be true, it is not 
always

good to use it.




Definitely NOT doable in C - you just don't have the tools.  While
you can do some parts of object based programming like message 
passing

(i.e. calling functions to operate on structure members instead of
accessing them yourself), and can even use tricks to hide structure
members (i.e. the known interface is just a dummy
char[appropriate_size] while the real structure is hidden), this can
be sensitive to compilers and in some cases even compiler options.


I do not consider that the public/protected/private keywords are the 
most important things in OOP.



You can't even define constructors and destructors for structures in
C, and have to take extra steps to ensure structures are constructed
and destroyed properly.


What are constructors and destructors? They are only functions which 
creates of free an instance of a structure. It's not automated in C, I 
agree, but it's doable. (And I have often seen C++ classes with Init and 
Clear methods, which just stole CTors/DTors roles. To be honest, I made 
a lot of that crap myself, in the past. I was a C programmer then, not 
accustomed to think in C++. Just different, not better.)
They are not even mandatory in OOP: they are only used for RAII, which 
is not the way of modern languages like Java or C# (they does not have 
destructors, which is one the the reasons for which I do not like them. 
I love RAII, because I love efficient programs. Even if RAII have to be 
hand-crafted.)


Take the SDL, for example, with SDL_Surface structure.
You never use malloc and free to control the lifetime of those objects, 
and they have a bunch of functions made to manipulate them, which only 
does that. An object is exactly that: a structure with functions to 
manipulate it.
In C, the only problem is that you have to explicitly give the instance 
of the object you want to manipulate, as a parameter. In Java, you can 
not overload operators, and that does not avoid doing OOP stuff, right?


You can name that problem a lack of type safety if you want, but it's 
not new that C does not make as many controls as C++ (which is, 
technically, incorrect, since there is, for example, reinterpret_cast... 
which should never be used except if you perfectly know what you are 
doing, because it's the equivalent of C-style cast.).



And there is no way you can do inheritance or polymorphism in C.


Here, you are wrong.
I won't explain myself, that link, with source code, will do it better 
than me: http://stackoverflow.com/questions/8194250/polymorphism-in-c
I remember that I understood how C++ works only when I found a document 
where the author was, by it's own words, reinventing the wheel. He 
explained how to do each C++ feature in C. Sadly, I can not find it 
anew, I should have saved it at that time ( in 10 years or internet, 
documents vanishes, I guess).


What I meant is, OOP is not just a built-in feature of a language. It's 
a paradigm, a way of thinking.
You can use JAVA which is a full OOP language (unlike C++, which 
explicitly allows to not use OOP technics) and not doing OOP, because 
you are doing things the wrong way (for OOP, I mean).
When Linus said that Linux must stay in C to avoid C++ devs to 
contribute, I agree with him (and I really love C++, for sure). Because 
I noticed something: bad C programmers often go to C++, thinking it will 
be easier to do good job. They do dirty code, often with lot of 
copy/pasted code, (recently I have seen C++ code with memset/memcpy to 
copy classes's instances, sounds like a nice example, but looking better 
in the code it might not be one of the worse I have seen.). And they 
call that C++ code, because they use the class keyword, and sometimes 
few instances of std::vector and std::string.
Note that I do not pretend to be a good C++ programmer, simply an 
average one. As in programming in general, in fact. But I can really say 
when I see dirty code (copy/paste of code is a really good measurement 
for that. By example.)
Lot of people forgot that if, in C, you can shot in your foot easily, 
C++ is worse: in C++, you can then reuse the bullet for your other foot.


Let me quote wikipedia as a last argument (yes, authority argument is 
bad, I know ;) ):


An object oriented program may be viewed as a collection of interacting 
objects, as opposed to the conventional model, in which a program is 
seen as a list of tasks (subroutines) to perform. In OOP, each object is 
capable of receiving messages, processing data, and sending messages to 
other objects. **Each object can be viewed as an independent machine 
with a distinct role or responsibility.** Actions (or methods) on 
these objects

Re: What's the easiest and/or simplest part of Linux Kernel?

2013-08-28 Thread berenger . morel




Le 29.08.2013 01:13, Cousin Stanley a écrit :

Ralf Mardorf wrote:



Assembler always is optimized code.


  Not always  :-)

  One can also write stinky code in assembler.

  Like any programming language,
  some programmers are better at it
  than others 


--
Stanley C. Kitching
Human Being
Phoenix, Arizona


This is something I understood very recently, and the reason for which 
I stopped to aggressively disdain Java and C#. The problem is not the 
language, it's the language's user. Always. If eclipse is slow, huge and 
buggy (in my experience, 2 years ago, it was.), it's not because it's 
written in Java, there are very good programs written in Java, and in 
Debian, you can find games with graphics of 90s, written in C or C++, 
which are slow as hell on a modern computer.


And nowadays compilers can make code better optimized than you could, 
too. The question is, what is real optimization? Speed? Size? How many 
of one? Or of both?


Before that, I learn that it was not windows itself which was buggy, 
but the softwares I was using. I discovered that last one when I 
discovered linux, and had some crashes ;)
Sounds like it's easy to say it's the language/OS 's fault, and never 
the programmer's one. Probably easy, but so often wrong.


I think time made me wiser on those points. (funny to notice that when 
I was a windows users, I was used to write window$ and M$ and other 
insulting transformations which are far worse. Stopped that by 
discovering another OS.)



--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/624e8478559f1a512366a8abcb414...@neutralite.org

Re: What's the easiest and/or simplest part of Linux Kernel?


On 8/28/2013 5:10 PM, Ralf Martyrdom wrote:

On Wed, 28 Aug 2013 22:49:29 +0200, Jerry Stuckle
jstuc...@attglobal.net wrote:

While I agree with much of what you said, I definitely disagree with
your comments on macros.  C was probably the 10th or so language I
learned, close to 30 years ago.  I found macros, when PROPERLY used,
can be quite helpful in making code clearer and more understandable.
The trick is to know when to use them and when not, to document them
well, and most important, pick good names for the macros.  Also, the
convention of using all caps for macro names is good; it tells the
reader this is a macro being used, and not a function call.


+1

I programmed 65xx Assembler with and without macro editor and I suspect
that somebody who know what (s)he does when programming in C, can use
macros to optimize C code, while for Assembler, it simply is less to
type, less to think about, when using macros, Assembler always is
optimized code.




Ah, 65xx assembler.  I forgot about that - it's been too long ago

A good language, though!  In many ways better easier
than Intel's assembler.

Jerry


--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Archive: http://lists.debian.org/521eb94c.5030...@attglobal.net

Re: What's the easiest and/or simplest part of Linux Kernel?


On 8/28/2013 7:52 PM, berenger.mo...@neutralite.org wrote:



Le 28.08.2013 22:49, Jerry Stuckle a écrit :

* which is doable in C. People saying that C can not do OOP are
incompetent or lie. I do not really like C programming, but paradigm
have nothing related to syntax, only with writer's minds.
Some people may not like OOP, and they will be true, it is not always
good to use it.




Definitely NOT doable in C - you just don't have the tools.  While
you can do some parts of object based programming like message passing
(i.e. calling functions to operate on structure members instead of
accessing them yourself), and can even use tricks to hide structure
members (i.e. the known interface is just a dummy
char[appropriate_size] while the real structure is hidden), this can
be sensitive to compilers and in some cases even compiler options.


I do not consider that the public/protected/private keywords are the
most important things in OOP.



What YOU consider keywords in OOP is immaterial.  Object Based 
Programming (OBP) is defined as having two attributes:


Encapsulation (private/public or similar, depending on the language)
Message Passing (functions in most languages).

Objected Oriented Programming (OOP) extends this to include inheritance 
and polymorphism (including protected or similar, depending on the 
language).


These are basic tenets of OOP, whether you agree or not.


You can't even define constructors and destructors for structures in
C, and have to take extra steps to ensure structures are constructed
and destroyed properly.


What are constructors and destructors? They are only functions which
creates of free an instance of a structure. It's not automated in C, I
agree, but it's doable. (And I have often seen C++ classes with Init and
Clear methods, which just stole CTors/DTors roles. To be honest, I made
a lot of that crap myself, in the past. I was a C programmer then, not
accustomed to think in C++. Just different, not better.)
They are not even mandatory in OOP: they are only used for RAII, which
is not the way of modern languages like Java or C# (they does not have
destructors, which is one the the reasons for which I do not like them.
I love RAII, because I love efficient programs. Even if RAII have to be
hand-crafted.)



Again, constructors have a specific purpose.  In OOP, they guarantee an 
object cannot be constructed invalidly, or if it is invalid, no 
operations on it can be done until it has been made valid.  A


Destructors also have a specific purpose - that being when the object is 
destroyed, any resources allocated by the object are released before the 
object is actually destroyed.



Take the SDL, for example, with SDL_Surface structure.
You never use malloc and free to control the lifetime of those objects,
and they have a bunch of functions made to manipulate them, which only
does that. An object is exactly that: a structure with functions to
manipulate it.


SDL is NOT an OO language!


In C, the only problem is that you have to explicitly give the instance
of the object you want to manipulate, as a parameter. In Java, you can
not overload operators, and that does not avoid doing OOP stuff, right?



Nope, operator overloading is not a basic tenet of OOP.  It's nice in 
C++ and other languages (and I wish it did exist in Java), but it is not 
required for OOP.



You can name that problem a lack of type safety if you want, but it's
not new that C does not make as many controls as C++ (which is,
technically, incorrect, since there is, for example, reinterpret_cast...
which should never be used except if you perfectly know what you are
doing, because it's the equivalent of C-style cast.).



This has nothing to do with type safety.


And there is no way you can do inheritance or polymorphism in C.


Here, you are wrong.
I won't explain myself, that link, with source code, will do it better
than me: http://stackoverflow.com/questions/8194250/polymorphism-in-c
I remember that I understood how C++ works only when I found a document
where the author was, by it's own words, reinventing the wheel. He
explained how to do each C++ feature in C. Sadly, I can not find it
anew, I should have saved it at that time ( in 10 years or internet,
documents vanishes, I guess).



This is NOT polymorphism.  Polymorphism is an extension of inheritance, 
 C does not allow inheritance, so therefore there is no polymorphism.



What I meant is, OOP is not just a built-in feature of a language. It's
a paradigm, a way of thinking.
You can use JAVA which is a full OOP language (unlike C++, which
explicitly allows to not use OOP technics) and not doing OOP, because
you are doing things the wrong way (for OOP, I mean).
When Linus said that Linux must stay in C to avoid C++ devs to
contribute, I agree with him (and I really love C++, for sure). Because
I noticed something: bad C programmers often go to C++, thinking it will
be easier to do good job. They do dirty code, often with lot of

Re: What's the easiest and/or simplest part of Linux Kernel?