Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Chuck Moore, Extreme Programmer

cs.uni.edu

Post reply on HN
Print view View original

101–110 of 186 posts

Re: Chuck Moore, Extreme Programmer

#101

Post by dewster »

coliveira wrote: post #40
dewster wrote: post #37

THE central problem with pure stack machines and stack languages: The programmer knows in their heart that moves, swaps, dupes, drops, etc. - any stack manipulation that doesn't involve a functional change to the data itself - is an inefficiency to be minimized, but this effort isn't in any way related to the problem at hand (writing a program to do something) so it's unwelcome mental overhead. I like puzzles as much…

Traditional languages are pushing and dropping data from the stack every time a function or procedure is called, they just give it another name: parameter passing. Making it explicit, at least Forth tries to reduce the need of copying things from the stack to local variables.

I don't think the stack in a traditional languages is the same as stacks in stack machines and languages. It's a lump of memory that gets allocated to a thread for stuff, and the allocation is indeed done in LIFO fashion, but I believe access to individual memory locations in the allocation is random. Name is the same, LIFO and all, but the mechanism granularity makes it quite different.

Re: Chuck Moore, Extreme Programmer

#102

Post by dewster »

protomyth wrote: post #24

Forth was always fun for me because it really was fun to build up a dictionary of words that solved your problem. It practically forced coming at the problem from the bottom. I do admit that I liked some aspects of Postscript better than Forth, but both are experiences. Thinking Forth is a pretty good starting point and in general a great programming book http://thinking-forth.sourceforge.net/

It's called factoring with subroutines, and Forth hasn't cornered the market on anything by calling them words.

Re: Chuck Moore, Extreme Programmer

#103

Post by fasquoika »

dewster wrote: post #100
fasquoika wrote: post #97

Earlier quoted context omitted.

