I’d pull the lever to kill one person immediately. Assuming the decision maker at each stage is a different person with different opinions on moral, ethical, religious, and logical questions, then it’s a near certainty that someone is going to pull the lever to kill the people at their stage. If you’re lucky, it’s the very next guy. If you’re not, it’s the guy killing a million people a couple of iterations later. If I’m the first guy, I’ll take the moral hit to save the larger number of people.
Exactly. If you have the means at hand, you have the responsibility to act. At the risk of taking a shitpost way too seriously, if you were in that situation and actively chose to leave the decision to someone else to kill double the people, then you acted unethically.
Technically the 2nd guy could just let it go through and nobody dies. However if it was to double over and over forever until it stopped, then technically the best option is to just double it forever. Nobody would ever die? If someone decided to end "the game" as it were and kill some people, then that's on them.
Yes, say there are 2^33 people for illustrations sake, by 33 decisions you (the first puller) are guaranteed to be dead too. At 32 it’s 50/50, the odds increase as the decisions get made. From a self preservation standpoint the best thing you can do to minimize your personal risk is pull the lever. It also happens to kill the fewest other people.
There are 1.3 million km of railroads in the world. At 200km/h, a trolley could travel them in little over 270 days.
Rearrange them in a circle and, providing everyone is cooperating for the sake of philosophy, there’s plenty of time to tie 8 billion people to the rails and run them over.
True, since we’re analyzing a hypothetical ethical question I shouldn’t leave any open assumptions. I made the assumption that at some point, at least one person will have to die, as in I see this trolley problem as a situation where at the end there is no choice and the maximum number of people die.
I think that’s bad logic. The choice everyone has is kill or not kill. I can’t be held responsible for someone deciding to pick kill when they have the ability to pick not kill.
Ok, and what does that actually mean for/to me? It’s not the same as intentionally putting somrone in a situation where both choices knowingly result in death. And even if was in this situation, wouldn’t it ultimately be the fault/responsibility of whoever set up the scenario to being with?
On the one hand, the possibility exists that the buck gets passed forever, especially as the kill count numbers grow substantially making the impermissibility of allowing the deaths grow with it. It’s not likely the any given person would kill one stranger, let alone millions.
On the other hand, in an infinite series, even something with miniscule odds will still eventually inevitably happen, and some psycho will instantly become the most infamous murderer in history, followed immediately by the person that didn’t just kill one person and end the growth before it started.
Now if we assume the victims tied up are frictionless orbs, and the train is also a frictionless orb, and the two of them are travelling in a frictionless void than I reckon we could kill a few more.
But then would they die if they don’t slow the train down? The train would necessarily have to impart some energy in order to effect a change in their bodies.
I mean if you’re going fast enough with a pointy train, you could chop up people pretty easy. You just need to make sure that each person is a tire width apart to make sure the wheels don’t lose traction. Assuming a person is roughly half a metre across and a tire is 75cm in diameter, we get 1.25m per person, so a track of 1250km for a million people. Not very long at all.
I agree with your logic, so far as it goes. However, there are, currently, just over eight billion humans in existence. If my quick, over-tired math is correct, that means only 34 people have to say no, until we run out of people to tie to the tracks. Assuming, at that point, the system collapses and nobody dies, I’d guess 34 people would refuse - might be the better choice.
Would you trust the entirety of human existence to be decided by 34 people? In my experience from watching reality TV, the last one always screws the rest over for their own benefit.
Imagine being the last one. You could singlehandedly wipe out half the global population. This would normally be a bad thing, and it is, but it would also make every surviver twice as rich, solve food scarcity and halve the pollution, perhaps even saving humanity from itself.
If that’s not enough, think about everyone now having double the amount of kittens and half the traffic on the roads.
I’m not sure reality TV is a good basis, it’s very manipulated and set up for drama. I have a lot more faith in humanity in general than I do in reality TV stars. But you still have a good point, it’s definitely not a sure thing.
Society and the economy are not a zero sum game. Killing half the population wouldn’t make the survivors twice as rich. It would send society into chaos which would make the remaining people’s lives far worse.
Oh yeah. I was assuming an infinite series (somehow). Also, odds are good that out of 34 people, one of them would misunderstand the rules or be crazy enough to do it anyway for various reasons. I’d probably still do it.
I think this is a good metaphor for how humanity has “dealt” with problems like climate change.
If you make a tough decision, it causes hardship now, but prevents hardship in the future. If you don’t make a tough decision now, someone in the future has to either kill a lot of people, or just pass the buck to the next guy. People justify not making the tough decisions by saying that maybe eventually down the line someone will have an easy decision and there will be nobody on the side path, even though all observable evidence says that the number of people on that path just keeps growing exponentially.
But what if you’re the tenth person with 1024 on the line? Or the 20th person with 1,048,576? Etc. Is there ever a point (before it’s everyone, in which case risk doesn’t increase) where you stop pulling it?
I’m sorry Timmy but you’re not allowed to have any dessert unless you close your tags like I taught you. Your grandmother was XMLish and you need to carry on our family tradition.
I thought you might do something like this so I got you a backup one from AO3.
TIL. Funny thing, though, is that they give an example of how to use <br> and have it with trailing slashes. And then explain that trailing or preceding slash will be ignored, anyway ¯_(ツ)_/¯
The actual thing that matters is that the / is ignored so (unlike with XML I believe) you can’t self-close a non-void element by adding a trailing /. But “void elements should not have trailing slashes” is extrapolation on your part; the trailing slash improves readability and is kosher since it doesn’t act as a self-close.
HTML parsers only allow this to stop pages breaking when developers make mistakes; see this Computerphile video. ‘Able to be parsed correctly’ is not the soul criterion for it a syntax being preferred, otherwise we would all leave our <p> elements unclosed.
Yes, it is not “incorrect” to write <br/>, but it is widely considered bad practice. For one, it makes it inconsistent with XML. Linters will often even “correct” this for you.
I personally find the official style (<br>) to be more readable, but this is a matter of personal opinion. Oh, and I used to have the same stance as you, but I also used to think that Python’s whitespace-based syntax was superior…
At the end of the day, regardless of anyone’s opinion, we should come to SOME consensus…and considering that W3C already endorses <br>, we should use this style.
“readability” is subjective. much like how there is no objective definition of “clean code”. i am not arguing that either option is more generally “readable”, i am insisting that people use a common standard regardless of your opinion on it. a bad convention is better than no convention. i dont personally like a lot of syntax conventions in languages, whether that be non-4-space indenting, curly braces on a new line, or early-declared variables. but i follow these conventions for the sake of consistency within a codebase or language, simplicity on linter/formatter choice, and not muddling up the diffs for every file.
if you want to use <br/> in a personal codebase, no-one is stopping you. i personally used to override every formatter to use 2-space indenting for example. but know that there is an official best practice, which you are not following. if you work in a shared codebase then PLEASE just follow whatever convention they have decided on, for the sake of everyone’s sanity.
if you work in a shared codebase then PLEASE just follow whatever convention they have decided on, for the sake of everyone’s sanity.
That goes without saying; I’m not a barbarian.
“readability” is subjective. much like how there is no objective definition of “clean code”.
Did you not see the part where I said it’s less readable “in my opinion”?
i am insisting that people use a common standard regardless of your opinion on it.
I can read this one of two ways: either you’re making an assertion about what people are currently doing, or you’re telling me/others what to do. In the first case, you’re wrong. I’ve seen many examples of self-closed <br> tags in the open source projects I’ve contributed to and/or read through. In the second case, IDGAF about your opinion. When I contribute to an existing project I’ll do what they do, but if I’m the lead engineer starting a new project I’ll do what I think is the most readable unless the team overwhelmingly opposes me, ‘standards’ be damned, your opinion be damned.
The spec says self-closing is “unnecessary and has no effect of any kind” and “should be used only with caution”. That does not constitute a specification nor a standard - it’s a recommendation. And I don’t find that compelling. I’m not going to be a prima donna. I’m not going to force my opinions on a project I’m contributing to or a team I’m working with, but if I’m the one setting the standards for a project, I’m going to choose the ones that make the most sense to me.
It’s not extrapolation on my part, the HTML spec is pretty direct about it:
Then, if the element is one of the void elements, or if the element is a foreign element, then there may be a single U+002F SOLIDUS character (/), which on foreign elements marks the start tag as self-closing. On void elements, it does not mark the start tag as self-closing but instead is unnecessary and has no effect of any kind. For such void elements, it should be used only with caution — especially since, if directly preceded by an unquoted attribute value, it becomes part of the attribute value rather than being discarded by the parser.
For example, in the case of <div/>Some text, browsers interpret this as <div>Some text</div>, treating the slash as ignored and considering the div element to encapsulate the text that follows.
You should never rely on a browser interpreting a non standard use in a specific way. It can change at any moment, and wouldn’t be reliably reversed because it’s inherently non standard.
It’s actually more confusing/less correct to close bodyless elements in HTML. Since HTML treats “/>” the same way as “>” which could lead to a “/>” tag not actually being closed, if it is used on a non-selfclosing tag.
There was this mini golden era around 2019 or so where it really seemed like Windows was getting their shit together. I think a lot of places use Macs for development now and Windows was trying to get that market share back. Stuff like the new console and WSL were amazing.
Yeah I swear from when Nadella took over until like 2 years ago, Microsoft really seemed to be on the right route. They were becoming the “good guys” of big tech companies.
WSL, actually being really good stewards of GitHub, Chredge actually (at first) being way better for users than Chrome, the amazing revitalisation of some of their oldest and most loved game franchises like Age of Empires and Flight Simulator.
But then recently we’ve had Microsoft adding shitty AI to everything, from Edge to Windows. We’ve had that AoE revitalisation tarnshined by showing off a really shitty official mobile game with all the makings of a typical pay 2 win time sink. The Age of Mythology remake has obvious AI art featured in it despite them insisting no AI was used (though thankfully the actual gameplay is as good as hoped for, at least). We’ve got large layoffs and other shitty corporate bullshit towards workers.
It isn’t bash, it’s Linux that’s well-embedded with the rest of Windows. You can get most Linux stuff working reasonably well, and you can even get a working GUI of some distros.
It works well - for a Windows subsystem. It is well-integrated but also separate which can be annoying sometimes.
For example, you might code in Python in VSC against a WSL folder but make a script to eventually run in Windows. You need to install and update Python twice then - a Linux and a Windows version (obvious, but can be annoying).
WSL is also really slow, especially for filesystem heavy stuff. You know how on Linux programs sometimes run faster via Wine/Proton than on Windows itself? Yeah, this is the other way around.
Honestly the type of stuff I do works good enough with MSYS through Git for Windows (which is a basic bash environment). There are three ways to get bash on windows,
MSYS/Git for Windows: Lightest choice. Least capable. Very easy to set up.
Cygwin: Only works with Linux stuff made for Cygwin. Pretty useful all in all but really weird to set up. Babun was my favorite way to use it.
WSL: The most Linux like but at the steep cost of being very disconnected from the Windows side. It feels more like a VM than a shell sometimes.
I preferred the simplicity of Git for Windows and Cygwin. Now, if I still had Windows on a work computer I probably would’ve deep dove into WSL and figured it out more.
Most useful things i found in wsl that made it not feel like a vm is knowing the wslpath command, and the fact that it can execute any exe such as explorer.exe (which works for even wsl directories). those two things let you use sed/grep/awk on files in windows and execute any exe on stuff in linux.
We tried to onboard two devs into our project earlier this year with it and it was not good.
We spent 4 days trying to get it to work, and had all kinds of problems from VPN not working, DNS not working and compile times being 20x slower (as I later learned, you’re not supposed to use your Windows NTFS partition inside of it). Partially, this has to do with our corporate environment being annoying, but it simply being different from a normal Linux in this regard is still annoying.
On the fifth day, we set up a Linux VM with them and they were ready to work in an hour.
It was earlier, when they released Windows 7 and it was the first (and only) release, management gave development a largely free hand and they could bring down some technical debt.
But apparently that didn’t work out for Microsoft and now we get one dystopian news after another.
Oof, slow compile times to target, of all things, the JVM? Implicit methods? Some(null)? Function call syntax where the difference between a tuple argument and a sequence of non-tuple arguments can be determined by whether or not there’s a space before the parentheses?
There are definitely some major issues with Scala.
I think that’s good when the objective is to improve the language. One key thing that holds many languages back is that they’re stuck with historical baggage, and it can be pretty difficult to replace/remove “outdated” stuff without breaking everything.
I do not want to be stuck using Python 2, or Scala 2 (although there exist people who use Scala 2 instead of Scala 3).
Where I’m working we’re heavily using Spark, which kind of blocks us from upgrading. There seem to be ways to get Scala 3 to work, but we also have old terribly written baggage code no one understands. Just upgrading between 2.12 to 2.13 was a journey.
I agree that the slow compile times are pretty bad (maybe even deal-breakingly for large projects). I think it’s kind of necessary for a language with as powerful of a syntax as Scala though, it’s pretty absurd how expressive you can get. Maybe if it didn’t target the JVM, it’d be able to achieve way faster compile times – I don’t really see a point of even targeting JVM other than for library access (not to say that that isn’t a huge benefit), especially when it has relatively poor compatibility with other JVM languages and it’s nearly impossible to use for Android (don’t try this at home).
Even more so, I think that null handling isn’t nice – I wish it were more similar to Kotlin’s. One thing I’m really confused as to why Scala didn’t go all-in on is Either/Result like in Rust. Types like that exist, but Scala seems to mostly just encourages you to use exceptions for error propogation/handling rather than returning a Monad.
A more minor grudge I have is just the high-level primitive types in general – it’s pretty annoying not being able to specify unsigned integers or certain byte-width types by default, but if it really is an issue than it can be worked around. Also things like mutable pointers/references – I don’t actually know if you can do those in Scala… I’ve had many situations where it’d be useful to have such a thing. But that’s mostly because I was probably using Scala for things it’s not as cut out to do.
With the tuple arguments point, I get it but I haven’t found it much of an issue. I do wish it wasn’t that way and it consistently distinguished between a tuple and an argument list though, either that or make functions take arguments without tuples like in other functional languages or CLI languages (but that’d probably screw a lot of stuff up and make compile times even LONGER). I saw someone on r/ProgrammingLanguages a while back express how their language used commas/delimiters without any brackets to express an argument list.
I think an actually “perfect” language to me would basically just be Rust but with a bunch of the features that Scala adds – of course the significant functional aspect that Scala has (and the clearly superior lambda syntax), but also the significantly more powerful traits and OOP/OOP-like polymorphism. Scala is the only language that I can say I don’t feel anxious liberally using inheritance in, in fact I use inheritance in it constantly and I enjoy it. Scala’s “enum”/variant inheritance pattern is like Rust enums, but on crack. Obviously, Rust would never get inheritance, but I’ve found myself in multiple situations where I’m thinking “damn, it’s annoying that I have to treat <X trait> and <Y trait> as almost completely serparate”. It would especially be nice in certain situations with const generic traits that are basically variants of each other.
Plus, I’ve always personally liked function overloading and default arguments and variadics/variadic generics and stuff, but the Rust community generally seems to be against the former 2. I just really hate there being a hundred functions, all a sea of underscores and adjectives, that are basically the same thing but take different numbers of arguments or slightly different arguments.
The custom operators are a double-edged sword, I love them and always use them, but at the same time it can be unclear as to what they do without digging into documentation. I guess Haskell has a similar problem though, but I don’t think Scala allows you to specify operator precedence like Haskell does and it just relies on the first character’s precedence. I would still want them though.
How it goes now, though, is I use Scala 3 for project design/prototyping, scripting, and less performance-sensitive projects, and Rust for pretty much everything else (and anything involving graphics or web). Scala has good linear algebra tooling, but honestly I’ll usually use C++ or Python for that most of the time because they have better tooling (and possibly better performance). I would say R too, but matplotlib has completely replaced it for literally everything regarding math for me.
Sounds like we’re actually in agreement about most of this.
I’m okay with languages limiting their “expressive” power in order to provide stronger correctness guarantees or just limit how “weird” code looks; but this is largely because I’ve worked on many projects where someone had written a heap of difficult-to-understand code, and I doubt such limitations would be appealing if I were working strictly on my own.
I also don’t really see the appeal of Java-style inheritance, but to be honest I didn’t use Scala for long enough to know whether or not I agree that Scala does inheritance “right”.
It does make sense that Rust provides mutability in some cases where Scala doesn’t. Rust’s superpower, enabled by the borrow checker, is effectively “safe mutability.” I hope other, simpler languages build on this invention.
(Jokes aside, all programming languages have their good and bad things. Some just have more bad than good. And i say that as a C/C#/typescript/asm developer :p
Even if you do design clean modular code and document it, you’re getting a question a year from now about how it works, or someone just duct tapes on top of it.
I’ve even experienced this in the 3D printing community, where I design a highly parametric model and put lots of effort into making all of the major dimensions and qualities parameterized and dynamically adjustable, with lots of bounds checking and value clamping, with all the parameters at the top of my scad file with comments explaining what each variable does.
And then someone comes along to remix my model, says I don’t want to install openscad, and just scales the entire output stl to change the dimensions, squashing all the features of the model in the process (instead of having the size gracefully adjust with all the features moving around to account), and leaving anybody starting from their work with a hard to remix mesh with no parameters.
Working with devs who aren’t familiar with design patterns, introducing design patterns by simply implementing them (in a new project) allows it easier for the devs to follow the implementation as examples, even though they aren’t necessarily familiar with the design pattern concepts.
At least they can observe the patterns and replicate the patterns elsewhere.
In my experience, this often doesn’t happen. So many developers are either inexperienced or cowboys, and there’s nothing inherently wrong with either. But at places where projects are small and numerous, teams often end up with nothing but a combination of the two.
As one of our office’s engineering “fixers”, I’ve taken over maintenance of several such projects. They usually have shattered remnants of code taken from other projects, open source libraries, internal libraries, stack overflow, and so on. Whole source files copied into the project, modified in ways that introduce impressive new failure cases while failing to add new functionality, and used in ways that completely ignore the features natively implemented in that code while those same features are bodged in as barely-working piles of if statements, balanced on a knife’s edge to avoid triggering the failure modes added by the project’s modifications of the copied code. I’m usually able to purge 20-30k lines of code from such projects in the first month, simultaneously closing multiple outstanding issues the PM had been led to believe were intractable.
That probably sounds like arrogance and/or shitting on everybody else’s work but it’s just reality at many workplaces due to a pace driven by unreasonable expectations from management. I just happen to be the person here that ends up sifting through the wreckage when a project reaches the inevitable osteoporosis phase, because of a natural disposition for reverse engineering. It would be great to escape for this and other reasons, as far as I can tell, most places aren’t that different.
This can work for junior devs who aren’t stuck in their ways. Unfortunately there are too many “senior” devs who are happy making crap. It’s hard to fight them constantly to do things properly (e.g. write actual commit messages rather than just “Fix #836”) so using tools like linters where possible is definitely a big improvement.
Or business decides all specs and design decisions that were made last quarter were actually garbage and yes we do want to be able to manually override every step of the carefully designed state machine. We’d like to be able to manually change all calculated sales data, but also the data needs to remain in a consistent state at all times. Oh and while you’re there, we decided the commission calculations will use a different system from now on. We expect it to be online by the end of the week, thanks.
The ‘document’ part also seems to be insanely hit-or-miss from my amateur experience. Self-documenting design/code is… well, not. Auto-generated documentation is also usually just as bad IMO. Producing good documentation really is a skill in and of itself.
Also small personal opinion: If your abstraction layers or algorithms are based off a technical concept, you should probably attribute that concept and provide links to further research, to eliminate future ambiguity or in case your reader lacks that background. Future you will probably thank you and anyone like me who immediately gets lost in jargon soup will also be thankful.
No you just do a rebase to bring it in. Assuming you’re making atomic commits you shouldn’t have a ton of merge conflicts. If you have to do this a lot, your branch scope is really bad and the problem isn’t in how you’re using got, it’s in how you’re slicing work.
If you try to pull someone else’s rebased / history rewritten branch, your git will tell you that it’s rejected. You can completely avoid this by merging instead of rewriting history.
You don’t pull rebased work pretty much ever. Rebasing is for feature branches by a single author to craft a high quality history, generally. It’s much, much better than littering your branch with merge commits from upstream.
If for some reason you do need to pull rebased changes, you simply do git pull --rebase. Works without issue.
programmer_humor
Top
This magazine is from a federated server and may be incomplete. Browse more on the original instance.