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 - "restrictive programming"
-
When you have to write methods that can only be used in a specific way only just to make sure your coworkers aren't fucking shit up.3
-
So today, my friend (who is younger) has returned from a programming competition hosted by the district. The language used was Pascal. Before the competition my friend had been pretty confident about his skills of using Free Pascal, but after that, he has been different.
He came back in tears. I asked him what was happening in the computer room.
- Turbo Pascal.
I was stunned for seconds. Who the heck in this 2019 still uses an ancient compiler dated from the 1990s for the DOS operating system? And yet the competition's computers had only it installed. I think nowadays everyone learning Pascal, at the very least, uses Free Pascal as the IDE. I could immediately imagine how restrictive and frustrating was programming on such that thing.
- I couldn't create... dynamic arrays... so I had to declare two 30 000-element arrays (which was required by the problem), but when compiling... it said... the maximum heap size was 64KB.
It wouldn't let me use "exit(result)" (to return a function's result) so I wasted many minutes replacing them with "<function name> := result; exit;".
And many more problems.
Raise your hand if you think this is ridiculous.7 -
Learning a new programming language is a lot like putting on a new pair of underpants. At first it's restrictive but then it becomes a part of you!4
-
One of my least favourite parts of the world of programming is the "there's a usecase for everything" attitude. Like take this part of "You don't know Javascript" https://github.com/getify/...
> But var is still useful in that it communicates "this variable will be seen by a wider scope". Both declaration forms can be appropriate in any given part of a program, depending on the circumstances.
Now you would imagine that after this comment the author added a good example of this or at least had a reference to another part of the book where it showed this, but nope it goes on to include this note:
> It's very common to suggest that var should be avoided in favor of let (or const!), generally because of perceived confusion over how the scoping behavior of var has worked since the beginning of JS. I believe this to be overly restrictive advice and ultimately unhelpful. It's assuming you are unable to learn and use a feature properly in combination with other features. I believe you can and should learn any features available, and use them where appropriate!
Which again, "durr there's a usecase for this feature" or rather it's coming with basically an insult towards people who don't think you should use var without actually addressing anything. And what usually happens when someone tries to "there's a usecase for everything" is to either be really vague, or come up with some silly thing that you "might" do. -
With C++11, fell in love with std::enable_if and others in type_traits.
Lets you take generic programming to a whole new level. I never used it when this was part of boost thinking it didn't make as much sense. Now, I like to qualify my template definitions to be as restrictive as possible based on the expected usage.