buzzybee

RemObjects is not unknown. You're just new.

FizzleFade is also found in Microprose games from the era (e.g. Railroad Tycoon, Civilization), sometimes in full-screen transitions and other times to fade in single sprites. But more relevantly to "id software history", you can find it in Origin's Space Rogue, which John Romero contributed to. A likely possibility is that he picked up the trick on this or a previous project while at Origin.

It's also possible to use a slower "arbitrary PRNG and bump" scheme that tests the VRAM for the desired values(e.g. if it were a sprite, by running the blit at that pixel address and testing) and walks forwards or backwards until an unset value is found. If the walk can be done fast enough, it'll execute at the same framerate as an LFSR cycle-length fade. It can be further supplemented with an estimation heuristic or a low-resolution map to generate unique patterns. It's just less speedy and mathematically interesting to do that.

It enables the coder to engage in some late binding without engaging in a lot of casts or more elaborate metaprogramming: the enum index used for assignment is itself an assignable value and therefore can be passed around and manipulated if the algorithm needs it. It's a very intentional tradeoff of structure and long-term clarity for a faster turnaround to make design changes.

I haven't even checked to see if the final program uses it. It's the kind of thing, though, that you might go in thinking, "maybe I will need that", and it doesn't add too much overhead to your prototype.

My strategy for personal coding recently has shifted towards a sincere exploitation of automatic programming(in a manner similar to model-driven development or language-oriented programming, or the research of VPRI). The overall feedback loop looks like this:

* Write an initial mockup that exercises APIs and data paths in an imperative, mostly-straightline coding style

* Write a source code generator that reproduces part of the mockup by starting with the original code as a string and gradually reworking it into a smaller specification.

* Now maintain and extend the code generator, and write new mockup elements to develop features.

The mockup doesn't have to be 100% correct or clean, nor does the code generator have to be 100% clean itself, nor does 100% of the code have to be automated(as long as clear separation between hand-written modules and automatic ones exists), but the mockup is necessary as a skeleton to guide the initial development, and similar, comprehensible output one layer down is a design goal. Language-level macro systems are not typically sufficient for this task since they tend to obscure their resulting output, and thus become harder to debug. Languages that can deal well with strings and sum types, on the other hand, are golden as generator sources since they'll add another layer of checks.

I'm still only using this for personal code, but it's gradually becoming more "real" in my head as I pursue it: the thing that stopped me before was developing the right feedback loop, and I'm convinced that the way to go is with a pretty lean base implementation(Go is an example of how much language power I'd want to be using in the target output) and an assumption that you're building a bespoke generator for the application, that won't be used anywhere else.

Source code generation gets a bad rap because the immediate payoffs are rare, and it's easy to take an undisciplined approach that just emits unreadable boilerplate without gaining anything, but the potential benefits are huge and make me not really care about design patterns or frameworks or traditional "paradigms" anymore. Those don't achieve anywhere near the same amount of empowerment.

I do microwave the sponge after use, for about 2 minutes so that it's bone dry. The reasoning is simple: most of the bacteria are going to hang out in the water. It's still going to be infected, but it doesn't have to be disinfected. It just has to remain close enough to the ambient load of the kitchen that it doesn't obviously inflame my hands when I pick it up. After all, my hands are germy too, most of the time. The soap, water, and pressure applied during cleaning are supposed to do most of the work.

The longest possible chess game:

https://www.chess.com/blog/kurtgodden/the-longest-possible-c...

Chess AIs, perhaps needless to say, are very good at computing at the depth necessary to win drawn-out endgames.

IME real users don't care about the app being aesthetically different, but they do care if the common idioms have changed(e.g. position of OK/Cancel). That shouldn't depend on your toolkit, though.

Some time ago someone recommended SpeedCrunch to me for calculator stuff and I use it all the time now. It's a little bit less intuitive since it takes a syntax instead of presenting buttons, but it does a ton more.

Worse-is-better: we already "solved" it with altcoins.

Regarding smart contracts and other inventions of cryptocurrency: I think, most of all, the crypto market is absolutely vicious, in a way that both capital markets and technology companies haven't seen(in the public eye) for many, many years. As of right now there's still some faith left that Ethereum is going to go places because firms keep trying to use the technology on the basis of hype. Unlike with most overhyped and half-baked tech, though, the failures do not get shoved in the back room for some hapless dev or ops team to deal with. This is like if Apple and Google had daily columns on the front page showing every bug or support issue that they experienced in the past 24 hours.

