I thought about this article a lot since it was published. I might be going off the tangent a bit here but it might be relevant here
I do think it is possible to make create a company with properties mentioned in dhh's article that have novel technical challenges. I used to think that only consumer startups can have it because only there you get users and traffic. ITA software and Akamai comes to mind. In fact, scaling a consumer product is fairly common knowledge (every app except Whatsapp and Facebook is sharding databases, adding a cache line to it and going through roughly the same steps).
If you can make a good product for businesses that requires solving a problem only made soluble with recent technology advances (for example, multicores, reduced latency gap of RAM and flash storage), then you never need to worry about monetisations strategies, VCs, exits and other things. Maybe you need but it will be like dessert after dinner rather than salt in Indian food.
Oh wow. That's beautifully done. Simple comments that explain clearly what the code is doing, pretty clear choice of variable names so little head-scratching going on.
The documentation of redis is really good for a large open source project. I am not a contributor, but still read the source code from time to time. Full credit to antirez for taking the time to make it easy to contribute to redis!
I have some C programming experience and I wanted to learn C++ so I bought and started reading Stoustrop's book, thinking it's the K&R of C++.
It's the worst programming book I have ever read! It's introduction made me hate C++ and if I didn't had to work with other C++ libraries, I would have avoided C++. The text is full of bloat, for the lack of better word. It's the opposite of crisp writing.
I read some good language books like K&R's C, Joe Armstrong's Erlang book. I loved them and I thought this would be in same league. It's not.
I would like to learn C++ systematically, like not cut-and-paste stuff. "How to think like a computer scientist: C++" seems like a good book. I read the book "How to think like a computer scientist", which is an introduction to programming in Python. I think that would be a good start. Is it a good book for experienced programmers wanting to learn C++?
To people wanting to learn C++, please avoid Stoustrop's book like Plague.
I find Stoustrop's writing quite the opposite, concise, informative and a touch entertaining at moments. But I can understand why you might see it otherwise, to each his own.
You may find his book "Principles and Practice Using C++" [1]
more accessible.
As someone who knows a number of programming languages more or less fluently, I found that book to be invaluable when I started working in C++ professionally. It's not a book to teach you programming or any of the General concepts of OOP, FP, or the like. It is, however, a great resource for learning C++ assuming you know the high level concepts already.
While it's rather introductory, "A Tour of C++" is a much more concise book. Read that and then maybe look at some Scott Meyers books (I haven't read "Effective Modern C++" but the other entries in the series are good and I'd expect this to be a good place to start after the tour book).
K&R is a "first book" and important historically, but right now it's an atrocious book if you want to learn current C and this has been the case for a long, long time.
Sometimes these first books don't withstand the test of time.
That's not entirely fair - it's not just about being first.
K&R may be archaic now, even obsolete. However, for decades it has was held up as a an example of what a good technical/language book could be. You don't have to agree with the assessment to agree with the fact - that this was touted as a very good technical book for various reasons.
There never was a "K&R" of C++. That's not unusual, many languages are in the same boat. If you want to go back to the "firsts" it would be a combination of The C++ Primer and Strousoup, putting them together gave you something that was both more and less that K&R was for C.
I first studied the K&R in the early 90s, and it was already terrible by then. Especially if you wanted to teach anything other than quirky systems programming.
From the software engineering point of view, almost every single code example is terrible. Abundant implicit casts depending on the OS, loops that leak buffered reading between iterations, etc etc.
Just no. Never, ever recommend K&R to anybody as a general programming book neither for C or in general. Only the intro descriptions of language characteristics and important functions of the standard library are any use, and then again even these are extremely obsolete now.
Sure, it was a snapshot in time. By the nineties it was already old. I'm not defending it at all as book to learn C from.
There is, however (like or not), a reason we even now say "X is the K&R of Y". As such it is a bit silly to claim that the only reason K&R succeeded as well as it did was by being early....
There's not a whole lot that's changed in C11, (C is kind of "done" at this point) and there's not been a newer book that teaches the language so well.
That's his reference book. It's not designed for systematic learning. It's designed as a reference, as in "cut-and-paste stuff". You want one of his other books, meant to take you from zero to literate in not just C++11 but programming in general: https://www.amazon.com/Programming-Principles-Practice-Using...
Bjarne's text is just that, a text, not a read. It should be referred to as a reference. I completely agree with all your accounts because I did EXACTLY what you did a few years ago. I'm still working through the book, but I kinda said "eph it" and enrolled in a solid course. Worth the G I spent? absolutely. THat said, the 'effective' and 'Exceptional' books are well written.
Would you please define which of his books you read? Just saying "Stoustrop's book" doesn't really help anybody.
He wrote a few books, as you can see here: http://www.stroustrup.com/books.html
I had some doubts myself before buying my first e-ink based device. It helped a lot to watch movies on y-t where guys were test driving them.
Not all e-ink displays are of equal quality. The newer ones should be ok, those claiming 16 levels of grey. However the definitive test should be made by your very own eyes.
e-ink displays look to your eyes basically like paper. I absolutely love my Kindle for reading books.
For papers though, not so much. The screen is too small for a layout format like PDF to work. The document has to be able to reflow for the screen like a proper e-book to work really well, and PDFs don't. I've heard the Kindle DX was great but those haven't been made in a while, otherwise there's a few big ones Sony made which are apparently awesome but expensive.
I clicked on this expecting some technical stuff and all I got was this BS social/community whining.
Well, even in the worst case where FreeBSD community is trash, they have one of the best kernel implementations and one of the best open source OS documentation.
I agree, it was a disappointing article. Even the technical section about source control at the beginning seems a bit odd. First they note how huge the codebase is, then move on to compare the project to Django and Python?
Let's remember that FreeBSD is an entire OS, not just a kernel. If you want to compare it to the linux world you have to imagine the kernel + the GNU userland + the distro specific utilities and package management of something like debian or red hat.
It's not really surprising that the codebase ends up being huge and that you can't just change the architecture and tooling around it to use the trending software stack of the day.
On the other hand the fact that FreeBSD is so comprehensive is the killer feature for me when compared to something like Linux. It's a full OS, with everything (usually) playing nice with each other, a single documentation for the entire base system etc...
I also find that the kernel code is generally a little nicer than linux's, although linux is more featureful overall.
Yes, FreeBSD is slower moving than Linux and generally more conservative. That's not a bug, that's a feature.
The whole idea of this talk was about the community side of the project. I make exactly the points you're making regarding code size but that just speaks to the difficulty of managing a community looking after a codebase of that size.
I'm also not criticizing the pace of FreeBSD development so much as I'm criticizing the pace of its leadership (of which I'm a member, don't forget) to deal with issues that would make FreeBSD more fun to work on.
Thank you for taking the time to reply. It was just a bit of a surprising read from my point of view, as somebody who's not directly involved in the project (like you are) but who's been observing it since around ~2004.
There are three main points in this article: the issue of version control, the "Dragonfly BSD incident", and the GamerGate garbage fire.
Regarding the first issue, while it was sad to see a good dev like Matthew Dillon leave the project, what do you think should have been done better by the leaders of the project? Clearly there was an incompatibility here, maybe having Dillon work on his own project (and then sometimes have a back and forth between Dragonfly and FreeBSD) was the right solution? Would Linux for instance have dealt with the issue better? I recall many personality clashes amongst the Linux "elite", some not so long ago.
The migration away from CVS sure did take a long time, but as you mention yourself the technical challenge was pretty high. Lest we forget, Linus ended up writing his own version control system because the existing solution were not deemed satisfying. And FreeBSD is significantly bigger than linux's codebase. Regarding the test suite, testing operating systems is notoriously difficult (you can't easily abstract away from the hardware to run well contained unit tests). I don't recall Linux having an extensive test suite either.
The GamerGate thing I won't touch with a hundred kilometer pole. How an operating system project got dragged into that I still can't fathom.
So in the end, I don't think those issues are that big of a deal on their own. IMHO the main "trouble" with FreeBSD is simply that its market share is tiny compared to Linux. I'm a big fan of FreeBSD but my IRL job is linux kernel dev, not FreeBSD kernel dev. More and more first party vendors support linux, not any of the *BSDs. "Netcraft confirms it - BSD is dying". There's a momentum problem and I'm not sure switching to github or adding a test suite are going to solve it.
FreeBSD is betamax, linux is VHS. FreeBSD is mercurial, linux is git.
The only thing that could've been done better was realizing that there wasn't a way to fix it earlier. The story was more told as to give an idea of the kinds of things a community can face.
The migration to Subversion was given as a case where core could've made a decision and given direction but chose not to. Whether they're right or not is a whole separate set of arguments.
I think everyone would be happier if Gamergate had never been a thing.
The trouble with FreeBSD, as stated, is that like a whole lot of other community projects it's largely volunteer and its leadership is 100% volunteer. If we had more mindshare we might have more volunteers but then we'd need leadership to be more active.
FreeBSD is pretty common in some market segments, especially infrastructure appliances and devices. It's an easy choice for NAS controllers, internet core routers, email gateways, firewalls, messaging platforms, CDNs. Not to forget the humongous chunk of FreeBSD that is in OSX.
If you think it has a small market share, you're looking at the wrong market.
While I agree it is popular in certain circles that use it in high volume, it clearly has a relatively small mindshare among developers and open source contributions. Linux, just the kernel, regularly gets contributions from 100x the people that contribute to FreeBSD base.
I'm gonna have to challenge you on that 100x number because I think you may have plucked it from thin air. Obviously contributor numbers are a) hard to define and b) hard to capture, but for an order-of-magnitude estimation, I give you two sources, both of which have incentive and access to maximise the number counted:
So Linux has more like 13x individual developer count in recent times. You can round that down to 10x if you like, but 6x doesn't tell the recent story.
Note that this is comparing the Linux kernel to FreeBSD base, which is like kernel + glibc + coreutils + binutils + other stuff.
Same, I do my best to stay away from politics but even a damn BSD story ends up with politics. It's not so much complaint to author but just a grim realization...
I also think there is some corporate backing in C++ compilers. Like a few internal company people are getting paid to fix this kind of stuff.
Regardless, it's great to see C++ compilers incorporating latest standard features. For comparison, check JavaScript standards implementation in browsers (not sure if it's a fair comparison).
It is a very fair comparison actually, with similar compatibility pains in the past due to both differing interpretation of the standard and plain non-compliance. Things are getting much better lately.
I remember watching a 90 minute documentary on Chernobyl on television around 2010. It was mentioned that the construction of sarcophagus was 10 year behind schedule.
Glad to see the work done though the world paid a huge, huge price for it.
I do think it is possible to make create a company with properties mentioned in dhh's article that have novel technical challenges. I used to think that only consumer startups can have it because only there you get users and traffic. ITA software and Akamai comes to mind. In fact, scaling a consumer product is fairly common knowledge (every app except Whatsapp and Facebook is sharding databases, adding a cache line to it and going through roughly the same steps).
If you can make a good product for businesses that requires solving a problem only made soluble with recent technology advances (for example, multicores, reduced latency gap of RAM and flash storage), then you never need to worry about monetisations strategies, VCs, exits and other things. Maybe you need but it will be like dessert after dinner rather than salt in Indian food.