Another reason not to use python?

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
Click to expand...
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.
 
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.
 
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.
Click to expand...
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.
 
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!
 
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.
 
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.
 
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.
Click to expand...
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.
 
kpedersen said:
It seems that until Rust can self-host on 32-bit
Click to expand...
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.
 
You must log in or register to reply here.
Back
Top