subwayclub

It's complicated. If you despecialize at the "star musician and corporate schmoozer" skills and become more of an independent brand manager/marketer where the music is just one element of the business plan, you have many opportunities to practice your craft online. But as we all know, it's way more plausible that you and I and the aspiring kid down the street can't pull off the kind of hustle and vision necessary to make it work.

That only makes the dynamic even more exaggerated when you travel from a reasonably clean, streetcar-suburb neighborhood like West Portal or the Outer Richmond to the city core and are abruptly surrounded by a mass of bodies failed by society.

Code generation is, in essence, the ultimate static construct since it allows you to compile any feature you would achieve through late binding and reflection, but with a static code path. Which in turn lets you leverage the compiler toolchain more and bring more errors towards compile time(where they're cheap to resolve).

Dynamic languages can always lean on runtime features, but that's also their peril. Late binding deprives you of leveraging the tools in favor of "trust me".

In both cases you can get a maintenance nightmare, of course. The point as I see it is to move things toward the runtime when the error case is not troublesome, and towards the compiler when automating in more safeguards would help.

If you look around, you can find AM4 platform in prebuilts from some of the biggest PC OEMs. Intel is still the majority of the lineup, of course, but APU systems have given AMD leverage here that they didn't have the last time they had competitive performance. It makes the OEMs offer the platform for an energy efficient/SFF build option, while also giving leeway to do an upgrade down the road.

I invested in a Rumpl blanket and eventually took to putting that on the carpet, a smaller blanket to support the head, and one top cover. The Rumpl is designed to be of a similar quality to a sleeping bag but easier to spread and wash. It's an "as if perpetually travelling" mindset.

Digital tends to have more latency by its nature. Parameter changes often produce zipper artifacts, stepping, etc. It's all solvable, but not uniformly solved.

Godot 3 actually has some built in DSP effects and send buses: https://godotengine.org/article/godot-30-new-internals-progr...

Regarding visual editing, those tools are of direct interest to any signal processing work(which for games means audio, visual effects, and in some cases asset dependency resolution). They don't work well once your task is too fine-grained. Graphs of finite state are also extremely useful for game AI and concurrently scripted logic, so tools that formalize those concepts and give them visual UI are also commonplace.

In audio work, a FSM is a good starting place to conceptualize processes like key state tracking and envelope triggers. Games have more shifting requirements so the design process of the FSM is given much more emphasis.

Intel has a lot of threats lately. Things seem to be moving towards a small die and MCM strategy to get better yields and move investment towards the package and FSB. AMD made a huge investment in that direction with Zen arch and Infinity Fabric - Threadripper's big package and high core count has opened a new tier of enthusiast desktops - and they may have plans for furthering that on the GPU side of things(Vega is positioned for efficiency at lower wattage, which is poorly reflected in the "hot-and-loud" flagship releases. It's expected to pair well with Zen in the forthcoming Raven Ridge APUs though.)

Intel shares with Nvidia(also currently using large dies) a limited form of performance leadership at the high end that may be eroded in the face of these shifts. Most of the market is going to see more benefit from more cores instead of faster cores with the current conditions. That might be less true once we're talking about a baseline of 16 or 32 cores, but 2 is proving to be too few for current workloads.

And that's just their nearest competitor. ARM SOCs have consumed the mobile market and are creeping upwards. My ARM Chromebook makes a pretty good Linux desktop too, and you can practically trip over RaspPi devices.

Integrated language+database solutions are a recurring motivator for new one-off languages: Pick System and FoxPro are classic examples of writing around a custom language vs "scripting" inside SQL. Applications with custom database-like systems such as game engines also frequently lean in this direction(UnrealScript, GDScript). The main difficulty is in the practicals of getting all of the desired functionality into a useful package - not the theoretical aspects.

As of right now (for game projects) my strategy is to use source code generation to make the working language behave in a database-like fashion and emit a static result, rather than to engineer a complete dynamic schema with a scripting runtime and all the bells and whistles of a standalone database. The latter is both harder to build and lets me leverage fewer of the tools of the host environment.

The article deals with a lot of stuff apart from the clinical aspects of diagnosis and treatment. For example, it outlines someone who lost social connections as he grew older, a major causal factor in depression.

