Live data from Hacker News

Chuck Moore, Extreme Programmer

cs.uni.edu

141–150 of 186 posts

Re: Chuck Moore, Extreme Programmer

#141

Earlier quoted context omitted.

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

No, but Forth provided one of the nicest, most immediate, and interactive environments to explore a problem. Instead of multiple files in a text editor, you build and test your app live and then dump it all to a text file. I have rarely had that experience with any other language except Smalltalk. I understand some Lisp environments act that way, but Forth was available places Lisp and Smalltalk were not.

>you build and test your app live and then dump it all to a text file

The Tcl shell is really great for doing this. Since everything can be represented as a string-type, you're able to introspect your defined procedures and dump them to disk.

Re: Chuck Moore, Extreme Programmer

#142

Earlier quoted context omitted.

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

Both. And under the hood, Forth implements a virtual stack machine on top of a non-stack machine, which is inefficient.

I guess I'm just trying to counter all the mythos and happy talk surrounding Forth and stack processing in general. In the end Forth is a highly (too?) simplistic language, a product of its time, and nothing all that special or powerful. It does a lot of stuff poorly and the code tends to write-only. The syntax is so loose that the entire dictionary has to be searched to know you're dealing with a number. It's no mystery that we aren't all coding on it now.

Re: Chuck Moore, Extreme Programmer

#143
post #21

Earlier quoted context omitted.

> 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.

wxWidgets has very low overhead. I think I have done some stuff that's also 1-2MB and much easier to code than plain Win32.

Re: Chuck Moore, Extreme Programmer

#144

> 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".

In the real world, anecdotally, my employers have always preferred to buy 160 hours of my time rather than share 480 hours of someone else's time with 1000 other customers. It may have been because that person is then 1/1000th as responsive to their specific needs. It also may have been because that person wasn't cleared, and paranoia requires their code to be vetted before allowing it within breathing distance of ou…

> I have never seen a company that makes it easy to buy a third-party license, and never a company that makes it easier to use a gratis licensed software than a paid one.

Meeting anecdote with anecdote, I've never worked at a company that made paying for licensed software easier than using gratis.

Re: Chuck Moore, Extreme Programmer

#145

Earlier quoted context omitted.

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.

It is true that traditional languages lump local variables and return information in the same stack. But the difference is only in the way this is handled by the program. In traditional languages the programmer has no idea how parameters are passed in the stack and the compiler does everything. In Forth this is made explicit, but on the other hand there are no formal parameters to worry about (notice that Forth can use local variables if you want, it is just not the idiomatic way).

Re: Chuck Moore, Extreme Programmer

#146
post #134

Earlier quoted context omitted.

Kdb (the weird line-noise functional programming language) is similar. The trial version is a 200KB binary.

Isn't Kdb the database you can program in Q now, but also has K the PL too? I program in J, which is similar. I don't consider it line noise, but I get the drift.

[edit] yes, KDB+ is the database product. Q is one interpreter that interops with it. K is another.

I am not 100% sure but I think Q is actually K plus a standard library of "Q words" so you can write K directly if you want.

I think the reason for Q is as a more familiar interface for people with SQL experience.

Re: Chuck Moore, Extreme Programmer

#147
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.

"I'm from Iowa. I only work in outer space."

Re: Chuck Moore, Extreme Programmer

#148

Earlier quoted context omitted.

> Forth is not powerful. It is ugly, stupid and mean. That's a statement of someone who doesn't understand Forth. Of course, one can write ugly code easily. Any language with raw power (Asm, C, Forth, Ada) needs a disciplined developer to get beautiful and maintainable code. Forth code can be really beautiful if the vocabulary is well thought out. I consider Forth the best choice for tiny iOT devices, Firmware, and o…

I've written a standalone Forth system that could boot from a floppy and recompile itself. I've ported the core interpreter to C so I could use libraries. I've rewritten it using various threading techniques. Up to that point it was just toy systems because i never did something useful with those. Then I rewrote a Forth interpreter than would play really nice with C. That thing right now is around 30k/3KSLOC. This ti…

Doesn't your latter post contradict your previous post? If Forth is not powerful how did you manage to do such things with Forth, and why did you stay so long with Forth despite its "ugliness" and "meanness"?

Re: Chuck Moore, Extreme Programmer

#149

Earlier quoted context omitted.

Kdb (the weird line-noise functional programming language) is similar. The trial version is a 200KB binary.

The author of Kdb is Arthur Whitney. He is another extreme programmer who has had a huge influence on fintech and made boat loads of cash I would presume.

Just want to say that it's awesome to see Rebol/Red and K mentioned in a comment thread about Chuck Moore.

It's interesting because Rebol and K have almost totally opposite philosophies about how software should be structured. K emphasizes flat namespaces and leans heavily on the primitives and only a handful of functions. Rebol encourages writing DSLs to fit the language to the problem.

But despite different philosophies, they both allow incredible programmer productivity. I think a lot of this productivity comes from adherence to "Do not speculate!" and therefore not having a bunch of non-useful functionality or boilerplate for the end-user programmer to have to manage.

Re: Chuck Moore, Extreme Programmer

#150
post #44

Earlier quoted context omitted.

Nobody equated that. The time when he made his is decades ago, so obviously nothing from those days compared to a modern EDA toolchain and associated bits and pieces. I think you subconsciously added the 'modern' in there somewhere and then argued against that.

You might actually be right. When I read this: > He wrote his own chip design software and analog simulator I immediately thought of a modern toolchain. Had I known that this was done decades ago, I might have reacted differently. Nonetheless, even decades ago, both Cadence and Synopsys likely had pretty advanced tools under development. I may be mistaken though.

Moore mentioned these in passing at the end if the link https://colorforth.github.io/1percent.html He was stressing the solution fits the problem. Not a solution which can cover/contain the problem
Post reply on HN