Neat. Little bit frustrating that there was no input measurement. I strongly suspect you'd need very good insulation to make it viable.
Edit: Watched the freezer video. Performance is predictably bad, but not as awful as one would expect. Might actually be a viable daily driver with thick enough insulation or vacuum panels.
There are also translations around that come via the Chinese cannon instead.
The suttas are probably very hard to understand without background knowledge or commentary (or, really, actual practice), but of course I don't know which of the commentaries GP refers to. The dhammacakkappavattana sutta, being one of the important/famous ones, has truly voluminous commentary from truly voluminous sources.
GP refers to "continuous effort to face the uncomfortable". I'm not sure that I'd use that sentence to summarise the Buddhas teaching to be honest. But I suppose that it could be a reference to the 6th limb of the noble eightfold path (right-effort), or the 7th (right-mindfulness), or to the 1st noble truth (the truth of unsatisfactoriness/ suffering).
it takes a while to learn how to use your text editor well, and everyone is probably good at a different one. but they all pretty well have the ability to produce the same result, so why bother forcing one?
it's better to (have a tool that can) specify what the end result should look like and let people work the way that they are good at.
In my team everyone uses IntelliJ Ultimate with the same settings.xml file. We all have the same automatic tasks that happen on each commit: reformat code, optimize imports, check TODOs, perform SonarLint analysis. This has greatly reduced frustrated merge-requests filled with unimportant details such as code formatting and newlines. It has also greatly improved the code quality because it will warn you that you left a TODO in the code or that a certain method could also be private before you commit the code into the repo.
Nobody has a problem with this, although in the Java world every corporate developer uses IntelliJ anyway. A couple of legacy project teams are still on Eclipse.
Agreed. Plus now many editors obey the same .editorconfig files; and for those that don't, .editorconfig can be used as a reference for developers to configure their own working environment.
I can understand wanting to standardize in a company with a 1000-person engineering org, where maybe it's harder to enforce that everyone uses the same conventions if there's no standardization in tools; but in a team of a few dozen, you should only be hiring people you trust anyway, and communicating with them about why small things like this are important.
If I had some persistent problem or concern I would just bring it up, I wouldn't wait for some scheduled meeting. I guess some managers might not be so easily available.
It's not just the managers. I've worked with great managers who were truly available, but due how busy I perceived everyone to be, I never felt comfortable interrupting things for what I deemed weren't critical issues.
Since we did have regular 1 on 1 meetings, I knew I had a dedicated block of time coming up to hash things out.
What if your manager is in the middle of something? Even if they allow for the interruption trying to help, their mind may still be on the other task, and they likely will try to find the quickest solution to get back to what they're doing instead of the best solution.
If you instead talked about it in your one on one, they can spend more time on it with you.
I believe the "/or" was added after it was submitted the OSI and FSF, because they felt that it could be misinterpreted without. However it appears that OpenBSD didn't change their version (probably because they don't believe it's ambiguous).
It helps to be familiar with the words (Factor term for functions) in use. You can use http://docs.factorcode.org to look them up. All the help is also available from within Factor itself. You can click on word definitions and it comes up.
In this case there is a word called '<color-picker>' being defined. It takes no arguments off the stack and leaves one, gadget, on it.
Now working from left to right, 'vertical' is a constant. '<track>' creates a new GUI object called a track that requires the orientation to be on the stack. That what 'vertical' is. It's the orientation.
Now that there is a track object there we fill in the slots of that object. That's what '>>foo' does. It stores something in the 'foo' slot of the object on the stack. So "{ 5 5 } >>gap" stores the 2 element vector containing the integer 5 twice, into the 'gap' slot.
'<color-sliders>' creates a gadget and a model that is left on the stack. This is what 'bi-star' is now operating on.
'bi-star' is a combinator. It requires two objects and two quotations (quotations are factors term for anonymous functions or closures). It applies the first quotation to the first object, and the second to the second object. This system of combinators is described in the Joy language writings, although I think under different names.
"[ ... ]" is the syntax for the quotation. So "[ f track-add ]" is the first quotation. "bi-star" call this with the 'track' on the stack since that's the first object that "bi-star" gets access to.
The rest of the code can be worked through in a similar manner. In general you learn to recognise things like "<...>" for creating objects, ">>foo" for setting slots, "[ ... ]" for quotations and combinators to reduce stack management (like dup, rot, pick, etc).
They do in my (marginal) experience. I have found it to be a very common idiom to keep word definitions in these languages as short as possible. Probably for this very reason.
You define new words for the sole purpose of keeping things short and to the point. This holds true for most languages (At least if you want readable and maintainable code), but a language like Factor, this becomes an absolute necessity.
I would not be surprised if this is the reason Factor is called Factor. Specifically when related to factoring in Algebra where you do much the same thing: "splitting" an expression into a multiplication of simpler expressions.
