OrbStack has its own virtualization layer designed to simulate Docker. Containerization has different primitives even though it supports the same OCI images
Docker Desktop/Obstack start a single VM that runs all your containers. This means that you'll have to scale it accordingly. Davit uses Apple Containers that runs a very thin VM for each container you spin up. Depending on your use case it's more, less or equivalently effcient.
Problem is, usually describing the problem you want to solve *correctly* using formal tool is a task as hard (and often, equivalent to) the implementation. That said, having a formal description is useful
For some problems, yes. Formal specification is particularly useful in two cases. 1) The problem is simple but an efficient implementation is hard or bug-prone. Examples are garbage collection, file systems, sorts, databases, and tree updating.
2) The inverse of the problem is simpler than the forward operation. Examples include matrix inversion and parsing.
I wouldn’t split it like that. Formal verification is useful in the case that the spec is simpler than the implementation. That’s it.
Coming up with simple specs is not necessarily easy. You could say that is kind of what math is about. That’s how we actually make progress: find those cases where simple specs are possible and build upon them. That’s the kind of library made for eternity.
It could still be useful if the spec is roughly as hard as a simple implementation, in case you have automated methods to find more efficient implementations, guided by the constraints of the spec
Which is still a case of the spec being simpler than the implementation (you are after) ;-)
Very often, the spec is indeed just a very simple implementation. Often you can make the spec especially simple if there are no constraints on the resources it can use, at times even infinite ones.
Exactly, LLM is good at "code inpainting" : define clear structures and goals, and it will fill the boilerplate. But it doesn't work for reasoning and abstraction, so it fails to synthesise and propose novel views. But that's integral to the way it's designed and has been trained, to do a kind of "averaging" which limits it's capacity to explore novel designs
> But it doesn't work for reasoning and abstraction, so it fails to synthesise and propose novel views
I disagree. Have a conversation with it about your problem and work through design decisions with it. When I do that, I find it gives me a lot of good ideas.
Disclaimer: I'm not working on anything groundbreaking (like most people)
Yes, but "good ideas" compared to what? If you were aware of the better alternatives, you probably wouldn't be discussing those details with an LLM. You'd find that it just randomly gave you one. It might work, but you don't know how well until you're already entrenched.
Nobody knows everything, so of course LLMs can be useful sometimes. More useful than plain old search, books, or even discussion with real humans? Maybe.
Search can offer a much broader context than an LLM hyperfocused on just generating text. Books may lead you to realize you were asking the wrong questions. Discussions will provide an overall "vibe" of the topic.
These are not competing options. We can and should be using all of them when possible.
If we are going to use the GPS analogy, not every trip is a route or even paved. GPS is notoriously unreliable when on a hike. You have to be a lot more careful than that.
Most real world software tends to be exactly that kind of situation. You need the rest of the business to help decide every detail of a service that will be in production long term. You are not just on a hike. Business is conquest. You are setting up camp with the lofty goal of scaling to a settlement, then a town, etc.
This sounds dramatic, but I think many are too easily impressed/jaded. Some people can't believe it, but this is still very early days for software. We're barely at the point where, maybe, the layperson can just about build small trivial gadgets for themselves. Meanwhile, there are people out there sailing the seas and beyond.
Sure, if you're one of the few that is building something truly novel, I agree AI will not be as useful to you.
That's why I added the disclaimer above: I'm not working on anything groundbreaking (like most people).
And I disagree with your premise overall, because I think the overwhelming majority of software development is much more like driving on a paved highway than it is like hiking through unmarked forest. Which is exactly why AI works so well: it's trained on thousands of examples of very similar solutions to very similar problems.
All of the hard work has already been done by people before us. We have the luxury of sitting down in front of incredible hardware, operating systems, fully designed languages, optimizing compilers, IDEs to fill in the blanks for us, and now AI to write up entire programs for us - none of which we had anything to do with the creation of. All we need to do is hook things together and slap on a layer of paint.
> the overwhelming majority of software development is much more like driving on a paved highway than it is like hiking through unmarked forest
The difficulty comes from meeting the exact requirements and providing a reliable result. Would you be so sure of this opinion if the requirement was to write "a simple CRUD app", but it had to integrate with a poorly documented legacy system and was for a big client with an SLA that could sink the business? Many devs find themselves in that exact situation all the time. What you end up writing, with AI no less, is tomorrow's poorly documented legacy system.
You don't know what you don't know. I'm reminded of stories where people from Europe traveled to America and underestimated how massive it is. They thought "just a few 5 hour roadtrips" sounded relaxing. They overlooked the details and found themselves falling asleep at the wheel, thirsty/hungry, and backtracking for hours.
> Would you be so sure of this opinion if the requirement was to write "a simple CRUD app", but it had to integrate with a poorly documented legacy system and was for a big client with an SLA that could sink the business?
Yes, because I think the underlying patterns are the same. Get data, move it around, serialize/deserialize it, store, query, present. It's very unlikely I'm going to run into some new pattern that's never been seen in code before. This is exactly where I think devs are giving themselves too much credit.
I'm not saying AI can do it without my help either, I'm just saying is that it can help me do it better and faster than I could have done without it.
The majority of code isn't there to merely be functional.
I agree that you could use AI to write the core functionality from scratch... or you can choose from one of dozens of available mature libraries that people have been using for at least a decade.
> This is exactly where I think devs are giving themselves too much credit.
Nobody is trying to take credit for libs they didn't write. Unless they're working solo, they rarely take credit for the code they do write either because the ideas came from the rest of the team and broader business needs.
Developer expertise is more like that of a bureaucrat than a craftsman. That has been true for a very long time. Those who are more interested in their tools and what they can do rather than what they draft for approval have always been the weakest devs.
What's most unfortunate is when someone charismatic and lacking experience jams their ideas through and makes a mess. This is the real reason you cannot get rid of the humans. There always has to be a bigger seamless plan. Humans are better at context and have much more of it.
Sure but you can also google your problem and check what is industry standard/what is the correct way to do things (imo in less time than it takes to go through a conversation).
But the problem is that when you ask ai to solve a problem on its own, its default plan can suck. You can mitigate that by research and context but it doesn't mean the initial problem is solved. But even that requires skill and human judgement (both ai conversation research or traditional research) and a lot of people want to skip that entirely.
I find I don’t necessarily need or want AI to give me ideas, but I would agree having a conversational back and forth generally yields decent results.
I have found being Socratic in my questions, and trying to get the AI to arrive at my intended design via such conversations supplies the right level of context for properly solving the problem. It’s token intensive, without a doubt, but I find the result is the AI tends to be better equipped to handle the many micro decisions that need to be made along the way.
The contrast to this is I give it a detailed prompt where it then asks questions of me, which also generally works but I find the AI tends to not be as well equipped for decisions it needs to make mid implementation.
It’s not perfect, and maybe not even a good fit for some. I also never know what to think when people tell me their idiosyncratic ways of using AI. Ultimately I think the most effective way is whatever lets you translate the vision in your head into the end result.
That’s not the core of the argument. You know that.
I’m putting things into perspective for people who are terrified that the last drops of their potable water and going to be used to generate a meme video.
Yes. Because a few golf course are produced every 10 years / 20 years or so. But people generating videos is going to increase exponentially. So this is going to be a huge difference
The fact that EVERYBODY here sees it but you, tells you that perhaps you should take a step back and try to understand... it might be YOU who don't get it at all...
Folks, we're now 5 levels deep on this thread and I still haven't heard it spelled out what's wrong.
I see "it's obvious" "cringey" and allcaps being used. Being able to vocalize specific problems and having the courage to clearly state it is a life skill.
Please be specific about the problem and why. Bonus points for replacement suggestions.
The boys-fight-for-girl is a very typical movie trope and this is a scene-based product. Maybe that's why they defaulted to it.
Well, here goes. The "story" told shows a woman as something men possess ("Backoff! She's mine!".) She even asks "do I get a say?" (hah, as if!) and is ignored, of course. If two men want to possess the same woman, they get into a physical fight, where the winner gets to own the woman. Oh, plot twist! She "decides" for the nice guy (lucky her, getting a man!)
Do you seriously think this is a story still worth telling? Is that how you view women? Is that how you view men?
But since you asked specifically about someone spelling it out letter by letter for you:
Women are not a prized possession, but individual humans, like men. You do not "take" them, you don't "fight over" them, you don't "own" or "win" or "loose" or "deserve" them - because they are not objects, but humans. They can also decide to pick neither of the two men if they so desire, and pursue a career in neuroscience.
Men who disagree over something do not, in fact, need to hit each other immediately, or throw rocks to their heads. They have the ability to talk and listen to reason. Because they aren't chimpanzees, but sapiens, a species with extraordinary capable brains.
Regurgitating this very trope, which works just as well with aforementioned chimpanzees instead of humans, proliferates the stereotypical depictions of women and men. Science is very clear about the fact that repeated exposure to an idea increases acceptance of this idea, so telling the tale of boys-fight-for-girl time and time again ensures its firmly planted in people's heads, influencing their view on other people negatively.
Women are exposed to severe violence all around the world, every day. If you don't believe this, I don't feel obligated to convince you with any particular slice from the mountain of freely available scientific material on the topic. Alternatively, for a fun little experiment, consider asking five female and five male relatives or friends each about the three worst things they can imagine happening to them on the way home at night. No spoilers, but the answers are going to be very different.
+1 This is a good if verbose response and the points and questions will be easy for the library author to address.
I'm going to take "you" here to mean the author instead of myself b/c I already found the example distasteful for reasons similar to yours.
> But since you asked specifically about someone spelling it out letter by letter for you:
You took time to do this and I appreciate it. I like to think you're teaching others how to respond clearer. I hope we can see this level of organized thought and direct challenge at the top level instead of reactionary slang and huffing.
I think you're discounting people's reaction of not liking it. That is communicative. Not everything has a well established model to communicate efficiently using words.
And being a trope is not enough of a defense; tropes can drift away from culture over time.
The demo is not egregious by itself, it's the choice of the demo for this circumstance. Why boy-hits-boy-with-rock-for-girl for an animation DSL?
Yes, even reworking a classic "infra diagram" with connection between a web browser and a server, but showing it as an animation could be interesting, but those little stories add very little
The fact that people in the tech-world don't realize that they are embodying deeply ingrained sexist / toxic behavior is the reason why women aren't more present, and why people like Musk or other sociopaths have been celebrated by this community, while the rest of the world hate them...
Yes. It’s astonishing how I see individuals with these enormous egos centered on their intellectual, technical achievements, who have such egregious blindspots surrounding their own unethical attitudes and behavior.
Sirs, please turn the apparatus upon itself. Question yourself as a part of a larger system. What is your function among members of your own species? How can you falsify your hypotheses on this subject? Please don’t be so incurious.
