dm3

Unfortunately there isn't a single definition of DDD accepted by everyone. At its core DDD is about the practice of software design which puts Domain - user language and problems - first. There are no technical considerations.

ES (Event Sourcing) and CQRS are technical patterns people like to use while doing DDD because of various reasons, but they're in no way required to practice DDD.

Switzerland does have poor people. ~10% of the population below the poverty line which is defined around 2.2k CHF/month per person. This definitely doesn't allow for a lot of high quality meat consumption.

The country with the most expensive meat I know is Switzerland. The local chains Migros and Coop mostly sell meat produced in Switzerland. Here's the chicken you can usually find on the shelves in Migros:

https://produkte.migros.ch/optigal-poulet-241001011000

> Whole chicken - $10/kg

https://produkte.migros.ch/optigal-poulet-schenkel-241110100...

> Chicken drumsticks - $15/kg

https://produkte.migros.ch/poulet-brustschnitzel

> Chicken breasts - $30/kg

https://produkte.migros.ch/bio-pouletbrust

> Chicken breasts (I suspect this is free range) - $58/kg

A lot of great comments here.

The closest community to what you are asking for here is probably the DDD/CQRS/ES[1] Slack[2]. Google groups are pretty much dead at this point.

[1]: https://github.com/ddd-cqrs-es [2]: https://ddd-cqrs-es.slack.com/

I'm not sure what properties of the system you assign to the DDD label, but in my experience DDD just means you put the domain first. It's all the Event Sourcing and CQRS baggage which gets lumped together with DDD and adds heaps of non-essential complexity.

If the understanding of the domain changes, you change the code - there's no way around that.

This reminds me of a pair of episodes on Darknet Diaries - Manfred[1] - ep. 7/8. Opened my eyes to how insecure games actually are (were?) and how the economy of virtual item trading moved from E-Bay to in-game transactions:

[1]: https://darknetdiaries.com/episode/7/

I'd think sharing the plan of building two versions of the same thing and tasking the teams to come up with two distinct implementation strategies would provide a better outcome. This way there's still competition, but of a friendly kind. The risk is further diminished by communication of lessons learned and not having to step on the same rake multiple times.

That's definitely a problem. I work around by naming all my structs with a `_1` suffix and `%s/_1/_2/g` (VIM find-replacing) every time a struct changes. Otherwise I find Revise works great.

Surprised there's no mention of SBE. It's my go to schema-based serialization format.

This information was true a few years ago. Now, with modular JVM you do not ship a VM with the program. JVM by itself is lean and starts up pretty fast. You can also compile to native with GraalVM - this is a viable option if you want to write lots of tiny command line tools.

See Babashka[0] for an example scripting toolkit written in Clojure.

[0]: https://github.com/babashka/babashka

I really enjoyed your comment. Probably because I've been thinking the same for a long time now. I've had to learn and write a lot of C++ in the past year and the only way to stay sane is to use as small subset of the beast as possible. In many ways Rust is a better C++ - no undefined behaviour, no lvalues/rvalues/xvalues/..., complicated move semantics, tooling, etc. Rust feels like a nice subset of C++ with additional safety features on top.

However, once people reach for C, C++, Rust or Zig - performance is on the line. To push the maximum out of the program we need to do as much compile-time programming as possible. C++ template meta-programming language is Turing-complete but extremely hard to learn and effectively program with. Rust compile-time programming is evolving - two sorts of macros and a Zig-comptime-like `const fn` feature. What I like about Zig's approach is summarized well by pron[0].

[0]: https://news.ycombinator.com/item?id=22112382

That's right. However, the 20s delay only happens once during the first plot action in the fresh REPL. That's when Julia compiles all of the functions not present in the system image. All of the repeated plotting will not require recompilation of the "base" plotting libraries.

I know of an attempt to implement an approach to track issues and code in a decentralized manner with SIT[0]. Unfortunatlely the project seems to be dead.

[0] https://github.com/sit-fyi

I think practically this would have to be solved by the equity brokers. All the intermediary accounting done in fractions and only rounded once cash leaves the broker.

There are already contracts trading at fractional cent prices. For an example see treasury bonds listed on CME. According to CME document[1] margin and option premium calculations round the amount to nearest cent. I suppose the same happens at settlement.

[1] https://www.cmegroup.com/trading/interest-rates/files/Treasu...

Would you care to expand on what would be the reasons?

Do you have a reference to the up-to-date guide that you'd recommend to get started in the OCaml ecosystem? The one that would cover editor integration (VIM/Emacs), build system, standard and essential libraries to use, etc.

That's not a fact. This is an interesting take on the "laws" of a classical economy[1].

[1] https://www.youtube.com/watch?v=LsUS3ynhAKY&feature=emb_logo

I think you're giving Haskell too much credit... In my experience most abstractions need to be replaced because of performance requirements - achieving lower latency, higher throughput, etc. That's the reason to go with UDP instead of TCP. Not sure if this sort of leakiness falls under what Joel had in mind though.

SBE is a zero-copy schema-full serialization format. I don't think there's anything which limits the format to the financial domain. For example, here's [1] a toy example of a schema describing a car.

[1] https://github.com/real-logic/simple-binary-encoding/blob/ma...

There's even an interactive version...

https://brrr.money/

Oh wow... Been walking past these things for a few years now. Never realized it's E-Ink!

Out of curiosity - what are the pain points related to Mount?

Not sure why people wouldn't like this answer. We've had great success with this approach and co-sleeping even after the breastfeeding period.

Would be interested to hear negative experiences.

Thanks for the answer.

To be clear, I wasn't comparing languages in terms of correctness of code you could potentially produce. Of course C++ is the worst on this metric. However, it has its own niche in low-latency setting where I can't see anything else replacing C++ any time soon.

> As for Haskell, I like the language, but it's super fragmented, everyone has its own Prelude and favorite language extensions, extensions that are sometimes in conflict with other extensions and the tooling is a mess. Also laziness is cool, but performance gets hard to predict. We have the same problem in Scala when we are using lazy abstractions actually, the difference being that Scala is opt-in instead of opt-out.

Not an expert in Haskell, nor Scala - only dabbling. However, the above could be repeated verbatim after replacing Haskell with Scala, couldn't it? You can write Java++, Haskell-- or any combination in between. Use one of the several FP stacks or build tools.

I think both Scala, Haskell and C++ can compete for the name of the most complicated, fragmented and diverse language and ecosystem in existence.

My favourite resource for the introduction to Calculus is "Calculus Made Easy" by Silvanus P. Thompson[0].

0: http://www.gutenberg.org/files/33283/33283-pdf.pdf

Another case of someone discovering, after 10+ years in tech, that code is a liability and you're supposed to solve problems instead of chasing trends and padding the resume.

Great that he's spreading the word!

There's PackageCompiler[0] which allows to precompile the packages you need for work into a system image. This means avoiding precompilation in the REPL every time you start up Julia. That's if you start with the custom system image.

However, it's a community effort and is somewhat non-trivial to get up and running with. Once Julia gets better precompilation/binary packaging support, common workflows like plotting will improve dramatically.

[0]: https://github.com/JuliaLang/PackageCompiler.jl

I stumbled upon another example of seemingly non-sensical potato-printing-and-mailing businesses in a Twitter post[0] yesterday. Mailaspud is actually going strong since at least 2014 so it's definitely not a joke.

At this point I will believe anything.

[0]: https://twitter.com/Paul_Courtney/status/1136274715092377605