Hacker Newsnew | past | comments | ask | show | jobs | submit | discreteevent's commentslogin

This is the same in any system where you have two different runtimes/programming languages. The source values need to be serialized to bytes and then deserialized by the target. You could use json for this or flatbuffers. WASI has its own serialization mechanism but I don't know what langugages it supports.

Do you think that LLMs will do much to help to alleviate this?

I just did a major refactor of a project to move it many versions up on a framework and whole process was effectively vibe coded. I'd estimate I did in a couple of days what would have taken a couple of weeks.

That's good and expect that could be shaved down even more. I was spending most of time just waiting for it do the work.

But I don't know if that fundamentally changes the situation or not. We've had steady improvements in developer technology for decades. Even pre-LLM, I'm building significantly more complicated applications now in less time than ever before. But as quickly as our developer technology improved, the demands on applications we build has gone up. I'm not sure even LLMs can outpace the demand for software.


Thanks for your honest opinion. Not sure why you were downvoted.

Likely because some people don't like to hear about positive experiences with LLMs.

I don’t get it either. I feel people are increasingly knee-jerk about downvoting, triggered by certain phrases, perhaps „vibe-coding“ in this case.

> "in my days, we had books and we remembered things" which of course is hilarious because today you can't possibly retain ALL the knowledge needed to be software engineer

Reading books was never about knowledge. It was about knowhow. You didn't need to read all the books. Just some. I don't know how many developers I met who would keep asking questions that would be obvious to anyone who had read the book. They never got the big picture and just wasted everyone's time, including their own.

"To know everything, you must first know one thing."


Which books? Did they not read them?

I would rather live in a world where I can put a raspberry cheesecake in my fridge occasionally. Because I know how to enjoy cheesecake without having to buy it every week. Not a world where when I pick the cheesecake off the shelf in the store someone says "Raspberry cheesecake! You may be one of these people who is lacking in self awareness so let me guide you. Did you know that it might be unsafe! Are you sure it's going to lead to a better outcome?"

A programming language forces a culture on everybody in the project - it's not just a personal decision like your example.


I think I see it slightly differently. Culture is complex: I would not generally use the word “force” to describe it; I would say culture influences and shapes. When I think of force I think of coercion such as law and punishment.

When looking at various programming languages, we see a combination of constraints, tradeoffs, surrounding cultures, and nudges.

For example in Rust, the unsafe capabilities are culturally discouraged unless needed. Syntax-wise it requires extra ceremony.


"The notion of an interface is what truly characterizes objects - not classes, not inheritance, not mutable state. Read William Cook's classic essay for a deep discussion on this."

- Gilad Bracha

https://gbracha.blogspot.com/2022/06/the-prospect-of-executi...

http://www.cs.utexas.edu/~wcook/Drafts/2009/essay.pdf


Let's make the interface so special that it gets its own file type. Let's say '.h' for "header".


There's this quote from Robert C Martin (Uncle Bob)

> Structured Programming imposes discipline on direct transfer of control. Object Oriented Programming imposes discipline on indirect transfer of control. Functional programming imposes discipline upon assignment. Each of these paradigms took something away. None of them added any new capability. Each increased discipline and decreased capability.

The interface (or extensible class) enables safe indirect transfer of control.


> so code was always more “writing” than “gears” to me… It was ALWAYS “magic.”

> I suddenly realized why half of all developers hate AI-assisted coding (I am in the other half).

Thanks for this. It helps me a lot to understand your half. I like my literature and music as much as the next person but when it comes to programming it's all about the mechanics of it for me. I wonder if this really does explain the split that there seems to be in every thread about programming and LLMs


Can you tell when code is “beautiful”?

That is an artful quality, not an engineering one, even if the elegance leads to superior engineering.

As an example of beauty that is NOT engineered well, see the quintessential example of quicksort implemented in Haskell. Gorgeously simple, but not performant.


As a PM working with team leads is so cumbersome...


I wish I could automate PMs :-p


You don't actually use it but somehow you know that "running GUI apps on the JVM isn't the best for 1000 [unspecified] reasons".

- This isn't a scientific approach.


You clearly don't know how Swing or Eclipse SWT works under the hood.

Java's big strength is that it's a memory safe, compiled, and sandboxed low level platform with over a quarter century of development behind it. But it historically hasn't handled computer graphics well and can feel very slow and bloated when something needs that - like a GUI. That weakness is probably a big reason why Microsoft rewrote Minecraft after they bought it.


I don't why this post is downvoted. My cynical reply to yours: "No, this isn't a scientific approach. It is the tin-foil hat HN approach!"


FYI Casio recently brought out a minimalist series of the F-91W (same watch - just a bit less chrome on the face) e.g. https://www.casio.com/europe/watches/casio/product.F-91WB-1A


There was a really good article on this here a few days ago that didn't get much traction. It was about how programming is a learning feedback loop and because of that there are good and bad ways to use LLMs:

"The readymade components we use are essentially compressed bundles of context—countless design decisions, trade-offs, and lessons are hidden within them. By using them, we get the functionality without the learning, leaving us with zero internalized knowledge of the complex machinery we've just adopted. This can quickly lead to sharp increase in the time spent to get work done and sharp decrease in productivity."

https://martinfowler.com/articles/llm-learning-loop.html


This is a great read and one which for me personally really summarises my feeling on developing with LLMs.


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

Search: