# Another reason not to use python?



## mark_j (Jul 31, 2021)

This could possibly go in the scripting topic.

According to these folks (jfrog.com) and to quote:


> As part of an ongoing effort by the JFrog security research team (formerly Vdoo) to automatically
> identify malicious packages, we are now reporting several Python packages hosted on PyPI as
> malicious. We have alerted PyPI about the existence of the malicious packages which promptly
> removed them.











						Python developers are being targeted with malicious packages on PyPI
					

JFrog finds a new supply chain attack targeting python developers using the PyPI repository




					jfrog.com
				




This is an on-going issue with repositories (and has been since Perl years ago) and languages that are based on this model.

Trust is something we often give out when probably we shouldn't.

For developers to assume the code they pull in is safe is just reckless. End-users, unfortunately, are at the mercy of packagers and port maintainers.

I did manage to find a reference to the affected packages, but I am not sure this is a definitive list:








						Software downloaded 30,000 times from PyPI ransacked developers’ machines
					

Expect to see more of these "Frankenstein" malware packages, researchers warn.




					arstechnica.com


----------



## a6h (Jul 31, 2021)

mark_j said:


> Trust is something we often give out when probably we shouldn't.


This is how they are growing their gigantic libraries, i.e. the main reason behind its popularity. If you want a Cobol (Python) job, you have to learn Cobol (Python). I understand that. There's nothing wrong with learning multiple languages -- use it; dump it. But there's a Python-fad too; mostly around ML and hacking-stuff!

A retro-way of doing things:
1. C and/or Shell (sh, sed, awk).
2. Too much work! Use Perl.
3. Well-paid jobs? Learn the new language, even if it's FoxPro 2.6.


----------



## drhowarddrfine (Jul 31, 2021)

vigole said:


> there's a Python-fad too;


And now Rust, too.


----------



## Tieks (Jul 31, 2021)

mark_j said:
			
		

> For developers to assume the code they pull in is safe is just reckless.



Right you are. I look at the code before ever using that stuff, the examples from the first link are obviously wrong imo. Something like `joy = '\x72\x6f\x74\x31\x33'`, why not simply joy = 'ROT13'?
I'm definitely off with `eval(compile(base64.base64decode(eval(...))))`. It's almost beautiful.


----------



## hardworkingnewbie (Jul 31, 2021)

Not the first time such a thing happened to a well enough established programming language with a central code/library repository, though.

But that's not a valid reason to not use that language. Just a sign that you should pay more attention to whom you trust, as always.

For me though Python is harmless, because the cake of stupid lazy ass programmers lies clearly within Node.js and their npm repository. These people are too dumb to program their own basic string manipulations. And that's not an overexaggeration.

A legally threatened developer named Azer Koculu pulled in 2016 around 250 of his modules from Npm, including something called left-pad. Some of his stuff was being used in a messenger called Kik, to which he had no ties, but he felt enough pressure to pull off all of his modules.

Left-pad was just this snipped of code, nothing more:

```
module.exports = leftpad;

function leftpad (str, len, ch) {
  str = String(str);

  var i = -1;

  if (!ch && ch !== 0) ch = ' ';

  len = len - str.length;

  while (++i < len) {
    str = ch + str;
  }

  return str;
}
```

So all it does is to pad out the lefthand-side of strings with zeroes or spaces. No rocket science. This modulie back then had almost 2.5 million download *per week*. And really something at beginner programming level as well.

So when he pulled it there was a nasty fallout, because suddenly lots of stuff around the world was broken when people were trying to install all fancy npm stuff, because that dependency was now unresolvable. This was so enormous, that the maintainer of NPM restored a version of it quite fast enough.

Here's a nice writeup about the incident: https://www.davidhaney.io/npm-left-pad-have-we-forgotten-how-to-program/

Or that case when one guy named Dominic Tarr, the author of event-stream, didn't want to support this any longer and handed over the maintainer ship to another guy. event-stream has also around 2 millions downloads *per week*. And the new author used it to spread malware. Nice writeup here.

NPM also back then introduced other innovative hideous stuff as well in its update process, like - uhm - ads on console in its command line interface. Well, they quickly shelfed that then.

And then the inevitable happened: npm was acquired by Microsoft. What could possibly go wrong...


----------



## mark_j (Jul 31, 2021)

Yes, don't get me wrong, every language, where you pull in code from elsewhere to fulfill X function without vetting the code is real bad. 

However, these languages like python that are so-called multi-paradigm are designed so users/developers can just pull in what they want without any thought. What could possibly go wrong? You've given us another very good example.

It's all fun and games until you're hacked.


----------



## Alain De Vos (Aug 1, 2021)

Can't the same thing happen using perl5 or ruby ?


----------



## Tieks (Aug 1, 2021)

Alain De Vos said:
			
		

> Can't the same thing happen using perl5 or ruby ?



I've seen similar things in Perl .pm modules. You just have to check when you  pick up something from a repository somewhere.
Don't get me wrong, there are many well-programmed and useful modules out there. It's just that not all of them are.


----------



## Crivens (Aug 1, 2021)

mark_j said:


> Yes, don't get me wrong, every language _developer_, where you pull in code from elsewhere to fulfill X function without vetting the code is real bad.


FTFY


----------



## kpedersen (Aug 1, 2021)

Of course the developers fault. Though I suppose languages with their own package manager kind of encourage this kind of careless behavior. NPM, Crates.io, CPAN (incl LaTeX), Gems, etc all breed terrible behavior. It is so rare that a program pulls in one or two dependencies like a typical C or C++ program. They *always* without fail seem to drag in dozens of little bits of cruft.

This and bindings. The world is built on C, so I suppose other languages needing bindings to wrap the native libraries are at a disadvantage when it comes to dependencies. I.e if Rust had a tiny C compiler added to it so it could consume C libraries directly, it would be a much stronger contender to C++.


----------



## Alain De Vos (Aug 1, 2021)

Sometimes I code in D-lang. And when i need binding for let's say postgresql it pulls in numerous of libraries which are not postgresql related.
They all fail at the same place.


----------



## kpedersen (Aug 1, 2021)

Alain De Vos said:


> Sometimes I code in D-lang. And when i need binding for let's say postgresql it pulls in numerous of libraries which are not postgresql related.


Can D-lang not use C includes directly? Just like with C++, you lose a bit of safety or an idiomatic API but you do benefit from simplifying the solution as a whole.


----------



## Alain De Vos (Aug 1, 2021)

You can call with extern-C, and then it follows the C-calling convention. This works fine for simple libraries.
It fails when you have complex include files with lot's of macro's and defines. Or when C++ is used.
I should try it once with for instance libpq.


----------



## astyle (Aug 1, 2021)

A good expression for all that - the devil is in the details. When a program gets big enough to do anything of interest - that's when it becomes easier to hide malicious intent among mistakes. And then you wonder why we have tight control over who actually gets to be a committer - just remember the mess that University of Minnesota got itself into, with a supposedly malicious commit that exposed holes in how kernel patches get submitted.


----------



## mark_j (Aug 1, 2021)

Alain De Vos said:


> Can't the same thing happen using perl5 or ruby ?


Absolutely, that's why I mentioned it. When I was using perl (a lot) a long time ago this always worried me. You pull in modules and then run them as root or other high privilege and don't give it a second thought.

Obviously the entire open source ecosystem is a potential victim to this issue because we share but often don't care about the code we incorporate. This seems especially true with junk like javascript.


----------



## hardworkingnewbie (Aug 2, 2021)

mark_j said:


