Interesting. It’s definitely more abstract and philosophical than books like “Effective C++/Java/etc,” but I personally got a lot out of it and find it to be a really useful resource in code reviews. Particularly when commenting on the big picture and structural aspects, rather than just language-specific idioms or correctness.
While it’s true that difficult decisions need to be made, it seems that the point of democracy is that such decisions should have popular mandates. This reform doesn’t seem to have anything close to a popular mandate
This is a dumb way of thinking about democracy. People shouldn't quietly let politicians do whatever they want until their term is up, they should let them know that they are unhappy. If the government doesn't provide a way to do this, then there is no other option but to protest.
Government should be afraid of citizens, not the other way around.
This worked great during an earlier era. Insisting on 18th century political technology to solve 21st century problems in an era of instantaneous communication is a scam. Elections can be and are manipulated, and insisting that they are the sole legitimate form of political expression is a giant red flag.
Kind of a problem, imagine if a politician was elected to do something, then does something totally different, basically lying.
Who's going to stop him/her?
> Please don't complain that a submission is inappropriate. If a story is spam or off-topic, flag it. Don't feed egregious comments by replying; flag them instead. If you flag, please don't also comment that you did.
You pasted the guidelines yourself.
It includes the wording "most" and "evidence of some interesting new phenomenon."
In other words, it is not so straightforward.
It is left for the judgment of moderator.
In this case, election had global consequences which goes beyond many things in the recent history. We can see posts about war regularly on here, which are not flagged. And the war is only about politics by definition.
I dealt with a lot of the same issues around meaninglessness vs. golden handcuffs (at Google incidentally) and recently took a job at a smaller company, albeit without a pay cut. I specifically resisted switching jobs for several years for the same reason: having to grind Leetcode only to end up with the same alienation and cynicism. Turns out all that salary isn't just for hard work. Anyway, honestly, having now finally taken that step, I'll say that Leetcode isn't really a huge cost (you do it and then you're done for a while) and that simply working on new stuff does get you over one hump, namely the boredom. Not sure how long the new-stuff momentum will carry me past the possible onset of meaninglessness, but I'm trying to just adopt the "one must imagine sisyphus happy" mindset. Not a strategy but maybe at least a tactic? Happy to discuss further
Edit: I'm aware this is a very privileged situation to be in, honestly that doesn't help much with coping though and everyone wants to be happy. I seriously had just decided I never would be. Even that (temporary?) feeling is mind-blowing
Oh man, I read this article a few months back and it immediately resonated with me. I've never used Scala, but this advice has been applicable in every language, project, and team I've ever worked with, and I very much regret that I didn't already have this resource to cite in past code reviews.
A lot of the worst tendencies that developers complain about in complex programming languages (i.e. all of them, they're all complex) could be addressed by this advice.
They all CAN be complex, but I feel like Scala was designed to BE complex, to give a developer as many tools as possible to write complex code. Contrast this with Go which was designed to be simple, to give developers few options and few points of contentions. And it's not just the language, but the mindset of the developing community.
I mean in a future release of Scala, they will add generics - that, combined with higher-order functions, will allow for functional programming constructs like Option and operations like map, filter, etc - those are already possible, but the function they operate on has to be declared for every type.
But while that has really taken off in some languages and environments, it's heavily discouraged in Go - the runtime is not designed for it, it can't cleverly unroll and optimize it, and the function call overhead will make its performance terrible compared to a regular loop.
TL;DR while it is or will be possible, it conflicts with the principle of least power described here, and a number of e.g. Go proverbs and other wisdoms.
Yeah, no argument there. And I definitely like the Go community’s tendency towards straightforward code. But even there (among less Go philosophy-minded engineers, possibly) I’ve seen crazy abstractions built using interface{} that didn’t need that kind of generic code for the use case. Another one in Go is the nil/interface type interaction, for example. And this kind of thing can be hard to reason about, and that’s what I’m trying to say. All the languages have these complex and tricky bits and it’s best to stay away from them unless truly necessary.
I've done a few small projects in OCaml. It's a brilliant language that I deeply enjoy using. But the situation for newcomers and those who don't have established patterns is bad. It's hard to do anything nontrivial from scratch, and the community doesn't seem to have any consensus around dependency management, builds, project structure, and so on. Make and autotools may work for you, but it's not like your setup is on the ocaml.org homepage, reproducible by an application developer in five lines of shell commands.
It's common now in some language ecosystems for the default tooling to just generate all this stuff for you, and you move on to writing code. So if you're e.g. a JavaScript developer who is interested in functional programming, and you're used to npm or whatever, it's a difficult start.
The commenter I'm replying to uses an entirely different toolchain, and the frequently-recommended Cornell book (https://www.cs.cornell.edu/courses/cs3110/2021sp/textbook/) uses ocamlbuild and utop and makes no mention of Dune. If you (understandably) happen to land in the official OCaml manual at https://ocaml.org/manual/index.html instead of the page you linked to (which I can't find from ocaml.org, by the way, but you're right that the ocaml.org tutorials do mention Dune and opam), then you don't see Dune or opam mentioned at all. I get what you're saying, but I don't think you could disagree with the premise that there are parts of the OCaml ecosystem that a newbie would land in and be confused or misled by here.
That's fine, but if you go to https://ocaml.org/ and click the big 'Install OCaml' CTA at the top of the page, it takes you through installing opam, dune, and ocaml-lsp-server. And as per the latest OCaml Survey, it looks like the majority of the community are using opam and dune: https://docs.google.com/forms/d/1OZV7WCprDnouU-rIEuw-1lDTeXr...
Do some of the doc pages need to be updated? Yes. Do some universities take a long time to update their course materials? Yes. Does this mean there's no conensus? No.
There appears to be a rough consensus but it seems to have emerged relatively recently. I learned OCaml about two or three years ago and at the time the best tooling was Tuareg and Merlin in Emacs. Fortunately for me I love Emacs, but I found the Dune documentation poor and overall I got the sense that the OCaml production ecosystem (vs academic) is largely dictated by Jane Street these days, but the community is kind of quiet about the extent to which Core is the "real" standard library and the default stdlib is an academic curiosity. For one thing, the community seemed to be in a transition period between ocamlbuild and Dune, as the official resources recommended ocamlbuild and the community said everyone uses dune.
Yes, this is changing, and these changes have been ongoing since about 2013 when opam was created. But it's true that they're accelerating. I think it's reaching critical mass. so yes a few years ago I would say your points would be valid, but today they are less so.
Dune itself is only few years old. And there has been quite a lot of work on consolidating ocaml.org as a clear entry point for newcomers. But that is still an on-going work.