Basically, C's semantics assume too little - everything is a primitive type or a pointer dressed up to look like something else. Pascal has a stronger notion of types and this allows for additional automatic optimization where they're relevant - memory layout just happens to be one such area.

IIRC games made pretty good use of MPU-401 intelligent mode to drive the MT-32 module. The first really elaborate game scoring work on the IBM platform came through the MT-32(Sierra picked it up and everyone else followed - it was a good target for composers but in practice most people heard the music on Adlib/SB), so I would consider it successful in that niche.

And on that note, what I think Web Audio tried to be was a drop-in kit for game engines. Getting the full functionality of Unreal into the browser motivated the requirement for audio processing. But the actual implementation was muddled from the start: basic audio playback remains challenging(try to stream a BGM loop instead of load+uncompress and discover to your woe that it's not going to loop gaplessly, even when the codec is designed to allow that.) and my hobby stab at an independent implementation ran out of gas when I tried to get their envelope model working. The spec has a lot of features but not enough detail, and my morale sank further when I looked at how Chrome did it(stateful pasta code). I got something half-working, put it aside and never came back.

OTOH I had also tried Mozilla's system. That was very simple, and I got a synth working in no time at all with decent performance and latency. Optimizing from that point would have been the way to do it, but something in browser vendor politics at that time led to it being dropped.

They could automate the implementation of the protocol from the spec, as has been done to TCP/IP on at least one occasion(VPRI STEPS).

The US is usually broadly categorized as "strong mayor" (very consolidated power) and "weak mayor" (board of supervisors form a coalition) depending on the municipality.

Where this distinction gets muddled is when a metro area is sprawling enough to have many governments. For example, City of Los Angeles has a mayor, but it only represents some of the major neighborhoods of the metro area, while Los Angeles County, which spans multiple cities, has a board of supervisors providing oversight on a more regional scale.

In contrast, San Francisco is a combined city and county with both mayor and board of supervisors: but the Bay Area has 9 counties(more if you count certain outlying cities) with a multitude of city governments, and there is no equivalent to the LA county board unifying representation at the "millions to one" scale - those issues are duked out between different county agencies or pushed up to the state level. Accordingly, Bay Area cities have some more individual freedoms but are much less inclined to cooperate on regional issues and will frequently export problems onto each other.

The saying goes, "history never repeats itself but it often rhymes".

If there's a threat on the horizon, it's probably the one we discuss the least right now.

The right way is, to speak in philosophical terms, totally a pragmatic choice. If nothing in C++ is working for you, don't use it. If a really obscure technology is making you go really fast, use it.

The one and only thing that muddies this picture is other people. Once you are collaborating on a program(whether on the same team, through end-user code, or through a library or API call) all your tricks, preferences and conventions are subject to other people's inept groping and misunderstanding. And that is where you get into standardized best practices. They are basically guaranteed to not actually be the best practice, but they're the one you can compromise on.

I recognize a lot of myself from a few years ago in that (and I'm 32) and the main things that changed me in no particular order were:

* Adopting a more deliberately Stoicism-inspired philosophy - whether or not I'm succeeding at my goal there will be another struggle waiting after that, so there isn't really an endpoint here other than my death or permanent incapacity. * Buying into feedback loops over goal-and-achievement systems. Feedback is more important to doing good work than any other thing - if you don't have it then you don't know if it's any good. But also, it's easy to miss what forms of feedback are available and sometimes it's as simple as critically thinking about whether or not an expected result happened(e.g. write software, add a feature: did it actually do what you expected?) * Got a lot of money. I did this through crypto. I had no expectations about it, it was just a way of putting another iron in the fire. The amount of physical effort put in was, of course, clicking a few buttons, typing a few passwords. But the mental/emotional effort of "why bother" and "why study this" - that is why you aren't seeing everyone on the street talk about it(yet). I had to make a firm decision to get in for anything to happen. And there's a lot of random chance to that, just as with my game projects, which have hardly gone anywhere in years of trying. And now that I have the money my mind is rearranging things so that I will further devalue my work on games in a monetary sense.

A lot of "striver porn" - worrying about productivity and getting ahead and making Right Decisions - stops making sense post-success. If you end up with the success, great, but I wouldn't try to impose a narrative arc on it. The actual factors involved are just mindboggling. The feedback loops, on the other hand, those are something you can improve from nearly any life status. And they tend to vastly differ from productivity tropes because they're about optimizing a whole cross-section of life, not just quantifiable output. E.g. if you do less but your stress level is lower, do you end up ahead on health later?

I have the corresponding regret of wishing I got in six years ago instead of four years ago. Not that I'm doing bad now, by any means. It's just a relative success kind of thing.

A certain irony about knowing all the tricks and using Python is that you invariably encounter people online who say "well Python was too slow so I dropped it" when the problem they encountered is covered either by one of Python's prolific extensions or by a slight reformulation of the problem.

And, having said that, I also didn't know that some optimizations were possible until later in my programming career. There's just a point where it escapes one's current level of skill.

Programming more skillfully is primarily about making decisions on which feedback loops you pay attention to, and not getting stuck on ideas about feedback that seem momentarily fashionable or convenient, but lead to bad outcomes later.

Write prototyping code that solves an existing problem as nearly as you can manage, and then figure out how to improve it on one or more metrics:

* smaller SLOC (automatic programming, data abstractions, etc)

* better portability, fewer dependencies, simpler build processes

* better throughput, latency, or resource usage(memory, storage, bandwidth, energy)

* eliminate one or more classes of errors(e.g. off by ones, null dereferences)

* better user interfaces, better documentation and accessibility

* more efficient development of the prototype

* better working environment (workflow, tools and knowledge of the tools, automations for convenience)

Oftentimes, you can make one change and improve several metrics. Other times you sacrifice one to get others. There are bad tradeoffs like code golfing or premature optimization. Having the prototype already in hand is crucial in all cases since it gives you a spec to bump up against when you're at risk of falling off track. If you're more daring this can take the form of an existing shipping codebase.

I try to not stay in flow state. It means that the problem I'm working on is too familiar and I should automate the programming of it so that I'm grinding on something hard again.

Edit: but it's okay if it's a prototype

My first thought was: Dippin' Dots, the ice cream of the future.

Have you considered writing an automatic file syntax check/rename? Reading the thread made the idea pop into my head that it could be a useful tool, especially in fast moving or group environments.

I prefer organizing by year and by category(business, code, etc) instead of by client but overall I'm mostly happy to have any organization of my files at all.

The community college course I took past spring used Thomas Nagel (What Does It All Mean?) supplemented with some handouts. I would recommend a class because part of the doing of philosophy is the discussion. Plus the classroom is one of the few places where you can delve into the nuances of an issue without being considered pedantic or boorish.

I think there are some parallels between the cryptocurrency shift and US internal frictions today. The government now is like a machine running without a master, and that's hurting its ability to respond to this development in more than a basic bureaucratic sense of getting tax money and arresting criminals. Stronger control would take a coordinated effort across several arms(propaganda, legislation, backdooring and attacks on the network, seizures). The capability is there in theory, but it's going to other perceived threats with more short-term political value.

On the other hand, if the tech hockey sticks in adoption, that's basically the end of the world order as we know it and the start of one where economic value skips around between different cryptocurrencies, never really staying in anyone's control. In effect a "marketplace for power consolidation".

It's not quite like the gold standard, because liquidity between cryptocurrencies is a software feature, not a physical constraint, and a perpetual stream of speculative ICOs discourages capital pooling. If you're poor in the dominant currency, you simply adopt the underdog to even the odds. Everyone will be writing themselves blank checks through chain forks, in effect encouraging a demurrage economy.

I got used to the idea of staying away from the cutting edge in the early 2000's. The original Athlon and Thunderbird processors were groundbreaking in performance, but consumer cooling and PSU design had not caught up with their power and heat output demands - the result was uncomfortably noisy and hot at best. The high end parts really are like Ferraris in that they do take more of your time and care to deal with issues like that.

Now when I look at new machines and components I look for something slightly middle-of-the-road, mainstream-leaning, with low power output but quality components, and later revisions of an architecture, since system performance is a more-than-the-sum-of-its-parts game. I actually priced out a Ryzen 3 build today, but I might be better served with the last gen APUs.