Author Topic: food for thought: code bloat  (Read 15766 times)

0 Members and 2 Guests are viewing this topic.

Offline bd139

  • Super Contributor
  • ***
  • Posts: 23033
  • Country: gb
Re: food for thought: code bloat
« Reply #50 on: July 17, 2022, 09:20:27 pm »
Legacy supoort, web frameworks and so on. Not reinventing the wheel and not wanting to remove any existing wheels.
Worst company for bloatware is Microsoft.
They build so many layers to software and that its almost impossible to copy or replace.
Windows, .net framework, .net core, WPF, Winforms etc etc

That’s all the good stuff.

If you want to poke something start with Teams and look at all the shit they are building on top of layers of shit in typescript. The next major version of office is in typescript and electron.
 

Offline YurkshireLad

  • Frequent Contributor
  • **
  • Posts: 365
  • Country: ca
Re: food for thought: code bloat
« Reply #51 on: July 17, 2022, 10:10:45 pm »
Legacy supoort, web frameworks and so on. Not reinventing the wheel and not wanting to remove any existing wheels.
Worst company for bloatware is Microsoft.
They build so many layers to software and that its almost impossible to copy or replace.
Windows, .net framework, .net core, WPF, Winforms etc etc

That’s all the good stuff.

If you want to poke something start with Teams and look at all the shit they are building on top of layers of shit in typescript. The next major version of office is in typescript and electron.


Ugh, Teams is like a fatberg you find stuck in a sewer. Bloated, ugly and no use to anyone.
 
The following users thanked this post: bd139

Online SiliconWizard

  • Super Contributor
  • ***
  • Posts: 14490
  • Country: fr
Re: food for thought: code bloat
« Reply #52 on: July 17, 2022, 10:17:59 pm »
isn't VSCode  mostly TypeScript as well? :popcorn:
 

Offline bd139

  • Super Contributor
  • ***
  • Posts: 23033
  • Country: gb
Re: food for thought: code bloat
« Reply #53 on: July 18, 2022, 07:16:00 am »
Yep and it’s getting worse each release. Half the ancillary crap that runs behind the scenes and the remote host for remote machines eat a ton of RAM and resources. I’ve dumped it and gone back to vim recently.
 

Offline tellurium

  • Regular Contributor
  • *
  • Posts: 232
  • Country: ua
Re: food for thought: code bloat
« Reply #54 on: July 18, 2022, 04:51:12 pm »
Yep and it’s getting worse each release. Half the ancillary crap that runs behind the scenes and the remote host for remote machines eat a ton of RAM and resources. I’ve dumped it and gone back to vim recently.

Likewise. I try a couple of editors every year for the last 20 years, and always go back to vim.

The nice feature of vscode / sublime I've missed was multiple selection with Ctrl-D then simultaneous edit. Useful for quick renames / refactorings. Though, vim's search + cgn + replacement + .   does the same thing, as I've found out.
Open source embedded network library https://mongoose.ws
TCP/IP stack + TLS1.3 + HTTP/WebSocket/MQTT in a single file
 

Offline bd139

  • Super Contributor
  • ***
  • Posts: 23033
  • Country: gb
Re: food for thought: code bloat
« Reply #55 on: July 18, 2022, 04:58:47 pm »
I tend to use
Code: [Select]
:%s/foo/bar/g for that.
 

Online SiliconWizard

  • Super Contributor
  • ***
  • Posts: 14490
  • Country: fr
Re: food for thought: code bloat
« Reply #56 on: July 18, 2022, 05:57:37 pm »
Yep and it’s getting worse each release. Half the ancillary crap that runs behind the scenes and the remote host for remote machines eat a ton of RAM and resources. I’ve dumped it and gone back to vim recently.

