I recently chose to go with Juce on a project. Seeing this keynote convinced me I made the right choice - it's nice to see an individual so focused and caring about the aesthetics of their coding.
Thanks for the talk, really enjoyed it. You even managed to make me share in your frustration of the remaining state machine and exception! A fascinating insight of a start to end refactor, I bet it was really rewarding!
I have a suggestion. As another comparison of the two different versions, why not introduce the same, simple bug in both, then give the C and C++ versions to your students, and measure how long it takes them to fix the bug? Sort of a objective, scientific, maintainability experiment.
I would suggest to anyone watching this video to take a look at Robert C. Martin, Martin Fowler, Kent Beck and Michael C. Feathers books about xp, TDD, SOLID, refactoring, Continuous Integration etc those are all intricated subjects that helps when working with legacy code (by legacy code I mean code not under unit test)
Well, this is interesting, but is not a fair comparison, because the result is not the same scope. The resulting code will compile on many less platforms than the original one, since it doesn't care about supporting them. It also throws away features that the presenter does not feel important, because he doesn't need them. So, indeed, given it supports less platforms and less features, the new code can be shorter, vastly shorter and simplified.
Seems like a lot of your changes will impact performance, or change behavior of the code. Why not just make a wrapper as intended? This leaves the C version more able to compile on smaller systems.. and you get the benefit of bug fixes to the original. Using this rewrite means you will be the sole maintainer, until it gets widely adopted. Things like crc/adler are used in more than just zip.. they are used in png decoding as well.. so any changes to that implementation affects lots of things downstream. When you claim that adding a couple microseconds to startup, in order to get rid of a table in the code, is justified, it kindof sounds like you aren't seeing the bigger picture. I used to think along these lines.. that modernization was worth it for its own sake.. and that shortening code at the expense of performance, is a worthy endeavor. The zip header files aren't designed to be included in multiple points in your project.. they should mostly be included in one place, in your wrapper interface, where you make prettier functions and make an interface that conforms to your local architecture. When used this way, a lot of your worries about name conflicts and macros, etc, go away. One of the most appealing things about a library like zlib is that its been debugged already.
+Michael Schlachter Maybe it wasn't clear, but this talk was done as entertainment, and to illustrate some points about refactoring.. The intention is not to launch a project to replace zlib! And JUCE has already provided a wrapper around zlib for many years anyway. This is just about how its internal implementation could be done better. However, it's a mistake to assume that this kind of thing would impact performance - I deliberately did benchmarks because I expected this kind of comment, and even without spending effort optimising it, there was no slowdown compared to the C version. As for small systems.. well anything that has a modern C++ compiler would handle this just fine. And actually, in re-factoring it, I managed to remove at least one layer of unnecessary buffering, so it'd have a smaller memory footprint.
I guess if you enjoy paying off technical debt for a living, it's all good. Who doesn't like fixing bugs, and checking security advisories? Dropping in a new .lib or .dll is for suckers. www.google.com/search?q=zlib+security+advisory
I recently chose to go with Juce on a project. Seeing this keynote convinced me I made the right choice - it's nice to see an individual so focused and caring about the aesthetics of their coding.
Mate, what other choices were there then ? There’s like none now, 7 years later
Thanks for the talk, really enjoyed it. You even managed to make me share in your frustration of the remaining state machine and exception! A fascinating insight of a start to end refactor, I bet it was really rewarding!
Great talk! Love the insight into the nerdery.
Great video! Very inspiring!
I have a suggestion. As another comparison of the two different versions, why not introduce the same, simple bug in both, then give the C and C++ versions to your students,
and measure how long it takes them to fix the bug? Sort of a objective, scientific, maintainability experiment.
I just took a look at the JUCE source, I realized that aliens look a lot like us and have a British accent.
I would suggest to anyone watching this video to take a look at Robert C. Martin, Martin Fowler, Kent Beck and Michael C. Feathers books about xp, TDD, SOLID, refactoring, Continuous Integration etc those are all intricated subjects that helps when working with legacy code (by legacy code I mean code not under unit test)
Where can i find/download your rewritten code?
Well, this is interesting, but is not a fair comparison, because the result is not the same scope.
The resulting code will compile on many less platforms than the original one, since it doesn't care about supporting them.
It also throws away features that the presenter does not feel important, because he doesn't need them.
So, indeed, given it supports less platforms and less features, the new code can be shorter, vastly shorter and simplified.
See also the work I did on Sortix libz.
Seems like a lot of your changes will impact performance, or change behavior of the code. Why not just make a wrapper as intended?
This leaves the C version more able to compile on smaller systems.. and you get the benefit of bug fixes to the original. Using this rewrite means you will be the sole maintainer, until it gets widely adopted.
Things like crc/adler are used in more than just zip.. they are used in png decoding as well.. so any changes to that implementation affects lots of things downstream.
When you claim that adding a couple microseconds to startup, in order to get rid of a table in the code, is justified, it kindof sounds like you aren't seeing the bigger picture.
I used to think along these lines.. that modernization was worth it for its own sake.. and that shortening code at the expense of performance, is a worthy endeavor.
The zip header files aren't designed to be included in multiple points in your project.. they should mostly be included in one place, in your wrapper interface, where you make prettier functions and make an interface that conforms to your local architecture. When used this way, a lot of your worries about name conflicts and macros, etc, go away.
One of the most appealing things about a library like zlib is that its been debugged already.
+Michael Schlachter
Maybe it wasn't clear, but this talk was done as entertainment, and to illustrate some points about refactoring.. The intention is not to launch a project to replace zlib!
And JUCE has already provided a wrapper around zlib for many years anyway. This is just about how its internal implementation could be done better.
However, it's a mistake to assume that this kind of thing would impact performance - I deliberately did benchmarks because I expected this kind of comment, and even without spending effort optimising it, there was no slowdown compared to the C version.
As for small systems.. well anything that has a modern C++ compiler would handle this just fine. And actually, in re-factoring it, I managed to remove at least one layer of unnecessary buffering, so it'd have a smaller memory footprint.
I guess if you enjoy paying off technical debt for a living, it's all good. Who doesn't like fixing bugs, and checking security advisories?
Dropping in a new .lib or .dll is for suckers.
www.google.com/search?q=zlib+security+advisory