this post was submitted on 06 Feb 2024

110 points (94.4% liked)

Programming

17318 readers

84 users here now

Welcome to the main community in programming.dev! Feel free to post anything relating to programming here!

Cross posting is strongly encouraged in the instance. If you feel your post or another person's post makes sense in another community cross post into it.

Hope you enjoy the instance!

Rules

Follow the programming.dev instance rules
Keep content related to programming in some way
If you're posting long videos try to add in some form of tldr for those who don't want to watch videos

Wormhole

Follow the wormhole through a path of communities [email protected]

founded 1 year ago

MODERATORS

[email protected]

110

What are some common misconceptions about programming that you'd like to debunk? (programming.dev)

submitted 9 months ago by [email protected] to c/[email protected]

179 comments fedilink hide all child comments

top 50 comments

sorted by: hot top controversial new old

[–] [email protected] 5 points 9 months ago (1 children)

That Python is the most readable language. Merely forcing an indentation style is only part of the issue. Python programmers have a tendency to write a bunch of named parameters all on one line, and it's a mess.

Even the automated documentation can't make it right. What the hell is this shit?

class werkzeug.test.EnvironBuilder(path='/', base_url=None, query_string=None, method='GET', input_stream=None, content_type=None, content_length=None, errors_stream=None, multithread=False, multiprocess=False, run_once=False, headers=None, data=None, environ_base=None, environ_overrides=None, mimetype=None, json=None, auth=None)

This is not enlightening. It might as well go on the shelf next to the worst regex you've ever seen. The automated doc generator needs to break these up to put one arg on each line, or just omit it altogether and let the detailed docs handle it.

It's not just the doc generator, either. I see this kind of style all the time in Python code. It's unreadable and it also makes it harder to figure out diffs when a parameter in the middle is changed (though it's helped by color coding for pull requests on GitHub and the like).

It's almost like the language attracted a bunch of people who thought indentation was the only thing you needed to make readable code. No further thought put into it.

[–] [email protected] 2 points 9 months ago* (last edited 9 months ago) (1 children)

I don't disagree that this is hard to read, but I feel it's worth mentioning python has a pretty acceptable style guide. The problem is, it's far less common in python to bundle parameters into some holding object. So here you have massive function that has to accept a lot all at once. In use it's probably not as bad looking however.

And at least, it actually explains all the damn parameters. It's a lot nicer than seeing functions parameters you don't understand, and all you have is the name. This is not limited to python either

[–] [email protected] 3 points 9 months ago (1 children)

There are plenty of other languages that have named parameters but no holding object. You format it like this:

some_func(
    foo: 1,
    bar: 2,
    baz: 3,
)

And this works fine. Of course, not everyone does that, but I almost never see it done in Python.

This style comes into conflict with rules that functions shouldn't be longer than 20 lines for whatever. The solution to that is to be relaxed about the line count rule. I'd rather see 40 trivial lines than 20 with everything crammed up.

[–] [email protected] 1 points 9 months ago

Completely agree with that, we have the same issue in C# where I work. Just waiting for the day I get to push and update to our shared code style (editorconfig) to force that.

[–] [email protected] 11 points 9 months ago* (last edited 9 months ago) (1 children)

Myth: You are lazy.

Truth: It's highly probable you are neurodivergent.

While, accurate numbers are not available, I have seen people estimating that 20% of people working in FAANG are neurodivergent. If coding comes naturally to you but the laundry is your mortal enemy, it's worth learning about ADHD/ASD and other common disorders. Being a coder can be a sign, the immediate feedback helps a bunch of us, or as Russel Barkely says "when you solve a problem on a paper, NOTHING HAPPENS".

Edit: Rephrase.

[–] [email protected] -3 points 9 months ago (1 children)

Are you sure you don’t have autism? You sure sound like you do, maybe even some asshole mixed in there too

[–] [email protected] 3 points 9 months ago

Hey, I am sure I have it, I rephrased the comment, thanks for bringing that up.

[–] [email protected] 34 points 9 months ago (5 children)

Requiring a candidate to know a specific programming language is stupid. Nearly all of the commonly used languages in industry are similar.

It's maybe more valuable to require knowledge in a specific framework, where knowledge is less transferrable between popular frameworks. Nonetheless, I personally rather hire an engineer that solves problems and learns flexibly rather than one that happens to know the right tech.

[–] [email protected] 2 points 8 months ago

It's not a black and white issue. "Jack of all trades, master of none" vs "expert of one". Both have their place and I think it's better to have a mix than just one or the other.

I've seen python newcomers writing code as if they were writing in another language. They don't know about dataclasses, operator overrides, __init__ vs __new__, metaclasses, __init__.py vs __main__.py, @property, match, the walrus operator, or assignments, or the common pitfalls of python like mutable defaults, type hints, and a bunch of other things.
Knowing a language in-depth helps write DRY code, avoiding common pitfalls, handling things better like debugging, profiling, and other tooling, and avoiding pitfalls of the language, which newcomers have to first learn, regardless of how their experience with other languages.

A lot of stuff is transferable, for sure, but every language uses different idioms, covers different paradigms, and so on. It's good to have at least one expert on the term to teach others, and to have people flexible enough to switch of willing to learn. Having only experts can mean a static team unwilling to experiment or use better programming languages or technologies. Having only beginners or mediors of a language can produce functional, but sub-optimal code. YMMV

CC BY-NC-SA 4.0

[–] [email protected] 1 points 8 months ago

It is better to find a developer that has experience with the language features you use rather than one that is experienced in the exact language you use. For example, I work on distributed systems in Java/GoLang/Python. We want candidates that understand how to write concurrent logic and stay away from people who are just Java web developers.

The big issue is doing a coding interview with candidates. We have a standard straightforward problem that candidates need to solve by filling in a stubbed out method. We have it in Java and have ported it to GoLang. If we have to interview a candidate who does not know either of those languages, we would need to find a language that the candidate knows and we know well enough to port the problem to. We would also have some difficulty digging in to design specifics like choice of concurrency primitives.

[–] [email protected] 3 points 9 months ago

I used to agree, but now I'm not so sure. There are huge time savings in having someone already familiar with a specific technology. They've ran across an issue before and can quickly find the solution.

For example, I started learning Elixir a little over a year ago. I struggled with how to get it to change data in place, and the answer is that you don't. You work with data in an immutable way; you make a copy with the change made and throw away the original. Once you get used to it, this works very nicely, and Elixir has quickly become one of my favorite languages. However, few other languages force you to work immutably, and nobody does it voluntarily. It takes a bit to get your head around it, and you'll take a lot longer on any given task until you do.

[–] [email protected] 2 points 9 months ago

I generally agree with this, there's specific circumstances but for the most part its true.

I went from a C# position to PHP, to Python, to perl all with little or no experience with what I was jumping in to. There's different nuances and the syntax might take a bit to get used to but as long as someone understands the how and why of what their code is doing that can be pretty easily transfer to most other languages. It's all about the fundamentals.

[–] [email protected] 7 points 9 months ago (1 children)

I'd say this is pretty dependent on the language. For example, with C++, you need to micromanage (or at least benefit from micromanaging) a lot of things that you can get away without knowing about at all with other languages. That stuff takes time to pick up if you're self-teaching as you can write stuff that looks like it works without knowing its half as fast as it could be because you aren't making use of move semantics, and if a colleague is teaching you, then that's time they're not spending directly doing their own work. On the other hand, someone with Typescript experience could write pretty decent Javascript from the get-go.

[–] [email protected] 2 points 8 months ago (1 children)

C++ is unique in that it is wildly dominant in its niche. I am sure that any developer who has worked with another object oriented, manually memory managed, systems programming language (are there any other popular ones out there?) should have no trouble picking up C++.

[–] [email protected] 1 points 8 months ago

There are other rarely-used C++-like languages that fit your criteria, and they basically all aim to eliminate the kind of thing I was talking about. If someone was used to one of those and tried picking up C++ for the first time, they'd probably end up with working, but unnecessarily slow C++, having assumed the compiler would do a bunch of things for them that it actually wouldn't.

The popular low-level systems programming languages that aren't C++ are C and Rust. Neither is object-oriented. C programmers forced to use C++ tend to basically write C with a smattering of features that make it not compile with a C compiler, and produce a horror show that brings out the worst of both languages and looks nothing like C++ a C++ programmer would write, then write a blog post about how terrible C++ is because when they tried using it like C, it wasn't as good at being C as C was. Rust programmers generally have past experience with C++, so tend to know how to use it properly, even if they hate the experience.

[–] [email protected] 24 points 9 months ago (2 children)

Some programmers are software engineers. They solve problems, sometimes problems with great ambiguity or non-straightforward solutions.

And some programmers are... code technicians? They understand and write code, but their job seldom involves problem solving. Often times, they're asked to code an already solved problem, or mostly solved.

This is not a diss. I was in the second camp for a while. But it hurts your career to stay in that. So be careful.

[–] [email protected] 1 points 8 months ago

Same. Writing code is FUN! However that's not the only goal there is. It's a part of the puzzle. Perhaps it takes some maturity to reach that point.

[–] [email protected] 1 points 9 months ago* (last edited 9 months ago)

Totally agree, I had the fortune to read Domain Driven Deign by Eric Evans early in my career. While, the book may be outdated, it helped me understand that my job is to turn the unknown or ambiguous into code. I find that much more exciting than being a coder.

[–] [email protected] 13 points 9 months ago

When you release something, your work is not done. You have to maintain it, fix bugs, release patches, and probably the worst part, keeping it up to date.

For example, Apple decides to deprecate some API, or decides to switch cpu architecture, or for the millionth time change how app signing works, or add some new security feature that breaks your app. Now you need to make your app work properly on the new platform, switch APIs, all the fun. Or, there's some critical vulnerability in library you used and customers are deleting your app from their computers (a lot of companies use automated scanners that check against published CVEs). It's most fun when you learn that the new version that fixes the vulnerability completely breaks compatibility with the old one and now you have to rewrite all the code that used that library.

Also, maintaining open source projects is not fun. It's a lot of work, in most cases unpaid, thankless, and building a community around a project is really hard.

load more comments