Yes Bolt is the name of the company. Hypertext app with radial menus... Maybe something that Don Hopkins made? https://medium.com/@donhopkins/designing-to-facilitate-browsing-a-look-back-at-the-hyperties-workstation-browser-535eab3a3b3c

hyperties—you nailed it

autodesk also does this in some of their cad tools, although i neve really got used to that

No worries. Lets wait for October.

Leif Andersen sent me a pre-print. I like the approach of the paper, which is to expand Racket's macro system to include define-interactive-syntax that operates at edit time. (In addition to the compile time and run time execution stages.)

Sure, I have customers to assist, servers to manage (not that they need much management), and business accounting to do; but professors equally have classes to teach, students to supervise, and committees to attendIf you’re going to equate teaching / supervising students with business accounting, then it’s probably safe to say academia is the wrong field to enter.

Might vary by field or, more likely, institution but for some students are absolutely viewed as a tax.

unfortunately true 😞

yoshiki it's a wiki! you can edit it 🙂

another ‘data source’: https://www.google.com/search?q=site%3Aworrydream.com+alan+kay&oq=site%3Aworrydream.com+alan+kay&aqs=chrome..69i57j69i58.3559j0j1&sourceid=chrome&ie=UTF-8

yet another ‘data source’: https://www.quora.com/profile/Alan-Kay-11

Srini Kadamati feel free to add them to like the bottom of the Writings page or something

all my favorite features of this have to with freely defining and passing in stuff from the right pane for variables that aren’t defined yet. you get to save example arguments for your function calls! and use them to figure out states later on in your program!

I forgot to mention that I also really enjoyed the description of the FlowSheets project here. I plan to learn more about it.

https://youtube.com/watch?v=y1Ca5czOY7Q

This is really cool, thanks for sharing. Trying to figure out if I would use it to teach (given that this was one of the motivations for the work) vs. just using the console + debugger… and I’m not sure. Maybe for students who already had some programming experience? Seems like a lot of the features require some knowledge, although the UI that enables clicking around and editing values / typing in simple expressions would be relatively easy for beginners to use and is really nice… much more immediate than the debugger.

reading now but ctrl f for “until most poll”— i think should read “until its most recent poll”

I saw this https://news.ycombinator.com/item?id=24558788 on HN. Congrats!

Garth Goldwater Thanks and fixed! (And in case anyone else sees any typos I really appreciate when people point them out)

Holy crap, I had no idea it had gotten so popular.

Typo in footnote 3: "survery". :)

Thanks, fixed!

FoC-relevant question the HN thread doesn't seem to have directly addressed: how are you confident that VSCode has reached the optimal extension API? Without necessarily doing a deep dive in their docs, could you talk about what makes its API good?

I actually don't think the API matters, just which language it's written in. E.g., what's "right" about VS Code is simply that extensions are written in HTML, CSS, and JavaScript, the "proof" of that is simply all the extensions that have been written for it, especially relative to previous approaches. (And the point is doubly illustrated by Atom's initial explosion of extensions, with a completely different API.)

I'd be happy to hear some evidence that the design of the API itself is important. I can think of examples that illustrate it's not important (VimScript as an example of successful poorly designed API, NeXTSTEP/AppKit as a well-designed API not being as successful as it should have been) but I can't think of any that illustrate that it is important. Generally my opinion is that what matters is platform momentum, and developers will support the platform regardless of the design of the API, as long as it can do what they need it to. (There's a bit of a contradiction here, in that the language choice could be considered part of the API, I have to think more about that, but I think the answer has something to do with the "special" nature of HTML/CSS/JS as the browser languages.)

One random side note: I do actually think VS Code has a weakness right now, and that's that it can't run in integrated browser. Historically that's been a tough feature to capitalize on though.

One thing to clarify is that I think frameworks need a good API, e.g., Ruby on Rails needs a nice developer experiment, but platforms don’t, like Twitter doesn’t need a great API, or Windows, developers come to it for other reasons.

Come to think of it, I actually think VS Code is more evidence API doesn't matter. I honestly couldn't even say whether VS Code's API is well designed because I don't even know what it's design is. Atom has a beautiful API, communicated effectively through documentation (I appreciated their design and philosophy around lazy loading for example). I've now spent more time with VS Code than I ever had with Atom, but since documentation doesn't really communicate it, I don't feel like I even understand what philosophy or organizational principles of their extension system are. If I were to characterize VS Code's design approach it would be: Scale solves all problems (a play on "given enough eyeballs, all bugs are shallow"). E.g., just ship something and let people bicker it out in GitHub issues and eventually we'll arrive at a working design. And so far there been right! And I actually think the approach is brilliant, because it's future proof. Bad decisions now, get corrected over time, because correcting bad decisions literally is their process.

your article doesn't seem to address https://microsoft.github.io/language-server-protocol/ or https://microsoft.github.io/debug-adapter-protocol/ I suspect part of the reason the popularity of VS Code exploded is because both projects allow providing excellent IDE support at relatively low cost to language authors (at least when compared to the cost of creating a custom IDE or writing plugins for say, idea or visual studio)

Ah, I think I misinterpreted the "There just isn't anywhere else to go" paragraph as being about the API design. What exactly did you mean by that?

@Andrew F Regarding "There just isn't anywhere else to go":

