Simple answer: It is not the computer who does this task, it is the repository maintainer who decides which package has to be compiled with which dependencies. And if I disagree with the decision of that maintainer I have to do it myself anyways.
For example, I use conky without graphical output, but none of the distros I know of deliver such a package. But building it myself with changing a few lines in a Slackbuild is very easy (much easier than building your own DEBs or RPMs).

If you make a standard install of Slackware that is exactly what you get.

1 members found this post helpful.

You're making an assumption that the only dependency management is binary package dependency management. A good source-based dependency-resolving package manager that makes including or excluding optional dependencies easy would offer the best of both worlds here. I'm not saying I'm dying for such a package manager, just pointing out the flaw in your argument.

The system administrator (that's you) is the one responsible for resolving dependencies on your Slackware system. I see the lack of dependency resolution in Slackware as a strength, not a deficit. You have complete control over how your system functions. I highly doubt that dependency resolution will ever be added to Slackware. Why break something that functions properly?
I suggest that you take time to get to know Slackware. There is a reason why our distro is legendary.

1 members found this post helpful.

Dependency resolution means that the entire project grows in size from a small project like Slackware to a huge project like Ubuntu. More people for maintaining packages are needed, which requires more volunteers or paid workers, this means also more server space is needed to host the files, then you have to constantly test packages to ensure they work against newer or older packages, and then you have to not only provide a developer platform but a release platform as well... etc. etc. etc.

In short.. it's a royal pain in the ass.

By keeping Slackware limited down to only what is absolutely critical to function it eliminates problems of all shapes and sizes. While Slackware does have at least a Dual-Layer DVD worth of an installation and packages, by comparison to other platforms which include software, Slackware is still one of the smallest mainstream distributions.

Plus, Slackware has a good learning curve any network or systems administrator should learn which is package management and dependency resolution. If you use the SlackBuilds website you can actually learn which dependency packages are needed by programs and how to resolve them.

Trust us when we say, "learning manual dependency resolution through effective administration" is a good thing to learn, because in the end, you will be glad to know it.

Ubuntu is a beginner friendly distro that offers a graphical installer and graphical tools for just about everything you need. Ubuntu also offers dependency management through the apt-get package manager or graphical front ends to apt-get like Synaptic Package Manger of the Software Center.
Ubuntu is based on Debian but the upstream Debian packages are modified by the Ubuntu developers.

Ubuntu has become increasingly bloated in the last few years. Ubuntu also now uses the smartphone-like Unity desktop. I have switched to using Lubuntu with the LXDE desktop. It is the fastest and lightest member of the Ubuntu family and offers a simple clean desktop with LXDE.
I have not found Ubuntu to be unstable or buggy, just bloated (i.e., heavy on computer resources) compared to Slackware.

Slackware is "hard core" distro. By this I mean that the installation, configuration and administration is done with basic command line tools.
Slackware is also "plain vanilla" Linux. That is, all upstream packages are presented as they are straight from the developers without modification. This leads to more stable and predictable computing in my experience.
The dreaded dependency management is not really a problem at all. Slackware comes with most of the tools and libraries that you need to compile third party packages. And with slackbuilds.org and sbopkg, installing, upgrading, and uninstalling third party packages on Slackware is almost idiot proof. The lack of a "smart" package manger lets you add newer versions of packages at will without having to fight a package manager that resolves dependencies.

I think Ubuntu is easier for beginners. Slackware is better for people who want to take the time to learn Linux.

it's rather CRUX gone wild

I think it's called "Gentoo".

1) Slackware full setup has no unresolved deps.
2) For ex. try to figure out what packages nmap-*.t?z needs. It has zenmap -- python GUI for nmap, so it needs python and X. So, how to install nmap on console-only Slackware system? To solve this you need to split package to two or more. But this contradicts to KISS rule. Continue to move in this way you get something similar to Debian. So, why not to use Debian for Debian-like behavior?

1 members found this post helpful.

Thank you for mentioning this. Exactly. A full install of Slackware works out of the box with all dependencies met. I recommend a full install of Slackware for users starting out with Slackware. If you have some experience you can customize your installation.

I install slackware full, and have a sbopkg queue file with all the additional tools / games / whatever I want in order and ready to go. After install, boot, get network up, and run the queue file, go get some coffee. I complete system will be there when it's done.

apt-get is some cool tech, if you don't want to know what you are doing and don't care what it does, as long as it "mostly" works... upgrades can be fun, dist upgrades can be even more so and you end up with tons of packages, daemons, etc that you don't want or need.

Given the choices, it's slackware for me, every time.

p.s. can a distro be called linux if it can't compile after a full install?

No need for apt. I generally do a full install of Slackware on all my machines and use slackpkg and sbopkg for updates. Only on my VPS account do I have something slimmer (stripped to under a Gb, despite including a full development environment). The only reason I bother to strip it down there is because my VPS package only provides 20Gb, so a full install would be a significant percentage of the disk space leaving less room for actual files. That said, achieving a small install only takes effort the first time you setup a machine and configure it as you like. After that you are just pulling in updates, which is as easy as on any other distro. So I would argue that apt is overrated.

P.S. For a desktop I can't think of a single good reason to bother slimming the install down as I explain in more detail on my blog (in short there is no speed gain and the disk space used costs almost nothing).

A nice example of why dependency tracking can become a royal pain in the ass is one I encountered a while ago. I had to install another version of LDAP on that system than the system was supplied with. In the end, I had to use another type of server, because the packages that depended on the ldap package could not be uninstalled because the packages that depended on the ldap package were depended upon by yet another set of packages, somewhere up to the kernel package (!!!!) So, I had to uninstall the entire system, just to be able to uninstall a package I did not need nor use.

Another funny one might be PHP: it has so many optional dependencies, that you can argue what you want, but try to remove mysql from your PHP build and insert PostgreSQL instead, with packages that resolve their dependencies.

Never ever, will I go for a system that does automatic dependency tracking for me again. (Not that I ever by choice of my own did that, actually.) I'll personally do all I can to rip that part out of the system. It can bite you, and when it does, it bites you hard. In the nuts.