478
Microsoft announces Python formulas in Excel... which have to get sent to the cloud
(techcommunity.microsoft.com)
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
this post was submitted on 23 Aug 2023
478 points (97.0% liked)
Technology
59623 readers
1109 users here now
This is a most excellent place for technology news and articles.
Our Rules
- Follow the lemmy.world rules.
- Only tech related content.
- Be excellent to each another!
- Mod approved content bots can post up to 10 articles per day.
- Threads asking for personal tech support may be deleted.
- Politics threads may be removed.
- No memes allowed as posts, OK to post as comments.
- Only approved bots from the list below, to ask if your bot can be added please contact us.
- Check for duplicates before posting, duplicates may be removed
Approved Bots
founded 1 year ago
MODERATORS
Emulate that shit with Java!
java isn't slow
I mean, whatever speed java has or doesn't have, what the other person said was emulate, you'll have your os then on top of that the JVM then on top of that your python implementation, then finally the python code. If that's faster than os->python imp..
Just like Python doesn't run from the source code through the interpreter all the time (instead, if I'm not mistaken, the interpreter pass converts the code to a binary runtime form, so interpretation of the source is done only once), so does "modern" Java (I put modern between quotes because it's been like that for almost 20 years) convert the code in VM format to binary assembly code in the local system (the technology is called JIT, for Just-In-Time compiler).
It’s Jython and it’s like 25 years old
Still on python2 as well (Stable version )
If you need python 3 there's also graalvm but its python support is still "experimental".
Plus Java IS slow, quite slower than compiled languages at least
java is a compiled language
If you go that detailed, then the jvm is JIT compiler, not an interpreter, so Java code still mostly runs natively on the processor. Java is quite fast achieving pretty close performance to C++, the only noticeable problems are on desktop because of the slow jvm startup and slow GUI libraries compared to native ones.
Factual errors:
Words which have a common understanding in the current compiler construction world, which you define in IMHO a non standard way
Factual errors about Java:
Very much not a thing. JIT interpreters are actually not that common. Most interpreters parse code to an AST in memory and then run execute said AST, without any compilation to machine code.
Listen to yourself the output of the compiler makes it not a compiled language. Java is a compiled language, and jvm bytecode can be compiled (see graalvm), or interpreted (and when interpreted it can be JITd)
I think you're used to modern interpreted languages and are unaware of how the runtimes of interpreted languages used to work.
Something like Basic (to use a properly old example) was constantly interpreting source code during the entire run.
If I'm not mistaken Python was the first major interpreted language which by default interpreted the code into a binary format and then just ran the binary (and, if I remember it correctly, that wasn't the case in its first version). By this point Java already JIT compilation in its VM for a while.
I think you're committing the error of comparing modern interpreted languages with how Java worked 2 decades ago.
There is another compilation step inside the Java Virtual Machine which "compiles" the VM Assembly code to native code at runtime.
This is what's called JIT compilation and has been part of the standard Java Virtual Machine for about 2 decades and the default - at least server side - for almost as long (i.e. you have to explicitly pass a parameter to disable it at startup if you want the old runtime interpreted VM opcode behaviour).
Source: I used to design and develop mission critical high performance distributed server systems in Java for banks since before 2008 and it definitelly is capable of handling it (the bottleneck tended to be the TB-size database, not the Java application).
Eh...Java source code compiles into bytecode which runs in a virtual machine. Compare this to a language like C which compiles to native machine code. Java still gets interpreted.
The bytecode is turned into native code before execution
That's not how it works. If that really was how it worked there'd be no point even having bytecode; you'd just straight up get the native code. Unless you're talking about JIT, but your wording seems to be implying that all the bytecode turns into native code at once.
I was referring to JIT but there are also other options like GraalVM for AOT compilation.
Performance of non-native bytecode such as Web Assembly can reach quite close (80%-ish) to machine code.
Yeah, in my personal experience (with numerical compute-heavy code), normal python code, ran in the normal python interpreter, is much slower than the equivalent normal Java code with the normal Java VM (like 50x). Then C/Fortran is ~2x faster than Java (with gcc + optimization flags).
I think Java is a good middle-ground between coding speed and execution speed. Sadly, it seems to be dying. And JavaFX is shit for trying emulate full-stack web-dev. The fucking ancient Swing is even better.
Scala and Kotlin are OK, but I think they are making the mistake of feature-creep that causes large projects with many people to contain multiple programming paradigms that only some of the team can grok well, instead of a restricted OOP Java codebase that encourages Gang of Four style code. Though, I guess GoF-style code resulted in that crazy complicated "enterprise" Java shit.
Last I checked Java was alive and well in the server-side for things like middleware and backend, especially because the whole development ecosystem is incredibly mature and significantly more stable and well integrated with corporate-category systems than pretty much anything else (good luck managing a single reliable transaction across, say, 2 different databases in 2 different sites and 1 MQ system with Python).
Absolutelly, it's been mostly limping in a half-dead state on the UI ever since day 1 and even Google using it with Android didn't exactly help (because Google's architectural design of the entire Android framework is, well, shit, and has become worse over time).
It also lost it's proeminence in dynamic web page generation at around the early 00s to actual templating languages (such as PHP) with a much lower learning curve and later to Python.
The ecosystem for Java is rock-solid and in widespread use in corporate multi-tier architectures that require reliable operation (were, for example, it's native multi-threading synchronisation support and core libraries make a huge difference) and integration with professional backend systems, but for the rest, not so much (I did both that stuff and Android, and the latter is like the amateur-hour of Java ecosystems in comparison with the former).
At least Android has switched to Kotlin which is rightfully superior.
The problem in Android has always been that the framework design is pretty bad in design and technical architecture terms and its evolution over time has made its glaring flaws more obvious and actually made it even messier, rather than the language (Java is fine as languages go and UI stuff only has to run in user-time, so response times of 100ms are fine and bleeding edge performance is not required).
Further, splitting the user base into two languages, by introducing a new language that is not used anywhere else (hence you're not going to find Kotlin programmers from outside Android development whilst you will find plenty of Java programmers) is one of the stupidest technical architecture decisions I've seen, and I've been in the industry for over 2 decades.
Last but not least, the gains from the small programming-time efficiency advantages of Kotlin over Java are a drop in the ocean next to the losses due to the Android Framework itself being badly designed (something as simple as not having functions in different core classes that do the same thing named the same).
Even for programmers going for Kotlin is a less than wise career move: as an Android-only language those who specialize in it are locking themselves into programming for Android only and have fewer career options - hands up anybody who expects to still be programming Android in 10 years time! The great thing of generic languages is that there are a lot of lateral career moves you can make without the high likelihood of failure that comes from hiring managers naturaly prefering people with several years of experience in the programming language used in their projects over people who say "I've mainly done Kotlin but I can learn that easilly".
What many years of experience in the industry tells me is that you don't want your career to hang on the ficklness of a vendor, any vendor, especially the likes of Google who will drop massivelly hyped systems with tons of 3rd party investment whenever they feel like: just ask everybody who invested in developing for Stadia.
I code Kotlin for a hobby and have never heard of Android frameworks. While the largest use case is still Android it IS a very good language, and there are a LOT of things online about Kotlin being used outside of Android. Kotlin is a generic language; you don't need Android stuff at all to use it.
A framework in the software development context means an integrated set of software libraries and tools for developing for a platform.
So all the android.* libraries, the build tools, the Android IDE and so on together form a framework for Android application development.
As Kotlin is not a generic language and is only really used for Android, it makes sense to consider it as part of the Android Application Development Framework (a programming language is basically a kind of tool), but for example Java which is generic has its own independent compiler, runtime and core libraries and there are various frameworks (such as I2EE, Spring, Android and so on) that on top of Java and those core elements add a set of libraries and tools to allow development of applications for different platforms (FYI, I2EE and Spring are for server-side application development).
If I'm not mistaken Google themselves refer to the tools and libraries for developing applications for Android as the "Android Application Development Framework".
The android.* libraries are not included with Kotlin. I consider it an independent framework, just like the ones you said. What's your definition of a generic language? AFAIK Kotlin can do everything Java can do. Kotlin also has its own independent compiler and runtime (Native) though it inherits Java's or C's libraries, which also means you can just use Kotlin frameworks with it. Spring even made their own completely Kotlin version, along with Compose. In a 2020 JetBrains survey 47% of surveyed developers were using Kotlin for web backends so Kotlin is definitely not limited to Android. I got that from the Wikipedia page which also has a lot of big names that use it including Amazon, Netflix, and Shazam (Apple?).
I meant it as "general use" language, as in a language that's widelly used for several things.
I'm quite suspicious of the methodology of that JetBrain survey, since 47% would put Kotlin above the likes of Python for web backend development, which is the most ridiculous claim I've read in quite a long time.
Certainly big corporates aren't using Kotlin (with or without Spring) for making middleware (which is not at all the same as web-development) and "big name companies" "using it" doesn't mean much because merely trying it out for 2 weeks with a handful of developers on a side project fits the definition of "using it". If it was that successfull you would be hearing about actual large projects. Frankly it sounds a lot like a certain kind of marketing messaging I've often seen in the past for other kinds of languages or frameworks some large tech company or other was trying to convince developers to use, and such manufactured hype doesn't really mean anything when it comes to the actual usage in the field.
Certainly that idea about Kotlin's "success" isn't something I'm seing in the hiring side and if companies aren't hiring for it they're not using it seriously.
(PS: The idea that Apple would use it is pretty wild as Kotlin was created in response to Apple coming up with their own language for smartphone development - Swift - which replaced Objective-C, and they're pretty similar in terms of the language features they add over the languages they replace, so it's kinda silly that Apple would give up on the developer-lock-in benefits of Swift to adopt the language of its competitor which is also trying to achieve the same kind of developer-lock-in but to benefit Google instead of Apple).
I think you're comparing 47% to the wrong statistic. It's 47% of Kotlin developers do backend, not 47% of backend developers use Kotlin. I haven't seen any reliable backend languages survey yet.
It's not just side projects. Though admittingly most of the sources there are from a "talking kotlin" podcast which I suspect is tied to JetBrains, the projects discussed in the podcasts aren't just side-projects. For example "Allegro" is Poland and Slovenia's Amazon and almost all of their backend is Kotlin apparently. It backends tax collection in Norway and (part of?) Shazam which is owned by Apple which was why I put "Apple?", I'm not saying Apple's using it officially.
"Kotlin created against Swift" is completely speculative. The only things related they have is Swift started in 2010 while JetBrains announced it in 2011, but even then it's a stretch as Swift was only announced in 2014. You can't make something in response to something which doesn't exist yet.
Ah, right.
That makes a lot more sense.
It's interesting that Kotlin is also seriously used for server-side rather than just for frontend work in Android: is was not aware of that.
Indeed Kotlin being created as a response for Swift is speculative. The timings (launched one after the other separated by about 1-2 years) and the launch target platforms (both main smartphone OSes) were peculiar, as are the characteristics of both languages (they roughly added the same things over the languages they replaced, though that was the kind of "need" OO developers had been feeling at around that time and quite a few options came out, both new languages and new features for existing languages), but I'm not privy to whatever behind-closed-doors discussions there were on that so don't really know for sure.
As you say, maybe indeed Kotlin was being developed in parallel and then for launch piggy-backed on Google's need for "it's own language" in the smartphone market in response to Apple having lauched their own with quite some success - as I pointed out, it makes business sense to try as much as possible to lock-in developers to your own platform - since it would make sense for JetBrains to launch with a big partner with a large installed based.
Kotlin was announced in 2011 and Swift was announced in 2014; that's 3 years apart. Like you said, they do look kinda similar but I think that's the result of being designed with 2010s principles.
Kotlin also didn't launch on a smartphone platform, it just kinda released with the build tools without any initial target platform. Since JetBrain already owns IDEA, the most popular Java IDE, they just bundled that with Kotlin to launch the language. I think it's the opposite, Google piggy-backed off JetBrain's fame and install base in response to the Swift thing instead of also developing a new language. It isn't a lock-in either, JetBrains is quite independent of Android though they did kinda lock the language server to IDEA.
I used to make high performance distributed computing server-systems for Investment banks.
Since the advent of Just In Time compiling, Java isn't slow if properly used.
It can however be stupidly slow if you don't know what you're doing (so can something like Assembly: if you're using a simple algorithm with a O(n) = n^2 execution time instead of something with O(n) = n*log(n) time, it's going to be slow for anything but a quantum computer, which is why, for example, most libraries with sorting algorithms use something more complex than the silly simple method of examining every value against every other value).
Just because you can make slow assembler doesn't make Java fast.
Java is clunky and not fast compared to C++ which is clunky and fast, Python which isn't clunky but slow bla bla bla bla...
That's oversimplifying things.
For things like algorithms Java can be as fast as C++ because ultimatelly it all ends up as the same assembly code: the differences in performance between one and the other are within the same range as the differences in performance between different C++ compilers or even optimization flags chosen and ultimatelly boil down to how good the implementation of the Java Virtual Machine is for a specific architecture (things like whether the generated assembly takes in account the way the microcontroller handles conditional jumps and cache misses).
Were Java is slower than C++ is in things like memory management: even the best garbage collection will never beat the kind of carefully handcrafter managing of memory that you can do in C++, though the upside of the different memory management architecture in Java is that your programs don't just start behaving in weird ways because you incorrectly accessed a variable in stack using a pointer and overwrote other stuff or even the function return address.
Then again if performance is your greatest consideration you would go for C, not C++ (note that I didn't say Assembly, as good C compilers are actually better at optimizing than most Assembly programmers).
Well that was a lot of misconceptions.
So compiler will make java as fast as C++ but not C++ as fast as C?
Also, when speed matters it's never great to have huge Java classes, it just won't be optimised away (anough) and you'll have a memory / bus bottleneck.
Also, if you really want speed you go parallel, IDK if java is up for the challenge lol (can you configure stackspace and so?) or to beat them all, you run it on the GPU (or several GPU lol :-)
I think I didn't explain myself correctly.
The Just In Time Compiler in a Java Virtual Machine which does a final compilation step at runtime from JVM assembly to native code will make the typical code in algorithms run as fast as in C++ because ultimatelly they both end up as the same assembly. I've actually measure this by the way, though it was years ago.
However things like memory architectures are different between those languages and the one in C++ can easilly be made faster than in Java, though the downside of that memory architecture is nastier bugs.
Further, and this time about general performance, if you're worried about performance above all, then in terms of general performance, C is generally faster than C++: for example virtual functions in C++ objects have calling overheads which function calls when there is no inheritance do not have so unless you don't use inheritance at all, some function calls in C++ will be slower.
As for parallelization, I've actually worked both in massive parallel Java with distributed computing and GPU computing and they're completelly different kinds of parallelization with different capabilities and optimal use cases: good luck making a CUDA application optimized for serving paralled requests from millions of clients sourcing data from multiple sources and good luck making an LLM runtime with distributed computing in Java were parts of the pre-trained neural network are in different machines - GPU computing can't arbitrally decide it needs some data and fetch it whilst the overhead of synching two parts of a Java system running in different machines is way (millions of times?) larger than the overhead of synching read-then-write-access to the same position in a RWStructuredBuffer from 2 different processing units.
Comparing these two kind of parallelism is not an apple and oranges comparison, it'sm more like an apples and horseshoes comparison.