Skip to content

Instantly share code, notes, and snippets.

@RobertAKARobin
Last active February 1, 2023 21:34
Embed
What would you like to do?
Python Is Not A Great Programming Language

Python is not a great programming language.

It's great for beginners. Then it turns into a mess.

What's good

  • A huge ecosystem of good third-party libraries.
  • Multiple inheritance.

What should be good

  • It's easy to learn and read. However, it's only easy to learn and read at the start. Once you get past "Hello world" Python can get really ugly and counterintuitive.
  • The Pythonic philosophy that "There should be one -- and preferably only one -- obvious way to do it." As someone who loves working within rules and rigid frameworks, I love this philosophy! As someone who writes Python, I really wish Python actually stuck to this philosophy. See below.

What's "meh"

  • Forced indentation. Some love it because it enforces consistency and a degree of readability. Some hate it because they think it enforces the wrong consistency. To each their own.
  • Dynamic typing. There are lots of dynamically-typed languages and lots of statically-typed languages. Which kind of typing is better isn't a Python debate, it's a general programming debate.

What's bad

  • 400 ways (more or less) to interpolate strings. This prints "Hello Robin!" 3 times:

    user = {'name': "Robin"}
    print(f"Hello {user['name']}!")
    print("Hello {name}!".format(**user))
    print("Hello %(name)s!" % user)
    

    If there was a unique and obvious use-case for each of these then that would be one thing, but there's not.

  • 69 top-level functions that you have to just memorize. GvR's explanation sounds nice, but in reality it makes things confusing.

  • map doesn't return a list, even though the whole point of a mapping function is to create one list from another. Instead it returns a map object, which is pretty much useless since it's missing append, reverse, etc. So, you always have to wrap it in list(), or use a list comprehension, which, speaking of...

  • List comprehensions are held up as an excellent recent-ish addition to Python. People say they're readable. That's true for simple examples (e.g. [x**2 for x in range(10)]) but horribly untrue for slightly more complex examples (e.g. [[row[i] for row in matrix] for i in range(4)]). I chalk this up to...

  • Weird ordering in ternary/one-line expressions. Most languages follow a consistent order where first you declare conditions, then you do stuff based the on those conditions:

    if user.isSignedIn then user.greet else error
    
    for user in signedInUsers do user.greet
    

    Python does this in the opposite order:

    user.greet if user.isSignedIn else error
    
    [user.greet for user in signedInUsers]
    

    This is fine for simple examples. It's bad for more complex logic because you have to first find the middle of the expression before you can really understand what you're reading.

  • Syntax for tuples. If you write a single-item tuple (tuple,) but forget the trailing comma, it's no longer a tuple but an expression. This is a really easy mistake to make. Considering the only difference between tuples and lists is mutability, it would make much more sense to use the same syntax [syntax] as lists, which does not require a trailing comma, and add a freeze or immutable method. Speaking of...

  • There's no way to make dicts or complex objects immutable.

  • Regular expressions require a lot of boilerplate:

    re.compile(r"regex", re.I | re.M)
    

    Compared to JavaScript or Ruby:

    /regex/ig
    
  • The goofy string literal syntaxes: f'', u'', b'', r''.

  • The many "magic" __double-underscore__ attributes that you just have to memorize.

  • You can't reliably catch all errors and their messages in one statement. Instead you have to use something like sys.exc_info()[0]. You shouldn't have a catch-all in production of course, but in development it's very useful, so this unintuitive extra step is annoying.

What's bad about the culture

Most programmers will acknowledge criticisms of their favorite language. Instead, Pythonists will say, "You just don't understand Python."

Most programmers will say a piece of code is bad if it's inefficient or hard to read. Pythonists will say a piece of code is bad if "it isn't Pythonic enough." This is about as helpful as someone saying your taste in music is bad because "it isn't cultured enough."

Pythonists have a bit of a superiority complex.

@nslay
Copy link

nslay commented Oct 24, 2022

