61–70 of 116 posts
One of my favorite TUI frameworks. I made https://github.com/mathaou/termdbms with it. A very pleasant experience.
That looks pretty cool, but as most/all DBMSs come with a TUI utility*, what is the advantage? *(psql, sqlplus, isql, etc....)
Earlier quoted context omitted.
I'm having trouble thinking of a single example of a language, library, or piece of technology that is not either an acronym, a name of something that exists, or a combination of such names. Be it an object (Flask), a concept (Scheme), a letter (C), a person (Sinatra), or an animal (Python). Maybe we need explicit namespacing in English? I'll start saying stuff like "programming languages colon colon ruby" so people…
erlang
I spent a good chunk of time last week looking for a solid cross-platform GUI toolkit. I came to the conclusion that the terminal is the most portable GUI platform available. You can create an app that has windows, buttons, mouse support, etc, statically compile it for Windows, Linux, and Mac, and run it over SSH. The closest you can get to that with real graphics is using a toolkit built on OpenGL, and you'll be for…
> "The achilles heel of terminal UIs is that they can't display images."
That statement is not entirely 100% accurate these days, thanks to some really creative hacks over the years. I'll list a few links where some fun examples live. ;)
[1] https://github.com/atanunq/viu
[2] https://github.com/stefanhaustein/TerminalImageViewer
[3] https://askubuntu.com/questions/97542/how-do-i-make-my-termi...
[4] https://unix.stackexchange.com/questions/35333/what-is-the-f...
I spent a good chunk of time last week looking for a solid cross-platform GUI toolkit. I came to the conclusion that the terminal is the most portable GUI platform available. You can create an app that has windows, buttons, mouse support, etc, statically compile it for Windows, Linux, and Mac, and run it over SSH. The closest you can get to that with real graphics is using a toolkit built on OpenGL, and you'll be for…
I'd look at Qt or Electron if you need to do cross-platform desktop apps, if for no other reason than accessibility. Sure you can make wacky midnight commander like GUIs in the console, but no screen reader is going to be able to make heads or tails of them and you'll shut out users.
JAWS might have dumped all their TUI accessibility features now that they think blind users should only use the GUI, but BRLTTY is based around the console. Orca does assume Gnome and/or a web browser, but it's no worse than usual with a console. (That is to say - I hate Orca, no matter where I'm using it.)
If you're making your own TUIs, there's a few things that curses sneaks in to make things a nicer experience. It uses the start of heading, start of text, file/group/record/unit separators from the invisible portion at the start of the ASCII table, which your sighted users can't see, but things like BRLTTY announce.
(Note: I don't use BRLTTY with an actual Braille display. I use it with espeak.)
I spent a good chunk of time last week looking for a solid cross-platform GUI toolkit. I came to the conclusion that the terminal is the most portable GUI platform available. You can create an app that has windows, buttons, mouse support, etc, statically compile it for Windows, Linux, and Mac, and run it over SSH. The closest you can get to that with real graphics is using a toolkit built on OpenGL, and you'll be for…
I've seen the charm suite on HN before, and everytime I see them I wish they had bindings to other languages. I'm just not interested in Go, but I'm really interested in learning to create ssh applications. Its an application runtime with a lot of potential for the dev space, but almost no quick-start frameworks!
Why not? There's a lot to hate about every language, but one advantage about Go is that it's fairly easy to context switch in/out of, which makes it great for side projects, because it's cognitive load while using it is really low. Unlike say, Rust. I do love Rust though.
The problem is that sometimes the zero value is valid, but not special in any way and doesn't make sense as the default. Go has arbitrarily decided that one particular value is special without your blessing or the ability to override it. This leads to bugs in which the zero value shows up in places where you don't expect it, simply because there is some code which doesn't explicitly set it. That's a very easy mistake to make, which makes writing Go an error prone activity.
I shudder to think that there's probably some Go program that deals with money, and a user's balance might be cleared to zero simply because some operation forgot to explicitly set it in some struct.
In order to implement "optional" fields in Go where you want to distinguish between zero (a valid value) and none (a missing value), the common solution is to either put the integer behind a pointer (which can be null) or use some "sentinel" value like -1 to indicate that the value is missing (as long as that sentinel value isn't actually valid in the domain of discourse). These are terrible hacks, but exactly what you'd expect from programmers who spent the majority of their careers writing C.
This design also leads to another kind of issue: sometimes you don't want people to be able to construct values of a particular type without going through a constructor which ensures the relevant invariants hold. This concept ("smart constructors") is widely used in other programming languages, but it's impossible in Go because Go allows anyone to construct an inhabitant of any type simply by declaring a variable of that type.
A simple example of that kind of issue is pointers: in (safe) Rust, references are guaranteed to be non-null, and you use sum types to implement optionality. This is great because you can always dereference a reference and not worry about handling the null case. In Go, all pointer types have that nasty zero value (null), and there's nothing you can do about it. The billion dollar mistake.
I like the fact that Go encourages simplicity, and for the most part the language is fine. But I'm convinced that having every type be pointed rather than supporting proper sum types is actually more complex in terms of the implications it has on writing and reasoning about code. They have mistaken minimality for simplicity.
Earlier quoted context omitted.
Why not? There's a lot to hate about every language, but one advantage about Go is that it's fairly easy to context switch in/out of, which makes it great for side projects, because it's cognitive load while using it is really low. Unlike say, Rust. I do love Rust though.
I'm only really interested in learning a language if it excites me, or if I'm getting paid to do it. I don't hate Go, and would be fine to learn it on company time for company projects, but there is no spark that would lead me to learn the language on my own. I've written some basic Go, but if I'm using it in personal projects, I'd would have to invest time to understand the ecosystem, runtime, standard lib, best pra…
I spent a good chunk of time last week looking for a solid cross-platform GUI toolkit. I came to the conclusion that the terminal is the most portable GUI platform available. You can create an app that has windows, buttons, mouse support, etc, statically compile it for Windows, Linux, and Mac, and run it over SSH. The closest you can get to that with real graphics is using a toolkit built on OpenGL, and you'll be for…
Earlier quoted context omitted.
Why not? There's a lot to hate about every language, but one advantage about Go is that it's fairly easy to context switch in/out of, which makes it great for side projects, because it's cognitive load while using it is really low. Unlike say, Rust. I do love Rust though.
I just can't get past the fact that Go doesn't have sum types. As someone who dabbles in category theory, it makes no sense to me that so many popular languages have product types but not their categorical dual. The lack of sum types leads to so many hacks and weird design patterns in the language, like returning two values when you only want the caller to read one of them (that is actually Go's error handling strate…
Earlier quoted context omitted.
Game engines (at least the lightweight ones) seem good for cross-platform graphical apps in general but the idea of redrawing a static GUI at 30 FPS just sounds too inefficient to me.
You're absolutely right. So I do without 30 FPS. We're all up this tree where we want all the features we're used to and we're willing to put up with software bloat and insecure software and sprawling supply chains to get it. I'm not. So I start with something minimalist and do what I can within it. One of my inspirations is http://akkartik.name/illich.pdf