Can a low-level programmer learn OOP?

[Chris Carlen]

Hi:

From what I've read of OOP, I don't get it. I have also found some
articles profoundly critical of OOP. I tend to relate to these articles.

However, those articles were no more objective than the descriptions of
OOP I've read in making a case. Ie., what objective
data/studies/research indicates that a particular problem can be solved
more quickly by the programmer, or that the solution is more efficient
in execution time/memory usage when implemented via OOP vs. procedural
programming?

The problem for me is that I've programmed extensively in C and .asm on
PC DOS way back in 1988. Then didn't program for nearly 10 years during
which time OOP was popularized. Starting in 1999 I got back into
programming, but the high-level-ness of PC programming and the
completely foreign language of OOP repelled me. My work was in analog
and digital electronics hardware design, so naturally I started working
with microcontrollers in .asm and C. Most of my work involves low-level
signal conditioning and real-time control algorithms, so C is about as
high-level as one can go without seriously loosing efficiency. The
close-to-the-machine-ness of C is ideal here. This is a realm that I
truly enjoy and am comfortable with.

Hence, being a hardware designer rather than a computer scientist, I am
conditioned to think like a machine. I think this is the main reason
why OOP has always repelled me.

Perhaps the only thing that may have clicked regarding OOP is that in
certain cases I might prefer a higher-level approach to tasks which
involve dynamic memory allocation. If I don't need the execution
efficiency of C, then OOP might produce working results faster by not
having to worry about the details of memory management, pointers, etc.

But I wonder if the OOP programmers spend as much time creating classes
and trying to organize everything into the OOP paradigm as the C
programmer spends just writing the code?

Ultimately I don't care what the *name* is for how I program. I just
need to produce results. So that leads back to objectivity. I have a
problem to solve, and I want to find a solution that is as quick as
possible to learn and implement.

Problem:

1. How to most easily learn to write simple PC GUI programs that will
send data to remote embedded devices via serial comms, and perhaps
incorporate some basic (x,y) type graphics display and manipulation
(simple drawing program). Data may result from user GUI input, or from
parsing a text config file. Solution need not be efficient in machine
resource utilization. Emphasis is on quickness with which programmer
can learn and implement solution.

2. Must be cross-platform: Linux + Windows. This factor can have a big
impact on whether it is necessary to learn a new language, or stick with
C. If my platform was only Linux I could just learn GTK and be done
with it. I wouldn't be here in that case.

Possible solutions:

Form 1: Use C and choose a library that will enable cross-platform GUI
development.

Pro: Don't have to learn new language.
Con: Probably will have difficulty with cross-platform implementation
of serial comms. This will probably need to be done twice. This will
waste time.

Form 2: Use Python and PySerial and TkInter or wxWidgets.

Pro: Cross-platform goal will likely be achieved fully. Have a
programmer nearby with extensive experience who can help.
Con: Must learn new language and library. Must possibly learn a
completely new way of thinking (OOP) not just a new language syntax.
This might be difficult.

Form 3: Use LabVIEW

Pro: I think that the cross-platform goal can be met.
Con: Expensive. I would prefer to use an Open Source solution. But
that isn't as important as the $$$. I have also generally found the 2D
diagrammatical programming language of "G" as repelling as OOP. I
suspect that it may take as much time to learn LabVIEW as Python. In
that case the time spent on Python might be better spent since I would
be learning something foundational as opposed to basically just learning
how to negotiate someone's proprietary environment and drivers.
Comments appreciated.
--
Good day!

________________________________________
Christopher R. Carlen
Principal Laser&Electronics Technologist
Sandia National Laboratories CA USA
cr***************@BOGUSsandia.gov
NOTE, delete texts: "RemoveThis" and
"BOGUS" from email address to reply.

[Aahz]

In article <7c********************************@4ax.com>,
Wolfgang Strobl <ne***@mystrobl.dewrote:

>
SNOBOLs powerfull patterns still shine, compared to Pythons clumsy
regular expressions.

Keep in mind that Python regular expressions are modeled on the
grep/sed/awk/Perl model so as to be familiar to any sysadmin -- but
there's a reason why Python makes it a *library* unlike Perl. So adding
SNOBOL patterns to another library would be a wonderful gift to the
Python community...
--
Aahz (aa**@pythoncraft.com) <* http://www.pythoncraft.com/

I support the RKAB

[Eddie Corns]

aa**@pythoncraft.com (Aahz) writes:

>In article <7c********************************@4ax.com>,
Wolfgang Strobl <ne***@mystrobl.dewrote:

>>
SNOBOLs powerfull patterns still shine, compared to Pythons clumsy
regular expressions.