Only use case for single item tuples I can think of is for initializing with repeated values.
For example:

zeros = (0,)*10 # Create a tuple of 10 zeros.

This kind of operator overloading is far far worse than anything you could claim of C++'s operator overloading on streams.

@edhemphill
Copy link

edhemphill commented Oct 26, 2022

It unfortunately started making its way into college curriculum... which is how it got so deeply embedded in the software industry. As scripting languages go - its honestly not bad. The main pain is the package management and byzantine library folders.

The core issue is WAY too many people use scripting languages when they should be using compiled languages. In my view scripts should only be used used when you might need to quickly change something or for single use actions, like installs / deployments, or building a ML model you will use somewhere else again and again. Not for constant operation. Like a website. Or an entire startup's code base. Seems the college professors which loved python forgot to explain this.

... the amount of compute in the world wasted to due to python's incredibly slow execution. Imagine. Lol.

@0xTheSmartGuy
Copy link

Even being an interpreted language, Python is really slow than any other interpreted languages right now we have. Some folks says "speed doesn't matter" yet you also bring frustrated about how slow your program is. It's a horrible idea to use Python for backend, especially a heavy load work, as the concurrency in Python literally suck.

And please, don't conflict with ML and data science where Python is being used. They used it because they wanted to complete a task as soon as possible, there's nothing about speed but all about how easily a concept can be understand by others, same goes to school/college where Python is being taught. I honestly don't think we shouldn't use it, but we should avoid using in critical apps or services where speed, stability and reliability is most important.

Very funny, Python might with some tricks go fast seriously. TIT-PL is the proof, go, it's not so bad, since i optimized it slightly

@nslay
Copy link

nslay commented Oct 28, 2022

Yes, interpreted languages are slower IF the routines being executed are actually written in the interpreted language. Most (if not all) of the ML and numerical algorithms used in Python wrap natively compiled code. As long as you're spending more time executing natively compiled code, the Python interpreter really shouldn't be causing too much of a slow down.

OK, so if the Python interpreter isn't really an issue when using natively compiled bindings (a lot of things!), what's the problem? Remember how Python is supposed to be about readability? Fast Python scripts (numerical ones anyway) are likely to be written in ways that are alien to how people think. Having to think in terms of linear algebra and vectorization to avoid the interpreter (e.g. to avoid otherwise more readable for loops that impose NO OVERHEAD in compiled languages) leads to potentially harder to read scripts. Sure, those scripts can execute at near native speeds but people will have difficulty understanding what's happening.

This isn't really a problem unique to Python. It's all scripting languages. MATLAB especially comes to mind!

@BrianG61UK
Copy link

It unfortunately started making its way into college curriculum... which is how it got so deeply embedded in the software industry. As scripting languages go - its honestly not bad. The main pain is the package management and byzantine library folders.

The core issue is WAY too many people use scripting languages when they should be using compiled languages. In my view scripts should only be used used when you might need to quickly change something or for single use actions, like installs / deployments, or building a ML model you will use somewhere else again and again. Not for constant operation. Like a website. Or an entire startup's code base. Seems the college professors which loved python forgot to explain this.

... the amount of compute in the world wasted to due to python's incredibly slow execution. Imagine. Lol.

Yes yes. 100% agree.

@xennex22
Copy link

xennex22 commented Nov 22, 2022

Micropython. The broken scripting language moves into the embedded world, added a host of problems to the already full basket of python failings.

  • Slow. Very slow. 300-500 times slower than C/C++. Start up time can be an issue too.
  • Debugging. Or complete lack of any debugging other than printing output.
  • RAM use.
  • Flash use. 'FLASH_TEXT' overflowed by xxx. Probably with micropython is biased towards processors with external flash like the ESP32 or RP2040.
  • Threading. Or lack of. It's not a RTOS.
  • Community. Same mantra repeated (it's faster to develop!) and same toxic responses (you're not using the right hack tool!)