If you're programming in Forth and you find yourself doing lots of stack manipulation, you should at least consider using local variables. Once you accept that there will be times when variables make more sense, you'll be surprised at how infrequently you actually need them. Edit: Be aware however, variables dramatically reduce composability (in any language actually, most just aren't very composable to begin with).…

Pure stack machines don't have local variables. They have at most two stacks and that's it.

I was under the impression we were talking about Forth, not a pure stack machine

Re: Chuck Moore, Extreme Programmer

#104

Post by PeCaN »

throwaway7645 wrote: post #89
feelin_googley wrote: post #16

The "Do Not Speculate!" idea reminds me of the practice of delivering "the kitchen sink" when only a small program that does one thing would suffice. It reminds me of when, e.g., a 1990s-2000s Windows user needed a small program that does one thing, and in order to get it, the download from Microsoft was an installer with hundreds of megabytes of unneeded binary files. It was not possible to download only the single…

This is what I like about Rebol & Red...pity Rebol didn't catch on more. The full Rebol download is a single executable (no real install) and can build GUIs, and so much more in a very small amount of code.

I'm always amazed when I see things like Red, with a 1MB executable with an interpreter, compiler, GUI, networking libraries, parsing libraries, and more all built in.

Or the QNX demo disk back in the day. OS, GUI, web browser (with javascript), full clustering support, and more, on a single 1.44MB floppy.

Re: Chuck Moore, Extreme Programmer

#105

Post by ryandrake »

com2kid wrote: post #78
woodrowbarlow wrote: post #72

Earlier quoted context omitted.

i don't buy it. dpkg was released in 1994, and that was designed to tame the nest of people passing around small executables on the internet.

> i don't buy it. dpkg was released in 1994, and that was designed to tame the nest of people passing around small executables on the internet. The problem is corporate policy. In the yee old days, publishing content to MSDN was not easy. Bill Gate's rant[0] on this topic gives some insight. Grabbing small EXEs is now a lot easier. See: https://docs.microsoft.com/en-us/sysinternals/ [0] http://blog.seattlepi.com/micr…

I knew which rant that was going to be before I even clicked on the link. Great memo. Really refreshing Software companies need leadership who actually dogfood the software they make and who care enough to rant when quality, usability, performance, etc. has gone to shit. Too many seem to simply have their noses in their competitors' feature checklists, so their E-mails are all "Company X has Feature Y. Why can't we have Feature Y??"

Re: Chuck Moore, Extreme Programmer

#106

Post by m3kw9 »

ham_burgers wrote: post #81
wyattk wrote: post #9

I want to take a moment to reflect on what a great community HN has. It never ceases to amaze me. The link is from the CS department at the University of Northern Iowa in Cedar Falls, IA. It sounds obscure, but that's my hometown. I grew up a couple blocks away from it. I sat in on classes there. I even know the author's family. That's small town Iowa, for ya. I never thought I would see anything related to that on h…

I work in the fast food industry, don't code, and I'm not even particularly interested in tech, but spend hours reading the articles and comments here.

Maybe you should start coding, you may actually like it too

Re: Chuck Moore, Extreme Programmer

#107

Post by virmundi »

HumanDrivenDev wrote: post #71
acjohnson55 wrote: post #46

> Moore also has a corollary called Do It Yourself!, which encourages you, in general, to write your own subroutines rather than import one a canned subroutine from a library. The other side of this coin is NIH Syndrome. I've seen that go wrong in all sorts of ways. One of the key skills of being a great engineer in the real world is exercising good judgment whether to "build or buy".

I think a degree of skepticism is required with NIH. I'm probably not going to roll my own crypto, or high performance statistical routines. But if something invented elsewhere "solves" a problem that really isn't rocket science, or if it's a framework - I will almost always avoid it.

out of curiosity, did you roll your own logging framework? When I read that point, logging came to mind. Should I use SLF4J, or simply print to out?

Re: Chuck Moore, Extreme Programmer

#108

Post by swyx »

ham_burgers wrote: post #81
wyattk wrote: post #9

I want to take a moment to reflect on what a great community HN has. It never ceases to amaze me. The link is from the CS department at the University of Northern Iowa in Cedar Falls, IA. It sounds obscure, but that's my hometown. I grew up a couple blocks away from it. I sat in on classes there. I even know the author's family. That's small town Iowa, for ya. I never thought I would see anything related to that on h…

I work in the fast food industry, don't code, and I'm not even particularly interested in tech, but spend hours reading the articles and comments here.

serious question, if you arent interested in tech, what interests you about the articles and comments?

Re: Chuck Moore, Extreme Programmer

#109

Post by swyx »

erikb wrote: post #50
acjohnson55 wrote: post #46

> Moore also has a corollary called Do It Yourself!, which encourages you, in general, to write your own subroutines rather than import one a canned subroutine from a library. The other side of this coin is NIH Syndrome. I've seen that go wrong in all sorts of ways. One of the key skills of being a great engineer in the real world is exercising good judgment whether to "build or buy".

The steps of learning . Beginner: Learn the basics, be proud of getting something done that works, even though it might not be a useful result. Experienced: Learn the systems. Figure out which system is more helpful than others. But don't worry too much before you start learning a new system. Even a "bad" system will teach you something valuable. In the end you need to learn far more than one system anyways to progre…

how many levels of abstraction can you name? i think that would be a useful exercise.

Re: Chuck Moore, Extreme Programmer

#110

Post by ruricolist »

derefr wrote: post #32
teddyh wrote: post #7

Quote from ( http://www.ultratechnology.com/1xforth.htm ): “ I wish I knew what to tell you that would lead you to write good Forth. I can demonstrate. I have demonstrated in the past, ad nauseam, applications where I can reduce the amount of code by 90% percent and in some cases 99%. It can be done, but in a case by case basis. The general principle still eludes me. ”

I'm not surprised that the general principle that helps Moore reduce his code size eludes him. Authoring something blinds you to your own style—both to your mistakes, and to your brilliances. It's why prose writers can't be their own editors: you need someone who wasn't in your head during the writing process to actually be able to see what's ended up on the page, rather than just seeing reminders that immerse you ba…

You certainly can be your own editor, but you have to wait a few years between the writing and the editing.
Post reply on HN