sclangdon

What is a "better" solution? If a macro-programmed office document is doing its job, what constitutes "better"?

I particularly liked the part where he tells the engineer "you're not understanding me, I don't care why it doesn't work, I'm just telling you that it doesn't work. I'm a consumer and these are $300 earphones and they can't send a signal from my ears to my ass" [1]

Reminds me of so many people I've worked with who think it matters to consumers/users why something doesn't work. Like they can justify it, and it's not that big a deal.

1. https://youtu.be/36Gw3tErUSM?t=16m20s

If you're interested in Zork and functional programming, you might be interested in Eric Lippert's series about writing a Z-machine (a virtual machine used by Infocom for some of it's text adventure games, including Zork) in OCaml.

https://ericlippert.com/category/zmachine/

I believe some games companys use it. Naughty Dog of Uncharted and The Last of Us fame, being the most famous. I think they used it to create some game logic DSL or something of that sort.

More info here - https://www.reddit.com/r/Racket/comments/5g8xse/are_there_an...

As an aside, I always think it's such a shame that no one seems to mention Bresenham's updated, and quicker, run-length slice line algorithm.

http://www.phatcode.net/res/224/files/html/ch36/36-01.html

And here is the source, along with some other Farbrausch projects.

https://github.com/farbrausch/fr_public

To be fair, "More on DOTA 2" is completely meaningless out-of-context. The article could literally be about anything (in the DOTA 2 universe).

So whilst the new edited title is a bit click-baity, it is nevertheless more meaninful than the original.

It's interesting that you think CMake is a "dumpster fire". Consider that CMake isn't the only build tool, but has, without question, risen to the top as the premier build tool for C++.

Why do you think that is? No doubt you'll say it's because the other options are worse, but I'll just say that I like CMake. I miss CMake when I use other languages and I can set up a complicated project with CMake quicker and easier than I can with other tools.

As always, it's what you know.

It makes me smile when someone starts off a complaint with something similar to "I've been programing in C++ for x decades. I have y qualifications that should impress you. I worked at z company which should impress you further. Yet, despite this, I cannot write safe C++ code".

The author's post, in particular, is excellent as it follows this token introduction with "I don't know anyone else who can write safe C++ code, either". This is further strengthened by "people I know to be skilled programmers (based on what, I don't know), have never professed that they can write safe C++ code, and therefore people who do, are obviously suffering from some psychological effect".

I mean, really? You can't do it, and your friends can't do it, so no one can do it? Even though there is a world of software out there that does exactly what you say can't be done? And further, anyone who says they can do it must be less-skilled and suffering for a form of illusory superiority complex? Get over yourself.

How ironic that he knows about the Dunning-Kruger effect, but fails to apply it to himself.

Also remember that id Software wrote an engine specific to the game they were creating (it's debatable whether you can call them engines at all, really). Things are a lot more streamlined if you take this approach because you rarely, if ever, have to answer the question "would this work for some other title?". Or worse, "would this work for any future title that may not even be in the same genre?"!

That, I think, is the mistake many game devs (who write their own engines) make. They make an engine for all possible games, then try to use it for their 2D match-3 puzzler, which uses about 5% of the code they've written, and even then they have to cludge some bits.

Isn't it just what you're used to? I recently (2 years ago) went the other way - from Windows to macOS - and I feel the same way as you but in reverse. I'll never buy another Mac, and I can't wait to get back on Windows, but I know it's not because macOS is inherently bad. It's because I have over 20 years of Windows knowledge and despite it's flaws, I know it well and I know nothing of macOS.

There's plenty of quality on Windows, and Windows itself is a very good OS. It's just what you know, and what you're used to.

Indedentally, in over 20 years I've never encountered a show stopping problem, or kafkaesque hoops I've had to jump through. Maybe our definitions are different...

If you think you don't have to comment your code, I don't think your understand the purpose of comments.

If you've been a developer for any length of time, I'm sure you will have encountered a situation where you've read some code, thought to yourself "wow, that's terrible, I'm going to change that". Then, several hours later, realised why it was done the way it was and actually, you can't really improve it after all. That is why we comment; to save the next person who enters the cave (and, if you're the kind of dev who spends several hours trying to understand something and doesn't retrospectively comment what you've found, then I'm afraid we can never be friends).

And please, don't assume the next person has the same knowledge of the system that you do.

That isn't a compramise, it's the goal. Your comments should be about the "why", and not the "how". We already know how, that's what code is - instructions about how something works.

What we don't know is why it was done in the first place, or why it was done a particular way, or why I shouldn't change that line that looks wrong but is really correct.

In my experience - working solely for large organisations for the last 17 years - the number crunchers are almost always swayed by "it'll be better in the long run".

It rarely ever is, of course, but don't underestimate the will of a developer to push an interesting project that they know in their hearts will not really benifit the company.

You seem to be under the impression that writing efficient code is at odds with writing reliable or robust code. Efficient does not mean unsafe. Efficient code does not have to shoot-from-the-hip. Efficiency means that the task is completed with the minimum wasted effort. To assume that you cannot have relieable code that is also efficient is absurd.

If reliability is the top priority for your project, it just means you factor that in to your optimizations. It doesn't mean you just ignore efficiency and write any old shit, as seems to be the custom today.

Your OpenSSL example seems to suggest the Heartbleed exploit was a result of developers daring to write performant code, and not that they simply wrote buggy or insecure code, performant or not.

When this article refers to the term "modern C++" it seems to be talking about Andrei Alexandrescu's now 16 year old notion of modern C++ [1], not the C++11 and newer notion [2].

[1] Addmittedly, Andrei's notion is still completely relevant today (and still, imo, the best C++ book available) but I don't think it's what most people think of when they hear the term "modern c++" these days. - https://en.wikipedia.org/wiki/Modern_C%2B%2B_Design

[2] https://github.com/isocpp/CppCoreGuidelines/blob/master/CppC...

The download isn't even remotely that big. If you are talking about the compiled size, you only need to build what you use (look up the --with-<library> and --without-<library> switchs).

You can also use the included bcp utility [1] to extract a subset of boost.

[1] http://www.boost.org/doc/libs/1_64_0/tools/bcp/doc/html/inde...

macOS comes with Apple's build of Clang, which has different versioning from "proper" Clang.

Selective, private-sector, paid-for schools in the UK are called Public Schools. I assume the quotes are because the schools are anything but public.

Actually, it tells the compiler that every time it comes across a class called string that isn't fully qualified, it should use std::string. And since he's put it in the global namespace, it will apply everywhere this header is visible.

He really shouldn't do that in a header, but if he at least moved it down a couple of lines so it's inside his private namespace, it at least wouldn't affect anyone else. There is no good reason to do it globally.

Insertion and deletion _were_ prime examples. It's not necessarily the case with today's hardware, especially until you reach some threshold of the number of elements (usually hundreds of thousands).

You say "the same operation just requires pointer changes (after finding where you want to insert or delete)" like it's some trivial thing that doesn't enter the equation. But finding where you want to insert or delete in a non-contiguous linked list is not a consideration that should be an afterthought in brackets.

Furthermore, when you have found the location, it's still not _just_ pointer changes. You actually have to allocate the memory for the node, too.

Traversing pointers and allocating memory is a lot slower than working with a contiguous block of memory (assuming you don't have to re-allocate the contiguous block of memory, of course).

Either way, don't take my word for it. If you're a C++ programmer, just benchmark std::vector against std::list, or watch this video - https://youtu.be/YQs6IC-vgmo

Perhaps not a perfect fit, but what I've done in the past, and found to work quite well, is to turn those big datasets you mention into an event stream.

You can do it quite trivially by simply raising an event on every line read, or you can add some kind of transform to the data beforehand, etc. Whatever you need. You can obviously take this further and turn it into a service or something, but that's up to you.

Here's a simple example in C# - https://ghostbin.com/paste/bzgez

Actually, it is the merit of the language. C - and FORTRAN for that matter - are fast because their restrictions force you to program a certain way. A way that just-so-happens to be efficient (if not particularly safe).

For example, generally, people use a lot of static arrays in C. Arrays are efficient. The way you program with fix-sized structures like arrays tends to be different to how you program with dynamically-sized structures and that style of programming tends to be more efficient.

In the vast majority of cases, a C or FORTRAN program will be more efficient than other languages not because they are C or FORTRAN, but because they force you to use an efficient paradigm.

Even other compiled languages like C++ or D are, more often than not, slower than the C counterpart UNLESS they are programmed in a "C style".

e: To be clear, the fact that they are compiled low-level languages obviously does help, but I'm trying to make the point that it's not the only reason.

If I remember correctly, the reason Facebook switched to Mercurial from Git was because they needed to make some changes or add additional functionality and Mercurial is an easier system to do that with, apparently.

STL does use hybrid sorting. It is usually implemented as an introsort, which begins with a quicksort and switches to heapsort based on the number of elements to be sorted.

Not familiar to me, no. I have a desktop for desktop-style use, and guess what, I don't have to worry about it being limited to 16GB of RAM because it doesn't have to consider size, power consumption, or anything else that a laptop has to consider.

On the other hand, I also have a 13" 2015 MBP[1]. It is only ever plugged in when it needs charging. I bought it specifically for it's size and battery life, because, as ludicrous as this might sound, I want my laptop to be as portable as possible. I don't _want_ it to be plugged in and I don't want to feel like I've been working out when I've been carrying it.

I know, this is crazy talk, but might I suggest that many of the people complaining are doing so simply because they bought the wrong tool for the job? It sounds to me like an awful lot of the complainers would have been better served by an actual desktop computer.

[1] I had never even used OSX before, and own no other Apple products, but I bought a MBP based entirely on battery life and size, because it was the best option out there.

Since when were simple solutions considered stupid? If filtering audio (which will probably only work the CPU, and thus the fan, more) is smarter than stopping a fan, I must be as dumb as bricks.

PBRT is big because it is written using literate programming and therefore includes (almost[1]) the entire source code for the ray tracer in print, which arguably makes it easier to follow than other books on the topic.

The PBRT ray tracer is also a production quality ray tracer and uses many advanced techniques you won't find hobby ray tracers, such as differential geometry, which naturally increases it's size.

[1] Some utility classes are left out.

Good job OP. I personally found Eric Lippert's 6-part series (and playable Silverlight demo) on the subject fascinating. I didn't notice it referenced in your design document, so here it is.

https://blogs.msdn.microsoft.com/ericlippert/tag/shadowcasti...

Although they generally didn't compete in the 4kb genre, Farbrausch open-sourced many of their demos and demo-making tools a few years ago [1].

fr-041: Debris [2], and kkrieger [3] (the 96kb FPS) are particularly worth checking out for the uninitiated.

[1] https://github.com/farbrausch/fr_public

[2] https://youtu.be/wqu_IpkOYBg

[3] https://youtu.be/2NBG-sKFaB0