Red Hat's New Graphics Engineer Is A Longtime AMD/ATI Linux Developer

[blackiwid]

I've never found Python that easy to get or I've just looked at the wrong code examples, but something about the way it handles variables and the self.something stuff never quite jived with me. Every time I've ever tried to learn Python I get to around a chapter 3 or 4 in a guide and get discouraged by thoughts of "I feel like this variable system is fighting against me." and "Shouldn't I focus on something "better" like C or Rust?".

Python has many design problems. It is great for having a language that you basically 1:1 use pseudocode and it just runs.

It's great to learn the basics (with some small limitations) but the deeper you go into and the bigger your code base get's the more it shows it's big design problems.

Let me name a few bigger problems:
1. no blockscope
2. to much syntax (I go deeper into that)
3. incorrect if/else statement (that is not only true for python)
4. hard to get much speed out of it.
5. very focused on using much variables
6. to few constructs.

That are of course only some headlines that tackle down to other stuff. No blockscope should be obvious. that means that you have to care that if you have maybe 2 loops with a iterator that you make sure that it got reseted, which can lead to many mistakes that produce no error just by changing the order of blocks much side effects.

The biggest problem is, to much syntax, the major guy behind Python hated functional stuff, and therefor created a separate language for it with crazy special syntax.

Like such:

isApple = True if fruit == 'Apple' else False

when the normal if else has different syntax. Also with lambda:

(lambda x: x + 1)(2)

Very special syntax that is completely different from as example a name function variant:

def add1 (x):
  return x + 1
...
add1(2)

Not only have you different syntax which lets you refactor the one to the other (maybe you used quickly a lambda but noticed that you need that function on more places and want a named function) very painful, you need either a very intelligent (in proprietary python ides those exist) refactoring tools or you have to do lots of steps by manually.

You also need to learn the lots and lots of different syntaxes. But you also become problems using lambdas that go over several lines. Because python is basically build around the assumption that you only have short lines that don't go longer than 1 line except multiline-comments.

You need something like that:

fn = lambda x: 1 if x \
                           else 2

yet people will say you for longer stuff use def. So you get nearly forced to not use lambda.

About the incorrect if statement it represents not the block logic.

So idealy you have somethnig like:

if X:
  then:
    foo ()
  else:
    bar ()

because else is a subblock from if logically, else alone is no block. so it's a subblock.

Which is correctly done in lisp:

(if x (foo) (bar))

But that is not lisp specific all c-like languages have this horrible notation that aperently got introduced back in SBCL days from the inventers of the C language. Horrible design decition in my opinion.

Because multiline Lambda don't exist you need to seperate your code parts into smaller peaces and have more interim results and safe them in variables, which forces you to think of 1000 variable names.

About the two few constructs you could say I complained about to much syntax and now I want more constructs but a different construct don't need to have a different syntax it just can have a different name. So they don't have a switch/case statement so you usually see code like that instead:

if x < 0:
    x = 0
    print('Negative changed to zero')
elif x == 0:
    print('Zero')
elif x == 1:
    print('Single')
else:
    print('More')

again in (e)Lisp you have the pcase macro:

(print
 (pcase x
   ((pred (lambda (i) (< i 0)))
    (setq x 0) "Negative Changed to zero")
   (0 "Zero")
   (1 "Single")
   (_ "More")))

which purely compared line and charakter based is not that much different, but it is less repetitive therefor easier to refactor or just to change.

4 times print and 4 times "x" vs 1 print and 2 times "x". More DRY code therefor better. And yes there are ways to do that with lisp comprehension in python but A that is very advanced and B also not much better / cleaner.

In this example the negative number check would not be possible with list comprehension as far as I know. So in this specific example it would not be a option but also because there is a x=0 statement list comprehension would need to use functions as return value and not values that would mean 4 defined functions for the 4 possible conditions, which again would mean lot's of repetitive code. 4-5 function heads...

that are some of the problems I have with python but for small shell scripting it's good enough I guess