chipsy

Faxing did exist essentially as soon as they came up with wirephoto. It was just really, really expensive for a long time, and you got a better average benefit out of a long distance call or telegram.

I think it is absurd to think that the paper is not impressive. The rendered output shows no sign of corners being cut - it is nicely laid out and has well made graphics. It's about as good as TeX output, and the system is doing far more work to get to the point where it can render. The same size team and schedule with a more conventional approach might make something like Word in a similar amount of time, but without the underlying flexibility.

I like this post because it captures some way in which my perspective has changed over time. Engineering was something I saw as a way to perhaps "cheat" at product problems because if I made a good enough/fast enough/automated enough/generic enough solution, I would be able to iterate on it really fast and so somehow come out ahead of people who went directly towards the simple solution. This mentality was clearly inspired by years of homework being a task that would never go away and that I desperately wanted to get out of my life as fast as possible in the way that consumer products advertise their elimination of household tasks - ergo my goal as a student was to wish I could automate away all aspects of my studies. I would look for any kind of secret trick or forgotten technique that would get me closer to that goal at minimum effort. All the while I would build very little that was finished and get lost in maximizing my use of silver-bullet abstraction.

I've eventually come around to flipping this idea on its head, though. If I design not just some kind of product or solution, but a whole process, starting basically with how I want to run my life and then drilling into specific details from there, the technical knowledge stands on more even ground with other forms of knowledge, and with seeing life itself in a more precious sense.

With that mindset, good scheduling of every day as an end in itself grows vastly more important, and abstraction-for-its-own-sake falls away: All programming problems start by assuming they are solved first with "code that looks like breadboard wiring" [0] and then working up the abstraction ladder from there. Automating the technical parts of the solution won't guarantee that it's right in any other way, but it will ease the pain of changing the specification. Acknowledging that the problem is messy, that breadboard coding is messy, and that I won't know how to solve everything immediately and cannot depend on a silver bullet, all constitute crucial first steps.

Now I always look for really basic groundwork to be laid out early on - typically, transforming the breadboard code into something that uses a new data structure, or generating the code flow from a stack or a list or a tree - and that no shortcut is possible without compromising the ability of a potential future abstraction - that it just takes a lot of layers to get where I want to go. Breadboard code is assumed to be ideal until demonstrated otherwise, while "x in y lines" hype is to be avoided under the assumption that the solution is brittle and over-modeled towards the demo code. I cannot assume that my valuable production code will need x or work in y lines. I don't abstain from adding dependencies, but I will preference towards copy-paste-own when I find a reason to reuse code.

[0] http://www.instructables.com/id/How-to-Build-an-8-Bit-Comput...

Plan and structure more of your day. Put better things to do on your calendar, things you like such as hobbies or social events as well as "productive" tasks. Give yourself a generous amount of time to do things in, more than you expect to use. If it doesn't become a habit and you just waste all the time, figure out why. You aren't a robot and you have to make a life that works well with your natural feelings, so don't expect to become someone else just because you constructed a schedule that says so.

Edit: and don't make decisions "when you feel like it", then you fall off schedule. Plan a lot in advance and then try to stick to how you planned the day.

I remember trying this one and thinking that the language was fine(it is literally an update from the makers of the Atari 8-bit BASIC) but the UI is unsuitable as it uses generic Android text input, the same flaw shared by most every other on-device IDE I've tried. That doesn't just mean that it's crude, it's also buggy - the view desynchronizes when editing large bodies of text using that text control.

What touchscreen programming needs is a really polished touchscreen UI, and that challenges the whole assumption of a text editor being ergonomically optimal.

This has already happened with SQL databases. Performance tuning a database can be messy because sometimes you have to outsmart the query optimizer. But in the average case it is doing the Right Thing without you having to think about what engineering has gone into it.

Demand for new data models is insatiable and for each one, a software ecosystem can develop around a similar degree of automation, tuned towards the specific domain. It's a very, very black-boxed future.

At 30 I enjoyed this but have a certain criticism in mind. I do recognize that my frenzied "quest for meaning" is fading a bit as I settle into habit, but I'm also certain that that doesn't mean that I'm in a better place. I just have to look at my own parents to know that being too stuck in your ways is like a state of death manifest in everyday entropy, pardoned by believing that the entropy is a temporary illness and "normal" will return tomorrow without urgency.

