jasim

What about long arrays? Is there a mechanism where Svelte knows which element is mutated, and do fine-grained recomputation/update only the corresponding view elements?

This is the primary place where we have to go outside the framework in React. Only a large linear list has this problem -- if it was a decently balanced component tree, then we could skip updating huge swathes of it by skipping at a top level node. But it is not possible in an array. You have it iterate through each element and do a shallow comparison to see if the references have changed.

That said, it is fairly easy to escape to DOM from inside a React component with useRef and the portal pattern. Then we can write vanilla JS which makes updates to only the values it changes.

If Svelte solves this in an elegant manner, then it would be a very compelling feature over React. I'm asking here because last I checked, most of the examples in Svelte's documentation pointed to simple counters and regular objects, and I couldn't find an example of a large linear list.

I've been using Zed for a few days now, and it is really nice!

I tend to use JetBrains IDEs for development and Sublime Text for everything else, with VSCode being an "if I don't have any other choice" option.

Zed is already feeling like a great meld of IntellJ and Sublime - the features of an IDE with the lightness of Sublime, and excellent aesthetics that Atom was once known for.

Can anyone explain the deep nostalgia and longing for old DOS era software, and in particular VGA text mode interfaces?

I love staring at these screenshots and spinning up a DOSBox every now and then and going thru 1-2-3, FoxPro, WordStar and so on.

I don't know what I'm looking for from them, does anyone else have a clue?

When you boil it down like that, then all problems in the world is a people problem. They can also be a systems problem, an incentives problem, and often a training/cultural problem. These framings are all valid, and have their place. But certain framings can help solve certain situations better.

In the narrow confines of programming, a way of thinking where we structure problems as transformation of data from one shape to another and minimizing mutable state can help systems be more robust. It is not an object-oriented vs functional programming debate. It is just a good practical way of approaching problem solving.

Unfortunately that is a very high-level description bordering on woo-woo. Which is why the book discusses these ideas with concrete code examples. For a lot of us who've hit a wall with the kind of reliable systems we could build, and discovering this new approach, it is an understanding borne out of lived experience. There is a lot of tacit knowledge here that's difficult to unpack and even more difficult to transfer to others. This book, like many others, helps, but cannot be a substitute for doing the actual work of experimenting, making mistakes, and internalizing.

But all of that is moot unless folks care about it, and care about it in the right way (like not going all in on functional programming and deep copying and immutable values where tight zero-memory-copy zero-alloc zero-kernel-call code was necessary), all of which finally makes it a people problem I guess?

> Functional architecture makes extensive use of advanced abstraction, to implement reusable components, and, more importantly, supple domain models that anticipate the future.

I believe Mike Sperber is talking about Haskell when he says "advanced abstraction", but most regular line-of-business software can reap significant benefits with just simple FP principles: mostly immutable data, record types, sum types, and a vocabulary of small decomposed functions that can parse, transform, and combine this data, together building to larger wholes.

You do need a language with types and first-class functions, and the most common vehicle for that currently is TypeScript. Combine that with a book like Grokking Simplicity by Eric Normand, especially the fundamental idea of separating data, computation, and action, and you have a software system that is supple, simple, and amenable to continuous growth and refactoring over a long period of time.

Grokking Simplicity, IMO, is a severely under-discussed book when it comes to FP. Its only sticking point for me is its lack of static types, but otherwise it is the first and only book that I've seen that distils the functional way of thinking for the working programmer in an accessible way, without having to resort to the all-or-nothing proposition of completely pure FP.

This feels like process and principles driven design, which I've found to often result in a sub-par end-product, but with copious rationals.

You see the end product and you know this is not what you want, but being an instinctual reaction, it feels arbitrary and unfair. And processes are there exactly for this reason: so that some capricious stakeholder cannot impose stupid blockers without being seen as unreasonable in the face of so many "facts".

I think some of the best designs come out of the un-reasoned aesthetics and preferences of designers deeply immersed in the craft, and with all the reasonings post-hoc so it can be pushed through a political process.

> The researchers utilized 286 participants recruited from two universities: one in the United States and one in the United Kingdom.

The discussion here is interesting, but the research itself falls to the typical psychology research trap of using university students.

Clear and Simple as the Truth: Writing Classic Prose by Noel and Turner.

I read it when I was trying to find a writing tone that I was comfortable with. Should it be casual, cool, and excited! with lots of exclamations? or detached, clinical, and precise? or, flowery, fluffy, and inserting difficult words, especially "dichotomy" everywhere I could?

One ideal I enjoyed was the 90s hacker writing aesthetic. PG's essays for example. It is easy to say "edit, edit, rewrite", but the tone was not easily pinned down.

Clear and Simple as the Truth is the best writing book that I've read - it answered these questions for me thoroughly, and the writing is delightful. I've read it cover to cover twice, and find myself enjoying a few quotes on occasion.

