Join devRant
Do all the things like
++ or -- rants, post your own rants, comment on others' rants and build your customized dev avatar
Sign Up
Pipeless API
From the creators of devRant, Pipeless lets you power real-time personalized recommendations and activity feeds using a simple API
Learn More
Search - "stupid design decisions"
-
For the new/aspiring developers:
1. If you are still looking to learn more, but you don't know where to go, start brainstorming. Make a list of projects you could make and sort them by difficulty. Put the ones you could do now at the top of the list, and the ones you aren't sure how to do yet, at the bottom of the list. As you go through them, if you want to do something but aren't sure how, just hop onto an irc chat and everyone will be glad to help. As you go through the projects, your logic and program design skills should improve, as well as your knowledge of programming.
2. Put comments in your code. Seriously. If you are working on a project and suddenly stop working on it for a week or more, you will go back to look at that code and be extremely confused. If you are making something open source, its even more important. If people can understand the code, they are more likely to contribute to it.
3. Try not to focus on code for too long. The longer you work, the more tired your brain gets. Eventually you get tired and make really stupid decisions in your code.
4. Don't code while tired (look at #3)
5. If you are writing code as an assignment, make sure to rename all variables to proper names before submitting it. The instructor will likely not be pleased to see variable names with the f-bomb in them. -
So I figure since I straight up don't care about the Ada community anymore, and my programming focus is languages and language tooling, I'd rant a bit about some stupid things the language did. Necessary disclaimer though, I still really like the language, I just take issue with defense of things that are straight up bad. Just admit at the time it was good, but in hindsight it wasn't. That's okay.
For the many of you unfamiliar, Ada is a high security / mission critical focused language designed in the 80's. So you'd expect it to be pretty damn resilient.
Inheritance is implemented through "tagged records" rather than contained in classes, but dispatching basically works as you'd expect. Only problem is, there's no sealing of these types. So you, always, have to design everything with the assumption that someone can inherit from your type and manipulate it. There's also limited accessibility modifiers and it's not granular, so if you inherit from the type you have access to _everything_ as if they were all protected/friend.
Switch/case statements are only checked that all valid values are handled. Read that carefully. All _valid_ values are handled. You don't need a "default" (what Ada calls "when others" ). Unchecked conversions, view overlays, deserialization, and more can introduce invalid values. The default case is meant to handle this, but Ada just goes "nah you're good bro, you handled everything you said would be passed to me".
Like I alluded to earlier, there's limited accessibility modifiers. It uses sections, which is fine, but not my preference. But it also only has three options and it's bizarre. One is publicly in the specification, just like "public" normally. One is in the "private" part of the specification, but this is actually just "protected/friend". And one is in the implementation, which is the actual" private". Now Ada doesn't use classes, so the accessibility blocks are in the package (namespace). So guess what? Everything in your type has exactly the same visibility! Better hope people don't modify things you wanted to keep hidden.
That brings me to another bad decision. There is no "read-only" protection. Granted this is only a compiler check and can be bypassed, but it still helps prevent a lot of errors. There is const and it works well, better than in most languages I feel. But if you want a field within a record to not be changeable? Yeah too bad.
And if you think properties could fix this? Yeah no. Transparent functions that do validation on superficial fields? Nah.
The community loves to praise the language for being highly resilient and "for serious engineers", but oh my god. These are awful decisions.
Now again there's a lot of reasons why I still like the language, but holy shit does it scare me when I see things like an auto maker switching over to it.
The leading Ada compiler is literally the buggiest compiler I've ever used in my life. The leading Ada IDE is literally the buggiest IDE I've ever used in my life. And they are written in Ada.
Side note: good resilient systems are a byproduct of knowledge, diligence, and discipline, not the tool you used. -
omg, I hate my managers who always make engineering design decisions, literally, my manager made shortcuts and decisions that I told him not to do, now we have to live with this shit. which can be fine, but then in 1:1 he tells me that I have a short-term vision, I am like hello you stupid piece of shit, don't you remember telling us what to do and we pushed back to you for all the dumb decisions you have made. my manager has no idea about technology and yet people listen to him for engineering decision, stupid.5
-
And why is symfony so fucking slow? Well I guess it has something to do with depending on code annotations for everything, or every simple task requiring a whole cloud of a thousand classes, stupid design decisions....I fucking hate symfony, piece of shit software