> Absolutely, that's why I mentioned it. When I was using perl (a lot) a long time ago this always worried me. You pull in modules and then run them as root or other high privilege and don't give it a second thought.
> 
> Obviously the entire open source ecosystem is a potential victim to this issue because we share but often don't care about the code we incorporate. This seems especially true with junk like javascript.


Well you don't have to use Javascript for such examples. Any programming language, where for some tasks is a standard library established well enough so it's practically everywhere but not many have a look at its internal status quo, and only few people actually have the knowledge to dive even deeper to be able to judge if the algorithms are implemented correctly or not will fit that bill. 

For me the prime example is OpenSSL, when the heartbleed exploit was being discovered. This lead to the LibreSSL fork, and boy oh boy, what they did found in the source code was disgusting.


----------



## Crivens (Aug 2, 2021)

The problem is worst when the code loads its dependecies on its own. You have no way to validate a build. Now for that safety critical stuff, like in medicine...


----------



## fbsd_ (Aug 2, 2021)

Actually there is no reason exist to not use any language while they are being useful for that work. There can be python packages that contains viruses but It doesnt means its very dangerous to code. While there are more than 137 thousand python packages, it is very difficult to download 4 or 5 infected packages. As long as I know that packages were working like RAT programs. They are stealing browser datas, Discord recovery codes, files from fs etc. Also there is risks exist on JS too. As long as I know there is a lot of npm packages found that contains malicious code.

While the world is a cruel place, there is always the instinct of self-preservation, and at the same time those who are afraid of committing crimes in real life will create viruses by writing and stealing a little code in the virtual environment.

So the solution is prefering open-source, popular packages for projects


----------



## astyle (Aug 2, 2021)

hardworkingnewbie said:


> Well you don't have to use Javascript for such examples. Any programming language, where for some tasks is a standard library established well enough so it's practically everywhere but not many have a look at its internal status quo, and only few people actually have the knowledge to dive even deeper to be able to judge if the algorithms are implemented correctly or not will fit that bill.
> 
> For me the prime example is OpenSSL, when the heartbleed exploit was being discovered. This lead to the LibreSSL fork, and boy oh boy, what they did found in the source code was disgusting.


Old stuff... OpenSSL has actually been patched for Heartbleed already.  The Wikipedia page actually points out that Heartbleed first appeared in 2012 (when OpenSSL was on version 1.0.1). Big Tech companies have been surprisingly slow to patch it up, but by mid-2014 Heartbleed became a big enough problem to finally be acknowledged as something that requires attention and a fix. FreeBSD updated its security/openssl OpenSSL implementation to 1.0.2 back in 2015, which corresponds to 10.1-RELEASE support cycle.


----------



## hardworkingnewbie (Aug 2, 2021)

That was not my point; my point was that you can include bad libraries everywhere, and even well known might packages like OpenSSL might be just that - bad, astyle.


----------



## kpedersen (Aug 2, 2021)

hardworkingnewbie said:


> That was not my point; my point was that you can include bad libraries everywhere, and even well known might packages like OpenSSL might be just that - bad, astyle.


At least with C or C++ you include one library, i.e OpenSSL. With many other languages you will need OpenSSL *and* countless other libraries providing the non-native binding layers, frameworks, etc.

The chance that one single library is bad is quite low. However once a solution drags in loads of cruft, this chance raises considerably.


----------



## astyle (Aug 2, 2021)

Crivens said:


> The problem is worst when the code loads its dependecies on its own. You have no way to validate a build. Now for that safety critical stuff, like in medicine...


Crivens : Sorry, but I'd like to challenge you for some concrete examples here. Are you talking about runtime deps? the FreeBSD pkg and ports systems are actually pretty good about limiting that to registered deps. 

FWIW, when I compile lang/rust, I notice that the source tarball isn't large, but `make` pulls in a truckload of deps from crates.io... But I honestly look at that as 'reinventing the wheel'.  For comparison, devel/llvm bundles nearly everything it needs into one fairly large source tarball, that takes forever to compile, but doesn't need to pull in a truckload of deps that are frankly a re-implementation of standard UNIX utilities.


