6 ms·

If you mean Android Studio being slow (and the Android build system in general, with its many transform steps), that has little to do with Java itself. Even In

If you mean Android Studio being slow (and the Android build system in general, with its many transform steps), that has little to do with Java itself. Even IntelliJ IDEA, built on the same platform is much, much faster than AS (with non-Android projects). Android Studio is just a slow IDE. 16 GB RAM and a good CPU is the absolute bare minimum for it these days for any non-trivial project, especially if you want to run the emulator as well.

benibela 6y ago
Yes, Android Studio (and the emulator) The Android app development went from my first laptop with 4GB RAM and HDD to my second laptop with 8GB RAM and HDD to my current, third laptop with 16 GB RAM and SDD. But all the laptops were really fast. I started writing Pascal code with Delphi under Windows 98 on a 166 MHz PC with 64 MB RAM or something, and it was fast enough
- realharo 6y ago
  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.
  - 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.

benibela 6y ago

Yes, Android Studio (and the emulator) The Android app development went from my first laptop with 4GB RAM and HDD to my second laptop with 8GB RAM and HDD to my current, third laptop with 16 GB RAM and SDD. But all the laptops were really fast. I started writing Pascal code with Delphi under Windows 98 on a 166 MHz PC with 64 MB RAM or something, and it was fast enough

realharo 6y ago
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.
- 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.