Weirdly, programming this stuff not from scratch can be harder if you use the apis that will utilize the GPU like vulkan or modern opengl.
309 karma · joined November 4, 2020
Either way for the fastest algorithm out of the set or sorting algorithms that are known.... Most likely it’s a family of algorithms that share the same speed metric of O(N). There may be an algorithm or several algorithms that are faster. Look it up, you might find it.
What I can guarantee you can’t find is the best design pattern or style of programming. There is no theory here let alone a definition for “best.”
It’s obvious your question is trying to take the conversation in some other direction. Let me try to guess it. Your probably going to talk about other intrinsic downfalls and costs to sorting outside of the speed metric like memory or the domain limitation for O(N) sorting algos. To which I respond memory has nothing to do with the speed of the algorithm and is off topic from my claim. We know the fastest algorithm(s) by definition, because the theory of what is faster and what is not is fully fleshed out.
The theory on which is the best algorithm to use in a problem given the speed and memory cost is something we don’t have a theory for yet, hence the usage of best practices, which further proves my point. This is where you conflate things, you didn’t separate aspects of areas described by theory and aspects not yet described by theory. You mistakenly lumped everything together.
Hopefully I anticipated your actions correctly and you are the one who is taught a lesson here rather then your intention of teaching me something via your trap question.
Second explaining architecture is not solely an architectural job. It’s mainly the job of the person who writes documentation. The “architects” job is pretending he knows some “theory” of architecture more then the engineers actually coding the “architecture” when no such “theory” even exists.
Yeah I can see that given how off the point you are in your posts. Your initial response is that the separation of form and function is a mistake.
I’m saying it’s not a mistake, separating form and function via abstraction is intrinsic to the industry and I use UI/UX as an example. Your retort is that UI/UX abstractions are notoriously leaky.
How does a leaky abstraction move the conversation in any direction? Most abstractions are leaky, everyone know this, but despite this we still need to program our computers via a high level language designed to separate form from function. Otherwise everyone would use assembly language. The leaky ness is known but to manage complexity we have to separate form and function.
So your statement is completely and utterly wrong. Your responses fail to prove your point and go off topic into unrelated metaphors, tufte and Tex. Stay on topic.
Either way you are wrong about math. All decisions can be mathematically modeled. It’s called a conditional expression, and you use it to model/calculate decisions when you program.
Logic and Science are different in the sense that Logic does not require any evidence. Logic uses simple assumptions called axioms and then theorems derived from those axioms to make broader statements about the system. A computer is basically a system molded around logic so that you can use logical reasoning to derive statements and ignore evidence. This is what I mean by "rigor." Ironically, for convenience, testing (aka science) is used in computer programming even though formal analysis is a stronger (but more challenging) form of proof.
Science on the other hand is more evidence based. If evidence contradicts logic than the evidence takes precedence. The medical field is more science than it is logic hence the distinction. A computer programmer can use heavier reliance on axiomatic reasoning to derive statements but the medical field will defer more to the black box statistical results of evidence.
The difference is literally the same difference between math and science. Computer Programming blurs the line a bit but overall programming is closer to axiomatic reasoning than it is to science.
This statement is patently false, especially for UI/UX. Even at the lowest level there are platform agnostic API's (opengl) that are divorced from CPU/computer architecture. At even higher levels, javascript/css/html is a graphics API that is divorced from even the operating system. Separation of form and function is the foundation of software. It cannot be a "fools errand" when all of UI/UX is designed with the separation of form and function in mind.
It is therefore fundamentally impossible for you to stand by a notion that is completely false. More than likely your statement is just a mistake and you didn't think it through. Such is one of the downfalls of "Architects"... they are so concerned with high level truthisms that they fail to even build the correct high level picture of the computing world.
For software systems, the devil is, unfortunately, in the details.
Theoretically, those "software architects" would put a stop to "over-engineered" solutions, but why do these companies still have technical debt?
Most likely because technical debt is not solely just "over engineered" solutions.
Ok, so you are basically implying that your opening statement is wrong and what you meant to say is that abstractions do not have zero costs and that the industry is unaware of this. Just admit you're wrong instead of relying on the political stratagems used by "architects" to stay relevant.
I would argue that everyone is fully aware of this concept. It's a necessary evil done to reduce complexity otherwise we would all be programming in assembly language. As for AWS specifically, isn't it proof of what you say? The technical details are leaking into the interface showing that function and form can't be fully separated.
If you're saying the architecture of AWS should have been holistically designed to support a more intuitive interface, I would say you're describing another problem all together. A holistic design is a synonym for "waterfall," and there's a good reason why it's avoided in the industry.
The problem with waterfall is that the current needs of the market is always a moving target. No architect or even UI/UX designer can predict the needs of the market in the future thus things are continuously put together agile style (aka ad hoc). This produces technical debt which is something neither Architect nor the UX/UI designer can solve. AWS definitely suffers from some debt and the UI reflects this, but again, this is NOT because they lack "architects" as every company has this problem whether or not the company has "architects."
It's obvious that abstractions have costs and it's obvious that sometimes things are designed holistically. But these obvious things are off topic. The point here is that your initial statement is completely and utterly wrong wrong wrong.
Please stay on topic. Are you still claiming your initial statement is right? or are you now claiming it's wrong? Don't change the topic into the industry "passing the buck to UI and UX" this is not your initial statement.
When I went to Standford to get my PhD is Software Architecture I was required to take at least 2 semesters of classes on the theory of naming things in software. The biggest point the class made was proving mathematically how one should never name anything after a plant, Greek/Roman god, gemstone, animal or molecular structure.
An "Architect" can't solve this problem anymore than an "Engineer" can fix the problem of technical debt because neither person can see the future. It's like pointing at everything wrong with a piece of technology and saying an "Architect" could've fixed that in hindsight.
"Architects" are not the solution to technical design and technical debt.
An engineering manager can place all engineers in a room and ask them to come up with an "architecture" that is the same if not better than anything a single "Architect" can come up with, and this "Architecture" will never solve the problem of technical debt for the same reason why we can't predict stock prices.
I neither agree or disagree with your remark about "Wholistic" designs but your example is extremely inapt.
The entire MacOS is programmed using a an interface separate from function. If they didn't program the Operating system in a higher level language that can be compiled into separate architectures then the move to ARM would be an even more complex engineering maneuver. The entire reason why Apple was able to move to new hardware without completely rewriting the software is because Form and Function are separated.
The parent poster declared that AWS needed some "architects" which I think is kind of arrogant given the fact that most "architects" don't even have the ability to engineer the tools built by AWS. They are just "mere" users of the tools.
Usually there are "costs" to doing this and much engineering work is done to reduce this cost as much as possible. Either way, what you say is categorically wrong. Separating form and function is not a "mistake" given that it is so fundamental to the entire industry.
Curious as to how Christians rationalize around this. If you're christian how does the existence Zoroastrianism fit with your world view?
I am not interested in the validity of your justification and thus I won't debate it (that would be against the rules on HN). I am just interested in the justification itself.
This is the Technical product managers job. The architects role is suppose to be an extreme high level view of purely the technical side of the business.
From my own anecdotal experience "architects" who try to fulfill the role to the definition end up being mostly useless.
We've formalized how to define the "fastest" algorithm and for that we have definitive answers on what is faster and what isn't.
Our notion of what is "best" is the thing here that has not been formalized. "Best" is a vague word it needs to be defined before it can even be formalized.
My bias does not allow me to think of a better way of verifying reality by assuming observation, probability and logic is recursively true.
Is there anyone here that doesn't share my bias and if you don't, why?
Think of it like horse drawn wagon vs. a car. There might exist a guy who in his humble opinion thinks the wagon is better so he use it to get places instead of a car but is that guy a reasonable guy? No.
The analogy I mentioned above is more apt because Mongo was indeed at one point in time more of a wagon rather than an unpopular piece of music.
You don't see any "best practices" for making algorithms faster or more memory efficient. We have complexity theory that tells us the metrics definitively. This just means for algorithm complexity formal rigor has been established.
For areas where we use the word "design" or "best practices" or "code organization" it's mostly people just randomly guessing things because there's no quantitative metric to tell people whether or not a guess is actually better or worse. What's the Big O of FP vs. OOP? Who knows?
Nobody is clear about what is being measured here. What makes a "bad design" bad and what makes a "good design" good? Once we figure it out you will see that the word "design" will largely exit the field and be replaced with something along the lines of "calculation." It is better to "calculate" the best way to organize code rather then to "design" it because the word "design" is a synonym for "random best guess".
The lack of formal rigor or some statistical metric means we can go into circular arguments about these topics forever.
And no design can fix a bad tool, we can dive into the practicalities here but I'm more of a philosophical person so...:)
All tools, including programming languages can be bad no matter the skill of the user.
It's impossible for EVERY tool to be good. This isn't reality. There has to be tools that are patently bad to use and people have used these bad tools to build great things. But it doesn't change the fact that a tool can be horrible to use.
I would argue that at the time the article was written, Mongo was definitively a bad tool. Things have changed, but not all things.
Why don't all countries use metric? Not everything in this universe needs to follow a perfectly logical explanation.
As for the pictures, I can say the most famous brand people are most familiar with where I'm from is sees candy chocolate boxes. I've never seen Kraft candy, that company is mostly known for cheese. If sees candy did label their candies I've never seen it and therefore it must not have been very evident.
Regardless what you think, the quote exists because most people usually don't know what they're eating when they put these candies in their mouths. See here for the quote: https://youtu.be/egkrxkiUnoo?t=43
If you squint you'll see that's a Sees candy box.