Shacklz

> without calculation, I can’t express the temperature outside in Celsius

I think you'd get used to it rather quickly if it becomes ubiquitous in your daily life. It's probably a little bit similar to when there's a change in currency or some such - like when the EU introduced the Euro. Someone here could maybe confirm from personal experience but my German and other EU friends all mentioned that in the first few weeks it was quite the headache, "is this price expensive or not", but after a while the numbers start to stick and make sense of their own.

> This is, in effect, one of the most common ways wealth is redistributed in the US. Why is it so bad?

Because the government could simply tax those with wealth more and use taxation as a means of redistribution. Like most western countries do.

Anand Giridharadas dissects this topic rather convincingly in his "Winners Take All", see also his infamous google talk: https://www.youtube.com/watch?v=d_zt3kGW1NM

From my point of view, this is one of those cases where structural typing just doesn't work all that well when used for OOP.

Typescript does give you a solution to this problem, namely that you use generics to constrain the parameters of your method:

    let append_animals = <T extends Animal>(animals: T[], animal: T) => animals.push(animal)

Your example now gives the expected error.

TypeScript does indeed have its quirks, but most of them do not really matter for real-life purposes or can easily be worked around like in the example above.

An intern's productivity sort of lies in "how fast they learn". Can they pick up things by just being pointed into the right directions or do they need everything spoon-fed, in small doses, with repetition, to then still get it wrong?

At least in our place, we do not really expect them to be productive in the usual sense, but they definitely have ample opportunity to give us a feeling of their place on the bell curve.

(as an anecdote: We currently have some 17 year old apprentice which puts some of our seniors to absolute shame, myself included. The amount of motivation, learning hunger, quick thinking and ability to ask the right questions is really astounding, especially given that he essentially just started and has next-to-no education in our area to speak of as of yet)

From a society point of view, it doesn't really matter "who" wastes it. Ultimately, the outcome is the same: Someone spends time on something that society does not benefit from.

... sidenote; I personally think that something completely inefficient "is not that bad". Much worse is work that is directly detrimental for society as a whole, even if it does make a few people rich. Now that is terrible.

As an alumni, thanks a lot for doing this. Looking back, all the things that I've learned in just the first few weeks in the industry made writing code so much more productive - if only someone had shown some of it already during some early semester, even just during some assistant teaching hour, it would have saved so many hours.

I remember specifically when one of the exercises for some compiler lecture contained unit tests the code had to satisfy, and I was like, wow, why didn't I already knew about this during algorithm classes earlier where I was fumbling around with some diff-tools to check my output. Let alone proper version control, now that would have been a blessing.

In hindsight, it's a bit embarrassing that I didn't bother to, well, just google for it, but neither did my colleagues - I guess we were so busy with exercises and preparing for exams that we just didn't have the time to think further than that.

> If you use any others and you are a normal developer, chances are you are overcomplicating things and should rethink your way of using git.

I strongly disagree with this one.

Git is one of those constants in our developer-live that is bound to stay for a long time. Probably longer than most other tech/tool that most of us use and learn on a daily basis.

The fundamentals of git aren't that complicated, the datamodel isn't any more complex than what you get taught in an introductory datastructure course. And once you understood it, you can leverage it to create an actually readable and usable commit history instead of the unreadable mess that your average enterprise project is. In my opinion, it's well-worth the trouble of taking an afternoon to understand git beyond the commands you've mentioned.

> The thing that is surprising to me is that people were so desperate for these horrible factory jobs for so long

We folks on HN (well, anyone who's even remotely related to tech) just tend to forget how good we have it. You might want to look up working conditions in meat plants, healthcare, warehouses, construction... in today's day and age.

Sure, it's not as bad as painting with Radium (although, back then they did not know how bad it is), the jobs might not be an immediate health hazard, but there are still plenty of people out there working under miserable conditions for terrible wages.

> You can, 99.9% of the time, emulate linear history with first parent history

Fully agreed, but that requires first of all to understand how this works and second requires you to run commands locally. If you're unfortunate enough to have to use e.g. bitbucket-server at work like I do, you'll always see the full graph, there which is A LOT easier to grok if it's linear. And since that's what's most devs look at (instead of git-log using some extra options) and also where CI-state happens to be reported (green/red build), that's worth a ton :)