And please don't tell me to write in python and then embed C, or use hack tool x to get around a shortcoming on python.
I blame the RP2040, which is just sad all by itself. And old ARM core. A lack of internal flash.
Micropython. The basic stamp of the 20s.

@DIYsciBorg
Copy link

DIYsciBorg commented Dec 5, 2022

Whatever circle-jerk this is:

===================================

C:\Program Files\KiCad\6.0\bin>python.exe -m pip install --upgrade pip
Defaulting to user installation because normal site-packages is not writeable
Requirement already satisfied: pip in c:\program files\kicad\6.0\bin\lib\site-packages (22.2.2)
Collecting pip
Using cached pip-22.3.1-py3-none-any.whl (2.1 MB)
Installing collected packages: pip
WARNING: The scripts pip.exe, pip3.10.exe, pip3.9.exe and pip3.exe are installed in 'C:\Users\e_pre\Documents\KiCad\6.0\3rdparty\Python39\Scripts' which is not on PATH.
Consider adding this directory to PATH or, if you prefer to suppress this warning, use --no-warn-script-location.
Successfully installed pip-22.3.1

[notice] A new release of pip available: 22.2.2 -> 22.3.1
[notice] To update, run: python.exe -m pip install --upgrade pip

C:\Program Files\KiCad\6.0\bin>python.exe -m pip install --upgrade pip
Defaulting to user installation because normal site-packages is not writeable
Requirement already satisfied: pip in c:\program files\kicad\6.0\bin\lib\site-packages (22.2.2)
Collecting pip
Using cached pip-22.3.1-py3-none-any.whl (2.1 MB)
Installing collected packages: pip
WARNING: The scripts pip.exe, pip3.10.exe, pip3.9.exe and pip3.exe are installed in 'C:\Users\e_pre\Documents\KiCad\6.0\3rdparty\Python39\Scripts' which is not on PATH.
Consider adding this directory to PATH or, if you prefer to suppress this warning, use --no-warn-script-location.
Successfully installed pip-22.3.1

[notice] A new release of pip available: 22.2.2 -> 22.3.1
[notice] To update, run: python.exe -m pip install --upgrade pip

C:\Program Files\KiCad\6.0\bin>

===================================

(Yes, I get that path warning AFTER adding that path to my path variable.. because.. REASONS!)

For a casual / occasional user (especially from a Windows env), grocking the process of maintaining dozens of custom environments is already a PITA, and seems like it SHOULDN'T be unnecessary. But the absolute useless error output and circle-jerking of trying to update even the most rudimentary installation is maximum frustration.

Not a single thing about Python is ready for "everyone" to use. Its only ever ready for "Steve" to use (or whomever is lucky enough to just happen to have their env set precisely the way Steve did).

How many "Apps built on python" have you watched break during the installation process. For me, its been 100%. NOTHING python ever works out of the box.

@nslay
Copy link

nslay commented Dec 5, 2022

Well that's what Docker (and similar) is for... a band-aid for Python dependency nightmares. I'm not trying to justify this, just that large Python projects point you to Docker for this reason. And, IMO, that is positively hideous. Is that really the future? Every application is a virtualized OS because of dependency hell? Horrifying...

@ccrsxx
Copy link

ccrsxx commented Dec 11, 2022

Lack of null safety is the biggest problem in Python IMO

@Username2k1
Copy link

Username2k1 commented Dec 12, 2022

yes Docker was created exactly because of the shittiness of Python. That is 100% true.

Sure docker isn't heavily used for countless of services that use other programing languages. Container are.just the base of modern architectures.

No other language sucks as bad as python it is why I refuse to
learn python and wish it would just die already.

So you don't know python but loose time here whining about it ? Interesting concept

And if colleges and code camps would stop teaching this horrendous, shitty
language and move to something better this problem would be solved much
more quickly.

Maybe the problem would be solved if you tried to learn it, seems like a troll anyway.

@greypanda
Copy link

And then he goes praising Ansible, which is written in Python.

