8 ms·

And if you try to write the 20x faster version, your coworkers will think you are over-complicating and not being a team player.

db48x 3y ago
Not necessarily. Good comments go a long way.
- crabbone 3y ago
  I have a very long list of things that were good, worked well, and ended up rejected because the team didn't want to put in effort to learn how they work. My conclusion so far is that if you want to make things work well, you shouldn't be working on a commercial project, use a unpopular language with a steep learning curve to filter out those who'd be a drag on your project. Maybe you don't have to be a jerk, but being blunt helps. Below are some examples of initiatives that were meant to improve things and how they failed due to other programmers being lazy and / or ignorant. When ActionScript was a thing it competed with HaXe. A similar (also ECMAScript-related) language with a small but dedicated community, a compiler that was hugely superior to to MXMLC (official Adobe compiler for AS3) and a bunch of features intended to improve code correctness and performance. I was hired by a company making a "PowerPoint online" kind of product. The main system component was a large Flex (AS3) applet that was hugely inefficient especially in terms of how it utilized network. It had to load huge shared libraries with assets (mostly clip art) every time users wanted to either edit or watch a presentation. The AWS bill was growing dangerously big. My mission was to find a solution to reduce the network activity. My idea was to create a separate player component that would extract the relevant assets from the libraries server-side, compile them into individual SWFs. The reason was that the final presentations were loaded a lot more often and by first-time users (i.e. no caching). HaXe was the ideal language because it already had a library that could generate a large subset of SWF, and it could compile both to AS3 and to C++, so that generation could also be done on a server using a more efficient implementation. After several month of work, I produced a set of programs that could generate SWFs both server-side and client side and showed how this would improve the network activity. The other programmers on the AS3 team, who earlier promised to get familiar with HaXe, since they had to incorporate the new player component into the existing Flex applet... didn't hold their part of the bargain. No matter the amount of help I provided, they simply wouldn't do anything to incorporate the new component, instead making claims that grew more bizarre and more untrue as time went by. Having spent more time trying to convince the team to adopt my code rather than writing it, I decided to look for a different place to work at. In the end, this entire effort went down the drain. ---- In a very similar way, I had to solve a problem created by using Google's Protobuf Python bindings which required generating Python modules in order to function. We needed to have an API server that could simultaneously serve multiple versions of the same Protobuf API from similarly named modules. Since Google's implementation didn't allow this, I wrote my own (while my manager was on maternity leave). I improved parsing speed, network load, reduced the amount of maintenance the component needed by making it possible to add new Protobuf message definitions at run time... 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 have a similar story about extracting and aggregating Web interface from a RoR app, producing a Swagger definition... written in Prolog, which was also thrown away because Prolog. Similarly, had written an I/O tester for distributed filesystem in Prolog, which was thrown away for the same reason... And this answer will eventually hit the character limit if I keep listing things that were discarded simply because programmers didn't want to learn how to do their job.
  - Nathanba 3y ago
    wouldnt it have been easier to port the Haxe code to AS3? afaik both language are very similar. Then you wouldn't have a problem and you wouldnt have to rely on them to learn your codebase. Likewise I doubt that the parser being written in C was the problem, the problem was probably that (I assume?) you didnt also provide the convenient python bindings. Otherwise it's hard to believe that someone would throw away finished code. I myself was in a similar situation once though, I bound to an external java code via JNI and it worked fine. But they ended up rewriting via HTTP calls anyway. Sure it's easier that way but I mean damn.. not even keeping it around as an option or as a benchmark seems a bit too lazy. But I still understood why they did it, it's just a source of possible errors for them and they don't want to deal with it. 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.
    - crabbone 3y ago
      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.
nesarkvechnep 3y ago
In the end they'll just use a Lambda.
- boppo1 3y ago
  Is that beneficial or not? I'm still too much of a novice to know.
  - TheFlyingFish 3y ago
    (assuming that we're talking about the AWS serverless functions) Like everything else, it's situational. Upsides of lambdas are ease of deployment (no need to worry about servers, that's kind of the whole point of serverless), virtually infinite horizontal scaling, and a very generous free tier. Downsides are relatively slow cold starts, difficulty of exposing to the outside world (eg via HTTP route), and lack of state management. Personally I like using Lambda as glue between different parts of the AWS ecosystem, or to handle events, dispatch notifications etc. However I would definitely not use Lambda for anything remotely resembling a stateful web app, for instance. The slow cold starts and inherent statelessness are going to make that difficult. Also API Gateway is a huge pain to work with, or was last time I looked at it.
nikanj 3y ago
Your coworkers would prefer you splitting the thing into two microservices communicating over a REST api, aka the 200x slower version.
- hgraves1991 3y ago
  We hate to see it
- cmrdporcupine 3y ago
  Yep. And then wonder why they're getting pages in the middle of the night because CustomerPaymentsProcessingService became inconsistent with CustomerMembershipProcessingService and CustomerOrderStatusService and people's credit cards are charged without their memberships showing as active, or whatever. Or maybe not wonder, because it makes them feel important?
- nesarkvechnep 3y ago
  A REST api without a hint of hypertext.
xxs 3y ago
it's time to change your workplace, not everyone is meant to be petty/incompetent.
- cmrdporcupine 3y ago
  My experience is that even the most committed and smart people degrade as teams into patterns which produce seemingly unnecessary complexity because that's where our industry trends and tools push us. People create boxes to isolate perceived complexity, that in turn create new complexity. I share the other commenter's frustrations. I want out of the tarpit.
  - xxs 3y ago
    I have the exactly opposite experience - I call bullcrap when I see it, bluntly and directly. 'Industry standard' nonsense is still nonsense. The sheer truth is that many developers are just CV driven, or they miss their childhood playing with toys. Overall the software developers/engineers (we) are an extremely spoiled breed, often entirely detached from reality - and it shows.
thelastparadise 3y ago
> And if you try to write the 20x faster version, your coworkers will think you are over-complicating and not being a team player. Hear hear! Why is it like this?
- cmrdporcupine 3y ago
  Because 9/10 developers would not implement it correctly anyways (even if they think they did) and the generally-right thing to do is rely on existing libraries and services which do this already.
- nerdponx 3y ago
  Because spending tens of developer-hours to save tens of compute-hours usually isn't worth it. Justify to me that it's worth the time investment, maintenance burden, and risk of failure, then I'll let you work on it.
michaelcampbell 3y ago
Which can be the case. Saving 15ms a few times a week/day/hour(?) vs hours of developer maintenance time over the life if the thing can still be an issue.

db48x 3y ago

Not necessarily. Good comments go a long way.

crabbone 3y ago
I have a very long list of things that were good, worked well, and ended up rejected because the team didn't want to put in effort to learn how they work. My conclusion so far is that if you want to make things work well, you shouldn't be working on a commercial project, use a unpopular language with a steep learning curve to filter out those who'd be a drag on your project. Maybe you don't have to be a jerk, but being blunt helps. Below are some examples of initiatives that were meant to improve things and how they failed due to other programmers being lazy and / or ignorant. When ActionScript was a thing it competed with HaXe. A similar (also ECMAScript-related) language with a small but dedicated community, a compiler that was hugely superior to to MXMLC (official Adobe compiler for AS3) and a bunch of features intended to improve code correctness and performance. I was hired by a company making a "PowerPoint online" kind of product. The main system component was a large Flex (AS3) applet that was hugely inefficient especially in terms of how it utilized network. It had to load huge shared libraries with assets (mostly clip art) every time users wanted to either edit or watch a presentation. The AWS bill was growing dangerously big. My mission was to find a solution to reduce the network activity. My idea was to create a separate player component that would extract the relevant assets from the libraries server-side, compile them into individual SWFs. The reason was that the final presentations were loaded a lot more often and by first-time users (i.e. no caching). HaXe was the ideal language because it already had a library that could generate a large subset of SWF, and it could compile both to AS3 and to C++, so that generation could also be done on a server using a more efficient implementation. After several month of work, I produced a set of programs that could generate SWFs both server-side and client side and showed how this would improve the network activity. The other programmers on the AS3 team, who earlier promised to get familiar with HaXe, since they had to incorporate the new player component into the existing Flex applet... didn't hold their part of the bargain. No matter the amount of help I provided, they simply wouldn't do anything to incorporate the new component, instead making claims that grew more bizarre and more untrue as time went by. Having spent more time trying to convince the team to adopt my code rather than writing it, I decided to look for a different place to work at. In the end, this entire effort went down the drain. ---- In a very similar way, I had to solve a problem created by using Google's Protobuf Python bindings which required generating Python modules in order to function. We needed to have an API server that could simultaneously serve multiple versions of the same Protobuf API from similarly named modules. Since Google's implementation didn't allow this, I wrote my own (while my manager was on maternity leave). I improved parsing speed, network load, reduced the amount of maintenance the component needed by making it possible to add new Protobuf message definitions at run time... 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 have a similar story about extracting and aggregating Web interface from a RoR app, producing a Swagger definition... written in Prolog, which was also thrown away because Prolog. Similarly, had written an I/O tester for distributed filesystem in Prolog, which was thrown away for the same reason... And this answer will eventually hit the character limit if I keep listing things that were discarded simply because programmers didn't want to learn how to do their job.
- Nathanba 3y ago
  wouldnt it have been easier to port the Haxe code to AS3? afaik both language are very similar. Then you wouldn't have a problem and you wouldnt have to rely on them to learn your codebase. Likewise I doubt that the parser being written in C was the problem, the problem was probably that (I assume?) you didnt also provide the convenient python bindings. Otherwise it's hard to believe that someone would throw away finished code. I myself was in a similar situation once though, I bound to an external java code via JNI and it worked fine. But they ended up rewriting via HTTP calls anyway. Sure it's easier that way but I mean damn.. not even keeping it around as an option or as a benchmark seems a bit too lazy. But I still understood why they did it, it's just a source of possible errors for them and they don't want to deal with it. 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.
  - crabbone 3y ago
    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.

nesarkvechnep 3y ago

In the end they'll just use a Lambda.

boppo1 3y ago
Is that beneficial or not? I'm still too much of a novice to know.
- TheFlyingFish 3y ago
  (assuming that we're talking about the AWS serverless functions) Like everything else, it's situational. Upsides of lambdas are ease of deployment (no need to worry about servers, that's kind of the whole point of serverless), virtually infinite horizontal scaling, and a very generous free tier. Downsides are relatively slow cold starts, difficulty of exposing to the outside world (eg via HTTP route), and lack of state management. Personally I like using Lambda as glue between different parts of the AWS ecosystem, or to handle events, dispatch notifications etc. However I would definitely not use Lambda for anything remotely resembling a stateful web app, for instance. The slow cold starts and inherent statelessness are going to make that difficult. Also API Gateway is a huge pain to work with, or was last time I looked at it.

nikanj 3y ago

Your coworkers would prefer you splitting the thing into two microservices communicating over a REST api, aka the 200x slower version.

hgraves1991 3y ago
We hate to see it
cmrdporcupine 3y ago
Yep. And then wonder why they're getting pages in the middle of the night because CustomerPaymentsProcessingService became inconsistent with CustomerMembershipProcessingService and CustomerOrderStatusService and people's credit cards are charged without their memberships showing as active, or whatever. Or maybe not wonder, because it makes them feel important?
nesarkvechnep 3y ago
A REST api without a hint of hypertext.

xxs 3y ago

it's time to change your workplace, not everyone is meant to be petty/incompetent.

cmrdporcupine 3y ago
My experience is that even the most committed and smart people degrade as teams into patterns which produce seemingly unnecessary complexity because that's where our industry trends and tools push us. People create boxes to isolate perceived complexity, that in turn create new complexity. I share the other commenter's frustrations. I want out of the tarpit.
- xxs 3y ago
  I have the exactly opposite experience - I call bullcrap when I see it, bluntly and directly. 'Industry standard' nonsense is still nonsense. The sheer truth is that many developers are just CV driven, or they miss their childhood playing with toys. Overall the software developers/engineers (we) are an extremely spoiled breed, often entirely detached from reality - and it shows.

thelastparadise 3y ago

> And if you try to write the 20x faster version, your coworkers will think you are over-complicating and not being a team player. Hear hear! Why is it like this?

cmrdporcupine 3y ago
Because 9/10 developers would not implement it correctly anyways (even if they think they did) and the generally-right thing to do is rely on existing libraries and services which do this already.
nerdponx 3y ago
Because spending tens of developer-hours to save tens of compute-hours usually isn't worth it. Justify to me that it's worth the time investment, maintenance burden, and risk of failure, then I'll let you work on it.

michaelcampbell 3y ago

Which can be the case. Saving 15ms a few times a week/day/hour(?) vs hours of developer maintenance time over the life if the thing can still be an issue.