Re: [mildly OT] Some info about Python

[Sean Conner <sean@...>]

It was thus said that the Great Lorenzo Donati once stated:
> On 19/01/2020 01:47, Sean Conner wrote:

  [ snip ]

> >Also, back in late 2018, a new project was announced.  I (by myself,
> >on my own) managed to write 90% of the code base in Lua in two days
> >(the last bit wasn't done because of some still open questions).  The
> >other team that actually started writing the code took the better
> >part of a year (I think---I'm not entirely sure they're done yet) to
> >write the program.  But hey, I program in Lua, what so I know?
> 
> Yes, from your POV you are HUGELY productive with Lua (and that's why 
> I'm /not/ bashing on the language - heck! I LOVE it). But from a 
> management POV you are (seriously) a potential liability: if you decided 
> to leave the company they would be seriously sc***d up, unless there 
> were a ton of expert Lua programmers around ready to jump on board to 
> keep care of the code you wrote.
> (BTW: how much of your Lua coding requires interfacing with C through 
> Lua C API?).

  Hard to say.  I have to use some of the POSIX stuff (network IO, select(),
reading time at millisecond precision (or better)) and there is some C glue
to some specialized data files that *could* be done in pure Lua (5.3) but
due to resource utilization (we mmap() the files beause they're shared among
several programs) and the pain of reading binary data in Lua 5.1 (there's
the reason for string.pack()/unpack()).  Oh, and LPEG---parsing of SIP
messages (lots of text).

  But the main logic is in Lua, and because of coroutines, it's all
imperative, this, that, theother type sequence which makes for easy
modifications of the main logic---the same *can't* be said for the other
components written in C++---there's it's a nightmare tangle of state
machines all over the place.

  Yes, I am aware of the view from management, but so far, it's never been
an issue (my first and third manager (same person) didn't care, my second
and fourth one (same, but different person) didn't understand what our
department actually *did*, my fifth manager put my Lua-proof-of-concept (I
was using Lua at the time for prototyping purposes with the intent of maybe
rewriting it in C when the logic was hashed out) into production without my
knowledge, I didn't have a sixth manager (long story) and I'm now on my
seventh manager (yes, seventh---number six wasn't an official manager,
again, it's a long story) who is close to retirement anyway).  And my record
of quick turn around times speaks for itself---unlike the turn around time
for the non-Lua components.

  If I leave, is the company screwed?  Not really, as the only other Lua
programmer works in our department (he uses Lua for configuration, not main
logic).  On the down side, with the exception of me, the entire department
is near retirement age, so in a few years the company will be screwed anyway
(let's see, Lua, C89 and C++98, lovely mix of langauges there 8-/

> Moreover, ask yourself if a company wanted /now/ to invest in a new 
> language, would they choose Lua (even if (a) they needed something where 
> Lua shines and (b) they knew about Lua altogether)?

  Gaming companies seem to like Lua.  It's also in Apache and Redis.  So
it's out there.

> Of course if you already have a huge codebase in Lua with good senior 
> programmer/s/ (note the plural), you would think thrice before making a 
> switch.
> 
> But still, if a technology is going to be obsoleted [1] by market 

  I think you forgot your footnote.

> forces, that's an important factor in management decisions (remember 
> those firms stuck to maintain huge COBOL codebases in critical systems 
> that paid big bucks for the few greybeards that still knew it?!?).

  Yes, and we're trying to get away from some legacy code ourselves (SS7). 
There's nobody left in our company that really understands it.  There is a
department that works with SS7 at our parent company, but they use an
entirely different SS7 stack than we do (theirs is homegrown, ours is
purchased, not sure which one sucks worse).

> A good technical manager should be able to see that a technology is 
> going the way of the dodo and plan for its timely replacement.
> 
> I'm not saying Lua is obsolete because it is bad, but market forces have 
> (almost) nothing to do with what is good or bad (sadly). If a product is 
> badly marketed there is no hope it would be able to compete (especially 
> on a large global scale).

  And in my department, I'm surprised we didn't use Erlang.

> Python has a huge advantage wrt. other competitors: it appeals to 
> non-programmers. Go aimed at being a new system language, maybe 
> replacing C in some areas. They were targeting professional devs.

  From what I've seen, Rust is pulling away at the C programmers and part of
the C++ crowd, Go is pulling away Python users and a part of C++
programmers, with Swift pulling away programmers who work with Apple
products.

> Ask yourself which language would you use if you weren't an expert 
> programmer with a problem at hand that required some serious programming 
> that didn't require hiring a professional dev.
> "Hey everyone is talking about Python. Let's try it!"

  I can't answer that as I'm an expert programmer.  And if I'm honest, if I
were a 15 year old kid, I"m not sure I would even have an interest in
programming these days.  Long gone are the days of turning on a computer and
less than a second later (and that's key) typing

	10 PRINT "HELLO SEAN"
	20 GOTO 10

> [*] BTW, although I appreciated some new features in the evolution of 
> Lua from Lua 5.1 to Lua 5.3 (e.g. goto, operators). I really didn't 
> understand some decisions: string.pack/unpack, half baked utf8 library?
> 
> These seems very specialized tools that would fit very well into an 
> external library in the current Lua philosophy. Yet they were included 
> in the standard library. Why? Who knows!

  string.pack()/unpack() I agree with, but the UTF-8 changes were not just
limited to the utf8 module.  There are some language changes to allow
Unicode escape sequences.

> And the new features of Lua 5.4 ... well I'm a bit perplexed. Some 
> mechanism to handle RAII more deterministically is very useful, but the 
> syntax complications seems a bit ugly to me. But I didn't try it, so 
> it's just a gut feeling.

  I have similar feelings, and I feel that Lua 5.4 isn't that compelling to
switch to (but it will be easier than the switch from 5.1 to 5.2).

  -spc