It is the changes in life that make it lively, and so to live I should strive to maintain some rate of change in myself, so that I never die while still alive.

No, it's because game engines don't unit test well. There is too much I/O, latency dependent behavior, and shared mutable state to make it feasible outside of some math and low level format or protocol tests. Many game bugs are purely data bugs and result from a misconfiguration or a malformed asset. Manual testing of the result, following a checklist and creatively hammering on the system, is thus the default method.

What Riot is using is a form of integration test where manual user input is emulated to produce a result data set. What you aren't seeing in the test code is "everything else" that was needed to set up a running game state. This technique makes it easy for QA to jump in and see what's happening visually when a failure occurs, eliminating the need to slave away at a checklist.

Plus one for my interest. I became checked out of front-end framework developments when it started to become a big build process with a lot of dependencies, and if that can be reversed, I'd be happy to work with the DOM again.

It's always been really, really bad once you try to take the experience into your own hands. The path of least resistance with technology is to stay well behind the curve, choose the popular brand, avoid niche use cases, use the minimum amount of features, and modify nothing - in effect, to use everything as if it were an Apple device in stock configuration. However, sometimes more effort is worthwhile because the unmodded experience is so poor or ill-fitted.

Yesterday I finally got fed up with my cheap Android phone and flashed it with a modded rom. It took probably 8 hours of reading and downloading and testing and waiting to get it into a working state, because there are so many points along the chain where a little misconfiguration breaks the process, and the people making mods often have working software with poor documentation and inadequate testing.

In the end, there just is never enough time to go around to make it perfect for everyone in every use case. You have to choose carefully when you want to fight the battle - and you can expect to lose, a lot of the time.

Here is an example of a contemporary demo on the Atari 8-bits:

https://www.youtube.com/watch?v=eY_YsoR11d8

You might notice that some scenes show more colors onscreen than contemporaries like the C64 - this is all because of the display list interrupt techniques Crawford talks about, combined with clever overlaying of the player/missile sprite system. (The weird term for these hardware sprites is because it's built on the legacy of the 2600's system, which itself was built around the needs of the pack-in games: two players, two projectiles, one ball.)

The A8 series was limited in lifespan in the USA for a number of reasons: poor documentation, platform fragmentation, and price competition. It shipped with very little documentation on how it worked, leaving developers starved for resources for several years(Chris Crawford himself contributed to the unofficial bible, "De Re Atari"). There were the original 8k-upgradeable-to-48k 400/800 models and the newer XL/XE models, which shipped with 64k standard, and additionally, a change partway through the 400 and 800's life to an upgraded graphics chip; although most old software would run on the new machines, the C64 was more straightforward to target and to program, and it led the way in price-cutting the home computer market, which gave it a huge lead in market share. The later life of the A8 was entirely in European markets.

In terms of what the two machines can do when pushed to the limit, though, there's plenty of room for comparison.

"Topic-centric" is already a thing in technical writing. It produces those mystery-meat help systems you find in larger applications where you can find information about a specific piece of functionality piecemeal, and if you're lucky also a tutorial that tells you how to put it together into a larger workflow. If you're unlucky, it manages to summarize the parts you already knew without telling you about any details or pitfalls.

The graph is useful for note-taking and exploration, certainly, but it produces a design constraint that isn't always situationally appropriate. Binding things into a narrative can add a lot of value.

It's very difficult to have an open discussion between dozens of parties because every discussion is subject to tactics that dissuade an exploration of the topic. The pigeonholing of "challenge" vs. "offense" into separate boxes of "good" and "bad" is one such mechanism, as it premises the audience and opponents to be professionals engaged in a formal discussion, not laypeople who are there because they're curious and want to be entertained and cheer for "their" side and feel good about themselves. The ground truth is that you keep returning to Reddit or HN because it's fun enough not to quit, not because it does you any good. You can come up with all kinds of rationales why it actually does you some good, but the underlying mechanism making me write this comment is that there is a game to play here, and it's not driven by my sense of virtue or collaborative spirit.

