/prog/ - Programming

Please help list more reasons.

it brings people like OP to this board.

>>2862

According to some internet pleb the core modules don't even respect the naming conventions.

>>2871

Also a good point.

>>2862

>"Annoying indentation syntax that can't even mix tabs with spaces"

>implying this is a bad thing

>implying bikeshed arguments in every fucking project about indentation was valuable

Shut up and write code.

>>2888

This fuck sake don't hate on a language every language has problems. I guarantee you only wrote this because you think python is too easy and you want to feel superior with your c ++ template syntax or whatever fucking language you use

>>2969

>don't hate on a language every language has problems

Do a significant amount of work in the M programming language and then come back and say that.

There are legitimately bad languages. I don't think Python is bad (though it is pretty slow), but in a world with Javascript and PHP, how can you say "don't hate on a language"?

>>2862

>- Slow & inefficient performance

That's the fault of the interpreter, not the language.

>- Annoying indentation syntax that can't even mix tabs with spaces

"Durrr, I can't indent like a normal human being so it's the languages fault."

I don't want to see my text editor's default tab sized mixed in with whatever amount of spaces you like to use. You shouldn't mix tabs with spaces, you retarded fuck.

>>2992

>That's the fault of the interpreter, not the language.

Not OP, but you better be aware of cancerous semantic constructs, that require sophisticated JIT compilers to get ok-tier performance on average. Yes, that's a languages design failure.

There is only so much what even an advanced JIT compiler can do and for Python the bar is below Java.

It's also simply not the case that Python has impressive compilers at the moment.

With Cython and Nuitka you only get noteworthy gains if you don't use normal semantics.

And while PyPy is an interesting research project, the compiler itself isn't blowing the fuck out of anything. It also doesn't really support Python 3.

Your best bet is to hope for a Graal-based VM, but I won't be waiting for it.

>>3006

python doesn't need to be fast, performance rarely matters for script languages.

it's way faster than java because it doesn't need to load up some shitty runtime environment first and it clearly beats bash at everything.

of course python sucks for large applications but the only thing that matters for scripts is how quickly you can write them, and python is pretty good at that.

idk about other languages but apparently it's the only language with which even non-programmers can achieve something.

if you want to write a large application just use c++11 and use smart pointers for everything that's used less than… idk.. a million or billion times per second.

>>3010

>way faster than Java

100% grade-A bullshit.

>>3010

>python doesn't need to be fast

Python does need to be fast. The incredibly slow start-up time is why it never was able to replace shellscript which was a very important goal that redhat had hoped it would achieve. Shellscript is Linux's cancer - the impossibly slow execution time and non-existent data structures coupled with abysmal error handling diseases everything it comes in contact with and is the main source of slow & broken in Linux.

>>3011

>>3017

/thread

>>3017

Please don't generalize, unix shells are ordinary user programs, it's not a synonymous with bourne/bash

>>3017

The Unix shell will never be replaced with a full-featured programming language.

It's a fucking language shell. If a shell can't launch a command just by typing that fucking command, it's not useful as a shell.

Similarly, if you want to make a script that mostly just launches and uses a couple commands, why would you use a real language.

You can't really claim that any real programming language is going to replace shell scripting, when the use-cases are so fucking different; it's an entirely different paradigm.

> the main source of slow & broken in Linux.

Not at all. The main source of slow and broken in Linux is huge programs built on slow languages. Calibre is an example of this. Portage is another. I love my Gentoo as much as the next autist, but just doing a

emerge -uDNp @world

Shell scripting is never used for CPU-intensive shit. Hell, most real programs will use it just to set environment variables and such before launching the real program, if at all, so that's not a source of any kind of slow or broken. Are you referencing anything in particular? What have you seen shell scripts do slowly or broken on a real system (as in something you installed through the package manager, not a broken-ass script you found on the internet or cobbled together) that should have been done in a different language?

OP left out the whole bullshit 2.6 - 3x python boondoggle.

tfw every school is now dumping Python and embracing Racket as their default teaching language because of problems students have had with Python. Typed Racket is also straight baller, and now being taught as intro CS at Chicago U https://www.classes.cs.uchicago.edu/archive/2014/fall/15100-1/

>>3022

>never replaced by a full featured language

uhh, was a long time ago with csh/tsch

there's also a dozen various scheme/racket/lisp shells

You can use Emacs to fully script and abstract away your shell with tsch or clisp shell. Not everybody sits there typing commands into an interpreter some of us control a thousand boxes and want to automate this without shitty bash scripts

>>3033

>csh/tsch

You must be fucking joking. csh is inconsistent shit even compared to Bourne, with 3 different ways to set variables, broken inconsistent syntax between the ways, and no real decent way to manage standard file handles.

Lisp shells aren't real shells, they're mostly some convenience functionality around Lisp. A REPL for a programming language that can also call native commands is no substitute for a real shell, and also tends to lack the real shell functionality that is necessary for sysadmins, like variable interpolation, command substitution, process substitution, heredocs, flexible file descriptor redirection, and the like.

There's a reason that languages that are designed to work as shells are used as shells, and languages designed as real programming languages are used as programming languages.