mahidhar

Well, unlike a human, I cannot expect any these LLMs to take any ownership of the work they do. I cannot expect any given model and version (sonnet 4.6) to learn, improve and adapt over time. I cannot expect it's limitations to ever go away at the model level. So it is not like a human in most ways that I actually care about.

That said, I can't wait for LLMs to stop being AI and start being just another tool. Anything cursed with the "AI" label seems to go through this mess. In the earlier AI cycles, rules engines were considered "human-ish" and got hyped up, but today we just see then as just another tool available to us, and we're better off for it.

I remember watching his Google talk[0] several years ago while learning vim. RIP and thank you for your contributions.

[0] https://youtu.be/eX9m3g5J-XA

Agreed. Recently I was discussing the same point with a non-technical friend who was explaining that his CTO had decided to move from Digital Ocean to AWS, after DO experienced some outage. Apparently the CEO is furious at him and has assumed that DO are the worst service provider because their services were down for almost an entire business day. The CTO probably knows that AWS could also fail in a similar fashion, but by moving to AWS it becomes more or less an Act of God type of situation and he can wash his hands of it.

If you have a couple of hours to spare, I recommend listening to the episode of the Songhai Empire by the Fall of Civilizations podcast. They go into the fascinating historical background of the Timbuktu scholars and libraries. Link: <https://www.youtube.com/watch?v=GfUT6LhBBYs>

Actually it's pretty weird. This is a sports blog and content engine. And the author is someone who started this publication. I'm not sure what the motivation/context is at all here.

I've generally had a little bit more success with mocking when I'm hiding that dependency behind my own interface. So for example in Java, instead of trying to mock the AWS provided class, I write my own class (like a facade or repository pattern) which has a very simple interface of a success case and maybe a couple of relevant failure cases. It's calling the AWS library within it. But my mocks are at the level of my facade class which I find easier. The drawback is I'm not sure if there's a good general strategy to test the implementation of that facade. Most of the times the implementation is simple enough that I can do some simple integration tests for the most relevant cases, but there's always a risk that I am missing out some weird edge cases and I don't know how to properly deal with that.

Unfortunately, I must agree with you that there are definitely some very troubling implications to how WebAssembly might be used to build more effective walled gardens on the web.

I can easily imagine a "platform" WASM module which acts as a runtime for other WASM modules built by "app" developers. This Platform module can be easily cached by FAANG or other big commercial interests, similar to AMP by Google (maybe even be pre-bundled into the browser?). The only way to discover, download and run these other apps is through this curated Platform module. All this could be rendered through something like the Canvas API instead of the DOM, which again is managed on a low level by the Platform and in turn exposes higher level API's for the Apps. The Platform also has built in support for Ad networks, tracking, etc., which cannot be disabled without disabling the whole ecosystem of apps. And of course, like any good play/app store, it is completely incompatible with anything else, leading to new levels of Balkanization of the web.

I hope that this isn't the case, and I'm completely wrong about this. But I just can't shake the feeling that as a community, we are championing WebAssembly as purely a performance win, without considering how big commercial interests might seek to exploit this new technology.

Edit: typo with AMP

As a fellow web developer, I want to offer a different viewpoint. Firstly, the pros that you listed for the web are equally valid today as they were 7 years ago. But additionally, I want to push back a bit against the "app-ifiction" of the web. I see the web as its own platform, and trying to implement "native" features on it seems counter productive. The web has features which are completely native to it, which are either very difficult, or downright impossible to replicate on Android and iOS apps (proper URL's, standardisations etc., just to give some examples off the top of my head). And yet no one seems to be complaining about that. I understand that this argument comes across as a what-about-ism, but I do genuinely think that the web platform is different, and should be approached on its own terms, rather than trying to mimic an Android or an iOS app experience.

On a higher level, as web developers, I think it is worth remembering that we don't have to build these half broken app experiences. We can still build web sites. We can still open a simple index.html file, put in some markup, and voila, it renders on the browser. We can choose not to implement all the trackers, invasive ads, broken "personalisation" algorithms etc. The fact that these things are implemented on all websites nevertheless is not because of some technical failure of the web platform. I believe it's a human problem of organisational politics, where the business users want these features, and overrule any objections that the developers might have regarding privacy or performance. Additionally, Android and iOS apps also implement these tracking features, with numerous SDK's available to create these marketing funnels that you mentioned. They may not be visible as an ugly badge icon in the top right corner showing how many were blocked, but they are definitely there. At the end of the day, the business/client that we are working for is asking for these things, and we can either try to educate them against these features, cave in and implement these functionalities, or move to a different organization/team/project more in line with our view points. But we cannot solve this with a technical solution like changing platforms.

Finally, regarding the perception that the web is a free and open democratiser, isn't it still one? I can still spin up a web server not hosted on one of the cloud platforms to host and serve my content. Yes, discoverability, scaling etc., are problems, but that's true for practically everything from social media, to e-commerce. Again, from a technical perspective, nothing is stopping us from developing websites or even web apps which are not beholden to commercial and centralised interests. Again, we don't do it, because of "IRL" reasons which don't really have any good technical solutions. In fact, going into the highly controlled and regulated environments of Apple's iOS, and to lesser extent Google's Android, sounds like the exact opposite of free and open.

That being said, if you find that you like working on iOS or Android apps, or you want to build apps which leverage the strengths of those platforms, then go ahead and I hope enjoy it!

So I work with a company where we provide online nutrition consultation to employees from other organisations as part of a larger corporate medical program. Our system has a scheduling system developed in Rails to deal with these appointments. This system was developed by a person who quit the company some time back.

A few weeks back, we got some complaints from a client who said some of their employees weren't getting allotted an appointment slot, despite the fact that the slot is supposedly free. I dived into the codebase to try and figure out the problem. There were some minor bugs which I spotted first, and could fix without using a debugger. But the appointments were still getting dropped occasionally. So I started tracing the control flow more carefully.

That’s when I found one of the strangest pieces of code I had ever seen. To figure out what the next available appointment slot was, there was a strange function which got the last occupied slot from the database as a DateTime object, converted it to a string, manipulate it using only string operations, and finally wrote it back to the database after parsing it back to a DateTime object, before returning the response! This included some timezone conversions as well! Rails has some very good support for manipulating DateTimes and timezones. And yet, the function's author had written the operation in one of the most confounding ways possible.

Now, I could have sat there and understood the function without a debugger as the article recommends. And then, having understood the function, I could have then rewritten the function using proper DateTime operations. But with a client and my mangers desperately waiting for a fix, I used a debugger to step through the code, line by line, just understanding the issue locally, and fixed the bug which was buried in one of the string operations. That solved the problem temporarily, and everyone was happy.

A week later, when I had more time, I went back and again used the debugger to do some exploratory analysis, and create a state machine model of the function, observing all the ways it was manipulating that string. I added a bunch of extra tests, and finally rewrote the function in a cleaner way.

Instead of romanticising the process of developing software by advocating the use or disuse of certain tools, we should be using every tool available to simplify our work, and achieve our tasks more efficiently.

An interesting observation in the article is the data structures DSL that the author goes into quite a bit of detail, which is essentially what most Clojure/Lisp developers also talk about.

Basically the author points out a lot of benefits of using the native serialisable data structures of the language itself to model the domain, instead of creating a separate representation which has to be parsed, optimised, evaluated, etc. Lisp users just take the same idea one step further by having the "host" language also be represented using the same data structures, instead of just the DSL's.

As Alan Perlis said, "It is better to have 100 functions operate on one data structure than 10 functions on 10 data structures."

Agreed. One of the common things I use is git add --patch <file>. This allows me to commit changes in a file under different commits, by staging only the parts of the file that I consider as relevant for that commit. A lot of times I have different conceptual ideas in the same file, and I would have either forgotten to commit them during the day, and only realize it in the evening when it's time to push the code upstream; or those features would have been developed in parallel, because they are codependent, but are not necessarily the same from a conceptual point of view to the project. Either way I would want them under different commits so that my commit log is clean, and each commit can stand on it's own. This is where the --patch flag and the staging area are really useful. It might be a little trickier than just committing all tracked files with changes, but I appreciate the control. However, I do sympathize and agree with some of the points raised in the article, and I think there's definitely a scope for better interface design in git. For example, the stash is something that regularly confuses me, and the solution in the article seems like a better interface.