fish2000

Vice has it: https://news.vice.com/en_us/article/qvx3wp/active-shooter-re...

tl;dr this article has no Native American weaponry review nor far-Eastern bear-hate listicles, meh

I know you were probably just throwing out the “90%” statistic, but if you take that as a given, the implication that 10% of the libstdc++ bugs on file are legit is a worrisome notion in and of its own right. I don’t want to be responsible for triaging those bugs (and nor do you, I am guessing; this being why the reports are valueless) but the fact that this is the bug rate in this, a gold-standard library in common, ubiquitous use… well as far as I can see, this is the context in which that the OP’s article should be considered.

… I build all of my C++ projects with Clang and link them against libc++, so I don’t know if I am dodging a very high-caliber bullet (so to speak) or if the other shoe will drop at some point, and I will find myself going down the OP’s rabbit-hole of library-bug investigation.

Do not use magic. — Strongly agree.

Do not use macros. — Absolutely I agree: I involuntarily grimace whenever I look at and/or things like Boost MPL, or the wartier corners of the Python C-API’s underbelly, etc. I only use macros as straight-up batched ⌘-C-⌘-V:

    #define DECLARE_IT(type, value) extern const type{ value }
    DECLARE_IT(int, 0);
    DECLARE_IT(int, 1);
    DECLARE_IT(float, 0.0f); // etc
    #undef DECLARE_IT

Do not use typedefs to hide pointers […] — I cannot stand it when people do this. That asterisk is as syntactically valuable to you, the programmer, as it is essential to your program’s function. If the standard library can slap asterisks on file and directory handles than so can you (and by “you” I specifically include whoever wrote the `gzip` API among other things).

[…] or to avoid writing “struct” — Huh, actually I feel the opposite, I think all those “struct” identifiers are clutterific, much like excessive “typename” id’s in C++ template declarations. But so aside from the points where I totally disagree with the author, I absolutely feel the same way 100%.

Separation of concerns, fungibility, limited exposure, a lower bar on future legal entanglements … I could go on

I haven’t got a ton of experience in this arena, but what I have done in the past is: 1) incorporate the larger venture as an LLC (“My Company, LLC”); 2) incorporate the specific project as a C-Corp (“My Company’s App, Inc.”) – my partners and I own the LLC, which controls the C-Corp, which holds the assets of the project.

Specifically, this makes it easier if we want to sell ”My Company’s App“ to a Facebook- or Google-class buyer entity. The LLC can also incorporate a bank, if ”My Company’s App“ needs to start conducting transactions that necessitate the use of (say) a Federal Reserve client (á la Venmo or Stripe).

The hazy miasma visions of a perfect past can legitimatize themselves, in some, with far far less than 10 to 20 years. Some can do it in a span of weeks – q.v. “Where I Was From,” the memoir by Joan Didion (which specifically is about California, but is quite relevant to these topics to anyone most anywhere in the USA).

Yes, there is a Zen state of C++ programming wherein you, the programmer, surrender to the wisdom of the compiler, and in doing so are liberated from caring about the minutiae of the type system, to be carried forth, skyward, on the twin winds of inference and overload resolution. I do enjoy that. RTTI is nothing like this – it’s a red herring, neither elegant nor powerful… at best it’s a misnomer (it’s more like RTT total lack of I, amirite) and at worst a distraction.

I dislike exceptions too, but in a difference-of-opinion way where I can be like “OK, that otherwise legible and reasonable code uses exceptions, unlike mine” and it doesn’t make me grimace like I involuntarily do for RTTI… I’d love to be mistaken tho, anyone with an inspiring counterexample, do share.

Good start but -- some C++ stuff is wrong, e.g. in the bit on friend functions, a member function prototype is written with an empty block instead of a terminal ";". Subtle, but you know. Also, more subjectively, std::string is described as immutable, but with no further discussion about what that means or how that might work.

Just sayin. Frankly I like how it's not Wikipedianishly drowning in citations and/or demands for same -- but how does it get updated? I immediately tried to expand on those two issues I mentioned but there was no sort of UX recourse for my pedantic urges (FWIW)

Wow this takes me back – 2007, those were the days. Back before so many flagship projects had frankensteined libLLVM into their innards; before every single JavaScript framework was required by law to include at least one CLT whose executable name ended in 'c'; back when GCC on Apple was just a matter of /usr/bin, and not a parade of endless Homebrew formulae PRs… srsly dogg this is an excellent article, a product of its time but a bonafide bulwark, presciently on the precipice of paradigm. I +1'ed.

… also one of the forthcoming Clang projects is a static-analysis tool (á la `clang-format`) for replacing any `auto` decls with the actual typename, so you can write lazy code without appearing unscrupulous at code reviews

These are good rules – as in liquor advertisements, it’s advisable to always accompany a declaration that uses `auto` with a rejoinder in the comments to Please Enjoy Responsibly

“A Variadic Template A Day Keeps The Job Security In Play”

OP I believe you meant to say “q.v.” instead of “e.g.”

I am really into C++ but it has the same problem that Perl has – it does not try to stop anyone from using it to express themselves in an ugly or inscrutable fashion – and this is a frustrating aspect of dealing with the C++ ecosystem/community.

Personally I spent enough time writing Python to acquire significant coding OCD about things like whitespace, file/directory layout, documentation. When I write C++ I have two prime directives: 1, keep it compulsively tight and legible; 2, use the idioms of C++ to sort out other peoples’ APIs (as opposed to reinventing wheels). I stick to these rules like they’re a diet, it is easy to let your mind wander and find that you’ve spent half the day writing a framework instead of solving your problem; metaphorically this is the equivalent of forgetting to go to the gym and then ordering pizza for dinner. Along these lines I give myself one premature optimization a week, like as a cheat.

I find it is most productive when you are using C++ “against” something. For example I just wrote a bunch of templates that eliminate like 90% of the requisite API boilerplate the Python C API calls for – that was simultaneously satisfying in both the “I totally solved that specific problem” and “dogg check out this clever snippet I wrote” senses of ‘satisfying’. Contrastingly, the last time I created a class hierarchy it was a sprawling regrettable mess – I am more “structure-oriented”, versus “object-oriented”, but still.

q.v. another blog by a fantastic marketer-who-codes, Cody Boyte: https://medium.com/@codyboyte

Naturally, this articles’ photo of the mud-slaked Rubenesque woman was the image on my screen when my new co-worker dropped in on me… calling this piece NSFW feels a bit prudish but let my experience be your warning

q.v. The Manifesto of the Futurist Programmers, 1991 (linked) – based on the Futurist Manifesto, signatories include one Milanese painter, and 5 noteworthy denizens of Silicon Valley…

In the interest of not spoiling I leave it as an exercise to the reader to click through and scroll down

This is indeed a great intro article.

For those interested in seeing examples of LLVM hacking in action, I would recommend reading the source for Halide – https://github.com/halide/Halide – which is an image-processing DSL implemented in C++ and piggybacking on LLVM. I myself learned a lot about LLVM this way.

    holler ("Preposterous fd value %d", fd);

(I just had to debug a descriptor mess and this style of freewheeling 90’s-style documentation rejuvenated me w/r/t all of that, hah)

By “goads” do you mean “gods” (in, like, the Battlestar Galactica sense) or is that supposed to be “gonads”, as in junk? Just askin.

This is pretty awesome – I’m writing a Python extension in C++ that piggybacks on top of NumPy dtype codes, and I thought that I could “just” use templates to deal with dynamic typing. It proved to be waaaay less straightforward than that, and I had to hack through a lot of stuff with cumbersome macros, and wound up with a gigantic binary image as a result. Actually doing type erasure in C++ (which type erasure, as I understand, is like de rigueur in Java) cuts through all of that cruft… and so, to the refactormobile! Yes.

Python's API structure may be fast and loose, but that is a feature, I think. Its type system may have some threadbare implementation spots – the _sre example from the standard library, for instance – but there are some compelling examples as well.

I, for one, have been working on an app implemented mostly with PyObjC, the bridge between Python and Objective-C. I had all but written off PyObjC as a bizarre yet unuseful language mule... but lately I had the occasion to read through the PyObjC source code base, in service of my project. Did you know that when you subclass a wrapped Objective-C type in Python, an all-new Objective-C class is created and wrapped as the descendant class, behind the scenes? That blew my mind.

That happens transparently, in concordance with Python's type heiarchy and runtime ABI. As it turns out, PyObjC predates Mac OS X, and the authors have put a lot of work into mitigating things like the GIL and system events.

I am also a fan of Django's field type system, as the author mentioned – and I am curious about what he thinks about descriptors (which he mentioned one but did not address) – I think descriptors are an amazing addition to the duck-typing regime in Pythonville.

Plenty – as I recall, the Glock was invented (in the garage, no less) by a guy whose passion for shooting things was on par with the iron-fisted cleverness of Woz and Jobs.

Things are pretty hackable, in a very different way from computers. It is amazing how far hobbyists can take their passion for the various technologies and physics – few of which ever have any need for electricity, and many of which evolved from the more gruesome acts in the annals of human history.

But like – you know how you can get rid of KDE and go Gnome? Similarly, you can also get a milled lower receiver for your AK-47 (exotic, as it was designed from stamped metal components), and if you do it right you can still use your favorite wooden furniture.

To extend the metaphor•, that's like being able to reuse all of your conf files and compiled binaries on a new processor architecture based on a different distro – as long as you're extra careful about `rm -rf` and you understand that mishandling powerful tools will kill you and your friends.

I don't have any interest in killing people, but I find guns fascinating in the same geeky way that compels me to like having opinions about various other dramatically complex systems whose histories are steeped in the bizarre slow-brewed lore that forms around the sort of stories geeks occasionally offhandedly tell in their few and far-between hours of not being furvorous (like e.g. when github is down).

• - quite beyond its utility, I am afraid, my apologies

> corrupt spacetime

Like (say) a vacuum metastability event?

http://en.wikipedia.org/wiki/False_vacuum#Vacuum_metastabili...

Funny that – I often imagine that a nicely productive compromise would be a scheme like the SCDP office on “Mad Men“: mostly private offices, but with a pseudo-open “Creative Lounge“ that facilitates collaboration but retains basic human stuff like doors, for some sense of sonic isolation.

That particular plan is far from perfect – they have often used the lack of isolation (e.g. people peeping on neighbors through ceiling-level windows) as a plot device – but I still like the actual looks of it, based on actual experience with the open-plan-induced drudgery discussed in the article.

These tools straddle some Venn circles, so the developer pitch can be confusing.

For example, I make use of both ipython and bpython, both of which I refer to as either shells or REPLs; though neither program is a proper shell (in the /bin/chsh sense), and though people also call them “interpreters” (technically, the python interpreter still interprets), “environments” (vague) or even “IDEs” (wat?) – the concept behind the tools is popular and well-understood.

Personally I think it’s particularly funny to call these Enhanced REPL Shell Interpreter Environments (or what have you) “IDEs” and lump them in with Eclipse or Visual Studio or those other behemoth coding tools; I like bpython and ipython for the myriad ways they are un-Eclipse-y, and if I did C# I would presumably get into CSharp for the same reasons. All of which, like many bicycle-shed innovations, are mere matters of taste.

I did not think a random-thing-generator could possibly make me laugh again, but for me `git-shoot-subtree` was the undeniable breaking point.

Yeah – what post?

q.v. JCL