Hacker News Reader

Comment by homebrewer | Hacker News Reader

And the guy who wrote this:

> .. work at a gas station and don't make money coding.

(From the readme of one of his other projects.)

If self-proclaimed "senior software engineers" worked on this, we would have a multi gigabyte download with an Electron-based editor.

There's a donation link in there with a very fair asking price.

View on HN

Programming was sometimes even easier in the past, this is actually one of the reason for BASIC to exist: "Beginner's All-purpose Symbolic Instruction Code".

On Amstrad CPC 464 / 6128, you just entered the interpreter, you could immediately interact with existing code and start playing around with it.

Today, it's more complex, because the Operating System developers deliver more complex APIs to fit the needs of the plethora of developers, and the level of abstraction, and responsibilities of each teams / components.

Though natural selection tends to favor the simpler / more friendly languages (Python / Javascript), and others like Haskell, Erlang, Lisp, etc... are just for people in museums who see beauty in complexity.

Some say:

Simples see beauty in complexity. Smarts see beauty in simplicity.

> Today, it's more complex, because the Operating System developers deliver more complex APIs to fit the needs of the plethora of developers

This project is evidently coded against Win32 and runs on any Windows OS in the last 30 years.

Which is to say the "operating system developers" provided APIs in 1995 that are still there, still work.

Last I checked, Electron isn't an OS API.

I think QBasic was the perfect level of ease of use versus ability to produce useful programs. It had a full featured editor that could run your program with a single keystroke. It included support for graphics and music. Most importantly, it had extensive builtin documentation.

It's more complex because the tooling optimizes for teams of developers rather than single developers. For example, back in the day it was expected that programmers knew enough of how UI works for their given platform to where they could either drag widgets onto a form (e.g., VB, Delphi) or just code up where they're supposed to go (e.g., Tcl/Tk) and they'd have a UI for their application. These days there's a huge division of labor between how widgets are supposed to look and feel, and where they're supposed to go (designers), what their actions are supposed to be (front end developers), and what state changes those actions represent (back end developers). These are assumed to be done by different people, so the tooling supports each person's workflow, e.g. L^HFigma for the designer, React for the front end, etc.

Bisqwit is a nearly Carmack-tier programming genius. For a time he drove a truck to make a living and just programmed in his spare time.

https://www.youtube.com/@Bisqwit/

I'm a "senior software engineer" by title (I need to make more money than I would working at a gas station or driving a truck, and programming is what I'm relatively good at), I love things like this, and I fight for simplicity and lack of bloat whenever I can, sometimes putting myself at odds with my colleagues and Management.

Yeah :) I have something a bit similar here. An old Ruby version compiled for Win32 (Win2000 and up) with graph library ready to use.

991k ruby.exe*

I wrote performance monitor in it for fun: http://borg.uu3.net/~borg/?gperf

Reply on news.ycombinator.com