ByteJockey

It's slightly more complicated in practice. The US has this weird system where you can opt out of full union membership and become what's called an "objector". You opt out of union membership but still pay a portion of dues (those directly around contract negotiation and the like), and you're still covered by the collective bargaining agreement. The downside being that, as you're not a union member, you generally don't get voting rights.

To quote the NLRB's website directly:

> Federal law allows unions and employers to enter into "union-security" agreements which require all employees in a bargaining unit to become union members and begin paying union dues and fees within 30 days of being hired. Employees may choose not to become union members and pay dues, or opt to pay only that share of dues used directly for representation, such as collective bargaining and contract administration. Known as objectors, they are no longer union members, but are still protected by the contract. Unions are obligated to tell all covered employees about this option, which was created by a Supreme Court ruling and is known as the Beck right.

This usually works well enough, but in certain circumstances, you can have a small minority control the entire operation and the vast majority are "represented" by an institution they have no voice in. This seems to be the case in lower paid unions (e.g. grocery baggers) because the majority can't afford the extra dues.

I appreciate the link, thank you.

Given the context of this thread (comparison of ruby and python), it should be noted that python also has this. You can decorate a method with `@property` and call the method without parentheses.

It's really nice because it means you don't have to pre-wrap all of your properties with accessor methods. They can just be properties, and if something changes, you swap the property out with a decorated method and you don't need to change any code.

> but I feel like it makes it very difficult to reason about performance

This seems like a form of premature optimization.

I mean, you're not wrong technically, but if you were exceptionally performance concerned, you probably wouldn't be using ruby.

If you're just regular performance concerned (i.e. you want to stop pathological behavior in the hot loop), you're really only concerned about 1-2% of your code. You wait until it's an issue, run a profiler over your code and optimize the couple of parts that are causing the issue.

They mention doing this a decade ago. They were probably using utilities to manage downloads from the ruby application archive (which would have still been around at the time) and automate running `setup.rb`

> Sure the water in that creek might be falling hundreds of meters, or even kilometers, but without a dam the height differential at your generator is only going to he a few metres at best. Enough to power the lighting, fridge, and washing machine in the houses that the creeks happen to run by, but not much else.

Could be, but that's a bunch of stuff you don't have to power with the existing system. Given how many creeks there are, that seems like it could really add up.

> With the advent of long lasting perovskites and (hopefully) some less polluting battery technologies you're not even better off cost-wise.

That's fair. I've learned in my life that I don't have a good intuition for what the costs of large infrastructure projects are.

That really depends on what percentage of water's potential energy is expended in small creeks and the like vs big rivers.

I actually have no idea how to estimate that. Anyone have a good estimate on that? Intuitively, I'm thinking that most of those rivers are fed by many small streams, so it would be approximately equal. I'm entirely unsure of that though so treat it as having huge error bars.

Wait... so the US army did poorly against guerilla combatants half way across the world, and therefore another country that lost in Afghanastan and a country that hasn't successfully invaded anyone that doesn't border them are a good match?

> Yes, I mostly see people saying that laws don't matter because billionaires are beyond law at this point.

Huh. Weird. Well, I don't see it brought up on HN all that often (once a month tops?), so we must hang out in different circles outside of here.

Anyways, you have a good one.

> They plan to use the exact same code!

