Refactoring is something that should be constantly done in a code base, for every story. As soon as people get scared about changing things the codebase is on the road to being legacy.
this post was submitted on 01 Sep 2023
3 points (100.0% liked)
Programming
17278 readers
435 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
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 !webdev@programming.dev
founded 1 year ago
MODERATORS
Python, and dynamically typed languages in general, are known as being great for beginners. However, I feel that while they’re fun for beginners, they should only be used if you really know what you’re doing, as the code can get messy real fast without some guard rails in place (static typing being a big one).
load more comments
(2 replies)
Programing is a lot less important than people and team dynamics
Until you know a few very different languages, you don't know what a good language is, so just relax on having opinions about which languages are better. You don't need those opinions. They just get in your way.
Don't even worry about what your first language is. The CS snobs used to say BASIC causes brain damage and that us '80s microcomputer kids were permanently ruined ... but that was wrong. JavaScript is fine, C# is fine ... as long as you don't stop there.
(One of my first programming languages after BASIC was ZZT-OOP, the scripting language for Tim Sweeney's first published game, back when Epic Games was called Potomac Computer Systems. It doesn't have numbers. If you want to count something, you can move objects around on the game board to count it. If ZZT-OOP doesn't cause brain damage, no language will.)
Please don't say the new language you're being asked to learn is "unintuitive". That's just a rude word for "not yet familiar to me". So what if the first language you used required curly braces, and the next one you learn doesn't? So what if type inference means that you don't have to write int on your ints? You'll get used to it.
You learned how to use curly braces, and you'll learn how to use something else too. You're smart. You can cope with indentation rules or significant capitalization or funny punctuation. The idea that some features are "unintuitive" rather than merely temporarily unfamiliar is just getting in your way.
Most modern software is way too complex for what it actually does.
Python is only good for short programs
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.
We used to have a Python guy at my work. For a lot of LITTLE ETL stuff he created Python projects. In two projects I've had to fix up now, he used different tooling. Both those toolings have failed me (Poetry, Conda). I ended up using our CI/CD pipeline code to run my local stuff, because I could not get those things to work.
For comparison, it took me roughly zero seconds to start working on an old Go project.
Python was built in an era where space was expensive and it was only used for small, universal scripts. In that context, having all packages be "system-wide" made sense. All the virtual env shenanigans won't ever fix that.
Real programmer learned Assembly.
VHDL is a good language.
If you think to be a good programmer, you're the opposite.
Are you saying the only good programmers are ones who aren’t aware of their worth and think they’re bad?
Nope, my sentence doesn't involve "think they're bad".
Front end and back end are different enough that you can really specialize in one or the other. They take very different mindsets. I know how to make css obey, I don't know how to make sql performant. Its possible to have both, but not as well.
For every front-end dev, you need 3 back-end guys and a designer.
Programmers are not bad at our jobs, its just not a mature disclipline yet.
It's not mature, because nobody let it mature.
Programming is over 70 years old, that's not a new discipline. Yet, the engineering in our industry is still abysmal. Countless reinvented wheels, nothing is ever finished, changes happen often enough for the sake of change, not progress.
That's part of the nature of programming. Half-finished might be good enough. If you've made an awesome wheel but I need a kink in one of my spokes and yours doesn't do that, making my own wheel might be cheaper than modding yours.
OTOH, there's nothing more frustrating than looking for a particular wheel, finding ten really great ones that collectively have the features you need, but individually aren't good enough.
To stay in the analogy: usually we just want to transport things from a to b. It doesn't matter, how we get there. So usually we begin with a road and start to cobble together a vehicle from barely fitting and functioning junk we find on the roadside.
There's hardly any stable surface to work on. And that's extremely costly.
SQL is the core language that everyone should be required to learn first and foremost.
Why would I, an embedded developer working on devices with at most a couple of mb of flash, need to learn SQL?
It teaches you to think about data in a different way. Even if you never will use it in your products, the mental facilities you have to build for it will definitely benefit you.
You could be onto something. On of my first language was "dBase" (early 90s) which, through it's style, enabled you to build complex user interfaces with data storage very quickly. I only built small things with it at the time, but it influenced my desire for some better solutions than we have to today.
Learning SQL on an enterprise database is what started my journey into coding. It really forces you to think about what you're doing because of how structured the language is. It's also very immediate in that you do x and you get y.
It also makes you think more about data models which I'd argue is why we ended up with the garbage that is MongoDB. Developers not thinking about their data and how it relates enough.
For anyone with their rankles up. 99.9999999% of the time you want an RMDBS. That remaining 0.00000001% you want NoSQL. So any project you spin up? Guess what? You want an RMDBS.
Completely agree. I really love SQL, but I hate it's syntactic limitations. SQLAlchemy was my band-aid with an after-burner to make it bearable (and maintainable).
The best codebase I have ever seen and collaborated on was also boring as fuck.
- Small, immutable modules.
- Every new features was coded by extension (the 'o' in S.O.L.I.D)
- All dependencies were resolved by injection.
- All the application life cycle was managed by configurable scopes.
- There was absolutely no boiler plate except for the initial injectors.
- All of the tests were brain-dead and took very minimal effort to write. Tests served both as documentation and specification for modules.
- "Refactoring" was as simple as changing a constructor or a configuration file.
- All the input/output of the modules were configurable streams.
There is more to it, but basically, it was a very strict codebase, and it used a lot of opinionated libraries. Not an easy codebase to understand if you're a newbie, but it was absolutely brain dead to maintain and extend on.
Coding actually took very little time of our day, most of it consisted of researching the best tech or what to add next. I think the codebase was objectively strictly better than all other similar software I've seen and worked on. We joked A LOT when it came time to change something in the app pretending it would take weeks and many 8 pointers, then we'd casually make the change while joking about it.
It might sound mythical and bullshity, and it wasn't perfect, it should be said that dependency injection often come in the form of highly opinionated frameworks, but it really felt like what software development should be. It really felt like engineering, boring and predictable, every PO dreams.
That being said, I given up trying to convince people that having life-cycle logic are over the place and fetching dependencies left and right always lead to chaos. Unfortunately I cannot really tell you guys what the software was about because I am not allowed to, but there was a lot of moving parts (hence why we decided to go with this approach). I will also reiterate that it was boring as fuck. If anything, my hot take would be that most programmers are subconsciously lying to themselves, and prefer to code whatever it is they like, instead of what the codebase need, and using whatever tool they like, instead of the tools the project and the team need. Programming like and engineer is not "fun", programming like a cowboy and ignoring the tests is a whole lot of fun.
I never got so far, but had a system built which some parts of what you described. It was incredibly relaxing to develop with it. Our take as a team was: boring is better, we don't want to be paged on weekends.
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 also feel better when I use less libraries, even if that may seem irrational sometimes.
I think part of the library craze stems from people who really only want to use the programming language as a tool to get fast results (which is legitimate, of course).
For example in academic contexts you have a lot of scientists who use R with a whole truckload of libraries, often unnecessarily. It reminds me of the plugin craze in the whole wordpress can of worms...
Go with what works
Error messages should contain the information that caused the error. Your average Microsoft error "error 37253" is worthless to me
Keep functions or methods short. Anything longer than 20 - 50 lines is likely too long
Comment why is happening, not what
PHP is actually a really nice language to work with both for web and command line utils
Don't over engineer, KISS. Keep It Simple Stupid
SOLID is quite okay but sometimes there are solid reasons to break those rules
MVC is a PITA in practice, avoid it when possible
Keep functions or methods short. Anything longer than 20 - 50 lines is likely too long
If it doesn't fit on my screen it's too long.
load more comments
(1 replies)
The amount of unqualified people is staggering beginning with those who have no university education.
There are also a lot of e-commerce agencies who just don't have their sh1t together. Was expected to work on 3 different clients a day who all had different platforms, different requirements etc. Yes, you can dump some new code into the project that looks like it's working, but then you don't have time for any unit tests, exception handling if the user won't cooperate etc. and it's basically just some dodgy, untested code that will come back a few days later with some issues related to something nobody told you about.
The other "senior" programmer in the company never set up any local environment but instead ftp'd all changes directly to the live server. I asked him if needs help to set up a local server and debugger, but instead he would just dump vars on the live server and stream the contents of error.log to his second screen to catch any issues...
Compiler checked typing is strictly superior to dynamic typing. Any criticism of it is either ignorance, only applicable to older languages or a temporarily missing feature from the current languages.
Using dynamic languages is understandable for a lot of language "external" reasons, just that I really feel like there's no good argument for it.
If your function is longer than 10 statements, parts can almost always be extracted into smaller parts. If named correctly, this improves readability significantly
HELL NO! If you split that function into three, but these always have to be called in succession, you win nothing but make your code WAY harder to read/follow.
Well named functions, called in succession increase readability, not decrease.
load more comments
(1 replies)
Python is legitimately the best language by far for the vast majority of non-performance critical tasks, and most tasks that need to be developed for are not performance critical.
For bigger projects, anything with MANDATORY types is a must for me. Optional, not compiler checked hinting doesn't cut it.
Not that i hate the language, but I do hate the tooling around it. I don't think I've ever had a pleasant experience with setting up a Python project. And all the data stuff is just wrappers for code in other languages, making the packaging story even uglier, even harder.
view more: next ›