morsecodist

Totally agree but I would expand location into convenience. For example, I find restaurants that don't take reservations or have limited hours are often better.

In my head I have a category for reliable restaurants to go to when you are planning something with people and you want to make sure to have a consistent, predictable experience and restaurants that are worth waiting for or going at a weird time.

It seems the answer in this article is reasoning models are expensive and they are becoming the norm.

Reasoning/chain of thought seem like diminishing returns to me and I worry they are a bit of a dead end/local optimum. Reasoning models call the language models tens of times so it will be tens of times less efficient than the underlying language model but the quality is not tens of times better. It also feels finicky to me. The bump from Chat GPT-3 to Chat GPT-4 was a reasonable positive shift across the board. The reasoning models produce answers with a different vibe, maybe better overall but worse at some tasks better at others. I can use O1 at no additional cost so I do use it fairly often but I often consciously opt for 4o either because I prefer the results of the quality boost from O1 isn't worth the wait.

The burden of proof is on the positive claim. Even if I were to make the claim that another human was reasoning I would need to provide justification for that claim. A lot of things look like something but that is not enough to shift the burden of proof.

I don't even necessarily think we disagree on the conclusion. In my opinion, our notion of "reasoning" is so ill-defined this question is kind of meaningless. It is reasoning for some definitions of reasoning, it is not for others. I just don't think your shift of the burden of proof makes sense here.

I was a bit broad here. I am sure certain projects get things better than others. When I said no place I was more referring to whole categories of development like, front-end, back-end, embedded, data pipelines, ect...

I love types and advocate their use whenever possible. They help a lot but they are a spectrum. Thanks to static analysis tools like TypeScript or even eslint you can get a bit towards automated checks on front end code. Also even compiled languages can miss some things, different languages have type systems that give you different kinds of guarantees. For example, Java has NPEs that can't be caught at compile time.

There is really no place where updating dependencies is dramatically better. Back end frameworks and even whole languages have this problem. On the front end, I mostly use React and it has been fairly backwards compatible. It's a tradeoff. If you never ever make breaking changes you can end up constrained by previous design decisions. If you make them all the time users won't be able to keep up.

Weeks is the most terrifying unit of time to think in. Short enough so you have a good sense of how long it feels but long enough to add up quickly.

I've set up and run my own physical Linux server as well as cloud ones and it may be easier to get a Linux box up and running with an application but to get it into a state I consider production ready it's much harder. With ECS (or similar offerings, I agree kubernetes can be overkill) you get logging, blue green deployments, permissions, secret management, scaling, and more built in. You don't need to worry about upgrading your server and there's a whole category of security issues you don't really need to worry about. I work in a space with some compliance requirements and I do not think we could meet them at the size that we are without offerings like this.

As a user I like to pick models. Maybe I am using them wrong but I actually find reasoning/chain-of-thought models worse at some things, even things they are supposedly better at like coding. They are also buggier in my experience and an order of magnitude slower.

This also doesn't bode well for AI progress. It feels like the kind of thing you release if you want to release something but haven't made much progress on improving the fundamental language model. Even chain of thought itself, while interesting, is a bit disappointing compared to language model improvements. It is more comparable to automated prompt engineering than a fundamental improvement of the model to represent knowledge and problem solving. This development seems to be doubling down on this direction.

Benchmarks are meaningless in and of themselves, they are supposed to be a proxy for usefulness. I have used Sonnet 3.5, ChatGPT-3, ChatGPT-3.5, ChatGPT-4, ChatGPT-4o, o1, o3-mini, o3-mini-high nearly daily for software development. I am not saying AI isn't cool or useful but I am experiencing diminishing returns in model quality (I do appreciate the cost reductions). The sorts of things I can have AI do really haven't changed that much since I got access to my first model. The delta between having no LLM to an LLM feels an order of magnitude bigger at least than the delta between the first LLM and now.

Even if the technology of AI ends up driving a huge economic value there is no guarantee that will translate into NVIDIA stock performance. The expectation that NVIDIA will capture a lot of this value is already priced in to the stock, which is a major reason why the current price is so high.

I would say the more a given app/feature has network effects the more invested I am in it being cross-platform. For example, iMessage and Facetime are highly social. Apple was resistant to adopting the RCS protocol for iMessage, though they eventually caved and now the experience of texting between iPhones and Androids is better for both parties so it seems preferable to me.

