31–40 of 91 posts
Laravel’s use of conventions and facade. It was quite nice to see how a carefully designed developer experience can improve productivity. For most app, the code basically write itself.
The versatility of common lisp.
Up until a point functional programming with PHP or Python were always littered with small state time bombs which could change at any point in time. Only after thinking about state explicitly in Erlang based programming, was it clear how the state enclosed in OOPS is a total digression from reasoning about state and behavior separately.
Python, Erlang and then Clojure
Just dropping `binding.pry` anywhere in the code, run it and then get a full REPL with all the variables and instrospect everything with `ls`. This is why I am still coming back to Ruby and writing everything like it. In most other languages you spend a lot of time actually trying to find a way to debug properly. Happy to hear recommendations how other languages are doing it. (I know that there are debuggers :P )
Go down the rabbit hole of the actor model & eventual consistency, it will make you a better developer. After reading everything you can on the topic, there are a couple of frameworks that implement it (Orleans Framework & Akka & others). I think it will make a comeback as it is a natural fit for multicore cpu's/gpu's.
It is also fairly easy to create, persist and resume state machines, which can help a ton for complex workflows. It also forces you to think in a bottom-up approach instead of a top-down approach like most languages/frameworks.
Another interesting thing to dig into is "code calisthenics" and "tiny types".
Pure functions. It totally changed my game when I realised that state was "evil" and that it should be treated like the dirty little possum that it is. The whole functional programming paradigm made a big change for me. Coming from the 90s you know, we were fed Object Oriented paradigm down the throat up to mid-2000s. If you didn't do OO on your resume, no point applying. Then slowly the whole industry started lookin…
> composition over inheritance
I agree here, so I view the use of utility classes (like Tailwind) as the composition approach and the traditional CSS approach of using complex cascading rules as the inheritance approach. It took a while for people to see that big inheritance trees don't scale well in OOP languages. I'm seeing the same thing repeat with CSS here where people cling to the old way because it's what people have been told is best practice.
In combination they are a huge productivity boost that you can't really imagine without having tried it. I still remember the days where I wrote tests over tests and ran the system to check if it works. But "if it compiles it works" is just a sooo much smoother workflow.
I have these 2 huge files with hundreds and thousands of small unit tested functions that do everything under the sun like sorting a js hash by key, to making ajax requests, to all the things I've needed to do over the years. This has reduced my time to code by so much I can't even begin to describe and also I feel confident of not making silly mistakes since the functions are tested and reused many time. Thanks to tree shaking in js it also means I do not increase the bundle size.
On other thing that has helped me a lot with programming is learning zen css and zen html, i.e. div.test>span>b type stuff. Such macros really help a lot to avoid mistakes and help speed up things.
Things like depending on interfaces as opposed to concrete implementations; or prefer message passing over direct data access are practices that I learned in OOP that I still value. The "Small Talk crowd" from the first team I worked in and influential authors in the topic (specially Sandi Metz) still have a dear place in my heart for how they improved the way I view software design.