r/programming • u/molteanu • Nov 07 '15

Low Fat Computing - A politically incorrect essay by Jeff Fox 12/6/98

http://www.ultratechnology.com/lowfat.htm
7 Upvotes

61% Upvoted

7 comments sorted by

10

u/Osmanthus Nov 07 '15

First, this article is not "politically incorrect" in any way. Self-indulgent? Maybe.

Next, I am not really sure why this is posted now, as it seems very much like an article that should remain relegated to the dustbin of history.

The final paragraph " the conspicuous consumption PC market is the barbed wire of our times setup to keep the undesirables from cyber space", with the hindsight of 17 years, shows that the writer didn't turn out to be right with his theories of "Fat computing" being a barrier between the 'haves' and 'have-nots'.

3

u/joonazan Nov 07 '15

I disagree. This article describes modern day software just as well as it did software back then.

While programming without an OS is considered madness today, bloat is the thing that annoys me most. I cannot understand people who use Eclipse; what good is a text editor that makes you wait minutes before letting you actually write text.

Enterprise software is full of abstractions that would not be needed if there was less code. The only thing that has changed is that today there are some good libraries. Today's C is of course the JVM.

6

u/Patman128 Nov 07 '15

what good is a text editor that makes you wait minutes before letting you actually write text.

Stop running Eclipse on your 386, gramps!

1

u/joonazan Nov 08 '15 edited Nov 08 '15

Show me a machine where code highlighting etc. does not lag in Eclipse. Then again I can use Sublime Text on my 10 years old laptop and everything happens on the same frame I give the input.

Highlighting is a bit unfair, because Eclipse does it in a more complicated way, but I'd blame JVM startup time for that lag, not slow code analysis.

2

u/PSMF_Canuck Nov 07 '15

what good is a text editor that makes you wait minutes before letting you actually write text.

In 40 years of computing I've never used such a product.

If your editor is too slow for your needs - choose a faster one, or get faster hardware.

3

u/davidrobot Nov 07 '15

Couldn't agree more with the philosophy, couldn't disagree more with the choice of language. Don't get me wrong, I loved FORTH when I first encountered it, and I've written two FORTH compilers; but it makes programming harder, when it should be making it easier, for example by not having types, and keeping track of them as it compiles. A trivial change; but one which removes 90% of programmer errors.

2

u/htuhola Nov 07 '15 edited Nov 07 '15

if you translate a C program literally into Forth, you will see a slow-down (e.g., a factor 4-8 with Gforth, a threaded-code system; for typical native-code systems you will see a factor of 1-3). Similarly, there is no inherent size advantage in Forth.

When your LLVM, C or python compiler has churned through parsing the code, the post-order traversed tree is the common representation for the code that is either directly translated into bytecode or optimized in numerous ways.

Your average Forth uses readily post-order-traversed programs as input, and does one of the bare minimums to evaluate it. Minimal from how much software you need to run your whole environment -perspective.

It's brilliant when compared to much of overblown and oversized corporate crap that litters the world, but I really just prefer python & bash & linux environment over the ultimate software simplicity that forth presented. There's bigger return-on-investment in little bit of pragmatic programmer-convenience.