Skilled debate in a venue like Reddit requires an understanding of esotericism, of not simply laying out facts and implications based on your own assumptions, but presenting a fascinating puzzle to the reader that leads them to challenge their own assumptions without being challenged by anyone in particular. When successful, such a puzzle glides beneath the surface tropes of the discussion, presenting the perspective without provoking hostilities. The karma system does not reward this very well, as those carefully crafted puzzles tend to get middling scores, while simple agreement, rationalization arguments(why your assumptions are right and the critics are wrong, from Someone Smart), and congratulatory joking trigger the instant upvote response. But putting in the effort into that dialogue is essential to engaging the community.

It's a language powerful enough to let you design a custom template system, i.e. it's second-order meta-programming, pushing the leveraging potential way farther than most people would even consider offhand. This kind of thing doesn't matter so much when you have a system already described within a few thousand lines, but it gains credence as more of the code consists of business logic and data models - stuff that has its own programming ruleset.

An internal, interpreted DSL can be written to do similar, but I think the point of this tool is to ease the process of writing the DSL itself, and to make the resulting runtime efficient.

It's brought on by being a big company that wants to leverage existing customer bases into new markets. Both Sony and Microsoft engaged in the "platform strategy" in the last two generations, while Nintendo sat back making traditional gaming consoles, focusing on building their own market rather than invading an existing one.

Basically, the console brand, to MS and Sony, is ultimately a tool that can be used to build a potentially bigger empire. Share and revenue prospects come before whether the experience makes sense, and in the echo chambers of such large companies, it's easy to fashion a story where every consumer is hungry for all of this stuff and wants a single source to deliver it.

Digital distribution has brought back the feeling of the older computer games in a big way. Steam has some titles, but it still puts up some barriers. itch.io [0] is the hotspot for stuff too small to notice these days. Just last night I was linked to a homage to the ICOM adventure games [1] and it was hosted on itch.

Kids don't really seem to care too much about a high fidelity experience. Everything is new and different to them to begin with, so that stuff is just window dressing.

[0] http://itch.io [1] https://grahfmetal.itch.io/infested

Simple geometry argues that you can fit more people on dedicated train cars than a fleet of independent vehicles. You don't get 100% of the benefit of stop-free transit in the real world because there will be pedestrians - you need a dedicated right of way. The argument for independent vehicles was made with rail PRT too, and it only ever reached a niche campus-and-airport market.

What you get from autonomous vehicles is improved flexibility, and that improves all transit modes while only slightly changing the dynamics that make rail vs. bus vs. car interesting.

I'm also a not-taker (as opposed to a note-taker) and my entire school career consists of binder paper covered with doodles while I listen, with half-hearted notes taken when the teacher required it for some reason. This got me into some trouble once or twice when the teacher lectured a fact that was nowhere to be found in the textbook, but for the most part it was just one of multiple things that made me a poor fit for academia.

I do make use of mind-mapping now, though. It's handy for dissecting a big linear text into branches and partitions and not overlooking parts when I try to review.

This is a nicely polished-and-optimized hardware version of the UI in Stephen Lavelle's Plingpling. [0] I have a prototype sitting around of a directly inspired "draw-to-physics" thing myself.

[0] http://www.plingpling.org/

Hong Kong faced this conundrum in the mid-20th century: Lots of refugee immigration, plus a major fire, causing an urgent housing crisis at the bottom end of the market. The city built massive, tenement-style public housing blocks, and never stopped building. Almost half of the population of Hong Kong today lives in public housing.

https://en.wikipedia.org/wiki/Public_housing_in_Hong_Kong

Parking lots are attractive to crime: Unattended vehicles, low surveillance, relative anonymity, unused space late at night. Many kinds of deals take place entirely within parking lots. The crime wouldn't vanish if these locations were busier and less anonymous, but it would be a little more challenging to go completely unnoticed.

The Bay Bridge OTOH did have a railway(Key System rail) for some time after it opened. Ripped up in the mid-century turn away from streetcars, thus we now have only car traffic on both decks.

I will allow that GC can be fast, but you have to work hard and have appropriate language features to keep it "chunky". If you have millions of small traces to follow, the n of your O(n) is going to be big. In contrast a manual collection algorithm can rely on user supplied metadata to free the whole dataset in one instant without having a tracing step.

In apps that need to scale, designing data to be efficiently allocated and freed becomes crucial and the reference by default strategy really falls down.