>Keep in mind that Python regular expressions are modeled on the
grep/sed/awk/Perl model so as to be familiar to any sysadmin -- but
there's a reason why Python makes it a *library* unlike Perl. So adding
SNOBOL patterns to another library would be a wonderful gift to the
Python community...

I don't believe you can get the benefit of SNOBOL matching without direct
language support. There's only so much a library can do. However a valiant
and interesting effort:

http://www.wilmott.ca/python/patternmatching.html

Eddie

[Paul Rubin]

aa**@pythoncraft.com (Aahz) writes:

.So adding SNOBOL patterns to another library would be a wonderful
gift to the Python community...

Snobol patterns were invented at a time when nobody knew anything
about parsing. They were extremely powerful (recursive with arbitrary
amounts of backtracking) but could use exponential time and maybe even
exponential space.

These days, it makes more sense to use something like pyparsing. Or I
wonder if it would be feasible to write something like Parsec for
Python (Parsec is a parser combinator library for Haskell).

[Steve Holden]

Wolfgang Strobl wrote:

Steve Holden <st***@holdenweb.com>:

>I'm happy you are proceeding with so little trouble. Without wishing to
confuse you, however, I should point out that this aspect of Python has
very little to do with its object-orientation. There was a language
called Icon, for example, 20 years ago, that used similar semantics but
wasn't at all object-oriented.

Actually, there was a language called SNOBOL, 40 years ago, that used
similar semantics, developed by Griswold et al. Its object model was
remarkably similar to that of Python without classes. And it even had
dictionaries (called "tables") :-).

For an explaination of the concept "variable" in SNOBOL see
<http://www.cacs.louisiana.edu/~mgr/404/burks/language/snobol/catspaw/tutorial/ch1.htm#1.3>

