Skip to content

Piero Bosio Social Web Site Personale Logo Fediverso

Social Forum federato con il resto del mondo. Non contano le istanze, contano le persone

#Reminder

Uncategorized
2 2 12
Feed RSS

Gli ultimi otto messaggi ricevuti dalla Federazione
  • @dwarf right??

    read more

  • @ruby0x1 anyways, tldr my answer is normal human social mirroring behavior and immediacy

    read more

  • @ruby0x1 however I'm not in a position of evaluating such purchasing decisions at the moment, so that case is kind of academic

    read more

  • @ruby0x1 another case where I might consider trying a game engine is as a product evaluation for a for profit project where the tradeoff of having to pay royalties incurs some benefit to the production, such as shipping a game instead of reinventing the universe. In that position, I imagine the attractive points are going to be things like cost of training, availability of paid 1st and 3rd party support, showcase examples of other successful games, and other such things.

    read more

  • @GustavinoBevilacqua praticamente gli idranti della polizia

    read more

  • @ruby0x1 however, that is orthogonal to me simply trying an engine.

    Similarly, I've "tried" unreal engine, because my work continues to pay me lots of money to work on unreal games, which in a way is another form of peer pressure. I've considered giving it a try for some small personal projects on the theory that it might be beneficial to broaden my holistic knowledge of the engine beyond what my day to day work calls for, but so far I've decided that my work/life separation is more important.

    read more

  • @ruby0x1 I also tend to shy away from things where there is the appearance of a major time investment developing a set of skills that I would have to pay rent on. So for example, I learned Blender geometry nodes instead of learning Houdini despite being under the impression that Houdini is probably the superior procgen tool. Like wise I've spent the better part of year reinventing audio from first principles instead of buying Reaper or whatever.

    read more

  • @ruby0x1 in the absence of being accidentally embedded in an enthusiastic community, I tend to be very sparing about taking up new tools at all, and tend to limit myself to tools that are available under permissive open source licenses if the tool does something I'm convinced I would not enjoy implementing myself (eg I'm gonna probably use kissfft instead of implementing my own fft, whenever I next have a problem that is best solved with an fft)

    read more
