Poefke

AI changes the rules of software development. This article is how I am adapting my work now.

There will be no red-eyed metal skeletons marching over a field of human skulls. No machine intelligence will announce that it has become self-aware and decided to remove us from the equation.

The system most likely to take control of your life will not threaten you.

It will offer to help.

Most software is not good, using these rules. And that is written by human developers. The problem is that most software developers have less than 5 years experience. The community doubles every 5 years. Experience is scarce. So AI, learning from all the stuff online, does not learn great code, it learns from available code. You can make it produce better code, if you do the hard work of defining better in terms the AI understands. I've been trying to find a way forward with AI generated code, using my own definition of 'good architecture', and results with chatgpt 6 are promising. Not perfect, but good enough. I used a book I was writing as input, you can read an unfinished version of it here: https://programming-for-wizards.dev.muze.nl/ (Still working out the kinks of the underlying software) The other approach is to explicitly keep the whole decision tree as a causal chain in a repository: https://github.com/muze-labs/spiral-developer Still testing that one out.

LINQ is much more sophisticated, translating as much of the query as possible to the target (server) language, like SQL. JAQT is not doing that. lodash, underscore, and others, had a great impact on javascript by introducing lots of functional paradigms. Most of that is now part of javascript itself. JAQT's main purpose is to allow you to filter arrays of objects and create custom objects, just like GraphQL. And be a bit easier to learn than Array.map/reduce/filter.

Author here, if you are comfortable with filter/map/reduce, than JAQT doesn't provide much benefits, I agree. My target audience is developers who aren't that used to that. I've had much more success with junior developers using JAQT, then trying to get them to use map/reduce.

The target audience for unit tests is not the client, it is the developer. Unit tests allow you to change code with more confidence. 100% code coverage is not a useful aim, you should aim for 100% confidence in your code. Unit tests can also function as example code, that can't get out of date, since then the tests will fail.

Testing for quality assurance is a different thing, usually called acceptance testing and sometimes including regression testing. One easy way to make clients angry is by re-introducing bugs that were fixed in earlier releases.

Yup, it was an experiment. There is a follow up, called cobalt: https://github.com/poef/cobalt/

But its not meant as production ready code, instead I'm exploring the concept and what it means for editing, rendering, etc.

Hi, original author here, I just found out my old project featured here and love the thoughtful responses. If you are interested, I've been working on a new version of and on, called cobalt (https://github.com/poef/cobalt/). Hope was the proof of concept, cobalt is a more rigorous implementation. Specifically the range algebra is complete there.

It's still a hobby research project. There's a lot I've learned building and using it, about the things that HTML is good at, and what it isn't good at.

What I'm trying these days is to see if I can get a WYSIWYG editor with a user experience that comes close to the user experience of writing markdown. This isn't easy and its interesting to explore what makes that so.

The only reason I used a text format is because I wanted to keep the code as simple as possible. Only introducing extra complexity when I hit a wall somewhere. I don't know if the current format will scale to more complex use cases, but I really like the fact that you can read HTML and reason about it, so I kept to that in Hope as well.

As for the text part, that is simple. I like to be able to manipulate text as text. There are many many tools to work with plain text. I can use regular expressions to search through text, get ranges of the result and apply an annotation to those ranges. You lose a lot of that in any other format.

Agreed, you cannot edit one part without the other. But there are many situations where this is not a drawback. Nobody is writing Word documents in a text editor for example.

But I'm looking at a way in which you may be able to add annotations to a document that isn't under your control. If the document is either guaranteed not to change, you won't have a problem. Documents hosted on IPFS or a versioned URL to a Hyper document fit this bill.

If you want annotations to automatically change when a remote document changes, you need to be able to 'follow' the changes. Between when you originally 'linked' to the document and now, what has changed in the document. Which parts are deleted, which parts are added. If you know that, you can update the offsets in your annotations. So I'm looking into making a versioned document format to allow just that.

Hi, original author here. When I started out I wasn't trying to solve a problem. I was exploring a concept I was curious about. But in the end, we (me and a colleague) ended up building it into our WYSIWYG HTML editor as an alternative to the browsers execCommand editing API. When editing rich text, an API that is build around ranges for everything is a perfect fit.

The editor (https://simplyedit.io/) converts a contenteditable area's content to hope, we apply some markup (annotations) and convert the result back to HTML. I wrote the Hope-HTML conversion routine once, and all the range based manipulations are now one-liners instead of treewalking horror shows.

Original author here, hope is an old experiment and I hadn't updated it to avoid mixed http/https content. This solved now in the online demo.

Original author here, this is exactly right. Hierarchy and contentless annotations don't mix well. This is the main disadvantage when compared to xml/html and the like. On the other hand, using annotations with offset pointers to the main text make things like overlapping annotations and multiple sets of annotations possible, which are difficult to pull of in xml/html.

Patterns of Software: Tales from the Software Community, by Richard Gabriel

I like where this is going, I have been thinking about similar problems lately and, inspired by a talk from Alan Kay, started writing down a research direction for a solution. I'm looking for feedback and other people interested in this. You can read the whole thing here: https://hackmd.io/kafpxBeqQua_rcrncP14tQ?view

TLDR: I'm thinking of building on top of the browser a universal document standard, which allows for interactive documents that contain the application you need to render it, but also to get data from it and link it to other documents. I'm thinking of using IPFS as a storage mechanism to get stable links. Iframes to securely compose documents, using a bootstrap javascript line as the only requirement for any document format. A message bus system, using iframe postMessage api, to connect all documents.

I'm in the pre-design phase, there is no code, just thoughts.

If you resize the image in steps, with each resize at least 50% of the previous step, you can do a pretty decent approximation of cubic resize using the canvas. Doing this for a year now, we've gotten no complaints and we have designers as clients :)