mhd

Seems everyone has. Which is weird, given how bad everything looks despite this focus.

I'm not sure what's going on in the design world. I mean, of course there's the influence of the web design spheres. The web didn't have the GUI standards that e.g. Macs were known for. In the beginning, they couldn't emulate the desktops. Toolkits like ExtJS tried, but you stated with the basic problem that you didn't know what desktop you wanted to emulate. Windows? Mac?

By the time the browser caught up, the damage already had been done, and the stop-gap solutions and styles more suitable for ads created a "web style". Flashy, flat, deserts of whitespace. The aesthetic stranglehold this had then not only persisted, but crossed over first into mobile (the somewhat standardized look & feel of early iOS quickly vanished), then the desktop.

And now nobody knows where they're going, despite having more people solely focused on "UX" than ever before. But you need to do something to justify your position/salary, and that's how we get the Microsoft/Apple designs of the last decade or so. And not having any ideas beyond type systems or init replacements, the open source world just emulates that.

Next step, programmming and RPG with RPGs in RPG.

When I read about Pancake, for a very short moment I was hoping for some Elan[1] influences…

1: https://os.inf.tu-dresden.de/L4/l3elan.html

A lot of C# and Java code is oriented towards web backends, too. Which are quite big and complex. So it seems natural that languages in the same design space (trad OO) converge on similar features. I think the only exception these days is Go.

I think these days you could change "You can write Fortran in any language" to "You can structure your code like Spring in any language"…

Perl? Are there existing modules for the Linux KMS interface? Otherwise this would also be an off-beat language choice, and these days with only marginally more developers… (And I say that as a Perl fan)

Personally, I'm glad that this isn't yet another Rust post ;)

Don’t threaten me with a good time.

Any good cases for that? I’d be afraid of ending up with a lump of duct-taped SATA SSDs around the PCB…

I'm voting for Cold Fusion on top of Golang.

Someone should make a windowmaker dockapp out of this.

> I'd even suspect if you tried Golang it may even bring SumatraPDF to other platforms which would be another huge benefit to your users

Probably by using a cross-platform toolkit written in C++.

Done a while ago: https://en.wikipedia.org/wiki/Scwm

There was also "GWM", based on its own lisp dialect, "WOOL", which was around from at least the early 90s.

On the more popular side, you had sawfish (using an elisp-alike, IIRC) and stumpwm (Common Lisp).

I would recommend most fonts that Michael Sharpe worked on. He did some nice refinements on already-decent fonts, often to bring copies closer to the original[1]. Heck, I’d recommend them outside of LaTeX, too.

Favorites out of those are XCharter, ScholaX, Etbb and Erewhon.

Also have a look at Algol Revived, which is a remake of a font made for French Algol 60 books by famed type designer, Adrian Frutiger.

[1]: https://ctan.org/author/sharpe

To be fair, everything is still bundled with Slackware.

This reminds me of the days when all of a sudden win32 programming in assembly became hip enough, probably as a response to the increasing size of shareware downloads ('twas the dark time of MFC).

Combined with early Palm Pilot 68k programming, those were the last hurrahs of non-retrocomputing asm I can remember.

On the other hand, I'm also sad that I don't longer have a computer interface like I had from 1995 - 2010, i.e. that everything is webflat and image-heavy. So weighing the timeline options, I'm not sure I'd pick the look and feel of the post-optimal time frame on a given day ;)

I'm currently using an old copy of Letter Gothic 12 Pitch from an ancient Ventura Publisher CD, and like that style a lot, so definitely going to try this.

The Wiki[1] is one of the primary "hang out" spots, although it's a bit different from usual online communication. But there's a lot of mutual commenting, small articles and utilities etc. on there.

[1]: https://wiki.tcl-lang.org or https://wiki.tcl.tk

Sure, but does anyone remember SCGI?

Well, sadly NeWs isn't supported anymore.

While I agree that there's been a decided shift towards one-try-language-ism these days, there always were complaints about Perl's readability. Mostly because its heydays didn't quite coincide with good programming practice, both the early Perl4 admin scripts that replaced the horrible mish-mash of "standard" user space of the commercial Unices, and later quick-fire CGIs.

"Proper" procedures and tooling were less involved there, if they were present in the Perl version of those days in the first place. (And also Python wasn't a horrible feature creep blob back then, so shone in comparison)

Perl had and has a lot more to offer than that, but many people didn't come across that. Of course these days purity tests are much more involved, and many people wouldn't even dare touch languages where there's no type system that could launch a 1000 ships of PhD's writing theses about it. ;)

Having ranted that, it feels a bit odd to argue about this in a thread about MIDI. Where you're likely to connect to a plethora of synths from the 80s that have the combined computing capacity of a pregnancy test. Where using an Atari ST from '85 to sequence things is still a viable option. Where DIN plugs are the state of the art, like on your oldest Model M.

And we're back to the roots of Project Builder, XCode's predecessor.

Or, to be honest, early XCode versions, where a lot of editing was done in more stable/capable editors.

Isn't this basically the same feature that existed in ksh93?

Wouldn't that mostly matter if you're really navigating in your source code via the tree panel? In the post-Textmate days, fuzzy file finders seem to be all the rage whether you're using vim or IDEs (or Sublime etc.). Or you go to definition/references immediately.

I mostly use the file navigation when exploring the structure, which I'm not doing that often.

And which I probably should do with a class browser anyways, which I used to do often in Eclipse, way back in time, but it seems that particular SmallTalk-ism isn't very popular in contemporary IDEs.

OpenLook would like to have a word about those corners…

(But yes, in general it's all custom "cards" and list views. HTML didn't allow a good set of GUI widgets, so people adapted, and now the cruel circle has closed with desktop UIs being "informed" by web and mobile views)

> GUIs made in FLTK are visually ugly.

In the earlier days, both Qt and gtk quickly jumped on the theme train, where you could customize the looks of widgets heavily, and IIRC FLTK never caught up there. I think the default L&F can compete with default gtk1/2 or Motif-ish Qt, but you couldn't go up from there or try to have a common look & feel between toolkits.

These days, that has gone one step further. Where a lot of people consider anything with "old-school" widgets to be ugly and outdated, and a more web-like cards/list-view based approach with highly customized and animated UI elements.

Qt with its QtQuick/QML parts seems quite competitive there, not sure how good Fltk 1.4 is here.

(Just repeating the way I see the "state of the art" here, I personally don't like that "proper" GUIs are now retrocomputing)

If I remember correctly, both FLTK and XForms have a commmon "ancestor" in the Forms library for SGI (pre-OpenGL days).

> effectively better than all of the alternatives

Which gladly rarely happens, so often you still have sufficient choice. Now, if it turns out Euler sabotaged some bridges and caused deaths, you'd still have a hard time avoiding using e.

But for software? It's usually rather easy to find alternatives. And ReiserFS never was an exception here.

Having EWD as a dissenter also seems a rather low bar, to be fair. (One might say he was a bit of a Edsgerlord.)

There's a lot of hearsay in that articles, and a lot of sentiment rooted in the particulars of that time.

Sure, it was a complex thing in the late 60s/early 70s. Sure, Wirth came up with something simpler. But I'm missing a deeper analysis, especially with a more modern view point where basically any language is at least as complex as Algol 68[0].

> Arguably Wirth’s Algol-W was a better successor to Algol-60

I might not even disagree, but what were the arguments, and how are they holding up?

> and arguably did not have the same connections to industry as the likes of Fortran and Cobol

Sure. But neither did Algol-W or Pascal. And pretty much anything else in the 20th century.

[0]: http://cowlark.com/2009-11-15-go/

I wouldn't go that far, as there are already a bunch of people using it. As always, there's a spectrum between mass consumption and purely individual environments. It's just that as an industry, we've never been that much oriented towards the "mass" end since personal computing started. You basically pick one of two or three IDEs, and as a prize get to customize your color scheme…

There's still a not-quite-niche amount of e.g. (neo-)vim or Emacs users who have highly customized environments, and often not just by composing various third party elements, but also writing a lot of extension and glue code.

And of course on the other end, you've got people who wrote their own editors and other daily apps, often encouraged by constraints - forth environments in embedded situations (Chuck Moore's ColorForth being a good example), or Windows without "POSIX escape hatches", where there's a lot of handwritten tools in C/C++. I'm a bit saddened about how little one knows of this, which brings us back to art: Just like we're never getting to see the unique paintings some Belgrad plumber is doing in their attic, we're also never getting to see the dozens of Rexx scripts that work for some IBM mainframe programmer for decades.

A lot of the "alternative" environments are less practical. But they are joyful to their users, which is a part of user experience (or, well, human experience) we shouldn't neglect. Performative minimalism is probably one of the bigger ones amongst the readers of this forum.