I used to joke that when SO goes under, I will move professions. The joke came from my experience of how many common issues in technology could not be solved with knowledge found via a search engine. I don’t see that niche as gone, so I wonder what is satisfying that requirement such that new questions do not show up at SO?
TFMs are not a thing anymore. Most of them are merely collections of sparse random dots one might join by sheer luck only, granted no other knowledge of the system being attempted to document.
Time to just call these tariffs: sales tax. Extra money for the government on all goods imported are taxes. The rest of the complexity distracts from the basic cash flow and the inevitable results. More money spent and consumed by the government.
Right, but the goal is to solve a marketing issue. The Trump base is resistent to criticisms of dear leader and the mechanisms behind tariffs raising all prices can be misunderstood (and let's be honest, who really trusts economists). Call it a sales tax, they know what that is. The mechanism doesn't matter.
Complex solutions are easy. Simple is hard. Often simplicity takes time, iteration and understanding that comes from actually operating a system. I think the missing link here is the Kaizen-oriented refinement that turns complex into simple over time. I find that modern OO-languages frustrate this process by needing cross-cutting changes to refactor for incremental improvements. Expression-oriented languages (like Clojure) are much more fluid, enabling the incremental refactoring required to transform the initially complex and awkward system into the simple and refined scalable system. Unfortunately, just like other languages, it is possible to write difficult-to-change systems in Clojure. And that seems to be often the way it is done.
Specifically for clojure, do you have any recommendations about how to make systems easy to refactor? I've often read discussions about how dynamic languages are quicker to write and more difficult to refactor than static ones, and I've had my fair share of dealing with issues during refactoring of clojure code, but I don't remember having read anything particular around clojure best practices. Googling for a bit does not produce particularly insightful results, so if you have any insights that'd be awesome.
EDIT: Part of the things I'm finding are my own comments in HN from some years back, in fact :(
Yes, I like to call the style Procedural Composition. The key characteristics are no logic with IO, and all system functions are assembled from higher-order middleware functions. This is the way ring, the web framework, and various client libraries like clj-http work. One of the best ways to get familiar with it is to look at the ring libraries.
What this allows one to do is assemble handlers from lots of small higher order functions. It has the downside of one needing to have initialization well organized and thought out. But the fractal-cul-sac as one co-worker has nicknamed it of ever dividing and increasingly specialized functions with IO and logic twisted together is effectively prevented. One can always modify one handler without affecting others or changing how existing functionality works. And it is always testable in small unit tests because the logic is pure.
Systems built in this style can radically reform themselves in a controllable, reliable and consistent way indefinitely. They are immune to the "apogee" phenomena whereby a system gets to the size and fragility where it can no longer be modified without causing unforeseen regressions, triggering the need to rewrite it to move it forward.
This style is for handler-oriented procedural software common in web services etc. It does not apply to embedded state-machine oriented software that operates real-time control etc. That is a different problem space.
The reason it's hard to refactor to simplicity is that one must feel free to modify foundational assumptions, and the repercussions of that change are both hard to implement (you must recapitulate all following changes with the new assumption) and test. By "foundational assumption" I mean architecture at the high level, and general code organization at the lower level. It is the "second system" problem, writ small but many times over.
Given that code grows over time in accordance with selection pressure, these lateral, foundational changes are always going to be difficult because recapitulating the following growth in general takes the same amount of time as the original system took to grow. The irony is that if that system is making money, it is even LESS likely that the will to simplify it will arise; if the system doesn't make money, then there will be neither will nor resources to try it.
"Physics progresses one funeral at a time", Planck's Principle [1], applies here. Software gets simpler but not laterally within a working project; it only gets simpler with new projects. Luckily software devs seem more open-minded than physicists so we can progress faster than funerals, but not arbitrarily so.
Changing and refining Clojure code is a remarkably pleasant experience. There's very little state, so you can usually just grab what sexp you need and extract it.
I saw a 2x2 matrix recently that showed how NP-hard problems require exponential time to solve but polynomial time to verify the solution. It gave examples for every other cell of the matrix besides (exponential time to solve, exponential time to verify), which it left as blank or N/A.
I think we have found something that fits that square: truly simple solutions. It's easy to come up with a simple solution that is unsatisfactory, that's not what I'm talking about.
I mean a solution that is so simple and complete, that it was HARD to come up with. It's easy to verify that such a solution is simple, sure, but it is HARD to verify that the solution is truly complete or satisfactory
> It gave examples for every other cell of the matrix besides (exponential time to solve, exponential time to verify), which it left as blank or N/A.
I would be interested in seeing this matrix, because it sounds incomplete to me.
Any NP-complete problem, as in a problem that is exponential to solve but polynomial to verify, is a "decision problem" version of a "optimization problem" that is exponential to both solve and verify.
For example, the decision-problem version of the traveling salesman is, "given a graph of nodes and weighted edges, does there exist a route that visits all nodes with a total edge cost of less than N?" Solutions are hard to compute (evaluate many paths to find a good solution) but easy to verify (evaluate the given path exactly once and compare the cost to N).
Meanwhile, the optimization-problem version of the traveling salesman is "given a graph of nodes and weighted edges, what is the route that visits all edges with the least cost?" The solution is now both hard to compute and hard to verify, because to verify it you also need to consider the entire decision space to determine whether or not there's a route with a lesser cost.
I don’t wish to be too much of a fly in the ointment. I understand the darkness of dark patterns. But if we wish to not be secretly tracked (which is dark), then isn’t the alternative to openly ask if I want to exchange knowledge of my identity in exchange for the content I seek, so they can target the ads that pay for the content aggregation service I am using? The preceding question mark is not rhetorical. Maybe I am missing something? In the end though, Cat picture or not, the people that provide the service need to get paid.
Could you please tell me how to do this? I've been trying for a long time to export HTML documents to PDF from the browser and could never get internal links to work.
Microsoft Word can do it, but you must _save_ the document as a PDF. I know this because I've done it dozens of times, as recently as a year ago.
Notably, you _can't_ use PDF printers to accomplish this. PDF printers reduce the document to only visual data, losing interactive features.
I know Word isn't part of your solution but maybe this distinction between saving the document as a PDF vs. running the document through a printer driver will be useful to bear in mind in your case.
But I also suspect that you might have succeeded in the past unknowingly. This is because many, _many_ PDF viewers do not support internal jump links. This is apparently too "advanced" a feature for most in-browser viewers, for example, including the built-ins.
If you aren't already doing it, always test whether features are working in Adobe Reader before checking with viewers which may have reduced featuresets.
Thanks a lot! I'm exporting HTML documents to PDF from the browser on a regular basis, and normal http links have never had any problem to work, while jump links have been impossible.
Processing everything through Word after export could maybe be an option. In my experience exporting from the browser have been the only option to get nice PDFs. Everything else I've tried have mangled the layout something terribly, and Open Source converters are all of low quality.
It could be that it is the PDF clients that refuses all jump links, but then the problem is unsolvable, since these PDFs have to work on normal consumer devices such as Android and iOS phones. Apart from the jump links, PDFs are a god-send, since they work well everywhere.
