This is a problem for folks with sensitive data, and also for coorporate users who don't want their data being used for it due to all kinds of liability issues.

I am sure they will have a coorporate carve out, otherwise it makes them unusuable for some large corps.

LLMs help a lot in doing 'well defined' tasks, and things that you already know you want, and they just accelerate the development of it. You still have to re-write some of it, but they do the boring stuff fast.

They are not great if your tasks are not well defined. Sometimes, they suprise you with great solutions, sometimes they produce mess that just wastes your time and deviates from your mission.

To, me LLMs have been great accelerants when you know what you want, and can define it well. Otherwise, they can waste your time by creating a lot of code slop, that you will have to re-write anyways.

One huge positive sideffect, is that sometimes, when you create a component, (i.e. UI, feature, etc), often you need a setup to test, view controllers, data, which is very boring and annoying / time wasting to deal. LLM can do that for you within seconds (even creating mock data), and since this is mostly test code, it doesn't matter if the code quality is not great, it just matters to get something in the screen to test the real functionality. AI/LLMs have been a huge time savers for this part.

I get the impression that the software scenarios where LLMs do the best on both reliability and time-saving are places where a task was already ripe (or overdue) to be be abstracted away: Turned into a reusable library; as as a default implementation or setting; expressed as a shorter DSL; or a template/generator script.

When it's a problem lots of people banged their head against and wrote posts about similar solutions, that makes for good document-prediction. But maybe we should've just... removed the pain-point.

Well, at least it is a video. Meta had its layoffs with emails when they did all those rounds in 22-23 and 24. You got an email if you were safe, and another if you were terminated plus some links to some portal etc. Plus, there was some video/zoom call for some I think.

Anyways... modern corp culture, don't expect too much from larger companies. Once a company grows beyond a certain limit, it becomes impersonal as it has to.

Macromedia Fireworks was the modern predecessor of these tools that ushered web graphics back in the dot com days. It was bought by Adobe, and shuttered around 2009.

I loved that tool

Still keep a machine on Mojave to use FW CS 6 and will probably eventually have a VM running it to use it, it’s a distinctive combination of features.

Next is a Superman videogame being blocked because it goes against the 'policies/interests' of a country that manages to lobby a lot here.

You seem to be sarcastic but there's plenty of countries that have stringent laws on what games are and aren't allowed.

Well you know Superman shouldn’t fight against genocidal maniacs and instead should fight for them. Then we wouldn’t have to ban him and infect we can all celebrate him.

It is still incomplete and a mess. I don't think they thought through the actual main cases Swift is used for (ios apps), and built a hypothetical generic way which is failing on most clients. Hence lots of workarounds, and ways to get around it (The actor system). The isolated/nonisolated types are a bit contrived and causing real productivity loss, when the old way was really just 'everything ui in main thread, everything that takes time, use a dispatch queue, and call main when done'.

Swift is strating to look more like old java beans. (if you are old enough to remember this, most swift developers are too young). Doing some of the same mistakes.

Anways https://forums.swift.org/t/has-swifts-concurrency-model-gone... Common problems all devs face: https://www.massicotte.org/problematic-patterns

Anyways, they are trying to reinvent 'safe concurrency' while almost throwing the baby with the bathwater, and making swift even more complex and harder to get into.

There is ways to go. For simple apps, the new concurrency is easy to adopt. But for anything that is less than trivial, it becomes a lot of work, to the point that it might not make it worth it.

Their goal was always to be able to evolve to the point of being able fully replace C, Objective-C and C++ with Swift, it has been on their documentation and plenty of WWDC sessions since the early days.

You're getting downvoted but I fully agree. The problem with Swift's safety has now moved to the tooling. While your code doesn't fail so often at runtime (still does, because the underlying system SDKs are not all migrated), the compiler itself often fails. Even the latest developer snapshot with Swift 6.2 it's quite easy to make it panic with just... "weird syntax".

A much bigger problem I think are the way concurrency settings are provided via flags. It's no longer possible to know what a piece of code does without knowing the exact build settings. For example, depending on Xcode project flags, a snippet may always run on the main loop, or not at all or on a dedicated actor all together.

A piece of code in a library (SPM) can build just fine in one project but fail to build in another project due to concurrency settings. The amount of overhead makes this very much unusable in a production / high pressure environment.

1.So far, it is great if you know what you want, and tell it exactly how you want it, and AI can help you on that (basically intern level work).

2. When you are in a new area, but you don't want to dive deep and just want something quick and it is not core of the app/service.

But, if you are experienced, you can see how AI can mess things up pretty quickly, hence for me it has been best used to 'fill in clear and well defined functionality' at peacemeal. Basically it is best for small bites, then large chunks.

What's your track record. What is your current scope of work for Claude Code?

This conversation is useless without knowing the author's skillset and use-case.

> pride in "craftsmanship, control issues, and perfectionism

sounds like you can't code for shit. guidelines, standards, and formatting have developed for a reason. the reason is: less bugs and maintainability. you sound like the average cocky junior to me.

> pride in "craftsmanship, control issues, and perfectionism

I mean, do we really want our code base to not follow a coding standard? Or are network code not to consider failure or transactional issues? I feel like all of these traits are hallmarks of good senior engineers. Really good ones learn to let go a little but no senior is going to watch a dev automated or otherwise, circumvent six layers of architecture by blasting in a static accessor or smth.

Craftsmanship, control issues and perfectionism, tend to exist for readability, to limit entropy and scope, so one can be more certain of the consequences of a chunk of code. So to consider them a problem is a weird take to me.

Buying in NYC is just wild. A condo can have a 400$/mo tax, while the next door one is 1300/mo, and the other one down the street can be only 35$/mo for the first 20 years.

There is also a mortgage tax of 2.05% for a loan, which is batshit crazy as it favors rich 'cash only' people, instead of middle class / poor folks. Also, everything over 1m has a 'mansion' tax, where a 1m gets you one bedroom, without even a washer and dryer, and also there is a 'new building tax' which is another 1% or 2%.

For a 'not new' smallish 2bdr, 800sfq, in Greenpoint, the cost of purchase was 1.3m-1.35m and just the closing costs (taxes and all) was 55K! Just to buy a place (not talking about downpayment and all).

With a current rates, you'd end up paying 9k-10k for a basic (10 years old) 2 bedroom, which is insane at any levels.

Anways, end of my rant. The city needs to both build more, and lower taxes for residents, and raise them for anyone that is not a NY resident. Period. But the builders have resisted this, and Cuomo the coorporate stooge gorvenor we had vetoed/ended a initiative to have good taxation that favors residents.

Building more and giving tax breaks to anyone (even foreginers/non state residents), is just a hand out to developers, and 1/3rd to those apartment will be used a 'storage' for outside money. Locals loose on this.

So true... out of the 5 games I have bought on steam, I have played 2 (one fully), and installed and just played briefly 1, and two other never even installed.

Agreed... in most large (non trivial systems) REST ends up looking/devolving closer to RPC more and more and you end up just using get and post for most things and end up with a REST-ISH-RPC system in practice.

REST purists will not be happy, but that's reality.