It's often ignored because not all people get to work on interesting new features or care about the customers. This is all cool and dandy if you're a founder or working a job where the actual product is interesting, but most jobs are boring with no actual incentive or even a way how to care about the customer and then making it at least technically interesting in some aspect is a way not to go insane.
Just playing the devil's advocate here. I would prefer using boring technology that gets the boring work done as quickly and easily as possible anyways, but that's because I have more fun doing other things than working.
I think it is important to point out that boring tech is not Java 8 or .NET 2.0 that some companies are stuck with.
There is still lots of interesting stuff if your company uses newest Java or newest .NET but both are „boring” in a good way so mostly stable and changes to those are incremental and progress is stable.
Heck Angular with its latest improvements in v17 and v18 is quite interesting - but counts as totally boring and stable tech. Migration to signals and standalone components is a bit of a hassle but still is rather easy.
While I prefer wired keyboard as well (due to not having to deal with pairing / connection issues), this argument I don't understand:
> Firstly the board is completely wireless, which means I have to charge it via USB-C. As I'm sat practically tethered to my desk all day a permanently wired option would actually be more convenient as it would save me to the hassle of charging.
Then plug the USB-C cable in permanently? How is it different from it having a wired keyboard?
Plugging in the USB-C cable is for charging only, so it would still be a wireless connection. I'd still need to connect via bluetooth or the Logitech dongle. I won't get any of the benefits i.e. latency / lower power consumption of using a wired connection.
I also have concerns about the charger degrading the battery if it's completely plugged in.
That's not what the post is about. They describe the process as mostly fixing issues with existing software, so the motivation is that something is broken or not working as required anymore.
Refactoring it is just one of possible parts of the process, much opposed to 'yeah this legacy code is broken dogshit and needs to be rewritten even though the current software is already written, proven and works for 99% of the stuff we need' approach.
Not directly, but kinda, at least in my experience.
Clients and management generally understand that old code needs to be maintained. They don't love that reality, but that's not generally a tough sell unless they're completely clueless. And they're usually not completely clueless.
The tension in my experience comes when an engineer wants to perform something other than the fastest, sloppiest, filthiest duct-tape maintenance imaginable.
Management accepts the need for fixes, but often does not have the technical/___domain knowledge to understand the short- and long-term merits of Proposed Fix A versus Proposed Fix B. And naturally, incentives heavily push management toward the quick fixes by default. Time is money, after all. And managers are expected to meet quarterly and annual OKRs. We don't have a good way to quantify the long-term value of a "proper" fix versus a "duct tape" fix. And so on.
So for me maintenance work is difficult to separate from notions of longer-term software maintenance such as refactors, dependency upgrades, etc.
I personally don't believe refactoring should ever be part of "maintenance".
Maintenance needs to avoid YAGNI and avoid the engineers natural desire for over-engineering and unnecessary perfect polishing and abstruse abstraction.
Refactoring is something that should be driven by new features (or worst case towards rewrite), and few have the skill to do it well.
I'm not arguing the sibling strawman that maintenance be "the fastest, sloppiest, filthiest duct-tape maintenance imaginable."
Excelling at maintenance is highly skillful work and often poorly rewarded.
Well, I certainly agree that engineers tend towards YAGNI and this must be avoided.
Refactoring is something that should be driven by
new features (or worst case towards rewrite),
This overlooks a whole other class of factors that can drive maintenance: changes in the environment.
Assuming we're talking about a program that does something useful and isn't just a screensaver, it's probably ingesting data from the outside world. That data can change in a variety of ways. API partners and users can introduce changes on their end and will eventually find new and annoying edge cases. Or maybe the volume of data increases by 100x and changes must be made on your end.
Or maybe your software sort of rots as the security vulnerabilities pile up. Eventually you've got to make major version or point upgrades to the framework and/or various dependencies.
We want to handle these demands judiciously and as a rule, yeah, refactoring isn't generally going to be the answer but sometimes it is.
> I personally don't believe refactoring should ever be part of "maintenance".
Of course it shouldn’t, because software maintenance does not exist. Programs don’t degrade with use. All “maintenance” on software is, like new development, the implementation of new context->behavior combinations, and calling it something different is a result of applying an inappropriate physical-product metaphor.
There are several activities in software that are similar to maintenance of physical products. e.g.
* that parsing library that you used 2 years ago and was in good working order then, is now outdated and has known vulnerabilities that are not present in the latest version, apply update.
* Those cloud-hosted databases that you use are an older version that the cloud vendor has deprecated and will some time withdraw support for, apply migration to a later one.
It also works just while plugged in so there is no downtime. I feel like I charge it couple times a year by any random usb-c that is on my table at the moment while I keep using it.
Even if it didn't, it takes maybe 1-2 minutes to charge for the rest of the day so there is no disruption.
I'll just have to guess the reimagined IDE is not longer very text-centric given that without proprietary JavaScript the page is just a green background.
Not yet, but I'd expect we'll eventually get there. Code always remains the source of truth and thus will have its place in every IDE for finer control, but I imagine shifting our primary interaction with code from the editor panel to an agent controller can become a powerful models once these agents become very good. A neat way to think about this is code reviews.
When I give a task to another developer on the team, they go out to understand the task, work on it, write tests, run everything and put it up for review (which is then also auto-evaluated by CI first). In this scenario, as a reviewer, we already don't have an absolute need to read every line of code as long as high level design/project principles are followed and all scenarios are covered in tests that are passing.
AI agents can become this other developer picking up and completing end-to-end tasks, but rather than taking hours/days, they take a few seconds/minutes at best — so review comments can actually be shared and incorporated quicker within the IDE itself.
This only sounds like a 'problem' because the lisp dialects are so similar that you would almost expect them to be the same, no?
That seems like a nice feature - you know Common Lisp so you have to only learn some nuances to write PicoLisp effectively.
When it comes to the c-family of languages, you wouldn't expect a complaint about having to be aware of the differences between C and JavaScript since you can't even entertain the idea that they are all that similar.
Not the OP but would somebody be able to summarize HOW are the lisp REPLs different then to me?
I've written limited amount of clojure and common lisp just to play around and I don't recall any difference between Clojure REPL and the REPL I get for say Kotlin inside IntelliJ idea.
Maybe the ability to send expression from the IDE into the REPL with one keybind but I cannot say it's not possible with the Kotlin one right now because that's not what I use it for.
Thanks, I forgot about this aspect of live program editing. Whether or not it's possible (or how close just quick live reload) is to this it' definitely not a first class citizen like you presented. It also reminds me of Pharo (or maybe just smalltalk, I've only played with Pharo) where you build the program incrementally "inside out".
It does make me wonder how aplicable this way of programming is to what I do at work but that is more because of the technologies and architectural choices where most of the work is plumbing stuff that is not local to the program itself together. And maybe even for that with the edges mocked out it would make sense to work like this.
Again, interesting video that made me think. Thanks.
Being able to interactively update code in response to an error, without leaving the error context and being able to restart stack frames (not just a “catch” or top level, as in most languages) is one of the key features that makes REPL-driven development possible. Or at least that’s how I see it.
It’s not something you always need to use, but it can be handy, especially for prototyping and validating fixes.
There's a person above saying that it's about being to able to mutate program state from the repl, which is a thing that's also possible in any repl for a language with managed memory.
Not just from the REPL, but from the REPL in the context where the error occurred, without having to structure the code ahead of time to support this. It’s not always an important distinction, but it’s handy when prototyping or if the error is difficult to reproduce.
There are some other affordances for interactive programming, such as a standard way to update existing instances of classes. I’m sure you could implement this sort of functionality in any language, but this is universal and comes for free in Common Lisp.
CL also has other interesting features such as macros, multiple dispatch, compilation at runtime, and being able to save a memory snapshot of the program. It’s quite unique.
Cl Condition system + repl = godmode. Your software crashes? Do you go back and set a breakpoint? No, because you’re already in the stacktrace in the repl exactly where the crash occurred. You fix the code, reload it, tell it to ether run where it left off, or restart from an earlier point.
That is definitely not the same. I write a lot of python code and the interpreter / interactive development is just not as good as it is in Common Lisp.
To my knowledge there’s no real “mainstream” language that goes all in on interactive development. Breakpoints and traceback are all perfectly cromulent ways to debug, but it’s really not the same, sadly.
Your math is too simple. Consider alternative scenario where you invest your down payment and what you save on mortgage (generally slightly more expensive), invest what you save on extra repairs / maintenance.
After those 30 years it's entirely possible that as a renter I have:
- been able to take advantage of moving freely for personal or economic reasons
- been able to move to a newer completely renovated apartment number of time for no costs other than moving my stuff instead of either paying for it or living in a house with a 20 years old kitchen
- been able to live without stress about all the responsibilities that come with owning a house, being in debt and tied down
- come out with enough money from my S&P500 that I started 30 years ago to decide to settle down somewhere and buy the house or continue as is with bunch of money saved up
I am not saying that this is what will always happen or that owning a house is strictly worse but the "rent is money down the drain, mortgage payments is money you keep in the end" angle is way too naive.
You must be a much better investor than I am. On property I have to date never lost a dime, and made pretty good money every time I bought something and held on to it for at least five years. But on other investments the returns have been all over the place, from tripling my money to losing it all and everything in between.
If you don't have a home that you own yet and your only options are mortgage or renting I'd pick the mortgage any time, but I'd always make sure to buy in a market that is active.
It sounds like I might be in this case. We're talking decades. You are talking about various investments and even making sure to time the mortgage to beat the market.
I am talking about putting the money in S&P 500 and similar without trying to time, beat or track anything.
You always bought property in or nearby city centers then. My mom's house lost 10k (~5%) in value in 10 years. Not an issue at all, but rural houses do not appreciate as much as the worst ETFs
> been able to live without stress about all the responsibilities that come with owning a house
A lot of renters report that being forced to move house regularly is a huge source of stress.
> rent is money down the drain, mortgage payments is money you keep in the end
Mortgage is paying rent on a house-sized chunk of money which you have to spend on a house. Economically they're similar. Except the US has a big tax advantage which is only available to morgagors. (Does it also have the home capital gains tax exemption?)
> I am not saying that this is what will always happen or that owning a house is strictly worse…
In my adult life I have lived in ten rental properties and have purchased two homes (currently living in one of them). In my cases of home ownership, my property values increased enough over the time I lived in those properties that you could theoretically view the monthly outlay of my mortgage and taxes as nearly a zero sum game. However rent was always an expense and the amount of investment income I made on a theoretical “down payment” amount across the terms of those leases would not come close to erasing the rent I paid.
I realize this is anecdotal and specific to my ___location and frankly luck, but for me it makes having a mortgage make sense financially.
Things must be really different in the US then.
The downpayment here is really not an amount that you can make any serious investment with. Even if I made it I could not afford to put it in high-risk/high reward investments and the low risks ones are not even worth the cost of blocking the money.
- I can still move freely for whatever reason i want. I simply sell the house and buy a new one.
- the cost of changing a kitchen once in 20 years in your example but even once in 10 years is insignificant and the fact that I choose it according to my needs instead of getting whatever I find more than make for the cost.
- I have no stress of needing to move (generally the more flexible rent agreements that allow you to move out whenever you want also come with the risk of getting kicked out or rent changing significantly)
But again all comes down to the difference of rent vs mortgage and here in Europe for most people the difference does not make sense. let's talk specifics.
Let's say rent is 700eur/Month and mortgage is 800Eur/Month. the difference is less than you would spend for frivolous, spur of the moment things.
But this ignores taxes. Also most renters don't save and invest they consume whatever they have left each month sometimes more. Owning a house with a mortgage forces you to save. Given real estate price trends over history throughout the world, do you want to be long or short it?
The explanation that made the most sense to me is that, for people who for whatever reason, don't tend to invest budget surplus, buying a home leads to better outcomes on average. It keeps the lifestyle creep at bay with minimal mental load.
How do you calculate the monthly savings of renting vs mortgage? E.g, how do you decide how much more to put in the S&P500, than would have been possible if you had a mortgage?
Kinesis freestyle is pretty cheap. I bought the mechanical one which is more expensive but don't use it. I'm too comfortable with microsoft ergonomic keyboard with light membrane keys https://www.microsoft.com/en/accessories/products/keyboards/... of which I have three.
The only issue with the microsoft one is that it has to fit you since it is split but one piece. With a fully two piece split keyboard you can adjust it to your needs.
Fertility is definitely not below replacement rate. Maybe in western countries.
You find it hard to say it's unfair but you seem to hint to it. I don't think it is in the slightest.
Also you sound like a software developer from the US so you likely can afford to work say 80% and "recoup" some of that free time.
Yes, I meant in the West, where much of the high-tech work the article is about.
Well of course I feel it's unfair at some level! That is indeed why I made the comment.
Assuming we want society to continue, someone has to have kids. And while of course we don't want to force individual people to have kids, we should (again assuming we do want humanity to continue) probably try to achieve some kind of balance to where large swathes of people don't self-select out of having kids due to economic/career reasons.
And if the working spouse tries to shed home responsibilities to help them focus on their career, this simply promotes inequity, both sex-wise (since more women are stay-at-home spouses than men) and class-wise (wealthier people will be able to hire additional help, while poorer people will not).
Just playing the devil's advocate here. I would prefer using boring technology that gets the boring work done as quickly and easily as possible anyways, but that's because I have more fun doing other things than working.