Just because we cannot prove something, doesn’t mean that we can treat strong claims the same way as proven hypnosis. If we cannot prove that UBI is overall beneficial, we just cannot believe it with the same certainty that we would if we had a bunch of studys on our side.
Look, I’m not saying that we have nothing - I’m just saying that what we have are educated guesses, not proven facts. Maybe “open question” was too strong of a term.
Well, you can conclude anything using your reasoning, but that does give the high degree of certainty that is sought after in the studies reviewed in the article.
Again, I’m not saying that I don’t believe static type checkers are beneficial, I’m just saying we cannot say that for sure.
It’s like saying seat belts improve crash fatality rates. The claim seems plausible and you can be a paramedic to see the effects of seat belts first-hand and form a strong opinion on the matter. But still, we need studies to inspect the impact under scrutiny. We need studies in controlled environments to control for things like driver speed and exact crash scenarios, we need open studies to confirm what we expect really is happening on a larger scale.
Same holds for static type checkers. We are paramedics, who see that we should all be wearing seat belts of type annotations. But it might be that we are some subset of programmers dealing with problems that benefit from static type checking much more than average programmer. Or there might be some other hidden variable, that we cannot see, because we only see results of code we personally write.
The original author does mention that they want to try using rust when it becomes more stable.
This is why any published work needs a date annotation.
Damn, this actually looks really good! Is there an estimate on when this will be useable-ish as a main phone for non-dev users?
Hindley-milner type inference for the win!
It’s hard to implement, but the result is a statically typed language, mostly without type annotations.
Because it is hard to design a study that would capture it. Because it is hard to control many variables that affect the “bugs/LOC” variable.
My conclusion is that it is hard to empirically prove that “static type systems improve developer productivity” or “STS reduce number of bugs” or any similar claim. Not because it looks like it is not true, but because it is hard to control for the many factors that influence these variables.
Regardless of anyone’s opinion on static/dynamic, I think we still must call this an “open question”.
Or post to gemini instead
Will read, looks interesting and I already agree with the premise but,
please people, add metadata (date, author, institution) and a bit of formatting to your pages. Not much, 10 lines of global CSS would help already.
deleted by creator
deleted by creator
What bugs do you mean? Anything serious i should know about?
I’ve tried nextcloud, it felt too slow.
Why would you want that all in one container?
I don’t want it, SeaFile provides only such conglomerate Dockerfile. And I didn’t have much success with writing my own Dockerfile for it. It’s terrible.
This is just what I need. A few months ago, SeaFile shat the bed and I just could be bothered to fix it. It’s deployment is a mess - a server, then a frontend host, a reverse proxy, a database - all in one container!
So I will try this out. I was contemplating building a thing like this myself, so I can contribute fixes/features too.
I use docker to package and deploy my website. When it is compiled to HTML, I place it into a docker container that is based on nginx.
This container is now easily ported to production server and ran to serve the HTML over HTTP.
Dan Luu. From summary of summaries: