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

91–100 of 186 posts

Re: Chuck Moore, Extreme Programmer

#91

Post by throwaway7645 »

HumanDrivenDev wrote: post #69
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…

> It reminds me of this quote: "The problem with object-oriented languages is they've got all this implicit environment that they carry around with them. You wanted a banana but what you got was a gorilla holding the banana and the entire jungle." - Joe Armstrong What Joe Armstrong (who I admire) complains about is actually what I love about OO languages. And for me that's the true essence of what OO is, and how it d…

I'd love to see if in 50 years we're closer to Smalltalk, Haskell, or something completely different. I'd love to say something radically different, but I have a feeling static types will continue to increase in popularity. No real evidence, just a gut feeling. Thanks for posting your feeling on OO. In some ways I've always felt very restricted writing OO (even in Python), but learning Smalltalk is making me see it from an entirely different perspective.

Re: Chuck Moore, Extreme Programmer

#92

Post by arthur_pryor »

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.

that's definitely the sort of thing i like about this place. i'd imagine programmers are very very heavily represented here, but it's nice that it's not to the exclusion of everyone else.

Re: Chuck Moore, Extreme Programmer

#93

Post by throwaway7645 »

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…

I'm a big Chuck fan, but I get the feeling that he isn't on a short deadline to build some standard business app like 90% of coders where you almost have a template...sure it has lots of code you don't need and to paraphrase Rich Hickey, it isn't simple, but it's really easy (at least in the short run). He's doing things where he is allotted the time to really understand the problem and deliver a minimal solution. Listening to his interviews make me sad as they call up images for how programming could be if we'd gone about it differently. Small teams writing small and efficient software where you can grok the entire thing at once.

Re: Chuck Moore, Extreme Programmer

#94

Post by HumanDrivenDev »

throwaway7645 wrote: post #91
HumanDrivenDev wrote: post #69

Earlier quoted context omitted.

> It reminds me of this quote: "The problem with object-oriented languages is they've got all this implicit environment that they carry around with them. You wanted a banana but what you got was a gorilla holding the banana and the entire jungle." - Joe Armstrong What Joe Armstrong (who I admire) complains about is actually what I love about OO languages. And for me that's the true essence of what OO is, and how it d…

I'd love to see if in 50 years we're closer to Smalltalk, Haskell, or something completely different. I'd love to say something radically different, but I have a feeling static types will continue to increase in popularity. No real evidence, just a gut feeling. Thanks for posting your feeling on OO. In some ways I've always felt very restricted writing OO (even in Python), but learning Smalltalk is making me see it f…

> I'd love to see if in 50 years we're closer to Smalltalk, Haskell, or something completely different.

I guess in my mind FP and OO are orthogonal. If I write an immutable object and I send it messages that are referentially transparent, am I not doing both? Would it help FP people if they thought of such objects as "a record of partially applied functions"? So I hope both. I'd love if there was a statically typed, high level pure OO language without all the cruft of Scala or C#. Maybe I have to wait for the next programming fashion cycle for that to happen.

> Thanks for posting your feeling on OO. In some ways I've always felt very restricted writing OO (even in Python), but learning Smalltalk is making me see it from an entirely different perspective.

I often wonder if I need to coin a better term for "OO" for what I am talking about. Alan Kays whole schtick was that objects contained both data and procedures, but by combining them they became something new, and more than just the sum of their parts. That's the powerful idea to me. But language changes, and OO in 2017 just means "Java".

Re: Chuck Moore, Extreme Programmer

#95

Post by throwaway7645 »

hoosieree wrote: post #84
derefr wrote: post #36

Earlier quoted context omitted.

I feel like a desire to program in Forth is more the consequence of being a crazy-in-the-good-way programmer, rather than something that aids in becoming that sort of programmer. Moore, from my perspective, decided to bootstrap a computing architecture from as primitive and restrictive of a starting place as he could come up with. Forth makes sense as a language if you imagine yourself as a time-traveller stranded in…

The "stranded time traveler" explanation explains a lot, actually. Including motive.

I also really liked that analogy.

Re: Chuck Moore, Extreme Programmer

#96

Post by kevin_thibedeau »

com2kid wrote: post #21
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…

> 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 program, which was no more than 1-2MB in size. That might have been more to do with how hard publishing code to the web was back then, an internal p…

It has always been possible. Sysinternals was doing it 20 years ago. The catch is you had to build with Win32 and not the framework du jour.

Re: Chuck Moore, Extreme Programmer

#97

Post by fasquoika »

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…

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). By using local variables you essentially turn a procedure into a monolithic block

Re: Chuck Moore, Extreme Programmer

#98

Post by hoosieree »

rvense wrote: post #60
carapace wrote: post #4

Legend has it Chuck Moore had a 3D wire-frame CAD program he used to carry around as a punch-card deck in his shirt pocket.

I've heard he just types it in from memory when he needs it.

Not from memory: from scratch, every time. Adapted to the problem at hand and not carrying unnecessary baggage.

Re: Chuck Moore, Extreme Programmer

#99

Post by mikekchar »

throwaway7645 wrote: post #93
derefr wrote: post #32

Earlier quoted context omitted.

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…

I'm a big Chuck fan, but I get the feeling that he isn't on a short deadline to build some standard business app like 90% of coders where you almost have a template...sure it has lots of code you don't need and to paraphrase Rich Hickey, it isn't simple, but it's really easy (at least in the short run). He's doing things where he is allotted the time to really understand the problem and deliver a minimal solution. Li…

Chuck Moore was amazing before I even knew how to code (and was a big inspiration for me), so I'm not going to even pretend that I know how to do what he does. However my view of this is that we, as programmers, can't just look at our jobs from a technical perspective. Nobody is given the time to make great solutions. The best programmers know how to work so that they can get the time they need. This is not trivial.

You can't just wander up to management and say, "I need X to make an optimal solution". They will negotiate you down. That's their job -- to negotiate into a position of advantage. When you need protection from the chaos that surrounds the rest of the organisation, you can count your lucky stars when you have an expert negotiator on your team. But when you go up to that expert negotiator and say, "I want X", the first thing that's going to go through their minds is, "I wonder if I can get that cheaper".

So programming has to be a balancing act of constantly delivering functionality while at the same time ruthlessly refining your vision of how it's going to work. If you are delivering quickly, regularly and constantly nobody will touch you for fear of screwing it all up. But knowing how to do that while still marching inevitably closer to simpler and simpler solutions is hard. A normal person needs to practice (and get it wrong) a long time before they get good at it.

Chuck describes a lot of his techniques in his books, but it's fluency that you need -- and it's fluency while things are hitting the proverbial fan that makes all the difference. You need great judgement to look at what you need and to prioritise it appropriately. If I deliver X quickly, I'll show progress. Do I need to show progress now? How fast? Can I refactor Y while I'm here? Is all of this necessary? And so on and so on.

It's tempting to think, "If only I was given lots of time.", "If only I didn't have incompetent coworkers", "If only people would listen to my advice", "If only management could look past tomorrow"... But that's not useful. Anybody can be a great programmer if we remove every problem before they start. The measure of your worth is how many of these complicating factors you can deal with while still producing great code. That's what's rare.

Re: Chuck Moore, Extreme Programmer

#100

Post by dewster »

fasquoika wrote: post #97
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…

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.
Post reply on HN