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 love that, going to reuse that one

Don't credit me, it's not original, but I don't know the actual source.

First time I heard it, it was about XML. So, quite a while ago.

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.

This. Shadow IT is a symptom, not the disease.

"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.

Ah I got it to work for two movies :)

You just made disco stu very happy, if these trends continue- 'Ey!

All the 847 chapters of Philodemus fan fiction of MLP (my little Plato)

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.