@RobertAKARobin
Copy link
Author

Personal posts will be removed.

@TolstoyDotCom
Copy link

Consider the ternary operator in Java/PHP/etc vs how it's done in Python. Why didn't Python just copy the "normal" way? To be different? To avoid copying from other languages? To (like cults) force people to do things in strange ways particular to the cult to force them to leave their previous lives behind? While there might be some merit to putting one value at the start of the statement and the other at the end, putting the condition first seems to make more sense to more people.

Also, let's say you want to print out "the value is " + i . In Python you have to know that i is a string or convert it to a string.

Add in tacked-on OOP ("self" everywhere), lack of interfaces, using underscores as access control, and the worst feature of all, duck typing. If you have to turn a Car into a Duck, that's a design problem.

Would you do online banking at a bank that used Python for backend processing?

@Odalrick
Copy link

Odalrick commented Dec 23, 2022

Consider the ternary operator in Java/PHP/etc vs how it's done in Python. Why didn't Python just copy the "normal" way?

Because if you always copy everything, you never innovate. We'd be stuck with punch cards if no-one ever innovated.

Also, Python has an aversion to cryptic symbols, so they had to use text instead of "?" and ":" (Not necessarily cryptic code; I am aware that people have problems with comprehensions.)

If you start writing versions with words instead of symbols, I think you'll find that a if a > b else b falls out quite naturally. IIRC there were also some polls that found that the use for ternary operators was to set default values where it sort of makes sense to have the common result first.

My point is that there were good reasons to do it that way at the time, and they couldn't know before trying if it was a good idea.

let's say you want to print out "the value is " + i

First of all, you don't do it that way. Something like "the value is %s" % i would be more like it. (I know, cryptic symbols. But this has ancient roots, copied from C before the dawn of time. )

know that i is a string or convert it to a string

...yes. Obviously; that is what I want. I don't get that objection at all. If you want to print a string, you have to have a string to print. If you want to walk you have to have legs.

As an aside, using + for concatenation is one of the warts of Python. Addition is commutative, concatenation isn't. Silly.

I like self, makes things explicit. There are ABC:s and types now, don't need interfaces too. Underscores as access control is brilliant, a perfect solution to the actual problem.

Duck typing isn't about turning cars into ducks, it is about allowing both cars and geese to honk, without requiring them to be explicitly defined as honkers. You don't have to like duck typing, I don't particularly, but complaining about it because you don't know what it is... perfectly in line with this thread.

Would you do online banking at a bank that used Python for backend processing?

Yes... would you use a female doctor? It's not about the soft bits, all that matters is if it works correctly.

@Pharap
Copy link

Pharap commented Jan 2, 2023

the whole point of a mapping function is to create one list from another.

This is the one point I disagree on.

map, as a programming concept, should operate on an abstract sequence of objects. That includes things like trees.

To quote Wikipedia (from the same article this gist links to):

The concept of a map is not limited to lists: it works for sequential containers, tree-like containers, or even abstract containers such as futures and promises.

From a more practical standpoint: if map returned a mutable list that suggests that a new list has been created, so if you chained map together a few times you'd end up creating junk lists that would be automatically discarded.

If instead map creates some kind of lazy iterable object then you don't need to build a list until a new list is explicitly created from that iterable, which is a far more efficient way of doing things.

@Pharap
Copy link

Pharap commented Jan 2, 2023

@Odalrick:

Because if you always copy everything, you never innovate.

Python didn't innovate though. The trailing if idea already existed in Perl (which predates Python by just over 3 years), and it wasn't the best thought-out idea back then either.

Certain features become widely copied because they work well, and ternaries are one of those features.

(I know, cryptic symbols. But this has ancient roots, copied from C before the dawn of time. )

I can't help but find that a bit ironic after the mention of Python not liking 'cryptic symbols'. Especially considering the ternary operator is also from C.

If you start writing versions with words instead of symbols, I think you'll find that a if a > b else b falls out quite naturally.

It might read more like English, but personally I prefer Haskell's answer to the problem, which is c = if a > b then a else b. It follows the ternary ordering, it's easier to parse, and you can nest it: if a > b then (if a > 0 then a else 0) else (if b > 0 then b else 0).

(Haskell's answer to the problem actually comes from ML, which predates both Python and Perl. In fact, it's only 1 year younger than C.)

I like self, makes things explicit.

I definitely agree with this. I tend to prefer using an explicit this even in languages where it's optional.

Duck typing isn't about turning cars into ducks, it is about allowing both cars and geese to honk, without requiring them to be explicitly defined as honkers.

I'm not convinced that's actually a good thing.

Firstly, it's error prone.

honk is fine because you're not likely to find a honk method that does something other than making a sound, but there are situations where two classes might both have a method with the same name that does something very different.

For example, take +. As you said yourself, it's commutative for numbers but not for strings, so if you fed both into a function that expected the passed object to implement + in a commutative way then it could work fine for one but break silently for the other. That problem could be solved if there was some kind of interface concept that had to be opted into, which would separate the commutative adders from those objects that are using + for something that isn't really addition.

Secondly, not having an explicit interface means that instead of specifying a named concept and its rules within the language you end up either leaving that concept vauge and undefined, or having to define it in the comments. By writing a function that expects a passed object to honk, the concept of 'something that can honk' becomes important and relevant to your program, so callers should be aware of its existance and should be informed enough to know what honk is expected to do, and that's easier to manage when you have some kind of interface/typeclass concept.

I'm not necessarily saying Python should have something equivalent to interfaces, just that duck typing is error prone and better alternatives do exist.

@muratyaman
Copy link

muratyaman commented Jan 2, 2023

https://realpython.com/python-interface/

massive patchwork!

we can compare such features implemented by libraries like babel for javascript; they are loved by developers and eventually become the language features:

https://en.wikipedia.org/wiki/ECMAScript_version_history

a bit of supply and demand scenario there. (copying/inventing or not) some programming languages, which refuse to adapt or are too slow to adapt, will be eliminated eventually: check php world. people create new programming languages every year! probably more specialized and much more efficient in some aspects. we should try them.

if we are "data entry clerks" for "machines" using ways of "code", I'd rather enjoy that and be efficient at it too. I don't feel that way with some languages like python, perl, erlang, java, rust, c, etc. soon, we could be replaced by "machines" as well (check chat gpt!) but until then let's aim for delivering good quality, fast and efficient software applications. that also applies to language designers and compiler writers!

@Preposterone
Copy link

@Odalrick:

Underscores as access control is brilliant, a perfect solution to the actual problem.

What problem exactly do underscores solve and how?

@tankorsmash
Copy link

I enjoy the whitespace-is-significant aspect because of how code has to be at a certain minimum of readability. Still easy to make stuff unreadable but you can get some sort of feel for the code based on indentation.

I don't use black or another formatter for Python, but having an opinionated, language-wide formatter like elm-format makes life a lot easier when you're looking at foreign code.

I could imagine though, if you've only ever interacted with 'unpythonic' code, one would feel like it's an unrealistic or arbitrary goalpost and I could imagine feeling pretty frustrated there.

@Odalrick
Copy link

@Odalrick:

Underscores as access control is brilliant, a perfect solution to the actual problem.

What problem exactly do underscores solve and how?

The problem of telling the internal stuff that you shouldn't touch apart from the external API.

You're a the programmer, what does it matter how the private variables are protected? You're not going to access them regardless, right?

Reading private variables is a bad idea regardless of if you do it by decompiling a library and reading memory addresses or by accessing a variable named _count. In either case you know you are doing something you shouldn't, but it is your code and Guido can't stop you. So why bother trying.

@Preposterone
Copy link

@Odalrick:

Underscores as access control is brilliant, a perfect solution to the actual problem.

What problem exactly do underscores solve and how?

