7 ms·
I wrote my Android app in Pascal Although I used Java to create the layouts/views. But I have started porting some things to Kotlin. Nearly finished replacing
by benibela 6y ago
I wrote my Android app in Pascal
Although I used Java to create the layouts/views.
But I have started porting some things to Kotlin. Nearly finished replacing all the Java
I also had to buy a new computer. The Pascal IDE worked great on my ten year old laptop; the Java/Kotlin IDE became so slow, it was unusable. It is surprising that Java can run on a phone, when it cannot run on my development system
- realharo 6y agoIf 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 agoYes, 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 agoI'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 agoWe 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 agoThe 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 agoI 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.
- seventh-chord 6y agoI guess thats more an issue of "modern" IDEs, which seem invariably bloated. Im sure there are productivity arguments to be made about using an IDE, but I can't get over how they all take forever to start, and how any change in the UI layout causes everything to flash around for a good second.
- TeMPOraL 6y agoThe productivity argument can be had about using an IDE vs. not using any at all. But it doesn't really work to explain how the IDEs get larger and slower while not offering commensurate gains in productivity (and arguably, being slower creates a loss in productivity).
- g_p 6y agoAgreed. I'd be interested in knowing if the perceived slowness is due to the number of layers of abstraction involved in aspects of the build process, that might also be used in the IDE figuring out what to include. I remember when "android" IDE was a plugin for eclipse... Now it seems to be a deeply integrated plugin for IntelliJ, coupled with an infinitely more complex build system (gradle), that has a fairly high fixed overhead to run for anything, and which seems to need to download 100 MB worth of code from a server for itself. Maybe we need to try get back to overall system designs where one good engineer can have the full design in their head? I suspect the slowness of the IDE has something to do with the complexity of the tooling, and the need to call the native tooling to figure out include paths, to enable features like search or finding definitions. But surely it shouldn't be this bad?
- hyperpallium 6y agoYou can develop in java on a phone within http://termux.com http://termux.com (term + linux repo)... if you're comfortable in vim or emacs.
- kragen 6y agoI'm comfortable in both, but not with the Android onscreen keyboard.
- janvidar 6y agoI'm not comfortable with a typical Android screen size either, but I have a Samsung tablet with physical keyboard flip case (Galaxy Tab S6). These two together provide a functional and workable environment for me. I haven't tried the DeX-station, but I believe that too could be quite workable with a phone.
- hyperpallium 6y agoTermux has some "soft keys" for ESC, ctrl, alt etc (user-definable). Swipe in from left, hold the button labeled "keyboard". Hacker's Keyboard (app) is the recommended onscreen keyboard (has ESC etc). But really need a bluetooth keyboard e.g. logitech K480 or fullsize logitech K375s - or regular USB one if your phone has OTG. Bonus: doubles screen space.
- kragen 6y agoYeah, Hacker's Keyboard makes a big difference, but I still only hit the right key 90% of the time, because I can't feel the keys with my fingers, and I can only hit a couple of keys per second. There's a big difference between making a typo once every 40 characters and making a typo once every 10 characters, especially in a vi command!
- hyperpallium 6y agoAnd then, while correcting it, make another vi typo, etc... a sort of event horizon, esp when tired. Physical keyboard! With a full size one, it really feels like a unix terminal. Which it is. And very fast by 70's unix standards.
- neverartful 6y agoInteresting. Which Pascal IDE did you use?