556 karma · joined March 5, 2018
And while the rest of the world knew how to find a file size... how long was it before C++ cleaned that very very simple corner up?
And if you look under the hood at the implementation of std::conditional.... I feel ill.
The thing I like about Alexandrescu is he invented this meta programming stuff... super super super clever magic...
...and then backed away saying it shouldn't have to be so hard, we shouldn't need magic to program.
Whilst I'm sort of proud of the 'word at a time', always contiguous and zero copy aspects of it... the important bit is the metadata.
All the optimization was really to allow me to record metadata around...
* When was a message posted?
* When did it start to be handled?
* When was it finished being handled?
* What was the correlation ID? (ie. the ultimate causal source of the events chain)
...and then extract this data into a sqlite DB and either query that directly or to create message sequence diagrams with the mscgen tool.
Why is this important?
Because I have lost count of the really hard, gnarly real time bugs I have solved using this tool.
* Your democratic vote (local / and national)
* Where you spend your money.
* Where you spend your time.
You cannot refrain from voting and all votes are counted.
Vote wisely.
Make executable notes as you read.
FTFY
ie. Add in asserts or logs that check what you believe and log (or abort) if what you believe is false.
Otherwise it's idle speculation that never gets falsified.
ie. Most books on technical are hard to understand, not because the subject is so hard, but because most author's are crappy at writing books and explaining there field.
Hamming is an example of how are hard topic could be made readable.
It wouldn't go.
Takes a log time to digest the man page, but once you have you can do anything.
Where such services are provided by a functioning state maybe, but if they are, they also have a functioning currency and banking sector.
Where their isn't.... I had a Ukrainian friend who said in the worst days of state dysfunction (now decades ago), the de facto currency was bottles of vodka.
At least with a bottle of vodka, you can drown your sorrows if your currency crashes.... So your zeroth challenge is "How is Celo better and cheaper and more trustworthy than a bottle of vodka?
Your web site basically says "Apple Pay", but without Apple.
So how do you get from that to, "a monetary system that creates the conditions of prosperity for all"?
It's not how much disk space or ram it takes up.
It's certainly not the amount of dollars/megabyte it burns.
It's how much mind space of both the user and the developer it takes up.
Alas, mindspace is the one thing utterly untouched by Moore's Law for millenia.
I much prefer it this way.
Retrospective self reported questionaire.
Pah.
Around about the weakest evidence you can get as to what their actual diet was.
I would rate this study as "Junk Science".
And that is the problem.
I have met teams that have gone into analysis paralysis about which unit test framework to use.
I have met teams where one of the impediments to unit testing was "we don't have time to learn something that complicated, we don't understand why all this stuff is necessary".
Answer:
It isn't necessary. Get off your ass and start unit testing with the simplist framework possible.
It's more important, way way more important to just do it than fuss about the framework.
Like TFA.
Once you have actually done that for awhile, someone will say, "Wouldn't it be nice if..."
And _that's_ the time to introduce a framework. Or grow what you have.
On a C project I elected to grow, the nice thing about it is test setup and teardown? It's exactly the same thing as process set up and teardown.
So valgrind will tell you _exactly_ if anything leaked or was uninitialized!
Since you never enter into a conversation you ensure all your replies are pointless and trivial.....
...except you will never know this. ;-)
Any actual documentation and code examples of what it is?
I couldn't get anything from the marketing speak as to what stORMi actually was...
In the space of data modelling, my bet has long been on http://www.orm.net/
As user nemacol said above..... What an awful way to die. Really really nasty.
Take the minutes of the last business meeting you had.
Without even asking your boss, publish them on the open web.
Here on Hacker News for example.
After a day or so point this out to your CEO, telling him you will be doing this with _all_ future meetings.
Report back to us what was the result of your happy chat with your CEO.
I think you will find that, sadly, most of us do, indeed, conspire in secret against the interests of the general public at large.
Combined with Evolution extension.. unbeatable.
I have used SCCS, RCS, CVS, SVN, bzr, git, but hg is by far the least pain and most powerful I have seen.
Which noone has ever seriously claimed for git.
Mercurial + Mercurial evolution outcompetes git rebase workflows in a really nice slick reliable package.
Merges are so hassle free for me these days.
eg. Even though Point may not have a color instance variable, there is no reason why it can't have a default color for all "plain" Points.
Of course, extending this to a smalltalk / ruby "Objects all the way down" hierarchy if Point inherits from Object then Object needs to have a default (x,y) position and colour.
It would seem mad to give place default values for every property of any object ever on the Object base class...
However one could provide default values for Point and ColoredPoint which the equality operator uses.
In the end the only truly robust algorithm I could rely on was a combination of Nelder and Meads downhill simplex method with simulated annealing. I'm curious to see in the overview he mentions neither....
Have they been supplanted by something better? Or is he only considering "nice" functions (ie. "Smooth" even for higher derivatives with no local minima)?
Personally I keep coming across code where the "design" as indicated by names and comments indicate one thing.... but the fact of the code indicates another design.
Now if this indicates a bug, ie. Incorrect behaviour, yup, fix it.
But usually it has been "tested into the shape of a product". ie. The names and the comments and the data structures indicated first, draft, incorrekt, thoughts... and the reality of the code _is_ the correct behavior.
Usually at that point I refactor to reveal what the design really is, down at the mathematics of the code, not what the designer thought it was.
Dug around and found that this is a commonly reported side benefit of a ketogenic diet.
Sounds off the wall until you realize Keto diets were originally used for managing childhood epilepsy.
Well there is a massive bias straight off.
Nobody arrives at a post at random, nor will the toxicity be uniformly distributed.
When last did you go to Stack* and say "Show me a random comment please".
Swipe some from your cat.
Actually nice "case in point".
I have seen evidence presented that it's not the spikes that are the problem, but the "area under the curve".
ie. An insulin spike is just the body doing what it should, keeping the blood sugar in bounds.
However, it's how long times it goes on for times how high that does the damage (to an obese person).
ie. Nutrition science is packed solid with fine fine print and noxious little interactions and feedback loops.
Very little of which fits in a Cosmo magazine sound bite or is applicable to a general population.
So if you look at the [Big Picture of the metabolic pathways in humans](http://biochemical-pathways.com/#/map/1)... what do you have?
Fuzzily defined, extraordinarily complex tangle with feed back loops all over the place, some going through that amazing tangle of the brain.
If you were to translate this into a mathematical model and look at it from a purely mathematical perspective (even if you omit the parts involving the brain).
It's a highly non-linear system of Partial Differential Equation's with many variables and a bunch of fuzzily measured constants.
And then you compare it with a really really simple setup like, say, [3 bodies acting under gravity](https://en.wikipedia.org/wiki/Three-body_problem). You know, something almost as simple as it gets.
Way way way simpler than the metabolic pathways in humanity.
And we know from a purely mathematical point of view.... that except for a very very tiny set of special cases, we haven't clue what will happen with the 3 body problem.
So yes, the article is spot on.
In terms of individual chemical reactions, we have some ideas.
In terms of dietary advice to individuals or populations... We floundering and should admit it.
Far Better would be to compare Maker vs Researcher.
How "Production Ready" is the result of both activities is the interesting question. How well covered with tests? How maintainable? How re-usable in broader contexts? How readable and understandable?
I used to live on the margins of the Physics community and blamed myself for being a really really Bad Researcher for having no patience with the Physics papers I read.
Then one day I had an epiphany.
If I were to look at the physics journals the same way as I look documentation for software or hardware.... I would be really really Angry.
The average research paper is extraordinarily badly written and unreadable. They have adopted as best practices, styles and habits, that you'd never forgive in a datasheet.
If you picked up a datasheet written like a physics paper....
You'd throw it against the wall and spec a different part from a semi-decent manufacturer.
(Hint: Datasheets are notorious for being terse and indigestible and badly written.)
If you are not from a first world university with a first world library at hand with paid for subscriptions to the premium journals and a fat budget to cover pagefees... Scholarship be damned. It's a rort. It's a racket supporting a closed shop guild.
It's not Good Manners except in the sense of Manners defining a "Gentlemens Club".