Hacker News new | past | comments | ask | show | jobs | submit login

I think the trouble with a general purpose constraint solver is the results sometimes aren't what you expect or want. The best example of this is the Apple constraint system for screens used in XCode, so much time can be spent debugging constraints.



Certainly.

It should also be noted that 'constraints' are about as generic a word as 'Object Oriented Programming'.

Some constraints are easy to understand and use: such as TeX's constraints on spaces between words. I don't think anyone has ever really had an issue (aside from when the solver can't find a solution and you are forced to reword the paragraph). TeX "just works" and is probably the easiest constraint solver to use in practice.

In contrast, Apple constraints seem to be pretty complicated: https://developer.apple.com/library/archive/documentation/Us...

Manually selecting multipliers + constants is... non-intuitive and seemingly inflexible. Sure, its a list of constraints but that's not as useful of a search space IMO.

----------

Knuth's TeX system purposefully chooses an NP-complete representation that is well known to be "inefficient" and fails to scale.

It just so happens that paragraphs of text are naturally short enough to work with TeX in virtually every case. People don't seem to write paragraphs "too long" for the algorithm to handle.

There's an extraordinary amount of search space the algorithm is given. Its practically a "Knapsack problem" solver.

-----

So the goal is to find:

1. A system of constraints

2. That is easy to understand

3. That is powerful enough to represent "nice looking" layouts (or text, or images)

4. That may or may not be "efficient" to solve, but is "efficient enough" to work on practical problems.

This blogpost absolutely fails at #2, as it has basically created a new programming language API!! However... its probably a good stepping stone towards finding the "simple set of constraints" we want for practical use.

The next step is to probably play around with this solver ourselves, and then discover a subset of primitives that is easy to understand and describe.


AFAIK, TeX only gets really complicated when a document contains pictures (which it can move forwards or backwards relative to the text, if that leads to a better layout)

For text, https://en.wikipedia.org/wiki/TeX#Hyphenation_and_justificat... claims O(n²), with n the number of possible breaking points in a paragraph, or even O(nw), with w the width of a line.

As to the algorithm used by MacOS, that’s https://en.wikipedia.org/wiki/Cassowary_(software) (also used by the scwm window manager)




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: