chipsy

I agree with the sentiment. I don't think there's a solution in focusing your rumination inwards - in my case it's a good way to feel more anxious.

But I do have a bit of learned rationality in me, in the form of "I know I will commit error x in the future, therefore..." So rather than try to become a master of self-control, I make moves to arrange the world around me so that there are safeguards, the error is insubstantial, and I end up on the happy path automatically 90% of the time.

Similarly, I focus personal development on going "from strength to strength" rather than on shoring up weak areas. If I start from the models I know and keep extending them out more and more, I will get to the things I was overlooking, eventually. One thing I am doing now is using Streak Club [0] to develop a single habit over a long period of time, that I would ordinarily excuse myself from.

[0] https://streak.club/

Even in 1985, the applications were only sort of there. You had word processing and spreadsheets and a few other office apps. After that, the only things left for consumers were programming, education and games. And in 1985, games were "over" because early hype had died down and the console market crashed. Media apps weren't there yet: the first Mac was a year old, and the Amiga appeared mid-way through the year.

A lot of what made computers part of people's lifestyle was networking, and that only hit mass adoption in the 90's.

You could always go the route of many 80's and 90's RPG's and mash up some fantasy and science fiction themes - time travel, alien worlds, other dimensions, etc. Nearly every popular franchise of that era pulled in those tropes and they give you tons of breathing room to pull in whatever elements you want.

As someone who has commented on your engine threads in the past(and pointed out this challenge) it's good to see that you're getting towards the content stage of dev.

Here is my tip this time: try to find a lot of anchors outside of the game engine. You can do design incrementally by defining what the "rules", "logic", and "lore" of the world are, in order to clarify it. For example, use a mind map tool like a writer to plan scenario ideas. Pick a genre of music and a visual design language and incorporate them into the game's identity. Consider the limitations of the camera and control scheme and allow those elements to shape the scenarios. Borrow plots and characters from stories you like. Compose an essay response to something you want to critique, and then figure out ways to turn that essay into game form. If you don't have ideas for game mechanics, you can develop the story more instead and you'll eventually find some story elements that convert into mechanics.

The more of these things you can piece together in a coherent way, the more it will start to look like a complete design where "the work is cut out for you", instead of being a mass of bad content to crank out. There are a lot of ways to go about defining the design, but you will have to find some anchors if you want good content without a lot of meandering and second-guessing. The meandering should happen in notes and sketches, well before you try to write final code or assets.

Oh, and all of this can be done with an eye towards marketing. You can opt to choose and highlight elements specifically to capture an audience. The hard part tends to be finding concepts that you're happy enough with to want to think about for months on end.

This article provoked me to think about devices I had purchased in the last 5-6 years and left to rot. I charged up an Android tablet I got in late 2012. Then I brought out the Asus EEEPC 900 I got, two years earlier.

The tablet has always had issues holding a charge even when turned off, and it's a bit bulky, so I might put it back into service as a wall-tethered calendar and planner.

The EEE I stopped using because the original SSD was painfully slow and the bigger/faster one I got as a replacement died within a month or so. I ordered a new 64GB SSD for the EEE and am typing on it right now off a USB boot - it could become my future writing and notetaking device. It doesn't have the battery life of the Newton, but I could invest in a few aftermarket batteries as backups. This would complement my existing paper workflows, which come into play for the cases where I want to switch between drawing and writing.

Complex applications are the worst of both worlds. They don't do things intuitively, they invent unconventional UI paradigms, and they are extensively configurable, so they need a manual that begins with "how to read this manual".

The workshop analogy builds on a false premise of low configuration equating to underpowered function. A pro will use a lot of different speciality tools that have no or minimal configuration, vs. a Swiss Army Knife that is mediocre at everything. In the same way, Unix-style workflows are very "shoot yourself in the foot" stuff, but formal configuration of each tool is minimal.

