It seems that you're using an outdated browser. Some things may not work as they should (or don't work at all).
We suggest you upgrade newer and better browser like: Chrome, Firefox, Internet Explorer or Opera

×
avatar
Darvond: My understanding is that Python is the BASIC of the modern age. Absolutely fine if you're doing things slightly more advanced than shell scripts, but you should consider going to deeper languages.
I have to disagree with that.

Don't tell that to them: https://www.openstack.org/

Or them:

https://numpy.org/
https://pandas.pydata.org/

I think Python is great for A LOT of serious software. You just need to be mindful of the performance impact and the interpreter/package dependencies.
Post edited December 16, 2021 by Magnitus
avatar
Crosmando: Isn't it generally accepted that Python is a shitty programming language that only became well-known because Google was shilling it relentlessly for a decade or so?
Python is actually a really nice language for writing code in.

Some users find Python's dynamic typing to be annoying for larger code bases, but at least type mismatches tend to result in an error.

Explanation:

* The following code works thanks to dynamic typing
x = 3
x = "three"
(In other words, a variable can change type. Note, also, that variables don't need to be declared ahead of time, which cau cause issues if there's a typo.)

* You can't, however do the following:
x = 1 + "1"
(Perl silently converts "1" to a number and sets x to 2. JavaScript silently converts 1 to a string, and sets x to "11". Python will give an error to the effect of "can't add a number and a strong".)

