stantronic
08/02/2023, 8:00 PMJoffrey
08/02/2023, 8:05 PMstantronic
08/02/2023, 8:21 PMJoffrey
08/02/2023, 8:24 PMstantronic
08/02/2023, 8:25 PMJoffrey
08/02/2023, 8:40 PMeygraber
08/02/2023, 9:42 PMstantronic
08/03/2023, 7:15 AMeygraber
08/03/2023, 7:25 AMstantronic
08/03/2023, 7:41 AMTadeas Kriz
08/03/2023, 11:52 AMJoffrey
08/03/2023, 12:41 PMTadeas Kriz
08/03/2023, 12:55 PMJoffrey
08/03/2023, 1:03 PMThere's essentially nothing to be lostI'm ready to accept that you want to ignore the loss of the benefits of Kotlin's type system and advanced compiler errors, on the assumption that we're using an IDE in dev mode (which is not true for plain scripting), and thus it's already running the compiler for us in real time (so the developer is likely to see errors in at least a part of code). However, we can't ignore that developing such a thing would imply deallocating resources for other things, and that is a huge drawback that needs to be part of the analysis.
Tadeas Kriz
08/03/2023, 1:06 PMstantronic
08/03/2023, 3:00 PMTadeas Kriz
08/03/2023, 3:01 PMSam Stone
08/03/2023, 8:50 PMmcpiroman
08/04/2023, 10:18 AMloss of the benefits of Kotlin's type system and advanced compiler errorsInterpreted mode does not imply that. All the compiler frontend part, including type checking and analysis would still (need to) be run. Same as all the IDE diagnosis, if you're using IDE. Interpreted != python. It rather means that, later, instead of compiling the analysed code to some standardized form, such as bytecode or native code, saving it on disk, loading from disk by VM or OS, and then running, interpreter would run the kotlin code directly from memory, with just a minimal amount of intermediate transformations. Minimal still means quite a bit, I think, but even then the overall process from source to execution should be way faster.