On Fri, Dec 21, 2007 at 09:29:47AM -0700, Levi Pearson wrote:
> Charles Curley <[EMAIL PROTECTED]> writes:
> >
> > I'm not familiar with Thinking Forth, but Starting Forth is an
> > excellent intro. The biggest problem is that there is no LeoForth, so
> > the code examples may or may not work on yo
Charles Curley <[EMAIL PROTECTED]> writes:
>
> I'm not familiar with Thinking Forth, but Starting Forth is an
> excellent intro. The biggest problem is that there is no LeoForth, so
> the code examples may or may not work on your flavor of Forth exactly
> as they are given in the book.
IIRC, the v
"Forth - The year in which your 6 month project is finally completed"
On Dec 20, 2007 10:10 PM, Charles Curley
<[EMAIL PROTECTED]> wrote:
> On Thu, Dec 20, 2007 at 07:19:12PM -0700, Levi Pearson wrote:
> > Charles Curley <[EMAIL PROTECTED]> writes:
> > >
> > > I don't, but try some of these. I h
On Thu, Dec 20, 2007 at 07:19:12PM -0700, Levi Pearson wrote:
> Charles Curley <[EMAIL PROTECTED]> writes:
> >
> > I don't, but try some of these. I haven't tried any, so I can't speak
> > to how good they are. These all run on top of an OS, where my version
> > is the OS.
> >
> > [EMAIL PROTECTED]
Charles Curley <[EMAIL PROTECTED]> writes:
>
> I don't, but try some of these. I haven't tried any, so I can't speak
> to how good they are. These all run on top of an OS, where my version
> is the OS.
>
> [EMAIL PROTECTED]:/var/spool/mqueue# apt-cache search forth | grep forth |
> sort
> gforth -
On Thu, Dec 20, 2007 at 11:30:25AM -0700, Justin Findlay wrote:
> On AD 2007 December 19 Wednesday 11:19:51 PM -0700, Charles Curley wrote:
> That sounds awesome. Do you have the source code online somewhere?
I don't, but try some of these. I haven't tried any, so I can't speak
to how good they
On 12/20/07, Kurt Griffiths <[EMAIL PROTECTED]> wrote:
> With that in mind, there is no denying that the overall complexity (and,
> therefore, tendency toward code entropy) goes up the bigger you system gets.
> Although languages like Ruby can certainly reduce the amount of lines you
> write, the l
One great advantage of modular programs (and really, any system
or product) is that you can offload the development and maintenance to other
people (preferably competent ones). You have to be careful with this,
however, because the more tightly coupled you are to other people's work,
the more commu
Wow. That sounds sweet. Having a domain-specific language can really help
when creating a sequence of rules. This is why scripting is so pervasive
in game engines. Can you imagine having to hard-code all the cut-scenes,
interaction logic, maps, etc? It sure beats a complex data model and/or lots
of
On AD 2007 December 19 Wednesday 11:19:51 PM -0700, Charles Curley wrote:
> On Wed, Dec 19, 2007 at 10:44:16AM -0700, Nathan Blackham wrote:
> 20 years ago, I had a compiler, interpreter, operating system, and
> maybe an assembler, all in 8 Kb. 12 Kb on 32 bit processors. It ran in
> as little as 1
Kurt, I completely agree. After reading the whole article, I find that
his argument that large codebases are /inherently/ bad is a weak one.
I'd like to comment on two of his major points: a) Large codebases are
*unmanageable*, even by IDEs and b) Large codebases are *hard to learn*,
remember
On Dec 19, 2007 11:19 PM, Charles Curley
<[EMAIL PROTECTED]> wrote:
> 20 years ago, I had a compiler, interpreter, operating system, and
> maybe an assembler, all in 8 Kb. 12 Kb on 32 bit processors. It ran in
> as little as 16 Kb, but I preferred 24 Kb. I could port it to a new
> processor in a fe
On Wed, Dec 19, 2007 at 10:44:16AM -0700, Nathan Blackham wrote:
> Without futher ado:
> http://steve-yegge.blogspot.com/2007/12/codes-worst-enemy.html
Intersting. I'm not going to read the whole thing, but I do appreciate
his point.
20 years ago, I had a compiler, interpreter, operating system,
Dave Smith <[EMAIL PROTECTED]> writes:
> At my company, we're using QSA (EcmaScript) extensively for run-time
> macro execution and it's great. The guy who architected our QSA stuff
> is a long-time Scheme lover, and his QSA code reflects it. It looks
> fantastic. It has very little boiler plate, a
Nathan wrote:
> Without futher ado:
> http://steve-yegge.blogspot.com/2007/12/codes-worst-enemy.html
Wow. That was a fun read, on par, dare I say, with Joel Spolsky before
he went into complete business mode. Some of the jabs against Java
programmers were a little below the belt, but nonethele
On Wed, December 19, 2007 2:54 pm, Dr. Scott S. Jones wrote:
> It is intriguing. Now all I want to know is when and where to find the game.
>
> I confess, I haven't read the entire blog contents.
>
> Scott
He has a link to it in the right sidebar of the blog, I think, but the server
isn't
respon
+++ Nicholas Leippe [19/12/07 12:58 -0700]:
> On Wednesday 19 December 2007, Nathan Blackham wrote:
> > This article was mentioned in the IRC channel. Remember that he is
> > describing a problem that can exist in any language. He isn't bashing a
> > given language other than to get his point acr
If you are trying to reduce the size of your code base and switching
languages simply isn't an option (for one reason or another), there are
several other areas you can focus on that can really help:
1. DRY
2. Relying on operating system services/libraries
3. Using 3rd-party components
4. Using co
On Wednesday 19 December 2007, Nathan Blackham wrote:
> This article was mentioned in the IRC channel. Remember that he is
> describing a problem that can exist in any language. He isn't bashing a
> given language other than to get his point across. I am not a big
> programmer, but I can underst
This article was mentioned in the IRC channel. Remember that he is
describing a problem that can exist in any language. He isn't bashing a
given language other than to get his point across. I am not a big
programmer, but I can understand his argument and is something I think every
programmer sho
20 matches
Mail list logo
