Re: [mildly OT] Some info about Python

[Sean Conner <sean@...>]

It was thus said that the Great Peter Hickman once stated:
> 
> But when I want to try something out Lua is a
> good choice unless I envision serious string mangling or that something OOP
> may be the best solution

  For serious string mangling I reach for LPEG.  Yes, it has a learning
curve, but it is well worth learning if you munge tons of strings.  I tend
to reach for it over Lua patterns.  

> Although I get pissed when searching for an existing Lua library to do some
> task to find either zero or six. Not having standard libraries is not
> necessarily a bad thing. In other languages the standard / default library
> for something tends to have a kitchen sink set of features just in case
> someone might need feature X. This comes at a cost, the codebase is larger,
> it has codepaths that are addressing features you have no interest in,
> hitting performance and eating memory. More code means more possible bugs.
> Just look at the standard Python logger. It is truly a marvel of
> engineering. Of which I use at most 10% but the remaining 90% is baggage my
> application must carry. Same with Ruby, every unused language feature is
> hitting performance and eating memory

  I use syslog() for my lgging needs (and yes, I did write my own wrapper
for that [1]) and I was curious as to what a "logging module" would do that
syslog() doesn't.  I took a look at Python's logger and OH MY GOD WHAT
DOESN'T IT DO?  I'll leave that mess up to the syslog daemon to handle [2].

> I found four logger libraries for Lua but ended up writing my own (so now
> we have five). The evaluation and eventual development of my own solution
> slowed down development (with Ruby or Python there is no real choice, just
> read the docs and write code) but I have a solution that does exactly what
> I want. It does it as fast as possible. It uses the least memory possible
> and being small (54 lines including comments) it is not going to be
> difficult to hunt down any bugs. The very reasons I selected Lua for that
> project, these are Lua's strengths

  I generally write my own library code.  lposix (or is it luaposix?  I
forget which one is the current standard) was just too large for my tastes,
with functionality overlapping that of luasocket.  luasocket doesn't have a
good design (in my opinion).  luafilesystem is too heavy to use (because of
portability issues) and the list goes on.  My approach was to have well
targetted libraries that work well together (and prevent unneccessary
overlap), and I have:

	org.conman.fsys		- file system related calls
	org.conman.clock	- get time, set time, sleep
	org.conman.process	- process creation
	org.conman.signal	- signal related functions
	org.conman.net		- sockets and network addresses
	org.conman.tls		- TLS wrapper based on LibreSSL
	org.conman.net.tcp	- create file system like IO over TCP
	org.conman.net.tls	- create file system like IO over TLS
	org.conman.nfl		- network event driver framework
	org.conman.nfl.tcp	- handle TCP connections per coroutine
	org.conman.nfl.tls	- handle TLS connections per coroutine
	org.conman.pollset	- select()/poll()/kqueue()/epoll()
	org.conman.syslog	- wrapper for syslog
	org.conman.errno	- list of system error values
	org.conman.env		- load environment vars into table

  Theer are more, but I think you get the idea.  It took several years go
get this all written and designed, and I'm still mucking with them to this
day.  But now that I have them, it's easy to whip up stuff like a gopher
server [3] or a SIP processor (for work).

  Now that I think about it, I think this lack of modules designed to work
well together is possibly missing from Lua.

  -spc

[1]	https://github.com/spc476/lua-conmanorg/blob/master/src/syslog.c

[2]	Oh, and I wrote my own syslog daemon in Lua as well.

	https://github.com/spc476/syslogintr

[3]	https://github.com/spc476/port70