And that's been true right from the beginning with Bitcoin: scams, schemes, heists, data loss - the headlines scream blood all the time. We've never had that kind of "mean time to disaster" in technology before. The status quo was that something would fail, but the failure would never quite get back to the individual or company that produced it. They would spin it away, and no careers would be harmed. But the likes of Solidity produces a meat-grinder, a blind destroyer of any who dare enter calling themselves rockstar.

I think it's kind of awesome and beautiful, in that sense. It will induce a maturation throughout the economy to adapt to this new pressure. But like adolescence, it can be an ugly work in progress, and I don't expect Ethereum itself to be a survivor at this rate.

This is not a valid argument when the line in question is dealing entirely with abstract constructs(which it is) and all of the variables are function-local, declared on the very same screen, and several of them exist as aliases for more complex constructs. If you haven't encountered a need for this approach, you just haven't had to write really mathy code before. Mathy code derives little value from longer names, but it does benefit from density.

If you really think something is wrong with it, post ideas for longer names that will clarify and not substantially impact density. I would probably conventionally use "n0" and "n1" instead of "m" and "n" to represent "n-1", "n" - but the usage he has is consistent throughout the file, which is more than I can say of my stuff sometimes.

I've been on the "sleep on exercise mat with some blankets" train for years, but a few months back, stepped it up by eliminating pillows. I still gravitate towards getting something under my head, but it turns out that I only need another small blanket or cloth. I wake at more consistent hours and no longer experience numbness in my arms when waking. I believe there are many more "details" I can improve too. I got into training fast and slow breathing patterns for different activities, which seems to help both the training and the recovery. A plainer diet seems to help a lot of things, although it's hard to reconcile this against the constant imposition of the world to eat pizza and drink beer.

The core is so important. Core + breathing exercises will improve any other activity.

Contrast with FPC's compiler mode pragmas for different dialects. [0] FPC shows the effects of this story in the long term: there are several major divergences in behavior supported by the modes, and some individual features can be toggled per-unit or sometimes with a finer grain. [1] Since you're allowed to mix and match different units, the fragmentation poses little threat to any individual programmer, and it's possible to dial in assertions, optimizations, and calling conventions in a targeted fashion.

[0] https://www.freepascal.org/docs-html/user/userse33.html

[1] https://www.freepascal.org/docs-html/prog/progch1.html#progs...

Here's an easy challenge: Ask the overengineer to solve problems without introducing any new classes or functions. This starves the overengineer of oxygen, reducing their abstraction options to "loop", "branch", and "add variable". The resulting giant switch statement in a loop is likely to be a relatively clean architecture.

I've been musing about these sorts of issues of "what is really complex" lately, too. I started evaluating new languages for low-level application code again after spending a lot of time overly close to web browsers, and then ended up deciding that Free Pascal beat them on the stuff I cared about, relative to C compilers as a baseline:

* Best-in-class compile times

* Modules; preprocessor is relevant, but not dominant

* Generics, variant records, function and operator overloads, exceptions, safe string and dynamic array types

* Libraries for common things, with a reasonably conventional style: APIs, containers, bindings, etc.

* No GC; pointers are available, but language features discourage casual usage. RAII pattern is achievable.

* Strong + static types, nominal types and type aliasing.

* Good IDE support, mature tooling, compiler has very broad platform support.

The new languages do win on a lot of the language-feature aspects(particularly memory safety when performing deep optimizations), but they don't have as good a story on the tooling. The compile speed is a major feature and is only likely to remain advantageous over time - and the features already in place are quite effective at limiting source code size, boilerplate, and dangerous constructs. This despite "Pascal is verbose" being memetic.

And if I want more high-level power, I've found that writing a FSM is the most probable path to achieving it. A FSM that embraces the problem domain is a tiny compiler: input source constructs, FSM checks them, applies appropriate algorithms, then emits a list of actions. More power? Add a second FSM to make it a two-pass compiler. Add a stack, or attach it to a database. If it has to be fast, it can generate code in the last step, too. Those things add tons of power to model the problem and aren't heavily dependent on language-side support.