The best thing a complex application can do is be a general-purpose programming API at its core, with common workflows surfaced as a polished, simpified UI. Each of those workflows is its own application, with internal developer documentation to orient someone who wants to hack on it. Then the 80% cases are solved by default, and the 99% cases("this thing doesn't let me configure x") are solved by copy-pasting the application code and modifying a single line based on a Stack Overflow answer. And everything beyond that, you had to code anyway, so you enjoy a real programming environment with documentation instead, and hopefully a hook into the broader ecosystem so that the API is available throughout different coding environments.

Sadly, almost no application intentionally evolves in this way.

I've been able to play with one of those in the past year. It's still an attractive device even today, a bit like a form factor and OS variant on the TI graphing calculators.

If someone announced a new version with small updates(e.g. backlit screen) I'd be interested.

Edit: that said it would be competing with tablet + keyboard + battery pack combos now.

The framework level stuff is definitely reusable. Anything that involves rendering or collision touches on design decisions and thus impacts engine reuse. The off-the-shelf systems do conventional designs and workflows well, basically. But you go around them as soon as you want to explore in depth, no matter how big or configurable the engine is.

This leads to a situation where copy-paste at the start of the project may be the best way to reuse good stuff. Otherwise too many assumptions change. If you try to make it a parametric problem, you usually just find out you introduced accidental coupling later.

I'm feeling a lot more interested in OOC now than the last time I looked, not because the language changed but because I did.

I've tried everything else that's popular in the domain at this point and overwhelmingly, the problem is that new systems languages are too big, too incompatible with the existing ecosystem, or too immature in their tooling. They are usable, and many of their cares and concerns are justifiable, but they're overwhelming in a lot of ways. The compilers do so much, and they break, they have weird error messages, or do surprising things with their advanced features. They're mainly built by people who want to make great compiler technology - and they have that, but that doesn't necessarily lead to a smooth development experience on my end.

Most of those issues are sidestepped with a smaller language that just encodes a bunch of common idioms, which OOC does. There are other viable "compile to C" languages out there, of course, but I'm getting more interested in this one.

Edit: And yeah, this is the Go argument. But Go doesn't want to be C-like, really.

In general it's safe to assume that the world will default to thinking that you, I, and technology are all irrelevant. Like, people will say that it's important in the same way that politicians say that voters are important.

So when it isn't irrelevant, it's because things have snuck in to change the status quo. The internet, I think, is a big enough idea that it's still not really seen it's full impact yet - today we just see the waxing phase of the second attempt to lock down the network under the thumb of a few centralized players. (the first one being AOL et al.) but networks are really quite powerful, and I have faith that the pendulum will shift again.

This is a really important perspective. It comes up in all sorts of fields: If your project is too big to fail, nobody wants to cancel it.

Therefore, everyone tries to make their project too big to fail. It doesn't matter whether the organization as a whole benefits.

There's a trick one can pull if you decide to engage with literal thinkers head-on, and that is to give them bait by inserting a "great error" somewhere in the text, for example:

> ...this method is justified, because we know the earth is flat.

This is one of the core techniques in esoteric writing. What the great error does is intentionally push the dynamic of the conversation away from agreeability on the surface towards "picking apart and puzzling". People who aren't inclined to think about things will miss the great error entirely and go on without feeling the need to remark(since the essay's surface will usually be framed towards an audience's status quo), but once the error is discovered, the rest suddenly falls into doubt, and then literal thinkers are suddenly confronted with an essay that is far more challenging, because your error was not just an error, but a trap to force them to think about the other statements carefully in order to "prove you more wrong". It is their thinking, and not yours, that becomes warped. To pull this off the essay has to hold a tension between truth and falsity where some statements hold true even under inspection, while others don't.

This also makes the resulting comment threads much more lively since they will consist of smart people falling over themselves to show how wrong and stupid you are, only to find their minds are changed by the end.

In support of your comment, I would point out that gaming has become progressively less interesting for its technical developments over time. The first videogames really were revolutionary, even as they were derided for being crude, inauthentic, or simple transcriptions of games already playable with cards, pen and paper. The improvements from there have made them more accessible and appealing, but the forms and meanings of computer-driven interactivity haven't fundamentally changed - more realistic 3D just isn't as impressive as the first real-time 3D. We already passed the tipping point in terms of cultural impact, and VR is superfluous to that. It'll make its way into the world eventually, but not with the flash and bang that this generation is banking on.

Now, if we were talking about neural interfaces, that would be a more interesting discussion.

I think there are some answers to be found in technological histories, both creative tools and otherwise. The main point to consider is that new technologies augment the possibilities - outright replacement is actually the unusual case, because there's always some odd reason to have the old stuff around.

Artistic workflows definitely rank among those reasons; they do tend towards Taylorist efficiency when the artist doesn't want a restriction, but desire to be a maximally efficient artist in every aspect can lead to a deep probing of your motivations for doing any art to begin with, instead of just jotting down what the piece is supposed to be. So most artists will take on at least one technical restriction of some kind, consciously or no. That restriction subsequently guides and shapes everything else they're doing.

So for people who want their focus to actually be built on the limitations of analog, they need analog. Period. And that isn't most people, since there are many other ways to go about setting limitations, and what is usually needed when it's called for is an indication of analog, not its every nuance and imperfection. But like a car enthusiast who can enjoy old and inefficient designs, someone who really cares about analog audio will want to have the experience of the real stuff, despite the painstaking elements of doing so.

edit: And I welcome digital imitations. The newest VA synths really capture the imperfections of old stuff in a way I haven't heard from previous attempts, and I want to use them for that. But I don't want to have an analog box to tote around and maintain.

There is a point, but I think the wrong things are compared to indicate that it's "apples to oranges".

XML is designed towards a type of problem that is not an everyday programming problem. It is designed for a full-fledged schema - it builds on the lessons of SGML and its predecessors such as GML[0], for people who need those things, which has historically meant "documentation writers". DocBook and DITA do not really have equals at what they do, which is semantic, textual content with rich markup. (Yes, you like TeX. But it focuses on presentation for typesetting, not semantic meaning.)

This means that in practice XML is really useful for describing an abstract, pre-tokenized syntax. This is a useful tool from a language design perspective; it lets you take an intermediate position between human-friendly and machine-friendly formats, without going straight to binary data or writing a full string parser. When computer language tooling emits an XML AST, they give tool-writers who would like to manipulate or inspect the AST a major leg up.

Simpler forms like sexps or JSON exact additional overheads on that problem that can be nearly as bad as just writing a custom string parser, once you get beyond the "strings, numbers, and simple containers" cases that are basically about data serialization, not data parsing. You want to have nodes that have unique names or attributes once you get into the parsing problem, but they are superfluous if you have plain old data. And as soon as you get into mixing different types of documents validation becomes a major concern and XML has the right groundwork for that.

It's just that most people don't want or need to deal with data of that complexity, especially since XML as a plaintext document just looks like angle-bracket trash. For those needs they are better off writing in something that a string parser can work with and then using XML as an intermediate, if at all. Even for the documentation-writing situation, it's easier to write Markdown for 98% of the prose and then convert it to add the last 2%.

Basically, XML has been used for far too many things that it shouldn't, and the blame for that lies on some 90's-era hype machines that decided that XML would be the buzzword of the future and pushed it into every technology. We got some nice tooling out of it, but in the end, it's still most useful for a certain kind of document markup.

[0] https://en.wikipedia.org/wiki/IBM_Generalized_Markup_Languag...

> Many nations in the EU have some form of basic income

No, they don't.

Thus, esoteric philosophy will return to the world.

It's one of the tricks of any creative form to set down a lot of design rules and conventions - and not necessarily to make something more easily, but just to make it distinctive and cohesive. This is something I never had explained to me, but it encompasses so many different forms and aesthetics.

