How much of the improvement is attributable to the rewrite and lessons learned and how much is attributable to using the backend language du jour?
It also helps if the language idiomatically nudges you in the right direction.
Indirection tends to be minimized in Go, similar to C, and encourages solving your immediate problem.
Comparatively, Java and C++ encourages you to design/grab for reuse first, opting for flexibility.
IME Java devs will write idiomatic OOP in this style, just like Lispers will fiddle with macros. For us, picking Go helped signal that we wanted people who wrote procedural, direct-first code.
class MyService {
ILogger<MyService> _logger
MyService(ILogger<MyService> logger) {
this._logger = logger;
}Making it a monumental PITA to use without the associated Jungle: The chosen DI framework. Why is the ILogger generic? Because of the DI framework, so it can create a logger that corresponds only to this type.
We're literally writing code to keep the framework happy.
Even though there are no other implementations.
Why? Seems to boil down to "our language / environment / DI system / mocking framework is incapable of working unless you do it this way.
Yet more cognitive and implementational waste.
What does eXtreme Programming or Agile have to do with how you pass messages in code?
Perhaps it's something about my area, but this style is standard idiomatic Java/C#.
EDIT: And the opposite statement is (perhaps more) true for Go. Adopting IBeanProxyFactory-type of stuff in there is beyond unidiomatic.
I think it’s telling that Go, Rust, as well as more inspired stuff in later editions of C++/Java/C# all seem to be demonstrating that nominal inheritance-first polymorphism is not the only or always the best maze of abstraction for getting to a concrete dispatch from type A to type B in imperative-feeling languages.
> I want to point out that I love SmallTalk, and feel that this style makes sense in that environment.
Seems like 2 different things are being conflated, possibly because much of that XP TDD stuff was done by some prominent Smalltalkers.
Test first, send a messages to objects, or inject something smarter.
... and I loved it. Talking to a living thing via messages felt a lot like Erlang or Lisp. I don't get that vibe from Java/C#, despite similarities.
I should probably pick up SmallTalk again. Any recommendations?
I don’t want to assume your reply was intended to be rude. I think they’re asking for recommendations on anything that might help/guide them picking up SmallTalk again.
First you imply my question was rude, and then you call me a jerk, and then you call me mean.
I did not dismiss the request, I gave a recommendation.
In this case, I would want to learn more just for the fun of it, like learning to play an instrument, holding off effecting the world for now.
The first Smalltalk implementation I used was bought because I had already implemented a proof-of-concept prototype on a spreadsheet (Lotus 123 iirc).
As-it-happens I have no experience with Smalltalk-as-a-hobby.
This was written after comparing a ~300K SLOC Go project to it's original ~800K SLOC Java project at work, that we've rewritten over the course of a year or so.
In the Go version, test coverage is floating around 90-95%. Performance, and memory use especially, is drastically better. This is from lessons learned, where a large part of those lessons meant reducing this type of 1990s XP/Agile/SOLID style of constant indirections and pass through classes.
Yes, the main files where startup allocation happens are huge, but it's all in one file (per service) and can be easily grokked with IntelliSense and general code navigation features.
In the Java version, every folder had a large section of subfolders with files that pointed to other files that perhaps did something besides calling other objects. Startup was horrible, memory consumption was high and tests were somehow more verbose than Go (which are already a mouthful).
I want to point out that I love SmallTalk, and feel that this style makes sense in that environment. For Java/Microsoft Java, this style is IMO not worth the effort for neither developers nor codebase.
Interesting discussions in this thread already, thank you <3