Programing is a lot less important than people and team dynamics
Python is only good for short programs
Was Python designed with enterprise applications in mind?
It sounds like some developers have a Python hammer and they can only envision using that hammer to drive any kind of nail, no matter how poorly.
I mean, it's still a very nice language. I can see someone, marveled by that, would endeavor to make bigger things with it. I just don't feel it scales that well.
I agree. The GIL and packaging woes are a good indication that it's range of applications isn't as extensive as other tech stacks.
packaging woes
My own hot take is that I hear this criticism of Python a lot, but have never had anyone actually back it up when I ask for more details. And I will be very surprised to hear that it's a worse situation than Java/TypeScript's.
The endless packaging solutions for python is exactly the flaw that they're talking about.
Packaging a python application to work over an air-gap is extremely painful. Half the time its easier to make a docker container or VM just to avoid the endless version mismatch pain.
I don't mean it doesn't work for larger projects. Just that it's a pain to understand other's code when you have almost no type information, making it, to me, a no go for that
Larger projects in Python (like homeassistant) tend to use type-hints and enforce them through linters. Essentially, these linters (with a well-setup IDE) turn programming in large Python projects into a very similar experience to programming a statically typed language, except that Python does not need to be compiled (and type-checked) to run it. So you can still run it before you have satisfied the linters, you just can't commit or push or whatever (depending on project setup).
And yes, these linters and the Python type system are obviously not as good as something like a Go or Rust compiler. But then again, Python is a generalist language: it can do everything, but excels at nothing.
Go and rust are also generalist languages. Basically all main stream programming languages are and are equally as powerful (in terms of what they can do, rather than performance) as each other as they are all Turing complete. So you can emulate c in python or python in c for instance).
Anything you can do in python you can do in basically any other mainstream language. Python is better at some niches than others just like all other languages are with their own niches - and all can be used generally for anything. Python has a lot of libraries that can make it easier to do a large range of things than a lot of other languages - but really so do quite a few of the popular languages these days.
That's actually a good idea, enforcing it. Still, do these linters protect against misuse? E.g I have an int but place a string on it somewhere?
Yes, in a good dev workflow mypy errors will not pass basic CI tests to get merged. Types are not really a problem in modern Python workflows, you can basically have a better type checker than Java out of the box (which can be improved with static analysis tools). The biggest problem with Python remains performance.
Fair enough, I don't notice a significant overhead but then a lot of information is inferred by patterns , project structures etc etc
Python should not be used for production environments, or anything facing the user directly. You are only inviting pain and suffering.
My take is that no matter which language you are using, and no matter the field you work in, you will always have something to learn.
After 4 years of professional development, I rated my knowledge of C++ at 7/10. After 8 years, I rated it 4/10. After 15 years, I can confidently say 6.5/10.
Amen. I once had an interview where they asked what my skill is with .net on a scale of 1 - 10. I answered 6.5 even though at the time I had been doing it for 7 years. They looked annoyed and said they were looking for someone who was a 10. I countered with nobody is a 10, not them or even the people working on the framework itself. I didn't pass the interview and I think this question was why.
This is the only way;
if (condition) { code }Not
if (condition) { code }Also because of my dyslexia I prefer variable & function names like this; 'File_Acces' I find it easier to read than 'fileAcces'
I think it would be a much hotter take if you had the opposite opinion. I've only met a few of those.
I'm not a programmer (I tried learning programming and unity but got lazy so....) but when I learned about if-then statements, the second one seemed like the way it's supposed to be; I mean it looks so clean and simple. Do actual programmers prefer the first method?
I prefer the first method because it reduces the number of empty lines I have to scroll past and visually filter out
The 2nd is the style guide used in C#, and therefore what you've encountered in unity.
I've only seen the second type in C#, to be fair it makes code neater but i'm glad I left it for Java.
It depends for me. If the condition is some goofy ahh multiline syntax hell i like to use the second option.
I use all 3.
If it's very short and there's 2 or more in a row, I'll put it all in one line.
If there's a bunch of nested if statements, I'll use the second.
If neither of those conditons, I'll use the first.
Hot take: people who don’t like code reviews have never been part of a good code review culture.
Hot take #2: Unless you have great code review culture, code rewiews are just unnecessary blockers
It is also a situation in which when you don't have them you can feel smart since you don't have to find justification for what you do.
Everybody trashing on code reviews has never worked with a shit coder before
I'm a shit coder and almost every single review I've made big mistakes like forgetting to delete debug/dead code and there's always meaningful improvements being suggested
This was my experience too. At first I found code reviews to be an invaluable resource for improving my code. But I then reached a point where I'd learned everything I could from a particular reviewer.
I'd submit code that met every criteria, but the reviewer would still nit pick on tiny details that were entirely subjectective. It was no longer about the quality of code it became about the reviewer trying to put their mark on my work.
The only solution was to either ignore their nits or adopt the hairy arm technique whereby you include intentional errors for the reviewer to comment on so they feel their time had been valuable and you get away without yours being wasted.
I worked with a guy who brought 10k lines of code from various jobs over the years and slapped it all into a single commit second day on the job.
It was all VB.NET and looked like it was written in VB6 days because it was reimplementing functions that the .NET framework already provided us. And there were quite a few single line functions that did the simplest things like addition of two variables.
However my favorite function of all was IsMarksMachine() because it was used as a prod/dev switch. I ran into bugs testing the code and got the "Worked on my machine" line. Turned out the code branch under IsMarksMachine() somehow worked, but in all other cases, it didn't.
Mark is not the real name. But man was he a bad coder.
That doesn’t mean you are a shit coder, you are just likely forgetful. I also find stupid shit in my committed code, though that is also due to me not caring too much (I guess I really have burned out at my previous work place).
Now I’m at a better job, hopefully I can take proper care of my work here! Hopefully you don’t suffer from burnout.
SPAs are mostly garbage, and the internet has been irreparably damaged by lazy devs chasing trends just to building simple sites with overly complicated fe frameworks.
90% of the internet actually should just be rendered server side with a bit of js for interactivity. JQuery was fine at the time, Javascript is better now and Alpinejs is actually awesome. Nowadays, REST w/HTMX and HATEOAS is the most productive, painless and enjoyable web development can get. Minimal dependencies, tiny file sizes, fast and simple.
Unless your web site needs to work offline (it probably doesn't), or it has to manage client state for dozen/hundreds of data points (e.g. Google Maps), you don't need a SPA. If your site only needs to track minimal state, just use a good SSR web framework (Rails, asp.net, Django, whatever).
I loathe JavaScript heavy websites, especially when used for forms. Don’t break autofill and copy/paste. And don’t complain about the format just because I pasted! Seriously, why is pasting text in the correct format triggering some JavaScript framework? It all seriously gets to me.
With that said, I really like Hotwire. HTML over the wire is bliss. Stimulus is perfect for sprinkling non-invasive JavaScript throughout an application.
Preferring server side rendering is an interesting topic
Client side renderering is currently the preference because the company gets to offload the compute costs of their servers onto the clients' devices
As long as every website has a profit motive, even if it's just a single person trying to save some money on their AWS bills, server side rendering will never become the norm
The difference between generating JSON and generating HTML is minimal for the server, doesn't seem to me like server side rendered sites have significantly higher server compute costs. Also generally for SPAs, the server has to replicate whatever flow is happening on the client anyway to keep state in line (since the client can't be trusted)
It's not just JSON and HTML. There's also graphic rendering and even machine learning models
I do a lot of PHP, so naturally my small projects are PHP. I use a framework called Laravel, and while it is possible to use SPAs or other kinds of shit, I usually choose pure SS rendering with a little bit of VueJS to make some parts reactive. Other than that, it is usually, just pure HTML forms for submitting data. And it works really well.
Yeah yeah, they push the Livewire shit, which I absolutely hate and think is a bad idea, but nobody is forcing me, so that's nice.
I'm still hoping for browsers to become some kind of open standard application environments and web apps to become actual apps running on this environment.
Tabs are literally designed for aligned indentation, and they're configurable for clientside viewing. There is no excuse for spaces. I don't care if your goddang function arguments line up once they spill out onto another line. You've got deeper problems.
Tabs are designed for tabulation (hence the name), not indentation. The side effect is that a tab's length changes based on its position in a line, which is terrible for programming. If you use tabs in the Python REPL, it looks like this:
>>> def frobnicate_all(arr): >>> for item in arr: >>> frobnicate(item)
I work in a massive project where they used both. Often in the same functions. Sometimes mixing 2 and 4 spaces aswell.
Tabs could be a good idea if their default size in most environments (and often not configurable) wasn't 8, which is terribly big.
Computer hardware has been getting faster and faster for decades at this point, but my computer still slows down. Like WTF. The dumbass programmers take the extra power given to them and squander it instead of optimizing their code. Microsoft word could run pretty well on a windows 98 PC, but the new Word can slow down PCs that are 5-10 years old. Programmers are complete idiots sometimes...
Linux can be just as much of a slow-ass OS. The real issue is all of the crap everyone wants to do in the browser now.
With linux you have the option of debloating your system by using a minimalist distro with Windows you have no choice
I recommend https://www.youtube.com/watch?v=pW-SOdj4Kkk on this topic.
Here is an alternative Piped link(s): https://piped.video/watch?v=pW-SOdj4Kkk
Piped is a privacy-respecting open-source alternative frontend to YouTube.
I'm open-source, check me out at GitHub.
As someone who only learned a few things about programming, is optimizing code an easy thing? I've read about that many times but the only thing I could imagine (and I had to imagine it as I'm not really a programmer) is that perhaps their codes could be more efficient (so rewriting their code so that ten lines do the job of thirty for example) but I feel like if they lack the logic skills or math skills to do it then perhaps that's why the code contains large functions and such.
But again, I'm not a coder, so I've no idea how in practice code can be optimized.
Shorter is usually faster so your right on that account but not always. There are few things like optimizing for cache hits that can vastly speed up programs but are hard to do. Most slow programs are due to technical debt, high dependencies usage, mixed with laziness and lack of interest in developers with speeding up their program.
Agile in it’s current implementation with excessive meetings wastes more time than the mistakes it tries to avoid.
Not an Agile issue, but a "people fucking up Agile" issue. The priesthood of MBAs will adopt whatever terms people like and just hammer them into place to keep doing the same old shit.
I have experienced this but I think that's the fault of the people implementing it.
For instance, I have been in a 4-person team where the daily meeting took 30 minutes and people often rehashed discussions they had on the previous day. I have also been on a 10-person team where the meeting took 10 minutes on a bad day
Oh totally seen it work myself but I don’t know that it was agile that worked as much as they had a kickass team.
Some teams just jive well. They communicate, they know what each other is doing, and they can plan with minimal waste. And when it’s successful that’s across all roles not just the devs.
In my opinion those teams would have succeeded in waterfall, kanban or their own home brewed strategy as well.
Oh totally seen it work myself but I don’t know that it was agile that worked as much as they had a kickass team.
Some teams just jive well. They communicate, they know what each other is doing, and they can plan with minimal waste. And when it’s successful that’s across all roles not just the devs.
In my opinion those teams would have succeeded in waterfall, kanban or their own home brewed strategy as well.
We use too many libraries. This may be an actual unpopular opinion though. I find that the more a library tries to do, and the more dependencies it has itself, the more hesitant I am to use it. It just feels like a tower of cards ready to fall at any moment.
I'm not a very trusting person and work alone though so this might just be an emotional decision. But it is nice having a project be composed of code that does just what is needed and nothing else. It makes it easier to fix bugs and especially to maintain the code.
I do use libraries, but only if they're absolutely necessary or if they're very focused and don't try to do a million things. It's not about size but complexity.
I’m not a very trusting person and work alone though so this might just be an emotional decision. But it is nice having a project be composed of code that does just what is needed and nothing else. It makes it easier to fix bugs and especially to maintain the code.
And that's one of the reasons microservices are a thing.
As an embedded firmware guy for 10ish years:
C can die in a fire. It's "simplicity" hides the emergent complexity by using it as it has nearly no compile time checks for anything and nearly no potential for sensible abstraction. It's like walking on an infinite tight rope in fog while an earth quake is happening.
For completely different reasons: The same is true for C++ but to a far lesser extent.
I don't have first hand experience with it, I also don't get how it would help me. Maybe I need to look at it some more.
Shorter code is almost always better.
Should you use a class? Should you use a Factory pattern or some other pattern? Should you reorganize your code? Whichever results in the least code is probably best.
A nice thing about code length is it's objective. We can argue all day about which design pattern makes more sense, but we can agree on which of two implementations is shorter.
It takes a damn good abstraction to beat having shorter code.
but we can agree on which of two implementations is shorter.
Shortness for the sake of being short sounds like optimizing for the wrong metric. Code needs to be easy to read, but it's more important that the code is easy to change and easy to test. Inline code and function calls are renowned to render code untestable, and introducing abstract classes and handles is a renowned technique to stub out dependencies.
I mostly agree with this but more than shorter code I value readability, I would rather take 3 lines to be clear to any developer than use some obscure or easy to misunderstand structure to write it in 1.
Yep. And three functions is better than one for legibility even if one would be fewer lines of code
I think this is accurate on a larger scale, but I'll often do things like breaking up a large chain of methods with an interim variable just for readability. A few lines of simple math is better than one line of bit shifting wizardry that does the same thing but doesn't show the semantic meaning of the operation.
I agree. 100 lines of code may be 3x better than 300 lines of code, but 1 line of code isn't 3x better than 3 lines of code.
JS is horse shit. Instead of trying to improve it or using that high level scripting language as a compilation target (wtf?!), we should deprecate it entirely and put all efforts into web assembly.
To me it seems like the internet is full of JS apologists. Maybe it's just YouTube xD
Idk anything about web assembly but I 100% agree that JS is absurd and feels like it was created in a weekend by some schmuck who just wanted to be able to edit html on the fly because it was.
