nice! mailed them a couple more.
Perhaps you could add software links to your comment. I am always on the lookout for small applications that get the job done.
Tiny Apps
91–100 of 114 posts
Re: Tiny Apps
#92Back 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
#93Earlier 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.
Re: Tiny Apps
#94Earlier 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
Re: Tiny Apps
#95Earlier 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…
[1] https://www.athenahealth.com/more-disruption-please/labs
Re: Tiny Apps
#96Earlier 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
Re: Tiny Apps
#97Earlier 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.
Of course it all depends on what you want to do, but for me at least that was never a problem.
Re: Tiny Apps
#98Earlier 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)
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
#99Earlier 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…
Re: Tiny Apps
#100Earlier 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?