mschaef

Some of it's size, some of it the fact that the camera is a second device, and some of it's workflow.

I tried a Sony RX100 (1" sensor) when they first came out, optimistic about the possibility of using it for 'general purpose' photography. After all, it's small enough.

The problem was, it's a second device to carry around and keep charged. Then once you capture the image, it's largely stuck on the device until you find a way to offload your images. I briefly experimented with cables that would let me do things like transfer images from the RX100 to my (Android at the time) mobile phone, for archiving and sending to family and friends. That turned the whole thing into the sort of science fair project that I didn't have time for as the parent of a very young child. (Although in fairness, I can't think of a single time in my life when I'd have had the patience, kids or not.)

This is why, for all the arguments you can make against them as cameras, I've come to be very thankful for the amount of effort that Apple and others have made to get appealing images out of devices I always carry around anyway. I can take a set of pictures, edit them, have them automatically archived to cloud storage, and send them to whoever I want.. all with a single device I was carrying around anyway.

This leaves open the fact that the 'real' camera workflow is still an option when there's the need for higher image quality and the time (or money to hire a photographer) to take advantage of what a DSLR or the like can do.

(When I compare what I can do with my iPhone to what my parents had available to them (a 110 format camera and 35mm Nikons), I like the tradeoffs a lot better. the image quality available now is definitely better than the 110. Some of those 35mm exposures are probably better quality than what I can get out of an iPhone, but they're all stuck in albums and slides, and nobody ever looks at them. )

I have a couple DSLR's and a large frame compact, and I wholly get your point. The image quality on even an older DSLR is better, mainly due to the physics of the optics - there's nothing like a high quality lens dumping a bunch of light on a large sensor.

However.... it's really hard to overstate the workflow and convenience aspects of shooting with a phone. (Particularly as a parent, and even moreso when I was a new parent of a small child.) The phone has the twin benefits of 1) being present almost always and 2) being immediately able to process and transmit an image to the people you might want to see it. For the 99% case, that's far more useful than even a very significant improvement in image quality. For the 1% where it matters, I can and do either hire a professional (with better equipment than my own) or make the production of dragging out my DSLR and all that it entails. This is like so many other cases where inarguable technical excellence of a sort gives way to convenience and cost issues. IOW, "Better" is not just about Image Quality.

Apple made the II series for a long time. It was contemporaneous with the PET, but stuck around long enough to be relevant through the C64 and 128 (to the extent the 128 was relevant at all.)

> It feels like the industry quickly moved beyond the reach of the "hobbyist". There were no more "clever tricks" to be employed

It happened in a matter of a few years. The Apple II was built as a machine capable of running Breakout in software. Woz picked the 6502 (originally for the Apple One) because he could afford it.

It wasn't that long after that Commodore released the C64. They chose the 6502 because they'd bought the 6502 fab to protect their calculator business (and then they used it to assemble custom video and audio chips). From there, we were off to the races with respect to larger and larger engineering requirements.

Oddly, I wrote a bit about it a few days ago (in the context of John Gruber's recent discussion on the Apple and Commodore microcomputers): https://mschaef.com/c64

Thank you for the feedback. A month ago, it didn't need any text in the password field at all. I may have overshot the mark a bit when I added validation.

Longer term, I mainly want it to just use external auth (Google, etc.) and not use passwords at all.

Thanks for trying. (It expects mixed-case, which I need to actually say in the messaging.)

The codebase started out as something I used entirely myself, so the aspects of the workflow that relate to new user onboarding (most important for actually getting customers) are the ones that are the weakest. So this part of the codebase is where I'm working now to clean it up and it's probably also the most rough.

After trying text files and other apps, I wrote my own about ten years ago and have been using it ever since. ( https://famplan.io - I'm starting to turn it into something other people might use.)

I tend to agree with the idea that simpler is better, but a single text file wasn't quite enough. I like being able to see my lists on multiple devices, I tend to like to have multiple lists for different purposes, and it's also very useful to have shared lists for coordinating with my family and others.

The experience of using this has taught me a few things about how to use these lists effectively:

1. Using a list is like writing a journal - you need to be intentional about explicitly working to make it part of your routine. (Part of this is committing to record tasks that need to be done and then committing in some explicit way to actually doing those things.)

2. It needs to be fast, it needs to be easy, and it needs to be present. Anything else gets in the way of point 1.

3. It's important to track when you need/want to do, but lists of things to do can be overwhelming. (It's useful to have at least a few ways to ignore items when you can't or don't want to deal with them. I handle this by having multiple lists, and also having a snooze feature to ignore items for a while.)

4. You need to have a way to handle items or tasks that go on for a while. (You need to make a call, but have to leave a message, and are waiting for a callback... etc. These are places where you need to take action to push something along, but the action doesn't result in a complete task, so you need to revisit it later.)

This is going to sound odd coming from someone who wrote a tool for the purpose, but the key here is really to pick a system (any system) and then actually use it. Spend too much time developing the system, then all you've done is give yourself something else to do.

I haven't worked in COBOL, but I've worked with it.

This was around 1999, and I was building a system for configuring and ordering custom PC's at a large distribution company. One of the feature requirements was that we display inventory over the various options. (ie: There are 373 20G disks in stock, but only 12 30G disks in stock). The idea was that this would let a customer ordering 200 machines know that they should pick the 20G disk if the wanted it now.

The way inventory at this company was done was via two systems. There was a normal SQL database that had access to a daily snapshot of inventory taken from a mainframe that always had the up to date data. With the mainframe taking a while to process queries, we used the less current SQL database for the majority of the UI, but took the time to query the mainframe once a customer was in the shopping cart. Customers might see a change during the flow, but it would at least let them see the most current data prior to committing to a purchase.

The mainframe query itself was implemented by someone else as a COBOL job that produced the required inventory numbers. From my point of view, it was just a limited sort of query conducted over a specialized JDBC driver. (Not necessarily the weirdest aspect of that design.... for a variety of reasons, we did the UI in ASP/VBScript, the back end using Microsoft's JVM invoked via COM Automation, and the SQL database link was via a dubious use of a JDBC/ODBC bridge to connect to SQL Server. It all worked, but not the most solid architecture.)

==

My only other mainframe experience was working as an intern for a utility company a few years prior (1991-1992). They used CDC Cyber mainframes to run the power grid, using something like 4MM lines of FORTRAN code. The dispatchers themselves interfaced to the system using consoles with 4 19" color displays running at 1280x1024. Heady stuff for 1991. (The real time weather radar screen was cool too, in an age before the internet made it common place.)

> The core problem it addresses is client-server coupling. There are probably countless projects where a small change in a server’s URI structure required a coordinated (and often painful) deployment of multiple client applications. A HATEOAS-driven approach directly solves this by decoupling the client from the server’s namespace. This addresses the quality of evolvability.

Not sure I agree with this. All it does is move the coupling problem around. A client that doesn't understand where to find a URL in a document (or even which URL's are available for what purpose within that document) is just as bad as a client that assumes the wrong URL structure.

At some point, the client of an API needs to understand the semantics of what that API provides and how/where it provides those semantics. Moving it from a URL hierarchy to a document structure doesn't provide a huge amount of added value. (Particularly in a world where essentially all of the server API's are defined in terms of URL patterns routing to handlers. This is explicit hardcoded encouragement to think in a style in opposition to the HATEOAS philosophy.)

I also tend to think that the widespread migration of data formats from XML to JSON has worked against "Pure" REST/HATEOAS. XML had/has the benefit of a far richer type structure when compared to JSON. While JSON is easier to parse on a superficial level, doing things like identifying times, hyperlinks, etc. is more difficult due to the general lack of standardization of these things. JSON doesn't provide enough native and widespread representations of basic concepts needed for hypertext.

(This is one of those times I'd love some counterexamples. Aside from the original "present hypertext documents to humans via a browser" use case, I'd love to read more about examples of successful programmatic API's written in a purely HATEOAS style.)

> Yeah the era of "memory can outrun the CPU" was brief and glorious.

I don't think I fully recognized at first what was happening when wait states, page mode DRAM, and caches started appearing in mainstream computers. :-)

> Not sure about this alternate reality where Apple's 68000 machines were cheap :-) (I say this as an Atari ST owner).

Yeah... I should have cast a broader net. The Atari ST machines were much better deals IIRC. In any event, DTACK grounded PoV was that the 68000 was targeted at minicomputer scale machines, so anything that fit on a desk at all was arguably going to be inexpensive. (Years later, I did embedded work on 68K class machines intended to run in low power environments. They had to be "intrinsically safe" in potentially flammable industrial control environments. That architecture had a long path from 'minicomputer class' to where either wound up.)

The other thread this reminds me of is a bit later, Definicon was selling boards like the DSI-780. These were PC AT boards with an onboard 68020/68881 and local memory. Computationally intensive jobs could be offloaded to that board, which was supposedly like a VAX-11/780 on your desk. In some ways, it served a similar role to the DTACK attached processors, but at a slightly later point in time.

Like the DTACK grounded products, the window of time in which these products had value was oh so short, relatively speaking.

Truly from another era.

If you're not familiar, basementcat is right... DTACK grounded refers to the DaTa ACKnowledgment pin on a Motorola 68000. It's the signal that (when grounded) lets the CPU know that data it has requested from memory is ready to be read off the data bus. Systems with slow memory need to be careful that they ground the pin only when the memory has responded.

However, if your memory system can outrun the CPU, it was possible to just ground the pin and assume that the memory always responded in time to satisfy the CPU's read requests. The centerpiece of "DTACK Grounded" was a set of Motorola 68000 CPU boards that (initially) did just that. The memory parts they used were expensive for the time and small, but they were fast, allowed DTACK to be grounded, and allowed the overall design of these CPU boards to be very simplistic and inexpensive. For a while, these boards were most likely the most accessible path to a 16/32-bit microprocessor like the 68000.

What was also interesting was the way that these boards were used. They were sold as attached processors for Commodore PET's and Apple ][ machines. The software would then patch the internal 8-bit BASIC implementation to delegate math operations to the attached processor. Believe it or not, the speed improvement offered by the 68000 was significant enough to offset all of the other complexity around this implementation choice. The net was an accelerated and mostly compatible BASIC.

Later in the newsletter, the author talks about pairing an Intel 8087 with a 68000 to get better floating point. (The 8087 was a remarkable chip for the time.) The 8086 that was needed to run the 8087 is referred to as a 'clock generator'. I guess the net architecture here was to be a 6502 Host CPU, connected to a 68000 attached processor using an 8086 and attached 8087 to accelerate floating point.

Meanwhile, PC clones had sockets for 8087 chips, Apple was releasing relatively inexpensive 68000 hardware, and the 80386 was well on the way. The writing was on the wall for the DTACK grounded approach to accelerating 8-bit microcomputers, but it must have been interesting while it lasted.

> Especially FP, where it's very clear that mastery of it is extremely powerful. On the other hand, there are some like our regular synchronization primitives where not even mastery will save you.

This alludes to my biggest frustration with FP... it solves problems and should be more widely used. But by the time people are exposed to it, they've been doing imperative programming since grade school. It's harder for FP to be successful developing critical mass in that setting.

At least, this is my theory of the case. I'd love counter examples or suggestions to make the situation better.

> I feel like these explanations based on cognitive development...they're always (unconvincingly) used to rationalize why language A is better than language B.

I'm not arguing that one language is _better_ than another... just that people are exposed to some programming concepts sooner than others. That gives these ideas an incumbency advantage that can be hard to overcome.

> any attempt to prove something would have a high bar to pass.

Honestly, the best way to (dis)prove what I'm saying would be to put together a counterexample and get the ideas in broader use. That would get FP in the hands of more people that could really use it.

> Getting all this on a smart, distributed runtime seems very promising.

Hopefully it is.

This CPS article is the first of the Rama blog posts where it seemed like there might be something there. The earlier posts - "I built Twitter scale Twitter in 10Kloc" - were never really all that convincing. The thing they claimed to have built was too ambitious a claim.

> I feel like CPS is one of those tar pits smart developers fall into. ... eventually the language designers just sighed and added promises.

Bear with me, but raising kids taught me a lot about this kind of things.

Even at two or three years old, I could say things to my children that relied on them understanding sequence, selection, and iteration - the fundamentals of imperative programming. This early understanding of these basic concepts why you can teach simple imperative programming to children in grade school.

This puts the more advanced techniques (CPS, FP, etc.) at a disadvantage. For a programmer graduating college and entering the workforce, they've had life time of understanding and working with sequencing, etc. and comparatively very little exposure to the more advanced techniques.

This is not to say it's not possible to learn and become skillful with these techniques, just that it's later in life, slower to arrive, and for many, mastery doesn't get there at all.

Some of it depends on perspective. I was introduced to Logo in 1983 on a Commodore 64, and got a lot of mileage out of turtle graphics. (To the point of experimenting with recursion and circles, etc.)

The other thing to realize about Logo is that it was developed as a version of Lisp suitable for teaching programming concepts to young children. Turtle graphics were added because it was very anthropomorphic - children could more easily do things like give turtle graphics style instructions to other children and visualize themselves in the place of the turtle to debug their problems. It was intended to be close to a 'zero-entry swimming pool' style approach to programming.

But turtle graphics were intended to be only the beginning. The language also has a full set of list and structured data primitives. Children that started learning how to draw squares and geometry on the screen could take that basic skillset and use it to do progressively more advanced computation. Commodore 64 Logo included a version of the Animal guessing game that was built on List manipulation and didn't use turtle graphics at all. That was directionally where learners were expected to take the language, given enough time and appropriate education.

Underpinning all of this was a belief in constructivist education that had kids learning through doing, building, and experimenting. The idea was that Logo was a way to facilitate this sort of thing in an accessible way. How often do children (or anybody) get to define the rules of a 'world' and conduct experiments to see what those rules produce.

There's a lot of idealism in all of this, but I consider myself very fortunate to have been exposed to it when I was.

Maybe not - neither of these came with TCP/IP out of the box. Windows 3.1 didn't come with networking at all out of the box. (That was an upgrade product.)

It says something about the state of our industry that it has the credibility that it did.

Sun also briefly made a 386 based workstation. It didn't do well, but it could run DOS via V86 in a window on an otherwise Sun desktop.

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

Same here.

A mix is the only solution at the moment.

The problem is what you'd expect - wind and solar are what are known as energy resources. They are not capacity resources. This is another way of saying what you already know - wind doesn't work in still air and solar doesn't work at night.

This presents a handful of challenges:

* Generators make a lot of their money when they run. WWS can displace thermal units, reduce their runtime/profitability and make them less economically viable. (Even though they currently provide essential services that cannot be replicated with wind or solar)

* Solar falling off at night (or during an eclipse) requires thermal generation to step in to make up the loss. Just as an example, the eclipse cost TX something like 14,000MW of generation over four hours. That's ~25% of grid load around the time. They had to turn on 14,000MW of generation over two hours, turn it back off over the next two, and then ramp it all back up as night fell. This is not easy to do.

* Wind and Solar are typically both distributed and remote. Power needs to be moved over long distances from many places. This adds both cost and complexity, but also the need for reactive support for voltage stability, etc.

I tend to support wind/solar, but you shouldn't lose sight of the fact it's very complex to get it right.

It means what it says - imported from a tie to another adjacent network. It can be renewable, but does not have to be.

I had a series of HP devices around this time including an 11C, a pair of 48's, and a 200LX. The 200LX was the one that got the least use. It was would've been great if I had a need for custom DOS apps on the go, but as a general tool it was both too limited and too awkward.

(In an alternate world where calculators still made sense, it'd still have been interesting to see the 200LX form factor with hardware/software from the calculator division. They did at least get somewhat close to this with the financial calculator app.)

There for the purpose of making it easy to write card games. There were also a number of characters inspired by Wang word processors, which there'd been an early plan to reproduce on the PC.

> 2) They do. But then you read actual programs available on the web and they still default to using alists.

I was wondering how true this was, so I checked Planet Lisp. The first article is an admonition to use structures and classes _instead_ of alists, and it's followed by a bunch of other articles that use instances, structures, and hash tables. No a-lists to be found.

I've used Lisp (mainly Clojure, but others also) and I don't even remember the last time I used an a-list, outside of maybe Emacs Lisp. As you point out, they're a mostly dumb idea in an age where there are better data structures and memory hierarchies are multi-leveled and often packet switched.

I'll agree with you that it has been part of the Lisp culture, but that's the Lisp culture of the 70's and 80's. The language has moved on.

> It demonstrates that your criticism of the syntax of array languages boils down to “it’s different than the things I already know”

There's a lot of value in leveraging existing knowledge and experience. If something is different, it needs to justify the expense of overcoming that difference in terms of time and utility.

This is not just a 'tech' issue, it predates that. To pick the example of syntax, infix languages date back to at least John Backus' FORTRAN compiler in the 1950's. That team selected an infix syntax (at the cost of taking on implementation complexity) for the express purpose of aligning with what its expected user base was familiar with. In this case, it was an approximation of the infix notation universal to mathematics for centuries. Even now, infix is taught to kids as young as five or six, if not younger.

Any alternative syntax has to overcome heavily ingrained training in legacy syntax. It also has to overcome the fact that the existing legacy syntax is a more universal means of communication. The fact that something else is new, does not necessarily make it better or worth the investment. This is particularly the case when when there are many competing ways to spend time/energy the point is communicating ideas. (It strikes me as a little odd the tendency of our industry to so often pursue inventing novel languages to help improve communication.)

> Lisp is defined by much more than syntax. I certainly see many flaws in it (starting with the cons cell), which are total deal-breakers for me

This is a weird complaint, given that 1) linked data structures are almost universal in languages with pointers/references 2) all serious Lisps dating back to before Common Lisp offer alternative data structures 3) some Lisp's (Clojure comes to mind) essentially deprecate the cons cell in favor of these alternatives.

> When I first learned C, I didn’t know English well enough to understand what “if” or “else” meant. I learned these words in the context of programming first, and natural language second. This experience is probably the same for most of the world’s programmers.

This is the experience of learning to read music without speaking Italian. "Allegro ma non troppo" doesn't mean much in English.

> APL notation makes more sense once you get...... APL is way more regular... With it's small set of special symbols, regular syntax and human-friendly infix notation APL is designed be very easy to learn....It looks utterly alien to programmers that are used to the C-style syntax based languages, yes.

As you might guess from my original post, I'm a Lisp apologist. I like the syntax and I can make an argument for Lisp [1] that sounds a lot like the argument you make here for APL. From what you say and from what I've read, I suspect APL is another language like Lisp (and Smalltalk, Forth, and Tcl). These are all languages derive a great deal of elegance and coherence from a pure approach to syntax and design, and all are seductive in their way to people that have taken on the effort to learn how they work.

The problem is that this doesn't matter enough to overcome the incumbency bias in favor of more traditional languages.

> but your JS or C# code looks as alien if not more alien to an non-programmer as does APL to you.

It would be convenient for APL if this were true, but the reality is that it's not.

I learned Logo and Basic when I was eight. My kids learned JS/Python around the same age. This is a common experience. It's just not that hard to learn basic imperative programming in an infix language.

1] https://mschaef.com/lisp-syntax

Whatever trouble Lisp had from its parenthesis heavy prefix syntax will be dwarfed by the comprehensibility issues presented by this:

    { ⊃ ⍵ ⊇⍨ ↑⍒≢¨ ⍵ /⍨ 2≥ (⊂"aeiou") (+/∊⍨)¨ ⍵ } io:read "dict.txt"

I get that there's a very coherent intellectual framework to this, and it's possible to get used to it... but most people don't do that.

This is particularly true when the alternative is Excel, which was widely accessible before it was taught in schools, and is now taught in schools too.

(This language comes from a history where it used to be necessary to by special typewriter balls to print the text. https://www.computerhistory.org/collections/catalog/10269647... )