The problem of telling the internal stuff that you shouldn't touch apart from the external API.

You're a the programmer, what does it matter how the private variables are protected? You're not going to access them regardless, right?

Reading private variables is a bad idea regardless of if you do it by decompiling a library and reading memory addresses or by accessing a variable named _count. In either case you know you are doing something you shouldn't, but it is your code and Guido can't stop you. So why bother trying.

But... why not actually prevent access? What do underscores practically change? How is a naming convention BRILLIANT SOLUTION for private access?

Boggles my mind.

@Pharap
Copy link

Pharap commented Jan 15, 2023

why bother trying

Simple: to prevent programmers from doing something wrong, regardless of whether they're intending to do it.

Sure, someone who is determined might find a way to access a private variable anyway, but the point of having enforced private variables isn't to try to stop people who are determined to shoot themselves in the foot, it's to help programmers from making accidental mistakes - to help those who don't know that a variable is supposed to be private.

The underscore prefix 'solution' isn't really a solution, it's a convention, and conventions are only useful if everyone sticks to them.
Inevitably there will be people who flout convention. Even the core Python library itself contradicts the PEP 8 style guide at times.

@tombohub
Copy link

The underscore prefix 'solution' isn't really a solution, it's a convention, and conventions are only useful if everyone sticks to them.

yes, and I saw on Instagram guy posting code which breaks convention and his response: "I can type my code however I want".

Given that python is most popular among new programmers and there are instagram influencers who break conventions, those conventions are standing on glass legs

@Odalrick
Copy link

@Preposterone @Pharap @tombohub

But... why not actually prevent access?

Underscores do prevent access. Every time you see the name of the variable you see right there that you shouldn't use it. You literally cannot refer to it without including a note about not using it. How much more prevention is reasonable to provide?

someone who is determined might find a way to access a private variable anyway

Exactly. So you help programmers not to make accidental mistakes by ensuring that every time they see the name of the variable they are reminded that it shouldn't be used that way.

Instagram guy posting code which breaks convention

Bad programmers are bad programmers regardless of the language.

There is a certain nature of professionalism and responsibility assumed in Python. It is just one of the fundamental designs of Python, like white-space and "explicit is better than implicit". If that isn't something you agree with, then Python just isn't designed for you.

@grahamnicholls
Copy link

grahamnicholls commented Jan 16, 2023 via email

@Pharap
Copy link

Pharap commented Jan 16, 2023

Every time you see the name of the variable you see right there that you shouldn't use it.

That's like saying a "keep off the grass" sign prevents people from standing on the grass.

It's not really prevention if you're relying on people to self-censor and there's absolutely no obstacle standing in their way. Might as well leave your house and car doors unlocked while you're at it.

So you help programmers not to make accidental mistakes by ensuring that every time they see the name of the variable they are reminded that it shouldn't be used that way.

That doesn't help if they aren't aware of the convention in the first place.
If they aren't aware then there's nothing to stop them making the mistake.

In a compiled language with a proper 'privacy' mechanism the compiler would prevent the program from compiling and tell the programmer what they've done wrong. They'd either read the error and understand the problem or do further investigation and learn about the privacy mechanism, and then they'd fix their code.

In Python their code would run unimpeded with no warning about the mistake they'd just made, and then it would potentially break later down the line when they update their libraries and find that private variable is now missing because the implementation has been changed.

It need not even be an inexperienced programmer, it might just be a tired, overworked programmer who works on several language and forgot Python's convention because they work with so many different languages and it's hard to remember every language's little foibles. An enforcement mechanism would save them a headache.

Obviously Python isn't compiled in the conventional sense and its dynamic nature would mean any kind of actual enforcement would incur some runtime overhead, so I don't begrudge the fact they chose for forgo enforcement in favour of performance, but the point stands that a naming convention is not the 'perfect' solution.

Even if it were a 'perfect' solution, such conventions are not unique to Python.

