Can a low-level programmer learn OOP?

[Paul Rubin]

.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).

 

[Dennis Lee Bieber]

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.
--
Wulfraed Dennis Lee Bieber KD6MOG
(e-mail address removed) (e-mail address removed)
HTTP://wlfraed.home.netcom.com/
(Bestiaria Support Staff: (e-mail address removed))
HTTP://www.bestiaria.com/

 

[Steve Holden]

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 +1 571 484 6266 +1 800 494 3119
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]

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
(e-mail address removed)
NOTE, delete texts: "RemoveThis" and
"BOGUS" from email address to reply.

yes, maybe you should look at UML first.

hg

 

[Jay Loden]

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]

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]

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

 

[Dennis Lee Bieber]

"roaming names" is a brilliant description!

Twas just an attempt avoid the long nasty description of how the
names "move" from object to object... My biggest problem was that my
fingers were trying to type "roaming gnomes" (Travelocity's advertising
gimmick
http://dest.travelocity.com/Promotions/0,,TRAVELOCITY|1751|mkt_main|,00.html
)
--
Wulfraed Dennis Lee Bieber KD6MOG
(e-mail address removed) (e-mail address removed)
HTTP://wlfraed.home.netcom.com/
(Bestiaria Support Staff: (e-mail address removed))
HTTP://www.bestiaria.com/

 

[greg]

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/greg.ewing/python/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.

 

[Wolfgang Strobl]

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.

 

[Wolfgang Strobl]

(e-mail address removed) (Aahz):

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.

 

[Wolfgang Strobl]

(e-mail address removed) (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 ...

 

[Eddie Corns]

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]

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/greg.ewing/python/Snobol.tar.gz

Nice! You have restored my faith in the time machine. ;-)

 

[Paul McGuire]

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

 

[Eddie Corns]

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?).

It's on my list of things to get round to.

I think what I'm really after though is a parsing DSL. I only did only one
fairly small project in SNOBOL but I was impressed at the ease with which I
could express the problem (some googling suggested that many end users found
the same). I guess I want SNOBOL embedded in a modern language with scoping
etc. Python is antithetical to (this class of) DSLs (IMHO)

Probably what I really need is parser combinators in Haskell or maybe camlp4
or some such exotica but unfortunately I've never heard of them.

Eddie

 

[Paul McGuire]

It's on my list of things to get round to.

I think what I'm really after though is a parsing DSL. I only did only one
fairly small project in SNOBOL but I was impressed at the ease with which I
could express the problem (some googling suggested that many end users found
the same). I guess I want SNOBOL embedded in a modern language with scoping
etc. Python is antithetical to (this class of) DSLs (IMHO)

Probably what I really need is parser combinators in Haskell or maybe camlp4
or some such exotica but unfortunately I've never heard of them.

Eddie- Hide quoted text -

- Show quoted text -

I have had pyparsing users refer to pyparsing as an in-Python DSL, and
others make comparisons between pyparsing and Parsec (monadic
combinator in Haskell). I'm not sure why you would say this approach
is antithetical to Python - the builtin support for operator
overloading, __call__, __len__, __nonzero__(soon to be __bool__),
__set/getattr__, etc. permit you to impart quite a bit of expressive
behavior to your parsing classes. What I tried to do with pyparsing
was to emulate Python's builtin container classes and object instances
with the results that get returned from invoking a parser, so that the
after-parsing work would feel natural to established Python users.

If you want to just see some existing BNF's implemented in pyparsing,
you can view them online at the pyparsing wiki. Here are some
representative examples:
http://pyparsing.wikispaces.com/space/showimage/simpleSQL.py
http://pyparsing.wikispaces.com/space/showimage/fourFn.py
http://pyparsing.wikispaces.com/space/showimage/jsonParser.py

-- Paul

 

[Eddie Corns]

I have had pyparsing users refer to pyparsing as an in-Python DSL, and
others make comparisons between pyparsing and Parsec (monadic
combinator in Haskell). I'm not sure why you would say this approach
is antithetical to Python - the builtin support for operator
overloading, __call__, __len__, __nonzero__(soon to be __bool__),
__set/getattr__, etc. permit you to impart quite a bit of expressive
behavior to your parsing classes. What I tried to do with pyparsing
was to emulate Python's builtin container classes and object instances
with the results that get returned from invoking a parser, so that the
after-parsing work would feel natural to established Python users.

I don't dispute it is _a_ DSL nor even that it's a very powerful way to do
parsing (in case anyone was wondering). But my intuition tells me that it
ought to be possible to close the remaining gap and I'm trying to understand
how that could be done and that's the bit I suspect might require a higher
class of DSL (<whisper>ie macros</whisper>). Of course my intuition never
fails but sometimes reality distorts so as to make me look wrong.

The plan is to apply pyparsing to some real project and hopefully gain a
better understanding. I have in mind parsing Cisco config files as a first
trial. As to when I get time...

You see I could just sit down and work out how to solve the problem (eg the
config files) using pyparsing or whatever and move on but I'm sure you of all
people know why that's not enough!

If you want to just see some existing BNF's implemented in pyparsing,
you can view them online at the pyparsing wiki. Here are some
representative examples:
http://pyparsing.wikispaces.com/space/showimage/simpleSQL.py
http://pyparsing.wikispaces.com/space/showimage/fourFn.py
http://pyparsing.wikispaces.com/space/showimage/jsonParser.py

-- Paul

I appreciate the input and hopefully one day I'll be posting some questions on
the wiki.

Cheers,
Eddie

 

[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).

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/greg.ewing/python/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