This was a super-interesting read, but I'm disappointed there isn't a description of what, exactly, was wrong about what he did, and what one should do instead. The only thing that comes to mind is the obvious one: you don't want more than the FDIC limit in a single bank account.
Readit Newslackbeard commented on My startup banking story (2023) mitchellh.com/writing/my-... · Posted by u/dvrp
lackbeard commented on Why Triplebyte Failed otherbranch.com/blog/why-... · Posted by u/rachofsunshine
This is a very interesting, very well written post. The part that stands out the most is:
> if you needed venture capital to produce a viable small-scale business, you didn't really have a viable small-scale business to begin with. Triplebyte's break-even status was an illusion, predicated on funding that would probably never have existed if that scale were the founders' only ambition.
I wonder if there's a way to build a viable business out of a product like FastTrack that does not depend on venture capital to get going?
lackbeard commented on EU strikes deal to regulate ChatGPT, AI tech bloomberg.com/news/articl... · Posted by u/helsinkiandrew
why every single European citizen is dependent on US hardware, US software and US services
Mostly because US companies keep buying their EU competitors. Nokia, Skype, Spotify, ARM, ASML and countless others all originated in Europe. The ones that remain European are the ones that cannot be bought so easily, like Matrix (UK) or Mastodon (DE).
Isn't ASML a Dutch company? I can't seem to find any evidence they've ever been sold.
lackbeard commented on How do I become a graphics programmer? gpuopen.com/learn/how_do_... · Posted by u/pjmlp
I feel like this comment perfectly captures the difference between programming and coding.
Programming comes from a place of first principles, the goal being to understand what is needed completely so that a solution that meets many parallel constraints can be constructed.
Coding comes from a place of completing a task, the goal being to get from the requirement to the operating task in as short a time as possible so that one might move on to the next task.
Both disciplines have value. The original question was unclear about where the author hoped to end up.
To put this in a slightly different perspective, a graphics programmer can write a program to show a shaded object on any platform with a CPU and a way to display graphics. A graphics coder can write a program to show a shaded object only on those platforms where they have previously mastered the APIs for generating display graphics.
Good comment, and, basically, I fully agree, except, I really dislike your attempt to appropriate the words "programming" and "coding" here. Like, can you just explain what you mean without trying to redefine terms that have broadly accepted definitions distinct from how you're trying to use them here?
(Sorry, this probably sounds more critical than I'm intending...)
> As a Clojure programmer, this is not what I have in mind when I think of data-oriented-programming, but this:
Yeah, that's more or less how I would have defined DOP, too.
Could it be that there is a slight difference in meaning when people refer to "data-oriented design" (OP) vs. "data-oriented programming"? At least that's been my (anecdotal) impression so far.
I'm not sure what is meant by "data-oriented programming" (I know what "data-driven" means...) but, yes, "Data-Oriented Design" has a distinct (if somewhat nebulous) meaning which comes from game programmer culture. (And my guess is the difference between it and data-oriented programming is not slight.) Data-Oriented Design is, basically, the name given to the bag of techniques listed on the submitted webpage. I don't know if the term was coined by Mike Acton, but it was popularized by the talk he gave that is linked to on the submitted webpage. (It's an inspiring talk! You should watch it, if you have not, yet.)
As far as I can tell, Data-Oriented Design is a reaction to trauma experienced by game programmers trying to undo damage inflicted by the... inapt... application of OO techniques in game codebases by their (probably well-meaning, but ignorant) peers. (Hence the contrast in the names: OBJECT-Oriented Design -> DATA-Oriented Design.)
The keystone idea seems to be, instead of organizing your program's data as objects in an inheritance hierarchy, figure out which data will be accessed together in tight loops, and pack that data together in arrays. (I.e., prefer structs of arrays to arrays of objects.)
P.S., There's an interaction during the Q&A section of that presentation by Mike Acton which I love: one questioner asks, somewhat incredulously, (and I'm paraphrasing here) "If I were to follow the principles you have laid out in this talk, then, if I ever needed to alter the layout of my data--after having invested (perhaps significant) time already writing my program--I would subsequently be required to rewrite all the code which accesses that data." and Mike Action answers, basically, with a stone-cold "Yes."
That is exactly what "pay to win" means in the parlance of our times: the more you pay, the better chance you have to win. Tiers vs continuum doesn't matter here. The important part is that players with the same skill must decide how much money to pay the manufacturer to gain advantages over other players. If everyone had to buy the full set every quarter, then it would not be pay to win, it would just be a very expensive subscription game. There are things like sealed deck drafts where everyone agrees to buy in at the same price so that everyone can compete on skill. But there is a reason WotC doesn't allow proxy cards (just printing an unofficial copy of a card or a piece of paper with the name of the card), because they make a ton of money from the pay to win dynamic.
I agree that "tiers vs. continuum" has no bearing on the question of whether or not Magic: The Gathering is pay-to-win. I was merely pointing out that what tedunangst was describing was a continuum, not tiers.
Obviously, I'm not articulating my perspective very persuasively. Here's some additional flavor that might help (probably won't:)
1. In Magic: The Gathering, the most expensive deck is not always (or even ever, really) the best.
2. Is Golf pay-to-win? I can spend more on a set of clubs that have bigger sweet spots & will give me more distance with the same swing than my opponent's set.
3. The term "pay-to-win" comes from free-to-play MMOs.
I think most people that claim MTG is pay-to-win are just frustrated by how expensive it is. I agree. Don't play it!
I think it's pay to win in the sense that there are multiple subscription tiers, and if you only pay for basic, you're not winning against the players paying for gold++.
I would say, in that sense, there aren't really tiers; it's a continuum, and you can attempt to compete at whatever price point you're willing.
Ah MTG, the original pay to win game.
No, it's just a really expensive game with a subscription model. What's the price to pay to get four copies of each card in every standard set? That's your quarterly subscription fee.
It would be pay-to-win if you could do stuff like, pay a fee to take a second card at once during a draft, or tutor a card from your collection during a game, etc...
The time-honored (or "lindy") solutions here are joining a gym and going to church.
lackbeard commented on Legend of Zelda game sells 10M copies in three days finance.yahoo.com/news/le... · Posted by u/he0001