I've never used it. ;D
Well, I have tried VSCodium (which is VSCode without telemetry) and was unimpressed. It's slowish, eats up a lot of RAM and I don't like the text editor part itself much (at least compared to what I'm used to.)
The only thing it has going for it is the extension system and the amount of extensions. Which makes it look like any popular software: it is popular because it is popular (so sure the ecosystem grows exponentially). Not because it's particularly good.

The only occasional use I make of it is to edit markdown files. It has an extension for previewing the result, which is handy. If you can point me to a markdown viewer that is not web-based and that works well, I'll be glad to switch!

« Last Edit: July 18, 2022, 05:59:24 pm by SiliconWizard »
 

Offline bd139

  • Super Contributor
  • ***
  • Posts: 23033
  • Country: gb
Re: food for thought: code bloat
« Reply #57 on: July 18, 2022, 06:18:53 pm »
Yea I was using it for markdown as well to maintain internal documentation in GitHub.

I just use plain text files now
 

Offline Berni

  • Super Contributor
  • ***
  • Posts: 4957
  • Country: si
Re: food for thought: code bloat
« Reply #58 on: July 19, 2022, 05:28:29 am »
The reason that VSCode, VisualStudio, Sublime..etc use so much more resources is also due to the extensive autocomplete functionality they have.

They are basically halfway compiling the code in the background as you type, so it understands what you are referencing in the code and only suggests valid things about that item. This means it has to hold an up to date picture of what every namespace,class,structure..etc looks like in not only your code but also whatever is is exposed by the included libraries.

I personally like code editors that provide good autocomplete and Microsofts Intelisense does a rather good job. These autocomplete features help make me more productive by not making me remember the exact name of everything in my code and saves time with me having to look up what a structure contains or getting it wrong and finding out the name typo at compile time. This is especially true when using outside libraries that i never used before and don't know any of the functions from by head (the whole function prototype appears right there as i type it). Since you can just hit a key and have it autocomplete for you also speeds up typing, reduces chances of a typo and removes the discouragement of using longer names. At the end of the day it helps me get my coding done faster. Computers are better at remembering things than i am. If this comes at a cost of a gig or two of memory so be it, my machine has 32GB.

Could these features be implemented in a more optimized resource efficient way? Yes they certainly could. But until someone actually does it this is the best we got. But you will always have those Arch linux users rocking there good'ol vim on there trusty IBM Thinkpad from 2005
 

Offline bd139

  • Super Contributor
  • ***
  • Posts: 23033
  • Country: gb
Re: food for thought: code bloat
« Reply #59 on: July 19, 2022, 08:02:21 am »
I used to have working autocomplete on a 512MB machine. There is no reason for it to be as painfully large as it is now.
 

Offline tggzzz

  • Super Contributor
  • ***
  • Posts: 19522
  • Country: gb
  • Numbers, not adjectives
    • Having fun doing more, with less
Re: food for thought: code bloat
« Reply #60 on: July 19, 2022, 10:50:02 am »
I personally like code editors that provide good autocomplete and Microsofts Intelisense does a rather good job. These autocomplete features help make me more productive by not making me remember the exact name of everything in my code and saves time with me having to look up what a structure contains or getting it wrong and finding out the name typo at compile time. This is especially true when using outside libraries that i never used before and don't know any of the functions from by head (the whole function prototype appears right there as i type it). Since you can just hit a key and have it autocomplete for you also speeds up typing, reduces chances of a typo and removes the discouragement of using longer names. At the end of the day it helps me get my coding done faster. Computers are better at remembering things than i am. If this comes at a cost of a gig or two of memory so be it, my machine has 32GB.

Just so.

But it also needs the right language. Good luck with autocompletion with, for example, Forth or Lisp!

Autocompletion has one other virtue that newbies don't understand. Too often you see statements to the effect that "language X requires s too much typing" and that my language is better because it uses duck-typing. Autocompletion removes the "problem" of too much typing. (Personally I'd rather the compiler told me I'm wrong, rather than have a run-time error.)
There are lies, damned lies, statistics - and ADC/DAC specs.
Glider pilot's aphorism: "there is no substitute for span". Retort: "There is a substitute: skill+imagination. But you can buy span".
Having fun doing more, with less
 

Offline Berni

  • Super Contributor
  • ***
  • Posts: 4957
  • Country: si
Re: food for thought: code bloat
« Reply #61 on: July 19, 2022, 04:38:10 pm »
Just so.

But it also needs the right language. Good luck with autocompletion with, for example, Forth or Lisp!

Autocompletion has one other virtue that newbies don't understand. Too often you see statements to the effect that "language X requires s too much typing" and that my language is better because it uses duck-typing. Autocompletion removes the "problem" of too much typing. (Personally I'd rather the compiler told me I'm wrong, rather than have a run-time error.)

Yep this sort of functionality needs a lot of effort to implement than just syntax highlighting. But i tend to end up using the more popular languages so they are usually supported(C, C#, Python etc..). I don't tend to learn new languages until i find something that my existing set of languages doesn't do well.

If strong typing or dynamic typing is better is a topic for another day. My own preference is to have types defined wherever possible. I even use type hinting in Python just so that the IDE can warn me when i try to stuff something into the wrong spot. Even tho the Python language tends to be designed to not give a damn about data types. The autocomplete feature of the PyCharm IDE even tries to be helpful even without type hints by tracking the movement of data trough the code, so that it can do a best guess about the data type, or when accessing the members of a object in the code it assumes the member is part of the object and suggests it for autocomplete (even tho it has no idea what kind of object it is actually dealing with). So it still kinda works but nowhere near as well as in strong typing.

I do admit the strong typing of VHDL did feel annoying to me, always tended to prefer Verilog instead. But both of those languages are pretty terrible and i never found any decent IDE for them. But i just deal with it for when i want to do stuff with FPGAs
 

Online SiliconWizard

  • Super Contributor
  • ***
  • Posts: 14490
  • Country: fr
Re: food for thought: code bloat
« Reply #62 on: July 19, 2022, 06:54:40 pm »
autocomplete crap freaking annoys me to no end, so that's definitely not for me. I don't need
Give me good syntax highlighting, and sensible auto-indentation (which VSCode doesn't have IMHO, but that will of course be highly subjective).

As to a language needing "too much typing"? As I say on a regular basis, if, when developing software, the amount of typing needed takes any significant amount of time/energy compared to the design effort, then you're either writing trivial stuff or you're doing something really wrong. Just my 2 cents. :popcorn:
 

Offline bd139

  • Super Contributor
  • ***
  • Posts: 23033
  • Country: gb
Re: food for thought: code bloat
« Reply #63 on: July 19, 2022, 06:58:25 pm »
That’s where YAML needs to fuck off and die  :-DD
 

Online SiliconWizard

  • Super Contributor
  • ***
  • Posts: 14490
  • Country: fr
Re: food for thought: code bloat
« Reply #64 on: July 19, 2022, 07:10:32 pm »
I don't particularly care for YAML, there are better structured formats out there. ;D
 

Offline bd139

  • Super Contributor
  • ***
  • Posts: 23033
  • Country: gb
Re: food for thought: code bloat
« Reply #65 on: July 19, 2022, 07:30:26 pm »
There are indeed.

My pet pieve is templated YAML which is just pain and a definite incarnation of Greenspun’s Tenth Rule. Helm I’m looking at you there.
 

Offline tggzzz

  • Super Contributor
  • ***
  • Posts: 19522
  • Country: gb
  • Numbers, not adjectives
    • Having fun doing more, with less
Re: food for thought: code bloat
« Reply #66 on: July 19, 2022, 08:33:49 pm »
autocomplete crap freaking annoys me to no end, so that's definitely not for me. I don't need
Give me good syntax highlighting, and sensible auto-indentation (which VSCode doesn't have IMHO, but that will of course be highly subjective).

I've not used VSCode, and I hate DWIM for the reasons that have been articulated shortly after it was first implemented. And recapitulated every day by android spelling chucker/corrupters.

Nonetheless, with the right language, and probably a good editor/IDE, giving the coder instant feedback on the set of possible completions at this point in the code, it can be available assistant.

But the emphasis is on "set", "instant", and "choice".

Quote
As to a language needing "too much typing"? As I say on a regular basis, if, when developing software, the amount of typing needed takes any significant amount of time/energy compared to the design effort, then you're either writing trivial stuff or you're doing something really wrong. Just my 2 cents. :popcorn:

Agreed wholeheartedly.

But those are some of the justifications (and I use that word loosely) claimed by those pushing certain language (mis)features.
There are lies, damned lies, statistics - and ADC/DAC specs.
Glider pilot's aphorism: "there is no substitute for span". Retort: "There is a substitute: skill+imagination. But you can buy span".
Having fun doing more, with less
 

Offline brucehoult

  • Super Contributor
  • ***
  • Posts: 4040
  • Country: nz
Re: food for thought: code bloat
« Reply #67 on: July 19, 2022, 10:21:14 pm »
autocomplete crap freaking annoys me to no end, so that's definitely not for me. I don't need

I *hate* things flashing up when I'm trying to think and type. If you have to hit a key to get the suggestions then fine.

As for reducing typing, emacs' M-/ command works fine for me. It searches first backwards in the current file, the from the end of the current file, and then other open files, for a word starting with the characters to the left of the cursor, and completes it. That's all you need for not repeatedly typing long and descriptive names.

Quote
Give me good syntax highlighting, and sensible auto-indentation (which VSCode doesn't have IMHO, but that will of course be highly subjective).

I'm not sure what is "good" syntax highlighting. String literals and comments different to other things maybe. I don't need my freaking editor to remind me which things are keywords and type names. I'd rather have plain black text than an editor that looks like a Fisher-Price toy.

Quote
As to a language needing "too much typing"? As I say on a regular basis, if, when developing software, the amount of typing needed takes any significant amount of time/energy compared to the design effort, then you're either writing trivial stuff or you're doing something really wrong. Just my 2 cents. :popcorn:

100%.
 

Offline tggzzz

  • Super Contributor
  • ***
  • Posts: 19522
  • Country: gb
  • Numbers, not adjectives
    • Having fun doing more, with less
Re: food for thought: code bloat
« Reply #68 on: July 19, 2022, 11:50:18 pm »
autocomplete crap freaking annoys me to no end, so that's definitely not for me. I don't need

I *hate* things flashing up when I'm trying to think and type. If you have to hit a key to get the suggestions then fine.

Agreed.

ctrl-space turning the "what legally completes this class/variable/method" mode on/off works well.

Quote
As for reducing typing, emacs' M-/ command works fine for me. It searches first backwards in the current file, the from the end of the current file, and then other open files, for a word starting with the characters to the left of the cursor, and completes it. That's all you need for not repeatedly typing long and descriptive names.

Quote
Give me good syntax highlighting, and sensible auto-indentation (which VSCode doesn't have IMHO, but that will of course be highly subjective).

I'm not sure what is "good" syntax highlighting.

Discreet, muted, and can easily be changed so it doesn't offend me nor distract me from reading the text. The "Windows3.1 16 colour palette" falls far short of that!

Quote
String literals and comments different to other things maybe. I don't need my freaking editor to remind me which things are keywords and type names. I'd rather have plain black text than an editor that looks like a Fisher-Price toy.

Quote
As to a language needing "too much typing"? As I say on a regular basis, if, when developing software, the amount of typing needed takes any significant amount of time/energy compared to the design effort, then you're either writing trivial stuff or you're doing something really wrong. Just my 2 cents. :popcorn:

100%.
There are lies, damned lies, statistics - and ADC/DAC specs.
Glider pilot's aphorism: "there is no substitute for span". Retort: "There is a substitute: skill+imagination. But you can buy span".
Having fun doing more, with less
 

Offline Nominal Animal

  • Super Contributor
  • ***
  • Posts: 6266
  • Country: fi
    • My home page and email address
Re: food for thought: code bloat
« Reply #69 on: July 20, 2022, 03:30:42 am »
I'm not sure what is "good" syntax highlighting. String literals and comments different to other things maybe. I don't need my freaking editor to remind me which things are keywords and type names. I'd rather have plain black text than an editor that looks like a Fisher-Price toy.
(I prefer gray text on black for whatever reason, and as little of the editor showing as possible; only the text I'm editing.)

I have noticed that when browsing through code new to me, syntax highlighting reduces the cognitive load: it makes it faster for me to understand the code.
When writing my own code, it's probably just eye candy.

I only use colors for highlighting, though.  (Well, with Pluma I use the defaults which does apply italics to certain parts of Doxygen comments, and only my own theme/color palette.)

One quirk in my typing is that AltGr+Space must map to plain space, and not to non-breaking space (U+00A0), because in the keyboard layout I use, { is AltGr+7, [ is AltGr+8, ] is AltGr+9, and } is AltGr+0, and those are very often followed by a space by a finger in my other hand, and I occasionally release the AltGr key too late.  I used to have to modify the layout to do this, but in Linux Mint 20.04 it was this way from the get go.

As to a language needing "too much typing"? As I say on a regular basis, if, when developing software, the amount of typing needed takes any significant amount of time/energy compared to the design effort, then you're either writing trivial stuff or you're doing something really wrong. Just my 2 cents. :popcorn:
I fully agree!  And I often refactor/rewrite my own code.
 

Offline Berni

  • Super Contributor
  • ***
  • Posts: 4957
  • Country: si
Re: food for thought: code bloat
« Reply #70 on: July 20, 2022, 05:43:52 am »
In almost all the IDEs you can set up syntax highlighting or indenting or autocomplete to work the way you like it.

Syntax highlighting is another thing that is a little productivity boost. I also don't like it when it is too colorful, so i sometimes take a bit to find a good color theme i like. But just gentle color hints around the code make it so that i don't actually need to read everything when just looking over the code. I don't need to look for where a string literal begins or ends, or when those brackets begin or end, what is part of a comment what is not. My vision has a finite amount of text bandwidth it can read, so if i can avoid wasting it to read syntax details that means there is more bandwidth left over for actually reading the code i want to read.

I know computers are better than me at doing some of these things, so i let them do those things for me so that i can focus on actually thinking about the code i want to write. Not on the typing or reading it, those are just a barrier between my brain and the source code file where i want to get my code into.

Maybe i am just really bad at reading quickly or typing quickly, so that having to do more of those slows down my process of coding. Or maybe my memory is so terrible that i can't remember enough of a libraries documentation in my head to avoid having to have to look trough it too often while i code(as this is time spent not coding). I have no idea, all i know is the modern bells and whistles make me get the job done faster in comparison to a bare bones editor.

Try using an advanced editor for a week or so on a project (to get used to the new visual queues) and then switch back to a bare editor to see the difference. It is much like how i started out using Eagle for PCB design in the old days and it was fine, now that i use AltiumDesigner going back to Eagle makes me surprised i got anything actually done in it.
 

Offline tggzzz

  • Super Contributor
  • ***
  • Posts: 19522
  • Country: gb
  • Numbers, not adjectives
    • Having fun doing more, with less
Re: food for thought: code bloat
« Reply #71 on: July 20, 2022, 09:02:38 am »
And I often refactor/rewrite my own code.

That's where a good IDE with a "compliant" language beats any simple editor.

One classic example is to see whether the tool allows you to select a block of code and refactor it into a new method.

Another is to see whether the tool can rename a method or variable, and accurately change all uses to the new name. Anybody using macros (or reflection) deserves what they get :)
« Last Edit: July 20, 2022, 09:06:18 am by tggzzz »
There are lies, damned lies, statistics - and ADC/DAC specs.
Glider pilot's aphorism: "there is no substitute for span". Retort: "There is a substitute: skill+imagination. But you can buy span".
Having fun doing more, with less
 

Offline PlainName

  • Super Contributor
  • ***
  • Posts: 6848
  • Country: va
Re: food for thought: code bloat
« Reply #72 on: July 20, 2022, 02:56:11 pm »
Quote
The only occasional use I make of it is to edit markdown files. It has an extension for previewing the result, which is handy. If you can point me to a markdown viewer that is not web-based and that works well, I'll be glad to switch!

https://typora.io/

https://github.com/marktext/marktext
 

Offline Kjelt

  • Super Contributor
  • ***
  • Posts: 6460
  • Country: nl
Re: food for thought: code bloat
« Reply #73 on: July 20, 2022, 03:20:12 pm »
Software bloat follows the hardware bloat  ;)

You can ask the same non relevant question for hardware:
In the 80's we only needed 29,000 transistors for an Intel 8088, why do we now need 57,000,000,000 transistors for a mobile M1 processor ?
How much energy can we safe if we go back to 29000 transistors and 4 bit color graphics with a 320x200 resolution ?
Who needs those 4K super real games and movies ?

Totally irrelevant questions IMO. Real software bloat are unused bytes that can be thrown out without compromising any of the end results.
No company will ever invest millions of $ for 20-30% in code reduction, they invest in the next thing. Why ? Because new things have a ROI, while code reductions and cleaning only costs money.

https://en.wikipedia.org/wiki/Transistor_count
 

Offline madiresTopic starter

  • Super Contributor
  • ***
  • Posts: 7770
  • Country: de
  • A qualified hobbyist ;)
Re: food for thought: code bloat
« Reply #74 on: July 20, 2022, 04:27:02 pm »
And companies writing software don't care about code bloat since the customer has to pay for the faster PC needed. Hopefully this will change with rising energy costs. And software has a CO2 footprint too.
 


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf