Reddit Programming – Telegram
Reddit Programming
212 subscribers
1.22K photos
125K links
I will send you newest post from subreddit /r/programming
Download Telegram
C3 Language at 0.7.5: Language tweaks and conveniences
https://www.reddit.com/r/programming/comments/1n5u6qy/c3_language_at_075_language_tweaks_and/

<!-- SC_OFF -->Just released C3 0.7.5! For those unfamiliar, C3 is a systems programming language that takes a different approach than Zig or Odin in the "better C" space. (What makes C3 different: Evolutionary, not revolutionary, tries to stay close to C while fixing its pain points. You can learn it quickly if you know C. Compile-time introspection and programming without too much complexity. Modern conveniences (slices, error handling, defer, operator overloading) that compile down to what you'd write by hand. Familiar syntax - No need to relearn everything) This release adds: Module aliasing: alias io = module std::io Compile-time ternary: $debug ??? "verbose" : "quiet" Better macro system with optional parameters Tons of QoL improvements Demo stream (https://www.youtube.com/watch?v=OuZBxdM_YEI) | GitHub (https://github.com/c3lang/c3c) <!-- SC_ON --> submitted by /u/Nuoji (https://www.reddit.com/user/Nuoji)
[link] (https://c3-lang.org/blog/c3-language-at-0-7-5-language-tweaks-and-conveniences/) [comments] (https://www.reddit.com/r/programming/comments/1n5u6qy/c3_language_at_075_language_tweaks_and/)
Tried parsing invoices with GPT-4o, Claude Sonnet 3.5 & Invofox API (Python). Here's what I found.
https://www.reddit.com/r/programming/comments/1n5yf2b/tried_parsing_invoices_with_gpt4o_claude_sonnet/

<!-- SC_OFF -->I wanted to see how easy (or messy) it really is to extract structured data from PDFs with code. So over the last month, I tried a few approaches (using Postman & Python) and thought I would share on what worked, what didn’t and what ended up being worth the effort. a) DIY Workflow with GPT-4o and Claude 3.5 Both OpenAI’s GPT-4o and Anthropic’s Claude models are surprisingly good at understanding invoice layouts (if you give them the right prompt). But there were a few annoying steps: You have to run OCR on every PDF first (I used pdfplumber) Then, it’s all about prompt engineering. I spent a lot of time tweaking prompts just to keep the JSON consistent. Sometimes fields went missing or labels got weird. Both models respond fast for short docs, costs are similar (~$0.01 per normal invoice using 1-2k tokens) and outputs look clean most of the time. b) Invofox API (specialized models) tuned for invoices. You can upload the PDF straight away. OCR, page splitting, document classification are all handled behind the scenes. The schema is extracted automatically from what you expect from an invoice. Validation, error handling, even “confidence scores” for output fields are built in. This is great at automating invoice parsing at scale (bulk files, mixed documents). I also used Postman for this case, along with python code. complete code: repo (https://github.com/Anmol-Baranwal/doc-parsing)
full detailed writeup: here (https://www.invofox.com/en/post/document-parsing-using-gpt-4o-api-vs-claude-sonnet-3-5-api-vs-invofox-api-with-code-samples) This was mostly a side experiment out of curiosity. If you had to parse documents in a side project, would you rely on GPT/Claude + prompts or go straight for a specialized API? <!-- SC_ON --> submitted by /u/anmolbaranwal (https://www.reddit.com/user/anmolbaranwal)
[link] (https://www.invofox.com/en/post/document-parsing-using-gpt-4o-api-vs-claude-sonnet-3-5-api-vs-invofox-api-with-code-samples) [comments] (https://www.reddit.com/r/programming/comments/1n5yf2b/tried_parsing_invoices_with_gpt4o_claude_sonnet/)
I built a Debounce vs Throttle Interactive Visual Simulator on my blog
https://www.reddit.com/r/programming/comments/1n69gja/i_built_a_debounce_vs_throttle_interactive_visual/

<!-- SC_OFF -->I created a Debounce vs Throttle interactive visual simulator. It's a farm that spams animals when you press a letter on your keyboard. You can see how these design patterns behave in real time next to each other. Furthermore there is a brief table that summarizes the differences and also some images that explain each pattern separaretly I hope you find it useful. <!-- SC_ON --> submitted by /u/prox_sea (https://www.reddit.com/user/prox_sea)
[link] (https://coffeebytes.dev/en/javanoscript/debounce-and-throttle-interactive-explanation/) [comments] (https://www.reddit.com/r/programming/comments/1n69gja/i_built_a_debounce_vs_throttle_interactive_visual/)
The Hidden Vulnerabilities of Open Source
https://www.reddit.com/r/programming/comments/1n6e94p/the_hidden_vulnerabilities_of_open_source/

<!-- SC_OFF -->Exhausted volunteers maintaining critical infrastructure alone. From personal experience with contributor burnout to AI assited future threats, here's why our digital foundation is crumbling. <!-- SC_ON --> submitted by /u/gamunu (https://www.reddit.com/user/gamunu)
[link] (https://fastcode.io/2025/09/02/the-hidden-vulnerabilities-of-open-source/) [comments] (https://www.reddit.com/r/programming/comments/1n6e94p/the_hidden_vulnerabilities_of_open_source/)
Korean Open APIs (With English Translations)
https://www.reddit.com/r/programming/comments/1n6k8nm/korean_open_apis_with_english_translations/

<!-- SC_OFF -->I created a public API collection repository because I was tired of searching for open APIs all over the place while working on projects. It includes the latest (2025) English translations of Korean open APIs. To keep the links fresh, I also added a routine that regularly checks them, so everything stays stable and reliable. Feel free to take a look around, and any feedback is always welcome. Thanks! <!-- SC_ON --> submitted by /u/ybmion (https://www.reddit.com/user/ybmion)
[link] (https://github.com/yybmion/public-apis-4Kr) [comments] (https://www.reddit.com/r/programming/comments/1n6k8nm/korean_open_apis_with_english_translations/)
Error handling with linear types and automatic concurrency? Par’s new syntax sugar
https://www.reddit.com/r/programming/comments/1n6m0iz/error_handling_with_linear_types_and_automatic/

<!-- SC_OFF -->What’s the story of error handling if resources aren’t automatically droppable and expressions evaluate concurrently with their consumers? Does explicit cleanup and no call-stacks allow for convenient error handling syntax? Par is my programming language (https://github.com/faiface/par-lang) with linear types, automatic concurrency, and all-in-all is based on classical linear logic. Recently I’ve added more I/O functionality, which made me realize that manually case-ing on all Results leads to losing passion for programming. So, with all these new usecases in front of my eyes, I came up with a convenient error handling syntax that fits the unique constraints of Par: linear types and automatic concurrency. It is similar to Rust’s way in some aspects, but also quite different. Check it out: https://faiface.github.io/par-lang/error_handling.html What do you think? Would you be happy using this syntax? A small example: def Main: ! = chan exit { let console = Console.Open catch e => { console.print(e) console.close exit! } let path = Os.PathFromString("logs.txt") let try writer = path.createOrAppendToFile writer.writeString("[INFO] First new log\n").try writer.writeString("[INFO] Second new log\n").try writer.close(.ok!).try console.close exit! } <!-- SC_ON --> submitted by /u/faiface (https://www.reddit.com/user/faiface)
[link] (https://faiface.github.io/par-lang/error_handling.html) [comments] (https://www.reddit.com/r/programming/comments/1n6m0iz/error_handling_with_linear_types_and_automatic/)