> letting us do version control of our software with simple means instead of throwing everything at it

VCS is a pretty difficult topic, and it's not like git is the only tool out there (let alone the very first). Multiple people potentially working on the same file in conflicting ways is always going to be something that cannot just magically be made simple. After all, if there are no conflicts, "rebase" is literally the simplest command there is - just "git rebase origin/main" or whatever your equivalent is and you're good. It's only with conflicts where the fun stuff starts.

> It would have been easier to copy all the source files out, check out the branch I wanted, then copy them all back in.

That would be "git checkout -b some-branch" and then "git reset --soft origin/main" (or whatever branch you want to be on top of).

"reset" sets the pointer where you want it to be, "--soft" ensures that the actual files on your filesystem (the working tree) isn't touched. You will then have uncommitted files (your changes compared to the origin/main), that you can then recommit everything the way you want it.

reset --soft is my goto-recommendation for devs who have to satisfy a linear history but don't really care about git-history at all. Just do your changes as you normally would, using merge and whatever else floats your boat, and then once you're done, just use a soft-reset and then commit everything in one single commit. It's of course not ideal (meaningful atomic commits or some such would be better), but compared to having dozens of "fix stuff" and "merge from main" commits, it's definitely better.

I understand the sentiment, but since git is probably one of the longer-lasting constants in our industry (if not the longest-lasting constant), I personally think it's really worth to have a bit of a look into it.

Something I wish someone suggested to me years ago: Instead of trying to understand the commands, try to understand the datamodel. A branch is just a pointer to a commit, a commit is just a pointer (with metadata) to a tree, a tree is just... and so on. Once you understood this (which really isn't any harder than, say, understanding how quick-sort works), going from the data-model to the commands is fairly easy, almost intuitive if it weren't for all the convoluted options that each command can take.

Anyway, not trying to convince you or anything, just saying that I've been in your place a few years back, and wish I'd realized earlier how easy it actually is.

> And a linear history makes this much easier to analyze and understand, reducing cognitive load considerably.

This, so much this! And the price you pay for it is a slightly more difficult "insert". We started to enforce linear history in one of our bigger repositories (about 100 devs) about two years back; the first months were quite the ride (I had to do plenty of support-sessions to recover 'lost' changes). But the devs really started to see the benefits, and once they got the hang of it which was actually faster than I anticipated for most, it was smooth sailing. Many actually started to embrace it and advocate it for other repositories as well.

For me, it became also evident that filtering for people capable of learning git (rebase, cherry-pick, reset etc.) was very good at finding out who I'd want to work with and who not. It's really not that big of a deal, the UX of the CLI might be lackluster but the underlying datamodel is rather straight-forward. It's such a quintessential tool in our every-day-workflow that it's really worth putting a bit of time into understanding it, and if someone can't or doesn't want to, well, it might just be better if they work somewhere else than I do.

> If you're doing JS development, just use React.

I totally agree with your sentiment, but there are more frameworks out there with sufficient maturity to be considered enterprise-grade on the scale of react. Angular is certainly there, Vue as well at least in my book.

Probably some storybook-related issue, we also use it at work, and while it's a joy to use when it works it can be a pain to set up, and it does tend to need a bit more effort to keep it stable than one would wish for unfortunately.

ng is usually used in an AngularJS-context, which is the case here given the displayed code in their "Ng"-legacy-components

> The faux spontaneity is just so off-putting.

I think it would be really good educational material. Showing the silly dance that is performed removes all the glamour from the result, and might help alleviating the bad psychological effects that glamour is causing

> Are you prepared to do some very very fancy statistics?

I'd extend this with "... while understanding what you're doing?"

I've seen it so many times already, someone does some A/B-test and then presents a very fancy looking slide-deck with all kinds of crazy-looking math. But if you start to ask questions, it's all very obvious that they didn't really understood what they were doing and that very often it doesn't really matter to them in the first place; it's all about reaching a decision using some pseudo-scienty method that nobody dares to question because 'data' and 'science', without having to take responsibility.

You probably had some classes with Gutknecht at some point, who apparently contributed significantly to Oberon.

That being said, I'm in the same boat as you. I have definitely heard more about Oberon here on HN than at ETHZ.

> that he really focused on invariants

Oh the horror those classes were. Meyer is a great guy, and in hindsight I appreciate his ideas quite a bit. But the idea to take Eiffel for an introductory course, the questionable exercises (being encouraged/forced to write the code twice, once as invariant and once for the actual execution) plus the terrible Eiffel-IDE made those classes very easy to loathe.

Only if money is the only thing you're optimizing for, which isn't necessarily the case for everyone.

I once went for a job because of the money alone - it was the worst experience of my life and made me realize that money is not worth optimizing for beyond a certain point of comfort.

Fluent with Duolingo alone? Very unlikely in my experience.

From my point of view, you can make it to A1/A2 proficiency in a language with Duolingo alone - after that, it gets quite hard. Teaching grammar and conjugations isn't its forté, without resources outside of Duolingo it will get rather tricky.

That being said, I still use Duolingo for my daily dose of language exposure - but without Anki (for vocabulary), youtube videos (to explain various specific topics) and evening courses (which help a lot by giving a structured approach on what to learn in what order), my learning curve would probably flatten out.

Sure! I think Duolingo is fantastic to learn basic sentences and vocabulary. To reach A1/A2 proficiency, Duolingo is absolutely amazing in my opinion (I can only judge it for French though).

Once you go into the B1+ area, the usefulness of Duolingo starts to fall off, slow but steady - learning grammar and conjugations in all the different tenses isn't its forté. I think it's still very useful for repetition and constant exposure to the language, but without content outside of Duolingo, I'm not quite sure if it would work out so well.

For me personally, YouTube has been an amazing learning source for French - there are a lot of channels out there with tons of high quality teaching videos. If I had to name one, "Learn French with Alexa" is probably my favorite, but for a lot of topics it's very useful to watch multiple videos from different channels on the same topic, both as repetition and also because sometimes having multiple, slightly different explanations helps.

Since a few months, I do visit a weekly French course though - self study brought me only so far; reading already works quite well, listening so-so (depends on the talking speed), but I have a hard time speaking myself. It takes a very long to find the words, but the more I have to talk in course the better it goes.

One more thing: For purely learning vocabulary, I very much recommend Anki, it's amazing to just memorize words.

Ugh, this got a bit longer than intended, hope it gave you a bit of an overview of my approach :)

