4 ms·

But interestingly, some of those examples you cited are literally solutions to some of the problems you cited, so... For example, a language like Elixir that ha

But interestingly, some of those examples you cited are literally solutions to some of the problems you cited, so... For example, a language like Elixir that has "trivial concurrency and immutability" enables a test suite that can run across all of your cores at once and is deterministically guaranteed (assuming you watch how you touch shared mutable state outside that code, such as a database) to not step on itself while doing so. Compare this to any one of a number of mutable languages (such as Ruby) that claim concurrency but in actuality often contain deep software bugs that result in flagging, nondeterministic tests UNLESS they are run single-core. That is absolutely a solved engineering problem that then may prevent other mitigations like having to run the test suite across 25+ cloud machines (in single-core mode) and waiting 25 minutes for a test result before being able to continue, which then directly increases developer productivity. Also, being interested in those 2 things is not mutually-exclusive. I LIKE that this is a tangible business result of a fundamental language design decision.

mrkurt 4y ago
If you're after feedback, nothing in this post sounds like a tangible business result to me. It sounds like fun technical wizardry.
- pmarreck 4y ago
  Being able to run a test suite in parallel on your own machine is massively more useful than having to run it across a bunch of machines in the cloud. First of all, clouds go down (the external-dependency problem), or become unavailable when Internet isn't available (and also cost extra money). Secondly, you get instant (more or less) feedback on whether you broke anything, and that allows you to maintain velocity without having to backpedal. Thirdly, if the suite is run concurrently in a deterministically-random fashion (where it outputs the seed before the suite starts), you can often identify reproducible concurrency bugs that will NOT (or be very unlikely to) show up on your multi-VM cloud test runner (which run all the tests single-threaded on separate machines). Fourthly, if we're talking a functional immutable language, those types of bugs (which are some of the worst and most costly of bugs to track down and fix... I know this from experience, a nondeterministic session-loss bug at Desk that it took me a month to fix likely lost thousands of customers, not to mention the cost of essentially benching me for a month plus the benching cost of the previous devs that took a stab at it and failed) are rarely found to begin with. Every one of these leads to either more productive employees, lower ongoing costs, or happier customers. How are these not tangible business results?
  - pastage 4y ago
    I am too stuck in single thread front end integration tests to be able to relate. Are you actually talking about testing full stack or just some backend tech. We almost never have problems with our cloud testing, it is expensive. We need it to have some control over the front end work, benefit is that running the back end stuff is trivial and fast.
    - pmarreck 4y ago
      I have a design bias- I pretty much refuse to build anything for the front end that is not easily testable without using a headless browser as part of my test suite. Headless browser driving adds so much more resource consumption and time to the test suite over time that it defeats the entire purpose of a test suite, which is to (as quickly as possible) assess if any logic in the app has begun violating expectations, so you can proceed with building the next thing quickly without backpedaling and without waiting. I completely understand that individual browsers may have this or that problem or idiosyncrasy and that may need to be tested but I'd put that in QA, not your official standard app test suite. At the most I'd test whether endpoints actually spit out HTML, CSS etc. but not actually check the rendering step. I do have a JS suite as part of my full test that uses jsdom to check DOM manipulation but it is only because it is not resource-intensive and runs fast.
  - mrkurt 4y ago
    Oh I agree with the potential technical benefits. I think the business justification is pretty weak, though. The business benefits you listed are defensive. That is, if the business is doing well, those are things you might optimize for. The same way you'd, say, try and decrease power consumption. There are companies where an order of magnitude decrease in ongoing costs opens allows a whole new kind of product. But order of magnitude increases in the things you just listed are rarely developer process improvements or refactors. Customer happiness is a fun one. If you have a buggy or unreliable app, you'll frustrate customers (I am very aware of this, if you check my post history). You won't _make them happy_ just by building reliable software though. As someone whose #1 priority is reliability right now – fixing bugs faster very low on the list of things that matter. The problems users have with our platform are a combination of the wrong architecture, and non existent tooling for customer communications. Which gets back to the original post. We want to hire devs who can identify out what our users need most today, figure out what we can do about it (if we can at all), and then implement what makes sense.
snovv_crash 4y ago
If you can explain why you like them in terms of business value they provide, in the context of the specific problem this code is meant to solve, then I agree. But without these, it's like hiring a construction worker who will use any excuse to use a backhoe, even when it isn't suitable, just because they love operating it. It's childish and unprofessional, and as an employer, even if you have full time backhoe work for them to do, you want to avoid hiring them, because they'll probably cause a lot of damage to your building site driving the backhoe everywhere when someone else with a wheelbarrow would have been more suitable. Their excitement clouds their judgement about the efficacy of their tool of choice, and they will apply it when it isn't optimal. Elixir is great for massively parallel web facing problems, and if you can explain it as a tool you have in your toolbox for solving this kind of problem then great. But if you say Elixir is awesome and then want to use it to generate graphs from CSV files for internal business metrics, you've lost me.
- weatherlight 4y ago
  > But if you say Elixir is awesome and then want to use it to generate graphs from CSV files for internal business metrics, you've lost me. uhhh, so Elixir is a general purpose language that solves everyday problems. and just happens to havethis phenomenal almost "no-code" solution to literally the problem you just presented, with Elixir Livebook. ... The VM is 35 years old. The syntax is Algol inspired, the Elixir syntax is 10 years old, FP as a paradigm has been around since 1958. It's not some new and shiny toy, it's simply unfamiliar to you.
- pmarreck 4y ago
  I think the majority of programmers don't have that problem, especially with semi-regular discussion/contact. In the past, when I really wanted to try something and the boss didn't agree with spending work time on it, I spent my weekend time on it (back before I had a kid- Seems like a luxury, now!). Most of the time, I came up with something I could demonstrate on the following Monday which got accepted. Sometimes, it didn't, or my hunch/effort was unsuccessful (but I wasn't unhappy because at least I tried).

mrkurt 4y ago

If you're after feedback, nothing in this post sounds like a tangible business result to me. It sounds like fun technical wizardry.

pmarreck 4y ago
Being able to run a test suite in parallel on your own machine is massively more useful than having to run it across a bunch of machines in the cloud. First of all, clouds go down (the external-dependency problem), or become unavailable when Internet isn't available (and also cost extra money). Secondly, you get instant (more or less) feedback on whether you broke anything, and that allows you to maintain velocity without having to backpedal. Thirdly, if the suite is run concurrently in a deterministically-random fashion (where it outputs the seed before the suite starts), you can often identify reproducible concurrency bugs that will NOT (or be very unlikely to) show up on your multi-VM cloud test runner (which run all the tests single-threaded on separate machines). Fourthly, if we're talking a functional immutable language, those types of bugs (which are some of the worst and most costly of bugs to track down and fix... I know this from experience, a nondeterministic session-loss bug at Desk that it took me a month to fix likely lost thousands of customers, not to mention the cost of essentially benching me for a month plus the benching cost of the previous devs that took a stab at it and failed) are rarely found to begin with. Every one of these leads to either more productive employees, lower ongoing costs, or happier customers. How are these not tangible business results?
- pastage 4y ago
  I am too stuck in single thread front end integration tests to be able to relate. Are you actually talking about testing full stack or just some backend tech. We almost never have problems with our cloud testing, it is expensive. We need it to have some control over the front end work, benefit is that running the back end stuff is trivial and fast.
  - pmarreck 4y ago
    I have a design bias- I pretty much refuse to build anything for the front end that is not easily testable without using a headless browser as part of my test suite. Headless browser driving adds so much more resource consumption and time to the test suite over time that it defeats the entire purpose of a test suite, which is to (as quickly as possible) assess if any logic in the app has begun violating expectations, so you can proceed with building the next thing quickly without backpedaling and without waiting. I completely understand that individual browsers may have this or that problem or idiosyncrasy and that may need to be tested but I'd put that in QA, not your official standard app test suite. At the most I'd test whether endpoints actually spit out HTML, CSS etc. but not actually check the rendering step. I do have a JS suite as part of my full test that uses jsdom to check DOM manipulation but it is only because it is not resource-intensive and runs fast.
- mrkurt 4y ago
  Oh I agree with the potential technical benefits. I think the business justification is pretty weak, though. The business benefits you listed are defensive. That is, if the business is doing well, those are things you might optimize for. The same way you'd, say, try and decrease power consumption. There are companies where an order of magnitude decrease in ongoing costs opens allows a whole new kind of product. But order of magnitude increases in the things you just listed are rarely developer process improvements or refactors. Customer happiness is a fun one. If you have a buggy or unreliable app, you'll frustrate customers (I am very aware of this, if you check my post history). You won't _make them happy_ just by building reliable software though. As someone whose #1 priority is reliability right now – fixing bugs faster very low on the list of things that matter. The problems users have with our platform are a combination of the wrong architecture, and non existent tooling for customer communications. Which gets back to the original post. We want to hire devs who can identify out what our users need most today, figure out what we can do about it (if we can at all), and then implement what makes sense.

snovv_crash 4y ago

If you can explain why you like them in terms of business value they provide, in the context of the specific problem this code is meant to solve, then I agree. But without these, it's like hiring a construction worker who will use any excuse to use a backhoe, even when it isn't suitable, just because they love operating it. It's childish and unprofessional, and as an employer, even if you have full time backhoe work for them to do, you want to avoid hiring them, because they'll probably cause a lot of damage to your building site driving the backhoe everywhere when someone else with a wheelbarrow would have been more suitable. Their excitement clouds their judgement about the efficacy of their tool of choice, and they will apply it when it isn't optimal. Elixir is great for massively parallel web facing problems, and if you can explain it as a tool you have in your toolbox for solving this kind of problem then great. But if you say Elixir is awesome and then want to use it to generate graphs from CSV files for internal business metrics, you've lost me.

weatherlight 4y ago
> But if you say Elixir is awesome and then want to use it to generate graphs from CSV files for internal business metrics, you've lost me. uhhh, so Elixir is a general purpose language that solves everyday problems. and just happens to havethis phenomenal almost "no-code" solution to literally the problem you just presented, with Elixir Livebook. ... The VM is 35 years old. The syntax is Algol inspired, the Elixir syntax is 10 years old, FP as a paradigm has been around since 1958. It's not some new and shiny toy, it's simply unfamiliar to you.
pmarreck 4y ago
I think the majority of programmers don't have that problem, especially with semi-regular discussion/contact. In the past, when I really wanted to try something and the boss didn't agree with spending work time on it, I spent my weekend time on it (back before I had a kid- Seems like a luxury, now!). Most of the time, I came up with something I could demonstrate on the following Monday which got accepted. Sometimes, it didn't, or my hunch/effort was unsuccessful (but I wasn't unhappy because at least I tried).