rockstar VS FizzBuzz Enterprise Edition

what about using https://codewithrockstar.com/

You should just port your codebase to Rockstar at this point. https://codewithrockstar.com/

Rockstar

I've also decided to start work on a Rockstar interpreter, for shiggles. I'm still looking for resources on implementing interpreters in F#.

If you are looking for resources to get started, I used this interpreter: https://codewithrockstar.com/ and the docs here: https://codewithrockstar.com/docs

See http://codewithrockstar.com/ - it's a very expressive language! I'm not sure I am quite in the groove yet, but it's only day 1...

That "Hello World Enterprise Edition" looks dangerously under-engineered - I could understand it! Far better to follow the best practices demonstrated in the Fizz Buzz Enterprise Edition...

https://github.com/EnterpriseQualityCoding/FizzBuzzEnterpris...

Clean code is a balancing act - you’ll want to make sure you don’t turn your codebase into something like this.

???

I'll answer your question with a question: Have you seen https://github.com/EnterpriseQualityCoding/FizzBuzzEnterpris... ? :)

I'm guess that to those of us who remember when Java came out, "FizzBuzz: EE" is what we think of when we think of Java. :P

In Java I have to type a bazillion characters to get anything done! And make all these useless directories and files and InterfaceClassFactoryProtocolStreamingSerializer BS. And worry about how that executes.

C++? No bloat*, just speed

*Yes, there's some _optional_ bloat. But compared to Java? no contest.

There’s a difference between complexity that’s inherent to the problem, and complexity that’s added by developers who have drunk architectural cool aid.

This is an example where all of the complexity is caused by rigid adherence to the most popular architectural patterns of about 10 years ago.

https://github.com/EnterpriseQualityCoding/FizzBuzzEnterpris...

It looks completely ridiculous to modern eyes, but during peak OOP it was just how you should do it.

If you like simplicity then your fizz buzz implementation would be a few lines.

maybe it's fast, but is it enterprise quality? https://github.com/EnterpriseQualityCoding/FizzBuzzEnterpris...

Nope, I wouldn't use it. I've seen many projects that use DI containers in my career, and every single one of them was a pain to navigate, particularly when trying to get a foothold as a newcomer. It can also force you into some very enterprise-y code patterns. Keep things simple. My mantra is "Add complexity as you find that you need it, and not a second sooner".

Do you want a quick hack or a coder that's up to enterprisey standards? A proper solution could be in the 1.5 KLOC ballpark...

> you have no idea how much happens so your transaction doesn't get lost, corrupted, or errored out.

Maybe he doesn't, maybe he does - you don't know nor do I.

I'm pretty sure this is how IBM salesmen used to respond when confronted with those newfangled Unix systems which were starting to appear here and there, nibbling first, then taking larger bytes out of their market share. Instead of the litany of diverse systems they'd have thrown LPARs, SYSPlexs and ESMs around but in the end it still came down to the same thing: this stuff is too complicated to be left to amateurs. They were right, in a way... until those amateurs grew their wisdom teeth and took a large part of their market away from them.

Yes, "enterprise" stuff is complicated - often overly so [1] - and it has its place. This does not make it the only viable solution to these problems, something will eventually come up to eat your lunch just like IBM saw its herd of dinosaurs being overtaken by those upstart critters from the undergrowth. Maybe some smart software system which "guarantees" data reliability and availability without the need for "enterprise" storage devices? It wouldn't be the first time after all.

[1] https://github.com/EnterpriseQualityCoding/FizzBuzzEnterpris...