TFA describes two coding alternatives: abstract, high-level, easy-to-read code that we give to the compiler to optimize, or low-level, CPU-specific, manually optimized code. A Python library is mentioned as the archetype of the first kind.

> Windows Terminal [...] It's such a good terminal emulator

I find it horrible. Slow, colors are inconsistent, resizes are not always propagated to apps...

What terminal do you use on Linux that makes you miss WT?

1. I doubt anybody on HN has any interest in what your personal criteria are for reading blogs. Please, please, please let's stop polluting the comments with arguments about how a piece of software was made instead of about the thing itself.

2. I agree if you refer to TUIs that try to emulate/substitute complex GUIs, with sub-panes, dialogs, graphics, etc. I happen to love TUIs for simple text-only visualizations, though. They are usually quicker than GUIs and consistent among various OS, desktop...

> Please, please, please let's stop polluting the comments with arguments about how a piece of software was made instead of about the thing itself.

But it IS relevant how something was made! It tells us how much of the detail that's presented in code & blogpost is the authors intent, and how much of it is "filler". It tells us whether the author can answer detailed question as to why they chose a specific implementation, or novel technique, or not.

It tells us whether the author wants us to read every syllable, or whether readers are expected to let their own summarize the article for them instead (as would be the case here).

It's never worth it to spend more effort reading something than the author spent writing it. The important part is the human intent, not the filler surrounding it!

Your reasoning could be applied word by word to the latest novel by Stephen King. I may know that it has been written by an army of mercenary ghost writers and nonetheless enjoy it and warmly recommend it to all my friends. Judge a book by its content, not by its author. Do the same for software.

So you enjoyed a book written as a collaborative process between multiple human writers and somehow this is an argument to have less humans involved...?

I would rather frame it as an argument against credentialism.

I'm specifically referring to maintainers trying to get new protocols (like border draw calls) into emulators. As these TUI frameworks grow in popularity itincreases pressure on emulator maintainers to support their proposed spec. There's some TUIs I like myself but these generally respect and try to work around the limitations of the terminal. When emulators start shipping with boatloads of TUI-enabling functionality they stop being emulators and start being app frameworks (arguably hard to decide where to draw the line, and everyone will draw it somewhere differently. I draw it in its own cell)

For the record I do think ratatui enabled some really nice terminal apps. There's a use case for it. But yes I do think terminal emulators should move slowly. Definitely not at the speed of AI. Reasonable people can disagree.

Snark and a winky face emoticon really negate any insight you could have provided here. These types of comments are becoming too frequent here.

No one said don't do anything new. Multiple people said that a proposed new feature to a standard should have proved value, and that patching a standard and its related tools could be a sign the feature isn't as needed as you think.

That's useful feedback to audiences developing against, consuming, and even writing those standards.

> Snark and a winky face emoticon really negate any insight you could have provided here. These types of comments are becoming too frequent here.

I added the ;) after posting to indicate some amount of good humor. Feel free to read it how you like, but I'm not here to provide insight to someone that literally said they didn't read the post as their first ever comment on this site. Was this your alt?

> No one said don't do anything new.

No. It's literally the first line of the comment I replied to:

> I'm specifically referring to maintainers trying to get new protocols (like border draw calls) into emulators.

> Multiple people said that a proposed new feature to a standard should have proved value, and that patching a standard and its related tools could be a sign the feature isn't as needed as you think.

For some actual insight - I don't think that requiring a standard to have proved itself is a good place to be here. It's literally what I'm asking for here. Find a way to prove this out. Does it work, does it fail in some bad ways. I don't care about the 'make this a standard part'. I literally wrote "I'm not attached to this being the exact solution, but I think it's a problem worth solving, and I'd like it to be more than one terminal's feature (and more than one weekend's worth of yak shaving)." in TFA.

We're living in an age where experimentation is cheap. We can look at ways to find out if these things are valuable by trying them. My blog post isn't about making a standard a standard, we're a long way from that here, it's about working out if it's something people would find interesting and useful in the terminal. As a library maintainer in that space, having seen many many terminal user interfaces, I feel identifying gaps like this is a necessary part that makes things move forward. One thing to note is that experimentation down a path doesn't mean that that path will be accepted / used / useful. We do that in software all the time - HTML blink tag, DHTML, Java Applets, ...

And while we're at it, a better TERM variable, not the "user-agent header" of terminals that it is now.

To be more precise, TERM contains a single name, a key to index terminfo, a database of all known terminals and their capabilities. It assumes that such database is up to date and that every app has access to it, which is not always true, especially on non-unix platforms.

However, apps have begun using the name "as is", comparing it against known strings, e.g. "xterm", which led many terminals to advertise themselves as xterm just to ensure compatibility with existing apps.

A truly meaningful substitute for TERM would be a "semantic TERM", a variable that, setting apart the name of the terminal, focuses on the capabilities it offers. Not the complete set of properties listed in terminfo (we can give most of them for granted, today), but just the subset that differentiates modern terminals, like colors, kitty's protocol, OSC133, and a few others.

Already exists. Pay closer attention to the comments in terminfo.src explaining the suffix system and things like -16color, -vb, and -nam.

Never understood why 7 is considered difficult...

7 = ⌈ 2.2² + 2 ⌉

(2 << 2) - ( 2 / 2)

Rounding spoils the fun of the puzzle.

It seems very much in the spirit of allowing concatenation and square roots...

Rounding is a completely valid mathematical operation.

It is difficult when the rules do not allow exponentiation.

  7 = ⌈ 2.2 + 2 + 2⌉

Would still work.

> In over 50 years not a single parliamentary republic has turned authoritarian

What about Turkey? (I consider it among the parliamentary republics as it was so until 2017, when the authoritarian shift was already ongoing. In other words, the sequence has been: parliamentary, then turned authoritarian, then changed to presidential.)

Good point, I consider it borderline as it needed the transition via constitutional reform and a popular referendum to settle it.

> I can't think of a single time where you DON'T know what `count` is

A string created by strdup().

Then you know it's strlen+1

To be fair, that is a downstream effect of C's worst mistake (NUL terminated strings). Also, if every allocation you'd get is ptr+size you could just derive it by also copying the size.

Basically, the issue is C having unsized allocations and related not tracking string length.

So, new development in AI is contributed by AI more than by humans. Isn't this the exact definition of singularity?

I'd like to come up with some constructive comments, but I find everything so inconsistent and alien to me...

For example, variable declarations use the pattern <colon> <type>, as in

  var a: Int32

But literals follow the opposite syntax, as in

  a = Int32: 42

The return type of a function is introduced by : in func definitions, but by -> in imported func declarations:

  func foo(a:Int):Int
  import func bar(a:Int) -> (Int)

Other construct that I find far from my habits:

  var w, h, d = 640, 480, 2

instead of the more obvious (for me):

  var w=640, h=480, d=2

Arguments are passed by ref, not by val. Good luck with recursion!

Author here. The language has still many inconsistencies but not these ones.

Import functions is done the same way:

  func foo(a: Int): Int
  import func foo(Int): Int

May be the doc is outdated.

The multiple declaration is consistent with assignment:

  var w, h = 640, 480
  w, h = 640, 680
  w, h = getBoundingBox(obj)

The syntax

  var a = Int: 32

is unusual compared to many other languages because it just use a simple syntax:

  var id = expr

The type is prefixed only to resolve literals:

  var a = Int32: 42
  var b = Uint8: 42

It can be useful in generic functions:

  println("The answer is \a", Float32: 42)

But to create uninitialized variables I had to keep the syntax:

  var id: Type

> Import functions is done the same way [...] > May be the doc is outdated.

Same for function types? The docs still list the syntax with "->":

  & (Type) -> (RetType)

This one is up to date and it's definitely inconsistent, but I could not use ':' in place of '->' without creating an ambiguous grammar. Same for parenthesis in the return type since you can have a comma separated list:

  & (Type) -> (RetType1, RetType2)

Have you considered the syntax crystal uses i.e. 42_i32 and 42_u8?

It is not possible since you can create new integer types by sub-classing the primitive ones:

  class UserId: Int64
    ...
  end
  var user = UserId: 42

I also plan to replace predefined Int64, Int32, ... by generic types Int(64), Int(32), ... LLVM allows any integer size and Copper allows this kind of generic types.

The parallel assignment just work mostly like it does in ruby so that doesn't look weird to me (except the need for 'var' in the first place).

Agreed on the rest, though I don't understand what the problem would be with recursion. Is it using reference passing also for primitives like integers?

> Is it using reference passing also for primitives like integers?

That's what I assumed, but honestly I might have misunderstood the docs. This passage is not very clear:

> Copper manipulates only references to objects. Simple data types such as integers must be seen as references to stateless objects (i.e. objects that have no state in memory).

Sounds like they store the integer in the reference itself in that case. Which also is how Ruby does things (though Ruby has to decide what is what at runtime and thus steal a couple of bits off every integer).

Python does that too

Is this not destructuring a tuple?

Agreed.. and what is going on with the `!` syntax? The docs are not exactly clear on the purpose in all cases.

https://tibleiz.net/copper/documentation.html#basic-syntax

I think it's the opposite of & in C++, that is T! is an object, while T is a reference to an object.

You seem to reason in terms of trying at all costs to block the other players, not to maximize your gain. I agree the ultimate goal is to do better than all the others, but the tactics to get there may involve temporarily favoring other players in win-win exchanges to grow quicker, or to block a third player already far ahead, etc.