I always thought low-level programmers (C, C++, assembly, etc.) cared more about minimal abstractions and minimizing dependencies. But it turns out it's the same story no matter what level of the stack you are on. Currently working on a project with 200+ requirements in requirements.txt and growing. Before anyone says microservices just realize that you have taken the same programmers that made this mess and shoveled the problem elsewhere. These people will find a way to introduce 100+ dependencies on other services.
It’s hard work printing nothing
11–20 of 79 posts
Re: It’s hard work printing nothing
#12I always thought low-level programmers (C, C++, assembly, etc.) cared more about minimal abstractions and minimizing dependencies. But it turns out it's the same story no matter what level of the stack you are on. Currently working on a project with 200+ requirements in requirements.txt and growing. Before anyone says microservices just realize that you have taken the same programmers that made this mess and shoveled…
> Currently working on a project with 200+ requirements in requirements.txt and growing.
That's incredible. I've worked on some very large python projects before, but 200? That's pure insanity. Can I ask what that project does? I just can't imagine a project where you'd need 200 libraries.
Re: It’s hard work printing nothing
#13I always thought low-level programmers (C, C++, assembly, etc.) cared more about minimal abstractions and minimizing dependencies. But it turns out it's the same story no matter what level of the stack you are on. Currently working on a project with 200+ requirements in requirements.txt and growing. Before anyone says microservices just realize that you have taken the same programmers that made this mess and shoveled…
> Currently working on a project with 200+ requirements in requirements.txt and growing. That's incredible. I've worked on some very large python projects before, but 200? That's pure insanity. Can I ask what that project does? I just can't imagine a project where you'd need 200 libraries.
I can't either. I'm surprised every day. The app is just another generic CRUD enterprise thing. I guess in that regard it's not bad at all. I've seen Java projects with way more requirements.
Re: It’s hard work printing nothing
#14Earlier quoted context omitted.
They're probably warnings rather than errors.
So? If they indicate a problem or potential problem, they should be fixed in the software. The fact that there is a "warning" message means that someone, somewhere thought it serious enough to write home about. If they don't indicate a potential problem, then why even print them? Think about how you're supposed to treat compiler warnings: You don't ignore them--they are there for a reason. Quite the opposite--you sho…
It's a deprecation strategy. The warnings are typically for things that will break in the future.
GTK can't control yet alone offer patches for the 1 million + programs that depend upon it as a library.
Re: It’s hard work printing nothing
#15Earlier quoted context omitted.
They're probably warnings rather than errors.
So? If they indicate a problem or potential problem, they should be fixed in the software. The fact that there is a "warning" message means that someone, somewhere thought it serious enough to write home about. If they don't indicate a potential problem, then why even print them? Think about how you're supposed to treat compiler warnings: You don't ignore them--they are there for a reason. Quite the opposite--you sho…
Go fix them then
Re: It’s hard work printing nothing
#16I always thought low-level programmers (C, C++, assembly, etc.) cared more about minimal abstractions and minimizing dependencies. But it turns out it's the same story no matter what level of the stack you are on. Currently working on a project with 200+ requirements in requirements.txt and growing. Before anyone says microservices just realize that you have taken the same programmers that made this mess and shoveled…
> Currently working on a project with 200+ requirements in requirements.txt and growing. That's incredible. I've worked on some very large python projects before, but 200? That's pure insanity. Can I ask what that project does? I just can't imagine a project where you'd need 200 libraries.
Eh, in Ruby, just installing Rails is like 80 dependencies. Would be surprised if Django wasn't 40+
Re: It’s hard work printing nothing
#17Earlier quoted context omitted.
They're probably warnings rather than errors.
So? If they indicate a problem or potential problem, they should be fixed in the software. The fact that there is a "warning" message means that someone, somewhere thought it serious enough to write home about. If they don't indicate a potential problem, then why even print them? Think about how you're supposed to treat compiler warnings: You don't ignore them--they are there for a reason. Quite the opposite--you sho…
Read SQLite's FAQ on that. Given, most projects aren't as amazing as SQLite.
Re: It’s hard work printing nothing
#18Earlier quoted context omitted.
> Currently working on a project with 200+ requirements in requirements.txt and growing. That's incredible. I've worked on some very large python projects before, but 200? That's pure insanity. Can I ask what that project does? I just can't imagine a project where you'd need 200 libraries.
Eh, in Ruby, just installing Rails is like 80 dependencies. Would be surprised if Django wasn't 40+
Django itself has no requirements besides the standard library:
% pip freeze
Django==1.10
Re: It’s hard work printing nothing
#19Earlier quoted context omitted.
> Currently working on a project with 200+ requirements in requirements.txt and growing. That's incredible. I've worked on some very large python projects before, but 200? That's pure insanity. Can I ask what that project does? I just can't imagine a project where you'd need 200 libraries.
Eh, in Ruby, just installing Rails is like 80 dependencies. Would be surprised if Django wasn't 40+
[deleted]
Re: It’s hard work printing nothing
#20Earlier quoted context omitted.
So? If they indicate a problem or potential problem, they should be fixed in the software. The fact that there is a "warning" message means that someone, somewhere thought it serious enough to write home about. If they don't indicate a potential problem, then why even print them? Think about how you're supposed to treat compiler warnings: You don't ignore them--they are there for a reason. Quite the opposite--you sho…
Read SQLite's FAQ on that. Given, most projects aren't as amazing as SQLite.
I get some compiler warnings when I compile SQLite. Isn't this a problem?
Doesn't it indicate poor code quality?
Quality assurance in SQLite is done using full-coverage testing, not by
compiler warnings or other static code analysis tools. In other words, we
verify that SQLite actually gets the correct answer, not that it merely
satisfies stylistic constraints. Most of the SQLite code base is devoted
purely to testing. The SQLite test suite runs tens of thousands of separate
test cases and many of those test cases are parameterized so that hundreds
of millions of tests involving billions of SQL statements are run and
evaluated for correctness prior to every release. The developers use code
coverage tools to verify that all paths through the code are tested.
Whenever a bug is found in SQLite, new test cases are written to exhibit
the bug so that the bug cannot recur undetected in the future.
During testing, the SQLite library is compiled with special instrumentation
that allows the test scripts to simulate a wide variety of failures in
order to verify that SQLite recovers correctly. Memory allocation is
carefully tracked and no memory leaks occur, even following memory
allocation failures. A custom VFS layer is used to simulate operating
system crashes and power failures in order to ensure that transactions are
atomic across these events. A mechanism for deliberately injecting I/O
errors shows that SQLite is resilient to such malfunctions. (As an
experiment, try inducing these kinds of errors on other SQL database
engines and see what happens!)
We also run SQLite using Valgrind on Linux and verify that it detects no
problems.
Some people say that we should eliminate all warnings because benign
warnings mask real warnings that might arise in future changes. This is
true enough. But in reply, the developers observe that all warnings have
already been fixed in the builds used for SQLite development (various
versions of GCC, MSVC, and clang). Compiler warnings usually only arise
from compilers or compile-time options that the SQLite developers do not
use themselves.