Threads for reezer
-
I think the vocabulary here is very confusing. Let’s be clear: these words have definitions (I’ll just take Wiktionary):
- Product: Anything that is produced; a result.
- Project: A planned endeavor, usually with a specific goal and accomplished in several steps or stages.
In the context of the software industry, these definitions apply as in any other context: for example a team may have a Project of adding a new feature to a Product.
The difference between a Product and a Project is not:
- Product is easy to use while Project is not
- Product is a commodity offered/sold by a corporation to make money while Project is volunteer work aiming to save the world from corporations
Mastodon is a Product. It is produced by human work. You can just register to an existing instance. The fact that you can host it by yourself in your own terms is a feature of this Product.
Think of Mastodon as a vegetable you get from a local farmer: it’s a Product (it’s been cultivated by a human), but it will require more work than an already-cooked dish, but when you’ll have finished your Project of cooking your meal in your own terms, it will be delicious.
-
Product: Anything that is produced; a result.
Sure, but I’d argue that this a rarely used definition. By that definition there isn’t many things physical, virtual and abstract that are not a product.
While correct going with this definition is not helpful in pretty much any form of conversation. Like many other words that can mean pretty much everything by their definition.
A company producing computers might also produce a waste, sewage, paper trails, broken dreams, anger, yet only one of these things is likely considered their product.
There is many scenarios where the meaning/usage of some word doesn’t match the first definition in a dictionary. And with philosophical and abstract discussions it’s even more common.
That’s why you define words in the beginning. You also do that in laws, contracts, etc. And it was done in that article.
I’d argue that putting product in contrast to project as well as the topic and context make that word an okay choice.
-
I think I agree with your remark: my comment insists too much on definitions, while my initial intention was “just” to say that the vocabulary used in the post was misleading.
And I think it’s misleading because it fails to say what polished/funded/all-inclusive Products bring compared to volunteer-work/FLOSS Products: commodity. Obviously commodity wins, because we made our world crazily fast, but I think it also wins because most people don’t know what the tradeoffs are (mainly privacy, but also the environmental footprint of giant servers mining data for the sake of targeted ads).
So I’d say that the main answer is, as usual, education (of all forms: as soon as possible at school, at work, within families, etc.). If “people” knew what they are dealing with when it comes to big corp products, maybe they would consider making the effort of using less polished products, of maybe even they would consider helping make these products better (give feedback, time, money). This is the idea behind the last sentence of my comment: when “people” know more about the benefits of local/raw food, they make the extra effort of buying less transformed food. I believe the same could apply to tech products.
-
-
Stephen Walli gives a great talk on this subject, though his definitions are a bit different. A project is the thing that has a pile of code that it maintains and some infrastructure surrounding it. A product is the thing that people use. With this definition, the claim in the article is a tautology.
The key message from Stephen is that the two things are different. The product can’t exist without the project (so, if you want to sell the product or things built on the product) then you need to ensure that the project is healthy. Conversely, the project is not the thing that you want users to depend on.
For a lot of open source projects, the line is a bit blurry. The project is the thing in the GitHub repo, the product is the thing in the releases tab. For others, the product is the result of some integration. His go-to example is Moby (the project) and Docker (the project). This one is interesting because most people who say that they want Docker actually want some packaged version of Moby.
-
My hot take is: the more structural issue is the lack of clarity into how decisions are made. I would like to see working groups or similar in Ruby.
-
TBH, I am not so sure about this (I went at great lengths investigating this feeling last year). I mean, “normal” language development process would’ve probably felt more controlled and reliable for language users, no argument here, but I am not sure it could’ve led to a better language.
But that’s complicated! (When some features are merged a week before release without much discussion, I definitely think many different thoughts.)
-
I agree. Quire a few languages and projects face the problem of filtering too little with such an approach leading to bloats and lots of barely used and therefore badly maintained features that might be deprecated or slow development down.
Often times the structure is that you gave to create a quality proposa, followed by something like a vote (if even). So there’s a clear path for adding something that is hyped, but it’s not so easy to say no, especially not if the reason is more complex or is about keeping the language simple, or the style or also when there’s cases how a feature can and will be abused in the sense that code will become non-idiomatic. This is worse when a language grows in user numbers and a lot of people come in from other languages that don’t learn, maybe don’t want to learn or disagree with idioms (for example when the job demands it).
This is a pattern of events that many languages go through and usually the “solution” is picking up the next language that still is simple. Until there all of this happens again.
When non idiomatic solutions take hold and widely used libraries work that way the case for new proposals is created so this process reinforcemes itself. So there’s a lot of context, sometimes in time and while of course not all decisions in the past will have been good some might have been good in the context of the time, and when the language changes enough that it feels different you’ll have “warts” on a languages, weird parts that now one should never do.
All of this is pretty bad in my opinion because you end up with a language and especially its ecosystem maturing, but the language and some older bigger libraries and code bases being monstrosities because they had to shift with how the language evolved over time.
All of that of course was done with best intentions. But it leads to this pattern repeating.
-
I think that both can be true. What got us to the great language we have now may have needed to come from one person’s oversight. What gets us to the next level doesn’t necessarily have to look like what got us here today.
Maybe “working group” is too strong. Perhaps just more explicit invitations on how people can get involved. My PRs to Pathname are getting no reviews. Meanwhile I’ve gotten practically zero contributor interest in others contributing to syntax_suggest (my default gem).
Cohorts, mentoring, and mutual (code) aid could all help.
-
-
-
I wonder what they hope to achieve with that. I always do when someone adds telemetry. So far I haven’t seen a convincing answer.
-
Stuff I, as a developer, used telemetry for in IntelliJ Rust:
- Crash reports. They are sort-of-different from the telemetry, but also are the same.
- Figuring out what to focus on. Eg, if a lot of people use IntelliJ Rust with PyCharm, it makes sense to spend some time integrating into PyCharm-specific project view.
- Figuring out when to drop support for old platforms. If only 5% of users are on a particularly old IJ, plug-in can stop supporting it.
- Getting personal moral boost from seeing the number of installs going up
- Justifying continuing investment into the project by the company
I didn’t use fine-grained telemetry for specific features, as, at that time, barely anything was working at all.
-
It doesn’t really say they do that. Ending the experience feels different than finding hugs. It could mean both though but without a precise description of how data will be used all bets are off.
For what makes sense and what people want interacting with your users, etc. tends to give more insights info the whys. With telemetry one ends up having to guess
You could just count downloads. You could also describe better what your telemetry is on. I think people would be fine if you specified something like well report your version when you log in through our extension.
And for general stats about how much sense continued investment makes sense wouldn’t downloads and paying users be enough?
I really want to emphasize here that you could just make a l list of what and why you tell it. You likely have that internally anyways. Why not publish it unless it’s something you don’t want your users to know? Sure it might be a bit of effort but it could almost be seen as marketing/gaining trust.
-
-
-
-
From what I’ve seen in my professional life (as a product manager, thus making decisions about features), this is telemetry goal but, unless done at a Facebook scale where you truly experiment with a very large user base of “identical” users, it’s bullshit.
— Following the data, we could remove A.
— Wait, if you remove A, it breaks B.
— We could also remove C.
— No, C is the pet feature from the CEO.
— So let’s remove D.
— Ok.
— …
(phone rings)
— It’s our biggest customer. He’s angry we removed D. The CEO is using the feature once a year but it’s important to him.
— Sigh.…
— So let’s remove E
— Hey, no way, I did E, I like it. I’m simply blocking the telemetry.I’ve never seen telemetry data being useful. You need to use it in conjunction with user survey and interviews. Oh, guess what? Once you take the time to do proper user interviews, telemetry are mostly useless.
And the cost associated with telemetry is very high: you need to maintain the telemetry infrastructure. You augment the risk surface (remember when OSX was bugging because it was trying to phone home?). You need to keep this data reliably to avoid any privacy breach. You need to sort this data, to analyze it. The cost is important.
Which means that when a product add telemetry, there are only two options: either they are doing that “because everybody does it” or they have some way to recoup for the high cost. Which is rarely a good thing for the end user.
Fortunately, in 1password case, I switched to bitwarden years ago and bitwarden is cheaper, simpler, opensource multiplatform and works even better for me.
-
-
without aggravating too many users
Without aggravating the users who leave telemetry enabled, you mean.
-
The first thing that comes to mind is to check which features they could drop without aggravating too many users.
I would simply not remove features.
-
While admirable, that is not ultimately a sustainable policy depending on market factors.
-
-
-
-
-
With these things I always wonder how much it makes the “market share” statistics plummet. There is such features, there is extensions, there is a correlation of Firefox and privacy minded people, there is a correlation between the websites and mechanisms market share statistics use and the websites that Firefox users actually visit.
The Wikimedia stats seemed like a good indication of actual usage shares, since it’s tracked on the server side and because it’s a reasonably sized/used/famous website.
-
Link to Wikimedia stats: Wikimedia Foundation Browser Statistics – All Sites by Browser. In the last 30 days, 4.3% of requests used a Firefox or Firefox Mobile user agent.
-
-
“I don’t care about cookies” extension also works pretty nicely:
-
Not really. That accepts everything automatically, which is pretty much the opposite of the right thing, especially because you’re accepting a full privacy policy, not just allowing cookies.
Consent-O-Matic is better: https://github.com/cavi-au/Consent-O-Matic
It also seems to be better than the feature described in the OP, which can only do “reject all” or fall back to “accept all” if you set it to do that (why???)
-
I uninstalled I don’t care about cookies and switched to Consent-O-Matic when they got bought by Avast.
-
I wish Mozilla would just mainline Consent-O-Matic; its behavior is a reasonable default.
I mean don’t get me wrong; I’m glad we have the ability to do this in extensions, but it’s a shame we have to.
-
Fair enough. Although I’m also using Cookie AutoDelete: https://chrome.google.com/webstore/detail/cookie-autodelete/fhcgjolkccmbidfldomjliifgaodjagh?hl=en, so I really don’t care if they gather my temporary one-time cookies :), I just don’t want to see these annoying cookie banners.
-
Agreeing to random privacy policies means you’re agreeing to a lot more than just storing some cookies you can delete later. Cookies are not, and never were, the real problem.
-
I think the “real problem” is different for different people.
For me, the “real problem” is that if I would care about all the privacy policies of all websites I visit each day, I wouldn’t have the time to do any work nor to read any articles. Yesterday alone I visited 26 different websites, and by looking at the domain names alone, for most of them, I wouldn’t be able to tell why I was even there. We can also argue about what is the definition of the cookie rejection action, and how does an “essential cookie, without which the website can’t work” work, because not knowing how the law defines these, we can’t make an informed decision if we want those things to happen, or not.
If we say that a cookie is required for basic use of the website, then what does it mean? I think in order to be sure, we have to read the GDPR official legal texts, and even if we’ll gain that knowledge, we will need to decode lots of legal documents that define how the law makes sure that GDPR is even followed, what is the legal enforcement mechanism, and what is the risk that the website will illegally (by omission, or by intentional action) mis-use “essential” cookies for marketing purposes. Because if I check “use essential cookies only”, I implicitly trust that some random website is following the law, which is a bit naive in my opinion. This is also a real problem for me.
The cost of managing the privacy policy of one-off websites is simply too high. You have to use a shortcut somewhere. I choose to go there right at the beginning of that path, because I don’t believe GDPR is designed with users in mind; it’s a part of some shady business, and someone wants to make money off of it. I refuse to pay the price with my attention.
-
The problem that @robert_tweed slides to is that you are not granting consent to cookies. The law was never about cookies. The consent is required to handle and process information about you. Cookies are one mechanism that may be used for this but the site can also use a mix of IP address and browser fingerprinting to fairly accurately identify you as an individual. By consenting and clearing cookies, you are granting them a legal framework to collect this data and share it with third parties for a very broad range of purposes. In comtrast, if you reject tracking then you have denied them the legal framework to justify this and that opens them to the 5% of global turnover fines that the regulator may apply, which any moderately sane company will consider far too high risk.
-
-
I don’t think this comparison is apt. It would be more like: every stranger I meet asks me to take my picture. But in order to decline, they hand me over a short book of regulations, each stranger with their own rules. I need to read and understand those regulations to know how to decline the request. So I choose to wear a mask and allow myself to be photographed. They have a photograph of my mask instead of me, and are free to use that as they see fit.
-
-
-
No, it’s like someone comes up to you and and says they want to put a wrist band on you. To do so, they ask you to agree to a contract that gives you consent for them to track you using any means that they wish. They then give you a bright shiny wristband that you throw away and they track you with CCTV cameras and drones.
-
That’s not what’s happening though. It’s not the wristband (the cookie). It’s that effectively all means they want, your IP, ETags, browser fingerprinting, and most likely a combination of these are legally used if you consent. Even if you delete everything you still have the IP, and if you somehow hide/switch that you still have browser fingerprinting.
It’s a lot more like have a camera drone following you, watching you discarding your wristband, or watching you putting your mask on or whatever you want for the real world comparison of changing your IP would be.
There is ways to work with browser fingerprinting as well, but that’s on the rare side to do properly.
Of course working around these things and things like deleting cookies is great if you don’t trust the reject button which is reasonable. Just go on a random website and see what you get despite rejecting everything.
-
Browser fingerprinting works by estimation, not a specific result. Even if the fingerprint is unique, then it can be differently unique between different sessions of the same user. So it’s another tool for statistic analysis, not a “following camera drone” that is always able to detect intentional evasion. And even if it is able sometimes to detect it, then there’s still a statistical uncertainity of the result.
-
-
-
-
-
-
-
-
-
-
I despair of trying to convince people that a sanely constructed monolith is enormously preferable to a distributed microservice architecture, especially at the start, and doubly so if the team is small (<6 or so).
-
Quite so often I get the argument that splitting services is “cleaner so that one service does one job” and “it enforces clear boundaries”.
Each time I keep reminding people that clear boundaries and doing one job can also be done inside your service by having well defined classes, interfaces, libraries etc… you don’t need to split the application to get a clean design.
-
There are some good motivations for splitting a monolith into micro services:
- You need to be able to deploy updates to different components independently. Note that you still need to test updates, so this matters only if the process restart time for your monolith is noticeable to customers.
- You want to enforce the principle of least privilege. This is actually a good reason. Even if you are writing in a safe language, bugs in the language runtime may allow an attacker to leak secrets. Putting anything handling crypto keys into a separate service (at the very least) is probably a good idea.
- Closely related to the pervious point, you need independent failure domains. If you have some safety- (or business-)critical part of your service and some complex part, splitting them makes it easier to ensure that the critical part remains live when the complex part experiences bugs or attacks.
- You need to be able to split your service across multiple hardware nodes to achieve the scale that you need. This is much easier with explicit communication boundaries, but be aware that you are now building a distributed system and this is at least an order of magnitude harder. The first rule of building distributed systems is don’t build distributed systems unless you have to.
As you say, in 90% of cases none of these reasons apply, and even where they do it may only be for a tiny part of the app. There’s also one other closely related reason that isn’t technical:
- VC-backed microservice-hosting companies are much cheaper than hosting services for monoliths and so it’s cheaper to deploy to a subsidised platform than to one that has a sustainable business model, even when you bake in the cost of moving in a few years when they finish burning their funding.
-
You need to be able to deploy updates to different components independently. Note that you still need to test updates, so this matters only if the process restart time for your monolith is noticeable to customers.
Why? Why would that be different between a micro service and a monolith. I’ve seen many monolithic and non-monolithic architectures over the course of my career, built by various companies or myself. I don’t really see how this can possibly apply. Either you have a zero downtime deployment or you don’t.
You want to enforce the principle of least privilege. This is actually a good reason. Even if you are writing in a safe language, bugs in the language runtime may allow an attacker to leak secrets. Putting anything handling crypto keys into a separate service (at the very least) is probably a good idea.
That actually depends a bit. This argument is given more frequently than relevant. There’s many real world applications microservice architectures where that actually does matter. In reality whether a setup is infiltrated depends on bad code or bad setups and in that case they typically mean that you can wave goodby to all your secrets (as in things like user data, etc.). Also it’s not a given that different secrets in your application are all accessible. While this is a rare scenario it’s true though.
Closely related to the pervious point, you need independent failure domains. If you have some safety- (or business-)critical part of your service and some complex part, splitting them makes it easier to ensure that the critical part remains live when the complex part experiences bugs or attacks.
Yes, IF done correctly. And that’s really not a small if. One part still needs to interact with the other part. So it’s never completely split off. But then we could go into IF stuff is done correctly in the monolith it is the same. But I agree that in most companies/products/setups this is easier with microservices.
VC-backed microservice-hosting companies are much cheaper than hosting services for monoliths and so it’s cheaper to deploy to a subsidised platform than to one that has a sustainable business model, even when you bake in the cost of moving in a few years when they finish burning their funding.
This almost sounds like a joke to me. Do you actually mean that? Do you have any form of backing for that statement or do I maybe completely misunderstand what you are saying? Hosting a monolith is classically a lot easier and simpler to come by. Think of just renting a server/instance and deploying your Rails/Django/… monolith. Replicate is as much as you want/need and you are done. That’s usually orders of magnitude cheaper than anything even remotely related to microservice hosting. Even if there was magically zero overhead to pay for for service to service communication and the individual service overheads and the parts required for a sane microservice architecure, etc.
And I mean a VCs goal is to make as much money as quickly as possible from a venture, so why would they even go for cheaper?
-
You need to be able to deploy updates to different components independently. Note that you still need to test updates, so this matters only if the process restart time for your monolith is noticeable to customers.
In my brief career working on a network service, we never restarted the server outright; rather, we would start up an instance of the new version and switch over seamlessly from the old. Then eventually take down the old one (leave it up for a while to allow switching back in case something goes wrong). Is this not standard procedure? It doesn’t seem like restart time matters given such a design.
You want to enforce the principle of least privilege. This is actually a good reason. Even if you are writing in a safe language, bugs in the language runtime may allow an attacker to leak secrets.
Sounds like an excellent argument in favour of capability safety. (As I recall, log4shell started a cottage industry of blog posts arguing for capability safety.) The issue of bugs in the language runtime is—not illegitimate, but very, very marginal, especially considering that the kernel (ie, runtime of unix, another capability-safe programming language) is as much of a bug vector, if not moreso.
VC-backed microservice-hosting companies are much cheaper than hosting services for monoliths and so it’s cheaper to deploy to a subsidised platform than to one that has a sustainable business model
lol
-
In my brief career working on a network service, we never restarted the server outright; rather, we would start up an instance of the new version and switch over seamlessly from the old. Then eventually take down the old one (leave it up for a while to allow switching back in case something goes wrong). Is this not standard procedure? It doesn’t seem like restart time matters given such a design.
I have implemented this a dozen times or so for almost two decades. Since the old days with Apache httpd and still to this day on aws, kis, gcp, etc. This process can be done in less than a second on a service with proper latency. I also don’t know what GP means with independently. If there is no downtime, there is no problem to begin with.
-
-
Another thing to keep in mind here is that if you split into microservices, even though it’s usually very standard each of these services also does the whole microservice harness part. Which are thing that can go wrong differently in different services. Most of the time they don’t. But of course it’s silly to assume nothing ever goes wrong. And these things can be very hard to debug.
Each bit of thing you add is a thing that can go wrong. So you can essentially prevent whole classes of bugs and a lot of complexity in debugging.
And of course that comes on top of all these parts having upgrade, migration paths, bugs on their own, etc. So the potential for issues increases on all of these fronts.
People like to talk about credits for trying new technologies, but tend to forget about such things when it comes to more moving part, whether in-house or external.
It’s particularly funny when the same person that argues for micro services (and usually a whole slur of technologies with it) to make things easier somehow is worried when you use a different (well-established) programming language everyone on the team is familiar with.
I think a lot of that comes from (the assumption that) “everyone is doing this”. I also think that since a lot of these technologies are tied to companies and products there is a huge amount of marketing, which has an effect on developers/teams/companies.
And there’s just so many ways people profit from the whole microservice hype. SREs earn more than SysAdmins, Google, Microsoft, Amazon, RedHat, Grafana, Hashicorp, etc. all have products for microservice architectures and make more money if you have more services, people write books, make premium videos for topics around microservice architectures, consultants (like me) make more money when dealing with such topics.
So of course the overarching theme is “use microservices!”. Also that has been going on for long enough that there’s people who expect that and don’t know any different.
This isn’t some conspiracy, the is the usual pattern with monetizing hypes. And unlike “blockchains for everything” it’s not like this doesn’t also work. Whether code is part of a monolith or a microservice on the functionality side of things not much changes. I also don’t think that microservices are significantly worse or always a bad idea. There is just an unfounded default assumption that they are the best way to go pretty much always. And people - if they are there long enough - sometimes realize that. Sometimes not, because the main reason to switch from a monolith is that it’s some bad old code which nobody really understands that will be rewritten in the process.
So while it’s all done under the “migrating to microservices” umbrella what really happens is the code simply is turned into something sane, maintainable, which is exactly “clean interfaces”. Sometimes you also have things like weird ways of keeping state that essentially have to go away if you move to microservices. Yet another part is that you probably have understood your problem space enough to simply write a good service, with good abstractions, etc. Many success stories work like that. You did something X years ago and have worked on it since, now you have to change everything, likely rewrite a lot of things. Likely the outcome will better than you could have done all those years ago. And as an added benefit you can now say how you have skills with such a thing and of course everything will be better, cause you had a hand in it.
So lots of psychology kicks in there. But a lot of this is true for most new things. For example a new programming language. If you write something in a new programing language, likely something you have experience you have a new clean project with all the learnings and zero of the baggage/technical debt and often fewer or no compatibility requirements. So other than not knowing the language well you actually are in a better situation than before. And if you have some experience and the language is kinda similar (which really is the most common theme) a new language won’t be much of a hindrance. And everything that is is easily blamed on simply not knowing it well enough yet.
-
-
The words “sanely constructed” are doing a ton of unexamined work in your comment. Perhaps there are people who can manage and scale up monolithic codebases from a small start to dozens or hundreds of developers and vast amounts of code and functionality, and who can do so in a way that stays architecturally clean and maintains clear separation of concerns and so on.
But I’ve never personally seen anyone pull it off. Instead the monolith always becomes a hairball of cross-cutting concerns and lack of clear functional boundaries and other hacks, and eventually someone decides it would be easier to just acknowledge the inevitability of Conway’s Law and start splitting the thing up by team.
-
Perhaps there are people who can manage and scale up monolithic codebases from a small start to dozens or hundreds of developers and vast amounts of code and functionality, […]
The vast majority of systems never need to reach that scale. Of course, if you are completely certain ahead of time that you can’t be successful with anything less, go nuts, but for every system where microservices were justified from the start I expect there are hundreds where it wasn’t.
-
The vast majority of systems never need to reach that scale
Well, the vast majority of programming projects fail quickly, which doesn’t really make your point for you. But of the ones that stick around long enough to go from, say, 5 developers to 50, I think you’re going to find a lot more painful stories where they decide that they need to start breaking things up due to the difficulty of getting that many people to continue working in a 100% architecturally perfect manner.
So like I said: the word “sanely constructed” are doing a ton of unexamined work in your comment. You might as well just advise people not to write code with bugs in.
-
-
-
Our experience is mixed but I’d say a Lambda/SQS/CDK based architecture has a relatively gentle on-ramp compared to what people generally understand to be a container based micro-service architecture.
The amount of time teams have to be in each others’ business for all kinds of things with a monolith should not be underestimated and I don’t think is worth it from 4-5 product teams onward.
-
-
-
I can be confident that a Perl script I write today will run unaltered 10 years from now, modulo external collaborators.
I think this is one of the most underrated features of languages and their ecosystems.
It is annoying to do chores just to stay at status quo in a project.
It also can be a sign of bad architecture when completely is being broken all the time. Don’t get me wrong, everyone does mistakes, but when your API breaks on a regular basis maybe it’s time to take a step back and think things through. It’s hard to get things right at the first time, but thinking about the API and how it will be used in the context of having to break it is something that can and has been done. It baffles me a bit when some framework is released and even as a novice you can see how and why the API will have to be broken.
Of course there’s the phase of problem space exploration and all of this really depebds on a lot of context. I just sent to point out this is possible and it usually isn’t consideredy as much as other traits. And in certain areas it seems that frequent breakages are considered normal.
Also don’t get me wrong. I’m on the side of breaking compatibility early if it’s actually necessary, but it should be done in a way to ensure a project with some stability do it’s possible to build upon it without always having to come back to it
And of course shortly after that comes how important quality documentation of breakage and upgrade paths are.
Of course stability can come at the price of publicity. People tend to talk a lot more about that new major release than they talk about that thing that flawlessly did its job for 20 years without a hiccup.
-
I am really starting to get turned off by projects that break compatibility after an initial exploratory phase. It’s just so rare that the pain of breaking all existing clients is made up for by the nicer (really?) new API.
-
I consider it a sign of really bad software engineering. It is sometimes unavoidable. Requirements are never static (you they were, I wouldn’t care about the new version), but if you routinely break consumers then it suggests that you didn’t understand the first set of requirements. If something core to the model has changed (e.g. when LLVM decided to stop encoding pointee types in the type system, for very good reasons) then you expect some churn, but I often see changes that could have trivial compatibility wrappers added and avoided any breaking changes.
Unfortunately, Google has infected a lot of the open source ecosystem with this mindset. They routinely churn internal things because the have a monorepo and run refactoring tools over all consumers, of an API, but if your API is for external use then this doesn’t work. Open source projects used to be really good at this kind of stability and the older ones (GNU, FreeBSD, and so on) still are, but CADT is a real problem elsewhere.
-
-
-
I think Drew would be the first one to be glad for that statement to be proven wrong. :) Currently he’s also implementing another of those “impossible” projects: a new OS.
Also I think the “impossible”-ness was referring to a mass appeal product (either the browser, or the OS) that can compete on an equal footing with the Chrome/Firefox behemoths.
A small team with limited resources will probably lose steam (as Kling points out in TFA) when faced with the massive amount of things that a browser needs to do. Having a browser for a niche group of enthusiasts that are willing to accept that despite having the discord login page load, they can’t operate their bank’s website is a smaller endeavour and, I imagine that everyone is rooting for them to succeed in it.
-
I think a big part of it is the 90% problem. You can probably make a browser that works for most sites with acceptable performance but for every user there will be one critical thing that doesn’t work. This has been a problem for Firefox for a long time.
-
Yes, although it might not affect Ladybird strongly.
Firefox is supposed to be a browser for everyone, which means that everyone’s single broken site is Mozilla’s problem. Ladybird is a browser for the subset of people who are attracted to SerenityOS. A smaller set of people, and I assume it’s composed of people who won’t complain about the browser when they run into a problematic site.
-
Another new from-scratch browser is Flow https://www.ekioh.com/flow-browser/ tho it is closed source. Their target market is set-top boxes or in-TV software, where the browser does not need to be compatible with the entire web, just a few select sites.
I haven’t heard much about Flow recently; their last blog post was 2021, so I hope they are still going strong.
-
-
Ladybird seems to have broader scope though. The push to get LibWeb running and capable on Linux was strong since it was first shown off–with enough pressure that author took the time to make a Qt chrome for the engine. But it’s still a similar audience in that it’s the same crowd that won’t get mad if one site is broken.
-
-
-
There are issues though. You may be able to implement large parts, then people can use large parts of the week.
But then you hit a hard wall with DRM, so you’ll have things like Netflix that you simply won’t support, because there’s a gatekeeper for a binary and since they aren’t supporting somewhat big Browsers you’re out of luck. That part of the web is not free and open, but it has become a huge part of it in terms of usage.
So there you’ll be stuck when you just implant all the specs
I also don’t think this issue will become smaller. My main browser is configured to not use DRM even though it’s just a click away. There’s an upwards trend, largely spreading due to usage outsourced streaming solutions.
If other things will be streamed as well (software, games, etc.) I think it may become worse.
And then you have other topics. After some time where devs simply followed standards we now seem to drift back in a situation where Websites will tell you to use Chrome and refuse to work on other broesers even when they’d be capable.
I think the project of making a new broeser is great, but I think there needs to be a push away from many developments where despite standards there only is one browser.
This time I think it would be even harder to get out of it. Google, etc. used to have incentives to support breaking up the market share and they certainly profited a lot in the long run. I don’t see such incentives anymore. At least not right now.
-
If other things will be streamed as well (software, games, etc.) I think it may become worse.
This is only true if consumers of the content are willing to only operate inside of those ecosystems. If consumers want to watch something without DRM, then they can visit a streaming site that does not require DRM. This may be viewed as piracy on the side of the conglomerate or free access on the side of the consumer.
Just because corpos will only tell you their world is safe and legal doesn’t make it true.
Corpos will only take action if they lose enough money, otherwise there will always be a freer solution even if it is only known by a minority.
-
I’m not familiar with what you mean for Netflix DRM that is somehow tied to browser tech. Could you be more specific?
because there’s a gatekeeper for a binary and since they aren’t supporting somewhat big Browsers you’re out of luck.
What does this mean? What does binary mean in the context of web apps?
-
If you want to use Netflix or others, you have to use DRM. There is a standard for the interface, but how it’s implemented is that there’s closed source binaries.
Currently the biggest implementations is Widevine. It’s pretty much the standard way that video streaming platforms implement DRM these days.
Widevine is by Google. So they are gatekeepers and for example don’t build for Brave, Electron Applications, and many many other browsers, operating systems, architectures, etc. out there.
-
fair enough, thanks for sharing
-
-
-
-
-
-
I have to admit I was not aware of monocypher before.
The Why Monocypher? page is great and I especially love the “Why not Monocypher?” section. I’d love if more projects had something like that. In general the whole website is really well done. Great example of what a good project page should look like.
-
It would be to add mBedTLS to that comparison. 100 KiB is a somewhat odd size. For embedded use, it’ way too big (the entire TCP/IP + TLS + MQTT stack on the embedded platform I work on is about that size), for desktop or server things it could be an order of magnitude bigger and I wouldn’t care (I use libsodium via vcpkg and do LTO in release builds, so I effectively do subset it to only the APIs that I call and it’s much smaller than 3.3 MiBs).
-
-
In go, single character variable names are idiomatic, especially when the scope is small.
-
I’ve read that, and I try to follow idioms as much as possible, but I’m having a really hard time with this one because I really can’t find any justification for it (i.e. what makes Go so special that decades old advice is suddenly irrelevant?). I can see it if “small scope” means 1 or 2 lines, but beyond this I’m having a really hard time keeping track of them.
But even if one accepts the idiom, how do you solve my issue when the scope is not small?
-
http://doc.cat-v.org/bell_labs/pikestyle
Ah, variable names. Length is not a virtue in a name; clarity of expression is. A global variable rarely used may deserve a long name, maxphysaddr say. An array index used on every line of a loop needn’t be named any more elaborately than i. Saying index or elementnumber is more to type (or calls upon your text editor) and obscures the details of the computation. When the variable names are huge, it’s harder to see what’s going on. This is partly a typographic issue; consider
-
This is such a dishonest argument, though, because it presents a false dilemma between very short names and “huge” names.
In Python I routinely write loops like:
for entry in BlogEntry.query(): # do thing with entry...This is more readable than a single-letter name would be, and doesn’t fall into any “huge name” trap I’m aware of.
It’s not the 1970s anymore. Our computers have the disk and memory space to let us use names like “format” instead of “fmt”. And so we should, and should leave the 1970s conventions in the dustbin of history where they belong.
-
I’m not sure how this is a dishonest argument.
Your Python code is equally well expressed if
entryis namede, as far as I can see. It is not obvious thatentry“is more readable than a single-letter name” ofe, at least without more context.Preferring
fmtoverformatis not a decision made from 1970s-era technical constraints. It’s possible to prefer the shorter form over the longer form, even if our servers have bajillions more available resource-bytes.-
I’m not sure how this is a dishonest argument.
Because, as I said, it presents a false dilemma. If the only possible choices were single-character names, or “huge” unwieldy names, there might be a point. But there are in fact other options available which aid in readability by providing context without being “huge”.
It is not obvious that entry “is more readable than a single-letter name” of e, at least without more context.
Single-letter names rarely provide context. If a file contains multiple functions, each of which contain at least one loop, single-character names fail to differentiate which loop (or which function) one is looking at.
Also, I find it somewhat amusing that single-character loop variables are extremely likely to lose context or even collide during refactorings, yet as far as I’m aware the reason why Go stylistically discourages some other naming conventions (such as a “this” or “self” parameter name for functions which receive an instance of a struct defined in the same file) is that refactoring might cause loss of context.
But mostly, the single-character thing just feels to me like another instance of Go’s designers attempting to stand athwart the history of programming language design and practices, and yell “Stop!”
-
Single-letter names rarely provide context.
The normal guidance in Go is to name variables with expressivity (length) proportional to their lifetime, and the constraints of their type.
The name of a variable that’s only in scope in a single line block needs to provide far less context compared to the name of a variable that’s in scope for an entire e.g. 100 line function.
A variable of type SpecificParameter can be named sp because that meaning is unambiguous. A variable of type string that represents an e.g. request ID should probably not be called simply id, better e.g. reqID, especially if there are other string parameters that exist with similar lifecycles.
If a file contains multiple functions, each of which contain at least one loop, single-character names fail to differentiate which loop (or which function) one is looking at.
It’s not the job of a variable name to disambiguate at the file, or really even function, level. An index variable for a one-line for loop is probably appropriately named
ino matter how many times this situation is repeated in a function or file.-
A variable of type SpecificParameter can be named sp because that meaning is unambiguous. A variable of type string that represents an e.g. request ID should probably not be called simply id, better e.g. reqID, especially if there are other string parameters that exist with similar lifecycles.
Or name them
SpecificParameterandrequestID. Pointlessly shortening variable names far too often leads to names that confuse rather than communicate. IsreqIDa request ID? A requirement ID? A requisition ID? If I see that name out of context – say, in a debug log – how am I supposed to know which one it is?And even in context it’s not always clear. Going back to the “self” param debate, as I understand it the standard Go approach if I want to write, say, a function that takes and operates on a
Serverstruct, is to declare the parameter ass. Some obvious and more communicative names are ruled out by other aspects of Go’s naming rules/conventions, but how exactly is that informative? If I’m not directly in that file, and just see a call to the function, I’m going to need to either go look up the file or rely on IDE lookup showing me the type of the parameter to figure out what it’s supposed to be, since outside of the original context it might besforServer, or might besforSocketor forSSLContextorSortedHeadersor…(and the loop-index case does still lose context, and also needing to name loop index variables is an indication of a language with poorly-thought-out iteration patterns)
But really it just comes down to a question of why? Why does
requestIDneed to be shortened toreqID? Is the target machine going to run out of disk space or memory due to those four extra characters in the name? No. So there’s no concrete resource constraint requiring an abbreviated name. Is there any additional clarity provided by naming it onlyreqID? No, in fact clarity is lost by shortening it. What is the alleged gain that is so overwhelmingly important that it requires all variable names to be shortened like this? As far as I can tell, it really is just “that’s the way we did it with C in the 1970s”.And it’s not even consistent – someone linked below a buffered I/O module that’s shortened to
bufio, but theReaderandWritertypes it works with are not shortened toRdrandWrtr. Why does it have a functionDiscardand not a functionDscrd? WhyNewReaderSizeand notNwRdrSz? There’s no principle here I can detect.-
Once I’m familiar with the convention, it’s a lot easier for me to recognize the shape of reqID than it is to parse the text “requestID”.
Right now I’m working in a codebase where we have to write
sending_node_componentall over the place and it’s so miserable to both type and parse that the team unanimously agreed to just alias it issnc. -
-
Why are you abbreviating ‘identifier’ throughout your post? What about SSL? Communication is full of jargon and abbreviations that make sense in context. They’re used to make communication smoother. Code does the same. Variable names are jargon.
But really it just comes down to a question of why?
Because to many people, it’s simply more readable.
-
“SSL” is an initialism, not an abbreviation.
Variable names are jargon.
So there’s an agreed-upon set of standard names which all programmers everywhere are trained on, aware of, and understand? Cool, so why does this thread – asking about how to name variables – exist in the first place?
They’re used to make communication smoother.
And I gave examples of how abbreviated variable names fail at this, where slightly-longer versions do not have the same issues. I note that you haven’t actually engaged with that.
-
-
So, suppose we look at a set of possibilities:
requestIdentifierrequestIdentreqIdentifierrequestIDreqIdentreqIDreqIrqIDrqIrIr
Do you honestly believe that all of them are basically equally useful and informative, even when viewed out of context (say, in a log or error message when trying to debug)?
-
I never see variable names in log files, let alone without additional information.
Do you typically dump raw variable names into logs, with no additional context? Don’t you think that indicates a problem with the quality of your logs?
It seems pathological to focus on readability of variables in the context of poorly written log messages.
-
Log messages are one example of when a name might appear out of context.
Do you believe all of the above names are basically equally useful and informative, even when viewed out of context? Because if you work someplace where you never have to debug based on small amounts of context-missing information, perhaps you are lucky or perhaps you are THE ONE, but the rest of us are not. So I’d appreciate your input on the hypothetical missing-context situation.
-
-
Or maybe the names of local variables matter a lot less, and the way the code scans when skimming matters more than you acknowledge.
It’s easier for me to read code with shorter lines. The shape of the code matters about as much as the names, maybe more.
even when viewed out of context?
This is a non-consideration. I don’t view them out of context. Short names tend to read better in context.
-
-
-
Nobody is suggesting this.
The claim is that the verbosity of a variable name ought to be a function of the lifetime of that variable, and the ambiguity of its name versus other in-scope variables.
Variable names always exist in a context defined by source code.
-
-
-
-
If you have a for loop over SpecificParameter values which is 3 lines of code long, there is no purpose served by naming the variable in that loop body as
specificParameter, in general. It’s laborious for no reason.Variable names always exist in the context of the source code in which they are written. There is no realistic way that the literal name of a variable as defined in source code could end up in a debug log.
-
-
“IDE” is not an abbreviation, it’s an initialism. If you’re going to be pedantic like this you have to be correct about it.
-
-
-
-
-
-
-
Single-letter names rarely provide context. If a file contains multiple functions, each of which contain at least one loop, single-character names fail to differentiate which loop (or which function) one is looking at.
I would say if the name of the function is not visible on screen at the same time, your function is probably too long. But what’s your point here? That local variables should have names that are unique in a source file, although they are not in global scope?
But mostly, the single-character thing just feels to me like another instance of Go’s designers attempting to stand athwart the history of programming language design and practices, and yell “Stop!”
This one I don’t understand. Newer languages do not have/allow longer variable names than older languages (for the most part). So I don’t see how the length of variable names has anything to do with the history of language design.
-
I would say if the name of the function is not visible on screen at the same time, your function is probably too long.
I’d argue there’s no such thing as a function that’s too long, only too complex. Do you think this function would be worthy of splitting, being over a hundred lines long?
In my opinion it’s not, as it’s just a linear list of tasks to be done in order to generate a chunk of bytecode for a function. It’s like a cake recipe. It’s a list of steps telling you how to mix and bake all the different ingredients to produce a cake.
Now obviously, some cake recipes are fairly complicated, and they can be split into sub-recipes - but that is a result of deep nesting being hard to keep track of, not length. In Unreal Engine for instance there are lots of functions which go incredibly deep in terms of nesting, and those could probably be factored out for readability, but I still wouldn’t be so sure about that, as moving out to smaller functions tends to hide complexity. It’s how accidental O(n²) happens.
Which is why I tend to factor code out to separate functions if I actually need to reuse it, or to make a “bookmark” showing a future extension point.
-
-
-
equally well expressed if entry is named e
If it was
for e in BlogEntry.entries(), I’d agree (and I’d say it should be renamed to this becausequeryis too vague) because then you know you’re getting anentryback from that method. But a genericBlogEntry.query()doesn’t give you any hint as to what’s coming back - which is wherefor entry in ...is helpful because it signals “hey, I’m getting an entry object back from this”. Means you don’t have to hunt downBlogEntry.queryand find out what it returns.-
I’d argue if that’s not clear then it’s not e that is the problem, but .query that is. Also if you use some form of IDE the “hunting” down is usually okay. You anyways want to know whether it returns an error. And sometimes you want to know whether it’s some response type rather than the actual data or something. But in this example I think e would be as clear as entry - at least it is for the scenarios I can think of.
-
-
-
100% with you on this, but if this thread shows something it’s that this is way more subjective than I thought.
TBH I don’t mind it as much when it’s in the standard library, a few well known exception to the rule are not too bad.
-
-
-
-
-
(i.e. what makes Go so special that decades old advice is suddenly irrelevant?).
Even older advice and experience, from the people that wrote Go. They (and I) find it more readable to use short names, so they did.
For example: https://github.com/golang/go/blob/master/src/bufio/bufio.go
-
-
-
For most stuff, even though it doesn’t go into your concern I follow this: https://go.dev/doc/effective_go#names
In Go it’s usually that people go with “the more local a variable is the shorter it can be”. For things like net/url that is mentioned a lot in this context I usually go with “what kind of URL is this?” For example imageURL, apiURL, etc. It’s similar in other languages. Many standard libraries have URL, file, path, etc. If you use a car in a five line comment body it’s fine to name it c, of course one needs the self-discipline to rename things, should the context change, but that’s a good idea anyways.
If you go for longer, more specific, context-describing names you also don’t into situations where you have car and otherCar or similar confusing things. I imagine carToPark, carToRepair, crashedCar, driverlessCar, etc. If there is only one car, and the method isn’t giant single letter is actually pretty fine. Say you have a method to query a car from the database, or more general setters, getters things are clear. And if the logic is bigger it makes a lot of sense to define it anyways, because of potential for misunderstanding which car we are referring to. People sometimes overlook this can even happen when there is only one car, to precise how it is used. Maybe even indicate whether something is cloned or referenced.
-
Soft-wrap!?!?! Finally.
-
-
-
Of course. But maintaining hard wraps requires either an editor understanding the semantics (where a break can be inserted or removed without changing meaning) or manual labour, especially when editing existing paragraphs. Soft-wrapping is easier to do for the editor as it can’t change meaning and requires no manual work.
-
In what circumstances is a line break semantically significant within a Markdown paragraph (or a HMTL
<p>tag, for that matter)?I’m asking because I’m dimly aware of vast amounts of “non-standard” Markdown dialects floating around and I’m wondering if this is something like that.
(Of course, 2+ spaces followed by a line break does insert a
<br />tag in most MD dialects, but that’s not the issue here as far as I can see). -
-
-
-
-
-
-
Obviously: https://iwp9.org. I’m helping organize that one.
There’s also the 9front hackathon later, in August. There’s no website; it’s intended for contributors, so signup and information is done via an authenticated 9p share.
I’m also excited for https://bsdcan.org; this one has consistently been one of my favorite conferences, with good speakers, good hallway conversation, and a generally good vibe.
I’d also like to make it to at least one https://www.thestrangeloop.com/, which doesn’t leave me much choice but to go this year.
Gophercon (https://www.gophercon.com/) is another one that I want to make it to, given that it’s the language that pays my bills these days.
And finally, while I couldn’t make this year’s RWC (https://rwc.iacr.org/2023/), I’ve really enjoyed all of the ones I’ve attended. I’m no cryptographer, but the topics tend to be down to earth enough that I can follow along.
-
Obviously: https://iwp9.org. I’m helping organize that one.
Will there be recordings?
-
-
-
I am fed up with the Rust hype myself but this is just pointless. “if written by the right people.” Yeah sure, you don’t need memory safety if you have the magical right people who never write make memory errors.
-
If you have people who have sufficient attention to detail to write memory safe code in C, imagine what they would be able to do if you have them tools that removed that cognitive load and let them think about algorithms and data structures.
-
and let them think about algorithms and data structures.
Ideally they would be thinking about solving the problem at hand and not ways in which they can use spare tools.
-
-
Software is prone to many sorts of defects, and I find it quite plausible that there are people who could, pursuant to appropriate external factors, produce software in c with an overall defect rate not far off from what it would be if they wrote it in, say, typescript. (Typescript is quite an odd strawman here, considering that it doesn’t have—and isn’t, to my knowledge, known for having—a particularly strong or expressive type system, but we’ll roll with it.) I might even go so far as to place myself in that category.
I do agree with david that, absent such external factors, there are very good reasons to not choose to write applications in c; it is rather absurd that, in a general sense, programming languages are used which are not garbage-collected and capability-safe.
-
Typescript is quite an odd strawman here, considering that it doesn’t have—and isn’t, to my knowledge, known for having—a particularly strong or expressive type system, but we’ll roll with it.
Not strong, perhaps—it’s intentionally unsound in places—but I’d argue that it’s among the most expressive of mainstream languages I’ve used. You can express things like “function that, given an object [dict/hashmap], converts all integer values into strings, leaving other value as-is”, and even do type-level string parsing - very handy for modeling the sorts of metaprogramming shenanigans common in JS libraries.
-
-
Not disagreeing, but something to add here.
Languages also won’t prevent bad designs, bad performance, hard, unreasonably complicated builds and deployments, bugs (security-related or other kinds), and so on. So you can find projects by “the wrong people” in every language. Sometimes this colors how a language is perceived, especially when there aren’t many widely used applications written in it, or it is simply dominated by few applications.
Another thing when it comes for example to C and security. It might depend a lot on context and not just the language itself. First of all, yes, C has a topic with memory safety. I am not here to defend that, but I think it’s a great example where huge numbers of work-arounds and mitigations have emerged in the ecosystem. For example running a service in C written for Windows 98 has strongly different properties than OpenSSH on OpenBSD or something using sandboxing on Linux or OpenBSD and switching libraries, Valgrind, Fuzzers, etc. can make a drastic difference. While that doesn’t make C safe, it does make a difference in the real world and as such it is reasonable to go with a project written in C for security reason when the other option is some hacked together project that might claim to be production ready, but hasn’t been audited and was programmed naively.
So in the end it rarely is as black and white and very context dependent. The article could be understood as a language not defining these things on its own.
-
Languages also won’t prevent bad designs, bad performance, hard, unreasonably complicated builds and deployments, bugs (security-related or other kinds), and so on.
No, languages exist exactly to do these things. I’m excluding the extreme case of someone stubbornly writing intentionally terrible code to prove the point. When developers write code with best intentions, the language matters, and it does help or hinder them.
We have type systems, so that a “bad programmer” calling a wrong function will get a compilation error before the software is released, instead of shipping buggy code and end users getting random “undefined is not a function”.
When languages don’t have robust features for error handling, it’s easy to fail to handle errors, either by accident (you didn’t know a function could return
-1) or just by being lazy (if it’s verbose and tedious, it’s less likely to get done). When languages won’t let you ignore errors, then you won’t. Ignoring an exception —On Error Resume Nextstyle — needs to be done actively rather than passively. Rust goes further withResulttypes that in most cases won’t even compile if you don’t handle them somehow.You can have for-each loops that won’t have off-by-one errors when iterating over whole collections. You can have standard libraries that provide robust fast containers, good implementations of basic algorithms, so that you don’t poorly reinvent your own. Consider how GTA was terribly slow loading for years because of a footgun in a bad standard library combined with a crappy DIYed JSON parser. This error wouldn’t happen in a language with better string functions, and would be a total non-issue in a language where it’s easy to get a JSON parser.
It’s much harder to write bad Rust code than to write bad C or bad JS or bash. Good languages make “bad programmers” write better code.
-
Languages also won’t prevent bad designs, bad performance, hard, unreasonably complicated builds and deployments, bugs (security-related or other kinds), and so on.
No, languages exist exactly to do these things. I’m excluding the extreme case of someone stubbornly writing intentionally terrible code to prove the point. When developers write code with best intentions, the language matters, and it does help or hinder them.
No, they don’t.
- Bad designs are a factor of developer experience
- Performance is a factor of algorithms and implementations
- Complicated builds are based on design, build tools, libraries, frameworks, also see Bazel, etc.
- Deployments pretty much the same thing. I’d agree with builds and deployments language can have a huge influence, which is why containers are often used as a workaround. If we look at C code there is a huge range starting from super simple, single binary to absolutely horrible. So that’s why I don’t think it’s defined through the language.
- Bugs are to a large degree ones that can be made in every language. There’s so many bugs that have been done in C, Java, Python, Perl, PHP, Go and Rust. From bad error handling, over SQL injection, library misuse, etc. Sure, if your implementation has memory safety it is it’s own story, but it’s certainly not the only and not the only security critical bug.
We have type systems, so that a “bad programmer” calling a wrong function will get a compilation error before the software is released, instead of shipping buggy code and end users getting random “undefined is not a function”.
Yes. Yet there were C and C++ and people still came up with Perl, Ruby, PHP which all don’t have memory safety issues.
You can have standard libraries that provide robust fast containers, good implementations of basic algorithms, so that you don’t poorly reinvent your own
You can also have different implementations, replacements for standard libraries, other algorithms, because it’s not tied to the language.
Consider how GTA was terribly slow loading for years because of a footgun in a bad standard library combined with a crappy DIYed JSON parser.
This underlines my point though. Despite the language that is usually called fast it’s slow. Despite the language it was made fast. So it was not the language defining the software, but these factors.
It’s much harder to write bad Rust code than to write bad C or bad JS or bash. Good languages make “bad programmers” write better code.
While I agree with that sentiment, I’d be curious about any studies on that. Way back when I was at university I dug through many studies on such topics. From whether object oriented programming has measurable benefits, to typing, over development methodologies, and so on. In reality they all seem to have a lot less (that is no statistically significant) difference, from bugs to development speed over so many other factors. They always end up boiling down to developer experience and confidence. Unless there were biased authors.
I think a great example is PHP. I think a lot of people here will have seen terrible PHP code, and it’s a language I like to hate as well. It’s incredibly easy to write absolutely horrible code in it. Yet the web would be empty without. And even new projects are started successfully. I can’t think of anything good about it really, and I try to stay away from it as much as I can, yet even after decades of better alternatives new projects are frequently and successfully started based on it. And there’s some software in PHP that a lot of people here would recommend and often write articles about here. Nextcloud for example.
-
You’re reducing languages to the Turing Tarpit, overlooking human factors, differences in conventions, standards in their ecosystems, and varying difficulty in achieving goals in each language.
The fact that it’s demonstrably possible to screw up an implementation in a language X just as much as in language Y, doesn’t mean they’re equivalent and irrelevant. Even if the extreme worst and extreme best results are possible, it still matters what the typical outcome is, and how much effort it takes. In other words, even when a full range of different outcomes is possible, the language used can be a good Bayesian prior for which outcome you can expect.
Even when the same bugs can be written in different languages, they are not equally likely to be written in every language. This difference in likelihood is very important.
- A mistake of passing too few arguments to a function is a real concern in some languages, and a total non-issue in others.
- Strings with spaces — bane of
bashand languages where code is naively glued from text. Total non-issue in most other languages. - Data races are a real thing to look out for in multi-threaded C and C++ projects, requiring skill and diligence to prevent. In Rust prevention of this particular bug requires almost no skill or diligence, because the compiler does it.
You can also have different implementations, replacements for standard libraries, other algorithms, because it’s not tied to the language
For the record, Rust’s standard library is optional and replaceable. But my point was not about possibilities, but about the common easy cases. In Go you can expect programs to use channels, because they’re easily available. In C they are equally possible to use in the turing-tarpit sense, but in practice much harder to get and use, and this affects how C programs are written. Majority of Go programs use channels, majority of C programs don’t. Both could use channels equally frequently, but they don’t.
Despite the language that is usually called fast it’s slow. Despite the language it was made fast. So it was not the language defining the software, but these factors.
There’s a spread of program speeds and program qualities, and some overlap between languages, but the medians are different. C is slow in this narrow case, but overall program speed is still influenced by the language, e.g. GTA written in pure Python wouldn’t be fast, even if it used all the best designs and all the right algorithms.
And in this case the language choice was the cause of the failure. Languages aren’t just 1-dimensional “fast<>slow”, but have other aspects that affect programs written in them. In this case the other aspects of the language — its clunky standard library and cumbersome handling of dependencies — were the culprit.
While I agree with that sentiment, I’d be curious about any studies on that.
It’s a famously difficult problem to study, so there’s unlikely to be any convincing ones.
In my personal experience: since switching to Rust I did not need to use Valgrind, except when integrating C libraries. In my C work it was my regular tool. My attempts at multi-threading in C were awful, with crashy outcomes in both macOS GCD as well as OpenMP. In Rust I wrote several complex pervasively-multithreaded libraries and services without problems. In Golang I had issues with my programs leaving temp files behind, because I just can’t be trusted to remember to write
deferevery time. In Rust I never had such bug, because its temp file library has automatic drop guards, so there’s nothing for me to forget. I find pure-Rust programs easy to build and deploy. I usecargo deb, which makes a .deb file with no extra config needed, in production.A bit less anecdata is https://github.com/rust-fuzz/trophy-case While it demonstrates that Rust programs aren’t always perfect, it also shows how successful Rust is at lowering severity of the bugs. Exploitable memory issues are rare, and majority are panics, which are technically equivalent of exceptions thrown.
BTW, another aspect that language influences is that in Rust you can instrument programs to catch overflows in unsigned arithmetic. C doesn’t distinguish between intended and unintended unsigned overflow, so you can’t get that out of the box.
Speaking of PHP, it’s an example where even changes to the language have improved quality of programs written in it. People programming for “old PHP” wrote worse code than when writing for “new PHP”. PHP removed footguns like HTTP includes. It removed magic quotes and string-gluing
mysqlextension, encouraging use of prepared statements. It standardized autoloading of libraries, which meant more people used frameworks instead of copy-pasting their terrible code.-
You’re reducing languages to the Turing Tarpit, overlooking human factors, differences in conventions, standards in their ecosystems, and varying difficulty in achieving goals in each language.
Why not say ecosystems then? I specifically wrote that I was talking about implementations, ecosystems, etc., so I don’t feel like I am reducing anything here.
The fact that it’s demonstrably possible to screw up an implementation in a language X just as much as in language Y, doesn’t mean they’re equivalent and irrelevant.
I did not claim that.
Even when the same bugs can be written in different languages, they are not equally likely to be written in every language. This difference in likelihood is very important.
I did not claim otherwise.
Both could use channels equally frequently, but they don’t.
That is not a factor of the language though. And it’s certainly not defining software, which the actual topic was.
GTA written in pure Python wouldn’t be fast, even if it used all the best designs and all the right algorithms.
Again, I did not claim so.
And in this case the language choice was the cause of the failure. Languages aren’t just 1-dimensional “fast<>slow”, but have other aspects that affect programs written in them. In this case the other aspects of the language — its clunky standard library and cumbersome handling of dependencies — were the culprit.
Yes, but as you say languages are not 1-dimensional. There’s tade-offs, many factors why languages are chosen, and the language chosen might lead to issues, but they tend to not define the software. Unless you see some stack trace, or see some widget toolkit tied closely to a language you usually can’t tell the language something is written in, unless it’s badly designed (and I don’t mean by some super-human programmer, I mean average).
In Rust you can add an inexperienced member to the team, tell them not to write unsafe, and they will be mostly harmless. They’ll write unidiomatic and sometimes inefficient code, but they won’t cause memory corruption. In C++, putting a noob on the team is a higher risk, and they could do a lot more damage.
They can still make your program crash, can still cause all sorts of other security issues, from sql injections to the classic “personal customer data has been exposed publicly on the internet”. Yes, memory safety is a different topic, you don’t need to re-iterate that over and over. I don’t think anyone seriously claims either that C++ will result in better memory safety, nor that that isn’t an issue. The topic at hand is whether the choice of a language defines software. And I’d argue in most situations it doesn’t. Yes, if you have memory safety issues you wanna get rid of switch to Rust, if you want to not have issues with deployment, go away from Python. However, like you say, that’s only two dimensions and there is more than that for language choice. Else there would be that one language everyone uses - at least for new projects.
A bit less anecdata is https://github.com/rust-fuzz/trophy-case While it demonstrates that Rust programs aren’t always perfect, it also shows how successful Rust is at lowering severity of the bugs. Exploitable memory issues are rare, and majority are panics, which are technically equivalent of exceptions thrown.
Yep, memory safety issues are bad, and the consequences horrible. But think about the C software you use on a daily basis. What percentage of that software do you think is defined through memory safety issues or being written in C in any other way? Of all the software I can think of, it’s only OpenSSL and image (or XML sigh) parsers for me. That’s bad enough, but it’s still not much the total amount and sadly it’s even pieces that are used by many other languages. Don’t get me wrong, I absolutely hope that soon enough everyone will for example use a Rust implementation of TLS. Also for most encoders/decoders it would be great. I’d be very happy, if it was rewritten. Still I think most other software I use, including libraries there is other defining factors than the language which is exactly why they can be rewritten in Rust, without too much headache. If the language was defining the software that would be a problem.
-
Both [C and Go] could use channels equally frequently, but they don’t.
That is not a factor of the language though. And it’s certainly not defining software, which the actual topic was.
How is it not? Channels are a flagship feature of the Go language. This influences how typical Go programs are designed and implemented, and consequently it is a factor in their bugs and features.
The way I understand your argument is that one does not have to use channels in Go and can write a very C-like Go program, or may use C to write something with as much concurrency and identical behaviors as a channel-based Go program, and this disproves that programs are defined by their language. But I call this reducing languages to the Turing Tarpit, and don’t consider that relevant, because these are very unlikely scenarios. In practice, it’s not equally easy to do both. Given real-world constraints on skill and effort, Go and C programs will end up with different architectures and different capabilities typical for their language, and therefore “Written in Go” and “Written in C” will have a meaning.
Unless you see some stack trace, or see some widget toolkit tied closely to a language you usually can’t tell the language something is written in, unless it’s badly designed
There are many ways in which languages affect programs, even if just viewed externally:
- ease of installation and deployment (how they handle dependencies, runtimes or VMs). I’m likely to have an easier time running a static Go binary than a Python program.
- interoperability (portability across system versions, platforms, compatibility with use as a library, in embedded systems, in kernels, etc.). Wrong glibc.so version is not an issue for distribution of JS programs, except those having C++ dependencies.
- startup speed. if a non-trivial program starts in milliseconds, I know it’s not Java or Python.
- run-time performance. Yes, there are exceptions and bad implementations, but languages still impose limits and influence typical performance. Sass compilers switched from Ruby to C++, and JS bundlers are switching from JS to Go or Rust, because these language changes have a very visible impact on user experience.
- multi-core support. In some languages it’s hard not to be limited to single-threaded performance, or have fine-grained multi-threading without increased risk of defects.
- stability and types of bugs. Languages have different weaknesses. If I feed an invalid UTF-8 to a Rust program, I won’t be surprised if it panics. If I feed the same to JS, I’ll expect some UCS-2 mojibake back. If I feed it to C, I expect it to preserve it byte by byte, up to the first
\0.
So “Written in X” does tell me which problems I’m signing up for.
-
How is it not? Channels are a flagship feature of the Go language. This influences how typical Go programs are designed and implemented, and consequently it is a factor in their bugs and features.
That was in response to you saying that it could be done in C, and that it isn’t done for the language community. I was responding to that. What people do with a language in my opinion isn’t what a language is. Take JavaScript. Then look at its history. Then look at node.js, etc. It’s not the language that defined this path it’s the community. In a similar way it could be that C programmers start to using channels or something else as a default way to do things.
Anyways, I am not saying that channels are not an integral feature of Go and tied to the language, it’s a feature that part of the specification. So of course it is.
ease of installation and deployment (how they handle dependencies, runtimes or VMs). I’m likely to have an easier time running a static Go binary than a Python program.
I stated the same thing!
[more points from the list “There are many ways in which languages affect programs” ]
I’d argue that this is at least partly implementation dependent, and I think that shows with things like FaaS. But I agree, that depends on the language. Again I am not trying to argue that languages aren’t different from each other. We keep coming back to this.
So “Written in X” does tell me which problems I’m signing up for.
Again something I don’t disagree with.
My point is that we see in the real world that C/C++ software is being rewritten in Rust. Often times that is done without the average user even noticing. Heck, there is even Rust in browsers where developers thought it was JavaScript. What I am arguing is that if this is the case, then a language doesn’t define a piece of software.
-
-
It’s much harder to write bad Rust code than to write bad C or bad JS or bash. Good languages make “bad programmers” write better code.
While I agree with that sentiment, I’d be curious about any studies on that.
As reported by both Google and Microsoft around 70% of security issues are caused by memory safety bugs. So any suitable language which prevents memory safety issues will lead to programmers writing better code (at least security wise).
-
-
Memory safety issues, at best, cause crashes. At worst, they allow someone that can send you malicious data to execute arbitrary code with the privileges of the program. I’m curious of your definition of ‘code quality’ that includes arbitrary code execution vulnerabilities.
-
So in your understanding there is zero distinction of quality C code and non-quality C code?
Yes, I do think there is a difference.
Please refrain from making up a “definition of ‘code quality’” that somehow is “mine” by completely ignoring the context. Also please stop pretending I am defending C or not having memory safe code/languages. That misses the point of the thread.
But since you asked for the definition. I was not talking about the design of the language here, but the design of the code. So when I was talking about code quality here I was talking about readable, maintainable, understandable code. That doesn’t mean that languages themselves may have designs that make this hard or for example make secure code hard to achieve. Maybe the following helps understanding. Another trait is a garbage collector, which memory safety a lot easier, but might result in performance implications. You can still write performant and non-performant code in a garbage collected language. Also some languages make this harder and some make it easier.
However, the topic is whether a language defines a piece of software. Given that software can be rewritten from C++ to Rust (parts of Firefox, etc.) or C to Rust (see the Tor project), I would not say that C defined these pieces of software.
I also think that not including outlier situations (Python vs Go) overall software in various languages has been both hard and easy to deploy, compile, etc. I think C is a great example for some of the most horrible situations and some of the easiest. I know C projects where you need to spend ages just to prepare for a build and I know others where you dig out the most obscure platform, type in one or two commands and it just compiles and works.
For reasons like these I do find that a language defining a software is often an overstatement. However, it certainly can be a reason to struggle with it.
You don’t (usually) install a browser, a video game, a tool, run it for the first time and given it’s working think “Huh, it’s written in language X”. If running it fails or, if your video game tells you about its engine and so on I think that should be considered the exception. And I’d hardly call it “defining” the software.
I thought that would make sense, but something in what I am writing seems to sound like I am arguing that not having memory safety is a good thing or that I am defending C. Rust and C weren’t brought up by me. I also don’t think it’s a good idea to assume that programmers don’t make mistakes. If you could point out where I appear to take that point of view I’d be really curious. I’ve been hyped up of the prospect of people switching away from unsafe languages ever since the D programming language was announced. So I feel baffled when I come across as advocating unsafe languages.
-
-
-
-
-
-
[Sorry, this is a longer response, because I don’t want to be misunderstood here]
That’s an abstract/theoretical example though. In reality I will gladly use nginx, OpenSSH, etc. over what exists in Rust, but not because of the language choice, which is the whole point I am trying to make. At the same time I wouldn’t trust other software written in C.
Let me ask you a question. Would you rather build your company on a real life kernel connected to the internet written in C or in Rust in the here and now?
I am maybe a weird one out, but I usually take a look over the code and project that I am using. There is situations where C code is simply more trustworthy. Often in “new” languages you end up with authors basing on stuff that is new themselves, so you can end up being the guinea pig. There’s also a couple of signs that are usually good for a project, not because you need them on your own, but because they are a good factor for maturity. One of them is portability. Another is not just throwing a docker container on you, because the build is to complex otherwise.
And of course these things change. Might very well be that in future I’ll use a Rust implementation of something like OpenSSH (in the sense that OpenSSH isn’t just an implementation of the protocol). But right now in the real world I don’t intend to. I’d be way too worried about non-memory safety bugs.
But let’s go a bit more abstract than that. Let’s talk an abstract service and let us only focus on how it is built and not what it actually does. If I got to choose between an exposed service under your premises in memory-safe node.js/JavaScript or in non-memorysafe kcgi/C and my concern is being hacked I can see myself going for the latter.
In your example, sure I’d go by Rust. But the thing here is that it’s because of missing context.
But it isn’t language dependent. For example for non-language factors I am pretty certain that there is more PHP and more node.js code out there with SQL injection bugs than probably in Python and Ruby. Does that mean I should choose the latter if I am interacting with databases? I’d also assume that in the real world on average node.js applications are more susceptible to DOS-attacks (the non distributed version) than for example PHP, simply because of how they are typically deployed/run. That also doesn’t have much to do with the language.
I am focusing on the title of the article here. “Software is not defined by the language it’s written in” I really don’t think languages are the thing that defines software. I’ve seen surprisingly good, solid Perl code and I’ve seen horrible Java, Python and Rust code. The reason for that was never the language. Other examples I can think of is when Tor was still in C (and they switch to Rust for good reasons, pretty successfully), and there are similar project in Java and Python for example. But I wouldn’t use them, because while they are written in a memory safe language I’d trust Tor more.
I think the usual reason why a project is started in a certain language is this. A developer has a number of values, usually also found in the project. In the time when the project is started people with these language gravitate towards a language or a set of them. So when you look at a project and the chosen language you will usually see a time capsule of how languages were viewed during that time. But these views change. A project is started in C for other reason than 10, 20, 30 years ago. The same is true for Python, Go, and even Rust has seen that shift already. While the “more secure than C/C++, yet more performant” is a constant theme, things like web assembly, adoption by projects, even changes in the language are a factor that made people use or not use Rust for new projects (anymore).
-
Would you rather build your company on a real life kernel connected to the internet written in C or in Rust in the here and now?
That’s rather easy since there is no mature rust based kernel that had similar (same order of magnitude) man hours spent on it as linux or even *bsd.
-
-
I just said that I would prefer kernel in rust that had X hours of development from kernel in C that had 10X hours of development. How is that not a defining factor? :)
A good real world example of that is
ackvsripgrepmentioned in other threads. Both tools solve the same problem, yet it’s no surprise that theripgrepis significantly faster. And that’s with (as far as I understand) significant parts ofackbeing written in C (the perl regex engine). Imagine how much slower would it be in pure perl. Another dimension that these tools differ in predictable way is distribution. I can get statically linked binary ofripgrepthat has zero dependencies that can run on linux. Withackthere is no such option.You can claim that technically you can have memory safety, performance and easy distribution in any language. That’s technically true, but in practice it’s not the case and you can predict quite well how different tools will handle those dimensions based on the implementation language they are written in.
-
-
-
-
-
-
-
-
If someone feels like they are in a situation where they feel like they do non-nonsensical, ritualistic stuff, I highly suggest to say no and either bring it up or leave or potentially both. I think companies and teams sometimes do things that no longer or currently don’t serve a purpose. In such a situation it’s worth bringing it up. If the response ends up being hand-wavy or just in general isn’t addressing the actual issue at hand then draw your conclusions. It can be a sign that it’s time to move on.
I’ve certainly seen a couple of those kinds of meetings. I am not talking about any kinds of sprints or stand-ups that make sense, but they shouldn’t be just rituals that you just do because you always did them, because then they are a waste of everyone’s time and some companies or teams really do seem immature here. There isn’t that one golden one size fits all rule and it doesn’t make sense to pretend there is. Sometimes it makes sense to do your bi-weekly sprints and daily stand-ups or whatever, sometimes it doesn’t. It’s also completely okay to just try stuff and see how it goes. And actually they do work pretty well in many situations, just please don’t do meetings when you don’t know what for. There’s no point in that. If your reason is just to see each other, check up and so on. That’s a perfectly valid point as well. But if it’s an annoyance to everyone you either should do it differently or stop it all together. It’s wasted time, or maybe even worse to some. If it’s that static rigid thing, how can you possibly call it agile?
I agree with the other posts here about not being sure what that “we’re gonna need a grown-up for that”. I mean sure, sometimes you need a person or something else to make a decision. That’s okay. But I’d assume that a team has some level of independence, else why would it be its own team?
-
Say what you will about cloud, and I will say a lot more, but you can’t deny that it’s done a princely job of abstracting services from their underlying hardware.
Here I was, thinking that operating systems and for storage volume managers and (potentially distributed) file systems did that. ;)
Don’t get me wrong, the concept of object storage is nice, but that statement feels a bit silly. Distributing data and load, mechanisms for high availability, load balancing, HTTP APIs are all not things invented by the cloud and if you didn’t just run your hobby server it also was in use. What the cloud did and that I grant is maybe somewhat unintentionally and out of necessity and limitations standardize a lot of things. That’s really cool and I am very happy about that, but sometimes people almost make it sound like there was no proper server setup you could build before AWS came along. Just instead of paying your own people running it you outsource stuff and pay a third party and pay people to tell the third party what need, basically set up the specs for the contract via Terraform, etc. But I get get carried away.
-
Alternative proposal, made modestly: Let’s ban discussion of ChatGPT or other proprietary model-as-a-service offerings. This is mostly by analogy with cryptocurrencies and the
merkle-treestag; discussion of blockchain technology and open source code is fine and should be tagged, but discussion of specific vendors should be considered proxy advertisements and removed.-
Very little of the discussion is really chatgpt specific though. People reference that model because it’s the best available one by a reasonable margin, but you could take pretty much everything being said and replace chatgpt with llama-finetuned-to-take-instructions and nothing of substance would change.
And unlike cryptocurrency this isn’t primarily bad faith advertising.
I’d hate to lose out on interesting articles just because people happened to use a proprietary model as an example to make their point.
-
I disagree on the cryptocurrency example.
I think we’d be able to differentiate. We’ve for example merkle-trees with a policy of not talking about business stuff, yet nothing is removed simply because it mentions Bitcoins, etc.
In other words: There is a lot of stuff that is clearly off-topic referenced in on-topic articles posted here. While I am sure it’s not always clear cut I think that’s true for many tags and posts which is why people can flag. However, I have to admit that I feel like that system fails more and more, on the side of letting “spam” (articles to a large degree written for advertisement, with little technical content) through.
-
-
I don’t hate this proposal.
As a practical matter, though, the bulk of all of the work being done is being done in a couple of corporate labs–open-source models aren’t quite there yet.
-
-
I’ve been wanting to propose something similar.
I didn’t, because I am unsure about the best way to do that. Will this make AI AI without LLM? Wouldn’t it then make sense to split up AI completely? If so in which parts?
On the other hand maybe the ai tag really should be described as non-LLM AI?
Since others brought it up, maybe it’s worthwhile to consider ChatGPT specifically. I am thinking about posts that are directly about the product. Similar to how hardware isn’t really considered a tag to spam with newest products, reviews and use cases of whatever Dell, Leovo, Apple, etc. brought out and how it’s used. I think all the examples you gave are a bit like “Did you know the latest ear pods can do this?”. As well as some philosophical topics, that maybe should simply go into the philosophy tag? I know that’s complicated, but again, compare it with the hardware tag. If someone talks philosophically about the development of home computers and maybe the future it’s historical or philosophy. Yet we aren’t flooded with hardware ads.
-
I think it was Audacity that had added telemetry …. in the form of Sentry bug collecting. People really got super pissed off and I was honestly a bit flummoxed. Surely bug reports are reasonable at some level?
It does feel like the best kind of telemetry is the opt-in kind. “Tell us about this bug?” Stuff like Steam has user surveys that are opt-in. It’s annoying to get a pop-up, but it’s at least respectful of people’s privacy. I have huge reservations about the “opt in to telemetry” checkbox that we see in a lot of installers nowadays, but am very comfortable with “do you want to send this specific set of info to the developers” after the fact.
-
IIRC, Steam also shows you the data that it has collected for upload and gets your confirmation before sending it.
I also appreciate that they reciprocate by sharing the aggregated results of the survey. It feels much more like a two-way sharing, which I think really improves the psychological dynamic.
-
Unfortunately, bug reports are just a single facet of product improvement that seems to get glossed over. If you can collect telemetry and see that a feature is never used, then you have signals that it could be removed in the future, or that it lacks user education. And automatic crash reporting can indicate that a rollout has gone wrong and remediation can happen quicker. Finally, bug reports require users to put in the effort, which itself can be off-putting, resulting in lost useful data points.
-
If you can collect telemetry and see that a feature is never used, then you have signals that it could be removed in the future, or that it lacks user education.
But it can be very tricky to deduct why users use or do not use a feature. Usually it can not be deduced by guessing from the data. That’s why I think surveys with free-form or just having some form of channel like a forum tends to be better for that.
A problem with both opt-in and opt-out is that your data will have biases. Whether a feature is used by the people who opted in is not the same question as whether people (all or the ones who pay you) make use of it. And you still won’t know why so..
There tends to be a huge shock when people make all sorts of assumptions and then because they try them and they still fail they start talking to users and are hugely surprised by thing they never thought off.
Even with multiple choice surveys it’s actually not the easiest. I am sure people that participate in surveys of technologies know how it feels to when the data is prevented give wrong assumptions as interpretation.
It’s not so easy and this is not meant anti-survey, but to say that this isn’t necessarily the solution and it makes sense (like with all sorts of metrics) to compare that with actual (non-abstract/generic) questions to end up implementing a feature, investing time and money only to completely misinterpret the results.
And always back things up by also talking to users, enough of them to actually matter.
-
But it can be very tricky to deduct why users use or do not use a feature. Usually it can not be deduced by guessing from the data. That’s why I think surveys with free-form or just having some form of channel like a forum tends to be better for that.
Asking users why they do/don’t use every feature is extremely time consuming. If you have metrics on how often some feature is getting used, and it is used less than you expect, you can prepare better survey questions which are easier for users to answer. Telemetry isn’t meant to be everything that you know about user interactions, but instead a kick-off point for further investigations.
-
I agree. However that means you need both and that means that you cannot deduct a lot of things simply by using running some telemetry system.
Also I am thinking more of a situation where when you make a survey and add (optional) text fields to provide context. That means you will see things that you didn’t know/think about, which is the whole point of having a survey in first place.
-
-
-
-
That’s something I’m not so sure about either though. I don’t really have a problem with anonymous usage statistics like how often I click certain buttons or use certain features. But if a bug report includes context with PII I’m less keen on that. Stack variables or global configuration data make sense to include with a bug report, but could easily have PII unless it’s carefully scrubbed.
-
Pamela Fox demonstrates in this rare display of developer humility that one needn’t be a power user of their editor to get stuff done. I appreciate that, especially in contrast to the evasions of past guests who can’t seem to admit that they actually have any practices that they would personally cop to being bad.
Setting that aside, though, I’m trying to understand the advantage of (neo)vi(m) keybindings over the conventions of GUI text editing contexts. For example, on a Mac, command+arrow takes you to the beginning or end of a line (horizontally) or document (vertically). Option lets you move by word. Doing any of that and adding the shift key selects text. IIRC, Windows has similar equivalents. Combine those keyboard conventions with the command palette and multiple-select patterns popularized by Sublime Text and you have a pretty efficient workflow with a much shallower learning curve. I can imagine if a good portion of your day is spent in an environment without a GUI, it would make sense to get pretty good at vim or emacs, but I would genuinely like to know, what is the case for GUI users to learn vim deeply?
I’m sure there’s no particularly good argument in favor of it, and I no longer actually recommend it to anyone, but having typed
vimtutorone day 18 years ago, I’m too far gone to learn anything else. If you go throughvimtutorand that’s not the path your life takes you’ll probably end up happier and better-adjusted than I am.I was a GUI user, but switched to vim(likes) for accessibility reasons.
So for me it’s not about what I can do, but how. I can do everything in my entire setup and never have to press more than one key per hand at a time, and rarely have to hold a modifier key at all.
My editor, web browser, window manager, email client, etc etc all work like that.
But yeah, I would never really recommend any of this to anyone who doesn’t need it.
I think I can relate to that. Started using touch input and key-navigation because I had to reduce the wrist pain from using a mouse.
Another vote for accessibility here. I have cerebral palsy and was developing wrist pain when using modifier keys. I switched to a vim layout and made extensive customisations to eliminate the need for modifier keys. This is purely anecdotal, but the problems have not recurred since I made these changes.
I really need to do a full post on this, but some of the specific vim motions i miss in vscode:
vi{char}selects everything inside a quote/parenthesis/curly braces/sentence."Ayappends your selection to theacopy-register, which makes it easy to go through and collect a bunch of different little things to paste all at oncezflets you create new ad hoc folds over arbitray parts of the fileguulowercases the entire lineEach one is those is only a small boost to my productivity, but when I have 200 small boosts it adds up. That said, I avoid vim emulation in other editors. It’s easier for me to switch between two sets of muscle memory if they’re very different.
I’d love to read it. You have a great blog. Based on this summary alone, I’m not sure how or if I would use these features, but perhaps if I could see how you use them, in other words, in what context, that would be very interesting.
Have you tried reporting those? I got some vi behaviours fixed that way. vi(char) may be easy to add since I remember using di(char) and that worked fine.
Vim lets you use ctrl+arrow to jump by words as well. Useful in insert mode when you do not want to go back to the command mode for some reason. People should be able to discover that just by muscle memory, so it’s somewhat awkward that she did not stumble upon it. Yikes.
Vim’s [v]isual mode lets you move around your cursor to prepare a selection (instead of holding shift all the time) and then [d]elete it, [y]ank to [p]aste elsewhere. Among other possibilities. She would probably like it, since you can e.g. search using slash to locate where you want to place the end of the selection.
Or on a one uses Pos 1, End, Ctrl, etc. when hot on an Apple device.
I think they are just good, proper Editors of which there aaactually see rest few, GUI or not. They’re usually slow, resource hungry, inflexible, hard to impossible to configure, lack features one wants or just have but been designed well. Sometimes they suffer from instability, as in new versions (minor or major) breaking things.
That’s a general theme with software. It also applies to editors of course and when you have something reliable then you stick with it. For many people that’s something like vim or emacs.
It’s often the first editor that’s “good enough”. And if you are at any time SSH into something chances are you get to learn vim or nvi in the end. Even if nowadays some systems have other defaults. They tend to not be really great.
And once you know it you end up using it locally now and then, then it becomes a habit.
I think it’s easy to overestimate how much choice there is when you have a few requirements for editors.