Installing extensions went from manual (TextMate/Emacs/Vim) -> to third-party, centralized, but CLI style UI (Sublime Text's Package Control) -> to integrated "App Store"-style extension installing experiences (Atom/VS Code)

Extension capabilities went from almost no ways to customize UI (TextMate, and VIM/Emacs for anything non-textual) to customizing the UI through a custom API (Sublime Text) to customizing the UI in a standardized way with HTML/CSS/JS (Atom/VS Code).

Those are the progressions I don't see anywhere else they can go, i.e., installing extensions can't get any easier, and customizing UI can't get any easier.

I think you're primarily asking about other parts of the API? But I'm not sure these APIs have had major limitations in other ways besides in customizing UI and installing extensions. The most notable example I can think of is async process management being added to Vim/NeoVim. For the most part there just aren't other limitations, unless I'm missing them?

Emmanuel Oga Debugging and LSP are tough to address... to answer I think I have to zoom out. The way I wrote the piece was to draw on my observations watching conversations around people switching from TextMate to Sublime Text to Atom to VS Code, and reading people describing in their own words why they switching. And the overwhelming answer for Atom to VS Code isn't LSP or debugging, but it's because Atom was slow. (Note I'm leaving out the role extensions here because Atom and VS Code both have first-class extension support, whereas LSP is definitely a VS Code vs. Atom distinction.)

This isn't to say a lot of people don't also list debugging and LSP, but it was (and still is) dwarfed by performance discussions, and my goal was to have the article based as much as possible on what people are saying, not what I personally think is important.

Another point about LSP: Oddly enough, I think LSP benefits everyone except the incumbent more, because the incumbent can just get great support for these features through sheer inertia, whereas more resource-strapped outfits benefit more from the standardization by being able to work more efficiently.

And a quick bit on debugging: Personally the debugging integration is my all-time favorite feature of VS Code. But I can't imagine very many people are using it, outside of experts. As far as I can tell, you have to make an launch.json file just to debug a default Node app? That's madness.

That's a great example of an early-stage VS Code feature, where a completely nutty implementation is just dropped on users. But over time I'm sure setting up debugging will be amazing, because of the pace of development. That's the VS Code way.

(As a side note I had a section that got cut that had more personal opinions on VS Code's features, especially LSP/Debugging. But I decided to cut it and make it into a separate post because it was more based on what I personally think is important rather than what my pulse on the community at large thinks is important.)

I do actually think VS Code has a weakness right now, and that's that it can't run in integrated browser

what does this mean?

That you can’t run a browser inside VS Code. It’s always struck me as strange that web developers use consumer bowser that are sandboxed from the file system to test a program that’s of course made up of files on that file system.

You can see the impacts of this model in action by looking at the hacky live browser plugin for VS Code that spins up a server just to get automatic refreshing for HTML files. But the bigger impact is the sophisticated dev tools bundled into browsers. It would make so much more sense for those tools to be bundle with the actual source files, so there’s more seamless interaction between the two. For example jumping to editing the source HTML or CSS, or clicking in the IDE to add debugger breakpoints. There are some hacks to get around this, but they’re just that, hacks.

very odd considering that it’s based on electron

Yeah agreed

I'm not really following what you're suggesting. There are plenty of plugins for VS code that show a live webpage in one pane.

There are multiple reasons to use a simple webserver (which like 3 lines of code in node). If they used the files system then any 3rd party script loaded over the net would have access to their hard drive. Loading from the filesystem in a browser is just not something you should do. Further, many browser features are restricted to https only. And finally, often you want to run via some staging server because the simple case where everything can run from local files would be an exception for most actual usage.

As for bundling debugging tools into your own code, how does that have anything to do with VSC? If you want debugging tools compiled into your code you add them to your code no? For example if you want spector.js added to your code then you add it to your code. (yes, it's presented as an extension on that page but if you read the docs you can just as easily use it as a library in your code without having an extension)

There are plenty of plugins for VS code that show a live webpage in one pane.Not sure what you're talking about here? I'd love to see examples? I only know of one (https://marketplace.visualstudio.com/items?itemName=auchenberg.vscode-browser-preview), and it uses Chrome's video sharing API to stream PNG images and that's why it has the performance issues documented here (https://github.com/auchenberg/vscode-browser-preview/issues/21).

If they used the files system then any 3rd party script loaded over the net would have access to their hard drive. Loading from the filesystem in a browser is just not something you should do.This is a restriction that's there because consumers are mainly accessing arbitrary (and potentially dangerous) websites over the internet, whereas the integrated browser would mainly be used to access local web development projects, which have a different risk profile. (Plus I'm not saying that the websites you access should have access to the file system, I'm saying that the developer tools should.)

As for bundling debugging tools into your own code, how does that have anything to do with VSC?When I said bundled with the source code, what I meant was, right now the Chrome DevTools (https://developers.google.com/web/tools/chrome-devtools/) are in the browser, which doesn't have access to your source files. I'm saying these tools could be more useful if there were in the IDE instead.

(The easiest way to explain what I'm saying is that I think the browser developer tools should be an IDE feature, not a browser feature. The whole sandboxing question is a bit of red herring because integrated browsers are everywhere--just not in VS Code itself. The sandbox is only really relevant because since today the DevTools are a browser feature, the DevTools are subject to the browser's sandbox. Theoretically you could just not sandbox the dev tools, but that doesn't give enough value to be worth it alone.)

(I tend to talk about the browser sandbox because I think applying the risk profile of a consumer browser, used to browser arbitrary websites online, to a developer browser used to browse primarily local development projects is silly. But, strictly speaking, almost all of the most important browser developer tool features I'd like to see could be done without any sandbox changes, not even to the dev tools themselves.)

Finally, just to keep the conversation on track, there are a few points about loading local files and running dev servers that are confusing to me. Like this:

And finally, often you want to run via some staging server because the simple case where everything can run from local files would be an exception for most actual usage.I'm not sure what that's responding to, but I think the answer is source maps (https://developers.google.com/web/tools/chrome-devtools/javascript/source-maps) and Workspaces (https://developers.google.com/web/tools/chrome-devtools/workspaces). I.e., accessing local files and running a dev server are not mutually exclusive? Really I'm not talking about anything that doesn't already exist today, about half of what I want already exists, just with a atrocious UX because dev tools are essentially trying to stuff a second IDE into the browser.

Awww I miss working on Hest. Damn my responsibilities to my coworkers — don't they realize there are weird futures to be invented?

(I'm in the mode where I put Hest aside for a week to work on a small side-side project, and then that week turned into 2 months, and now I've got a backlog of other stuff to deal with before I can get back to Hest. It'll happen... but I've already lost so much of the mental context I had built up. There's no avoiding this being a decade-scale project, sigh.)

This visualization is super cool. Max Bittker is such a source of joy.

Great to see them putting an emphasis on trying to gracefully correct inevitable mistakes. Very practical and hype-free blog.

I'm interested in how much builtin knowledge they are going to go for ("...including pieces like here and now that are implicitly available from the beginning of the conversation..."). Natural language is absolutely laced with assumed knowledge. Will it be able to understand "my wife", "my sister", "my house" etc. What about the gradient of niche or local knowledge - "Boxing Day" etc?

The problem with starting down this road is it is essentially arbitrary where you stop, and the user won't know where that is.

I suppose it won't matter if the error correction is strong enough ("When you say "sister" do you mean mailto:Jane.Doe@outlook.com?")

Chris Knott What you're pointing to here is one of the fundamental problems of natural language understanding: to really understand language one must understand the world in which the speaker lives, including the agents who live there and their motivations.

One thing I find interesting about this paper in particular for FoC is that what they're doing in the personal assistant context could repurpose well to the narrower context of descriptive programming.

Back when I was an assistant for conversational agent research, it was disheartening: having a good natural langauge parser, but not much there there deciding what to conversationally. (This was well before the ML resurgence.)

I hope you'll write a review. 🙂

I’ve had Obsidian sitting on my computer but haven’t made content yet with it!

Obsedian sounds like I could use.. gonna try it out right now! Thanks😀

I'm also interested in anyone's experience with this or similar software. I am a long time "by hand notebook" person

personally I’ve prioritized a workflow / philosophy over a tool

I just use mostly use Mac notes, occasional Notion at work

Mac notes is so fast and easy, cross-plat syncing by default, etc. So its nice for “oh shit I’m in a meeting / need to take notes!” and I use it for my working memory as w ell

and then I maintain a weekly / daily todo list in there as well

4-5 Mac Notes are all I need, its light and simple

now, I’m starting “document” more so I’ll use Notion for that

but I wanna level up to smoething like Obsidian

I use Bear (https://bear.app) for this… but I’m switching to Linux soon and will lose it 😞 One of the few pieces of software I’ll genuinely miss from macOS.

It's surprisingly easy to manage a wiki just as a folder full of Markdown files in just about any scriptable text editor. The only commands you really need are:

1. Make a link: take the selected text, make a new file with that as a name, then replace the select text with the link. E.g., [selected text](selected-text.md).

2. A way to open the link, most text editors can do this out of the box.

I've been managing all my notes this way for years now and I love it. Having everything in git is great.

There is also https://www.zettlr.com/

Haven't tried it (and won't) but it's sitting in my bookmarks for a while.

We just talked a bit about clojure repls here https://futureofcoding.slack.com/archives/C5U3SEW6A/p1599496562080600

I independently had some related thoughts about REPLs. I'm using this opportunity to rant. Maybe this should go under that original thread on REPL's, or maybe it's own post, but I'll post it here to start. Apologies in advance 😛 .

For some context, I am not a "lisp person." That's not to say I dislike lisp. I greatly admire lisp....from afar. But, my career and personal interests always end up taking me in a different direction, but I digress...

My day job consists of optimized C++ and Python infrastructure used in the banking industry. It's very "traditional" in many ways. Recently, I "jury-rigged" a series of exploratory "REPL like" programs to test various subsystems. These "REPLs" can be infuriating to set up. No part of the environment is optimized for that kind of workflow.

But I have found that once set up, I was able to be enormously more productive and confident in my code. Compared to any lisp REPL, or even a python REPL, these programs are stone age primitive. Still, this made me want to explore expanding it to more parts of the system, but further I looked, the more difficult it is to setup. I have to make a cost/benefit trade-off against "getting real work done," and unfortunately, I often have to choose to stick with the status quo.

Before I shifted into lower level systems programming, I spent years doing to Javascript and PHP. I burned out on web programming, but this experience made me realize that one thing I miss is the exploratory coding and rapid feedback experience.

And that leads me to the crux of my lament. Why can't I have a systems level programming environment that allows for this kind of rapid feedback?

Obviously there are limits the closer you get to the hardware, but even then, Forth has been used in embedded for decades (with a REPL), and people have put a Python REPL on an ESP8266, so I know it's possible to go fairly far with this idea...

Again, I am not a lisp evangelical, In fact, I generally prefer static types and fine grained control over my memory management. I'm also not saying REPLs are a panacea. I'm a practical person. It's frustrating for me to see the potential for a particular tool, and yet, to be unable to use it. /rant

Seems to work great - reminds me of Light Table.