Did they announce a change of plans? Their website just says that they have no plans for a borrow checker (i.e. it's not required to actually implement rust).

From the website for the project:

> There are no immediate plans for a borrow checker as this is not required to compile rust code and is the last pass in the RustC compiler. This can be handled as a separate project when we get to that point.

Link here: https://rust-gcc.github.io/

Wait, is that what you always see as the argument against it?

Whenever I've seen it brought up it's always that it would require a constitutional amendment (specifically in the US). The federal government isn't allowed to do taxes that way under the current system (Article 1 Clause 2 Section 3).

Hell, the feds weren't even allowed to do a straight income tax until the 16th amendment.

> It completely failed and SUV consumption skyrocketed and people stopped buying minivans and station wagons.

The government put fuel efficiency regulations on sedans in the 1970s. This effectively killed station wagons. The rules around light trucks were different though, and that's why the minivan was created.

The SUV is an outgrowth of the same thing.

> When people air opinions they're unwilling to change

That's the thing, there are a lot more positions these days that people seem to be unwilling to change.

If that were the case, you'd expect to see forking of 3rd party libraries rather than writing of new ones.

That may very well be. What's the windows support like/does it come with windows pre-installed?

I may personally hate windows with a passion, but if we're talking about the layman's definition of "PC", I think that's still a hard requirement. Especially this side of the "I'm a mac/I'm a PC" commercials.

I think ARM would be allowed, but for a layman to consider it a PC, you probably do need the windows capabilities.

> That political party's actions are about weakening the federal government so as to make it easier for large corporations to behave abusively, not because of trust.

Can you think of a reason people would do that if they didn't trust those corporations more than the federal government?

> I don't think Americans and American companies understand how little trust rest of us have for the American government.

Have you... have you seen our politics? What makes you think that we think other people trust our government? We don't trust our government. Hell, it's trusted so little that one of our large political parties is basically entirely devoted to making sure that the government can't get anything done.

> Water, air, chicken, dirt, star stuff.

God, the Captain Planet re-boot got weird...

For this to work, you'd need most of the code to be written by people who are paid (i.e. professionals).

In my experience somewhere between 50-80% of code at most places is stuff pulled off maven/npm/github/etc written by people who are completely uncompensated, and possibly as hobby projects.

You could censure devs pulling in unverified code, but so far as I can tell, the vast majority of devs are really bad at reading code. I'm doubtful it would change anything.

This seems like something that should maybe covered in a computer science curriculum, but most colleges seem to have an aversion to becoming "job training" centers. If they don't start teaching it, I'm not sure how you can expect people to have training in it. Do we need a training course outside the traditional university system?

> how is that not putting code in the driver's seat?

Because humans enter into them.

What you're describing is not a problem of the code making decisions for people, it's a problem of people not being able to back out of something once they've made the decision.

I think there's definitely an argument around if this is worth it or not, but it's a different issue. An issue that's akin to many decisions in real life. To take a dramatic example, this is akin to firing a gun. Once fired, a bullet cannot be taken back, but the bullet is not in control, but it is a situation created entirely by human agency.

I suppose the devs who create the software we're talking about would have some agency in the previous scenarios. But I wouldn't be nearly as concerned if the people in, say, the train car were entirely the devs that wrote the train car door automation software.

I guess the distinction I'm trying to make is people being forced into a situation vs people voluntarily entering a situation (even if they might not be happy with the situation later). In the former situation, I'd describe that as people not being in control, in the latter I'd describe the people involved as being in control.

It's considered to have ended (and possibly started reversing) in developed countries starting in the mid 1990s.

Your link even covers it: https://en.wikipedia.org/wiki/Flynn_effect#Possible_end_of_p...

> but that puts implacable emotionless code in the driving seat, and the article explains very eloquently why that's a bad thing.

To re-iterate my previous point, putting code in the driver's seat would imply that something like the etherium network decides what transactions to make (or possibly entering into their flavor of smart contracts by itself). I have not heard of any proposals for this.

> A deeply and clearly thought out argument for why immutable blockchains and code as law are terrible ideas, yet the conclusion is that crypto-anarchist technologies are a net good.

I think there's an important distinction between things like bitcoin and the technologies described in the article. The technologies mentioned in the article all take some sort of action without ongoing human input.

Things like bitcoin (and other crypto-anarchist technologies), on the other hand, preserve human agency. I mean, there's a lot of automation on the mining side of bitcoin, but the currency side allows trades to be initiated by human beings. Bitcoin preserves human agency so well that people using it to commit crimes is one of the arguments against it.

Now, you could argue that what I'm describing is a bad thing, or that the tradeoffs are unfavorable, or what have you. And there are several reasonable arguments in this area. But I think the distinction between technology that responds to human input and does work for us and technology that runs autonomously and makes its own decisions based on rules set up at a prior date is important here.

> Which is why punitive fines ought to scale with income and/or wealth

That really seems like it depends on what the damage a particular action causes.

Property destruction, for example, probably shouldn't scale. If I, accidentally, destroy your shoes, I need to buy you a new pair of shoes (and maybe a bit extra for your inconvenience). The goal is to make the victim whole again.

For things with the potential for loss of life, the goal is primarily deterrence, I think that's where things make more sense to start scaling.

Of course. You have a good day.

> What about the people who don't have that advantage?

For the text editor? For general help, they will probably google "gnome text editor help" or "gnome text editor docs" like I just did, which returns >80% results for the new application despite it not existing for very long.

I also tested this in a private window in case google is tailoring this to my, generally more tech heavy than normal, history. It immediately came up with this general rundown/intro to the editor: https://itsfoss.com/gnome-text-editor/ which covers installation and even how to view the list of keybindings.

For more specific features, they'd probably google something like "gnome text editor $FEATURE".

It's short for ex's visual command which would allow you to interactively edit text rather than edit with commands. You didn't have to type the entire command to get it to work, just the first two letters (though the long form did work).

vi was originally just a command that forced ex to open in visual mode.

> "Vi" is not "just naming the editor what it is", it's a relatively distinct short name that doesn't actually mean anything unless you know the reason for the name (which I did not for years after being introduced to it).

But "visual" is was vi is. That's its grand innovation. It took a lot of it's (non-motion) commands straight from ed, but let you see the entire page of text as you changed it. ed didn't do this because it needed to be conscious of teletype machines.

It's a direct abbreviation of ex's "visual" command (and used to just launch you into ex in visual mode), and everyone using it at the time would have known what it meant.

> If you don't know the relationship between the GUI name alias, and the literal process name, how are you supposed to figure it out?

Oh boy. If you do not appreciate doing deep lore spelunking to understand things, the unix/linux ecosystems are going to be frustrating for you. Half of our stuff still pretends it's operating on those old character based teletype machines I mentioned earlier.

> How are you supposed to search for info or help about "files"?

Do you have the same problem with the "fork" call?

I mean, yeah?

Are you new to internet drama? People use it to feel high and mighty for a couple weeks and get some sweet, sweet dopamine hits, and then they go back to doing exactly what they were doing before.