AdventOfCode2020 VS component

> At the end of the day, you quit your environment and shut down. How do you ensure your interactive work is not lost and the environment is still what you expect it to be when you start again the next day. How would you compile such a program?

Modern Smalltalks have solved this problem. Smalltalk has the concept of Packages just like Java, and as you go along building your environment, even though you are modifying the Smalltalk image, you can export these packages to plain-text files, and put them in Git, just like any other language. The environment itself supports Git integration (called Iceberg in Pharo).

> Also, if significant parts of the source code are written inside the REPL, wouldn't the lack of modern IDE features be a hassle? No syntax highlighting, no code completion, no code inspections etc. Or are there tools that offer those?

The command-line REPLs that other languages have are NOT what you get in Smalltalk. I believe the author means the entire interactive environment, and the "style" of development is REPL, not the actual UI. The Smalltalk "IDE" is just as powerful as any other IDE, including code completion, automatic generation of certain getters/setters, renaming methods/classes, finding uses, jumping to declarations and even refactoring within methods. The difference between a normal IDE for Java is that this "IDE" is pervasively available, including in breakloops and the debugger. Since the system is live, there is no separate notion of debugging, the debugger is always there, and you can use all the editor IDE features when stopped in a debugger. You no longer have to deal with a crippled debugging environment way different from your authoring environment. It truly is mind-blowing!

I highly recommend giving Pharo Smalltalk a spin (by following their MOOC or similar). This video is also worth a watch - https://www.youtube.com/watch/baxtyeFVn3w

I did most of this year's Advent Of Code in Smalltalk and saved it in Git just like any other language. Someone else can then import it into their image. https://github.com/nikhilm/AdventOfCode2020.

Note that the source code looks very verbose, but you never actually interact with the source like that. The source is just a serialization. Your actual environment only ever shows you UI elements and entire IDE windows describing your classes and individual methods.

The only thing I miss in Pharo is that it doesn't have Vim keybindings :)

* Lifecycle management: Mount, Integrant or Component (https://github.com/tolitius/mount https://github.com/weavejester/integrant and https://github.com/stuartsierra/component)

When you start to have multiple stateful components (the database, the HTTP server, your Redis connection, a page cache, etc.), then you'll want to use a library like component that manages their (inter-)dependencies and provides a consistent notion of lifecycle.

Today I released a new version of Reveal Pro — dev.vlaaad/reveal-pro {:mvn/version "1.3.308"} — that adds sticker integration for system libraries such as mount, component and integrant!

I agree with the main sentiment from the article. Although I do think they are discussing Inversion of control more-so than dependency injection.

One of my first languages was .net and I was never able to really understand DI in that context that well.

Actually using javascript and ducktyping made me understand what it actually was.

I remember a .net job interview where I had to write a micro-service and opted to construct the dependency graph in the main function initialising "all" the classes there. Instead of discussing the pro's and con's of that approach they berated me for not using a DI framework (No I did not land that job, but in hindsight it was the most expensive job interview I've ever had. The room was filled with 8 developers going over my code).

The main thing the article glosses over is state. something people with a functional background hide from. But if you look at something like the httpclient in .net. I think it took the .net world like 10 years to start using the httpclient properly. Scope and lifetime of those kind of objects are important. managing connection pools, retry state, throttling or the incoming http request. DI does make that kind of thing easieR (I'm not saying it makes it better)

Look at clojure's component(https://github.com/stuartsierra/component), I'm not a clojure expert by far. But it is kinda DI/IOC in a functional language.

In closing we can agree that it is underused in the right places and overused in the wrong ones.

https://github.com/stuartsierra/component#no-function-should-take-the-entire-system-as-an-argument

Yeah like I mentioned I'm not like super sold on the everything-should-be-an-actor paradigm, but I find value in DDD + a light implementation of Components (similar to stuartsierra/component).

https://github.com/stuartsierra/component for managing components lifecycles in projects