----------



## mark_j (Aug 2, 2021)

hardworkingnewbie said:


> That was not my point; my point was that you can include bad libraries everywhere, and even well known might packages like OpenSSL might be just that - bad, astyle.


I think the differentiation between poor code and nefarious code needs to be made, as well as the trust placed in repositories such as the one at issue here.

You will always have bugs, even in God's own language, Rust , but code designed to exploit your system is a very different beast.

The true problem is trusting these repositories,  from Perl to Python but also for the seemingly blind pull-in of code to fulfill a purpose; I'm looking at you javascript programmers (just look at an average web page and the s%#t it loads from various javascript sites. It's a disaster waiting to happen).

Even in ports, many grab stuff from some individual's web site to build from. Has that been hacked? Even sourceforge was hacked a few years back, but they said don't worry


----------



## astyle (Aug 2, 2021)

mark_j said:


> I think the differentiation between poor code and nefarious code needs to be made


Think that's easy? Stuxnet was nefarious, but it took a team of Kaspersky-funded researchers a few days to even figure out that it was targeting nuclear reactors in Iran. And a PBS Nova documentary on the topic pointed out that the compiled code, when reverse-engineered, was discovered to have a goal of making some centrifuges go faster. That's the same stuff that makes fans on a graphics card go faster or slower. Even Stuxnet was frankly a gamble. It could have hacked the smart blender in my kitchen and made strawberry smoothies for me.


----------



## mark_j (Aug 2, 2021)

Source code.


----------



## Jose (Aug 3, 2021)

kpedersen said:


> The chance that one single library is bad is quite low. However once a solution drags in loads of cruft, this chance raises considerably.


And the more layers of cruft you have, the harder it is to understand what is actually needed and what is either optional or just plain pointless. Lots of lazy programmers drag in the kitchen sink just to be sure. It's less work that figuring out what is exactly needed, and using that and no more. The C/C++ linker punishes such behavior severely, and thus it's far less common in those languages.

The harder your dependency tree is to understand, the less likely it is someone will spend the time needed to identify any potential problems in it, and therefore the easier it is to sneak in nefarious code.


----------



## a6h (Aug 3, 2021)

Alain De Vos said:


> Can't the same thing happen using perl5 or ruby ?


Yes, but at least:

I. Perl has PerlMonks.
II. Perl has Merlyn.
III. Perl was in the FreeBSD base and is in the OpenBSD base.
IV. Perl didn't give us py:2->3 doomsday.
V. Perl by its nature, is a redditor-unfriendly construct. That's always a plus.
VI. Perl had Obfuscated Perl Contest.

P.S. Perl 7.0 is coming and is going to be a modern Perl 5.32 gem. I have no need to use Python; zero, none whatsoever!


----------



## astyle (Aug 3, 2021)

mark_j said:


> Source code.


It's kind of like trying to use a chainsaw - it can be a tool or a weapon. In the world of software security, ANYTHING is game for being malicious.


----------



## Crivens (Aug 3, 2021)

astyle said:


> Crivens : Sorry, but I'd like to challenge you for some concrete examples here.


They were using javascript for analyzing software and thought of medical uses. But with npm, you never know what you get from one start to the next. So, no validation.


----------



## a6h (Aug 3, 2021)

Alain De Vos said:


> Can't the same thing happen using perl5 or ruby ?


I almost forgot the most important things: if you stick to the CPAN, then you can count on the "_CPAN testers reports for all the modules on CPAN_" at cpantesters.org. There's no guarantee, but that's something!


----------



## Tieks (Aug 3, 2021)

mark_j said:
			
		

> code designed to exploit your system



That's the point, it's about the intention of the programmer. That example `joy = '\x72\x6f\x74\x31\x33'` clearly shows the programmer wants to use rot13 and is trying to hide that.


----------



