However, we’re still implementing IPv6, so how long until we could actually use this?
We can already use custom verbs as we please: we only need to have clients and servers agree on a contract.
What we don’t have is the benefit of high-level “batteries included” web frameworks doing the work for us.
I often felt that current ML speeds up newbie devs by effectively teaching them the language and libraries — but slows down experts that already know the stack well from memory.
It depends. You don’t need LLMs to write stuff for you that you already know. You use them to take.care of the drudge work or explore things you are not familiar with. Things like Copilot’s /explain can speed up onboarding even for seasoned developers, and Copilot can also help you speed up iterations on proofs of concept. For example, I’ve been using Copilot to experiment with some changes to the software architecture of some projects I own, and it’s fantastic at generating code following specific design patterns. It’s also fantastic to get it to iterate designs in near-real.time by prompting it with directives such as “repeat the last example but implementing X with design pattern Y and moving the implementation to Z”. You are presented with examples that you can browse through and get a taste of what you’d get, but with a fraction of the time. To top things off, you can prompt Copilot to present pros and cons and even propose optimizations.
Like any tool, it has its purposes. You just need to learn how to use it.
I don’t use chat, it’s usually useless.
I think Chat is the most useful feature of Copilot. Prompts like /docs work impeccably, but /explain and /optimize is also pretty good. /tests is hit-and-miss if you have zero tests and require too much context if you already have them. More often than not /fix is a waste of time.
Where I found Copilot to be quite useful is something unexpected: naming things. You can prompt it to give suggestions, you can ask it to refactor things for you. Quite nice.
I think that Claude is far better at generating code, and explore new stuff, but Claude is also down and broken extremely often,not to mention it’s annoying limit of 10 questions per half a day.
I use chat the most. It’s pretty good once you understand the importance of building context, set up personas, and feed it workable prompts. The biggest mistake I see people do is presume that you can expect it to output gold when inputting garbage.
Once you build up an understanding of what personas work for your personal tastes and what context you need to have, it can output impressive results. The most success I’ve been having is with somewhat complex refactorizations. Stuff like “refactor X so that Y and Y” can save you a lot of time.
The most disappointing experience has been with writing unit tests. copilot has this infuriating tendency to remove old tests when you’re prompting it to add new ones. You need to explicitly request it to append tests to file X without overwriting existing tests for it not to mess up, and even then results are sketchy. For unit tests it’s also important to setup good contexts otherwise whatever time you save by prompting copilot to write them will be wasted refactoring code to use specific frameworks and follow specific styles.
Like most have already said, the auto complete is top tier (…)
My experience is the exact opposite. Even though it has its moments, more often than not it just hallucinates and proposes a lot of stuff that neither matches definitions nor could possibly compile. I guess that this might reflect the impact of having classes with similar names in multiple namespaces but it’s bad to the point I prefer to rely exclusively on plain old autocorrelation.
I’m a scientist, and “Not a real programming language” gives me big vibes of arguing that a thing is a science
CSS is not a programming language. Neither is HTML.
This, however does not take away from its importance or the skillsets and expertise required to use it effectively.
What a weird belief: thinking the value they bring to a project is tied to whether they use programming languages or not. The majority of people working with programming languages are already bad at it. Why is it being used as a badge of honor?
Is this a “living in glass houses” scenario?
I wholeheartedly agree: the article is just plain stupid.
What I find more amusing is that front-end work ends up being the most critical work in any user-facing application. Apps can still lumber around if big chunks of backing services are down, but if a page is rendered poorly or a button is showing up weird, or if text is missing in a place everyone looks at, that’s automatically a SEV1 right there.
Unbelievable.
Mercure’s spec has a bit more meat on its bones in terms of providing an adequate description of the protocol.
From https://mercure.rocks/spec :
Mercure provides a common publish-subscribe mechanism for public and private web resources. Mercure enables the pushing of any web content to web browsers and other clients in a fast, reliable and battery-efficient way. It is especially useful for publishing real-time updates of resources served through sites and web APIs to web and mobile apps.
Subscription requests are relayed through hubs, which validate and verify the request. When new or updated content becomes available, hubs check if subscribers are authorized to receive it then distribute it.
I don’t think anyone believes that you are a list of well known apis.
shhh don’t raise suspicions.
From the whole blog post, the thing that caught my eye was the side remark regarding SPAs vs MPAs. It was one of those things that people don’t tend to think about it but once someone touches on the subject, the problem become obvious. It seems that modern javascript frameworks focus on SPAs and try to shoehorn the concept everywhere, even when it clearly does not fit. Things reached a point where rewriting browser history to get that SPA to look like a MPA is now a basic feature of multiple pages, and it rarely works well.
Perhaps it’s too extreme to claim that MPAs are the future, but indeed there are a ton of webapps that are SPAs piling on complexity just to masquerade as MPAs.
What does this GitHub Action offer anyone that one of Microsoft’s official Docker images doesn’t provide already?
In DDD, the model is loaded before any business logic is executed
That’s really not a DDD requirement. Having a domain model does not require you to preload data to run business logic. For example, you can easily have business logic that only takes as input a value object and triggers a usecase, and you do not need to preload anything to instantiate a value.
So cool. Curious, Why do they need to specify that the project has to be implemented in Rust?
Possibly because some people think that, much like MongoDB, Rust is web scale.
From the announcement:
The premise of chiseled containers is that container images are the best deployment vehicle for cloud apps, but that typical images contain far too many components. Instead, we need to slice away all but the essential components. Chiseled container images do that. That helps — a lot — with size and security.
I’m glad that Microsoft is being mindful of how they are delivering .NET container images. However, this announcement feels like a large marketing effort to spin a failure into a win. The need to provide lean container images is as old as Docker itself, and Alpine-based images are synonymous with lean images. A very basic security measure in containerized applications is to not ship stuff you don’t need. Microsoft’s container images are indeed quite big without no good justification.
It’s nice that Microsoft is fixing the problems they’ve been creating, but I’m baffled by the effort they are making to make believe this is something new or even a new concept.
Thanks for the info. Interesting.
Also worth mentioning, Ubuntu 23.10 already ships with .NET 8.
Do note that .NET 8 also introduces a couple of features to WPF:
Does this mean that WPF is not dead?
I imaging trying to be a professional electrical engineer (despite having a degree)
That’s the definition of specious reasoning, and fails to address the point I made.
This might be relevant to the discussion:
Custom methods won’t have the benefit of being dealt with as if they shared specific semantics, such as being treated as safe methods or idempotent, but ultimately that’s just an expected trait that anyone can work with.
In the end, specifying a new standard HTTP method like QUERY extends some very specific assurances regarding semantics, such as whether frameworks should enforce CRSF tokens based on whether a QUERY has the semantics of a safe method or not.