Windows 95, 98, 2000, XP and 7 are generally regarded as having great UIs.

Of course, we know what happened later:

https://mastodon.social/@danluu/111802159638869338

You mean a whole different window at the OS level?

Yes, that way I could switch between windows in a single shortcut, or even place them side by side so I can see both at the same time with other shortcuts.

That’s just a way inferior hack to the way vim does it by default.

Can you explain this more?

Why wouldn’t you want window management to be managed by the window manager?

Have you considered the Required<T> generic?

https://www.typescriptlang.org/docs/handbook/utility-types.html#requiredtype

I’m assuming for your example that only one tab is shown at a time?

In that case, you can do that in vscode, the only difference is the semantics of what is considered a “window”, and what is considered a “tab”.

To do this in vscode:

Have one window with four panes, and another window with three panes:

                         
        Window 1         
 ┌──────────┬──────────┐ 
 │          │          │ 
 │  Pane 1  │  Pane 2  │ 
 │          │          │ 
 ├──────────┼──────────┤ 
 │          │          │ 
 │  Pane 3  │  Pane 4  │ 
 │          │          │ 
 └──────────┴──────────┘ 
                         
        Window 2         
 ┌──────────┬──────────┐ 
 │          │          │ 
 │  Pane 1  │  Pane 2  │ 
 │          │          │ 
 ├──────────┴──────────┤ 
 │                     │ 
 │       Pane 3        │ 
 │                     │ 
 └─────────────────────┘ 
                         

You can then switch between your windows (or “tabs” in your example) by keyboard shortcut.

In vscode, you can make the Panes different files, or even different views of the same file.

What do you mean by:

There is no way to split a tab into windows in VSCode.

Do you mean, drag a tab out of a window to create a new window? Because if so, you can do that in vscode.

How would they know a release date if they haven’t finished making it yet?

I like to say:

We have a half finished skyscraper, and you’re asking me to Just add a new basement between the second and third floor. Do you see how that might be difficult? If we want to do it, we have to tear down the entire building floor by floor, then build up again from the second floor. Are you prepared to spend the money and push back the release date for that new feature?

Dude, I would just 2d print the png they sent and give them the piece of paper.

If they complained, I would say: “I literally printed the thing you told me to print.”

You can take the contents of a C file, put it into a C++ file and there’s an 80% chance it will work without modification, and 15% of the incompatibility will be just sticking a type on your pointer instead of using void pointers (untyped pointers), or in newer code switching the restrict keyword for one of C++'s newer pointers.

You can’t do that between JS and Java.

Space-f lets you open a file in the current workspace, and :open /path always let’s you open any file on the computer

Is this a file tree, or just a fuzzy finder?

Fuzzy finders aren’t a substitute for a file tree picker. They’re only great, until you don’t know the name of a file, or until you need to know of a file’s existence in the first place.

I remember being really interested in Helix when it came out, but it didn’t have a built-in file picker.

Is this still an issue for users? Is there a built-in solution, or a usermade solution to this?

Also, is there plugin support?

I can’t use an editor without rainbow indent/brackets, without them code just takes too long to read that it becomes frustrating.

1 hour of planning can save 10 hours of work.

1 hour of research can save 10 hours of planning.

Some small nits to fix:

1. C has it’s own undefined behavior.

2. JS has confusing behavior, not undefined behavior. Its specs are well defined and backwards compatible to a fault, making some things unintuitive and harder to learn if you don’t learn the history of the language.

3. Problems with both should be avoided by learning and using standard practices. (Don’t pretend C is object oriented, always use === instead of == in js, etc…)

In complete agreement:

1. Result types are awesome, all future languages should be designed around them.

you have to fix the indentation because if not then the document won’t work or mean something completely different

Whitespace has no meaning in json. You can indent however you want, or not at all.

I’m assuming you’re running into issues because you’re writing json in a yaml file which does care about indentation, and you’re only writing json in yaml to get access to comments.

In which case it circles back around to: why not use toml? Whitespace formatting doesn’t corrupt the file, and it has built in comments.

If you read the - as “dash”:

docker compose up
docker system prune -a
docker compose up

Cut and paste problem?

If you’re reaching for yaml, why not use toml?

How would you mark a flag in your json settings file as deprecated?

That doesn’t really work when you need two comments at the same level, since they’d both have the same key

Where do you put your comments in JSON files?

I think you’re forgetting about the Animation API.

Example: making something flash once to get a user’s attention

element.animate( {opacity: [1, 0, 1]}, { duration: 500 } );

Use CSS animations everywhere you can, but if you need to be able to hook into an animation (to dynamically change the speed, cancel something, sync animations together, etc…) you should be using the Animation API.

There’s never a need for jQuery.

What do you still need babel for?

The only features that come to mind for anyone who needs to reach out to babel today would be those working on the tc39 proposals themselves.

What do you mean about animations?

Every use-case I can think about is already well supported by vanilla css/js without libraries or frameworks. (not including really out-there use-cases like game engines or image editors)

Can you give an example?

DOM attributes are built for browsers and frameworks to take advantage of.

The style of some of those frameworks to stick symbols in there is downright weird. But that only goes against those particular frameworks. It doesn’t impact how good DOM attributes actually are.

Svelte uses labels, so Svelte itself is weird compared to everything. Except in a way to assembly and 50s goto-control-flow styled code.

But why bother with creating a new language

I can just do items.map(item => 〈Item key={item.id} item={item} /〉)

I don’t think this is a very good example. You’ve just said not to use a new language, then used JSX, a new language.

I have yet to be given an example of something a “general” intelligence would be able to do that an LLM can’t do.

Presenting…

Something a general intelligence can do that an LLM can’t do:

Play chess: https://www.youtube.com/watch?v=kvTs_nbc8Eg

Why can’t it play it? Because LLM’s don’t have memory, so they can’t work with logic. They are the same as the little “next word predictor” in your phone’s keyboard. It just says what it thinks is the most probable next word based on previous words, it’s not actually thinking or understanding anything. So instead, we get moves that don’t make sense or are completely invalid.

Did you purge and update your filters?

Note: I’m not talking about turning filters off then back on, I’m talking about updating the version of each filter itself.

it looks like JS/TS with arrow functions.

JS/TS already has arrow functions.

That’s not pro, that’s just reckless gambling.

It sounds like to me that you’ve taken your knowledge of your commonly used languages for granted, and assumed a new language would be just as easy. But if you watch a developer who is dipping their toe into that ecosystem for the first time you’ll find them making mistakes and running into footguns you didn’t know were possible.

Regardless of the language, not having a proper guide leaves devs susceptible to the incorrect blogospam that’s out there, where engagement is rewarded over correctness.

Ignore all of the blogospam.

The two things you need to know:

1. C/C++/Java/Go/Python have all gone through changes, growth and churn just like JS.
2. Knowing the history of the ecosystem will go a long way towards helping you. If you understand why things have changed, then you’ll know how to ignore the bad advice out there.

Here’s my shortened version of number 2.

The beginning:

• JS starts as a scripting language embedded into a browser
• Different browsers try to copy each other but put in their own “features” pulling the language in different directions.
• The amorphous blob that is JS starts to congeal and language standards are solidified. This standard is known as ECMAScript (named for legal reasons). ES1 is the first version, followed by ES2 and ES3, each adding useful features.
• ES3 (released in 1999):
  • This is what you could consider the first long term stable baseline widely supported version of the language, where you can make anything you want.
  • Almost everything you can make in future versions of the language can be backported to ES3.
  • If you want to go by analogy, you can think of ES3 as javascript’s C99.

The false start:

• Work starts on ES4 with a massive feature list (including static typing, classes, modules, algebraic data types, generators, embedded xml/xhtml known as JSX/TSX today, etc…). It fails due to political infighting, and for basically being too ambitious in a single version.
  • This sucks up years of progress between released versions.
  • This version is commonly seen as being poisoned by 90’s/00’s Micro$oft and the dark ages of Internet Explorer
  • But the spirit of ES4 was released spread out over future versions anyway.

The resumption:

• The v8 JS engine is released, making JS really fast and worth programming in. This is used in Chrome and Node.
• ES5 (released in 2009):
  • Adds native json support, reflection, and a strict mode to avoid some footguns with ES3
  • Think of this as C11
  • Some developers being experimenting with a more consise syntax in CoffeeScript that compiles down to ES5.