(It's better to get an error message right away than have the program silently run and have a bug you need to track down later.)
avatar
Crosmando: Isn't it generally accepted that Python is a shitty programming language that only became well-known because Google was shilling it relentlessly for a decade or so?
avatar
Orkhepaj: oh is it a programming lang? why would anybody name it a snake then? makes no sense

hmm
checking it out looks like it is used by apple fans
Actually, I believe Python grew up on Linux or some UNIX variant. In fact, Python is in the standard install of many Linux distributions, and is even essential in some. For example. Gentoo's emerge program, which you use to install software, is written in Python (which means that removing Python, which emerge will refuse to do, would prevent you from easily re-installing it).

Also, I believe the language is actually named after Monty Python.
avatar
lupineshadow: Stop chatting shit mate. Python is awesome.

It has a bad rep because of some old tropes though

"That Django's got your baby"
avatar
Magnitus: Python is the most productive programming language that I know. If you're gonna do everything with one language and nothing you'll do will be too cpu intensive, Python is probably your Huckleberry.

That being said, compared to most other programming language, it runs pretty slowly, it has a dependency on the Python interpreter, plus any package you require, to run and last I checked, the packaging and bundling ecosystem for Python was rather fragmented.

If you're ok with knowing more than 1 language, for some specific problem domains (ex: Golang for devops on cloud solutions or for command line clients, Scala for big data, NodeJS or Golang for high performance io intensive web servers, C or Rust for performance critical system-level components, etc), better alternatives can often be found.

Also, imho, Flask > Django. It is less opinionated and more minimalistic.
There's a trade-off between programmer time and CPU time. In many cases, programmer time is more important, and Python takes less of it than some other languages. Hence, if you want to get the project completed faster, or if you just want to make a prototype before you re-write in a higher performance language, Python is the ideal choice (or at least close to ideal).

avatar
Orkhepaj: so it is not as slow as those java apps?
which is better java or python?
avatar
Magnitus: I'm not a Java fan so I'd be biased in that answer.

Over the years, I've specialized in C++, Python, NodeJs and more recently Golang. I've done some Java on and off but it never stuck (and after tackling some codebases implemented with Spring in later years, I can say I want to have as little to do with the modern Java ecosystem as humanly possible).

Java is often accompanied by burdensome frameworks (ex: Spring, JBoss, etc) that add a significant complexity overhead to anything you do (and are old-school in their opinions, they often assume for example that your Java app will be a persistent standalone application and won't be managed by an orchestrator like kubernetes or even systemd) and is dependent on the ram-hungry, slow to boot JVM (which also needs to be installed on whatever machine Java runs), which in the age of containers, leaner virtual machines and cross-platform compilation that produces self-contained binaries for a lot of platforms anyways, is a step backwards in my opinion.

That being said, in terms of cpu utilisation, yes, Java > Python, but for those use-cases, I much prefer to use Golang.
Java is also opinionated about your choice of programming paradigm.

In particular, Java essentially forces object oriented programming. You can't even write a basic Hello World program without declaring a class and a member function, with something like 8 keywords that someone unfamiliar with OOP is not going to understand. By contrast, in C, all you need to do is write a single function, with void parameters and a simple return type, and it will run.

(C is a decent language, at least until you're dealing with strings or dynamic memory.)
Post edited December 16, 2021 by dtgreene
avatar
Orkhepaj: hmm so what kind of development doesnt require an IDE with lots of helper modules?
You don't need any for simple scripts; it's only when you scale thing up that you'll find the need for that sort of thing.

In particular, simple shell scripts and Python scripts don't need such tools, particularly if the project is small enough to keep it in a single file while still having it be manageable.
avatar
dtgreene: There's a trade-off between programmer time and CPU time. In many cases, programmer time is more important, and Python takes less of it than some other languages. Hence, if you want to get the project completed faster, or if you just want to make a prototype before you re-write in a higher performance language, Python is the ideal choice (or at least close to ideal).
There is a tradeoff, but the tradeoff is not binary, its a scale.

In terms of cpu/dev time tradeoff:

C > Golang > NodeJS > Python

It will take me about 3 times longer to write the same functionality in C than Python, for like 100x the performance.

It might take me 1.3-1.5 times longer to write the same functionality in Golang, for maybe 30x the performance.

For a lot of use-cases, that tradeoff favors Golang, but not C, over Python.

Also, there is tooling to consider.

If I want to write a Terraform provider, there is an sdk in Golang, but not Python (that I'm aware of, if there is, its unofficial). That makes Golang A LOT faster to develop in to write a Terraform provider.

Also, if I want to run a client on user-machines, with Python, I need to bundle the interpreter and packages in the binary if I want a self-contained binary, which will bloat the size of the binary considerably (and is also an overhead in terms of packaging the final deliverable).
avatar
Darvond: My understanding is that Python is the BASIC of the modern age. Absolutely fine if you're doing things slightly more advanced than shell scripts, but you should consider going to deeper languages.

As for a spambot suggesting websites be built with python instead of javascript, that is an interesting thought, too bad I have to tell the OP to FOAD.

Personally, I'm interested in seeing what going from C to Rust does.
Python is great for glueing together code written in different languages, particularly if shell script isn't suitable for the use case or isn't portable enough. (Shell script is *horrible* for things like number crunching, for example.)

Sometimes, you might need to do a quick repetitive task, or you need to do some quick number crunching that shouldn't take too much CPU time; in those cases, Python is great.

Comparing C to Rust, I notice that:
* Rust is a lot harder to write.
* It is a lot harder for Rust code to actually compile.
* Rust's stdlib is more bare bones than C's. (In particular, I still don't know how to do input from stdin without just calling the C stdlib.)
* If you manage to get Rust code to compile, it is very likely that it will be bug-free, or at least not have the sort of bug that's a pain to debug.

avatar
Magnitus: There is a tradeoff, but the tradeoff is not binary, its a scale.

In terms of cpu/dev time tradeoff:

C > Golang > NodeJS > Python

It will take me about 3 times longer to write the same functionality in C than Python, for like 100x the performance.

It might take me 1.3-1.5 times longer to write the same functionality in Golang, for maybe 30x the performance.

For a lot of use-cases, that tradeoff favors Golang, but not C, over Python.
Then again, one situation where Python is favored would be something like this:
* In Python, the code takes only a few seconds to run.
* The program isn't going to be run frequently. In fact, it might only be run once.

In that case, even if the performance difference is noticeable, it still doesn't make sense to re-write it in a faster language.

avatar
Magnitus: That being said, in terms of cpu utilisation, yes, Java > Python
Only if the program will run long enough so that one can neglect the JVM startup time.

A Hello World program is going to be much faster in Python (assuming the interpreter is in the disc cache (which it would be on any system that frequently runs Python code)) and use significantly less CPU time.
Post edited December 16, 2021 by dtgreene
avatar
dtgreene: Comparing C to Rust, I notice that:
* Rust is a lot harder to write.
* It is a lot harder for Rust code to actually compile.
* Rust's stdlib is more bare bones than C's. (In particular, I still don't know how to do input from stdin without just calling the C stdlib.)
* If you manage to get Rust code to compile, it is very likely that it will be bug-free, or at least not have the sort of bug that's a pain to debug.
Then why is the Linux Kernel starting to get converted from C to Rust? (Read here.)
avatar
dtgreene: Comparing C to Rust, I notice that:
* Rust is a lot harder to write.
* It is a lot harder for Rust code to actually compile.
* Rust's stdlib is more bare bones than C's. (In particular, I still don't know how to do input from stdin without just calling the C stdlib.)
* If you manage to get Rust code to compile, it is very likely that it will be bug-free, or at least not have the sort of bug that's a pain to debug.
avatar
Darvond: Then why is the Linux Kernel starting to get converted from C to Rust? (Read here.)
The kernel is different, plus the points I made aren't entirely bad. I also note that they're not re-writing the entire kernel in Rust; the first bits of Rust are going to be in drivers and similar leaf modules, not in the core that many things depend on.

Rust is a lot harder to write:
* For a kernel, this is probably OK, particularly since kernel code can be difficult to get write.

Harder for Rust code to compile:
* That's because Rust has safeguards to prevent certain types of bugs. Many of these bugs would likely cause a segmentation fault in userspace, but in the kernel, you don't have such nice behavior (though I might expect the kernel to trap the memory access and panic or oops if this happens).

Rust's stdlib being more bare bones than C's:
* stdlib is for user-space applications; we don't have C's stdlib available when working on the kernel, so this point doesn't really make sense at this point. You might have some functions like memcpy() available, but certainly none of the I/O or memory allocation functions (instead, you need to use in-kernel functions like kprintf() or kmalloc(), or access the hardware directly if you're a driver for that hardware). Similarly, you're not going to have rust's std, and will have to just use core, perhaps with some of the in-kernel functions adapted to Rust usage. (One nice thing about Rust is that it's easy to call C from Rust and vice versa, provided the Rust function has a C compatible signature.)

Rust code is more likely to be bug-free if it does compile:
* Isn't this a *good* thing, and a reason in favor of using Rust?
low rated
avatar
dtgreene: There's a trade-off between programmer time and CPU time. In many cases, programmer time is more important, and Python takes less of it than some other languages. Hence, if you want to get the project completed faster, or if you just want to make a prototype before you re-write in a higher performance language, Python is the ideal choice (or at least close to ideal).
Wow, wow, wow, wow...

Hi dtgreene,

This statement really caught me. I've never heard about trade offs between programmers and CPU times.
Would you mind to provide some references about it please? Because I find it a total non-sense... but you know... my ignorance is the worst adviser, so I'd really like to read and learn about that to forge an opinion.

Thanks in advance
low rated
why would anybody convert a kernel that makes no sense at all

why not just build a new one better with modern design ?
avatar
singhamrit: Python is a widely-used general-purpose programming language. It is used for web development and scientific computing often.

<SNIP>
Logically you can use just about any tool to make a website, at least at the simplest way. If i could feed output of say a awk program out to a port that is being sent to other people, and it happens to have html text, then you get the typical website results.

Getting input from what the Post/GET types are to make it actually usable would merely be a simple library or a way to accept said information. PHP you'd get that information in a variable as an array of data.

After that what else you use for database (or files) is mostly up to you. But that's a bare-bones minimal approach.
avatar
tag+: I've never heard about trade offs between programmers and CPU times.
CPU time is much cheaper than developer time ;)
This is the main reason we target "good enough" code in enterprises, but hobbyist open-source software tend to have much higher quality standards.

---

avatar
Orkhepaj: why would anybody convert a kernel that makes no sense at all
You’re the only one here talking about the NT kernel…
Post edited December 17, 2021 by vv221
low rated
avatar
tag+: I've never heard about trade offs between programmers and CPU times.
avatar
vv221: CPU time is much cheaper than developer time ;)
This is the main reason we target "good enough" code in enterprises, but hobbyist open-source software tend to have much higher quality standards.

---

avatar
Orkhepaj: why would anybody convert a kernel that makes no sense at all
avatar
vv221: You’re the only one here talking about the NT kernel…
talk when you reached 2% market share :)
that means never :P
Post edited December 17, 2021 by Orkhepaj
avatar
tag+: Wow, wow, wow, wow...

Hi dtgreene,

This statement really caught me. I've never heard about trade offs between programmers and CPU times.
Would you mind to provide some references about it please? Because I find it a total non-sense... but you know... my ignorance is the worst adviser, so I'd really like to read and learn about that to forge an opinion.

Thanks in advance
Its simple. I need to deliver to production by January 12th and I cost my employer 6 figures.

If I write things in a high level language, I'll make the deadline. If I write in C, I won't (because it will take me at least 3 times longer).

Alternatively, my employer could hire 3 people like me to compensate (which would likely bust his budget) which may or may not help depending on the problem domain (in this case, I can confirm it wouldn't help that much).

As it turns out, the operational code that I write doesn't need to have C-level efficiency in cpu utilisation (right now, I'm writing infrastructure as code and I guarantee you we won't need to provision 1 million virtual machines per second... that would definitely bust my employers' hardware budget).

Hence, I'm not doing it in C.
Post edited December 17, 2021 by Magnitus
low rated
avatar
tag+: Wow, wow, wow, wow...

Hi dtgreene,

This statement really caught me. I've never heard about trade offs between programmers and CPU times.
Would you mind to provide some references about it please? Because I find it a total non-sense... but you know... my ignorance is the worst adviser, so I'd really like to read and learn about that to forge an opinion.

Thanks in advance
avatar
Magnitus: Its simple. I need to deliver to production by January 12th and I cost my employer 6 figures.

If I write things in a high level language, I'll make the deadline. If I write in C, I won't (because it will take me at least 3 times longer).

Alternatively, my employer could hire 3 people like me to compensate (which would likely bust his budget) which may or may not help depending on the problem domain (in this case, I can confirm it wouldn't help that much).

As it turns out, the operational code that I write doesn't need to have C-level efficiency in cpu utilisation (right now, I'm writing infrastructure as code and I guarantee you we won't need to provision 1 million virtual machines per second... that would definitely bust my employers' hardware budget).

Hence, I'm not doing it in C.
nice , can i join?
avatar
Orkhepaj: nice , can i join?
Unless you genuinely care about that kind of stuff, if you're gonna put this amount of effort into something, there are easier ways to make more money, trust me.

I'm essentially a highly skilled laborer. Don't get me wrong, the kind of skill I honed (and am still honing, its a never-ending process) gives me leverage to negotiate a salary that is a lot higher than what a factory worker can aspire to, but ultimately, if you want to make crazy money (and if you put the kind of effort I put in my career into something, crazy money is not that far fetched), go into management, finance or own a company.
Post edited December 17, 2021 by Magnitus