When the paper was written, the jury was still definitely out on good concurrency practices for applications: the computing world(apart from mainframes, which of course had learned every lesson 30 years earlier, but nobody paid much attention to) had only relatively recently exited the era where one might ordinarily synchronize your co-processing units at the instruction level, with hand-tuned assembly, just like any other piece of external hardware. Cooperative, event-based programming is familiar to this style. Asynchronous primitives backed by hardware scheduling were the "new kid" for a lot of programmers.

So, like with every technology, there was some exuberance and overuse of a novel formalism which shows up in this paper: "scales to 100,000 threads", it proclaims. Not much later, interest in "green threading" and "lightweight concurrency" grew as a way to get some of the architectural benefits of being asynchronous while mitigating waste from large numbers of threads, and consensus shifted towards mixing the approaches, which seems to have converged on the few-threads, message-queue-per-thread approach.

I'm seeing it as a feedback loop problem, again. Managers and stakeholders have an easy time remarking on surfaced progress. The developer has to think and communicate everything else. Going purely hands-off doesn't work, because then the developer will tend to wander towards working on the wrong problems and get mired in them. Neither does chaining them down to a deadline, since that creates rushed, ill-considered work.

So the people who are perceptually 10x tend to have hit on a strategy that keeps them in the feedback zone without being overly concerned about surfacing everything right this second, and have management that cooperate with their strategy.

You wouldn't be alone as a philosopher-developer, there are a decent number of us out there.

However - shipping code is often very organic, cultivated stuff which foils attempts to establish a coherent philosophy, a through-line of "how it works" - it works because it worked the day before, all that changed was that a little bit more was added. Repeat till broken, then refactor back to sanity(else abandon ship). It's Sisyphean hill-climbing.

This in turn plays into the falsity of "engineering" as a way to describe what's going on with a lot of code. You can do it in the small, but at any scale the codebase habitually becomes a living organism. And that tends to get puzzle-solver types excited, because if it's alive and keeps changing, then they will have endless problems to solve forever!

So I believe the philosophers of the crowd ultimately tend to move away from the applications coalface and look for something relatively smaller that does allow some time for reflection and distillation of the problem.

I followed Carmack's suggestion and never looked back. I write simpler code on average now, and I spend less time having to re-read it too because I'm changing the same lines less often. What I lose in terseness in the short-term, I regain in being able to spot key abstractions that are more crucial to long-term program health. It plays well with debugging since there are fewer places where state can act at a distance.

It's very unfashionable advice in some circles, though. It sounds just enough like "go back to writing unstructured copy-paste spaghetti" to trigger some people's kneejerk. But the ground rules of "don't take subroutines, don't jump backwards" actually keep it from getting too far out of control, because they align you towards code that only uses enough flexibility for the task at hand, hence there's a lower likelihood of missing something. Very good practice for greenfield code where you might reflexively add a generalization that you don't use. I can still get better at it.

Edit: And one of the most important things it taught me, is that I can use scope blocks and a comment instead of a function, and it'll be sufficient.

What tends to happen as you refactor bad code is that you gain some intuition about the way the code needs to flow. The longer you spend grinding away at the existing code, the more likely it is that rewriting it will work, because you'll have pent-up "architectural energy" waiting to be used, and good, already-debugged code from the previous version that can be copied in.

The most likely causation for crossing a threshold from refactor to rewrite, while steering clear of the "big bang rewrite", is that you have to ship a feature that triggers an end-run around some of the existing architecture. So you ship both new architecture and the new feature, and then it works so well that you can deprecate the old one almost immediately, eliminating entire modules that proved redundant.

Edit: And if you don't really know where to start when refactoring, start by inlining more of the code so that it runs straightline and has copy-pasted elements(you can use a comment to note this: "inlined from foo()"). This will surface the biggest redundancies at a minimum of effort.

I went through something like this.

What your emotions are getting conflicted on is the idea of learning your real limitations. Because, despite appearances of competence and opportunity, you've surely got flaws that would prevent you from doing something someone else would find easy. One of them is manifest right now, in that you're bailing before the commitments get too intense. This happens within youth fairly often, even when no graceful exit is possible and it's the rationally correct decision to stick with a commitment. Other people, already people younger than you, even, have gone and made hugely consequential decisions without thinking twice. Some of them are dead, so maybe you're doing all right.