• 2012: Typescript is released adding an optional and gradual typing system to JS (inspired by C# and ES4) designed for both Humans and Computers.
  • In effect, this brings IDE-style support for JS
• ES6 (released in 2015):
  • With the lessons learned from CoffeeScript, a whole bunch of syntactical sugar is added to make the language more pleasant to write in.
  • With the lessons learned from community made modules, an official module spec is released and added to the language.
    • Known as ESM (EcmaScript Modules)
    • The community starts moving away from unofficial modules (CJS, AMD, UMD)
  • Babel is created to allow any developer to create and share their their own language extensions.
    • The faster feedback cycle from Babel allows for smaller and more frequent language updates.
    • Javascript moves to a yearly release cycle and ES6 is renamed ES2015
• ES2016
  • Adds block scoping as an alternative to hoisting
• ES2017
  • Adds async/await/Promise() syntax sugaring, to make asynchronous programming easier
• ES2018
  • Adds ... (rest/spread operator) syntax sugaring, to make destructuring and variadic functions easier
  • Ryan Dhal (creator of Node) releases his famous 10 Things I Regret About Node.js talk. Announces his intention to create a “modern reset” of Node known as Deno.
• ES2019
  • Minor changes
  • Deno is released
• ES2020
  • Adds ?? Nullish coalescing operator syntax sugaring
• ES2021
  • Adds ??=/&&=/||= Logical assignment syntax sugaring
• ES2022
  • Adds top level await, making asynchronous programming easier
  • Adds private field syntax sugaring
• ES2023
  • Minor changes

The current state of things

• Language-wise

  • Javascript has added a whole bunch of syntactical sugar since 2009 making it really pleasant to code in.
  • Typescript adds some really nice IDE support to Javascript and the vast majority of all libraries and frameworks are written in it giving that IDE support to Javascript developers.
  • Babel allows developers to create their own language extensions, which are frequently put forwards at for other developers to give feedback on. Useful proposals are added to the language on a yearly basis.

• Runtime-wise

  • Node is considered the older slow-moving most-stable release of running JS outside of the browser
    • Think Debian
  • Deno is considered the friendly Node, coming with all the tools a developer needs (linter, bundler, tester, ts support, etc…). In the last 5 years it has reached almost complete feature parity and compatibility with Node.
    • Think Ubuntu
  • Bun is a brand new kid on the block prioritising speed over compatibility.
    • Think nightly linux

• Standard workflow

  • Write in typescript
  • Let your editor check your typescript while you’re typing live so you don’t need to go through a compile cycle
  • Let your project’s stack compile your typescript for you.
    • If you’re writing a new project from scratch, Deno will run typescript for you.
    • If you want to build a new stack from scratch with no assistance, use the typescript project itself to check and compile your code into js, or use esbuild to strip out the typescript types to turn your typescript into js. (most developers elect to strip types since your editor/ide should be live checking your typescript anyway allowing you to skip a redundant compile check cycle)
    • If you’re using an existing stack, your build tools will compile/strip-out typescript for you.

• Tooling wise

  • Most projects use Vite / rollup / and other “zero-config” tools to build and bundle their applications. Some older projects still use Webpack (which does the same thing, but with a more complicated config file).
  • Everyone uses ESM modules now, almost no one uses the older modules.

For your simple fibonacci example:

1. Create your fibonacci module that exports your fibonacci function
2. Import module
3. Call function in module
4. Pick your endpoint:

• Browser endpoint: Output result in console.log() and see result in browser’s console.
• Server-side endpoint: Output result in Deno.serve() and see result in network requests/responses
• CLI endpoint: Output result in console.log() and see result in terminal

This comment just seems weird no matter which angle I try to approach it from.

immature tooling ecosystem

It’s over a decade old now. I wouldn’t call that immature.

Looking at your linked comment…

following a basic tutorial somehow ended up spending multiple seconds just to transpile and run “Hello, World!”.

1. Install deno
2. Create hello.ts containing: console.log("hello world");
3. deno run hello.ts (time taken to run command: 0.037s)

[…] 3 different ways of specifying the files and settings you want to use […] 3 incompatible ways to define and use a “module”

Yes, that tends to happen as ecosystems evolve over time. Typescript allows developers to use modern standards-compliant modules, while maintaining backwards compatibility for older code.

embracing duck typing means […]

One of typescript’s strengths is that its type system isn’t all or nothing. Typescript will support duck typers, but it isn’t forced or limited to that. You can add as much or as little typing as you want. In theory, this means that the language supports simple beginners up to experts creating turing-complete theorem solvers at compile time. In practice, this means a much smoother onboarding and porting experience.

Have a “generalized fibonacci” module taking 3 inputs […]

I’m not sure if this is the basic problem challenge or the hello world example was. It seems a bit ambiguous as to what you really want, but it’s easy to create a module that takes inputs and produces outputs while running on backend servers, in browsers, and in CLIs.

I thought I loved ts-node, since it’s a good patch over some annoying issues in node.

But I retried deno a few months ago (after having first tried it when it first came out) and I realised that I only ever liked ts-node, and that I actually loved deno.

Deno just ran ts as if it was ts-node without needing a dependency, or startup time, or any prior setup, and it did it so fast I thought something was wrong. It was great.

I absolutely understand OOP, its explosion took over everything that took a long time to recover from.

The problem with OOP is that it’s pushed as a cure-all both by teachers who do not the problems it solves and also do not understand its own limitations.

In almost every situation where OOP makes sense, something else makes more sense to use.

Interesting…

Every IDE and editor (gui and tui) I’ve used has always come preconfigured with a tab-size of 4.

The only thing I’ve ever experienced having a tab-size of 8 was github, and I thought that was just a problem with a setting from github’s size that I quickly set back to 4.

It seems that tui editors come with tab-sizes of 8 only when a config isn’t provided, and every environment I’ve used where I’ve used a tui editor has always come with sensible configs (for things like config location, language recognition for syntax highlighting, etc…) including a tab-size of 4.

The horizontal tabulation character moves the cursor to the next column which is a multiple of the tabulation length. See the examples here: https://en.m.wikipedia.org/wiki/Tab_key

Yes

Clearly the whitespace produced by each tab character has a different length.

No, each tab has the same size, the text rendered over the top of the tabs are not the same size.

Always remember the golden rule: Tabs for indentation, spaces for alignment.

NO

It’s intuitive until you realise that not everything fits in a single inheritance hierarchy.

This gives a good example: https://www.youtube.com/watch?v=wfMtDGfHWpA

a tab’s length changes based on its position in a line

What does this even mean? A tab is a tab.

Tab’s don’t have multiple lengths inside a file, they all have the same length.

That’s the point of tabs.

most environments

What environment are you using that have tabs set to 8?