Other languages have their own sets of conventions, but the problem is that there will always be groups who opt to break convention because they want to follow their own conventions, thus multiple different competing conventions appear.

Take C++ for example: one older convention is to prefix private member variables with m_, Google's style guide says to use an underscore suffix, some people use a preceding underscore like Python does, while other people (myself included) don't give private members a special naming convention at all and just rely entirely on the privacy mechanism.

If that isn't something you agree with, then Python just isn't designed for you.

<sarcasm>How very inclusive.</sarcasm>

@Odalrick
Copy link

@grahamnicholls

So you're not a professional if you despise Python, then?

No, you are a different nature of professional.

is it not implicit that _vars are not to be written to?

No, it is explicit. As explicit as the meaning of if, except and ==.

Implicit would be if, for instance, you could write private somewhere and then not have any warning that you cant use that variable until you run the code and get a runtime error

@Pharap

That's like saying a "keep off the grass" sign prevents people from standing om the grass.

Exactly. And if you are working with reasonable, well intentioned, trustworthy people, they will keep of the grass. Unless they really need to go on the grass; maybe if you have a heart attack they will go on the lawn to save you. You could surround your lawn with barb wire, land mines, and sharks. It won't stop anyone determined to go on the lawn, but it will prevent some uses you would approve of.

In Python the assumption is that the programmer is reasonable and trustworthy, and no particular things are put in to hinder them.

It is your code. Your lawn.

That doesn't help if they aren't aware of the convention in the first place.

There are a lot of things that doesn't help if you aren't aware of them. Programming is a skill.

Regarding enforcement; I like enforcement. I prefer compiled languages, and types, and automatic formatting, et al. But that isn't what Python is.

forgo enforcement in favour of performance

Exactly. It solves the actual problem with no downside. That is what makes the solution "perfect". And I never said Python was unique in this.

As an aside, not having one convention of how to write code is a flaw in the language. Good languages have one very strong style guide. Ideally it is a good style too, but I prefer restrictive to lax; even if I don't agree with most of the decisions.

If that isn't something you agree with, then Python just isn't designed for you.

<sarcasm>How very inclusive.</sarcasm>

The idea that everything should appeal to everyone is vile.

@muratyaman
Copy link

muratyaman commented Jan 16, 2023

there are many imperfect programming languages out there; none of them are promoting themselves as the best or the most dev-friendly in the world - not as much as python developers or university geeks. (except java maybe but that is a different story) please stop doing that. it is not funny anymore.

the fact that python is so strict e.g. about indentation is because they do NOT trust the developers and they enforce a programming style in the programming language itself! also, starting code blocks but missing the ending keywords or symbols are just horrible.

without the basic OOP principles, you cannot write a proper library or pieces of code in a large codebase - that will be used by other devs.

it is an ugly and inefficient non-dev-friendly language. they could not sell it to me. I will not use it and I will not promote it.

I'd rather promote a beautiful and inefficient language like Ruby!

or even I prefer using an ugly but very efficient language like Rust!

or maybe less uglier but efficient one: Golang!

so many choices are out there. use what you like and feel efficient with your team mates. (I'd still use one or more which are popular enough and maintained well.)

I can not pretend that my tools in my toolbox are the best, probably none of them is.(that is why people keep creating new programming languages every year!) I can deliver really impressive solutions using them and efficiently. I can have fun doing that - it's a bonus! with python I never felt I can do that.

@RobertAKARobin
Copy link
Author

use what you like and feel efficient with your team mates.

In my opinion this is always the correct approach.

@AkashicSeer
Copy link

AkashicSeer commented Jan 21, 2023

If nothing else this post shows how rabid the fanboys are. They make excuses for the suckiness of python, like christians make excuses for why the bible stories make no sense and contradict themselves, while painting god as a psycho tyrant.

You can't say anything without getting attacked. I personally hate python from trying to use programs written in the bullshit. It is such a pain to get anything written in python to actually run properly to the point it is often not worth trying for end users.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment