标签：#programming

submitted by /u/parametric-ink [link] [留言]

submitted by /u/Motor_Ordinary336 [link] [留言]

Introduction It's crazy to me that some GitHub repos, that were just created in the last...

Building software that can change itself without needing to be recompiled is a hard problem, and the reflection architectural pattern is a solid answer to that. I published an article diving into the reflection architectural pattern. If you've ever wondered how Spring Boot uses annotations to magically wire your dependencies, or how ORMs map database fields without explicit code, reflection is the answer. I break down how this pattern actually works, show practical examples, and discuss when you should and shouldn't use it. submitted by /u/Netunodev [link] [留言]

Everyone is hyping up local-first architecture because of Linear’s speed and the flack Notion is getting for its half-baked offline mode. Keeping data on the client sounds amazing for UX, but the engineering trade-offs are brutal. Unless your users are literally working in tunnels or you have strict privacy requirements, local-first feels like a massive over-engineering trap. Managing CRDTs, conflict resolution, and running database schema migrations across thousands of fragmented user devices is an absolute nightmare. Notion's struggles proved that trying to bolt offline support onto a legacy cloud-first DB just doesn't work well. I wrote a deeper breakdown on the strategic trade-offs and what the sync problem actually costs to solve here: https://buildmvpfast.com/blog/local-first-saas-offline-first-vs-cloud-first For most apps, a boring Postgres stack lets you ship fast and validate the product. You can worry about complex sync layers later. For anyone who has shipped a production local-first app, was the snappy UI worth the infrastructure headache? I'd love to get some feedback and hear your war stories on this. submitted by /u/Timely-Ad-2615 [link] [留言]

submitted by /u/lelanthran [link] [留言]

