I think 'joy' would be a fitting term, perhaps? Here (https://www.1517.org/articles/cs-lewis-on-joy) C.S.Lewis defines it well, and distinguishes it from 'pleasure' and 'happiness'.
First, congrats on the library and thank you for sharing it!
1) A hint about potential prior art: F# (and/or C#?) have a first-class unit system (physical units I think), which sounds a bit similar to monetary calculations. However, physical unit are easier to model than monetary unit I think.
2) Currently, I am building something tangentially related in Rust: A backtester (test trading strategies on historical and/or simulated data) with focus on accuracy. So one thing I included already is that Assets (like etfs) are valued in a currency.
If I may be so bold: How would you approach these questions / where could I read more about that?
1) When simulating, can I always assume that the exchange will work? (For assets, that is not always the case, sometimes one has to wait a bit until there is a buyer, or there might not be a buyer at all)
2) Is there public domain data in exchange rates?
3) If I have to choose, which exchange rate should I pick? The lower one, higher? What would make the most sense in the context of trading etfs, stocks, options, crypto etc.?
4) How to approach rounding, is there a best practise?
5) I assume it is best to immediately substract taxes in every transaction, even if they are formally defined annually, right?
6) Would you model inflation? I currently plan to ignore it and present it at the very end: "Your portfolio has a final value of X.X ¥. Adjusted for inflation, that would be Y.Y ¥ today (2024-10-08)."
The currency exchange support is way simpler than this. The library only provides a method that will calculate the monetary amount given another Money object as the rate:
val amount = 1 money "USD" // USD 1.00
val rate = 5.4905 money "BRL" // BRL 5.4905
amount exchange rate // BRL 5.49
It's up to implementers to hook up in other datasets and to consume the rates. Exchange rates datasets differ from country to country and some foreign exchange companies offer short-term contracts to hold a transaction at a given rate (sort of "guaranteed rate/price"). I don't see myself supporting this use case.
Nevertheless, Java Money (Moneta) has this feature. Never used it so, I don't know how it works.
I think it makes sense that this feature would not be planned in your library - as I understand, its goal is to support developers to write better money-related logic, which is sometimes related but different from simulating as accurately as possible.
I just noticed a potential misuse of your API: Transitve relationships: "A" = 2.0000 "B", and "B" = 3.0000 "C", then implicitely, "A" = 6.0000 "C". Can the user now define "A" = 7.0000 "C"?
That would be wrong - but not trivial to prevent, and practically speaking, it is okay I think.
Thank you for your time and for this exchange, wish you good success and fun with kotlin money! :)
To add to this: A bit similar to Lisp, due to the different compiler plugins, Haskell is more like a family of dialects. One can be pretty vanilla about what the types should protect against, but one can also build arcane type-magic buildings that rely on the newest PL research.
Simple, vanilla Haskell is approximated more and more by the mainstream languages: Optional types, andThen().orElse() and friends and other things - which I am really happy about!
Why not use a more mainstream langauge then? For me, there are at least 3 hard reasons:
1) The stuff mentioned above is old, battle-tested and deeply embedded into the language and the community - it feels ergonomic to use.
2) IO-being-a-library is a paradigm that produces programs that I love to maintain, also when others written them.
3) Haskell has nice interfaces that I miss in mainstream languages, Functor and Monad for example. My prediction is that in around 5 years, mainstream languages will start to offer these kind of interfaces - starting from "Wait, what else can we do with andThen() and optional chaining and so on?"
Heh, I don't think that will ever really change. What changes in my experience is your knowledge and confidence when it comes to translating requirements into maintainable technology. The real world stuff seems to be always messy. My attitude is to try to locate areas of potential unknown risk, plan how to deal with the known risk and then hack away, knowing that no matter how much time spent, the plan will be flawed. During this whole process, communication is really important (i.e. 30% feedback, where I just write comments of what I would change in the codebase and then talk about it with a collegue)
> Even when you understand it's wrong, or at least heavily negatively biased, fighting those interpretations feels like trying to swim upstream in a terrific current.
Achieving it still feels like the end of "A beautiful mind", where there are people hanging out in the room that are not there. They sound like they are they, they feel like they are, they smell familiar. But they are not real and will disappear some wonderful day, as they always do. So you just nod to them and go on with your live.
> some of our best people are remote, and we will continue to support it always, so please don't let hating SF stop you from applying to OpenAI!
What is a strong sign of conviction? Putting your money behind it. Which is exactly what is not happening here - not only keeping, but being open to increasing the remote working force. So is Sam Altman telling us that... OpenAI is not doing innovative work anymore? Or not valuing collaboration highly?
Obviously the "indirect" part of the post you are responding to applies.
Your last sentence seems to indicate that you know more than us - if so, enlighten us please about the incentive situation of Mr. Altman. (Whose products I value quite a lot, I will say)
Yes (did not doubt that), but this is of course only one part of the puzzle. Remember that the assumption of the post you responded too suggested incentives tied to real estate (stock in real estate sector might already be enough), and not about salary/stock in OpenAI. What about other engagements, promises made and so on? Has he declared that incentive-wise there is nothing else than OpenAI going on for him?
> However, if your work is about innovation and collaboration, then it's going to be more effective to spend time together.
Not convinced yet, at this point it just seems to be anecdotes, and pretty nebolous ones at that. I would be open to listen to this position if it was backed up by actual examples like "So we were working on Product X and team Y struggled with remote work in that and that way." Creativity/Innovation is not something fuzzy, but something very real that will result in deadlines not met, lower morale and so on - I will start to consider Altmans et al.'s position once I hear those non-fuzzy experiences. (As someone working in a small startup doing innovative products, and collaboration being crucial).
I work in a small startup doing innovative software/hardware products. Some of the most 'creative' work we have ever done as a team was when the power went out and we finally spent time workshopping what a particular thing should be like with a whiteboard and pieces of paper. That was a defining moment and what we came up with on that day is kind of what we have today.
Some of the best and most valuable insights in our process are captured in recorded IRL onsite sessions with our users. Humans put on a bit of a show when they're remotely connected and that just ruins the process because they just sort of withdraw after they say their bit. I have recordings that prove this - users spontaneously changing their minds or sharing more about how they really feel about something.
I would argue that the best creativity on a team occurs when there are actual meat-skeletons together in a room smelling each others' farts, interrupting each other, eating together, getting excited, getting pissed, whatever etc.
But you are absolutely correct that this is anecdotal and nebulous at best. In the article he mentions how this is better when the product is unclear and unformed yet.
Figuring out what a building should look like is different from pouring the cement. It is unfortunate, but in our specific case the team likes getting that cement poured. They focus and they get a lot of work done, only then it has to be re-done as it turns out everyone actually had very different ideas.
This isn’t necessarily a remote/non-remote work problem, but I think that’s why that guy in the original article talks about the benefits of having people in the office.
Again, how is that a remote problem? Sounds like a leadership, communication & project management problem. Everyone being in an office doesn't magically solve those problems.
You raise a good point, and I would answer it with agree and disagree:
Agree: Yes, you are correct, merely observing that a code path was never executed in the last 6 months is not the same as understanding why the code path was created in the first place. There might be the quite real possibility of an infrequent event that appears just once in every two years or so (of course, this should also be documented somewhere!).
Disagree: Pragmatically, we have an answer if the code path was not executed after 6 months use in production and test: We know that, with a very high probability, the code path was created either by mistake (human factor) or intentionally for some behavior that is no longer expected from our software. To continue the Fence metaphor, regarding Sensenmann: After 6 months, we know about the Fence that 1) it has no role to play in keeping the stuff out that we want out (that was all done by other fences that were had contact with an animal at least once) and 2) that it might have been used to keep out flying elephants or whatever, but no such being was observed in the last 6 months (at least the fence made no contact with it, which it then should have!) and probably went away.
That said, having a human in the loop is probably a good idea.