## _martin (Aug 3, 2021)

mark_j said:


> This seems especially true with junk like javascript


Hear, hear!. 
With python (and any other scripting language that was discussed above) you may have at least some sort of control. Trying to browse the web with JavaScript disabled is /practically/ almost impossible. Not to mention what all trace junk in brings with it. 

I didn't like python for many years. Most of the scripts I did are perl ones. But when I came into the CTF (capture the flag) game and started doing pwnables (hacker games) I noticed the perl is just taking my focus away from the problem at hand. Many times python just made things easier with the already available libraries. Depending on the exploit I still use assembler and C (and I love writting exploits in those languages) but I saw the beauty of the python too. Especially when I use the library I would not be able to write myself (SMT solvers, Z3, angr...).

Now with the 3.x python I have the same hate as before. So maybe I start to like it again in 10-15 years?  

But as with any other software one pulls from the internet -- beware of the risks.


----------



## kpedersen (Aug 3, 2021)

_martin said:


> Many times python just made things easier with the already available libraries.


Python has relatively few inbuilt libraries. Unlike Java it is not a "batteries included" platform. You need to source them from the PIP repo. This in itself isn't really a problem. C and C++ are similar.


_martin said:


> Depending on the exploit I still use assembler and C (and I love writting exploits in those languages) but I saw the beauty of the python too. Especially when I use the library I would not be able to write myself (SMT solvers, Z3, angr...).


This is where Python becomes a pain. For example, in C, I can grab a library and it is *one* dependency. In python that similar library would drag in recursively 20+ dependencies.

Certainly, use a library. It is incorrect to assume that using a library is wrong. However Python is an example of a "dependency language" where there are more dependencies than actual solution. It does a poor job of minimizing dependencies and lifespan and code correctness suffers.

Ultimately many language fall for this trap and thus never quite managed to surpass C (or even C++). Rust is going to be an unfortunate example of this. I think Java (and thus CSharp.NET) are one of the few examples of non-C languages that have not fallen for this trap. Possibly contributing to Java's comptitiveness with C on (slightly superficial) leader-boards such as TIOBE.


----------



## _martin (Aug 3, 2021)

kpedersen I didn't say otherwise. Python (as many other scripting languages out there) brings dependency hell with it. One has to pay attention (pip, cpan) what's being installed. 

I only shared my view on the python. It helped me speed up many tasks I had at hand and didn't stir my focus away from the actual problem. I never run pip/cpan on a host. Always only in a task-dedicated VM. But then I do store and run malware there too. I did also write few python scripts for gdb to ease my debugging - priceless. 

But then I start swearing anytime I open python3 (and still I tend to open python2 when things are not going the way I want to).


----------



## astyle (Aug 3, 2021)

Yeah, when dependencies begin to recurse, that's when it becomes impossible to verify things completely, and THAT's when malicious elements strike. But man, CTF and pwnables... that stuff is actually over my head. It's interesting to be on the sidelines, observe, take some notes for my own use, be an informed consumer of such 'entertainment' - but joining in on such games would be a bit too much for me. I'd have to do a truckload of practice, and rethink my approach to security from ground up just to show up at the playground. A real-life comparison would be surfing - waves with a 3-4 foot face are OK for me, but stuff beyond that takes more skill than I currently have.


----------



## _martin (Aug 3, 2021)

astyle: You just have to start. Everybody started somewhere. Some people are better than the others, as always. When I first started (pwnable.kr) and was introduced to GOT (in "toddler's bottle" section) I was blown away. Going passed that level was a huge step for me. 
Once I was stuck on a level for 7 months. I was going crazy. But persistence was a key. So just start somewhere, use whatever tools you need, break stuff and most importantly have fun.
And of course don't forget there are some crazy good people out there. Jaw dropping, crazy good.


----------



## Crivens (Aug 3, 2021)

With security/safety critical software I would first check if the thing is statically linked. That is not possible in these scripting languages. I would hate to break things like login when some genius updates libc.so with the result of some underhand C contest...


----------



## jb_fvwm2 (Aug 3, 2021)

vigole said:


> Yes, but at least:
> 
> I. Perl has PerlMonks.
> II. Perl has Merlyn.
> ...


So theoretically someone with enough time and money could change `seamonkey` from python2...python3 and maybe obtain its re-inclusion into the ports tree?


----------



## astyle (Aug 3, 2021)

jb_fvwm2 said:


> So theoretically someone with enough time and money could change `seamonkey` from python2...python3 and maybe obtain its re-inclusion into the ports tree?


Good luck with that... we're still trying to do that with KDE. I don't think that money has a place in that conversation, though (unless it's for housing the devs and renting server bandwidth).


----------



## bobmc (Aug 4, 2021)

There was another forum about software packaging which might be related to this discussion.








						Possibility to port snapd/flatpak for FreeBSD
					

Hi partners!  I recently studied about sandboxing formats of package distribution like Flatpak and Snap, and I realized that don´t exist ports our plans, at least from the flatpak / snap community, to port snapd or flatpak for others Unix-like operating systems, after some research I undestand...




					forums.freebsd.org
				




Apparently, snaps are easy to use (on Linux) but complicated to implement however it might stimulate thinking about something simpler.


----------



## astyle (Aug 4, 2021)

bobmc said:


> There was another forum about software packaging which might be related to this discussion.
> 
> 
> 
> ...


PC-BSD (a.k.a. TrueOS, and defunct since 2020) actually tried that with PBI packages....


----------



## Menelkir (Aug 4, 2021)

As I said before (I don't remember where) that the only reasonable one that could be "adapted" in a similar way is appimage, because it's basically an image with the deps inside that you run like ./name_of_the_image (pretty clean in my opinion, without directory hell, without fuzz, readable). Flatpak and snap have their own issues (bad ones), I'm happy that FreeBSD doesn't have this kind of contraptions (some linux distributions even makes you required to use, because the developers are lazy to port more applications and they just re-roll ubuntu/debian/arch to another new contraption that will be abandoned in some months/years).


----------



## astyle (Aug 4, 2021)

Let's try staying on the topic... This thread is about reasons not to use Python/Perl/Rust (Due to the fact that modules for those languages have a propensity to recursively pull in deps from repos, and that is a security risk on several fronts).

One issue that I see with repos is that they all seem to reinvent the wheel. Python has NumPy, Perl has a few Math libs/modules that implement very similar functionality, and the same thing can be probably said for Rust, as well. All 3 languages do provide OpenBLAS API. But if you don't have a repo, just a few project-specific libs that get compiled and installed (like devel/llvm, you have to implement the missing functionality from ground up, rather than pull in something premade from a repo.


----------



## Jose (Aug 4, 2021)

kpedersen said:


> I think Java (and thus CSharp.NET) are one of the few examples of non-C languages that have not fallen for this trap.


While it's possible to write clean and taut core Java, very few people do, unfortunately. The Java landscape is dominated by monstrosities like Spring, Maven, and Gradle. We wrote a "lightweight" alternative to Spring at work 'cause the latter was such a pig it was actually causing noticeable problems on modern hardware. Even our alternative drags in hundreds of crapware packages. One of the worst I've had the misfortune of looking into is the Hibernate Validator framework. Hundreds of classes most of which are facades, factoryFactories, abstractStrategies, and adapterAdapters. It makes me sad.

I once sent a partner some sample code with the following instructions for compiling it and running it:

```
javac SampleCode.java
java -cp . SampleCode
```
Senior Java Engineer was completely lost. I had to call him and hand-hold him through the process.


----------



## astyle (Aug 4, 2021)

Jose said:


> Senior Java Engineer was completely lost. I had to call him and hand-hold him through the process.


ROFLMAO, seriously??? How did he even get the job if he doesn't know the basic ropes of Java??? 

Worst part is, people in such jobs would not even consider the possibility that somebody lower on the totem pole just might actually be able to follow simple instructions. A Senior Java Engineer would call in an expensive outside consultant instead, with the reasoning that "If I cannot figure that out, it's not reasonable to expect anyone at my shop to be able to do that... I better call outside help, even if it costs a truckload of money".


----------



## Tieks (Aug 4, 2021)

Jose said:
			
		

> Hundreds of classes ...



Some people make a living of maintaining software like that. They will never run out of work, I suppose. Don't ask why they're using those classes, just because it's available for free mostly. And don't even think about asking for documentation, the last version was generated 5 years ago.


----------



## kpedersen (Aug 4, 2021)

Jose said:


> very few people do


Yeah that is a good point. With Java you have almost the opposite problem. Rather than hundreds of little ratty dependencies the Java developers favor these *big* systems that are just massive inflexible monstrosities that provide more red tape than anything else (possibly why IBM is still so interested in Java )



Jose said:


> Senior Java Engineer was completely lost.


Ugh, where I used to work 99% of the developers didn't quite understand what a compiler was and couldn't even make a hello world compile without Microsoft Visual Studio and that stupid "play" button. It often puzzles me how someone with so called passion or skills in a trade can be so oblivious.


----------



## astyle (Aug 4, 2021)

My biggest complaint about Java is not just the size and complexity of stuff like Maven, Gradle, and the rest. A lot of it is actually installable as  separate packages, so you can actually set up a repo for them. My complaint actually revolves around the 'Why' of these things. Most of the time, it's some kind of pile-of-crap verification (against initial programmer stupidity) and performance metrics. Sure, it's nice to be able to have an API that works with huge databases like Oracle or NoSQL or with huge zettabyte-sized disks - but come on, no need to get that frustratingly complicated. And then you wonder why Senior Java Engineers are so lost and confused.


----------



## Tieks (Aug 4, 2021)

kpedersen said:
			
		

> where I used to work 99% of the developers didn't quite understand what a compiler was



You probably coded with an editor and used the command line to compile, link and run. And yes, I am that old too. With modern IDE's however there is no need for all that. No wonder people who grew up with IDE's don't know the difference between javac and java. Many have no idea of what is going on underneath that IDE.


----------



## astyle (Aug 4, 2021)

Tieks said:


> You probably coded with an editor and used the command line to compile, link and run. And yes, I am that old too. With modern IDE's however there is no need for all that. No wonder people who grew up with IDE's don't know the difference between javac and java. Many have no idea of what is going on underneath that IDE.


I know about both, and I still get lost in Visual Studio. When I had to use it for a class in college, I had to ask for some coaching on how to use it - the compile/make button was not the most obvious thing. In Android Studio (which wants Gradle, BTW), you can just push a button and have it spit out an APK that you can straight install on your phone. But VS - just setting up for coding a simple helloworld took a long time for me. Setting up to code the exact same thing in command line - 15 minutes of typing, and I have a runnable a.out!


----------



## kpedersen (Aug 4, 2021)

Tieks said:


> With modern IDE's however there is no need for all that. [...]
> Many have no idea of what is going on underneath that IDE


True, though the concept of an IDE is pretty ancient and stems from MS-DOS where because it lacked true multi-tasking you could only run *one* program, it had to be all integrated into one monolithic thing. I actually learned on the Borland C++ 3.1 IDE first but then switched to the more modular tools (i.e vi, cc, grep, etc) much later because I realized it was a more efficient workflow and I was able to easily access "modern" workstations (that said, Watcom vi, wcl and wgrep were great tools for DOS. Coupled with DESQview, offers better tooling than I see most of my collegues using over 20 years later!).

A lot of IDE guys think they can stay confined to an IDE. But only because they leave the hard tasks to those with a little bit more of indepth knowledge of the underlying tools. Things like setting up build systems, remote debugging, complex VCS processes simply are out of reach.


----------



## astyle (Aug 4, 2021)

Seems like interpreted languages like Python and Perl have little ratty deps that recursively get dragged in from remote repos, and are a security risk. Compiled languages like Java and C/C++ do have huge frameworks and classes and libs included/installed, but are often unwieldy, and those frameworks seem ultimately rather pointless.


----------



## kpedersen (Aug 4, 2021)

astyle said:


> Compiled languages like Java and C/C++ do have huge frameworks and classes and libs included/installed, but are often unwieldy, and those frameworks seem ultimately rather pointless.


I would say that C currently provides the best middle ground. There are much fewer large frameworks than Java and one of the most important things to note is that Python, Perl, Java, etc *all* depend on the underlying C libraries anyway. So no other language can ever quite cut down on dependencies better than C. They will always have more.

The only way this can be changed is if an entire OS is built using a different systems language. Currently it looks like Rust / RedoxOS is closest but they are millions of man hours behind UNIX at this point. It won't be in our lifespans it can catch up. Not to mention one of the first things the OS included / wrote was a libc meaning that they are going in the wrong direction anyway.


----------



## astyle (Aug 5, 2021)

RedoxOS is not POSIX-compliant... they say so straight out on their own web page. Right now, it's just a proof-of-concept. Would be interesting to see if OpenBSD agrees to get re-implemented in POSIX-compliant Rust code.  Oh, and let's run KDE on top of that, while we're at it!


----------



## kpedersen (Aug 5, 2021)

To be fair, I don't think early UNIX was POSIX compliant (as we know it today) either. Many Linux distros aren't either. Even still, RedoxOS has very far to go. But, perhaps it can overtake GNU Hurd one day.

I do enjoy some of the Rust OpenBSD drama. It seems that until Rust can self-host on 32-bit platforms, they aren't going to consider doing anything with it. There are too many platforms that Rust (mainly its C LLVM backend) doesn't support.


----------



## bobmc (Aug 5, 2021)

Re - Another reason not to use Python -  Well it is often used as a tool to configure a software thing to work multi-platform.  It is the most likely cause of a failed install. And when I try to fix it, the scripts seem to be done in a hurry with no modular organisation. I am a C programmer. I bought books on Python and Rust but did nothing with them because of language syntax and Rust tedium.

I don't believe that BSD and Linux Kernels will be redesigned from C to any other language. C can be used for an infinity of programs. C is designed for processors and the processors are designed for C.  They are good friends.


----------



## astyle (Aug 5, 2021)

bobmc said:


> Re - Another reason not to use Python -  Well it is often used as a tool to configure a software thing to work multi-platform.  It is the most likely cause of a failed install. And when I try to fix it, the scripts seem to be done in a hurry with no modular organisation. I am a C programmer. I bought books on Python and Rust but did nothing with them because of language syntax and Rust tedium.
> 
> I don't believe that BSD and Linux Kernels will be redesigned from C to any other language. C can be used for an infinity of programs. C is designed for processors and the processors are designed for C.  They are good friends.


Not to mention that most of the languages in existence are merely syntactic abstractions over C, spiced with either including too much from get-go or recursing too much from get-go, all in the name of functionality.


----------



## bobmc (Aug 6, 2021)

kpedersen said:


> It seems that until Rust can self-host on 32-bit


It can also do some Lisp tricks:-
`let list = Cons(1, Cons(2, Cons(3, Nil)));`
Perhaps the Rust designer did not know when to stop.

BTW, using Lisp you can design your own application language without irrelevant features.


----------



## kpedersen (Aug 6, 2021)

bobmc said:


> BTW, using Lisp you can design your own application language without irrelevant features.


It reminds me of this book (http://www.buildyourownlisp.com/). A really good read.

Learn C, build your own lisp. Then write the language you want


----------