SNOBOLs powerfull patterns still shine, compared to Pythons clumsy
regular expressions. I've used the language a lot in the past, first on
the mainframe (SPITBOL on System/360), later on the PC (Catspaws SNOBOL4
&SPITBOL). When I switched to Python, it wasn't because of the
expressiveness of the language, but of the rich library ("batteries
included") and the IMO elegant syntax, i.e. blocks by identation.

<http://en.wikipedia.org/wiki/SNOBOL>
<http://en.wikipedia.org/wiki/Ralph_E._Griswold>

Icon came later. Griswold developed Icon as a successor to SNOBOL,
constructing it around the concept of generators and co-expressions. I
didn't like it.

I liked Icon quite a lot, despite having a large background in SNOBOL
(my undergrad final-year project was porting the SPITBOL implementation
to the DECSystem-10). I wrote email parsing software in Icon long before
anyone was doing it in Python.

It took a little bit more careful planning to get Icon pattern-matching
structures right, but there was much more explicit control of
backtracking. I only wish they'd grafted more OO concepts into it, then
I might never have bothered with Python! Someone did do an OO system
layered on top of it, but IIRC it was clumsy and rebarbative.

regards
Steve
--
Steve Holden [phone] [phone]
Holden Web LLC/Ltd http://www.holdenweb.com
Skype: holdenweb http://del.icio.us/steve.holden
--------------- Asciimercial ------------------
Get on the web: Blog, lens and tag the Internet
Many services currently offer free registration
----------- Thank You for Reading -------------

[hg]

Chris Carlen wrote:

Hi:

From what I've read of OOP, I don't get it. I have also found some
articles profoundly critical of OOP. I tend to relate to these articles.

However, those articles were no more objective than the descriptions of
OOP I've read in making a case. Ie., what objective
data/studies/research indicates that a particular problem can be solved
more quickly by the programmer, or that the solution is more efficient
in execution time/memory usage when implemented via OOP vs. procedural
programming?

The problem for me is that I've programmed extensively in C and .asm on
PC DOS way back in 1988. Then didn't program for nearly 10 years during
which time OOP was popularized. Starting in 1999 I got back into
programming, but the high-level-ness of PC programming and the
completely foreign language of OOP repelled me. My work was in analog
and digital electronics hardware design, so naturally I started working
with microcontrollers in .asm and C. Most of my work involves low-level
signal conditioning and real-time control algorithms, so C is about as
high-level as one can go without seriously loosing efficiency. The
close-to-the-machine-ness of C is ideal here. This is a realm that I
truly enjoy and am comfortable with.

Hence, being a hardware designer rather than a computer scientist, I am
conditioned to think like a machine. I think this is the main reason
why OOP has always repelled me.

Perhaps the only thing that may have clicked regarding OOP is that in
certain cases I might prefer a higher-level approach to tasks which
involve dynamic memory allocation. If I don't need the execution
efficiency of C, then OOP might produce working results faster by not
having to worry about the details of memory management, pointers, etc.

But I wonder if the OOP programmers spend as much time creating classes
and trying to organize everything into the OOP paradigm as the C
programmer spends just writing the code?

Ultimately I don't care what the *name* is for how I program. I just
need to produce results. So that leads back to objectivity. I have a
problem to solve, and I want to find a solution that is as quick as
possible to learn and implement.

Problem:

1. How to most easily learn to write simple PC GUI programs that will
send data to remote embedded devices via serial comms, and perhaps
incorporate some basic (x,y) type graphics display and manipulation
(simple drawing program). Data may result from user GUI input, or from
parsing a text config file. Solution need not be efficient in machine
resource utilization. Emphasis is on quickness with which programmer
can learn and implement solution.

2. Must be cross-platform: Linux + Windows. This factor can have a big
impact on whether it is necessary to learn a new language, or stick with
C. If my platform was only Linux I could just learn GTK and be done
with it. I wouldn't be here in that case.

Possible solutions:

Form 1: Use C and choose a library that will enable cross-platform GUI
development.

Pro: Don't have to learn new language.
Con: Probably will have difficulty with cross-platform implementation
of serial comms. This will probably need to be done twice. This will
waste time.

Form 2: Use Python and PySerial and TkInter or wxWidgets.

Pro: Cross-platform goal will likely be achieved fully. Have a
programmer nearby with extensive experience who can help.
Con: Must learn new language and library. Must possibly learn a
completely new way of thinking (OOP) not just a new language syntax.
This might be difficult.

Form 3: Use LabVIEW

Pro: I think that the cross-platform goal can be met.
Con: Expensive. I would prefer to use an Open Source solution. But
that isn't as important as the $$$. I have also generally found the 2D
diagrammatical programming language of "G" as repelling as OOP. I
suspect that it may take as much time to learn LabVIEW as Python. In
that case the time spent on Python might be better spent since I would
be learning something foundational as opposed to basically just learning
how to negotiate someone's proprietary environment and drivers.
Comments appreciated.
--
Good day!

________________________________________
Christopher R. Carlen
Principal Laser&Electronics Technologist
Sandia National Laboratories CA USA
cr***************@BOGUSsandia.gov
NOTE, delete texts: "RemoveThis" and
"BOGUS" from email address to reply.

yes, maybe you should look at UML first.

hg

[Jay Loden]

Steve Holden wrote:

It took a little bit more careful planning to get Icon pattern-matching
structures right, but there was much more explicit control of
backtracking. I only wish they'd grafted more OO concepts into it, then
I might never have bothered with Python! Someone did do an OO system
layered on top of it, but IIRC it was clumsy and rebarbative.

OT, but I just wanted to say, "rebarbative" is my word of the day for today thanks to this post. I consider myself to have a reasonably comprehensive vocabulary but that's a new one for me, so I had to look it up after your post ;)

-Jay

[Alex Martelli]

Dennis Lee Bieber <wl*****@ix.netcom.comwrote:

On Mon, 16 Jul 2007 11:45:04 -0700, Chris Carlen
<cr***************@BOGUSsandia.govdeclaimed the following in
comp.lang.python:

The more I play with Python, the more I like it. Perhaps I will
understand OOP quicker than I thought. What I've learned so far about
names binding to objects instead of values stored in memory cells, etc.
has been interesting and fascinating.

Don't confuse Python's "roaming names" with OOP, though. There are
OOP languages that still follow the variable=>memory address containing
object structure.

C++, definitely. But most OO languages, like Java &c, use a more modern
"object reference" naming scheme, just like Python, FP languages, etc.
Alex

[Hendrik van Rooyen]

"Dennis Lee Bieber" <wl*****@ix.netcom.comwrote:

Don't confuse Python's "roaming names" with OOP, though. There are
OOP languages that still follow the variable=>memory address containing
object structure.

"roaming names" is a brilliant description!

Thanks Dennis!

- Hendrik

[greg]

Aahz wrote:

So adding
SNOBOL patterns to another library would be a wonderful gift to the
Python community...

I wrote a module for Snobol-style pattern matching a
while back, but didn't get around to releasing it.
I've just put it on my web page:

http://www.cosc.canterbury.ac.nz/gre.../Snobol.tar.gz

There's no manual yet, but there's a fairly complete
set of docstrings and some test cases to figure it
out from.

--
Greg

[Wolfgang Strobl]

ed***@holyrood.ed.ac.uk (Eddie Corns):

>I don't believe you can get the benefit of SNOBOL matching without direct
language support.

That's my opinion, too.

>There's only so much a library can do. However a valiant
and interesting effort:

http://www.wilmott.ca/python/patternmatching.html

This is newer than http://sourceforge.net/projects/snopy/ which adapts a
ADA implemenation, which follows the SNOBOL model quite closely. Didn't
knew that. Thanks for pointing it out!

Well, unfortunately, it somehow demonstrates your point. This may be
missing familiarity with the changed idiom, though. Perhaps rewriting a
few of James Gimple's snippets from "Algorithms in SNOBOL4"
(->http://www.snobol4.org/) as an exercise using that library might help
to get a better appreciation. Perhaps I'll try, eventually ...
--
Wir danken für die Beachtung aller Sicherheitsbestimmungen

[Wolfgang Strobl]

Paul Rubin <http://ph****@NOSPAM.invalid>:

>aa**@pythoncraft.com (Aahz) writes:

>.So adding SNOBOL patterns to another library would be a wonderful
gift to the Python community...

Snobol patterns were invented at a time when nobody knew anything
about parsing.

But Snobol patterns aren't mainly about building parsers.

>They were extremely powerful (recursive with arbitrary
amounts of backtracking) but could use exponential time and maybe even
exponential space.

Sure. Like any Turing complete language feature.

>
These days, it makes more sense to use something like pyparsing.

Probably, yes.

--
Wir danken für die Beachtung aller Sicherheitsbestimmungen

[Wolfgang Strobl]

aa**@pythoncraft.com (Aahz):

>In article <7c********************************@4ax.com>,
Wolfgang Strobl <ne***@mystrobl.dewrote:

>>
SNOBOLs powerfull patterns still shine, compared to Pythons clumsy
regular expressions.

Keep in mind that Python regular expressions are modeled on the
grep/sed/awk/Perl model so as to be familiar to any sysadmin

Sure, I don't dispute that. There is room for both regular expressions
and SNOBOL type patterns, IMHO, because the concepts are different
enough.

>-- but
there's a reason why Python makes it a *library* unlike Perl. So adding
SNOBOL patterns to another library would be a wonderful gift to the
Python community...

Like Eddie Corns if find it hard to do in an elegant way, without
integrating it into the language. I haven't looked into it for a long
time, though.

--
Wir danken für die Beachtung aller Sicherheitsbestimmungen

[Eddie Corns]

Wolfgang Strobl <ne***@mystrobl.dewrites:

>few of James Gimple's snippets from "Algorithms in SNOBOL4"
(->http://www.snobol4.org/) as an exercise using that library might help
to get a better appreciation. Perhaps I'll try, eventually ...

I never noticed them or the PDF of the book there before. Some Friday
afternoon reading for sure.

Personally I hope to get more to time to look at a combination of Lua and
PEGs (http://en.wikipedia.org/wiki/Parsing_expression_grammar) for my parsing
needs.

Eddie

[Aahz]

In article <ma*********************************************** @python.org>,
greg <py*********@python.orgwrote:

>Aahz wrote:

>>
So adding SNOBOL patterns to another library would be a wonderful
gift to the Python community...

I wrote a module for Snobol-style pattern matching a while back, but
didn't get around to releasing it. I've just put it on my web page:

http://www.cosc.canterbury.ac.nz/gre.../Snobol.tar.gz

Nice! You have restored my faith in the time machine. ;-)
--
Aahz (aa**@pythoncraft.com) <* http://www.pythoncraft.com/

This is Python. We don't care much about theory, except where it intersects
with useful practice.

[Paul McGuire]

On Jul 23, 5:53 am, [e-mail] (Eddie Corns) wrote:

Wolfgang Strobl <[e-mail]:

few of James Gimple's snippets from "Algorithms in SNOBOL4"
(->http://www.snobol4.org/) as an exercise using that library might help
to get a better appreciation. Perhaps I'll try, eventually ...

I never noticed them or the PDF of the book there before. Some Friday
afternoon reading for sure.

Personally I hope to get more to time to look at a combination of Lua and
PEGs (http://en.wikipedia.org/wiki/Parsing_expression_grammar) for my parsing
needs.

Eddie

If you get a chance to look at pyparsing, I'd be interested in your
comments. The PEG page and the SNOBOL implementation have many
similar concepts with pyparsing (or is it the other way around?).

-- Paul

[John J. Lee]

(Sorry if this appears twice, accidentally included c.l.py.announce
the first time where it was (correctly) rejected, not sure if that
means it didn't get through to c.l.py either).

greg <gr**@cosc.canterbury.ac.nzwrites:

Aahz wrote:

>So adding
SNOBOL patterns to another library would be a wonderful gift to the
Python community...

I wrote a module for Snobol-style pattern matching a
while back, but didn't get around to releasing it.
I've just put it on my web page:

http://www.cosc.canterbury.ac.nz/gre.../Snobol.tar.gz

There's no manual yet, but there's a fairly complete
set of docstrings and some test cases to figure it
out from.

Interesting.

Would be nice if tarball contained a top-level directory rather than
unpacking directly into the current working directory -- people on
traditional (non-Mac) unixy systems don't expect that. PEP 8-style
module name (snobol.py not Snobol.py) would be nice too.
John