Post suggeriti
  • 0 Votes
    1 Posts
    9 Views
    When did you last finish a tech book? 📚50% of devs don't read anymore.But leaders building our AI future spend hours with humanity's oldest information technology.Coincidence? I don't think so.AI can write code and answer in seconds, but reading builds something irreplaceable: your brain 🧠Check out my new article: "Code, prompts, and... books? Why reading is an analog superpower in the age of AI"https://mattilehtinen.com/articles/code-prompts-and-books-why-reading-is-your-analog-superpower-in-the-age-of-ai/#SoftwareDevelopment #AI #Reading #Programming
  • 0 Votes
    3 Posts
    13 Views
    Summary of A Philosophy of Software Design by John Ousterhout Source: danlebrero.com These are notes by Daniel Lebrero Berna on John Ousterhout’s A Philosophy of Software Design. Some advice in the book goes against the current software dogma. The current dogma is the result of previous pains, but has now been taken to the extreme, causing new pains. What the author solves with “Comment-First Development,” others solve with Test-Driven Development. The excuses for not writing comments mirror those for not writing tests. Key Insights It’s easier to see design problems in someone else’s code than your own. Total complexity = Σ(complexity of part × time spent on that part). Goal of good design: make the system obvious. Complexity accumulates incrementally, making it hard to remove. Adopt a “zero tolerance” philosophy. Better modules: interface much simpler than implementation (Deep modules). Design modules around required knowledge, not task order. Adjacent layers with similar abstractions are a red flag. Prioritize simple interfaces over simple implementations. Each method should do one thing and do it completely. Long methods are fine if the signature is simple and the code easy to read. Difficulty naming a method may indicate unclear design. Comments should add precision or intuition. If you aren’t improving the design when changing code, you’re probably making it worse. Comments belong in the code, not commit logs. Poor designers spend most of their time chasing bugs in brittle code. Preface The most fundamental problem in computer science is problem decomposition. The book is an opinion piece. The goal: reduce complexity. 1. Introduction (It’s All About Complexity) Fight complexity by simplifying and encapsulating it in modules. Software design is never finished. Design flaws are easier to see in others’ code. 2. The Nature of Complexity Complexity = what makes code hard to understand or modify. Total complexity depends on time spent in each part. Complexity is more obvious to readers than writers. Symptoms: change amplification, cognitive load, unknown unknowns. Causes: dependencies, obscurity. Complexity accumulates incrementally; remove it aggressively. 3. Working Code Isn’t Enough Distinguish tactical (short-term) from strategic (long-term) programming. The “tactical tornado” writes lots of code fast but increases complexity. 4. Modules Should Be Deep A module = interface + implementation. Deep modules have simple interfaces, complex implementations. Interface = what clients must know (formal + informal). Avoid “classitis”: too many small classes increase system complexity. Interfaces should make the common case simple. 5. Information Hiding (and Leakage) Information hiding is key to deep modules. Avoid temporal decomposition (ordering-based design). Larger classes can improve information hiding. 6. General-Purpose Modules Are Deeper Make modules somewhat general-purpose. Implementation fits current needs; interface supports future reuse. Questions to balance generality: What is the simplest interface covering current needs? How many times will it be used? Is the API simple for current use? If not, it’s too general. 7. Different Layer, Different Abstraction Adjacent layers with similar abstractions are a red flag. Pass-through methods and variables add no value. Fix pass-throughs by grouping related data or using shared/context objects. 8. Pull Complexity Downwards Prefer simple interfaces over simple implementations. Push complexity into lower layers. Avoid configuration parameters; compute reasonable defaults automatically. 9. Better Together or Better Apart? Combine elements when they: Share information. Are used together. Overlap conceptually. Simplify interfaces or eliminate duplication. Developers often split methods too much. Methods can be long if they are cohesive and clear. Red flag: one component requires understanding another’s implementation. 10. Define Errors Out of Existence Exception handling increases complexity. Reduce exception points by: Designing APIs that eliminate exceptional cases. Handling exceptions at low levels. Aggregating exceptions into a common type. Crashing when appropriate. 11. Design It Twice Explore at least two radically different designs before choosing. 12. Why Write Comments? The Four Excuses Writing comments improves design and can be enjoyable. Excuses: “Good code is self-documenting.” False. “No time to write comments.” It’s an investment. “Comments get outdated.” Update them. “Comments are worthless.” Learn to write better ones. 13. Comments Should Describe Things That Aren’t Obvious Comments should add precision and intuition. Document both interface and implementation. 14. Choosing Names Names should be precise and consistent. If naming is hard, the design likely isn’t clean. 15. Write the Comment First Like TDD, comment-first helps design, pacing, and clarity. 16. Modifying Existing Code Always improve design when changing code. Comments belong in code, not commit logs. 17. Consistency Don’t “improve” existing conventions without strong reason. 19. Software Trends Agile and TDD often promote tactical programming. 20. Designing for Performance Simpler code tends to be faster. Design around the critical path. 21. Conclusion Poor designers spend their time debugging brittle systems.
  • 0 Votes
    2 Posts
    9 Views
    «Se vi capita di osservare qualcuno che "programma", potreste vederlo passare molto più tempo a fissare il vuoto che a digitare sulla tastiera. No, (probabilmente) non sta perdendo tempo. Lo sviluppo software è fondamentalmente una pratica di problem-solving e quindi, come quando si risolve un cruciverba complicato, la maggior parte del lavoro si svolge nella propria testa...»#coding #ai #programming https://chrisloy.dev/post/2025/09/28/the-ai-coding-trap
  • It's that time of year again!

    Uncategorized programming unix apue
    40
    0 Votes
    40 Posts
    28 Views
    Advanced Programming in the Unix EnvironmentTool Tip: ed(1) is the standard text editorAs part of our discussion of unix development tools, we take a short detour to provide a quick walkthrough of ed(1), the standard text editor. This is not done merely to up your geek creds, but understanding ed(1) will also helps us better understand other tools like vi(1), sed(1), and ultimately even things like diff(1) and patch(1) better.https://youtu.be/mRZsV7aMK0I#apue #unix #programming #ed