Its because "reality has a surprising amount of detail". It is actually the rare occurrence where a simple solution solves a complex problem. I link an excellent article that has been posted on HN multiple times, that explains exactly this.[1] (not mine)
This is very apparent in my work right now, as well as "all models are wrong, some models are useful".
I'm parsing some "simple" CSVs into a DB, but I have to keep the concrete representation intact for another purpose. The DB format will be similar to the CSV format, but can't be quite the same. I would've figured this would take a day or two (I've written many parsers before), but the amount of details I have to consider has lead me to circle back to this problem for a long time.
If we used ascii delimited values none of this would be a problem. The amount of effort spent on csv must be close to a million man years and all because we want to edit the files with a text editor without a special mode.
The files are CSV-adjacent, I should say. The issue here isn't the delimiter in fact, it's the fact that the format differs slightly between files, even within the same project. That, and the mismatch with the SQL DB format I want.
After rereading the post I realize that the op was talking about the schema of the files rather than the adhoc nature of trying to decode escape characters.
Not sure if it's just me, as I'm relatively new to the field, but I notice a surprising amount of people assume that the details in programming have already been made intuitive to them, and they use this "experience" to push ideas that are at odds with other domain specific details. To me, maybe this is what the author means by "stuck"?
> If you’re a programmer, you might think that the fiddliness of programming is a special feature of programming, but really it’s that everything is fiddly, but you only notice the fiddliness when you’re new, and in programming you do new things more often.
Yes off course, but with the obvious disadvantage that you lose resolution for every filter you add. Then you say let's just increase the pixel count, which means smaller pixel pitch. But then you lose low light sensitivity, have to decrease your lens f/#, so more expensive lenses etc... Which is why it isn't done for commercially / mass market sensors.
I read that as: take a bunch of pictures of a static scene, each with a different filter capturing specific frequency bands individually. Merge afterwards with whatever weights or algorithms you want.
You also need to take into account your manufacturing precision you can achieve with fabricating the lenses, how accurately you can position the lenses relative to the work piece etc. From my cursory reading of the paper it assumes perfect lenses and positioning, and only simulates the alignment procedure. Still, a worthy paper, but as others have mentioned, not much different than the methods used for optics alignment.
That's because IT security reports to the C level, and their KPI's are concerned with security and vulnerabilities, but not the performance or effectiveness of the personnel.
So every time, if there is a choice, security will be prioritized at the cost of personnel performance / effectiveness. And this is how big corporations become less and less effective to the point where the average employee rarely has a productive day.
Similar reason why the earth north pole is actually a magnetic south pole :) It was decided by convention / definition.
For those whom it isn't clear what I mean. Compass magnet's north poles point north, which is only possible if the earth's north pole is magnetically a south pole.
There is a joke, that in order to facilitate such a change, it should be done in more manageable steps. So on day 1, only the motorcycles switch over to the other side of driving, on day 2 the motor vehicles, and on day 3 the trucks and busses switches over...
[1] http://johnsalvatier.org/blog/2017/reality-has-a-surprising-...