I believe BuildKit solves the dependency graph problem. Docker has shipped with it since 18.09. It is opt-in for now so you have to use e.g. `DOCKER_BUILDKIT=1 docker build ...`.
I have great respect for Rich Hickey and I recently saw a cool talk about a financial startup using Clojure in production [1]. I have kept track of the language for some time but have never had the chance to use it in any serious capacity.
They do not just show ads. They also display content.
Existing in a filter bubble has a strong effect on your perception. Perception has a direct influence on your actions. Couple this with interfaces which are purposefully addicting ("high user engagement" is a euphemism), and you can very directly influence behavior.
The pervasiveness of smartphones means that these apps are only a few clicks away for virtually the entire world population. And worse, once these apps are installed on your phone, they relentlessly pull you back in with and endless stream of notifications.
It is not only Facebook. Applications like Reddit, YouTube, Instagram, Twitter, and TikTok all follow the same basic patterns.
It is not an overly dramatic description. If anything the public has been frightfully unaware of the influence that these companies can exert on the world. I am glad that this film has brought these issues into the spotlight.
There was a huge discussion shortly after Julia 1.0 was released regarding scoping [1]. Beginners intuitively think of scoping in a manner different from the way scoping should work in production projects. There was a lot of tension between seasoned programmers and educators (who had to constantly interact with beginners).
The community exhausted the entire design space (along with some full-blown prototypes). Eventually, the core Julia team chose to use more forgiving scoping in the REPL (virtually always the first point of contact for beginners), while actual projects enforced stricter scoping rules.
My key take-away is to consider how the language interacts with its ecosystem, not just how it should ideally operate in isolation. I have found the Julia team to be consistent in this pursuit. If the first point of contact is intractable for beginners, the project is dead on arrival. A technical tool should be tailored for experts, but you don't want to kill adoption along the way. Engineering is tradeoffs.
"Language agnosticism" is an ideal I have never been able to attain. Sure, I can hack together a solution on the first week of learning a language. But, am I able to write elegant, idiomatic, efficient code during the first few months? No way.
A language is not just the basic control flow operations, but includes package management, performance gotchas, correctness gotchas, standard library, library ecosystem, data representation, etc. Then there are details and edge cases that you just don't hit without months or years of hard work with a language.
My experience tells me to take choose a reasonably robust language, then stick to that language until you have an overwhelmingly compelling reason to switch.
People seem to focus on the volume of cars. But traffic is not just a matter of volume but of friction between cars. Reducing the friction (naively) appears to be a simpler problem. You wouldn't even need full self driving, only enough tech for cars to merge/switch lanes without slowing down.
Not requiring a central point of control is an additional benefit. The reduction of traffic would be an "emergent" behavior.
I feel compelled to restate how wonderful this book is.
> it has also helped me think about my feelings
The book focuses on communication with others, but effectively fosters constructive inner dialogue as well. I know of at least one other person who claimed it helped them avoid destructive habits.
> it has helped me put more structure around tough conversations
I deescalated a nasty dispute between two people close to me after reading only the first few chapters. I was impressed because I wasn't the type of person to emotionally connect with people so effectively.
I believe the world would be a better place if more people read this book.
One way is to show that, given a state of the universe, it is possible to determine the next state. From what I understand, this does not seem to be the case.
> So, what we do is take money and move it around into other businesses. The newspaper business earned great returns but not on incremental capital. But the people in the industry only knew how to reinvest it [so they squandered a lot of capital]. But our structure allows us to take excess capital and invest it elsewhere, wherever it makes the most sense. It's an enormous advantage.
Wow, they are playing the game at a higher order than I have even considered.
Racket has a special place in my heart. Racket, together with https://htdp.org/, helped me reach a point where I felt my code truly reflected the structure I was modeling. It helped me focus on data flowing through my code, rather than blindly following "cookbooks". Racket is one of the very few languages that get out of your way, so that the model is almost tangible.
Code design is what keeps complex projects from collapsing under their own weight. There are always trade-offs when constructing software, but I feel that design is often neglected needlessly.
This is a known `Pkg` bug (the patch should be merged this week). In the meantime, you have to `pkg> rm SymEngine` followed by `pkg> add SymEngine#master`.
Apologies, I wasn't trying to be pedantic. My point is that Juno is decoupled from the language itself. You don't have do depend on it to be productive with Julia.
I agree that tooling has a significant influence on the productivity of a language. One does not only adopt a language, but the ecosystem and community around it. I think we both agree on this. I am simply trying to point out that there is an unavoidable delay between the maturity of the language and the maturity of the ecosystem. I think its fair to take this delay into account.
https://github.com/moby/buildkit