There's a setting to turn off the "ding" when you get something correct. I thought it's annoying, so I turned it off. Suddenly, the app felt very dull, and maintaining my streak felt hard - I kept forgetting to look into the app. So I turned it on again.

... Pavlovian conditioning works, even when I'm the rat. For the time being, I'm okay with that, because Duolingo does help me learn French, let's see how it goes long term.

> Even a small shortage of fertilizers will reduce food production such that some people are looking at starvation

This is only because we pretend that the free market can solve these kinds of problems. If it weren't for supply chains that optimize in cost efficiency and nothing else, these sort of problems don't necessarily have to exist.

As a Swiss GA holder - UK public transport is all privately owned, right?

The joys of free market efficiency in "public" transportation - maximum efficiency for the owners/shareholders, minimum efficiency for the people.

The Swiss SBB is also again and again under assault to be fully privatized, luckily so far this hasn't happened yet, and I hope it never will...

Nonsense. There's no surgery in the world which would make me lose my allergies and eczema problems, but a few edited genes before birth might just do the trick.

Or an acquaintance of mine with cystic fibrosis, who's been in and out of hospital for the vast majority of her life and knows that she probably won't make it beyond 40; she definitely wouldn't mind if someone fixed those mutations before she was born.

> This is a perfectly reasonable justification for having a foreground application.

Except when you start having multiple monitors. Then it's an utter mess, and I have no idea how the Mac-enthusiasts are putting up with it. And as far as I'm aware, most actually kind of don't - the few mac-enthusiasts that I know all use their customized setup that heavily relies on third-party-tools.

> And doesn't provide any money for future shows that you might enjoy.

Which means that dinosaur-industry would finally have to arrive in the 21st century. People are very much willing to pay for things they enjoy - see Twitch Subscribers and Patreons for examples. Paying for shitty catalogues where the parts that you actually enjoy are distributed across multiple services just isn't cutting it.

Good riddance to all those copyright-attorneys and other parasites leeching off of the entertainment industry.

Seems to work perfectly well in other countries, why should it not in the US?

Just make it so that it's only already 'prepared', you still have to sign them off or correct them if there's something wrong.