Live data from Hacker News

Viewing profile — oddity

oddity

HN member
Joined
Mon, Feb 27, 2017, 9:43 PM UTC
HN karma
569
Public activity
173 items

About oddity

No profile information was provided.

Recent public activity

  1. comment
    Comment #42680460

    It's a fun observation, but the causality in this feels off. There are tons of esoteric programming languages that are difficult to write in and no one talks about because they hav…

  2. comment
    Comment #38862763

    I think, maybe, the stronger argument is that the area of Generative Programming (which covers just about anything that generates another program) itself is too broad to properly a…

  3. comment
    Comment #34464167

    There are different forms of argumentation and they have a different tone that maybe doesn't come through so well on the internet without context. I dislike the debate club mentali…

  4. comment
    Comment #34464038

    You're not wrong. You can think of internet arguments as a method of developing a thought and collecting counterarguments in a real environment to refine it. The choice of forum af…

  5. comment
    Comment #34463200

    I was fortunate to learn this from pointless internet flamewars early in my life. Understand why you're in an argument and what you hope to accomplish by being in an argument. On t…

  6. comment
    Comment #34462908

    Parallelization and GPUs were the hot story 10-5 years ago, and require(d) a pretty substantial shift in the software stack for less-general gains. You're still hoping the cost-per…

  7. comment
    Comment #34462778

    I want to believe that there's some world where developers start putting actual craftsmanship into their software (again?), but I think this will only be true for SaaS or related e…

  8. comment
    Comment #32314667

    I don't usually respond to old comments, so I don't know if you'll read this, but I hope I can encourage you to think more broadly about what "differentiable programming" means. Di…

  9. comment
    Comment #32302587

    There's no contradiction: autodiff is a method of implementing differentiable programming. In this example, it is implemented as a type that handles a trace of a program, but every…

  10. comment
    Comment #32302420

    This "discretizes then differentiates" to borrow terminology from [1] which is one of the more accessible presentations and papers. The program might evaluate correctly, but equati…

  11. comment
    Comment #32302329

    The existence of a different kind of CPU isn't a meaningful distinction at the level of discussing paradigms. The semantics are different, so the abstract machine is different. The…

  12. comment
    Comment #32302133

    I don't need OOP to do a hash table lookup and then an indirect function call with the receiver as the first argument either but that ignores that there's more to a paradigm than t…

  13. comment
    Comment #32301984

    Autodiff does not work with for loops or if statements. The current solutions effectively pick a few promising traces through the program and then assume that nothing else exists. …

  14. comment
    Comment #32301898

    Object oriented programming, for example, doesn't let me have a variable hold half of one object and half of another or let the language derive the code that gave me that object at…

  15. comment
    Comment #32297716

    At the time the comment was made the link was https://harvard-iacs.github.io/2019-CS109A/pages/materials.h... where neural networks were mentioned. See https://news.ycombinator.com…

  16. comment
    Comment #32147672

    The average consumer is more willing to pay for hardware than software, even if all the value is created by the software. It's the reason why Apple no longer charges for OS updates…

  17. comment
    Comment #32111570

    Apple's ethos of giving more to creators was because they were focused on the niche markets that would spend good money for good products. By the late 90s, creators were their prim…

  18. comment
    Comment #32075338

    The difference is much more nuanced than this. A modern GPU can (and probably does) do most of what you've listed for a CPU. Speculative execution and branch prediction are a bit l…

  19. comment
  20. comment
    Comment #32074589

    Most people just want an allocator that works reasonably well, and maintaining that expectation means not exposing too many details that you might be held accountable to. If you ca…

  21. comment
    Comment #32074402

    Depends on how you define innovation. The hard truth is that there is no free lunch. We like to pretend we're using a Turing machine, but the moment you start caring about performa…

  22. comment
    Comment #31963766

    C and C++ are some of the few languages where the spec goes out of its way to not depend on an allocator, for good reason, and this is well after you've accounted for the majority …

  23. comment
    Comment #31963466

    It's unreasonable to assume that an stdlib must be designed around performance to any capacity. For most software, the priorities for the stdlib are 1) existing, 2) being bug/vulne…

  24. comment
    Comment #31962474

    This misses the point of my comment. When you put faith in malloc, you're putting hope in a lot of heuristics that may or may not degenerate for your particular workload. Windows i…

  25. comment
    Comment #31962356

    If you're depending on the performance of malloc, you're either using the language incorrectly or using the wrong language. There is no such thing as a general purpose anything whe…