Semantic compression (2014)
caseymuratori.com
Semantic compression (2014)
1–10 of 33 posts
Re: Semantic compression (2014)
#2Semantic compression is such a cool shorthand.
This article really helped me put things I had believed for years into words when I first read it. It's pretty amazing.
Re: Semantic compression (2014)
#3How's this different from just refactoring? Why the fancy name?
Re: Semantic compression (2014)
#4How's this different from just refactoring? Why the fancy name?
There is a short mention of “refactoring” and how it is a bad name, I’m not sure why, just read the article in 3mins.
TL;DR: start with the complex things, deduplicate code and use proper data structures once you have working code with multiple use cases.
Re: Semantic compression (2014)
#5A page-long strawman isn't a great way to start an article. I also disagree with the author's claim that refactoring is ridiculous or different, but like the author I'm not going to elaborate.
Re: Semantic compression (2014)
#6Jargon abstraction
Re: Semantic compression (2014)
#7TL;DR: DRY
Nice read, though. Very approachable.
Re: Semantic compression (2014)
#8I think semantic compression is achieved by using a denser more expressive language, some languages can express the same activity in far fewer lines of code.
Personally I find the denser code, harder to read, which I think also makes sense, since it contains more meaning in less space.
If you are writing code, perhaps in python, and you keep following your editors instructions to refactor it, you end up with far fewer repeated lines of code, and lots of small reused functions, you are actually doing manual code compression.
I have always wondered why, if editors are so smart, they don't have a 'compress this project' button, which does all that for you.
Re: Semantic compression (2014)
#9How's this different from just refactoring? Why the fancy name?
The only thing the word “refactoring” tells me is that you’re rearranging code without changing functionality. It doesn’t tell me why you’re doing it. You could be doing it for all sorts of reasons: to extract part of the code into a separate library, to route around dead code so it can be excised later, to enable a performance optimisation, or to allow a new feature.
What’s going on in this article is refactoring towards a very specific goal. That goal is reaching an architectural style that could also have been achieved earlier in the development process, and it’s that style that is, AIUI, the point of the article.
Re: Semantic compression (2014)
#10The introduction describes encountering awkwardness during modeling in OOP, which definitely does happen. But I’m not convinced that a payroll system written in C++ in the style described by the post is going to be a better solution.