Hacker News Reader

You can't just freehand them with a rectangle tool and a few canned textures.

I mean, why not? If I'm a small business, and I need a custom (in-house) app, AND I could do it myself with little training, I'd rather do that then not have the business. (Again) how many businesses run on Excel Spreadsheets? Not every business can hire a programming firm to make a boutique app that's used by 100 people.

But I'm also one of those, "Why did FileMaker Pro die?" kinda person. And I still write Perl. I'm a weirdo, but I'm a pragmatic weirdo that likes to get stuff done.

I do a lot of freelance and I can't tell you how many businesses I've worked with who had some need that was just a smidge more than their current software would allow. If there was something in between using an interface and learning a full-fledged programming stack from first principles, it would go a long way.

Part of this goes towards getting people -- both today's mainstream developers and users -- to think hard about what using a personal computer should mean.

I can't think of a better definition of programming than "telling a computer what to do." That should be the first hint.

That's part of the reason why Emacs has this kind of cult following. There's always something you need that's "just a smidge more" than your Emacs can do, but it's very easy to just code up that missing bit. It might be not for casual user (requires learning some basics of programming), but then again, the legend goes that secretaries used to use Emacs and like it, for similar reasons people like Excel today - they need something extra, they can make it themselves on the spot.

And another thing people should learn from that, never underestimate secretaries, accountants etc.

It is often good to limit what non admins can do to the system, servers, their computer os etc.

We should also limit who has access to sensitive data.

But I think often companies could be more productive if they taught their employees to script a bit.

> And another thing people should learn from that, never underestimate secretaries, accountants etc.

It is difficult for the modern developer to think of users as anything other than dumb cattle, because doing so would raise ethical concerns about their high-engagement eyeball-farming products.

Back with Multics, secretaries were given Emacs as editor, and they had access to a manual on writing lisp code for it... With no mention anywhere that it was programming in one of the most capable languages of the time (MACLISP on Multics).

In short time, many secretaries that honestly believed that "programming wasn't for them and was too hard" had written lots and lots of automation for their daily tasks. Cava was their Hypercard.

http://www.gnu.org/gnu/rms-lisp.en.html

This came up the other day in a different thread but I think it bears repeating. I am generally an Electron hater, but there’s this huge opportunity for applications to provide access to a JS REPL inside Electron apps to give users the ability to tweak apps to fit their needs. Not just a “we’ve included scripting functionality” like eg VBA gives you, but access to the whole damned thing!

I can dream anyway.

I've been working on something like this, a visual programming language called BlockStudio [1] 1. www.blockstud.io

> But I'm also one of those, "Why did FileMaker Pro die?" kinda person.

FileMaker is not dead[1], and in fact it's now a highly-rated "Low-Code Platform For Business Developers".[2]

[1] https://www.filemaker.com/ [2] https://content.filemaker.com/2019_FM_forrester_report

>I mean, why not? If I'm a small business, and I need a custom (in-house) app, AND I could do it myself with little training, I'd rather do that then not have the business.

The first company I worked for developed such a system and it worked out very well for them. You would write your UI in XML and your business logic as Postgres stored procedures using either PLPGSQL or any number of other languages with Postgres bindings. They then had a C frontend which would parse the XML and render out the UI using either GTK or HTML. It also had the ability to make arbitrary HTTP requests which allowed for some pretty sophisticated integrations.

Everything about this felt wrong yet it allowed the company to rapidly deliver new functionality and bespoke customizations, on site and often in a matter of hours. It was also simple to the point they could train others in the business (outside of development) to use it.

>Why did FileMaker Pro die?

Did it, really? I still find it amazing. I did wonders with the lightweight version of it that came with Claris/Apple Works

FileMaker Pro is pretty much alive, they have a conference happening in two weeks: https://www.filemaker.com/learning/devcon/

There are many companies using it.

FileMaker Pro is still around.

With new versions that they email me about every couple of days.

> Why did FileMaker die?

IDK, but 80% of web apps were during the 2000s so so interfaces on top of a relational database...

And FileMaker was so superior...

Seems that in computer we try end to think that "worst is better".

In 2010s they still were, but with "relational database" part swapped out for something worse still.

If you squint, you can just see many webapps as taking what would work better as a bunch of MS Access forms, and locking it down from every possible side so that there's a directed flow users can't deviate from, and so that they can't possibly do anything with their data that the webapp owners don't allow.

When Hypercard was new, you could use it to create user interfaces that looked and felt exactly like all the other Macintosh applications of the era

Maybe someone could, if they put a lot of effort into it but I think you're misremembering this. Typical Hypercard stacks felt like Hypercard stacks and not other Mac apps. There were lots of nonstandard buttons and icons, no pop up menus, the menu bar wasn't used, etc. UI triggered by mouseover was easy and common in Hypercard, not so much in standard Mac apps.

"Users expect their programs to give them up-to-the-minute information from the internet, with slick animation and nuanced typography." This is what is the problem. It is also why I often write my own, because, I do not want those features.

Rather, better features can include such as keyboard commands (including prefixes, etc), compact view that still includes the relevant information, mouse chording, programmability (for data-oriented stuff, the ability to run SQL queries can help), etc

> Users expect their programs to give them up-to-the-minute information from the internet, with slick animation and nuanced typography.

Did you ever watch an average Joe, who has zero understanding what involves programming a computer actually use a computer?

Let me let you in on a secret: The average user doesn't care!

The average user doesn't care how fancy or not a UI looks like, if it follows the interface guidelines. The average user doesn't care if a UI is responsive. The average user doesn't care about smooth animations. The average user doesn't care about slick typography (they prefer horrible Word-Art, Comic Sans and Papyrus). The average user doesn't even care about up-to-the-minute information!

It is developers and people who have an understanding of the problems that must be solved to provide slick animations, responsive UIs, good typography and continuous data updates. Most developers, when thinking about a user think about themselves when they use someone else's product.

My mother already goes off the rails, if an update on her computer just updates one minor detail in the UI toolkits styling. Or if an iconset updates a previously inconsistent or missing icon.

Users care about consistency! It doesn't matter how bad a program is done in a certain aspect, as long it is and stays consistent.

The standard Hypercard should be compared against is janky, macro laden excel based “tools.”

Users don’t have these basic expectations you’re talking about of internal software. Every large company I’ve ever worked for or with has tons of critical business processes that are 100% dependent on some shitty spreadsheet that gets passed around.

> UIs are expected to reflow to devices with different screen sizes and dot pitches

> Users expect their programs to give them up-to-the-minute information from the internet, with slick animation and nuanced typography.

Do these requirements really come from the users? Or do they, in fact, come mainly from tech people? I never understood this mentality that mobile devices must be considered at all costs for all cases, and it seems to me that this mentality comes and always came from industry people, not users. I suspect this is related to three things:

- The laptop/PC market is "saturated", in the sense that it can no longer hyper-grow, so it's not so convenient to make a billion or two;

- A new zoo of careers paths has grown out of mobile and the startup era: UX designer, Product-Whatever, Growth-"Hacker", Agile Wizard, Evangelist Something etc, etc. It's very hard to convince someone of something when they salary depends on them not believing it, says the cliché but is true;

- It is more lucrative to show ads to passive consumers than to sell software to creators.*

This is a situation where the current game of Silicon Valley capitalism (copied everywhere) configures a race to the bottom in terms of the expression of human potential.

* This is why, even when you want to buy a tool, you now have to "subscribe to a service", with the loss of sense of ownership and control that comes with it.

> Do these requirements really come from the users? Or do they, in fact, come mainly from tech people?

I think a lot of them come from the "expectations" about computing created by the world of web applications. And those requirements themselves come from, most importantly, the advertising industry. In one way or another, by varying but important degrees, advertising defines how we create these interactive systems and worsens the user/developer divide

Hypercard seems rather reminiscent of VisualBasic to me, so I can understand its popularity. The difference seems that Microsoft embraced its quirks and shifted it into several areas (VBA for the office product, and perhaps VBScript for IE). VB became vb.net which was succeeded by c#, as the language (vb/c# and others) became decoupled from the development environment.

The main modern difference between ye-olde hypercard and vb, is that the whole ecosystem was a monolith, whereas now it's disconnected.

>Hypercard seems rather reminiscent of VisualBasic…

Hypercard predates VisualBasic by many years

Great correction, thanks! I actually meant that it reminded me of ye olde-VB (because it's ancient in its own right).

I would say it was closer to access and access forms than to VB. It was more UI centric where you just added snippets of scripts for button clicks and other actions. Access forms where like this but had wiring to the Access Database that was the real difference between the two. Hypercard was UI focused and access was data focused but both had the concept of layout the form and add snippets of glue. I would put Macromedia Director in this class of applications as well.

Maybe , just maybe HyperCard wasn't meant for professionals to make and sell programmers. Maybe if people had something like HyperCard today, they wouldn't need us programmers.

You shouldn't have been downvoted, as you're spot on.

Programmers who feel hurt, please take in mind that there will always be the need for system programming and building software platforms for enterprise levels; but the vast majority of small "business workflow" use cases would be best served by a tool allowing the final user to explore their needs and build a small interface to process .

Compare it to needing to call a interior designer or handyman to hang every picture in your home. You only should need hire professional contractors for real work, but small changes should be within the reach of laymen with simple tools.

Isn't that kind of what Lotus Notes did? Everyone ended up hating the email client foisted on people after IBM bought it, but the workflow capabilities and and form designer were really nice.

Yes; unfortunately the culture of "do it yourself software" died when Apple's model of "information appliance" took off.[1]

[1] See related article by same author: http://www.loper-os.org/?p=316 On the Still-Undefeated Tyranny of Apple.

Re: UIs are expected to reflow to devices with different screen sizes and dot pitches.

Most businesses still use desktops and laptops. For something in-house, the extra effort and complexity of reflow may not be worth it.