Originally published at Perl Weekly 777 Hi there! In the recent weeks I looked at a lot of MetaCPAN profiles (aka. author pages) such as that of MANWAR . If I could also find their LinkedIn profile I invited them to connect via LinkedIn . (If I have not sent you an invitation yet, then I guess I missed your profile. I'd be glad to get a connect request via LinkedIn.) I noticed that a large percentage of the people still have their @cpan.org email address listed. Despite the fact that cpan.org email forwarding has been shut down 6 weeks ago. That means people will get annoyed if hey try to contact you using that address. You could replace that address or hide it and offer other ways for people to contact you. Either of them is better than having a bad address. In addition, I noticed that some of the links people have there are not working. (e.g. incorrect link to their LinkedIn profile, or to their home page etc.) In order to fix these you probably first need to check and update your PAUSE account . After logging in look for the Edit Account Info menu option. There you can list your email address and you can even decide if you'd like to have a visible address or not. Then you could take a look at your MetaCPAN profile. For this visit MetaCPAN . Login in the top-right corner. If you don't remember whether you used GitHub or Google, don't worry. Inside you can connect them in the Identities menu point. Then go to the Profile menu point and update the fields there. Finally, if you have updated your profile after reading this, I'd be glad if you sent me an email so I'll know this messaged had some positive impact. Oh, and if you don't have a CPAN account and you have not uploaded anything yet, then what are you waiting for? Enjoy your week! -- Your editor: Gabor Szabo. Articles Time::Str - Time Zones and Leap Seconds Time::Str parses and formats date/time strings across 20+ standard formats, with an optional C/XS backend and nanosecond precision. The previous post, Intro

submitted by /u/noteflakes [link] [留言]

Most bad decisions in software engineering aren't made because the engineer chose wrong between two...

Plug a sensor into a switch, wire up a building full of cameras, or rack a server, and you are using Ethernet. It is the most widely deployed wired networking standard on earth, the quiet backbone under offices, factories, and data centers. And it is named after a scientific idea that turned out to be completely wrong. The name was not an accident or a marketing afterthought. It was a deliberate engineering choice, and the reasoning behind it explains why Ethernet outlived nearly every rival and still underpins industrial IoT half a century later. A memo, a laser printer, and a dead theory The date Ethernet enthusiasts celebrate is May 22, 1973. On that day, a young engineer named Robert Metcalfe, working at Xerox's legendary Palo Alto Research Center (PARC), circulated a memo describing how to connect the Alto - one of the first personal computers - to a new device PARC had built: the laser printer. The problem was getting many machines to share one wire without their messages colliding into noise. Metcalfe needed a name for the shared medium that carried the signals. He reached back into nineteenth-century physics and borrowed the term luminiferous ether . For generations, physicists had assumed that light, being a wave, needed something to wave through - just as sound needs air. They called that invisible, all-pervading substance the ether, and they believed it filled the entire universe as a silent carrier of electromagnetic waves. The trouble is that the ether does not exist. The famous Michelson-Morley experiment of 1887 failed to detect it, and Einstein's special relativity in 1905 made it unnecessary altogether. By the time Metcalfe wrote his memo, the luminiferous ether had been a discredited idea for decades. He used it anyway, and on purpose. Why a debunked idea made for brilliant engineering Metcalfe later explained the choice plainly: "We called it Ethernet because the ether could be coax, twisted pair, radio, optical fibers, power line, whatever you wa

submitted by /u/BlondieCoder [link] [留言]

Hello, I'm Shrijith Venkatramana. I'm building git-lrc, an AI code reviewer that runs on every commit. Star Us to help devs discover the project. Do give it a try and share your feedback for improving the product. Every developer eventually discovers the same frustrating pattern. Your application sends a 20,000-token prompt to an LLM. The first request takes 2 seconds. The next request contains the exact same 20,000 tokens plus a tiny user message at the end. And somehow the model processes the entire thing again. At least, that's what many developers assume. Modern LLM systems have a trick called prompt caching that can dramatically reduce latency and cost by reusing work from previous requests. But unlike traditional application caches, prompt caching isn't storing generated text. It's storing something much deeper inside the model. To understand how prompt caching works, we need to follow a prompt all the way through the transformer itself. The Expensive Part of Processing a Prompt When a prompt enters a transformer model, it isn't immediately generating text. First, the model must process every input token through every layer of the network. Imagine a prompt like: System: You are a helpful coding assistant. Project Documentation: [20,000 tokens of documentation] User: How does authentication work? Before generating a single output token, the model performs: Tokenization Embedding lookup Multi-head attention Feed-forward networks Layer normalization ...across dozens or even hundreds of transformer layers. For a large model, this preprocessing is often more expensive than generating a short answer. If another user asks: System: You are a helpful coding assistant. Project Documentation: [Same 20,000 tokens] User: Explain the database schema. Most of the prompt is identical. Without caching, the model would recompute everything from scratch. Prompt caching exists to avoid that waste. The Key Insight: Cache Internal Transformer State, Not Text A common misconception

submitted by /u/TheBigCore [link] [留言]

submitted by /u/swe129 [link] [留言]

Here is how interview goes every single time. Interviewer asks a question: what are the basic principles of OOP? Interviewer always assumes that the answer is "inheritance, encapsulation, polymorphism". These concepts were popularized and have direct connection to C++. C++ was designed by Bjarne Stroustrup. If I try to say that Stroustrup himself said that he didn't invent OOP [1] and try to talk about Simula, Smalltalk and Alan Kay's definition of OOP I always have a concerned look from the interviewer. I'm tired. I don't even have deep understanding of history of programming languages. It's just a one google search that leads to Wikipedia article[2]. It's common knowledge. Why it's a problem every time a have an interview? --- [1] Wired speaks to Bjarne Stroustup : Please note that my claim to fame is not to have invented OOP. I did not - that honour belongs to the designers of Simula: Ole-Johan Dahl and Kristen Nygaard - but I did have a major hand in making it mainstream. [2] https://en.wikipedia.org/wiki/Object-oriented_programming#History submitted by /u/FG3149 [link] [留言]

submitted by /u/der_gopher [link] [留言]

submitted by /u/lucian-12 [link] [留言]

It's widely accepted that as AI writes more and more of our code, opportunities decrease for newcomers to gain the skills needed to become professional programmers. At the same time, experienced people bemoan the way AI is causing them to gradually lose the skills they took so long and worked so hard to gain. Programming, like mathematics and perhaps music, sits in the middle between science and art. As science, it's all about capturing and organising knowledge, and as art, it's the application of creativity to problem-solving. Enjoyment - deep satisfaction or an emotional rush - can be had from either or both of these. But the perception is that AI is depriving us of opportunity, both to learn and to be creative. Code written by a human reveals a lot about the coder. Their depth of knowledge of the coding language, their creative use of variable and function names, and even the visual layout of a script. You can often tell at a glance whether the writer truly cared about the code they wrote, or whether it was just a means to an end, to ensure their next pay packet arrives on time. As AI improves, it makes fewer mistakes, but it also produces code that is increasingly hard for any human to read and truly understand. Since the job of a human in the coding loop is increasingly not to write but to validate code, this is becoming a problem. So here's my recent story, a series of happy accidents. I've been using agentic AI for about a year. First with Copilot in VS Code, then more recently with Claude Code at the command line. At the start, I found Copilot to make a lot of mistakes and to produce rather repetitive, poorly-structured code, but looking back, a lot of that was probably down to my own ignorance of how to control the process. The biggest problem I had was in validating JS or Python code. There was just so much of it, often using features of both languages I never fully got to grips with. I've never been a first-class programmer and most of my own code is pure

submitted by /u/PGurskis [link] [留言]

submitted by /u/Sushant098123 [link] [留言]