Python has come a long way in recent years, I remember when android switched to an ahead of time compiler for its java.
I really like lemmy. I usually learn something everyday. Thxs for that.
My current project is trying to create a cool fork of mobian for the pinephone with overclocks and some other stuff, right now I’m editing the debt trees to get about 50% more performance for roughly the same battery life, out of the pinephone.
With some other things, a bigger battery, and a custom modem firmware that can downclock the CPU in it, I’m getting 2% battery drain per hour with the screen off.
squaresinger@lemmy.world 2 days ago
Yeah, stuff improves a lot, but prejudices often stay the same. Java is really fast nowadays. That didn’t use to be the case.
Yeah, with a lot of work, really cool things can be done.
DarkAri@lemmy.blahaj.zone 2 days ago
I have several reasons for not liking java. One is that it uses a garbage collector but another the real reason, besides that it’s often slower than C to write in because it puts many constraints on you like forcing you into an object oriented paradigm. Python I don’t like because it forces you to format your code in a certain way which I don’t really like. I like the freedom of C. It has basically everything I like in a language, it’s fast, one of the fastest, it not safe. I hate safety, my trigger finger is my safety, and it has wide support and examples to draw from, but my favorite thing is probably how powerful and feature complete it is. You can do nearly anything with C. I have been using it since before I was a teenager and I still don’t know how many of its features work because I’ve never had a use for them. Things like templates and stuff. Also sometimes it’s just really useful to do things like create your own data types and stuff. Cast different types as strings or something. I like being able to write functional code as well as Op code along side each other. I like to build up most of my systems from scratch for performance reasons, like file handling because I do game programming usually. I understand many people dislike these things about C but I always rather have freedom and power and maturity for the types of things I like to do.
squaresinger@lemmy.world 2 days ago
This is another thing where hobby and professional development diverge.
For professional development, freedom just means unmaintainable code. For projects that run for a longer time you want everything to be as standardized as possible. People 10 years from now will need to understand your code, even if they live in a different country, went to a different university and haven’t seen any code from your organization before they join the project.
Cool and clever tricks will likely cause more trouble in the future than they will ever be worth right now. You write code once, but you will keep reading and re-working it over and over again.
This is exactly the issue here. When you stumble upon code that uses an obscure feature like that, it’s a “wtf moment” and it will likely result in something being used wrong and something causing a bug. We don’t want that.
That’s why close to every professional project uses a linter, which blocks you from using problematic patterns and illegible code. If you use C with a linter, it will force you to format your code in a certain way as well.
If you just DIY your own small projects and discard them before they become old, code style doesn’t matter. But if you ever looked at the code of one of your old projects and it took you a while to understand what you did there, then that’s the result of bad code style.
DarkAri@lemmy.blahaj.zone 2 days ago
I think it depends a lot on what you are doing. For game dev, there is really nothing else but C++. Also most bad code can be good code if someone is intelligent about it, and use good names and comments. Also if they know how to search through the code and trace things. For massive group projects I can kind of see your point. Being ina. Rush makes it very difficult to write good code, something that is laid out well, is interfacable and modular which makes it easier to understand. I personally try to write all my code to where it’s mostly an API to anyone else wanting to use it. Something where they don’t necessarily have to dig through tons of esoteric and confusing code, but I like to have everything wrapped in nice little function calls, that handle all the edge cases within and have a little description.
I understand rushing makes this hard but that’s more so a failure of the team leadership prioritizing the wrong things. If you are going to write code that’s going to be used for 20 years, it’s actually a much better use of your time to just write really clean and easy to understand and adapt code up front, and save yourself so much time in the future. The only time other people should really have to dig beyond the API layer of your code is when they need to debug or modify the functionality of your code. So to me it seems like you want to write the most abstract and stable and simple interfaces code when working on long term projects with multiple people, even if it takes 4x as long, and for little personal projects and stuff that will only be compiled once, you may just want to through 100k lines of code in a file and compile it and then forget about it.
Other things I do is wrap things and simplify things myself. I create my own libraries which I know that you as a professional programmer hate to hear, but I do believe in the power of simplicity and abstract compression if you really want readable code. Libraries have to be maintained if they are to be used in production, but inlining some of your own code into every project you do is very useful and doesn’t rely on external libraries and can greatly simplify the code you need to write. I wrapped many C std lib stuff in my own code for this reason. It cuts my code in half often times, makes the code very readable and descriptive, and I can just add it to all my projects as a header instead of link libraries and stuff. Idk. Maybe sometimes you just have to weigh the upfront development time and cost with later reliability and simplicity, which I’m sure you do, but your managers might be wise to consider that as well. Having bad code isn’t just bad for developers, it makes people using your product dislike the products. There are many reasons to just take the time to write better code and use better techniques at the cost of time, and to truly be successful you have to look beyond the next quarterly report and stock price and do everything in view of the long term. Efficiencies are often small by themselves and not worth it, but overtime efficiencies and good habits snowball into massive permanent buffs.