Loved the show, I have no expectations for this. It's just too easy to not be "right" for all sorts of incompatible different definitions of "right".
But, the animated series a good idea and smart.
First, it lets Nathan and Morena participate considering they're pretty busy with their prime time series.
Second, there's no reason to "jump ahead 20 years". They can pick right up from where they left off after they figure out how to dig Wash out of the ground. The animated characters don't have to age. They can do a prequel, they have a lot of flexibility which helps to not pigeon hole it.
And, ideally, the animated series can be less expensive, making it perhaps more of a chance for success and continuing (I have no idea how much modern animated show development costs compared to sets and CGI etc.).
I have not seen it, but I understand that The Clone Wars is a pretty successful series, so maybe that's an inspiration.
If there’s any chance at success, animated is probably it. Alternatively they could remake the show with a different cast portraying some other crew with a whole new storyline. Of course that’s not a reboot but it could capture the same kind of magic the first did with the right writers and cast. It could even be set before, after, or contemporaneously with the original. It would be a big expensive gamble though.
I watched "Lower Decks" episode just to see how they portrayed Deep Space 9, how actors pick their old roles. While they did good job, visuals were giving me this feeling it's a distant memory that fades away. Weird thing to say but same thing happen when I pick that "Babylon 5: The Road Home" - it's like the show you were watching but it's not the same.
And I risk saying that perhaps media that become iconic shouldn't be touched no matter what happened during production or screening. Because if you start fiddling around it even in a good faith that charm may be gone forever.
"Firefly/Serenity" for me is from same shelf as DS9 or rebooted BSG - a closed story that doesn't need any continuation. These titles got rather bitter than sweet ending; there are questions and that's good. Not everything has to be wrapped up with a picturesque idyllic scenery, where everyone "lived happily ever after".
But at the same time, I don't mind if they roll animated "Firefly". And I give them my thumbs up, will be happy if they manage to success but I don't have big expectations either.
> I have no idea how much modern animated show development costs
Animation costs are all over the place. It can be dirty cheap, it can be more expensive than a highly-produced live action. You can notice the difference, but it's not what actually matters for the show's success.
ST:TAS had some surprisingly good scripts for something that was somewhat a 70’s kids cartoon. Very much enjoyed how animation allowed them to run wild where practical effects wouldn’t have been possible (for better or worse at times, lol).
I adored Lower Decks. It was the right way to approach fan service for a franchise as I hate seeing fan service awkwardly ham fisted into every corner of nutrek. Some of the later seasons were a bit awkward, or rushed?, but overall I adored it. Terrific character development and overall really told that story of that period between being a bunch of green academy grads and being adaptable, competent professionals.
> The original Top Gun (1986) was describe at the time as the US Navy's most successful recruiting campaign ever, noted in this 2004 account citing 1990 correspondence with then Secretary of Defence Dick Cheney: <https://archive.org/details/operationhollywo00robb/page/180>.
Sure, but was that the intent of Tony Scott when he made the film, or was it just a side effect of watching exciting air wing navy operations portrayed on the big screen?
I can easily see a young man wanting to be not just a fighter pilot, but one of those guys on deck standing in the wind, dancing and pointing and saluting F-14s off the catapult.
I know some systems leverage the modern file meta data (extended attributes), but it's clearly not successful enough that folks can use them for an application like this.
Ostensibly, things like MacOS Spotlight can bring real utility and value to the file system, and extended attributes through the sidecar indexing, etc. But Spotlight is infamous for its unreliability.
The other issue with file systems is simply that the user (potentially) has "direct access" to them, in that they can readily move files in and up and around whimsically. The "structure" is laid bare for them to potentially interfere with, or, such as the case with the extended attributes, drag a file to a USB fob, and then copy it back -- inadvertently removing those attributes.
And thats how we end up with everything being stuffed into a SQLite DB.
Yeah, IMO extended metadata attributes are fine for caching data that can be recovered via other means but generally violate the principal of least surprise. For them to be successful a standardized transparent container format or something would be necessary, but at that point the FS abstraction is leaking.
Whenever I tried dabbling in Smalltalk, I would feel constrained by the system in terms of raw real estate. I never cared to view the system through the narrow slit of the method code editor. I would suffer the explosion of windows. All of it was off putting to me, and I never pushed through it to work with a project long enough in order for it to be comfortable.
But, let's contrast it to Java, which pretty much is in the same boat as a modern Smalltalk. A very large core system of packages, classes, and methods. Wrapped in a spider web of dependencies. And, granted, I've been working with Java a long time, and this is all quite comfortable to me. But at the same time, it doesn't suffer the issues that the Smalltalk browser presents.
Consider, regarding the parent point, the entirety of the JDK is not typically presented in the modern IDE. It's just back there. There's no real estate committed to it. There's your project (typically), with its classes.
I use NetBeans, so I have a project view of packages and classes, I have code tabs of individual classes, and a contextual method navigator within a class.
Its routine to potentially have a tab explosion, in contrast to a window explosion when exploring code. But when I do that, all I get is the code window, not the entire project or context of the class.
That is, in my code, I can click on, say, an ArrayList method, and jump to the JDK source code for the method within the ArrayList. I don't get its entire package hierarchy, I get its method list (uncatagorized, but alphabetical) while viewing the code file. So, the impact of viewing a new method is minimal -- it's just a new tab.
But as a benefit, I get to see not only the method I'm interested in, but I get to see the context of the code around the method. When I code, I don't write methods in a vacuum. I organize my code somewhat around aspect of the logic of the class. So, if there's a method that does one thing, chances are that the methods around it are doing similar or related things, or part of the logic of whats going on. Proximity in the source file tells part of the story not captured at the method level.
Sure, I can click around, in the navigator, in the IDE directly to visit other methods, but I can also scroll about, have the breadth of the class as a canvas and gather the ebb and flow of the logic within it. This is stark contrast to the ST "tiny" method browser.
I can also search globally within the source methods rather than just method signatures, while still having access to call trees and references and many of the other wonders of the ST browser.
Totally agree the only viewing methods in isolation,
is less valuable than viewing the methods around it "for free".
Indeed the methods in my classes are caryfully ordered,
to keep ones that are used together on the source together.
(And SmallJS is file based)
> But, let's contrast it to Java, which pretty much is in the same boat as a modern Smalltalk. A very large core system of packages, classes, and methods.
Java is used in many places. Smalltalk is not. The whole comparison falls short due to this already. TIOBE ranks Java #4 right now, which is not too bad, even though TIOBE also sucks.
My favorite anecdote relating to Firebird/Interbase (its original name) is that it is supposed to be renowned for its durability (i.e. resistance to corruption) and fast start times.
Because of this, they used it within the internal systems of the M-1 Abrahms tank.
Apparently when the main gun is fired, it gives off such a powerful energy impulse, that there is (at least was) a tendency for it to crash the internal systems.
So, they adopted Interbase because of its ability to work well in an environment where hard computer crashes are more a norm than an outlier.
There's a legend (perhaps me misremembering, or simply making it up, thus making it a legend rather than an anecdote) that Chuck Moore did something like this that eventually ended up as ColorForth.
The story is simply that he started with MS-DOS, some floppy disks, and DEBUG. Starting there, he bootstrapped to being able to boot something from a floppy, and just pushed on from there.
Its an interesting development idea of simply molding a RAM image to your liking with little more than POKE, PEEK, BLOCKMOVE and READ/WRITE the RAM image. The assembler is a tasty treat, but hardly necessary, and perhaps not as helpful as one would like since while the mnemonics are nice, its the labels that give an assembler its real power.
I always visualized putting subroutines at 16 byte boundaries, if only to make the addresses stand out a bit in the hex noise, but also to give a little wiggle room to make changes without stomping on other code. Thinking how cautious one has to be, particularly on an MS-DOS machine, you have to be knowing one misstep, one stuck loop, and you're reloading from disk again. "Save early, save often". Plus that one point when you're in the phase of writing the floppy bootsector and you now, suddenly have a larger step to go from bootable primitive Forth kernel, to one that can self-host, even if it's just defining code words as blocks of hex numbers, forgoing an actual assembler early on. But, ideally, by that point, you're already comfortable with block of hex code, however now you don't have the benefit of a disassembler outside of the carbon based meat computer stuck in your head.
I think after a day or two of full immersion in this environment, disassembling hex code would be mostly straightforward. Woz is said to have 6502 binary memorized. It doesn't really take much, you don't need to memorize it all. Knowing a dozen instructions can take you a long way.
Anyway, always been an interesting thought exercise. Nice to see something similar. I like the primitive base Forth used.
In my very modest experience, I once wrote a system that I could boot from a floppy, edit, then recompile. For this I needed to make an assembler, or rather I was willing to meet the challenge of writing an assembler for the 8086, which was notoriously difficult (not really for the subset I needed, which did not include the complex addressing modes for one thing).
When it came to writing the changes on the floppy I was very scared to trash my hard disk (writing to HD or floppy was just a value in a register when you use the BIOS API), but fortunately I found an old Toshiba laptop that had an external power-on switch for the hard disk! That thing was running at 10 Mhz in "turbo" mode!
Bottom line: I spent a lot of times reading the ISA specs, write the assembler in Forth, and compare/check its output with an actual assembler. It would have been more efficient to enter directly the instructions in hex, I think, except maybe for the boot sector.
I think after a day or two of full immersion in this environment, disassembling hex code would be mostly straightforward. Woz is said to have 6502 binary memorized. It doesn't really take much, you don't need to memorize it all. Knowing a dozen instructions can take you a long way.
It does. I am certainly no Woz, but I used to program a KIM-1 by hand assembling with pencil and paper from a programming card, then keying hex codes into its onboard keypad. After a few days you don't need to look at the card much. It's really quite practical - it's actually easier than dealing with editor and assembler tools. After fifty years, I still recall that A5 encodes LDA.
I am teaching myself Arm assembly for the M-series of processors, M-4 for now. I have been playing and using J (jsoftware.com) since 2010, and I have to say that as much as the higher abstracted languages and programs become, I still love the atoms and terseness of array languages and writing close to the metal. I started with Factor, gforth, and retro years ago. Something magical happens when you immerse yourself in it. Right now, I am working with KlongPy, which using the PyTorch backend along with the Klong language is amazing. I used to write assembly code for my Vic-20 back in the day and then bought the VIC FORTH cartridge for like $30 in 1982. I programmed my 1977 PET 2001 in the Commodore Basic 1.0 it came with, but there was a sys instruction for machine code! I used to write my code on an index card before typing it in and saving to the cassette recorder. Magazines had code to hand type in, so my coding was learned with reading and writing it first. I accidentally bought a hardcover book on PDP-11 programming and read the whole book before I bought my PET in 1977. Machine language.
I miss the early days of computing before the internet or Genie Online, but Echo in NYC was a blast - thanks, Stacy!!
Agreed, though I would say that 6502 is a lot more straightforward to memorize than x86. A lot fewer addressing modes and every instruction is always just a byte, possibly followed by immediate data. The 6502 was a little gem.
If you read the colorforth source (there’s only around 1000 instructions of assembly, it’s not a long read), there’s a real sense that much of the design (pretokenization, color tags, etc) are built around the punchline of a single (with rep prefix) instruction being used to linear-search the dictionary — going to trivial hardware-supported data structures here constrains the implementation a bunch, but there’s magic in self-imposed constraints.
there's a similar story by kragen on .. hmm HN or maybe SO where he describes a bootstrapping from a micro hand crafted asm monitor to forth to more and higher level languages. "stuck-in-a-basement" kindof challenge.
I can’t speak to getting an LLM to talk to a CL listener, simply because I don’t know the mechanics of hooking it up. But being as they can talk to most anything else, I see no reason why it can’t.
What they can certainly do is iterate with a listener with you acting as a crude cut and paste proxy. It will happily give you forms to shove into a REPL and process the results of them. I’ve done it, in CL. I’ve seen it work. It made some very interesting requests.
I’ve seen the LLM iterate, for example, with source code by running it, adding logging, running it again, processing the new log messages, and cycling through that, unassisted, until it found its own “aha” and fixed a problem.
What difference does it make whether it’s talking to a shell or a CL listener? It’s not like it cares. Again, the mechanics of hooking up an LLM to a listener directly, I don’t know. I haven’t dabbled enough in that space to matter. But that’s a me problem, not an LLM problem.
I live in rock and rolling California, and we love our stick framed houses. They’re very resilient to the tremblors that plague us.
Yea, if we’re hit hard enough, the stucco may or drywall may crack, but, big picture, those are cheap cosmetic fixes compared to anything more structural being damaged.
Back during the Northridge quake, my friend was buying a second floor condo in Santa Monica (which was hit pretty hard). It resulted in several drywall cracks, but nothing worse than that. Even better, the closing day was scheduled for the day after the quake.
My (large) bank is yanking their safety deposit boxes out. They let subscribers know that they have, like, 1 or 2 years to go. They're doing it across the branches. They basically feel it's not worth the liability any more, and the way it was presented to me, it's not just them, but other banks are also doing (or at least considering) this.
Things we take for granted. When my father passed, I was digging stuff out of SDBs that he had for decades.
reply