3 ms·

I worry that this is the chaos of folks not understanding compiler theory. This is the result: every minifier is a compiler, but none of these minifiers boast p

I worry that this is the chaos of folks not understanding compiler theory. This is the result: every minifier is a compiler, but none of these minifiers boast properties like idempotence and none of them are sufficiently correct that they achieve their goal on the first try. I don't expect to necessarily see scholarly papers, but I would not ever expect a minifier to improve on itself when run multiple times in a row!

nbevans 10y ago
Yep. The first minifiers were just some regexes to do a search and replace. Undoubtably many nowadays are full tokenisers and build an AST - but I do suspect that there's still plenty of room for improvement.
_delirium 10y ago
It's not that rare for optimizers to be able to find more optimizations in a subsequent pass. For example, it's often true (for at least small gains) in assembly peephole optimizers. Once you've applied one round of peephole optimizations, which are basically just simple pattern-matching replacing instruction sequences with better ones, the resulting, improved instruction sequence may now have new sequences that the peephole optimizer could improve again if run a second time. You could try running this iteratively until some kind of fixed point if compilation time were no issue... although, it might also have cycles! That is often the nature of these kinds of pattern-matching, heuristic optimization passes. That's especially likely if you mixed-and-matched from different compilers, like running optimization passes from gcc, clang, and icc interleaved with each other. Though that example would be difficult to do in practice, because they aren't source-to-source optimizers, and have totally different IRs, so can't easily be chained in the way these CSS-to-CSS optimizers can be chained.
nine_k 10y ago
This is one of the problems with IT: it has too little science behind it. A lot of things are built based on common sense, tradition, and chutzpah. Much like building was in medieval times. No wonder things often crash and take a hard-to-predict time to build. Some things can be over-engineered but under-scienced, so to say, at the same time. A lot of great computer science already exists, and is applicable, and some of it is taught at universities. But it's not required for a CRUD app or for a flappy bird clone. And when you grow up enough to want more complex things, a lot is already forgotten.
- sidlls 10y ago
  I have, I think, a different view: there is too much CS and not enough engineering in IT. The numerous CS grads have a bag of hammers as their toolset and so every engineering problem is a DS&A "nail." At least, here in the valley it seems that way. Outside of it there is at least in my experience much more of a nod toward software development as an engineering endeavor rather than as an exercise in pure CS.
  - nine_k 10y ago
    Yes, the theoretic / scientific part does not percolate enough into the engineering practice. Thus the practice is starving without a good conceptual view, while CS may be lacking in engineering department and thus practicality.
- SZJX 10y ago
  Guess it really depends. Maybe the frontend landscape can be a bit more chaotic since JS started on really shaky grounds and so many new things come out all the time, but I'd say in general programming is still quite rigorous, especially if you're a big organization and can afford all the time and resources to apply all the best software engineering practices with a whole team. Even if not, modern developers generally do quite well. Actually, hasn't the problem people been complaining about centered on the presumed disconnection between CS academia and actual programming, about how a lot of graduates just simply can't code a simple task? I'd say a lot of theoretical CS is just not that easily applicable to actual engineering work. There's a reason why people divide science and engineering. The latter is so much more about ingenuity and practicality in a lot of senses. They're not the same thing and it would be really harsh to classify the whole field as some "medieval architecture" stuff. Not to mention there are still plenty of great works in medieval architecture!

nbevans 10y ago

Yep. The first minifiers were just some regexes to do a search and replace. Undoubtably many nowadays are full tokenisers and build an AST - but I do suspect that there's still plenty of room for improvement.

_delirium 10y ago

It's not that rare for optimizers to be able to find more optimizations in a subsequent pass. For example, it's often true (for at least small gains) in assembly peephole optimizers. Once you've applied one round of peephole optimizations, which are basically just simple pattern-matching replacing instruction sequences with better ones, the resulting, improved instruction sequence may now have new sequences that the peephole optimizer could improve again if run a second time. You could try running this iteratively until some kind of fixed point if compilation time were no issue... although, it might also have cycles! That is often the nature of these kinds of pattern-matching, heuristic optimization passes. That's especially likely if you mixed-and-matched from different compilers, like running optimization passes from gcc, clang, and icc interleaved with each other. Though that example would be difficult to do in practice, because they aren't source-to-source optimizers, and have totally different IRs, so can't easily be chained in the way these CSS-to-CSS optimizers can be chained.

nine_k 10y ago

This is one of the problems with IT: it has too little science behind it. A lot of things are built based on common sense, tradition, and chutzpah. Much like building was in medieval times. No wonder things often crash and take a hard-to-predict time to build. Some things can be over-engineered but under-scienced, so to say, at the same time. A lot of great computer science already exists, and is applicable, and some of it is taught at universities. But it's not required for a CRUD app or for a flappy bird clone. And when you grow up enough to want more complex things, a lot is already forgotten.

sidlls 10y ago
I have, I think, a different view: there is too much CS and not enough engineering in IT. The numerous CS grads have a bag of hammers as their toolset and so every engineering problem is a DS&A "nail." At least, here in the valley it seems that way. Outside of it there is at least in my experience much more of a nod toward software development as an engineering endeavor rather than as an exercise in pure CS.
- nine_k 10y ago
  Yes, the theoretic / scientific part does not percolate enough into the engineering practice. Thus the practice is starving without a good conceptual view, while CS may be lacking in engineering department and thus practicality.
SZJX 10y ago
Guess it really depends. Maybe the frontend landscape can be a bit more chaotic since JS started on really shaky grounds and so many new things come out all the time, but I'd say in general programming is still quite rigorous, especially if you're a big organization and can afford all the time and resources to apply all the best software engineering practices with a whole team. Even if not, modern developers generally do quite well. Actually, hasn't the problem people been complaining about centered on the presumed disconnection between CS academia and actual programming, about how a lot of graduates just simply can't code a simple task? I'd say a lot of theoretical CS is just not that easily applicable to actual engineering work. There's a reason why people divide science and engineering. The latter is so much more about ingenuity and practicality in a lot of senses. They're not the same thing and it would be really harsh to classify the whole field as some "medieval architecture" stuff. Not to mention there are still plenty of great works in medieval architecture!