6 ms·

Maybe we should drop the idealism and be realistic: for various reasons bloatware is not going away. If we were to admit something like that, the next question

Maybe we should drop the idealism and be realistic: for various reasons bloatware is not going away. If we were to admit something like that, the next question is what can be done? We need better tooling for generating and reasoning about software manifests and supply chains, and we need better tooling and training for at least lightweight formal methods in design / development phases. Industry adoption of such things is not impossible but it needs to be more accessible to devs without phds and it needs to be faster/cheaper.

SilentM68 3y ago
Unfortunately, bloatware is the reality and that is depressing :( I wish things were like the 90s and software dev environments like Rebol [ http://www.rebol.com http://www.rebol.com ] were still king. It was simple to use, small executables, expressive, but no longer maintained :(
- brabel 3y ago
  There's a descendant of Rebol that is maintained: https://www.red-lang.org/ https://www.red-lang.org/
  - SilentM68 3y ago
    Yes, I was aware of RED since it was proposed but I have not checked its progress to see how it has evolved.
  - pbronez 3y ago
    Red looks pretty cool. Will try it out once they reach 1.0!
anta40 3y ago
>> the next question is what can be done? Minimize the usage of JS-based libs/tools, perhaps? Yes, I'm looking my daily tools like VSCode, Postman etc which are Electron-based. Perhaps rewriting it into Go/C++/Pascal could shrink the bloat.
palata 3y ago
> We need better tooling It's not always that we need better tooling. Here I think we need better developers, as in "developers who care about this issue". Developers are the ones including the bloat, right? If all the developers started working slower but including less bloat, what would the managers do? Probably the managers have no clue about the complexity of what their devs do: they just compare the tasks with t-shirt sizes (with estimations that are generally completely wrong, but they still use them). The problem is that if one developer works slowly writing less bloated code, and their 3 coworkers keep adding bloat, then not only it's still getting bloated, but the first dev appears to be less productive. It's a kind of competition between developers, where those who do the better job lose.
- photonthug 3y ago
  Bloat is the only endgame as capabilities and complexity increase, so tooling is the only answer. Stacks on stacks of software with millions of lines is the present and the future, so we have to get used to it, because it happens in a world with perfect developers Or in a world without whatever problem languages etc.
  - palata 3y ago
    I won't answer to that because we'll end up in an infinite loop, but I kindly disagree :-).

SilentM68 3y ago

Unfortunately, bloatware is the reality and that is depressing :( I wish things were like the 90s and software dev environments like Rebol [ http://www.rebol.com http://www.rebol.com ] were still king. It was simple to use, small executables, expressive, but no longer maintained :(

brabel 3y ago
There's a descendant of Rebol that is maintained: https://www.red-lang.org/ https://www.red-lang.org/
- SilentM68 3y ago
  Yes, I was aware of RED since it was proposed but I have not checked its progress to see how it has evolved.
- pbronez 3y ago
  Red looks pretty cool. Will try it out once they reach 1.0!

anta40 3y ago

>> the next question is what can be done? Minimize the usage of JS-based libs/tools, perhaps? Yes, I'm looking my daily tools like VSCode, Postman etc which are Electron-based. Perhaps rewriting it into Go/C++/Pascal could shrink the bloat.

palata 3y ago

> We need better tooling It's not always that we need better tooling. Here I think we need better developers, as in "developers who care about this issue". Developers are the ones including the bloat, right? If all the developers started working slower but including less bloat, what would the managers do? Probably the managers have no clue about the complexity of what their devs do: they just compare the tasks with t-shirt sizes (with estimations that are generally completely wrong, but they still use them). The problem is that if one developer works slowly writing less bloated code, and their 3 coworkers keep adding bloat, then not only it's still getting bloated, but the first dev appears to be less productive. It's a kind of competition between developers, where those who do the better job lose.

photonthug 3y ago
Bloat is the only endgame as capabilities and complexity increase, so tooling is the only answer. Stacks on stacks of software with millions of lines is the present and the future, so we have to get used to it, because it happens in a world with perfect developers Or in a world without whatever problem languages etc.
- palata 3y ago
  I won't answer to that because we'll end up in an infinite loop, but I kindly disagree :-).