Without looking at the article, my answer was yes, because it's a philosophical nature-of-truth kind of question. (Then I skimmed the article, which is a mildly interesting Cold War intelligence piece.)

What guides my answer is that data models the world in ways tied to its medium and its designed intent. A written description of an event is different from a video of that same event. A description or video that shows more of the event, or less of the event, may also say something different about it. And database fields like "First Name", "Last Name", "Age", "Gender", "Race", "Nationality", "Religion", "Sexuality", etc. are premised on subjective social norms - when systems are designed around those fields they necessarily encode beliefs about how people identify themselves.

When you capture different kinds of data, or when you are presented with a filtered subset of data, your subsequent interpretation of that data changes your view of reality, which subsequently informs your politics.

Art is frequently based around changing the model, which sometimes means changing the medium, but often as not is accomplished through changing more abstract rules about the piece - what techniques, themes, etc. are and are not allowed by design.

Minecraft was memory-bound and bandwidth-bound such that it only really became possible in the late 2000's. A typical PC in 2000 would have, if generous, 128 or 256 megabytes of RAM. A typical connection, if any, would be dial up, with some ADSL and ISDN folks. Minecraft worlds, on the other hand, easily run into the gigabytes. Not to mention that all of its word of mouth came from popular Youtube videos.

You can definitely find examples of earlier voxel renderers that are also more efficient than Minecraft(e.g. Ken Silverman's VOXLAP), but memory limits and networking gaps would remain real and intractable, limiting its potential popularity.

1. Battery powered automotive devices, both small(hoverboards, drones) and large(cars), continue picking up steam; articles circulate about the potential danger and disruption of the new devices

2. Multiple new operating system projects announced, targeted for unikernel VM deployment

3. Emerging AI techniques commercialized for creative applications, e.g. a new wave of selfie apps, professional art or music tools

4. Distributed apps using blockchain protocols start making small ripples

5. Software and devices that successfully bridge the mobile/desktop gap are demonstrated

6. VR/AR devices ship, but demand remains modest and mostly in professional niches

I would have said something about the economy and finance too, but this is a tech predictions thread. So I'll go for a tech-economic one:

7. Trends turn against one or more of the current leading social networks, as a bold newcomer finds an opening

8. Bubble mania in the Valley peaks and shifts towards panic as key macro indicators start sagging

> it rarely makes any sense to even think about these things before you have working code you can run through a profiler. Almost always, spending your time and effort finding and using higher-level abstractions pays off much more than tinkering with your ghetto-hashmap implementation 'to make it faster'.

There is a circularity to this logic that you should address.

On the one hand, you shouldn't write your own abstractions because someone else did a good-enough one already.

On the other hand, you shouldn't try to write more appropriate abstractions because you should have working code first.

Well, which is it? If you intend to write appropriate abstractions(and that's a goal of HH), you have to start off being a bit too crude and slow so that you have a working test case; then you can gradually improve that with better algorithms as you uncover the performance profile.

Jumping to "use someone else's code" introduces a dependency and a guess about average-case behavior. That is okay if we're making "Premade Hero", but it teaches nothing about algorithm design.

And w/r to your own project, there are a lot of guesses about what will be useful or helpful - the specifications boil down to "it would be fun to add more physics and scripting to Thrust" which, as a game design goal, is quite impoverished. HH also lacks for design right now, but everything in it is built on direct experience and isn't going to box in Casey later. It is motions he is going through to show to the crowd how it all works if you were going to do it yourself.

The simplest parser style is assembly code: one line, at most one statement. But there's always some desire to get a little more code density than assembly, it's just a matter of how one wants to go about the problem.

The syntax of older-style BASIC, for example, hews close to the assembly parsing model, just adding a few special cases for different keywords. Algol syntax has a tradition of design based around algorithm description first, with generalized power second. The Forth or Lisp approaches, because they are very generic and powerful, naturally pull those languages in the direction of extensive metaprogramming.

In that sense one can see that the more sugary syntaxes treat the programmer more like an end-user, because they direct the workflow. Generalized ones encourage a DIY approach to everything. There are tradeoffs to each strategy.

Proclaiming that the syntax only causes problems stands in complete defiance of most people's preferences in programming syntax.

We like syntax errors because they mold thoughts more precisely. Going against that is also going against a lot of "productivity enhancers" - we build them because we expect to have a lot of code, and we want to reduce the kinds of errors that it may contain. That doesn't mean that we should abuse them to write as much code as we can, but it does turn out that way in practice.

So in an odd way Moore and co are right - we would be more free if we also constrained ourselves more on this point.

But the broader thought is that you can apply such constraints at any time, in tandem with what you already like. And that is more likely to produce an innovation than "just Forth".

I disagree with this form of dismissal as a rule.

If someone says something and then says "it was a joke", "it was a game", "I was just making a point", that doesn't cancel out the words and their impact - social atmosphere is not an intellectually pristine environment. You will change the atmosphere by yelling "fire" in a crowded theater and once it's done, there is no going back.

Likewise, if we dismiss someone's statement because "it was attention seeking", "they didn't really mean it", "something was misunderstood", "it's just part of the culture", that also doesn't cancel it out.

There are plenty of young, impressionable folks who latch on to ideas unthinkingly because they cannot take anything seriously at their age and level of maturity. But that is not usually the case with a 32-year-old adult like Shkreli, or people in hiphop culture, or people in actual street gangs.

Posturing language exists to make a claim to credibility. It serves a real purpose and is used in an instrumental way, for the purpose of conducting business on the terms of those who use it. The people who exploit this language the best contain in their personality some particular combination of motivation and lack of restraint, enabling their threats to be real to some degree.

Shkreli already displays such a personality among multiple facets. There is no reason to deny him the possibility of simply being a bad human being who is in need of careful monitoring by society.

Stop-and-start development is completely normal when you introduce a lot of project tooling and it's new and shiny.

For this reason, projects run by a solo developer tend to use less tooling and process than team efforts; the friction introduced by each new step in the workflow is a major penalty. The solo developer can just opt to ignore all the cruft and use a cheap, lazy option, because there is no communication issue.

This also presents a bit of a dilemma if your goal is to learn a workflow in order to get hired on a team using that workflow, because you will feel like you are making nothing interesting or noteworthy. Your best option is to temporarily change your mindset from "engineer building software" to "writer building documentation".

The person documenting has to play detective and ask questions constantly. It takes them four times as long to do anything because they have to write down the steps and make it digestible. But each time they make progress and write down those steps, they set down a little roadway for people to drive over in the future. They also gain more credibility as an expert in the process.

There's been a boom in small, low speed transportation devices in the last five years. For $100 you can get an "adult kick scooter" with a brake - I ride one to connect with transit. Small-wheel folding scooter designs hit a sweet spot so a lot of variants are passing through - different wheel sizes, polyurethane vs. air tires, hand brake vs. foot brake, and most importantly powered options. Electric small-wheel scooters running around $1000 are common, and recently there was a crowdfunding campaign for a generic conversion kit [0]. The article's focus on traditional mopeds getting caught up in electrification is an interesting complementary story.

And, of course more wacky, impractical stuff like the "hoverboard" or "powered longboard" has also come along at the same time. It's a lot of fun to watch all these new ideas come online - give it a few more years and they'll all be in the impulse-buy range.

[0] https://www.indiegogo.com/projects/shareroller-add-on-e-powe...

People are faced with any number of ways to distract themselves electronically now. That makes it hard to enforce the environment of necessity that builds traditional skills.

On the other hand, when they do show an interest in something - and you will have to be very patient about figuring out what that is - there is probably an angle to it that involves automation, and thus computing.

This may be a British/American English gaffe. Collective nouns in British English are referred to using plurals, e.g. "Apple are planning a new product," vs. the American "Apple is planning a new product."

It's not documented and I don't want to read 200 lines of code.