A quick takeaway among many - it is the sophistication and clarity of thought that matters, not one's facility with the language.

"Great painters are often less skillful than mediocre painters; it is their concept of painting—not their skills—that defines their activity. Similarly, a foreigner may be less skillful than a native speaker at manipulating tenses or using subjunctives, but nonetheless be an incomparably better writer. Intellectual activities generate skills, but skills do not generate intellectual activities."

Yes, IIRC, Clipper 5's big marketing point was `aeval`! (short for array eval, array.map in modern langs).

Clipper also had a huge array of third party libraries, I fondly remember Nanfor, Grumpfish, and SuperLib.

If you want to see some code, here's a repo of one of my Clipper projects: https://github.com/jasim/EasyAccounts

There is also The Oasis mirrors which have a large cache of Clipper code: https://harbour.github.io/the-oasis/docs/

This is a history of dBase, not FoxPro.

Wayne Ratliff, in the late 70s, built a revolutionary piece of tech: a high-level memory-managed language that regular people could use (from early 80s!) to build database-backed user interfaces. That was dBase.

It is the greatest NoCode tool of all times.

The best release of dBase was dBase III Plus. Everything that came after was a trash-fire. dBase was interpreted - you needed the source .PRG to run it. So a couple of folks formed Nantucket and built Clipper Summer 87. It was primarily marketed as a compiler for dBase. But later versions of Clipper became their own language, and remains my most favorite programming language.

In parallel, there was FoxBase, originally a cheaper and then faster version of dBase, which was then turned to FoxPro with its separate command window and output window (thanks to a port to the original Mac GUI which necessitated it). Excellent product, extremely wide adoption for building business applications until FoxPro 2.6 for DOS.

For a detailed history of FoxPro, read FoxTales by Kerry Nietz. Anyone who's used dBase/Clipper/FoxPro would find it deeply enjoyable!

As a relative newcomer to Rust, I'm curious to hear about those early mistakes

This is diffused cultural knowledge, but most of the ideas in React can be understood as: view = render(state). It re-renders everything all the time. But practical considerations force some optimizations. Everything else in React follows from those optimizations.

For example, if you destroy and re-create DOM all the time, then it loses critical information like user's cursor position and text selections. It is also slow to read and write to the DOM. Thus the need for an intermediate data structure, the virtual DOM.

React re-renders the virtual DOM every time the state changes. And it then diffs the previous and current ones against each other and does just the minimal number of DOM mutations to sync it up. To speed this up a bit, array elements are denoted with "key" so (I assume) there is a way to see if an element has been added or deleted.

But re-rendering the virtual DOM all the time can also be costly in terms of performance. Thus the next set of optimizations: React.memo+immutable data, and so on..

lha, arj, pak, rar, pkzip. these were magic.

The "How" was stripped by HN from the title. Edited and fixed it.

The C source for Emacs buffer: https://github.com/emacs-mirror/emacs/blob/master/src/buffer...

Is there a tool that does what Karthik's software does, but with SGML?

There have never been dinosaurs in my town. We've always maintained a big board in both local and regional languages that said "DINOSAURS KEEP OUT".

The rule, for a YAML-based no-code tool, would be:

"Any sufficiently complicated descriptive-declarative programming language contains an ad hoc, informally-specified, bug-ridden, slow implementation of a Turing-complete programming language".

In Concepts, Techniques, and Models of Computer Programming, Roy and Haridi define descriptive-declarative programming as:

"The declarative 'program' just defines a data structure. This language can only define records! For example, defining graphical user interfaces. Other examples are a formatting language like HTML (Hypertext Markup Language), which gives the structure of a document without telling how to do the formatting, or an information exchange language like XML (Extensible Markup Language), which is used to exchange information in an open format that is easily readable by all.

The descriptive level is too weak to write general programs. So why is it interesting? Because it consists of data structures that are easy to calculate with. HTML and XML documents, and declarative user interfaces can all be created and transformed easily by a program."

Jason Gregory's Game Engine Programming is the book for anyone looking to build transferable knowledge about computing while somehow being around games.

Of course making a game and a game engine are two different ballgames, but what a book!

A game engine deals with managing a large, complex, intertwined domain. It requires parallel and concurrent programming, graphics and the 2d and 3d math to go with it, GPU programming, animation, audio, timing, memory management, profiling and on and on.

I used to use entr extensively for Sketch plugin development (the vector editing tool by Bohemian Coding). However the app used to crash randomly and I felt my plugin was causing it. I spent an inordinate amount of time trying to debug it, replacing libraries, changing code and so on. Thankfully I noticed at some point that the app was behaving well for long durations of time when I started it without entr. I got rid of it from my toolchain and things have been well ever since.

I still don't know the root cause, but now I know one more place to look for heisenbugs.

