4 ms·

I don't disagree. The problem is that people stop with the better practices (like statically strongly typed languages) and increased coverage/branch testing vee

I don't disagree. The problem is that people stop with the better practices (like statically strongly typed languages) and increased coverage/branch testing veeeeeeeeery long before they hit the diminishing returns. That's the crux of the issue most of the times: "eh, good enough". Additionally, I really want us to stop pretending we can program CPUs directly (and I include the higher-level languages here as well, not just machine code and assembly). We can't. We need more declarative languages, e.g. I want to be able to say "I want to open a huge file with scatter-gather mechanics and with these 3 functions piped that do mapping and reduction". Why should we always code this by hand? There are objective best ways to produce this code in most languages. Let's have a DSL library that allows us to express that intent and be done with it and move on to be productive on another task. This is not done enough to this day. Various people and organizations are doing it here and there and to me they are the beacons of our future hope. Everybody else is just banging at their Emacs / VIM in the meantime.

TheMonarchist 5y ago
> I want to be able to say "I want to open a huge file with scatter-gather mechanics and with these 3 functions piped that do mapping and reduction". IME C++ templates and generic programming help with that aim.
- pdimitar 5y ago
  Very far from it. I get what you're saying but it's not even close IMO.
selestify 5y ago
> Various people and organizations are doing it here and there and to me they are the beacons of our future hope. Who are these people and organizations?
- pdimitar 5y ago
  You can join me in a mourning session because when I stumbled upon them years ago I never took the effort of so much even writing down their names so now it's a blank stare from me, sorry... :(
cle 5y ago
I would consider coding these things by hand in the following non-exhaustive cases: - I am writing the thing you are asking someone to write - I have performance/memory constraints that existing high-level abstractions can’t adequately deal with - I have legal or other business constraints preventing me from using existing high level tools (eg company prefers to build in house to minimize dependency risk exposure) - I want to learn how that stuff works - I am working on new technology that does not fit cleanly into the prescribed mold of the high level implementations
- pdimitar 5y ago
  RE: your second point, it can easily be covered by a declarative DSL with a few conditions (in macros / code generating constructs). Example: in Elixir you have the so-called streaming functions you can pipe to each other that can do e.g. filtering, mapping, chunking and what not. But they don't actually operate on the data you passed them; they generate further functions and produce chains that only start working when you put a certain command at the end of the command pipe. This works really well if you work with a collection of 100_000 elements. Since Elixir is an FP language, you don't want to copy this huge list, say, 7 times one after another (assuming your transformation pipe has 7 stages). By using the streaming functions you only use the original list and produce a final list. Just one roundtrip to the memory. But... it has a performance impact and it's definitely not worth doing if your collections are e.g. less than 1000 elements, maybe even 2000. A declarative DSL can easily cover for such cases and have separate code branches addressing them. RE: tinkering, obviously. I am not saying normal programming should be "banned". But it's about time we have higher-order programming, man. We're all collectively slacking off on that and should be really ashamed! The rest of your points I don't see how to automate and that's OK. Like any tool, declarative programming should be used sparingly and only where it truly applies.

TheMonarchist 5y ago

> I want to be able to say "I want to open a huge file with scatter-gather mechanics and with these 3 functions piped that do mapping and reduction". IME C++ templates and generic programming help with that aim.

pdimitar 5y ago
Very far from it. I get what you're saying but it's not even close IMO.

selestify 5y ago

> Various people and organizations are doing it here and there and to me they are the beacons of our future hope. Who are these people and organizations?

pdimitar 5y ago
You can join me in a mourning session because when I stumbled upon them years ago I never took the effort of so much even writing down their names so now it's a blank stare from me, sorry... :(

cle 5y ago

I would consider coding these things by hand in the following non-exhaustive cases: - I am writing the thing you are asking someone to write - I have performance/memory constraints that existing high-level abstractions can’t adequately deal with - I have legal or other business constraints preventing me from using existing high level tools (eg company prefers to build in house to minimize dependency risk exposure) - I want to learn how that stuff works - I am working on new technology that does not fit cleanly into the prescribed mold of the high level implementations

pdimitar 5y ago
RE: your second point, it can easily be covered by a declarative DSL with a few conditions (in macros / code generating constructs). Example: in Elixir you have the so-called streaming functions you can pipe to each other that can do e.g. filtering, mapping, chunking and what not. But they don't actually operate on the data you passed them; they generate further functions and produce chains that only start working when you put a certain command at the end of the command pipe. This works really well if you work with a collection of 100_000 elements. Since Elixir is an FP language, you don't want to copy this huge list, say, 7 times one after another (assuming your transformation pipe has 7 stages). By using the streaming functions you only use the original list and produce a final list. Just one roundtrip to the memory. But... it has a performance impact and it's definitely not worth doing if your collections are e.g. less than 1000 elements, maybe even 2000. A declarative DSL can easily cover for such cases and have separate code branches addressing them. RE: tinkering, obviously. I am not saying normal programming should be "banned". But it's about time we have higher-order programming, man. We're all collectively slacking off on that and should be really ashamed! The rest of your points I don't see how to automate and that's OK. Like any tool, declarative programming should be used sparingly and only where it truly applies.