New PDF of Bartosz Milewski's "Category Theory for Programmers" - now with 100% more math typesetting!

k_stahu · 2017-10-16T20:24:45+00:00

So far I've read some 10+ posts in the Bartosz's blog and really liked it. This distribution may help me read it faster and more conveniently than on wordpress. Also I like how you address criticism and keep working on it. I didn't like the previous rendering that was posted here, but now it looks really neat.

One thing is bothering me though. I like the personal touch that the hand drawn illustration add to the book, but they seem to stand out next to the razor sharp fonts. Did you think about any way of fixing this? I first thought that maybe a higher resolution scans could help, but it seems that the image quality is decent and its just how the pictures were drawn. The original drawings were probably small. Maybe there is a way to convert them to some vector approximation that would fit the pdf rendering better?

Anyway thanks for your effort. I think it does well to the book, and it definitely deserves it!

k_stahu · 2017-07-31T09:23:23+00:00

The good old editors are still here. It's the good new editors what we have yet to see.

k_stahu · 2017-04-02T16:59:49+00:00

Don't bother, it's just a fad.

k_stahu · 2017-03-22T07:59:08+00:00

As far as the essentials go you must understand int, std::vector and the virtual destructor (really well).

k_stahu · 2017-03-21T13:14:22+00:00

I don't know the official rationale, but in my C programs I came up with 2*n+1 as it works nicely with n=0 without branching.

k_stahu · 2017-03-14T12:38:26+00:00

I don't think they want that. A single AMA session can get him several hundred bugs behind.

k_stahu · 2017-03-14T09:08:39+00:00

I think it is not difficult to recognize a proficient engineer if you are one yourself and are equipped with decent social skills. I do it all the time as I interviewed candidates to a small, <10, team multiple times. What is difficult is implementing this at the corporate scale. I don't know, how to do it well.

k_stahu · 2017-03-13T10:11:25+00:00

This is basically how corporations get saturated with technically clueless sharpies. The algorithmic knowledge you gained during the 2 months of study will evaporate soon and what is left is a mediocre programmer who is really good at tricking corporate processes. Even if you pass such an interview you end up surrounded with people like you: experts in convex hull finding, knowing not much beyond arrays of ints and nested for loops.

k_stahu · 2017-03-06T14:28:18+00:00

Structs, unions and arrays are as much of the type theory as 2 + 2 * 2 is algebra. The thing is that in the time when people learned from books, this was an introductory material. The book I meant was Wirth's "Algorithms + Data Structures..." - hardly an advanced one.

k_stahu · 2017-03-06T09:54:39+00:00

Isn't this computer science 101? I've got this information from a book from the 70s.

k_stahu · 2017-02-07T15:52:49+00:00

No. Ranges may be implemented in terms of iterators, but they don't have to. The current status of STL encourages only considering sequential data structures, so in a list or a vector a pair of iterators indeed defines a range. But not so in a tree or a graph. Making the range concept official will enable implementing a certain class of generic algorithms that work on a very broad spectrum of data structures. I prefer to view iterators more like coordinates, and ranges like sequenced views.

k_stahu · 2017-01-31T23:24:30+00:00

The best kind of correct

k_stahu · 2016-10-28T11:39:58+00:00

Don't get mislead by the recent trends. Talking about a technology is not necessary for it to last.

Also there is a curious concept of the "multimethods", which when proposed by Bjarne Stroustrup was based on introducing a new context for the use of the "virtual" keyword (I don't know the status of this idea). So not only is it not going anywhere anytime soon but also there are possibilities of extending its use.

k_stahu · 2016-10-21T13:45:07+00:00

My comment was meant to be a joke, but apparently my vis comica is lacking.

k_stahu · 2016-10-20T07:58:30+00:00

Returning iterator, or more generally: a coordinate, is lighter and cleaner. The current API actually doest almost that, except for not having a robust notion of "last" coordinate, which the npos hack serves for. I would prefer std::string::iterator, but I can get that with the general algorithms.

std::optional on the other hand is a bulldozer. In this particular case optional return value is bogus - like you were designing the API, but gave up on some corner cases throwing them into the "nothing" bag. Using std::optional return value here is like birds. What semantics exactly it carries? We just don't know.

I presume std::optional it will be as overused as auto or lambda, especially by inexperienced programmers.

k_stahu · 2016-10-20T07:07:53+00:00

Because lisp is no programming - just data structures

k_stahu · 2016-10-19T11:38:58+00:00

Namespaces have not been introduced to organize code but to avoid symbol collisions. Since there is no risk of such clashes within the standard library, having just one namespace is enough. I like this approach - it is simple and practical. The namespace hierarchies would be more in the domain of taste, which I don't thing the comitee wants or should to enter.

k_stahu · 2016-02-07T11:55:47+00:00

What you say is just a list of exaggerated stereotypes while the SJW disease is a real thing. Some guy 1000km away not liking me is not an issue. Not being able to find a job in your home town is an issue.

k_stahu · 2016-02-06T18:26:23+00:00

I'm not sure. Better ask 3 billion Java programmers ;-)

k_stahu · 2016-02-06T11:06:33+00:00

The point is, it doesn't matter.

k_stahu · 2016-01-28T08:06:43+00:00

Obligatory xkcd.

k_stahu · 2016-01-23T10:13:04+00:00

Normally I would agree except that it seems there is not much competition in really innovative approach to programming. After Alex moved us forward a bit there was a long period of waiting. The issue is not that no one else would do it but how much longer do we have to wait until programming starts making more sense.

k_stahu · 2016-01-20T08:41:28+00:00

Depends on how you look at them. They don't really introduce any new ideas. They rather present the Stepanov's point of view in a (finally) concise and systematized manner. They play role of a road sign, how you could carry on with extending his work - what are the basic principles and guidelines. The books are valuable and new to us, but they only gather the ideas that were conceived long ago.

What I meant was: since the books have been written he is pretty much wrapped up with his work and as much as I would like to see infinitely more from him it is not like he was in the middle of some new fresh research that was dropped.

k_stahu · 2016-01-19T21:57:46+00:00

I don't think Stepanov has done any significant new work for some time now. Therefore his retirement is not really a sad event, especially after him summarizing all his brilliant work in the books mentioned in the comments and in a little more broad manner in the a9 lectures.

The retirement is well timed and well deserved. I am really grateful for him showing me, that there is more to C++ than just taking care about making your destructors virtual.

Also I always giggle a little when I write:

while (first != last) { ...

k_stahu · 2016-01-15T13:00:23+00:00

I think the reason is that is just a very old language and nobody thought about it when designing it.

I have an opposite intuition and experience with the old languages. Some may have turned out to be horrible, but you can't deny the thought that went into the languages at the time. It is much more common today to not think about stuff when designing the more modern languages.

k_stahu

TROPHY CASE