Kudos to the name! The meaning ("ente" = "mine" in Malayalam) meshes deeply with what the service is, and it is short and easy for everyone to pronounce.

Sorry, I had tried changing it immediately after posting the link, but HN allows only changing the title.

I could not find clear references with an initial search. Can you expand a bit more about this approach? Thanks.

> Finally, functional languages tend to fight against large, mutually-linked, mutable data structures, yet the layout engine of a browser is all about that.

Is the DOM (and LayoutObject et al.) truly a case where imperative object-oriented programming shines? In pure FP operations like insertion, bidirectional traversal, and moving objects between parents can be cumbersome because there is no implicit identity for the objects.

Curious whether this is true, or is there a way to implement a DOM-like API with mostly immutable values?

I once worked for a German company (remotely) who made it clear that working beyond 6pm wouldn't lead to much progress, and my lead consistently logged out at just the time. So I had to follow his example and couldn't potter around after. I still love the team for that. But we consistently did a solid day's worth of work everyday and there wasn't much juice left to continue after.

Blink and you'll miss it !!

Oh the nostalgia. Linkers were exotic at the time. Before I discovered Blinker, I got to use Exospace that was shipped with Clipper 5.3. A lot of old goodies are still availabe at the The Oasis mirror at https://harbour.github.io/the-oasis/ftpgenrl.htm

I haven't done compiler work, but your note makes sense.

However I've been writing a fair amount of ReScript (OCaml but in JavaScript: The Good Parts) for UI work, and we never use catch-all in pattern matching.

It is an all-or-nothing proposition: you want to have complete certainty all the time that the compiler will catch all possible cases when the type is modified.

Without that certainty, discriminated unions are simply a lot of work for nothing in return.

This can lead to verbose code, but sometimes it is solved by generic handlers.

    let onControlFlow = (stmt, cb) => {
      switch (stmt) {
       | If(body)
       | While(body) => cb(body)
       | Module(_)
       | Let(_)
       | Statement(_) => ()
      }
    }

This is an unrealistic contortion of your example, but in user interfaces there are often cases where there is some sort of grouping within an ADT, and thus we can apply the same function to the tagged data common to it.

Quick shoutout to xHarbour and Harbour - the open-source, commercially-supported versions of Clipper. https://github.com/harbour/core

The projects are still going strong and many years ago I had ported a huge Clipper project into Harbour and had it working well across a 20 node network with both Clipper and Harbour binaries working simultaneously on the same database.

These days every time I make another web application I wish for the simplicity of xBase. But there is some core truth about application development hidden there that is lost to me now.

correction: dBase IV came out before FoxPro. From the book:

"By the beginning of summer ‘89, FoxPro was turning into an impressive product. As an outgrowth of the new language added to emulate dBase IV, and our new window-based interface, many items present in earlier Fox products were substantially transformed."

Kerry continues:

"By the beginning of summer ‘89, FoxPro was turning into an impressive product. As an outgrowth of the new language added to emulate dBase IV, and our new window-based interface, many items present in earlier Fox products were substantially transformed.

One of these was our text editor. Two commands in the language would present this to a user, MODIFY FILE and MODIFY COMMAND. In FoxBASE+, the editor was simplistic. It just filled the screen with whatever file was being edited. Only one file could be edited at a time, and there was a rigid limit to how big that file could be. It was functional for developing dBase programs, but most hardcore users would buy an additional editing program to do real text editing work.

As coded by Eric, though, the new FoxPro editor was an animal of a different color (no pun intended). It resided in a window and users could have as many text files open concurrently as they liked. They could easily copy and paste text between different files. There was no limit to the size of the file. (No attainable limit, anyway; the actual limit for a text file was larger than most modern disk drives.) It was also blindingly fast. It could open hundreds of files in seconds and scroll text faster than it could be read."

One of the original Fox developers wrote a great behind-the-scenes book about the software and the company culture, uptil their acquisition by Microsoft.

It is one of the more niche, under-appreciated technology books out there: "FoxTales: Behind the Scenes at Fox Software" by Kerry Nietz

FoxPro was originally FoxBase, a clone of dBase III, and in some respects better than dBase - IIRC, it could handle larger files, and worked better on a Novell Netware. FoxBase was however a console application - no windowing and no mouse.

Then in the beginning of 1989, they started working on "FireFox" - that's where the classic FoxPro GUI came to life. It was a big departure from dBase, and the name went thru multiple iterations before it became FoxPro. It was a runaway success. dBase never caught up - dBase IV tried catching up with FoxPro's GUI, but it was buggy, slow, and its lunch was being eaten by Nantucket's Clipper compiler.

It was fun times, but sadly the xBase dialect wars were superseded by the rise of Windows, and by the time people retooled into Delphi and Visual Basic, that went away and the web became the dominant application platform.