What a silly statement. There are plenty of use-cases where interpreted languages excels. It's programmer/developer responsibility to recognize when use what language.
Its my opinion, I'm allowed to have one right? Based on my experience with python vs C that is what I found to be the case in MY experience of using them.
Im not that fond of interpreted languages either. And not because they are slower (sometimes alot slower!) than native code but because the burden of user having to make sure that they have the running environment (that can be very big sometimes) for whatever cool interpreter language that the developer decided to use. And not only running environment but also one that has all the needed pieces that developer decided to use. Or from regular user perspective : - "Gee, that free app looks cool. I better try it" - "Oh, it's made with ABC interpreted language and needs XYZ environment of version 1.2.3 to run it. No problem, I just get it from my Linux distro repo" - "Oh, they only have version 1.2.2. Well, I guess I download the source code of 1.2.3 and build it" - "Hmmm, it needs dependency A1. Ok, I will get that too" - "Gee, A1 needs dependencies B1, C1 and JFK ......" ... several hours later ... after getting all the required dependencies and making sure they work - "Ok, now I can finally build XYZ environment of version 1.2.3 so that I can run that free app" - "WHAT?!? Undefined reference to function: __nan_nan_naaa_%&%"#"#/&" Compare that to if the same app would have been made with native code, needing nothing but the OS libraries (that are always there) and only minimal needed stuff for running it. Of course, that was just crude example but it pretty much sums it up It can be a burden for user and also for developer. And Im not willing to take *any* extra burden when deploying my apps. As much as possible should be found from the OS and only the minimal stuff needed for actually running the app. Of course, in a Linux world the pain can be eased because most of them have already things like perl or python interpreter preinstalled (and if not, then easy enough to kick package manager and install it). Some maybe have even things like ruby preinstalled. But there is always the next cool interpreter language waiting around the corner with it's own runtime environment, which of course needs it's own dependencies that need their own dependencies ...*sight* bloat, bloat, bloat
But that also can be true for native code. 1. Binary code can be dependent on library you don't have installed in your system. For example you have GTK+ libraries in your distro of choice, but program needs QT5. In Windows this can be dependency on Microsoft Visual C++ Redistributable. 2. It may be dependent on library in specific version. You can have QT version 5.1, but program needs 5.4 or later. 3. There can be binary incompatibility. You can have QT version 5.1 and program is dependent on QT 5.1, but your program is compiled by other compiler than your system. This happens especially in C++. C is better in this. Some libraries written in C++ expose their ABI as C ABI, because of that.
Yes but if you do native code, you as a developer, have already taken care of all these things for user. You have all the correct libraries and their versions resolved *for* user. They don't need to do any (possible) extra step. You have done all the hard work for them and made sure you have the right stuff bundled with your software when you deploy it. That's the biggest difference. If you just spit some script made with interpreter language for users to download, you are passing the burden of doing all those things to their shoulders. EDIT: I probably should mention that bundling libraries with native binaries is more of the Windows world thing because that system has A) no concept of package manager B) not even concept of system libraries (well actually it has ...kinda...but no, not really...). But no reason that bundling could not be done in Linux world too. And best and easiest of course would be static binaries from deployment point of view But glibc is an ******* in that regard Luckily, there is musl
For python there are tools to bundle interpreter and script together and make one, big .exe file for Windows. Or just make binary installer like it is often done for installing Windows programs. Installer will install script and interpreter. Even without these tools (bundling everything together) I don't think it is as bad as you are stating. Scripts are usually written in Python2, Python3, Perl (one would argue that shell is also programming language, but let's omit that). This will cover vast majority of scripts. Most (every?) Gnu/Linux distro have these interpreters in repository. Reasonable scripts are not so dependent on specific version of interpreter (let's simplify and say that python 2 and python 3 are different languages, even if they are just different versions of the same language) and are updated to cover current most popular versions of language. Some programs need some specific modules/packages, but they are usually in distribution repository. There are also tools such as pip which can automatically download required modules/packages. Not to mention that scripts can be in repository of your distributions as packages. They are tested and modified to fit into specific distribution version. So even if original, vanilla script is really version specific, distribution devs can modify it to fit into other version of interpreter. I acknowledge that there can be some problems with some scripts, but in reality there are always problems with software. I just stating that there are ways to cope with it and that compiled languages also have some problems. That said biggest advantage of interpreted languages is that you can run script on different processors. Script doesn't depend on whether it is run on 32-bit x86, 64-bit x86 aka amd64, ARMv8 aka ARM64 and so on.
Stefan, something I've been playing around with is called AIDE have you tried it? Its an ide for android devs its freakin awesome, probably the lightest ide I've seen in years it literally runs on a phone, I put it on an android tablet, the beauty of that is, you can compile and run code right there on the android device. The only downside is I couldn't get the native sdk to install, I'm waiting for the aide devs to respond about that so I am having to use java, but that's OK for now.
Whatever language you choose, there are trade-offs. Some of the worst horrors are inflicted in low-level routines often in critical systems with the excuse that they are more efficient (despite that being significantly true vanishing some while back). They're history, but also terrible, as the constant stream of OS bugs demonstrates. All the rubbish with obscure code, pointers, no bound checking, no dependency checking, which C and C++ either encourage or allow. At least managed code and interpreted languages can obviate many of the common code issues (memory management, code referencing, typing, bounds checking), as well as being much easier to review and maintain. Also, as a developer, I'd say I write very little code, it's mainly hooking together various libraries - as you've noted above. I'd like to say they were all paragons of software development, but at least they're better than what I'd write! So the skill is more selecting good libraries, keeping it simple, and documenting. That can be done, with care, in any of the languages. Of course, particularly for the critical elements (including CPU programming!), I'd like to see much more in the way of formal proofs and verification, but that still hasn't happened.
It can also be true for languages designed to be compiled to machine code. For example Rust type's are designed to be hard to make mistakes. Rust has manual memory management, but it is hard to make mistakes such as double free. These things are usually checked at compile time. But in the end you can make mistakes, bugs in whatever language you want. In some languages it is more difficult to make mistakes, but it possible. It is programmer/developer, who is in charge of code, testing methods, distribution of program and so on. For example in Java, a nominally memory safe language, there was a bug really similar to Heartbleed. You can write a Heartbleed in C# of course if you want.
Indeed, one can write bad code in any language. The problem the industry has is that that code pervades critical elements of operating system (and cpu). I think what I was trying to say was that, given a solid foundation of a secure operating system and high quality and maintained libraries, non-specialist programming is in fact best done with object oriented managed code or interpreted languages, backed by good compilers that can do much of the bound-checking and type checking if desired. Personally, I'm a fan of strongly typed languages and functional programming (when I get in the right Zen state). I find Javascript nightmarish by comparison with C#, for example. That's not all down to the language, it's the mis-mash of libraries and the html DOM that's dreadful.
Could you please give the name of the tools that make one single .exe ? Can you just run the resulting .exe without any installation requirement? Also, can it make binary blobs, similar to Windows .exe, for Linux ?
Yes, of course, provided that there is an interpreter ported for the arch No problem with x86/x86_64/ARM because those are pretty much de facto (can be found from almost everywhere) But how about some little more exotic arch like MIPS ? Or AVR from embedded world? Embedded chips have severe size constractions for memory and storage. Heh, any phone out there has million times more capacity. You can't use full interpreter in there and you have to use (I guess?) some specialized, stripped down version? Or if even that is not possible then native code it goes But still, it would be pretty interesting to use Python/Perl/etc in a development phase for those machines and then somehow convert them to self-running native code ....
Bugs can be found from any language. And with some languages that don't provide hand-holding for developer (they need to know what they are doing), it is easier to make serious mistakes. But even more serious than software bugs are the hardware ones that the current Meltdown/Spectre fiasco shows. One dude makes mistake with CPU memory protection in the 90s and the result is that 20 years we have had basically insecure machines. Maybe exploited by you know who ....
PyInstaller. I don't have much experience with it, because contrary to what people can think after reading my posts, I don't code in Python or Perl. I just know that other people use these languages and have ways to cope with things. 8-bit uC are really different world. You don't have much space, so it basically can run only C language or stripped-down C++, but don't have enough memory to program in usual object-oriented way. Let's not mix it with PC-programming world.
Yeah check it out you can download the aide.apk its free in Google play, its got a built in hello world and a few tutorials about some of the android api's, You can get extra tutorials if you want to pay for them, but you probably won't need that. I found the same devs make a web design IDE too also on Google play I didnt try it yet though. I'm just still too fascinated with being able to code apps on my phone and tablet lol
