I guess the upside is that you end up with a "compiler" that checks the invariants of your project and that domain rather than strict type safety. I love static typing, but I did try Elixir w/ Phoenix recently and was impressed that they were able to implement compile time checks like verifying that all redirects are valid routes, etc. Depending on what you're building, having a few small domain specific checks like that could be more valuable than strict type safety.
Improving performance isn't the only way you can make something "better". A system could be architected in a fragile or rigid way that makes extending it or adding new features extremely difficult without a rewrite.
I can't tell you how many times I've seen people "make it work" and create a mess that has to be rewritten later with much greater difficulty than if even the slightest amount of forethought had been given before hand.
While I agree with you that the JVM is great, I think most people that don't like it really just hate Oracle. It's not really a technical argument as much as it is philosophical. I don't really care either way, but I can see why people would mistrust Oracle knowing their history.
I understand the sentiment, Oracle is a terrible company and I don't like it either. But at this point we have the OpenJDK and you can use the JVM without caring about Oracle at all.
I switched to openJDK implementations after JDK 8 and lately that seems to be the way the entire community is going, due to Oracle’s new licensing restrictions.
If you just hate the JVM, Clojure was designed in such a way that it could be hosted on many VMs which is nice. As others have pointed out, it can run on BEAM VM or even V8 with Clojurescript I believe.
This isn't just a design principle for .NET libraries, it's a SOLID design principle. All classes should be inextensible unless they are explicitly designed to be extended.
The open/closed principle doesn’t say that. It says classes should be “open for extension” (usually meaning you are able to inherit from them and add functionality) and “closed for modification”, meaning you aren’t able to change internal implementations.
It does not say “everything should be closed by default unless explicitly marked otherwise”...
Composition is still an option, and arguably the default option. Sealing a class does not prevent anyone from extending the functionalities offered by a class.
This article seems like a great argument for using open source encryption software. This guy handed over his source code to the NSA without a warrant or anything? So any idiot that steals your laptop can just call him up and exploit his software to get to your files. Great.
Uhhh did he say it wasn't Sony's fault? His point was cross-play isn't the worst part, but the way Sony locks your account in. Don't see how that exonerates Sony.
I really liked Elm a lot, but the issue for me was that composing components is a shit show. You have to add variants to the root Msg type for every single subpage and have it dispatch to the right update/view functions.
I'm really excited about a project inspired by Elm called Yew but allows you compose components much more naturally and easily.
I really liked Elm a lot, but the issue for me was that composing components is a shit show. You have to add variants to the root Msg type for every single subpage and have it dispatch to the right update/view functions.
Doesn’t that make sense, though?
An app in Elm is some kind of state + messages that change the state. Since the state is usually too big to fit in a single structure, you break it down recursively into progressively smaller substates. These again have some messages that mutate the state.
Now, doesn’t it make sense to send the “child” messages through the parents? You shouldn’t command the children directly, you should always tell the parent to tell the child do this and that. At least in our [Swift, not Elm] app that makes sense, composes well and keeps the model simple to think about.
Not op, so I don't know his/her struggle. My struggle comes maybe from the syntax I'm not used to, but also it always feels like you have to keep the whole message-graph in mind to understand which message comes from where and goes where and needs to contain which data and while that type system helps, it feels like it also makes it more difficult. You cannot just run it and see how far you come, you're code just won't compile. I know, this is a good thing for bug free production code, but exploration is harder (at least for me).
Also the types become really complicated after a while since you wrap everything in some kind of message type. So your parent message contains a child message, containing some data that needs to get passed to the next view. So errors become less readable or helpful. Or I'm doing something wrong, which could very well be because I'm a bloody beginner.
[I]t always feels like you have to keep the whole message-graph in mind
It should be quite the contrary. When you design a piece of the app, the piece should have its state, messages and view code, so it should be perfectly possible to ignore any context, focusing just on the single piece. Just like when writing pure functions, for example.
You cannot just run it and see how far you come, you're code just won't compile.
This is a known initial hurdle with expressive static type systems I think. It gets better quickly and then you won’t be able to go back, feeling existential fear without the compiler watching your back.
So your parent message contains a child message, containing some data that needs to get passed to the next view.
This is getting too particular for me to explain/help/argue directly. In our app, for example, the main app model is either onboarding, home screen or signed out. Then it makes big sense for the main model to accept messages regarding onboarding, home screen or signed-out state. And when it receives a message related to one of its child states, it just delegates it. This makes sense conceptually and is quite natural to follow when reading the code.
I am not an experienced Elm programmer, so maybe I am getting this wrong, but what we have has worked for us well, so far.
When I was a beginner, I found this extremely slow & burdensome. So much boilerplate!
Working in a huge codebase, I don't feel this pain at all.
I wonder if the beginner experience is off. When you add functionality to a huge application, the ease of threading through state is so much easier than just always winging it like I used to.
Did you look into Google App Engine, Heroku, etc.? Those were pretty seamless managed experiences for me, of course you pay for the convenience though.
Not really, those solutions weren’t quite flexible enough to do what we needed to do. Google Kubernetes Engine has been great though, not much more effort than something like Heroku but way more powerful.
