I don't recall ever returning anything.
I don't buy that much stuff in general, but I feel like having the ability to just buy and return stuff makes you end up with more junk.
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.
