3 ms·

It is true that there is a a correlation between lower level programming and better programming in general. You probably won't see someone writing asm but crea

It is true that there is a a correlation between lower level programming and better programming in general. You probably won't see someone writing asm but creating crazy O^2 algorithms that run on every frame with memory allocations that run in the inner loop. At the same time a native win32 program can pack significant functionality into a 20KB exe. Put these together and you have a program where everything is instant, all the time on any computer. The original uTorrent was just over 100KB and installed then ran in an instant. These two refinements together are such a massive difference from any electron program that it melts my brain when people say that it isn't a problem to have a chat program feel like using windows 95 on a 386. People say talk about needing cross platform programs, but something like fltk has everything most people will need and also runs instantly, while adding only a few hundred kilobytes to an executable.

ghettoimp 6y ago
I strongly disagree with the idea that lower level is better. Yes, lower-level languages allow for programs with good performance, small executables, and so forth. There are many domains where they are clearly the way to go. But higher-level languages allow for better safety, tremendous productivity, portability, exploration, and flexibility. If you keep your data in an SQL database and you can easily query and update it in any number of ways that you didn't initially realize you wanted. If you instead keep it in hand-crafted C structs, you can probably provide awesome performance. for whatever you originally thought you needed. Once your needs go outside of that box, you'll have to spend significant development effort. The correct choice depends almost entirely on the domain.
- hootbootscoot 6y ago
  How about "being aware of what your abstraction layers cost, and being palpably aware of every needless contortion you create" know what everything does. call if from up on high? fine, but only if you literally can trace that high level call down to the machine code it emits :D C compiler suites can do that no problem "gcc -S mycode.c" For an appropriate dose of humility, so that you know that I'm not elevating myself here, but pointing out reality, check out GCC or LLVM source code. Something like Lua or Berkeley DB can be defined inside your program in a matter of a few hundred lines of included library code, but what does it DO? Bringing SQL and a database on board is rather odd for a desktop app, wouldn't you say? Configuration should be flat files, ideally, or managed via the apps gui, in which case an embedded database like Berkeley DB is usually more relevant. Your mention of SQL smacks of "all things are nails, always use hammers", to me at least. Have you worked with the actual computer itself in any capacity? I mean ASM, C, C++, etc, but essentially being aware of what an ABI is, what types actually are (memory shape patterns so we can define physical memory in terms of our data structures) Javascript is not computer programming, but rather programming the browser, or it's disembodied transplanted javascript engine. the animal is completely different from physical memory and actual instructions. Computers essentially manipulate memory structures. The further away from this you get, the more likely that your abstractions will be leaky, not fit what computers are actually DOING with your data, and this results in beautiful script driving janky machine code. Seriously, while we all like to pretend that everyone is equally special, let's recall that someone is a VBscript for Word expert, and that this is basically a virtual machine that itself is just defined inside someone elses program. Technological stacks are defined in terms of semi-arbitrary made-up things other people made-up and that you just need to know how to use.
  - com2kid 6y ago
    Sqlite is inanely well tested, incredibly lightweight, and will be more reliable than the vast vast majority of flat file configuration systems.
    - hootbootscoot 6y ago
      Ummm Context here is "desktop software" configuration management will be key-value and you needn't bring SQL in for that purpose. Let's not bring "in-house web app" into the picture just yet.
  - ghettoimp 6y ago
    The "all things are nails, always use hammers" mentality is almost explicitly what I am arguing against. My mention of SQL was particularly deliberate. It's an especially successful high level declarative language with clear semantics. Implementations provide sophisticated execution engines for optimizing and efficiently running queries. It is quite a lovely separation of concerns that gives you great flexibility and good performance. Obviously SQL would be a disastrous choice for, say, storing the pixel data in your video codec. Meanwhile, hand-coded C data structures and algorithms would be a disastrous choice for an inventory management system. Tradeoffs everywhere.
    - hootbootscoot 6y ago
      agreed. a well DESIGNED technological stack WILL allow for high-level control of low-level structures. Electron and Browser-based apps make a deliberate tradeoff that may be suitable for some kinds of apps (Balena Etcher, as I mentioned. You click a button and some process starts and alerts you when it's done.) I would simply say that the OP should reverse the question: "in which cases can an electron app suffice for a desktop application" and not presume the death of desktop apps.
- BubRoss 6y ago
  You are arguing against a point I didn't make. I'm not trying to rehash nonsense language arguments. I'm saying that many times the easy electron route is also correlated with programming that gives poor performance even outside of electron functions.
usrusr 6y ago
Not sure that I entirely agree there: I could easily imagine someone writing too close to the metal to stick to list iteration where a hash would be better and so on, unless it's prohibitively slower, whereas someone slightly higher would freely choose whatever they feel appropriate for the situation. They might often guess wrong and take a structure that is overkill for the typical dataset but the penalty for that will be negligible compared to the one paid for using a badly scaling structure on way too much data.
dkarl 6y ago
> You probably won't see someone writing asm but creating crazy O^2 algorithms I watched a lecture by Bjarne Stroustrup that he gave to undergraduate CS majors at Texas A&M where he coded a solution to a problem using linear scans and then a "better" solution using better algorithms with better big O performance. Then he did something interesting. He did a test on a tiny data set to demonstrate that the solution with linear scans was faster, and he asked the audience to guess at what data size the more efficient algorithms would start to beat the linear scan. After the audience members threw out a wide range of guesses he confessed that he didn't know. He had tried to test it that afternoon, but the linear scans outperformed the "better" algorithms on any data set that he could allocate memory for on his laptop. IIRC he finished by telling them that professionals often do performance optimization the opposite of how the books present it. Using an algorithm with optimal big-O scaling isn't the optimized solution. It's the safe answer that you start with if you aren't bothering to optimize. When you need better performance, you evaluate your algorithms using real data and real machines and qualify your evaluations based on the characteristics (size, etc.) of the data.
- BubRoss 6y ago
  You are focusing on an example and conflating it with the actual point that I'm making, which is that electron is not only slow, but compounded by slow programming in top. That being said... I know exactly what you are talking about and it was always strange to me, because it was actually iterating through every time to find a value first, so the iteration through the linked list would always kill the performance. Even so, basic linked lists are practically obsolete. This is not a good example of algorithmic complexity, because the complexities were actually the same.

ghettoimp 6y ago

I strongly disagree with the idea that lower level is better. Yes, lower-level languages allow for programs with good performance, small executables, and so forth. There are many domains where they are clearly the way to go. But higher-level languages allow for better safety, tremendous productivity, portability, exploration, and flexibility. If you keep your data in an SQL database and you can easily query and update it in any number of ways that you didn't initially realize you wanted. If you instead keep it in hand-crafted C structs, you can probably provide awesome performance. for whatever you originally thought you needed. Once your needs go outside of that box, you'll have to spend significant development effort. The correct choice depends almost entirely on the domain.

hootbootscoot 6y ago
How about "being aware of what your abstraction layers cost, and being palpably aware of every needless contortion you create" know what everything does. call if from up on high? fine, but only if you literally can trace that high level call down to the machine code it emits :D C compiler suites can do that no problem "gcc -S mycode.c" For an appropriate dose of humility, so that you know that I'm not elevating myself here, but pointing out reality, check out GCC or LLVM source code. Something like Lua or Berkeley DB can be defined inside your program in a matter of a few hundred lines of included library code, but what does it DO? Bringing SQL and a database on board is rather odd for a desktop app, wouldn't you say? Configuration should be flat files, ideally, or managed via the apps gui, in which case an embedded database like Berkeley DB is usually more relevant. Your mention of SQL smacks of "all things are nails, always use hammers", to me at least. Have you worked with the actual computer itself in any capacity? I mean ASM, C, C++, etc, but essentially being aware of what an ABI is, what types actually are (memory shape patterns so we can define physical memory in terms of our data structures) Javascript is not computer programming, but rather programming the browser, or it's disembodied transplanted javascript engine. the animal is completely different from physical memory and actual instructions. Computers essentially manipulate memory structures. The further away from this you get, the more likely that your abstractions will be leaky, not fit what computers are actually DOING with your data, and this results in beautiful script driving janky machine code. Seriously, while we all like to pretend that everyone is equally special, let's recall that someone is a VBscript for Word expert, and that this is basically a virtual machine that itself is just defined inside someone elses program. Technological stacks are defined in terms of semi-arbitrary made-up things other people made-up and that you just need to know how to use.
- com2kid 6y ago
  Sqlite is inanely well tested, incredibly lightweight, and will be more reliable than the vast vast majority of flat file configuration systems.
  - hootbootscoot 6y ago
    Ummm Context here is "desktop software" configuration management will be key-value and you needn't bring SQL in for that purpose. Let's not bring "in-house web app" into the picture just yet.
- ghettoimp 6y ago
  The "all things are nails, always use hammers" mentality is almost explicitly what I am arguing against. My mention of SQL was particularly deliberate. It's an especially successful high level declarative language with clear semantics. Implementations provide sophisticated execution engines for optimizing and efficiently running queries. It is quite a lovely separation of concerns that gives you great flexibility and good performance. Obviously SQL would be a disastrous choice for, say, storing the pixel data in your video codec. Meanwhile, hand-coded C data structures and algorithms would be a disastrous choice for an inventory management system. Tradeoffs everywhere.
  - hootbootscoot 6y ago
    agreed. a well DESIGNED technological stack WILL allow for high-level control of low-level structures. Electron and Browser-based apps make a deliberate tradeoff that may be suitable for some kinds of apps (Balena Etcher, as I mentioned. You click a button and some process starts and alerts you when it's done.) I would simply say that the OP should reverse the question: "in which cases can an electron app suffice for a desktop application" and not presume the death of desktop apps.
BubRoss 6y ago
You are arguing against a point I didn't make. I'm not trying to rehash nonsense language arguments. I'm saying that many times the easy electron route is also correlated with programming that gives poor performance even outside of electron functions.

usrusr 6y ago

Not sure that I entirely agree there: I could easily imagine someone writing too close to the metal to stick to list iteration where a hash would be better and so on, unless it's prohibitively slower, whereas someone slightly higher would freely choose whatever they feel appropriate for the situation. They might often guess wrong and take a structure that is overkill for the typical dataset but the penalty for that will be negligible compared to the one paid for using a badly scaling structure on way too much data.

dkarl 6y ago

> You probably won't see someone writing asm but creating crazy O^2 algorithms I watched a lecture by Bjarne Stroustrup that he gave to undergraduate CS majors at Texas A&M where he coded a solution to a problem using linear scans and then a "better" solution using better algorithms with better big O performance. Then he did something interesting. He did a test on a tiny data set to demonstrate that the solution with linear scans was faster, and he asked the audience to guess at what data size the more efficient algorithms would start to beat the linear scan. After the audience members threw out a wide range of guesses he confessed that he didn't know. He had tried to test it that afternoon, but the linear scans outperformed the "better" algorithms on any data set that he could allocate memory for on his laptop. IIRC he finished by telling them that professionals often do performance optimization the opposite of how the books present it. Using an algorithm with optimal big-O scaling isn't the optimized solution. It's the safe answer that you start with if you aren't bothering to optimize. When you need better performance, you evaluate your algorithms using real data and real machines and qualify your evaluations based on the characteristics (size, etc.) of the data.

BubRoss 6y ago
You are focusing on an example and conflating it with the actual point that I'm making, which is that electron is not only slow, but compounded by slow programming in top. That being said... I know exactly what you are talking about and it was always strange to me, because it was actually iterating through every time to find a value first, so the iteration through the linked list would always kill the performance. Even so, basic linked lists are practically obsolete. This is not a good example of algorithmic complexity, because the complexities were actually the same.