How fast are Linux pipes anyway? (2022)

Yes, when the mutex or condvar is inited with attribute PTHREAD_PROCESS_SHARED.

> The problem was I wrote the parser in C. This is what enabled good performance. When my manager came back to work, she realized she declared that she doesn't know C and will never learn (even though she wasn't related directly to the project), and the project was thrown to the dogs.

I sympathize with your manager here. If someone under me, ostensibly working on a Python app, wrote a component in C while I was away on leave, without clearing it with me first, I'd be pissed off too.

You decided to use a programming language that other people on your team didn't know, and therefore nobody other than you could maintain, debug, or extend what your wrote. And you did it underhandedly while your manager was away. You deserved the ire here.

There are lots of other ways you can make things closer to C-level performance while sticking closer to something a team of Python devs could maintain, e.g. using Cython or even running a Python program with PyPy (especially if it involves a lot of looping and basic string operations).

And did you even benchmark the Python implementation? How much faster was the C version really? Was it even a bottleneck in the system to begin with? How many developer-hours did you spend on the C version of this component, and how many would you have spent on the equivalent Python version?

Also, C is a really hard language to learn and use effectively, because of the loosey-goosey types and absence of memory safety. Your decision imposed a tremendous burden on the rest of the organization, which might not have been worth the performance gain in this one component of your system.

This was IMO a bad decision on your part, because it's overly fixated on the benefits of achieving a narrow technical objective, disregarding a variety of short- and long-term costs. At minimum, it's not at all obvious that your decision aligns with the broader goal of your team consistently delivering value over a longer period of time. There are countless war stories to be told, of overzealous junior- and mid-level ICs pulling shit like this and it ending up badly for the org.

It's one thing if another team actually committed to using a different programming language, and then backed off their commitment, as in the Haxe example. That's on them, not on you. But being a cowboy and writing stuff in hard-to-learn languages that other people on your team don't know, without any org-level buy-in for getting people trained up on it, is not at all a good habit to be in. Consider that you are the only common factor among all these problematic situations at different organizations.

Porting HaXe to AS3 wouldn't have solved the C++ part of the server component.

Even if I didn't need the C++ part, HaXe way of doing things is very different from Flex. Also, the code for SWF generation required quite a bit of linear algebra, which scared the original developers (the code had to take various properties of display objects and convert them into matrices of affine transformations, because that's how SWF format natively encodes it).

Even after all that, the code would lose a significant portion of performance gained from it being written in HaXe. HaXe made two significant improvements on MXMLC: since it was able to prove type correctness at compile time it removed type checks at run time (that's almost like removing half of the bytecode). And, on top of that, if it was able to resolve a reference during compile time, it generated a more efficient code for lookup (i.e. MXMLC generated code that stacked all contexts within function visibility and whenever a non-local variable was referenced it'd put a call to a function to look through this stack; this especially penalized the code with nested functions).

> Likewise I doubt that the parser being written in C was the problem

Doubt all you want, but it was the problem... Why did you choose to second-guess me if you were never there, never interacted with people in question, never seen the program in question? Like, on what authority do you think you know better?

> the problem was probably that (I assume?) you didnt also provide the convenient python bindings

You guessed wrong...

> Otherwise it's hard to believe that someone would throw away finished code.

You must be new here... I've seen this more times than I can count. Sometimes it's even a good thing.

> seems a bit too lazy.

Being lazy and ignorant is the name of the game. This is what people in general are made of, but when it comes to programmers, they have fewer checks that make other professionals resist being lazy and ignorant.

> don't want to deal with it.

Because, let me repeat it: ignorant and lazy.

> Also I wouldn't want to inherit Prolog code either because it's an ancient niche language, IDE and docs and everything else is probably terrible.

You are also demonstrably ignorant and lazy: you didn't bother to check, and decided to spew a bunch of nonsense.

* What difference does it make in what year was a language created? English is older than Esperanto, does this make English worse? Hebrew is older than English, is Hebrew worse?

* Prolog is alive and well. Multiple language implementations released new versions in the last year. A lot of academic research happens in Prolog because, conceptually, it's newer and more advanced than, say, Java or Python.

* Documentation is fine. Python documentation is a lot worse for example, because it's written by idiots... Python documentation writes simply don't know how to do it well, so it doesn't matter if there are many of them, or how much effort they put into it -- what comes out is garbage.

* I haven't experienced technical problems programming in Prolog. Installed SWI Prolog, wrote some code, ran it, fixed errors, ran it again... nothing out of ordinary. Editor support was not a problem, not anymore than editor's support for Python or any other more popular language.

[flagged]

[flagged]