Meanwhile, we take it for granted that there is a protocol for audio calls and text messages but not for video calls. I would like to more easily video call people with iPhones, and doing so would be technically possible but I can't because Apple benefits from the network effect. If I were to get an iPhone it would not be because Apple did a better job at creating a video call feature, it will be because people I know have iPhones and I want to call them. This seems like it gives incumbents in the space a large advantage because they can compete on having a user base and not on quality.

Ironically, Apple itself developed such a protocol for events and RSVPs (ICS), at a time when they didn't have market dominance. This caught on and it is great. I can make a calendar event in Google Calendar, Outlook, or Apple Calendar and invite anyone from any of those platforms. They can RSVP and I can track their RSVPs and they can also create events in their systems and invite me. This is the kind of thing I like to encourage where possible.

I think that's preferable to them being totally unable to RSVP but you're still going to be the friend that can't make the invite. It's comparable to iMessage. You can still talk to Android users but it's a notably worse experience.

Unfortunately, I have to hope this doesn't see widespread adoption. If this becomes the standard it will just add to already existing social pressure to get an iPhone in the US.

I appreciate posts that are about practical usage of AI and it's strengths/weaknesses and the kind of conversation it generates. Conversations about AI are tough for me to navigate because there are camps of people that seem very invested in AI being either omniscient or completely useless. I regularly see people saying that AI is at the level that it can replace engineers or build whole apps. When I try this with state of the art models, I am seeing results that are nowhere close. That said, I still use AI every day during my development and I have a flow I think makes me way more productive. I want more conversations like this about the mechanics of using AI as it currently, and honestly evaluating it's strengths and weaknesses without getting into hypothetical debates about the future or whether or not the AI "understands".

At least in my experience as soon as something goes a little wrong it just gets worse from there. The more of it's confusion and contradictory information are in the chat history the worse it gets. It also has to make changes to the code so you accumulate these spurious changes and the problem gets more confusing. I've had some luck starting over with a new chat asking what is wrong but if that doesn't work I just assume I'm on my own.

Designing the metric of success is the hard part. The magic of LLMs is that they can learn a lot with unlabeled data and a relatively simple cost function. They can be trained the mountains of data we just have lying around without a ton of additional labeling or making clever domain-specific metrics.

If this approach doesn't really generalize well, it negates a lot of the usefulness of these methods and suggests we are further away than we might think.

IAC is one technology I will defend to the hilt. IAC is difficult because the underlying problem it is trying to solve is hard. Different people over time are making updates to a mission-critical, stateful, system that need to be coordinated with each other.

IAC is complicated, tedious, poorly documented, risky to deploy, and never perfectly aligns with what is actually going on in production but it is still better; a lot better. Manual infrastructure is also all of these things except you have nothing to grab onto if you are trying to understand an environment and what is safe to change.

If your app is very simple and you can use an out of the box solution, you should avoid IAC. But the moment you want to do something custom you need it.

My issue isn't just with the names themselves but they are emblematic of AWS's overall mentality. They want to have the AWS(TM) solution to X business case while other cloud providers feel more like utilities that give you building blocks. This obviously works for them and many of their customers I just personally don't care for it. It is probably to do with the level of complexity I am working at (*which is not very complex).

Also, I don't think trying to emulate AWS's support and consistent API makes sense as a strategy for other cloud providers. They will never beat AWS at their own game, it is light years ahead. If cloud providers want to survive they need to fill a different niche and try different things.

> Picking AWS over Google Cloud

I know this is an unpopular opinion but I think google cloud is amazing compared to AWS. I use google cloud run and it works like a dream. I have never found an easier way to get a docker container running in the cloud. The services all have sensible names, there are fewer more important services compared to the mess of AWS services, and the UI is more intuitive. The only downside I have found is the lack of community resulting in fewer tutorials, difficulty finding experienced hires, and fewer third party tools. I recommend trying it. I'd love to get the user base to an even dozen.

The reasoning the author cites is that AWS has more responsive customer service and maybe I am missing out but it would never even occur to me to speak to someone from a cloud provider. They mention having "regular cadence meetings with our AWS account manager" and I am not sure what could be discussed. I must be doing simper stuff.

I agree that definitions are the problem. It seems the conscious term is overloaded and refers to a lot of concepts some of which are overlapping and some are totally different.

People also want to define conscious in terms of the concept they feel is most importantly different about humans. So this definitions conversation gets mixed with a what concepts are important conversation.

For example, the thing that I think is important is subjective experience. I think this is the most important difference between beings that need to be given moral consideration and those that don't and this is always what I have thought of as consciousness. However, I often have conversations where I am just talking past someone because they are interested in something else entirely. I hope we can start defining this upfront and having separate conversations here.

I have always been pretty skeptical of the value proposition of these companies. We have had prefab construction for decades and you could buy kit homes from the Sear's catalog in 1908. These methods are definitely useful but constructing the actual structures just doesn't seem to be the bottleneck in getting housing built.

I often hear the lack of productivity growth in the construction industry used as a justification for why companies like this are needed but you could also interpret that as the absence of incentives to increase productivity.

I am not quite sure what the bottleneck is, but it seems related to a combination of zoning, the ever-rising cost of land, housing's dual role as a commodity and an asset, a highly fragmented industry with perverse incentives, and interests entrenched by a combination of momentum and policy.

Cool on the clojure API. Functional programing really fits with this sort of thing. Does your implementation limit you to the JVM?

Discussing levels of complexity quickly gets pretty subjective. It is possible that Rama has found good abstractions that hide a lot of the complexity. It is also possible that taking on more complexity in this area saves you from other sorts of complexity you may encounter elsewhere in your application.

However, there is just more going on in an event sourcing model. Instead of saving data to a location and retrieving it from that location you save data to one location, read it from another location, and you need to implement some sort of linker between the two (or more).

This also comes down to my personal subjective experience. I actually really like event sourcing but I have worked on teams with these systems and I have found that the majority of people find them much harder to reason about than traditional databases.

It seems like an event sourcing database. Basically, instead of writing you write a message, then you can make read-only tables that update based on those messages. People do this today in certain domains but it is definitely more complicated than traditional databases.

This is more an advertisement for a type of database than a statement that they are unnecessary.

From what I can tell in the article it seems their differentiator is Event Sourcing and having arbitrary complex index builders on top of the events. It seems similar to EventStoreDB[1].

I have always been interested by the concept of an event sourcing database with projections and I want to build one eventually so it is interesting to see how they have approached the problem.

Also they mention on their site:

> Rama is programmed entirely with a Java API – no custom languages or DSLs.

It makes sense why they have gone this route if they want a "Turing-complete dataflow API" but this can be a major barrier to adoption. This is a big challenge with implementing these databases in my opinion because you want to allow for any logic to build out your indexes/projections/views but then you are stuck between a new complicated DSL or using a particular language.

1: https://developers.eventstore.com/server/v23.10/#getting-sta...

The whole EV experience seems tailored to suburbia where people can keep their car near their home and drive frequently on short trips. Many of them have the EV as a second car to circumvent the road trip issue.

I live in a mildly dense city and a lot of my neighborhood uses street parking. I almost never drive for short trips and a major reason I got a car at all is for longer more infrequent trips. I'd be happy to take a train instead but it is twice the price of flying and takes twice as long as driving. Instead of trains we'll get EVs and their infrastructure subsidized, no matter how much it ends up costing.

It's not just direct subsidy. Some local ordinances now require buildings to provide chargers so people who don't drive will pay more in housing costs.

> It’s possible that all physical processes involve a sensory component

Sure it is possible but we have way more evidence neurons have a sensory component, or at least things made of neurons.

You might find this: https://www.cell.com/neuron/fulltext/S0896-6273(22)00806-6 more interesting. Researchers were able to train neurons to control a pong game.

Putting aside whether or not discouraging investment makes sense as a strategy, it is absolutely wild that this is specific to single family homes. Apartments are unaffordable as well and they are also often owned by funds.

Are people who live in apartments just out of luck then? Discouraging investors from owning single family homes could encourage more speculation on multifamily homes.

You really don't need to think about monads or functional programming to have option and result. The focus on explaining these in the context of sum types and monads only serves to distract most people. A list is a monad and people use them every day and they are fine.

> Having a (val, err) tuple IS more easy than returning a monad.

Arguments about which concept is easier for people to understand pretty quickly descend into subjectivity but I don't believe this is universally true. Why am I getting a value when there's an error? What do I return as my value when returning errors? Explaining to someone that a function returns (val, err) and only one of these values will be significant is more or less the same as describing a result.

Option is even simpler. It's a list that can have at most one item. Or, you know how in python you can set a variable to None? Here's how to do it in a strongly typed language.