Live data from Hacker News

Tiny Apps

tinyapps.org

91–100 of 114 posts

Re: Tiny Apps

#92
I love the minimal and efficient app mindset.

Back in the 90s I used this DOS text editor that fit on a single floppy sector (512B). I forget the name, but it was a part of my standard toolkit for many years.

These days, I run "evilwm" for my home desktop. That's about as small and efficient as a DE/WM gets anymore, and I love it.

Re: Tiny Apps

#93

Earlier quoted context omitted.

I've been thinking about this a lot, mainly due to being grumpy about the proliferation of Electron apps and the effect that's having on my available RAM. When I'm not being so grumpy, I'm glad it's easier to write apps than ever before. I think someone on here posited that it's a choice between something written in Electron or not written at all. I think that's fair enough - maybe we just need to make it easier to w…

> I'm glad it's easier to write apps than ever before. I believe that it is Delphi which sits right at the sweet spot of 'native code', 'easy gui development' and 'easy deploy' and I am sad that it is not really in use anymore.

[deleted]

Re: Tiny Apps

#94
post #53
post #26

Earlier quoted context omitted.

I worked at Epic a long time ago. They're a bad employer -- churn that would make the worst valley sweatshop blush -- and even when I worked there had 10s of millions of lines of vb6 and the same in mumps/cache, the world's worst programming language. I'd imagine their systems have broken 100m lines of code by now. You're essentially using software to automate how hospitals and outpatient clinics work. Each one of th…

TDWTF had an article about MUMPS that stands out in my memory [1] When I see COBOL fixed width data at my workplace, I just think about that article and thank my lucky stars. [1] http://thedailywtf.com/articles/A_Case_of_the_MUMPS

If I'm not mistaken that is about Epic, but they didn't write the name to prevent lawsuits.

Re: Tiny Apps

#95
post #69

Earlier quoted context omitted.

I wonder why this field hasn't been disrupted yet. It seems ripe for it. Established players. Arcane systems. Poor performance. From what I've heard from employees at Epic their software is something of a nightmare. Is it just something waiting to happen? Is there a company that is already doing this? It could probably be done one independent hospital at a time. Eventually you could get a small network, etc. I unders…

There are companies that are trying. Athena was doing a good job in a lot of respects but then decided they wanted the hospital market and that hasn't gone well. The issue is that switching EMRs has a huge switching cost. You are looking at years just to get the sale. Then there is the time and cost to switch which can easily be 6-24 months depending on size. The biggest problem is that all the health care workers ha…

Thank you. It looks like Athena is trying to do just what I described. They even have an incubator for new health related startups[1]. Of course, it is difficult to know from the outside how well they are doing and their trajectory, but I am (foolishly?) optimistic.

[1] https://www.athenahealth.com/more-disruption-please/labs

Re: Tiny Apps

#96
post #53
post #26

Earlier quoted context omitted.

I worked at Epic a long time ago. They're a bad employer -- churn that would make the worst valley sweatshop blush -- and even when I worked there had 10s of millions of lines of vb6 and the same in mumps/cache, the world's worst programming language. I'd imagine their systems have broken 100m lines of code by now. You're essentially using software to automate how hospitals and outpatient clinics work. Each one of th…

TDWTF had an article about MUMPS that stands out in my memory [1] When I see COBOL fixed width data at my workplace, I just think about that article and thank my lucky stars. [1] http://thedailywtf.com/articles/A_Case_of_the_MUMPS

MUMPS really isn't a bad programming language. It has certain characteristics like allowing incredibly terse code, with abbreviations for all the commands and single letter variable names, but the trade-off of a NoSQL hierarchical datastore acting as variables to the programs with string values and string subscripts on arrays, hiearchical inter-process locking, high level variable management and garbage collection, run time code and variable evaluation, and other advantages. Modern MUMPS systems have high level database management systems as well.

Re: Tiny Apps

#97

Earlier quoted context omitted.

I'd say that with Lazarus ( http://www.lazarus-ide.org/ ) it even easier - just drag/drop the controls to forms to build your GUI, double click on buttons/checkboxes/radiobuttons/whatever or click on menus or double click on the event editor to automatically write the event handling boilerplate code and you just write the actual code in-place. Creates native executables without need for runtimes or big DLLs (you can…

Don't you need to be using Lazarus' language (Delphi?) for that? In most cases, that's very prohibitive, since a language with a large ecosystem is usually what you'd want to be writing stuff in.

Yes, but there is a ton of functionality already out there, Object Pascal is popular enough to have almost everything available and for the stuff that aren't available it is trivial to call into other native languages (and there are many bindings already available). If you have a C header you can even use a conversion program that comes with Lazarus to create a binding for it.

Of course it all depends on what you want to do, but for me at least that was never a problem.

Re: Tiny Apps

#98

Earlier quoted context omitted.

In my previous life as a cubicle drone in the late 90s I have worked with Delphi under Windows and always dreamed about it being ported/cloned/whatever on Linux. After seeing a demonstration of Kylix many years ago I almost lost any hope (slow as molasses and buggy), then one day I saw this new project called Lazarus which promised high compatibility with Delphi code and to allow building of native apps. Admittedly i…

I've tried to use Lazarus five or six times now, as a one-time Delphi developer: the main issue is that the lazarus ide likes to crash on the slightest provocation (and the 64bit mac versions don't work very well either)

Which version did you use and when? 10 years ago the IDE would crash at you sneezing at it and it wasn't until 7-8 years ago that things became stable. However i cannot remember the last time i saw the IDE crash (and wasn't my own fault with a component i was making that caused it to crash, but even that that is rare).

Note that there are a few versions flying around that are unofficial builds, some with addons that break it. Sadly one of them is the one from getlazarus.org which is both unofficial and often comes with unfinished and buggy features from development versions that cause it to crash and be generally more unstable. Combine this with the fact that the guy behind getlazarus.org tries his utmost to promote Lazarus (his version from his site) and there is a chance people who first learn about Lazarus will use the buggy one. He obviously means well, but i really wish he would link to the official site (http://www.lazarus-ide.org/) instead. The builds there are much better tested and there are many week-long release candidate builds that are tested by many people in the mailing lists, forums, etc before an actual final release is made.

Also note that the native Mac version is really in a worse state than the Windows and Linux versions. Thanks to Apple discontinuing Carbon (which is what Lazarus uses on Mac by default), a ton of work has to be done to rewrite the backend in Cocoa and there are very few programmers working on the Mac version so this progress is slow (also AFAIK this was delayed to implement the "Objective Pascal" extension to the compiler that would allow using Objective C classes directly without needing an intermediate C layer). Today you can use both Carbon and Cocoa as backend targets, but between the two the Carbon one is still the most stable. As an alternative you can use the Qt backend though that is more stable and featureful (thanks to it being also worked by the Linux devs), but you'll need to bundle a bunch of shared libs and are throwing all notions of minimalism out of the window :-P. Still it is the only way to get full featured stable 64bit apps with Cocoa made in Lazarus, at least until the Cocoa backend improves. And it isolates the bloat to a single platform, which while not ideal, is better than nothing (and IMO even the Qt+LCL combo is still better than bundling an entire web browser with your program).

Re: Tiny Apps

#99

Earlier quoted context omitted.

I've tried to use Lazarus five or six times now, as a one-time Delphi developer: the main issue is that the lazarus ide likes to crash on the slightest provocation (and the 64bit mac versions don't work very well either)

Which version did you use and when? 10 years ago the IDE would crash at you sneezing at it and it wasn't until 7-8 years ago that things became stable. However i cannot remember the last time i saw the IDE crash (and wasn't my own fault with a component i was making that caused it to crash, but even that that is rare). Note that there are a few versions flying around that are unofficial builds, some with addons that…

So, I do most of my work on Mac, so that's what I'm using. It took me forever to figure out how to rebuild it as a 64bit app using Qt (I built the Qt5 version, maybe that's part of my problem?). Anyways, once I did that, it started fine but I ran into several issues where changing properties of Data Access components would crash the IDE. (postgresql-related things in particular). If I find time, maybe I'll submit some sort of bug report with a reproducible scenario.

Re: Tiny Apps

#100
post #80
post #23

Earlier quoted context omitted.

Ha! Thanks so much for the kind shout-out, j_s - what a memory you have! Glad to see my humble corner of the web is still of some small interest ;-)

How did you know he mentioned you? Is there some sort of @mention bookmarklet/browser extension in HN?

failing other explanation, i linked the thread when i sent him a couple of additions.
Post reply on HN