Hacker News new | past | comments | ask | show | jobs | submit login

I feel like in the early stages of becoming a programmer, learning how to do all those little baseline problems is fun.

But eventually you get to a point where you've solved variations of the problem hundreds of times before, and it's just hours of time being burnt away writing it again with small adjustments.

It's like getting into making physical things with only a screwdriver and a hammer. Working with your hands on those little projects is fun. Then eventually you level up your skills and realize making massive things is much easier with a power drill and some automated equipment, and gives you time to focus on the design and intricacies of far more complicated projects. Though there are always those times where you just want to spend a weekend fiddling with basics for fun.




That should be when you move to more sophistcated (and also complex/complicated) languages that relieve you from as much of this boilerplate as possible.

The rest is then general design and archiceture, where LLMs really don't help much with. What they are really good for is to get an idea of possible options in spaces were you have little experience or to quickly explain and summarize specific solutions and their pros and cons. But I tried to make it pick a solution based on the constraints and even with many tries and careful descriptions, the results were really bad.


I think it is not the boilerplate of the programming language necessarily, but it is more to do with boilerplate of common business logic. E.g. even say form validation, I have done it countless of times and I can't be bothered to write out rules for each field again, but AI can easily generate me Zod schema with reasonable validation based on the database model or schema. It probably does better validation rules than I would do quickly on my first try.

Then I use these validations both in the backend and frontend.


There is nothing that stops a good PL from doing the same. In fact, that is why languages like F# support a concept called "type provider".


I'm talking about web/app UI validation, are we talking about the same thing?

Does F# provide ability to display validation errors with good UX to users using your app? How does it know what user friendly error messages look like?

Okay very simple example prompt that will generate 100+ lines of code.

"Give CRUD example using shadcn, react-hook-form, zod, trpc to create an example of a TODO app"

Which programming language would be able to replace the UI at this level of quality and how the UI looks?

Now this is very basic example, and it's a "todo app" without existing project, but I find it can give me a lot various different 100+ lines of boilerplate, from charts to sql explorers, to much else.

Also most web app developers and especially juniors usually have terrible error, loading, validation handling, and SOTA seems far superior to that, handling those cases everytime with ease and most intuitive error messages.

It will patiently always do "isLoading", checks for error, etc.


I'm not saying that this is a solved problem today. And yeah, llms are also helpul here.

What I meant is that this can be solved by a good language. But you would have to use F# (or another language with a feature like type providers) on the frontend.


It seems like F# is more like a type safety tool from arbitrary untyped data for developers rather than what I'm talking about though?

But even TypeScript can infer types in many cases?


Typescript can infer a lot of types, but you cannot read an SQL file at compiletime (with custom logic) and make it generate types that you can then use.

You have to generate those types as source code (like you basically do with the llm).

In F# and other languages, you can generate those types on the fly and use them. It can even go as far as describing errors with sql columns. Then, if there is any mismatch, the project won't compile. And if you add a new field, the code and validation will automatically work.


Completely agreed. Don’t be afraid to embrace this. You have to give it an active month until it starts to work in your hands though.




Join us for AI Startup School this June 16-17 in San Francisco!

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: