zenogais
Later on you can drop the diagrams entirely and perhaps keep them as some onboarding documentation if they're still useful.
Better title: "Why are drivers killing more pedestrians?"
[1]: http://www.robertgamble.net/2012/01/c11-generic-selections.h...
The only reason you don't have to worry about this is because std::vector handles it for you, at least in the code examples provided by the author. If you choose to go with a pure C implementation (which is what I'm trying out) then you will have to keep track of these.
> The reason I suggested -1 is because when we iterate through bd->items, we need a way to know if it's a valid value or just "holed".
Yep, I was able to get an example using -1 as a sentinel working and passing fuzz testing.
I think I've figured out roughly what the author intended, code below [0].
First, it looks like he's relying implicitly on data stored in std::vector. Namely vectors have both a capacity and a size. The capacity is total number of allocated elements. The size is the total number of elements stored actually stored.
Second, vector::resize won't reallocate until it runs out of capacity, but it will give you access to extra elements if you need them. So this is used to lazily re allocate while bumping up the size of the vector.
Both of these effectively make it "do the right thing" by leaning on the vector storing both size and capacity.
If you hand manage those values yourself you can get a pretty compact C implementation without a lot of code.
One last thing: Using a union here for the item_t is pretty much guaranteed to get you a segfault. The whole thing should really be a struct. This also allows for setting next to sentinel value if necessary.
[0]: C code for bulk_data_t example: https://pastebin.com/Tfcdt39h
For the bulk data with holes code:
First, there's an initialization step that has to happen the first time you allocate your bulk_data_t. Namely, you need to iterate through every item in the list and set its next_free item to the item following it, looping the last item back around to zero. You also need to do this for all the items between the new size and old size every time you resize your item list.
Second, safe iteration over all of the bulk data doesn't seem possible without adding some sort of flag to indicate whether or not an item is free.
Am I missing something here?
[1]: https://jacobitemag.com/2017/08/29/a-i-bias-doesnt-mean-what...
This reads largely like a recapitulation of Boehm's 2003 book "Balance Agility and Discipline" [1]. Have you read this and did this provide any inspiration for the article?
[1]: https://www.amazon.com/Balancing-Agility-Discipline-Guide-Pe...
See this wikipedia page for a list of all such authors: https://en.wikipedia.org/wiki/Aphorism
Bad estimation techniques - eg. guesses without a basis in historical data (most developers don't collect historical data) - are usually wrong. No one would argue this point.
If you do iterative development with intelligent planning and collect some historical data to use in estimates the game changes. First, most of the examples of "unexpected complexity" you gave can now be identified early and factored into your estimates. That leaves the 1% of truly unexpected stuff that you can then deal with as it comes up and factor into your future thinking in a post-mortem. Second, since you now identify risks earlier and can factor them into estimates, most of your work becomes estimable, and with historical data your estimates will improve.
There's even multiple process products around this idea already, but they're mostly used in the "safety critical" industry, see [1] [2].
[1]: http://resources.sei.cmu.edu/library/asset-view.cfm?assetid=... [2]: http://www.sei.cmu.edu/tsp/
PS. Understandably, we might not all even agree on what a better world would look like.
Really this shows that a small group of people plus a core team already leaning in one direction are probably enough to fork the network.
All of these seem very possible to crowdfund with the ultimate goal of unhooking them from perverse incentive systems of typical universities.
For example, giving authors / organizations a Bitcoin address where they can receive funds from individuals / organizations who want to support their research.
Also, awarding reputation to authors based on the level of peer review their research has successfully undergone (number of peers, level of rigor, etc.), and conversely awarding reputation and funding to those who perform peer reviews. Allowing users to contribute to a peer review fund for individual articles or in general.
All that to say this is very exciting and opens up a lot of new possibilities.
[1]: https://www.reddit.com/r/ethereum/comments/4oo1io/an_open_le...
IMO it probably won't be overly onerous to develop reliable contracts of this size using many of these techniques. It's just so few people have the discipline to delay implementation for design and planning at the level required when it needs to be bug free. Most software developers have no training in how to even begin designing and developing using these techniques.
[1]: Shuttle's primary flight software contains 400,000 LOC http://www.nasa.gov/mission_pages/shuttle/flyout/flyfeature_...