The best part is that copilot commented on the PR saying that this doesn’t actually change the behaviour, creates inconsistency in the codebase and suggested reverting the change! (This comment seems to have been ignored…)
> The configuration schema default was changed to "all", but the runtime fallback in extensions/git/src/repository.ts still calls config.get('addAICoAuthor', 'off'). This is now out of sync and can lead to unexpected behavior in contexts where the contributed configuration defaults aren't loaded (e.g., some tests/hosts), and it makes the intended default unclear. Update the runtime fallback to match the schema default (or omit the fallback so the contributed default is used).
My first language was also Logo, which I learned first in English at home, then in French at school. I wonder how many languages Logo was translated into?
The academic / business divide is a great example of the correct model depending on what you want to do. The academic side wants to understand, the business side wants to take action.
For example, the Viable System Model[1] can capture a huge amount of nuance about how a team functions, but when you need to reorganize a disfunctional team, a simple org chart and concise role descriptions are much more effective.
It’s hard to believe this is the first time I’ve seen Grasshopper on HN!
Just this morning, a colleague showed me a web app for building option exploration that he had vibe coded on Replit that wrapped around existing core logic in a Grasshopper script hosted in RhinoCompute [1].
The combination of visual programming, the tree data structure and Rhino’s geometry engine has made this the de facto standard for parametric design in architecture (sorry, Dynamo…)
This is basically what the OP is doing - just think of this of the cursor rule as a summary (aka a compression) of the session.
I did something similar for a small vibe-coded app. After a few back and forths to develop the first working version, I asked the LLM summarize the requirements and state of the app so far. I saved that summary into a `description.md` file, and can include it in a fresh conversation.
I was using simonw's llm so adding a new feature or making a change looks like:
`llm -f description.md -f code.py "Instructions for making another change."`
I also once got distracted by Spirographs. We got a Spirograph kit for our kids one Christmas, so I spent some time during the holidays writing a python package to draw them. Nothing fancy, just uses python’s built-in turtle graphics.
> Maple syrup is a minor luxury, easily substituted by other things like jam or honey.
Speaking as a Canadian, I suppose this is maybe technically true from an economic standpoint, but…we don’t even accept table syrup as a substitute, much less honey or jam.
(and I’ll bet IHOP serves table, not maple, syrup…)
Yeah, the flip side of there being 'less skilled' developers who operate at a higher level of abstraction is that it is easier to train more of them.
In absolute numbers, there are probably more people today who understand the fundamentals of computer hardware then there were 40 years ago, but it's a much smaller percentage of all the computing professionals.
Yes, absolutely - skills move from mainstream to niche, but are still required! For example, a much smaller proportion of the population knows how to farm today than 100 years ago, but it's still important :)
> Not that we shouldn't use modern tools, but having a generation of developers unable to do anything outside their chosen layer of abstraction is a sad state of affairs.
Funnily enough my day job is writing software for structural engineers (and I am a licensed engineer). Your comments are absolutely on point. One of the most important discussions I have with senior engineers is "how will we train tomorrow’s engineers, now that the computer does so much work?"
40 years ago, the junior engineers were the calculators, using methods like moment distribution, portal frame, etc… today the computer does the calculation using the finite element method. Engineers coming straight out of school are plunged right into higher level work right away - the type of work that junior engineers a couple of generations ago might not have seen for 5-10 years.
My first career development discussion with a senior engineer was "Just work for 10-15 years, then you'll know what you need to be a good engineer."
I have discussed this under the theme of Generation Gap (https://www.youtube.com/watch?v=5gqz2AeqkaQ&t=147s, 2:27 - 8:58), and have a similar conclusion to you: what at first appears as a different generational approaches are actually different facets of a well-rounded, senior technical skill set. Maybe the kids are just learning things in a different order than we did?
Simon Wardley would like a word…in his model this is the natural order of things. As technology matures and standardized and a new generation of tools is built on top of new abstractions, and the details of that tech no longer need to be understood in order to use it.
Subjects and skills that were requisite basics a generation* ago, become advanced, under the hood topics for specialists. The next generation of people need different skills in the day to day.
This post is a great account of what that feels like from the inside, from the perspective of the newer generation learning these (now) ‘advanced’ topics.
(Funnily enough, I don’t (yet) see anyone commenting "real men write assembler" - a skill that has long ago moved from required by all developers to super-specialized and not particularly useful to most people.)
*I am using the word generation in the broadest sense as it relates to cycles of technology
It appears that the two controls are physically linked, but have a 'fuse' mechanism. When the two pilots apply lower forces to their controls, the forces are transferred between the controls and they 'fight' each other to move the sticks. After a certain threshold (50 lbs?), the two controls move independently.
In all cases, the flight computer works of the average of the two sticks. When they are in sync, this works great. In a situation like this one, where the pilots are pushing in opposite directions, the average will all of a sudden, be quite different from both controls.
> the project owner is always, in the end, responsible for the success of a project
This is very relevant to large government construction projects in the public-private partnership model (aka Alternative Financing and Procurement). These go best when the project sponsor (the gov’t) thinks clearly about what risks the private partner is best places to manage and transfers those risks to them (e.g. managing lots of construction sub trades), while retaining the risks that they are best placed to manage.
It becomes very expensive when the sponsor just tries to throw all the risk over the fence. As the author says, this gets expensive - either through change order or sometimes even in the upfront cost. If you pitch a risk to someone who is badly placed to manage it or who cannot quantify it upfront, they will cover their risk with a big fee.
You can shuffle the risk, but you can’t make it go away.
Professional business people are familiar with different business models, and when to apply them.
For instance, hourly billing makes a lot of sense if the scope is vague - the client carries the scope risk.
Fixed price is amazing when the client has a specific, measurable problem that they don’t know how to fix (but you do). You can solve it cheaply, get paid waaay more than hourly and have a happy client.
Being a professional means having multiple tools in your toolbox and knowing how and when to use them. Drafting contracts is all about deciding how the risk will be shared - you need the right risk-sharing model for each situation.
Property taxes are usually set as a fixed amount to be collected, and the tax % is back calculated. In practice, this means that the only thing that matters is the value of a property relative to the rest of the city.
> The configuration schema default was changed to "all", but the runtime fallback in extensions/git/src/repository.ts still calls config.get('addAICoAuthor', 'off'). This is now out of sync and can lead to unexpected behavior in contexts where the contributed configuration defaults aren't loaded (e.g., some tests/hosts), and it makes the intended default unclear. Update the runtime fallback to match the schema default (or omit the fallback so the contributed default is used).