Hello everyone, I'm starting a new blog where I'm trying to mix my passion and experience for safe programming in critical contexts, and my (over)use of Python, and other techs that are used in... less safe contexts. The "investment hypothesis" if you will is that pieces of tech used daily in critical systems could see a broader use if they stopped being hidden behind mumbo jumbo, bad UX, and general lack of consideration for the common developper. In this blog I'll try to go and discuss fuzzing, contracts, why not some amount of lightweight proofing... and to mix them with application that are hopefully fun and nice to study.
This first post is about counting sheeps, with a design-by-contract twist.
Let me know what you guys think, it's my first blog at all, so I'm a taker for all matters of feedback, as long as it comes from the heart that is ;)
I think it's not saying that time is wasted but that it could be better spent verifying the same thing with other techniques. For example you could implement a graph type that guarantees absence of cycles at all point. Such a type would be great except for the fact that in most cases you would be better off preventing such cycles by construction, e.g. by only adding edges directed towards nodes that are not added yet.
I agree completely with the premise and the conclusion, however I would not describe types as moving errors to compilation time, but as moving effort to the earliest parts of the workflow: more time spent on writing code, more time spent on thinking before doing, more time spent on specifying your interfaces. Agreed on the diminishing return as well: use them as long as your leverage (= time saved debugging / (writing time + reviewing time + maintenance time)) is good, maintenance time in particular is often overlooked: how much time will it take to train the new recruit so that the understand your oh-so-smart custom types?
I would say it's a tool with an optimal point that is located along the "heavy use" side. I think it is interesting to think of them as solidifying your specification. As such if your spec is still changing or it is unclear (e.g. first impl draft, example code...), you should use some lightweight types, whereas a public API should have types that encode basically everything your comments can say about the values, operations, and memory representation of the parameters. That would be the point where I would consider that defining my types is "done" and I would consider switching to e.g. moving the functiona around instead (there are lots of hanging fruits in safe by construction approaches, that might not even require types - can't shoot yourself in the foot if I remove the footgun entirely)
And yet, most IT will see it as an opportunity for locking down systems and policies, instead of the call for help shadow IT is: people want systems that are reliable, efficient, and adaptable to rapidly changing business needs. Providing them is part of the core mission of IT, and they're failing at it in some companies. One anecdotal example: I'm responsible for doing trainings at my company. If I see someone providing trainings on their own, creating their own class material, using their own platform... basically wasting company resources; I don't consider it shadow training but I take it as an indication that A. they have a need B. are very willing to work to achieve it and C. I'm not filling up that need properly, maybe not even communicating correctly about it. I take ownership and I don't play vigilante. When IT are providers, helpers to the employees, instead of self-appointed inquisition on a mission to purify the systems and its users, it works for the best.
"Just fire discs" well that's easier said than done, and there's probably a tons of reasons nobody uses discs. One of them is already that we have no experience building or using disc-shaped bullets, especially compared to the trove of experience for... bullet-shaped bullets. So that's not a solution as much as it's an indication that this defense mechanism wouldn't be perfect given an adversary with enough time and will. That being said, nothing is ever perfect, and "arms race" are named this way for this exact reason.
The worse relationship I've had were in small companies. "Oh but we're so small we cannot afford raises" coming from the same people that are selling it millions later in the year.
I guess it means for some "plan do check act" loop, you want to avoid doing a plan, a do, then to plan again (because you have something important to note), then do a bit etc... This kind of back and forth were you subvert the principle by turning the loop into a 2 step pseudo-iteration.
No disrespect but judging languages on syntax is a lot like judging a book on its cover. Chosing a language is, for the experienced programmer, a choice of ecosystem, libraries, tools, architecture, and also a matter of long term maintenance, evolution, technical debts. Gscript scores very low on all of these, especially compared to the behemoth that is C#. Only unexperienced programmers and sales people use the "it looks somewhat similar so it must be" argument.
I wouldn't say overplayed as much as badly played because they underestimated
how much their CEO's had fortified his position. I find the situation pretty dire: we need more checks and watchmen on billionaire tech entrepreneurs, not less.
Ah if only it were that simple, truth is a company, especially old ones, have a value function that is in flux, and this may include revenue generation but more often than not this is completed or replaced by replaced by some variation of political clout acquisition: it makes them unkillable even with a negative balance sheet.
The advice about if up is not bikeshedding though, it is the exact kind of architectural choice you're saying one should decide on. Don't believe me ? Well imagine you have inputs, where should you validate them ? According to this rule of thumb it's at the topmost level, when they are received. Well that seems super sensible, and it's typically something that helps with understanding the code (rather than checking them at thw very last moment). Also for proofs that's technically necessary to allow the preconditions to "percolate up", which has the same effect of moving the if up.
So the first advice is definitely not bike shedding, the second one I'm not so clear though ;)
If you practice it daily, after about a week pushing that to 60 minutes shouldn't be too hard, it's not physical after all. What's important is to have a great setup so that it's super comfy for you to stay a long time without moving: hot, background noise should stay low, use some mat or pillow to sit on, and here you go...
6 minutes seems awfully short, I havent practiced meditation for a long time but my sessions where 20, 30 or 60 minutes long, it takes time for the mind to settle down and to benefit fully from flowing consciousness. Anything less would feel like a rush job, which is kinda paradoxical for meditation.
If you care about visibility control and minimalistic API design, then the most basic OOP features also provide a set of simple but powerful features: encapsulation, and contextual info on overload resolution (A.foo() is the foo() from A's type, no just any foo that can take A)
That's not quite the full picture you're painting here.
First of, at the moment the effort is super asymetrical: it takes way more efforts to check a paper for image duplication than it takes to alter an existing image to add it to a paper. So the journals are losing against the counterfeiter as we speak.
What's more, it is possible to run the detection tools long after publication, which makes it harder for someone to fake images because they run the risk of being detected later on with a more advanced version of the tooling. Typically malware devs try to erase all traces of their bad deeds and to run away undetected for this exact reason. But how do you hide an already published paper?
Finally, it takes efforts to run the tools. If this effort is greater than the effort it takes to fake an image, which it is, then the cost may become prohibitive, so fakers will try to avoid faking+prechecking in favour of faking+hiding (by publishing in unchecked journals for example). That is until they group together to organize faking at scale (setting up and automating a tool like that is probably were the cost is, not running it). Faking at scale does exist, some countries practice it eagerly. So now the question becomes: do we turn a blank eye to such blatant misuse of research or do we try to take them red-handed and to ban/punish bad behavior? Not such a hard question since being on the offensive is the only scenario where we have a remote chance of stopping or at least reducing the influx of faked papers, you don't stop the mafia by ignoring them.
IMO this is not the technical level that matter, it's the UX, if we leave aside the super duper AAA games, which would use Unreal, then it's about putting a whole lot of different assets together, and hold them with code glue. Unity has some nice things that are not there yet in godot (from the top of my mind: better font support, in term of UX once again), and C# is way better than thw half-assed language that is Godotscript.
That being said I'm pretty sure that Godot is about to close this gap before 2025, given the recent boost in popularity.
Le Nez in this context means the aromatic palette, through a metonymy. Not sure it translates well to English, since this stylistic device may be very French in its usage (another example would be Musée Rodin's exhibition Rodin, la main révèle l'homme)
I think what the poster above is going for is that the level of safety (as total number of saved human lives) resulting from turning a (napkin or otherwise) calculation into a definitive technological choice is probably suboptimal. Typically we would want a safe process to include retroaction or "self-improving cycles". That is not a single point of measurement or calculation is being used but instead we do provision for future safety evolution of the system, and monitor the safety conditions by setting up regular measurements. So, what is considered safe is not any standard in itself, because as conditions and technologies change it may become outdated quickly, but rather the process to redefine that standard so that we have confidence that our product is not only safe but that we can keep it safe in the long run (since we want to optimize on the total of lives saved, not on a weekly or monthly death toll).
A calculation that leads you to underdesign a product's safety and leaves no room for this product's safety improvement, in terms of mechanical or electronic update, is clearly not thought as being safe in that regard, regardless of the economies of scale or even low-term utilitarian goals (that would be expressed as: people spending money on a tesla would be safer in the short run, rather than using no automatic driving at all while waiting for a better product).
This is an important difference, and there is a societal choice to make here: do we (as society) want to buy now, and potentially have regrets later (when the safety of the product degrades with time, causing it to also have a record of people's deaths), or do we want to proactively force a notion of safety onto cars that is more than just being good enough at an arbitrary point in time, so that we hav more confidence over the long-term viability of that (societal) investment? As you can guess I gravitate towards the later, but of course it's a gradient, with several choices in-between, because pushing that thinking to an extreme would lead to stagnation, which would not do anything in terms of improving safety, as you noted.
Yes that's not even worth one single low wage employee salary, also this 20k figure is extrapolated from X's public prices, so it's not even very reliable as an estimate. It could be that tesla has entered some contract with X, we don't know. I'm pretty sure customer deaths due to a hackish autopilot function, or markets manipulation tactics are more interesting if you look for stuff that stinks in the Muskverse.
IKEA crap can last decades but not all of it. As an example I have used an IKEA desk for 6 months, and it showed real ageing by the end of it. And I was not eating at that desk, or sawing stuff, but some of the heat from the computer and maybe palm sweat? were sufficient to damage it. That is not durable.
Operator overloading has been a feature of many languages dating back to the very concept of using operator notation in programming. I know of no language that has the * operator dedicated solely to a single type. Typically you have at least signed and unsigned overload, as well as various bit sizes (including larger than the machine word size), and floating point representations. Extending that to vectorial operations, arbitrary precision, and others only seem to make sense and to be going with the flow...