TDD is overrated. Code coverage is extremely overrated. Both of these tend to lead to a morass of tests that prove the compiler works at its most basic level while simultaneously generating a surplus of smugness about the whole situation.
Tests have their place. Tests can be, and often are, valuable. But the easier the test is to write, the easier it would’ve been to just encode it into the type system to begin with.
Yeah creating tests for every single method is insane. If a feature changes it’s more difficult you either have to figure out how to implement the change without changing the method, or you change the method and have update the unit test. But if you’re constantly updating the unit tests, how do you know if you might’ve broken something else that the test was intended for.
It’s way better just to do integration tests that match the feature request. That way the feature that someone asked for will continue to work even if you decide to refactor the code.
Unit tests are only worthwhile if you refractor code or write the unit tests before writing the code. We started adding unit test for most everything where I work and I think it’s far more effort than it’s worth. It’s not that it catches nothing but it catches so little I don’t think it’s worth the time spent writing them.
I don’t think you understood my point. That’s exactly why I think unit tests aren’t all that useful. Most code changes require updating the unit tests so unless you change the unit tests first all that’s being done is saying, yep this works how I programmed it to work.
TDD as in religion is overrated. TDD done right is IMHO extremely effective.
The problem is, writing good tests is really hard, and I have seen/committed/experienced a lot of bad tests… just the top of my mind problems with TDD done wrong:
testing the implementation instead the interface
creating a change detector
not writing / factoring the tests in a good way
writing tests / TDD w/o having an overall design for the software
For every non trivial piece of software written w/o TDD, I always saw the same pattern: First few hours/days/weeks, rapid progress compared to TDD, afterwards: hours/days/weeks wasted in debugging, bug fixing etc… and the people can not even catch up with tests if they wanted.
Is TDD always the answer? Of course not, it is a tradeoff like everything else in technology. OTOH I have yet to see a project which benefited from not using TDD by any metric after a few days in.
That the HTML/CSS structure of web programming is absolutely disgusting and not necessary. The internet could be and should be so much more from a developer pov. Also people who double space instead of tab often have their mouths open while mashing space 16 times.
I completely understand and clearly see that web development is the future, but I still think it’s all gross and will always prefer targeted efficient compiled code. Why? Because I’m a huge fucking dork.
If white space carries any function that the compiler/interpreter needs to know about like structure or scope, it’s probably not a very good programming language.
Genuine question: why? What makes, say a semicolon, so superior to the the newline or tab characters?
To be clear: I don’t think whitespace as a part of syntax is an awesome idea which should be more popular. It’s definitely a bit more error prone in some ways. It’s not perfect. But it’s okay.
I’ve written a lot of Python and I don’t think I have ever seen a syntax error caused by incorrect whitespace. I’m not exaggerating. I regularly forget semicolons in other languages but I never type out incorrectly indented code. Maybe that’s just me though…
From some one who used Python as it was the easiest solution to few of my problems, and having to experience languages with brackets and/or endif/fi/done as ways to limit scope, I find that having things like brackets and/or scope terminators easier to parse and less error-prone. I’m thinking about moving on to Ruby whenever I had a need where Python would be a good choice, but the time it takes for me to understand a new language is blocking me from that.
I honestly think the scripting languages like fish have got it right.
Newline by default completes a line and can optionally be escaped. Saves you most of the semicolons and even implicitly highlights multi-line statements.
Whitespace doesn’t matter except for separating names.
Blocks are explicitely ended without braces you can confuse with brackets or parentheses, no matter the coding style.
If Rust and fish had a baby, I think it would be the best language to have ever been created.
A vast majority of the code in question is the code I’ve written for my work projects with multiple active contributors and refactoring is very common too. We all like to shit on Python for various reasons but no one in my environment ever complained about whitespace.
Like I said, I don’t think whitespace is perfect as a part of syntax but I’m much more likely to forget a semicolon than a proper indentation and this applies to any language. I guess it’s not universal tough, because you can often see code with messed up indentation on online forums etc. TBH this is just unthinkable to me, indentation is absolutely necessary for me to be able to read code and reason about it. When I’m thinking about blocks and scopes it’s not because I counted semicolons and braces, it’s 100% indentation.
Load-bearing whitespace is the fucking devil. This thread about hot takes is topped by a comment highlighting how people can’t even agree what kind of whitespace to use.
Python - you want code to fail if someone from one camp copy-pastes code from another camp, and the characters that make a difference are invisible?
KDE is ridiculously unintuitive and has become too awkward to use to recommend to a newbie.
Arch is not a general purpose distro. Theres too many things that can break it unless you meticulously follow the patch notes and participate in the community.
Not everything should be beginner friendly. Trying to nerf things because they are not beginner friendly should not be how tools/patterns of languages are designed.
Its ok to have more advanced topic that require more knowledge and that people don’t understand from the first moment they see them.
Yes and no. I mean sure, if you are going to leverage this to gain a significant edge in the market, that works.
If you add a tool to the project, that you need to understand to maintain some parts of it, which adds to the learning curve of someone joining said team, then the gains have best be worth the effort.
We adopt so many librairies/plugins/tools over time that adding more complexity than you need this way is just terrible.
Amen! One thing which drives me crazy is that most people confuse beginner friendly and user friendly, the two things are absolutely not the same thing. There is nothing wrong with having tools which are beginner friendly, especially for stuff one does once in a while. There is everything wrong with nerving tools which are for pros or even everyday usage: If I use something everyday I have rather an optimization for the mid or long run, than for the first few hours…
Readability is often in the eye of the beholder, but knowing that a component implements a design pattern is all you need to know how it’s used without even having to peek at the code.
I think the most vocal critics of design patterns are those who are clueless about design patterns, and they are just scared if stuff they don’t know.
I’ve seen it get a lot of hate revently. In my experience, it’s mostly been from people upset they had to refactor their 400 line function or write unit tests.
Almost everything in Scrum can be seen as protecting the team.
ONE example (there are many):
Problem: vague requirements
Solutions in Scrum:
Acceptance criteria on stories need to be clear
whole team grooms the story, everyone understands it and does planning poker to agree on costs. If the team doesn’t all understand it, it doesn’t get past this point
only fully groomed stories get into a Sprint and get worked on.
EVEN IF YOU GOT IT WRONG, you demo what you did every sprint, and the stakeholders can ask for additional work in a future story, reducing the cost of getting it wrong once.
The problem is that only 1 organization that I’ve worked for has actually tried to implement it correctly. The rest just say “yeah we do Agile SCRUM” but it becomes obvious quite quickly that no they do not. Just because we throw stories on a Jira board every 2 weeks and move them around does not make it SCRUM. I suspect this is partially the reason that some people have a negative view of it. They’ve only done “SCRUMfall” and assume that’s all it really is.
Files are a mistake and destroy all structure information.
You don’t have guarantee nobody touched your file, we should database that keep structure information instead.
Command Line is the minimum effort human interface, if we had more time/skill to make interface, the cli wouldn’t exists.
You don’t have guarantee nobody touched your file, we should database that keep structure information instead.
What is your definition of file and database? For example, do you think SQLite is a database, and a SQLite database file counts as a file? Do you think that editing SQLite or PostgreSQL with a third party client counts as touching a file?
Add comment