What an older person tends to figure out is that they are only getting more limited and closer to an end as time goes on, which makes them more motivated to focus on relative strengths and weaknesses. They will exit the situation when it plays to their weaknesses and saps their energy, and stay in and struggle when it fits their strengths and motivations.

It's hard to see, though, what you are doing when you're living it every day. Somehow you ended up on HN. But why HN, and not anywhere else? Do you know how you got here, or why you stay here?

These are things you can pick apart by journaling, collecting data, and trying to challenge your internal narratives. The "why" of what you do never really gets answered(because it's philosophical, hence it never reaches an end), but if you're occupying your time with struggles that you feel are worthwhile to you personally, and not just escaping forever, that's probably a good life.

Nope. Replaced by WASM within 5.

Real-time video composites were achieved on analog hardware such as Scanimate [0] starting around the 1970's; traditional film matte techniques [1] had also been used for well over a generation by that point and a travelling matte would suffice for compositing that image.

[0] https://www.youtube.com/watch?v=UHjkMThH0aE [1] https://en.wikipedia.org/wiki/Matte_(filmmaking)

Check the bitcointalk forums. There are lots of altcoin announcement threads. Most are absolute drek and not worth your time, and most of the comments are people deceiving others or themselves by engaging in pumping/bashing. I scanned those a little more when I started, but they're awfully crowded now.

It's not purely the sampling that's doing it to Hollywood: In some fashion, it's the heavily-derisked blockbuster formula to blame, and technology comes along for the ride.

Tony Zhou's Every Frame A Painting [0] offered a take on how the tendency is to work very closely to a temp track and then ask for something identical, which of course can only get you increasingly similar sounds. Dan Golding responded to this by adding some nuance, noting that temp tracks have always been in use, so the answer has to be a little more complicated, and he points back to the technology. [1] I would say that the technology is just a piece of the puzzle; you can order in a different type of sound and get it, whether or not you're using a computer-heavy approach. That's aptly demonstrated by the variety seen in indie games, for example. This is a problem that movies have made for themselves by being focused on fitting everything to a formula. The occasional film does slip through that has a great score that draws on something bigger than other films(for one example: Scott Pilgrim vs the World).

[0] https://www.youtube.com/watch?v=7vfqkvwW2fs [1] https://www.youtube.com/watch?v=UcXsH88XlKM

I gave up on Amazon the other day. What did it? The "accidental" signup for Prime. They have a multi-year track record of doing this to people, some of whom can't afford it. I rarely need to get anything from them. So I cancelled both Prime and my account. They are clearly uninterested in keeping up service quality these days.

You may want to try out RapidComposer, Sundog Song Studio, or Odesi to get a sense of what that workflow entails right now. I bought each of those (two of them on sales), hoping I would come to terms with them, but they just don't work for me. It's mix of "the UX could be better", in some cases, but also some underlying consequences for complexity that show up when you're given a blank piano roll and every possible axis of music theory exposed as an affordance in the UI.

What's working for me right now? ChordPulse [0] which contains arranger keyboard style presets, plus a few options for sequencing and detailing the arrangement. Export to MIDI, add melodies and tweaks on top, and the song is ready. There are much more complicated versions of this formula around like Band in a Box, but they both have things I don't need, and aren't quite as good at this basic workflow.

[0] http://chordpulse.com

It's only helpful if it adds something to the feedback loop. That's what an organization and its projects need at every stage: healthy feedback. If it's too far into fantasy, it gets forgotten and replaced with something more expedient; if it goes completely unaddressed, the absence manifests as some other failure.

So, early org chart is only useful if it doesn't jump too far ahead of what the business is: If you discover you need a different organization to execute on the plan, there's no point in planning for scaling the existing one out. But if what's being followed is a "hire a great team and great things will happen" kind of plan, then there's no conflict since it just means you've considered both near and long-term aspects of building a great team.

AutoHotKey?

In some respects I think the apparent lack of automation in GUI comes down to the methods by which it's accomplished feeling too crude to take seriously. Even ordinary "power user" apps like Excel are so in-depth already and support so many workflows that it's hard to figure out the efficient path for what you want to do.