Brian Deacon wrote:
I read _Python in a Nutshell_ from O'Reilly and I'm really quite
impressed with the language. It's the only reading I've done on Python,
so I don't really have any points of comparison, but I would still
recommend the book, if anybody is looking for a good resource.
I am pretty happy with Python so far. Just a few minutes ago a friend
IM'd me with a problem: Need to convert a bunch of hex from an ethereal
packet dump back into binary to change a value and then put it back on
the wire as part of some product testing he is doing. A quick google
search turned up just the right library and in 2 lines of code I had his
solution:
import binascii
print binascii.unhexlify("deadbeef")
I guess this actually shows off more the extensive libraries in python
but it is still quite useful.
As to LISP, I tried to start teaching myself, but I just went blind
trying to understand even the code I had written myself. The amount of
nesting parentheses was something I just couldn't train myself to read,
no matter how many ways I tried spacing, indenting, etc.
You should not have to worry about nesting parens. Use emacs (or any
editor that balances parens for you) and let the editor worry about that
stuff for you. It does take some getting used to.
What interests me about C now is the code I'm seeing where the authors
are using object-oriented techniques in a language that doesn't
explicitly support it. A disciplined use of function pointers and
struct's, and you can have most if not all of the benefits of OO
programming, but with the kind of visibility on the processing to avoid
spending unnecessary horsepower when you don't need to.
Yep. It is possible to do object oriented programming in straight C. The
question to ask is: Do I really need to be putting in this much extra
work in managing my own memory and pointers and reinventing the OO wheel
to get some extra performance? The gurus say that premature
optimization is a sin. Of course if you are just doing it all for fun
that is just fine.
Another big place where I could use some direction is in how to make the
transition from being so IDE-dependent. I've probably only just now
reached the break-even point with vi that I'm as fast as I would be in a
do-nothing editor like notepad in windows. I'd love a book that could
help me get my linux legs underneath me on just the basic stuff like
getting the most out of vi, using gdb, makefiles and all the rest. I'm
This is a tough one for Windows people. For the unix world the bash
prompt IS your IDE. Or some might say emacs is their IDE. I think this
is in line with the unix philosophy of using a number of small tools
each of which does its job well. As opposed to one big inflexible tool
that tries to do everything.
a .Net and java programmer for my day job, and I am not anywhere near as
productive in trying to program from my ssh terminal as I am with the
behemoth windows IDE's that give me context-sensitive word completion,
visual step-through debugging, and all the other niceties. But I
haven't found any good resources that tell me "This is how you get
really productive for programming in a linux environment."
I have a book called "Linux Application Development" by Eric Troan:
http://www.amazon.com/gp/product/0321219147/ref=pd_lpo_k2_dp_k2a_2_img/103-6164273-8019836?%5Fencoding=UTF8
Actually I have the first edition but I expect to the second to be more
up to date and complete. I think it does a pretty good job of covering
the tools you will want to know about to write C code in the Linux
environment.
--
Tracy R Reed http://ultraviolet.org
A: Because we read from top to bottom, left to right
Q: Why should I start my reply below the quoted text
--
[email protected]
http://www.kernel-panic.org/cgi-bin/mailman/listinfo/kplug-lpsg
