4 ms·

I'm pretty sure Delphi also didn't have the same level of code navigation and inspections across the entire codebase (including resources, even from 3rd party l

I'm pretty sure Delphi also didn't have the same level of code navigation and inspections across the entire codebase (including resources, even from 3rd party libraries), or a built-in CPU/memory/network/energy profiler of the same quality, or layout previews that actually reflect the written code. Android Studio is still slow even by today's standards, but that is not an apples-to-apples comparison. There are also some ways to make incremental debug builds faster (can be brought down to a few seconds for smaller changes, gradle can show which step takes how long).

jfkebwjsbx 6y ago
We have 3 orders of magnitude more computational resources than back then... There is something very wrong with IDEs and complex applications these days.
- realharo 6y ago
  The same can be said about just about any software (plus again, AS is an exception, a typical IDE doesn't use anywhere near that much RAM - only few hundred MB to low GBs). Everything is bigger these days - web browsers show bigger web pages, photo editing software deals with much larger photos, etc. Today's cars and planes are also much more complex than the cars and planes from 100 years ago. What it comes down to is, are the extra features provided by today's tools worth it? For most people, that's a no brainer. As a random example, take auto import suggestions. I can start typing 3 or 4 letters, and get a suggestion for a function name to call (and it's not just prefix search either, it is aware of words, etc.), then I just hit enter, and the function call is added to my code, plus the import statement is seamlessly added to the top of the file. I can see that function's documentation right then and there, navigate to its implementation and its usages inside a 3rd party library or just in my project, I get an immediate warning if I use it wrong or make a common mistake, etc. Then you have languages like TypeScript that automatically narrow variable types based on the checks you perform around them. So if you have `if (user === undefined) { return }`, then it knows that below that block, `user` is definitely not `undefined` and the error reporting and autocomplete reflects that and doesn't complain. If you later remove that check, you'll immediately see red squiggly lines on code below it that broke because it can no longer rely on that assumption. All of this requires having the code of my project and all of its dependencies indexed into a pretty verbose structure, but the productivity and reliability gains are 100% worth the extra bit of RAM and CPU time it takes - that's what it's there for.
  - IggleSniggle 6y ago
    I love TypeScript. But let's not use it to excuse our present situation. OCaml shares many properties with TypeScript, especially when TypeScript is used in a functional way with inferred types propagating through the system. And the tooling for OCaml has run for a long time on vastly less powerful machines. Just yesterday, VSCode had a UI lock for a good 5-10 seconds in a pretty small typescript project. It easily could have been some extension I had installed somewhere. But our current ecosystem solves for the combination of satisfying business managers (fast iteration) and developer enjoyment over producing long term stable and reliable programs that can run on minimal hardware.
  - mceachen 6y ago
    At the same time, I had typeahead find and completion for method and variable names back in the 90s with vi/emacs and exuberant ctags. It didn't need that much cpu or ram mojo. We tend to use whatever is available.
  - jfkebwjsbx 6y ago
    We were talking about code and IDEs, not media files. Code completion, GUI designers and all sorts of fancy features already existed in IDEs 20 years ago. You claim you have gained productivity, but coding a business app as a webpage or as an Electron app is not any faster than making it in VB6 or Delphi was. And the language were designed designed than JavaScript.
    - realharo 6y ago
      "Code completion" can mean many different things, from very basic features to more advanced ones. Many "lightweight" tools I've seen lack the more useful parts and offer only really basic completion. For example if a function in a library I'm using is called `createUserWithSubscription`, and I start typing `usersub` anywhere in the project, it should offer that function near or at the top of the suggestion list, even if its location is not already imported/included in my current file. Things like that have a huge impact on easy discoverability of a library's functionality, which in turn has a huge impact on productivity and speed of adopting new technology. If I just press Ctrl+space while the cursor is inside a function call, without typing anything, it should offer suggestions based on what other code passes into that function, or suggestions based on the type of the argument, etc. I don't recall these things from 20 years ago. And that is still just one of the features. >coding a business app as a webpage or as an Electron app is not any faster than making it in VB6 or Delphi was I would say it is. Of course the apps made today are very different from the apps back then, but making UI that displays data is much easier.
rs23296008n1 6y ago
Pretty sure it does. Delphi can be used to build its own components and the inspectors will pick up properties etc automatically. Compile time is a lot faster as well. Creating GUIs, including resizeable windows and controls was not only possible but relatively easy.

jfkebwjsbx 6y ago

We have 3 orders of magnitude more computational resources than back then... There is something very wrong with IDEs and complex applications these days.

realharo 6y ago
The same can be said about just about any software (plus again, AS is an exception, a typical IDE doesn't use anywhere near that much RAM - only few hundred MB to low GBs). Everything is bigger these days - web browsers show bigger web pages, photo editing software deals with much larger photos, etc. Today's cars and planes are also much more complex than the cars and planes from 100 years ago. What it comes down to is, are the extra features provided by today's tools worth it? For most people, that's a no brainer. As a random example, take auto import suggestions. I can start typing 3 or 4 letters, and get a suggestion for a function name to call (and it's not just prefix search either, it is aware of words, etc.), then I just hit enter, and the function call is added to my code, plus the import statement is seamlessly added to the top of the file. I can see that function's documentation right then and there, navigate to its implementation and its usages inside a 3rd party library or just in my project, I get an immediate warning if I use it wrong or make a common mistake, etc. Then you have languages like TypeScript that automatically narrow variable types based on the checks you perform around them. So if you have `if (user === undefined) { return }`, then it knows that below that block, `user` is definitely not `undefined` and the error reporting and autocomplete reflects that and doesn't complain. If you later remove that check, you'll immediately see red squiggly lines on code below it that broke because it can no longer rely on that assumption. All of this requires having the code of my project and all of its dependencies indexed into a pretty verbose structure, but the productivity and reliability gains are 100% worth the extra bit of RAM and CPU time it takes - that's what it's there for.
- IggleSniggle 6y ago
  I love TypeScript. But let's not use it to excuse our present situation. OCaml shares many properties with TypeScript, especially when TypeScript is used in a functional way with inferred types propagating through the system. And the tooling for OCaml has run for a long time on vastly less powerful machines. Just yesterday, VSCode had a UI lock for a good 5-10 seconds in a pretty small typescript project. It easily could have been some extension I had installed somewhere. But our current ecosystem solves for the combination of satisfying business managers (fast iteration) and developer enjoyment over producing long term stable and reliable programs that can run on minimal hardware.
- mceachen 6y ago
  At the same time, I had typeahead find and completion for method and variable names back in the 90s with vi/emacs and exuberant ctags. It didn't need that much cpu or ram mojo. We tend to use whatever is available.
- jfkebwjsbx 6y ago
  We were talking about code and IDEs, not media files. Code completion, GUI designers and all sorts of fancy features already existed in IDEs 20 years ago. You claim you have gained productivity, but coding a business app as a webpage or as an Electron app is not any faster than making it in VB6 or Delphi was. And the language were designed designed than JavaScript.
  - realharo 6y ago
    "Code completion" can mean many different things, from very basic features to more advanced ones. Many "lightweight" tools I've seen lack the more useful parts and offer only really basic completion. For example if a function in a library I'm using is called `createUserWithSubscription`, and I start typing `usersub` anywhere in the project, it should offer that function near or at the top of the suggestion list, even if its location is not already imported/included in my current file. Things like that have a huge impact on easy discoverability of a library's functionality, which in turn has a huge impact on productivity and speed of adopting new technology. If I just press Ctrl+space while the cursor is inside a function call, without typing anything, it should offer suggestions based on what other code passes into that function, or suggestions based on the type of the argument, etc. I don't recall these things from 20 years ago. And that is still just one of the features. >coding a business app as a webpage or as an Electron app is not any faster than making it in VB6 or Delphi was I would say it is. Of course the apps made today are very different from the apps back then, but making UI that displays data is much easier.

rs23296008n1 6y ago

Pretty sure it does. Delphi can be used to build its own components and the inspectors will pick up properties etc automatically. Compile time is a lot faster as well. Creating GUIs, including resizeable windows and controls was not only possible but relatively easy.