I started optimizing by making separate increment/render threads with a buffer and copy, and then doubled it to 4 threads. It's currently at 0xDD cycles but I don't think I'm going to take it farther:

http://i.imgur.com/sD5IAXP.png

The thread sync is pretty inefficient. It will need to incorporate some "tricky" techniques like what you've described to go faster.

It's really ungainly to work with -- but it does drop the cycle counts to solve the problems by running more threads.

It's coded. You see "handout" named as such more often when it's low-quality, inefficient service. With a system like BART, the whole thing was motivated by pressure to relieve middle-class downtown commuters specifically, and everyone else by chance(hence a design without redundancy that requires a midnight service shutdown). Geometry forces it to pass through many types of communities, but during construction, the slightly richer, whiter communities had more room to shape their relationship to the system:

Prime examples of how public pressures escalated the cost of the system are the Berkeley subway and the Ashby Station. After originally approving a combination aerial and subway line through Berkeley, that city later came to oppose the plan in favor of a subway-only line, which was much more expensive. The new plan necessitated redesign of the Ashby Station from an aerial to a subway facility. Extensive controversy and hearings ensued for the next 2 1/2 years, finally to be resolved by Berkeley residents voting to tax themselves additionally to finance the changes they wanted. Next, a Berkeley City Councilman filed a successful suit to redesign the Ashby Station, yet a second time, asserting the use of skylights in the original plans was not a true subway design. [0]

And indeed, the "nicer" stops on BART tend to be underground, while the "inexpensive" ones are mostly aerial alignments adjacent to freeways. (See the history around "freeway revolts" and you get a similar picture of class/race division.)

[0] http://www.bart.gov/about/history/history2

There's a sort of "feedback loop inversion" effect in play where transit caters to extremes of poverty and wealth and not the middle. For example, Palo Alto's Caltrain stops are not high-end real estate because transit runs through it - they're high-end because they have become a major destination for tech workers over the course of a few decades. On the other hand, West Oakland BART is within easy reach of many major destinations but it's been heavily resistant to gentrification: major firms do not have a presence there, and it's historically a working-class community, not a wealthy suburb. BART's deployment there is effectively transit as a "handout" policy, a way to make sure low-income workers get to their low-income jobs.

But places that are a bit outlying and don't have a big job market, like much of Marin, sit in a nebulous zone in between: they aren't really "in demand" right now, and that gives the community leverage to stomp out anything that would change that.

I agree too. "3D" had another push a half-decade ago in theaters and on TVs, and by this point it's reasonable to call it a failure. VR is much in the same vein: it's inconvenient enough to our lives that we're more likely to justify getting away from it than going to it. The Visicalc moment should either have happened by now or be right on the horizon. It hasn't. The demos are still basically reliant on the same kind of "spectacle" elements that 3D movies use, and the track record there is bad for franchise media - that is stuff that sells tourist tickets for theme park installations, but not repeat visits from loyal fans.

But AR, AR stands a chance. It is not hugely different to our existing uses of media technology - one more screen, in a different location, supplementing the existing experience. And it has good cross-over into VR for the remaining experiences that do work well in immersion mode. That might buy VR time to develop gradually for a few decades, like silent film. There are some things that are worth exploring with VR, but the tech really needs to be in mass adoption first.

There is a crucial element of that form of criticism, which is that it is played like a game: There is a definite time and place, a magic circle, and when it's over everything is "reset" and you just have a project artifact and happy workers.

Compare with a boss walking up on the floor and bellowing, "so, why is it late???" Now the whole office is cued in to maneuver and deflect blame, not just that one time but throughout the day, every day, until they leave the job entirely.

Really good leadership understands how to maintain the atmosphere for the situation. They can turn up the heat but do so judiciously. They have to do it with care precisely because the individuals tend to be a "bag of emotions", easily swung off track with careless dialogue.

The Reddit thread is cautionary towards a neutral business situation where the goals are simply to maintain trust, gather basic information, and assign tasks and plans. Confrontation in that instance is quite destructive.

Math-heavy code tends to involve a lot of very similar algorithms, leading to a copy-paste-rename situation that isn't really helped by using a function.

As such it's incredibly common to end up with bugs from assigning to "x, y, y" and not "x, y, z" etc. Sometimes a clever compiler will warn you that you have done something odd, other times you'll be left to discover the runtime error.