> A data type check certainly doesn't guarantee you've got the "right
> stuff."
This was about stack effect, or correspondingly (in other languages)
making sure that the caller passed the right number of args to the
callee.
> I realize that programmers who have felt comforted by syntax/data type
> checking compilers feel a little naked getting used to Forth, but with
> a little experience you'll understand the Forth programming/testing
> cycle and feel more comfortable.
I've written enough C code in my life to appreciate the difference
between having to find the bug by examining the state of memory with
gdb, and having the Python (etc.) interpreter tell me "wrong number of
args at line 237, called from line 415", showing the source code at each
of those two lines. I see the mismatch, say "oops" and fix the code.
(# of args isn't a good example of this, since C checks that statically,
but you get the idea).
> "Elizabeth D. Rather" <erat...@forth.com> writes:
>> A data type check certainly doesn't guarantee you've got the "right
>> stuff."
> This was about stack effect, or correspondingly (in other languages)
> making sure that the caller passed the right number of args to the
> callee.
>> I realize that programmers who have felt comforted by syntax/data type
>> checking compilers feel a little naked getting used to Forth, but with
>> a little experience you'll understand the Forth programming/testing
>> cycle and feel more comfortable.
> I've written enough C code in my life to appreciate the difference
> between having to find the bug by examining the state of memory with
> gdb, and having the Python (etc.) interpreter tell me "wrong number of
> args at line 237, called from line 415", showing the source code at each
> of those two lines. I see the mismatch, say "oops" and fix the code.
> (# of args isn't a good example of this, since C checks that statically,
> but you get the idea).
One of my first Forth programs in my life was assert( .. )
which pretty much worked like Hayes T{ .. }.
I used to use assert( a lot in the beginning. Today my preferred way of coding critical code sections is still with paper, pencil, and rubber gum. :-)
On 05/10/2012 02:11, Paul Rubin wrote:
>> I try to make these modifications one little piece at a time, and then
>> test it, as well.
>
> OK, so you make a small modification and create a bug, which makes your
> test fail. What now? You have to figure out the cause of the bug.
> And, I think, this is much easier in a (runtime) type-checked and
> bounds-checked language, than something like Forth.
This is made easier by using a test file - see below
>
>> look at John Hayes ttester (in Gforth under test/ttester.fs;
>> require test/ttester.fs
>> : bounds ( addr len -- last first ) over + swap ;
>> t{ 3 5 bounds -> 8 3 }t
>
> Oh this is nice, and I didn't know about it. I'm going to start using it.
>
These were written for application program development rather than Forth system testing which was the original aim of the Hayes tester.
Like some others I routinely use a tester like this when writing a program larger than a few words that I intend to maintain and use. After all you only have to type a simple test once into a text file instead of continually typing the same thing when manually testing at the keyboard. Then just start the Forth up with a command line that includes the test file - a simple double click in an IDE.
If such a test program is continually added to during development, you have a regression test available when you've finished. This test program can then be provided with the program for users e.g. see files dstrings.fs and dstrings-test.fs at
www-personal.umich.edu/~williams/archive/forth/strings/
dstrings is a strings package with garbage collection - something you mentioned as being desirable.
> "Elizabeth D. Rather" <erat...@forth.com> writes:
>> A data type check certainly doesn't guarantee you've got the "right
>> stuff."
> This was about stack effect, or correspondingly (in other languages)
> making sure that the caller passed the right number of args to the
> callee.
Since DEPTH returns the number of things on the stack, you could test that. However, since the actual stack depth at any point is context-dependent (i.e., you never know which things on the stack are actually parameters for other words, not *this* one), that is strictly a early-stage debugging tool.
But this is why many systems (including SwiftForth, SwiftX, etc.) have stack-monitoring facilities. In early-stage testing, if you have a word that is misbehaving you can type your way through it or use a stepper and watch the stack behavior.
Such tools are "quality of implementation" issues, not language issues.
>> I realize that programmers who have felt comforted by syntax/data type
>> checking compilers feel a little naked getting used to Forth, but with
>> a little experience you'll understand the Forth programming/testing
>> cycle and feel more comfortable.
> I've written enough C code in my life to appreciate the difference
> between having to find the bug by examining the state of memory with
> gdb, and having the Python (etc.) interpreter tell me "wrong number of
> args at line 237, called from line 415", showing the source code at each
> of those two lines. I see the mismatch, say "oops" and fix the code.
> (# of args isn't a good example of this, since C checks that statically,
> but you get the idea).
Different Forths have different programming aids, as I said above. I suggest you evaluate several different systems as regards programming aids.
Cheers,
Elizabeth
-- ==================================================
Elizabeth D. Rather (US & Canada) 800-55-FORTH
FORTH Inc. +1 310.999.6784
5959 West Century Blvd. Suite 700
Los Angeles, CA 90045
http://www.forth.com
"Forth-based products and Services for real-time
applications since 1973."
==================================================
Paul Rubin <no.em...@nospam.invalid> writes:
>Bernd Paysan <bernd.pay...@gmx.de> writes:
>> 4 red arms
>> green cylinder body
>> 4 black wheels
>> Is this a data structure or a program? I don't know, I don't care. To >> draw the robot, you have to interpret the data structure or to execute >> the program.
>I'd rather that it be data since then I can write code to interpret the
>data in multiple ways, and it helps to be able to write data before
>starting to write code. E.g. in Python:
/oneforth {load exec} def
/oneword {drop sub scalefactor div} def
%select none by default, later change one event and one forth from default
/event0x0041008D@0 {drop} def
/event0x0041008E@1 {drop} def
/event0x00410000@0x40000000 {drop} def
/event0x00410000@0x40000001 {drop} def
/tsc {drop} def
/event0x004100C0 {drop} def
/event0x004100C4 {drop} def
/event0x004100C5 {drop} def
...
<< /results {core2} /event0x00410000@0x40000000 {} >> bars
This selects the event0x00410000@0x40000000 records from the data and
draws a set of bars (for a bar chart). I guess I had to write _and
debug_ all these event* procedures before running the program
successfully. So what. The actual work was elsewhere.
These three steps are actually the evolution of how I write these
charts. The main driver here was to minimize the manual work for
integrating the data coming out of my measurement scripts into the
charts.
>If I'm supposed to implement such stuff myself, why do I want your
>toolkit in the first place? Obviously as a FOSS user I want to be able
>to extend the toolkit as a last resort, and obviously in the first
>releases of a toolkit, the important use cases haven't necessarily been
>identified. But after a few iterations I'd expect the toolkit to do
>pretty much everything needed, and modularity makes me not want to
>maintain my own fork if I can help it.
Yes, Knuth expected users to do their own forks of TeX for specialized
purposes, but this has not really happened, even though there is no
evolution of TeX to speak of (so merging changes back into the fork
would not have been an issue). People just don't want to much with
the internals of an existing program.
OTOH, the success of applications that support scripting and add-ons
shows that, no, you cannot expect a program to do everything that's
needed out of the box, even after a few iterations. So people are
willing to program extensions given a defined interface (e.g., various
packages on top of TeX, such as LaTeX, instead of a fork of TeX).
>OK, so you make a small modification and create a bug, which makes your
>test fail. What now? You have to figure out the cause of the bug.
>And, I think, this is much easier in a (runtime) type-checked and
>bounds-checked language, than something like Forth.
For a small modification, the bug is usually obvious. How can
something else be easier.
Debugging Forth code is usually easy in my experience, certainly for
things that would be caught by a type or bounds checker. But maybe it
takes experience to write programs such that such bugs are easy to
find.
>> If you haven't found Forth strings, arrays, hash tables, etc., by now, >> it's because you were looking at an embedded Forth, where all these >> features just don't fit.
>I'm using gforth and I didn't notice any of that in the manual.
Bernd Paysan <bernd.pay...@gmx.de> writes:
>Anton Ertl wrote:
>> I think that we probably would not have them if HTML had not become
>> way more complicated than HTML 2.0.
>People are notoriously bad at abstractions. They want WYSIWYG.
>Therefore, these alternative markup languages provide features that a >bulleted list looks like
>* item a
>* item b
>and an enumerated list is
>1. first item
>2. second item
>and the syntax for headline is
>headline
>========
>or
>headline level 2
>----------------
>This sort of type-writer markup seems to be pretty easy to grasp.
I don't find this easier than LaTeX or HTML, and in the end you need
some more "abstract" markup after all, e.g., for links. The wide use
of the HTML-like BBcode also supports my view.
>Yes, showing where you made a mistake is a good idea. But people are >much better at these visual markups, they do produce correct code much >more likely, because correct code is visually pleseant there. Incorrect >code isn't. That *does* matter.
My experience is that at some point visual pleasantness breaks down
and becomes hard to maintain. E.g., links, or comments. So now you
have a language that appears easy at first, and breaks down later.
>The lession I learned from both LaTeX and HTML is:
>* the content is in a free-form markup, i.e. you need to be flexible how >to parse your markup (one single markup notation won't do it)
Anton Ertl wrote:
>>This sort of type-writer markup seems to be pretty easy to grasp.
> I don't find this easier than LaTeX or HTML, and in the end you need
> some more "abstract" markup after all, e.g., for links. The wide use
> of the HTML-like BBcode also supports my view.
IMHO the motivation for BBcode is to make it easy to transform into HTML. The motivations for the other, more visual codes which are also widely used (like the Wikipedia syntax) is to make it easier.
"more abstract" markup uses more difficult constructs, of course.
Though I consider [url|name] as less cumbersome than <a href="url">name</a>. The only problem there is with the [url|name] notation is that some systems actually have a [name|url] syntax ;-).
> My experience is that at some point visual pleasantness breaks down
> and becomes hard to maintain. E.g., links, or comments. So now you
> have a language that appears easy at first, and breaks down later.
So your suggestion is to make everything hard to maintain, not just the difficult parts? If I would add comments to such a language, I would use skip-to-eol comments, and use one of the common EOL comments like %, # or //, which people are familiar with.
>>The lession I learned from both LaTeX and HTML is:
>>* the content is in a free-form markup, i.e. you need to be flexible
>>how to parse your markup (one single markup notation won't do it)
> Your example above is everything but free-form.
What I want to say is that the content is *not* in a form mandated by the browser (which would be fixed-form, fixed to whatever form the browser accepts), but one mandated by the content-provider (or that framework). Having the browser provide a fixed parsing program is so obviously wrong when you look at the current web: Almost everybody who has user-generated content uses something else than HTML, even when it is relatively close like BBCode.
So you say "this is BBcode" and the browser fetches a BBcode parser and uses that to read your content. Or you say "This is a particular Wiki markup", and the browser uses that parser.
-- Bernd Paysan
"If you want it done right, you have to do it yourself"
http://bernd-paysan.de/
In article <6cd04453-c73a-4587-a160-0603784ef445@googlegroups.com>,
<theoriginalsn...@gmail.com> wrote:
>Hi Paul,
>> .. And don't you have to boot your PC in order to
>> start the terminal program before you can type to the Fignition board?
>FIGnition, unlike embedded MCU boards like Launchpad or Arduino, is a
>whole, self-contained computer with a keypad for programming and video
>output and boots straight into its programming environment.
>I thought it was obvious from the introductory paragraph on the
>FIGnition home page that with FIGnition you can code on its keypad,
>directly into the machine as you would with an early 80s micro.
Indeed, pretty unbelievable. It is beyond me they didn't spare a
5 pin mini DIN connector, so you can plug in a vintage keyboard.
Typical dump prices 1 or 2 euro's. Then of course you can
find them by the wayside.
(I've collected 5 IBM original's, so my stock should last 5 life times.)
>However, on reflection, perhaps it's not obvious enough for some people.
It was the first thing I looked for. Do I have to hook up a PC, and
where do I plug it in? But then I'm known for getting at the important
points fast.
> > the reality is that the end-to-end complexity is still the biggest
> > hurdle the kids have to face.
> Maybe you could say exactly what you mean by "end-to-end complexity".
> you're advocating dealing with it through a very simple > implementation.
Abstraction is great for usability, but not so helpful for understanding. For example, a light switch 'buttons-up' the complexity of the national grid, and it's known they're very easy to operate. But it doesn't mean that we teach electronics using a slightly more detailed version of the national grid. Instead we start with simple, but real, circuits that can be understood.
The problem is that this buttoning up never really works perfectly for two reasons: firstly there's an inevitable conflict between requirements, resources and their implementation. For example, the user-interface for a GPS system is more complex than for traditional map navigation and future needs to support, e.g. congestion re-routing or inter-car collaboration.
Secondly, it's not practical to wait for systems to be completely abstracted before we build on them - in reality there's a continual mix of technologies that expose their heritage at various levels.
But end-to-end complexity can be understood fairly easily. In the early 80s we'd turn on a computer and start coding within seconds. By the mid-80s simple compilers were in vogue so we coded using a edit-compile-run cycle with monolithic programs. Here, conventional tools exposed underlying requirements for performance at the expense of ease-of-development. By the late 80s OS's were becoming more complex and GUIs were being introduced; so there was a need for simple IDEs which supported the libraries and multi-file applications. Here, multi-file projects expose the implementation trade-off between compilation performance and project size requirements. Project development again became more complex.
In the 90s raw APIs were 'buttoned-up' behind OO-frameworks, but today development environments such as Eclipse expect even newbies to handle multiple targets, sdks, simulators, mixed-language project implementations across objective-C/Javascript boundaries; mandatory source control and a plethora of cloud-hosted client-server scripting paradigms.
We can button-up this complexity for users, they just click on an Appstore and suddenly Augmented Reality is at their fingertips. But in the same way we don't teach electronics by diving into the national grid (or a simplified virtual national grid), it doesn't mean the best way is to teach using either fake programming paradigms (e.g. KODU or Scratch) or full-on environments where they just stitch stuff they don't understand together in ways they don't really understand.
You see this in practice, e.g. the previous poster who was shocked that GRADUATES don't understand how computers actually work as it's someone else's problem. But also in the way you don't really want to deceive kids with fake programming.
A good example was Young Rewired State in Birmingham a month or so ago. One of the finalists (a reasonably bright student) had created a Scratch-based app, but you could see that as he stood up he was basically embarrassed about it.
> Geany is a fancy IDE sort of like Eclipse.. handles multiple languages
> .. people just
> getting started should probably consider alternatives, so I mentioned
> Geany.
Indeed, it doesn't get much simpler than Eclipse ;-)
> Python is a language, not a complete environment.
True, it's hard to cram anything better than a crude CLI into 860Kb.
> The CPython distribution does come with an IDE
Hmmm, yes at 23Mb it might just be possible!
> it's less powerful than fancier ones like Geany.
Understandable, it's only 23Mb.
> I've never personally used LOGO but I know it's gotten some traction for
> teaching little kids.
Logo's smart; about as powerful as Lisp, but with a friendlier syntax. It's not totally general purpose, which is probably why it didn't replace Basic, but it is pretty good.
> How many kids today do you think are coding in Minecraft, compared with
> "early 80s systems"?
I really don't know. I do know that about 10 to 20x fewer kids can code at all compared with the mid-80s, despite the far greater numbers of available computers so I guess either it isn't that transferable or Minecraft 'coding' is more like HTML or something.
> Another theory ..in the early 80's the only thing [kids]
> could really do with them was code, and today there's far more
> possibilities.
I think there's some truth in that, though there were plenty of non-programming electronic toys in the day. It's certainly true there's far more distractions on modern systems - it's always far easier to not code than to code for all of us, but the complexity of modern systems (including modern coding systems) plays a huge part from personal experience.
> > I thought it was obvious.. with FIGnition you can code on its keypad
> No, that's not mentioned.
I meant, I now realise it's not obvious, it'll get changed.
> ..It frankly sounds nuts
Surprisingly, it's not though, it's faster than texting and as fast as typing on a touch-screen :-)
> I don't know if modern TV sets.. still have composite video input.
Pretty much all of them still have composite (sometimes multiple inputs) and/or SCART.
> You know, that Atmega part in the Fignition purports to be an 8-bit
> micro that's sort of a modernized 6502, but how do you know it's not
> really a much faster x86 core, running firmware that emulates the AVR
> instruction set, eh? ;-)
Because people have decapsulated AtMega168s and the functional units can be easily seen. But you'd be able to figure it out anyway from the outrageous power consumption; ns-level timing inaccuracies; parts cost (Atmel would probably go bust if they took that approach) etc. Like I'm arguing, almost nothing can be perfectly abstracted ;-)
> > Mark Wills <forthfr...@gmail.com> writes:
> > >Well, for youngsters, how about a cycle computer [...features
> > > suggested hardware...]
Yes, that'd be fun. It's a much more practical application than any 555 circuit, could be done with Forth and Arduino could do it pretty easily (you could do both, using AmForth). They can learn a lot about electronic design and could add their own features. Who cares if it's not a commercial solution - it'll help them get out of the hyper-consumerist ethos!
Being inspired in these terms, is all about being able to see that your only choice isn't just to buy prepackaged products.
On 06.10.2012 10:40, theoriginalsn...@gmail.com wrote:
> Hi Mark,
> Just looking at some other posts!
>>> Mark Wills <forthfr...@gmail.com> writes:
>>>> Well, for youngsters, how about a cycle computer [...features
>>>> suggested hardware...]
> Yes, that'd be fun. It's a much more practical application than any 555 circuit, could be done with Forth and Arduino could do it pretty easily (you could do both, using AmForth). They can learn a lot about electronic design and could add their own features. Who cares if it's not a commercial solution - it'll help them get out of the hyper-consumerist ethos!
> Being inspired in these terms, is all about being able to see that your only choice isn't just to buy prepackaged products.
> -cheers from julz
C'mon --- why on earth should kids learn Forth ???
They can spend their time way better to find their own place in this everchanging world.
The "target market" for Forth are not bicycle riding kids but technically oriented young students. For them you can crank up the complexity of a Forth demo, for instance a house photovoltaic battery charger or somesuch that is more useful than taping an Arduino board to a bike handle.
On Thursday, October 4, 2012 10:35:00 AM UTC+2, M.R.W Wills wrote:
> On Oct 4, 9:00 am, theoriginalsn...@gmail.com wrote:
> > Hi Paul,
> > > > The Microchip 23K640 is an 8-pin SPI Serial RAM chip
> > > Oh, interesting, SRAM (term used in the web page) usually means "static".
> > They're usually referred to as Serial SRAM chips.
> > > > which is run at 10MHz giving 0.9µs/byte read speeds
> > > Do you mean cycles per byte?
> > 9 cycles at 10MHz is 0.9µs. (9/10MHz = 0.9µs).
> > > > If I then start to learn to code using Firefox and
> > > > Javascript I'd head to the Tools menu which gives me 8 sub-options
> > > Sure, that's a terrible way to code. Try something like Geany with
> > > Python, or maybe Logo or something like that. I just mean it's easier
> > > to program with something that manages low-level details for you (such
> > > as memory allocation) more than Forth does.
> > Actually, you were claiming the complexity was hidden behind all the abstractions so coding is as easy as launching a browser. It's true that features like automatic memory allocation will help when coding, but the reality is that the end-to-end complexity is still the biggest hurdle the kids have to face. For example your alternative suggestions: Geany with Python / Logo etc illustrate my point. If all this complexity was truly hidden why would I want 'Geany' with Python? Surely Python would have hidden *all* the complexity and Geany would be unnecessary? Surely Python, given its size and level of abstraction, would be a better Logo than Logo?
> > The thing is that it must be our modern, complex systems that are the hurdle. Javascript used to be literally a menu-option away (View->Page Source, but now it's a sub-option), but kids just don't click it. I guess it's too much effort, but if they did, they'd be faced with a pretty hairy mass of script that'd put over 95% of them off. They don't then do a search for programming languages, find Python's already on their computer and drop down to a command line and then do another search to find tools to make its hostile interactive environment friendlier and then come across Geany or Logo or whatever.
> > > > They literally switched on a BBC micro and typed: 10 PRINT "I'm Fab!"
> > > > <return> RUN which, by any measure is less of a hurdle.
> > > You're complaining about the boot-up delay of modern pc's?
> > I think it's possible to see, given the context and the fact I didn't mention PC boot-up times, I'm talking about the overall, end-to-end level of complexity. Long boot up times are just symptomatic and keeping systems on sleep allieviate this somewhat, but the hurdles are still there, compared with early 80s systems. And early 80s systems were brilliant at getting kids to code; at least 10 to 20 x more effective than any combination of languages and environments on modern systems.
> > One would think that given the 'friendliness' and level of programmer help (e.g. code completion, syntax highlighting, abstraction, managed memory etc) and wads of resources, languages and IDEs that every kid would be a coder today, (if that was the key factor) because all these things are much better than they were.
> > But, the one major thing that's different is the complexity. Machines today are 10,000 times more complex and this complexity does leak into every aspect of computing from modern browsers to development environments and languages. Is it possible that this is the primary reason they don't code?
> > > If I want to start a python environment (I use IDLE sometimes, a fairly
> > > primitive IDE)
> > Wasn't it Geany a few seconds ago?
> > > There are Forth environments like 4e4th that you can flash onto the
> > > Launchpad or Arduino,
> > Or AmForth.
> > > .. And don't you have to boot your PC in order to
> > > start the terminal program before you can type to the Fignition board?
> > FIGnition, unlike embedded MCU boards like Launchpad or Arduino, is a whole, self-contained computer with a keypad for programming and video output and boots straight into its programming environment.
> > I thought it was obvious from the introductory paragraph on the FIGnition home page that with FIGnition you can code on its keypad, directly into the machine as you would with an early 80s micro.
> > However, on reflection, perhaps it's not obvious enough for some people.
> > > Have you ever seen Minecraft? It's a scriptable game, and kids get
> > > fanatical about programming it. Code Hero is partly inspired by it.
> > Minecraft can also emulate a 6502 using only a million times the resources of the original processor ;-)
> > -cheers from julz
> In the 80's I was lucky enough to be surrounded by home computers in
> my home. We first got a TI-99/4A, then a ZX spectrum, then a Commodore
> 64. Then an Amiga. At one point, we had a Spectrum, a C64, and an
> Amiga 500 all at the same time.
> With the execption of the Amiga, you could turn them on and be
> programming in BASIC in around 1 second. I trudge to the newsagents
> once a month and pick up Computer and Video Games (C&VG) and type in
> the listings that always promised to be awesome, but were actually
> kind of crap. Of course, they would be full of bugs, most type-setting
> errors, so much of that month would be spent trying fix the program
> that you spent 5 hours typing in. You learned to program. Okay, it was
> "just" BASIC, but you learned to program. It was completely
> fascinating - getting the computer to do what you wanted it to do.
> I contrast that with my own son. He has been surrounded by PC's,
> Laptops, Mobile 'phones, Playstations, Wii's and Xbox's. We've had
> them all over the years.
> He's never once shown even the slightest interest in programming. He
> never once asked me how these games worked. I find it a little
> strange. When I saw games like Manic Miner on the spectrum, I was
> desperate to know *how* they worked. Sure, I enjoyed playing them, but
> *I* want to do that too!
> Last year, I showed him Forth. I was pretty jazzed that he understood
> it. He understood the stack, he understood why + comes after two
> numbers, and he 'got' colon definitions the first time I showed him. I
> thought I had him. But no. He's not bothered with it since.
> I've concluded it's down to paradigm shifts, and when they enter your
> life: Perhaps a generation behind me, TV and Radio was the big
> paradigm shift. My parents remember when they got their first TV in
> the house. I *always* had a TV in my house, so TV and radio is very
> "meh" to me. TV and Radio was a big thing to them. A significant
> portion of the generation behind me are into HAM radio. My theory is
> this is because it became big just when they were at the right age to
> grab a hold of it. HAM radio is *their* 80's computers.
> A gneration behind them, radio in general was their "80's computers".
> They'd build crystal radio sets and it would often foster a life-long
> association with radio, many of them progressing to building their own
> valve radio sets, and perhaps having a career in electronics, just
> like we tinkered with 80's computers and had a career in computers.
> What is sad is, that I feel my children haven't really experienced any
> big paradigm shift that shape their lives. There's the internet, but
> they treat the internet like I treat TV: They grew up with it. It's
> nothing special. It's always been there.
> I worry for the graduate generation. WHen I worked at Serck Controls,
> we'd get graduates who didn't really know what went on inside a
> computer. They could program a little in Java. Maybe they wrote a Java
> applet (remember those) once. They didn't know much about processors,
> registers, assembly language.
> THat's okay. You can teach people this stuff. But the really worrying
> part is, they're just not that interested, thanks. I would ask them
> about "do you wonder how the Java compiler that you're using works? Or
> that C compiler?"
> "Nah. Fuck that. Someone else's problem".
> Someone else's *problem*. Sad.
> Who going to write the next generation of compilers? Will it become a
> more and more specialist 'art'/science?
> Another worrying thing: In my school in the 80's ('85/'86) we actually
> had a computer studies class. It was mandatory; part of the
> curriculum. We learned BBC basic and wrote simple little programs.
> That's all gone. My son recently studied how to make a CD label in his
> computer class. Whoop de fucking doo.
Hi Mark,
When I was 15 I asked my school if they could by me some bits to make a computer, but they had no idea what I was talking about. That was 1969 - I bought my first computer around 1982 - an Amstrad CPC64.
I do worry about young people these days being so gullible - the power of advertising seems to be strong - and I don't see much judgement or discretion being used, or curiosity about how things really work.
Two questions : do you write a Word document, or do you program it? Do you program in C# or write in C#?
"Programming" in the sense that it is used in the sorts of companies where I work, is less about problem solving and more about fighting the IDE. It follows the corporate structure - interfacing is
> Well, I was just responding to the initial post. Building your own computer *is* inspiring. It's also a Forth-based computer, which is what you want on this forum eh? Like proper computers it doesn't need an external host to do any programming with it. And it's very similar to an early 80s micro, using similar resources.
Perhaps, if I told I've got a linecard of my own FPGA-based Forth-processors, it makes things easier. It is not necessary to explain me all benefits of Forth in embedded systems. I just want to say that first imagination and 'Wow! -effect' are not enough to provide a valuable results. Simple projects could be a good quick-start for beginners, but they should be followed by more complex ones. So, we should think about teaching course, not about simple device without any specific functions.
> But the key thing *is* the simplicity, that's what makes it special; because only simple machines can be mastered and understood from end-to-end. How does it benefit kids if their only true experience of programming requires incomprehensible Giga-byte and GigaHertz, multi-core monstrosities? How would they ever grasp it, if even reading the code in the system would take many lifetimes?
> And how is it inspirational if every computer we experience is pre-packaged, surface-mount technology that requires a microscope to modify it? It's in some sense impressive, but what does that say about accessibility?
It looks like a mix with platform-independent basic principes (that's good!) and evaluation platforms, which targets a very simple applications. You should to choose, what you want to do - explain something (and you require a comprehensive hardware platform to demonstrate as many features as possible), or implement a low-cost high-volume device.
> Ultimately, we have to weigh up why kids aren't inspired to program today. Is it because computers aren't cheap enough (though even a netbook is 3x cheaper than a ZX Spectrum in today's money)? Or could it be something to do with them being 10,000 times more complex? Does FIGnition fit the STEM club criteria? (yes) Can you do a substantial amount of a GCSE computer studies on a FIGnition? (yes) Is FIGnition cute and fun? (you bet ;-) ) !
In this project, you are talking about a student lab. It requires about 1 hour to explain and implement this device, almost regardless of hardware platform. Also, check the 'rotary encoder' for properly debouncing scheme. Some kinds of these devices uses two optocoupled pairs, which makes a pulses consequently and at a different moments of time. So you simple should wait for second sensor after first and so on. Otherwise, you must filter the leading and trailing bounce sequences.
Finally, I can repeat that this application is too simple for inspiring anybody for a long time.
theoriginalsn...@gmail.com writes:
> For example, a light switch 'buttons-up' the complexity of the
> national grid, and it's known they're very easy to operate.
I like your light switch example, and it makes the same point as the
earlier examples I gave.
> there's an inevitable conflict between requirements, resources and
> their implementation. For example, the user-interface for a GPS system
> is more complex than for traditional map navigation
Really it's not. Just key in the address you want to travel to, versus
messing with map books, street-finder indexes, coordinate grids telling
you to jump from one page to another or buy another book, etc. Or
worse, in the nautical case: figuring out how to use a sextant and sight
tables and all that, plus it doesn't work if there is cloud cover.
> and future needs to support, e.g. congestion re-routing or inter-car
> collaboration.
Maps don't do that, the car GPS that I currently use doesn't either, and
it's very helpful regardless.
> But end-to-end complexity can be understood fairly easily. In the
> early 80s we'd turn on a computer and start coding within seconds.
Again you're talking about the boot delay while saying you're talking
about something different. If you get a regular PC to boot in 3-seconds
and auto-start an IDE, what have you lost? Maybe you could just do a
software image that boots a PC or a Raspberry Pi to your favorite IDE.
> multi-file projects expose the implementation trade-off between
> compilation performance and project size requirements.
It's not just compilation performance, it's also general modularity and
manageability of the code. There's no significant loading delay for
reasonable size Python programs but it's still helpful to separate stuff
into different files. But, maybe for initial teaching, this isn't
needed.
>development environments such as Eclipse expect even newbies to handle
>multiple targets, sdks, simulators, mixed-language project
I think this is sort of a Java and "enterprise" thing. I don't think
Java is a good language for beginning programmers.
> [Logo] didn't replace Basic, but it is pretty good.
Basic is pretty dead now, unless VB counts as Basic, and even VB is
pretty dead now, so something replaced Basic.
> I do know that about 10 to 20x fewer kids can code at all compared
> with the mid-80s,
Where on earth do you get numbers like that from?
One impression I do get is that the main app kids are interested in
coding these days is video games, so your product should be able to get
stuff moving on the screen.
> [8-button keypad] it's faster than texting and as fast as typing on a
> touch-screen :-)
Really, your thing will be a lot more usable with a USB host port that
can accept a normal PC keyboard.
We all seem to be assuming that kids don't program these days, unlike
the halcyon days of yore when computers had 8 bits, we made our own fun
and used the power of our imagination, we didn't have remote controls,
and there was this thing called discipline.
Are we really sure about this?
(Julz, how do you know that 80s computers were '10-20x more effective at
getting kids to code' ?)
I mean, it seems to me thinking back on it that in my experience it was
uncommon for kids to program in any way whatsoever, and very rare for
them to get beyond simple BASIC or LOGO programs. I never really got
beyond very rudimentary programs, and I'm fairly certain there was
no-one in my year at school who did much more than that, and moderately
sure there was no-one in the years either side of me. Later on I met
people my age who had gotten into programming in a big way as kids or
teenagers, so sure they existed, but I'd put the number at well shy of
1%.
(I see your ancedotes, and i raise you mine)
Maybe rather than something being wrong with either computers or kids
these days, it's just the case that programming is something that
doesn't really interest most kids, never has, probably never will, and
people with the inclination to be real hackers are pretty rare, and,
unsprisingly, well over-represented in this newsgroup.
That's not to say I don't think it couldn't be presented in a way that
would make it more approachable or fun for kids, or whatever, but I
don't think it was really all that approachable or fun (for most kids)
back in the day. Those that did anything beyond the rudimentary were
those few that found it innately interesting and natural.
The one thing I think maybe made it more attractive to program back then
was the fact that the games and even applications available to you were
not actually all that sophisticated, so it was easier to see yourself as
footing it with commercial programs.
an...@mips.complang.tuwien.ac.at (Anton Ertl) writes:
>> {'name':'Paul','languages':['Python','Forth']}
> This reminds me of what I do with data in charts written in Postscript.
> In simple cases, the data is interpreted directly and drawn right away:
I couldn't follow the Postscript code details but I get the general
idea. It still goes against the usual wisdom that once you figure out
your program's data structures, the code takes care of itself.
Another issue is that Lisp and Python-like languages not only have a
convenient syntax for reading those structures, they can also print them
in a way they can read them back in. So you can easily compute data and
dump it out for later re-import. This is very convenient for fast
interactive development.
> OTOH, the success of applications that support scripting and add-ons
> shows that, no, you cannot expect a program to do everything that's
> needed out of the box, even after a few iterations.
I would say here, the toolkit is script interpreter and the stuff
exported to the scripting language, and the application is the user
script. So it's pretty usual in the iterative development of such
frameworks that in early versions, the script system can't quite do what
you want and you have to mess with the internals, such as to export new
functions that scripts can use. But eventually the scripting level
becomes pretty powerful. This happened with Emacs, with browsers, etc.
> Debugging Forth code is usually easy in my experience, certainly for
> things that would be caught by a type or bounds checker. But maybe it
> takes experience to write programs such that such bugs are easy to
> find.
It's well known that such bugs are a perennial drain on development time
and source of exploits in in C and C++ programs. I'm interested to know
if Forth somehow avoids these problems where C and C++ fail. The rest
of the development world dealt with it mostly by migrating to type-safe
and GC'd languages.
Paul Rubin wrote:
>> Debugging Forth code is usually easy in my experience, certainly for
>> things that would be caught by a type or bounds checker. But maybe
>> it takes experience to write programs such that such bugs are easy to
>> find.
> It's well known that such bugs are a perennial drain on development
> time and source of exploits in in C and C++ programs. I'm interested
> to know if Forth somehow avoids these problems where C and C++ fail. > The rest of the development world dealt with it mostly by migrating to
> type-safe and GC'd languages.
We had that discussion a while ago, stdlib strings are broken by design (and even though people here argue that zero-terminated strings in C are "optional", people learn this broken string functions when they learn C).
The solution for this problem is to have string buffers growing and shrinking with the string. This doesn't require full GC and type-safe stuff, it only requires resize() of malloc-ed blocks.
The little string words I use for that in Gforth are documented, though only in the current development branch. I've used them quite often, and I never had any sort of buffer overflow or alike with them.
I think Forth program development differs in two important ways from C:
* We don't write big chunks of code and then test them. This is done in C, because compiling takes long, and to debug stuff you need to write a debug harness etc.; in Forth we change little things and test immediately.
* We extend the programming language to provide what's missing. C people use libraries and stick to their libraries even if there are serious flaws.
-- Bernd Paysan
"If you want it done right, you have to do it yourself"
http://bernd-paysan.de/
Bernd Paysan <bernd.pay...@gmx.de> writes:
>>> things that would be caught by a type or bounds checker....
>> I'm interested to know if Forth somehow avoids these problems where C
>> and C++ fail. > We had that discussion a while ago, stdlib strings are broken by design > (and even though people here argue that zero-terminated strings in C are > "optional", people learn this broken string functions when they learn C).
It's not just strings, it's every sort of array, in every language
except apparently for Forth. I guess Forth array users can always write
access functions that check bounds, and use those at least during
developent.
> The solution for this problem is to have string buffers growing and > shrinking with the string. This doesn't require full GC and type-safe > stuff, it only requires resize() of malloc-ed blocks.
C++ STL strings and vectors do this growing and shrinking, and are
somewhat less vulnerable to these hazards than C stdlib strings, but you
still have memory leaks and double-free errors to deal with.
> The little string words I use for that in Gforth are documented, though > only in the current development branch. I've used them quite often, and > I never had any sort of buffer overflow or alike with them.
Cool, I'll look for them.
> I think Forth program development differs in two important ways from C:
> * We don't write big chunks of code and then test them. This is done in > C, because compiling takes long, and to debug stuff you need to write a > debug harness etc.; in Forth we change little things and test > immediately.
I'm not sure how much this really helps: it handles immediate, localized
bugs, but not really bugs involving long-range interaction between
components.
I think Forth applications simply tend not to be of the type that uses
dynamic memory or even strings all that much. The typical profile might
be more like MISRA C. This is perfectly fine of course.
> * We extend the programming language to provide what's missing. C > people use libraries and stick to their libraries even if there are > serious flaws.
I'd say if the same stuff turns up missing again and again, it's time to
factor it into the library.
Paul Rubin wrote:
> It's not just strings, it's every sort of array, in every language
> except apparently for Forth. I guess Forth array users can always
> write access functions that check bounds, and use those at least
> during developent.
Hehe, the word goes "using bound checking during development is like using a parachute while still on ground". The development style is "crash early, crash often"; you might do your bould checking there and crash, but the application program should rather be robust.
The array function in my string package is auto-expanding the string array instead of crashing. This goes towards robustness, not towards crashing.
>> The solution for this problem is to have string buffers growing and
>> shrinking with the string. This doesn't require full GC and
>> type-safe stuff, it only requires resize() of malloc-ed blocks.
> C++ STL strings and vectors do this growing and shrinking, and are
> somewhat less vulnerable to these hazards than C stdlib strings, but
> you still have memory leaks and double-free errors to deal with.
That's why I only allow strings to live in global variables (or - when used within my OOP package - as instance variables of objects which know how to dispose themselfes).
>> I think Forth program development differs in two important ways from
>> C:
>> * We don't write big chunks of code and then test them. This is done
>> in C, because compiling takes long, and to debug stuff you need to
>> write a debug harness etc.; in Forth we change little things and test
>> immediately.
> I'm not sure how much this really helps: it handles immediate,
> localized bugs, but not really bugs involving long-range interaction
> between components.
When our programs have interactions between components, testing that is part of the testing.
> I think Forth applications simply tend not to be of the type that uses
> dynamic memory or even strings all that much. The typical profile
> might be more like MISRA C. This is perfectly fine of course.
Applications like MINOS certainly are not that common Forth applications.
>> * We extend the programming language to provide what's missing. C
>> people use libraries and stick to their libraries even if there are
>> serious flaws.
> I'd say if the same stuff turns up missing again and again, it's time
> to factor it into the library.
We do that, but our main problem is that we usually don't think the libraries others have created are any good.
-- Bernd Paysan
"If you want it done right, you have to do it yourself"
http://bernd-paysan.de/
Bernd Paysan <bernd.pay...@gmx.de> writes:
> Hehe, the word goes "using bound checking during development is like > using a parachute while still on ground".
Yeah, leaving bounds checks active all the time is probably best
practice in most applications.
>> you still have memory leaks and double-free errors to deal with.
> That's why I only allow strings to live in global variables (or - when > used within my OOP package - as instance variables of objects which know > how to dispose themselfes).
But now you've got the issue of leaking or double-freeing those objects.
If you've got complex, dynamic data structures, storage management is a
nontrivial issue.
>>> in Forth we change little things and test immediately. ...
> When our programs have interactions between components, testing that
> is part of the testing.
I guess I'm not seeing how this is different from C then. Code change
is not topologically continuous. Sure you can write a new component
bottom-up, but you can't really connect it up to other components til a
substantial amount of the new component is working, and maybe then you
find there you find an interaction problem you hadn't thought of in
advance. What then?
On Oct 8, 6:09 pm, Bernd Paysan <bernd.pay...@gmx.de> wrote:
> The array function in my string package is auto-expanding the string
> array instead of crashing. This goes towards robustness, not towards
> crashing.
No it doesn't. If it's *auto* expanding then it just hides an
undetected problem. You end up with a program that works fine for a
few hours on the lab bench, but crashes every three weeks in the
field. It goes towards crash later. And I can tell you, from bitter
experience, they are the hardest of all bugs to find, and often end up
never being solved:
"Hey, that plating controller is really great, saved us a lot of money
in copper sulphate solution, but it crashes every three weeks, and we
have to scrap whatever job is in the bath."
"Hmmm... Are you sure it's not some power spike? Is a large pump
nearby switching on or something like that?"
"Dunno. Could be. We're all scratching our heads here! But hey, it's
like only every three weeks or so..."
"Hmmm... Say, how's about we program it to do a reboot at the end of
each job?"
"Yeah. Great idea"
< six months later >
"How's the controller"
"Oh man! Solid as a rock! We just love it! Send us the bill. And
another controller while you're at it!"
"Great"
On Oct 9, 5:57 am, Paul Rubin <no.em...@nospam.invalid> wrote:
> Yeah, leaving bounds checks active all the time is probably best
> practice in most applications.
No. Testing the absolute living shit out of the application to prove
that a bounds error cannot happen is the way. Detecting a bounds error
is very nice in a spreadsheet, or an app to convert GIFs to JPGs or
whatever. It's not really much use on the rocket firing system on the
alignment correction system of a telecommunications satellite. Out of
bounds? Whoop de doo... You're still going to fall out of orbit!
On Oct 9, 5:57 am, Paul Rubin <no.em...@nospam.invalid> wrote:
> I guess I'm not seeing how this is different from C then. Code change
> is not topologically continuous. Sure you can write a new component
> bottom-up, but you can't really connect it up to other components til a
> substantial amount of the new component is working, and maybe then you
> find there you find an interaction problem you hadn't thought of in
> advance. What then?
You re-factor. You change the code.
You know these kind of high-brow discussions are quite entertaining.
They often make me chuckle to myself. Not so much here on CLF, but on
Java websites, or (all the time) in programming books we hear these
kind of every-day programming problems cited as major disasters.
Project Mangler: "Oh no! Johnny had to change the interface of his
object to take an unsingned int instead of an int. CALL THE MEDIA. OH
NASH NASH. WAIL WAIL. HOW WILL WE EVER RECOVER FROM THIS TERMINAL
ERROR? SOMEONE FIRE JOHNNY. HOW COULD HE BE SO STUPID... SEE? SEE?....
IF HE HAD ABSTRACTED THE INTERFACE FROM THE DEFINITION OF THE CLASS
THEN THIS WOULD NEVER HAVE HAPPENED... BUT NO... *NOBODY* LISTENS TO
ME. I TOLD YOU IT WOULD BE A DISASTER. I READ IT IN A BOOK. OH NO!
WE'RE REALLY SCREWED NOW. UP SHIT CREEK. *WE'LL HAVE TO RE-WRITE THE
ENTIRE APP*. OH MAN. I KNEW THIS WOULD HAPPEN..."
Johnny: "Er, it's okay guys. I did the change. Took like 15 mins. God
bless the object browser, eh?"
:-)
The truth is, if you know the app, you can change it. It really isn't
a big deal. Sure, there's a cost. The expense is in the re-testing,
not in the re-engineering.
Mark Wills wrote:
> On Oct 8, 6:09 pm, Bernd Paysan <bernd.pay...@gmx.de> wrote:
>> The array function in my string package is auto-expanding the string
>> array instead of crashing. This goes towards robustness, not towards
>> crashing.
> No it doesn't. If it's *auto* expanding then it just hides an
> undetected problem.
I honestly disagree. What should $+! do other than auto-expanding the destination string so it can add the requested string? Same with a string array, which you usually use by converting lines of a file into an array for random access.
Some of the auto-expanding code I wrote allow to expand one bit at a time, but not arbitrary writes into the void. This covers pretty well for what could be an undetected problem.
Having to expand deliberately and manually makes the use of such a package tedious at the expense of robustness.
> You end up with a program that works fine for a
> few hours on the lab bench, but crashes every three weeks in the
> field. It goes towards crash later. And I can tell you, from bitter
> experience, they are the hardest of all bugs to find, and often end up
> never being solved:
Sorry to say so, but if you don't print out a meaningful backtrace in case of a crash, you won't solve this sort of problems. Maybe yes, it only crashes every three weeks and the backtrace goes something like
out of memory error
$[]+!
some function calling that
etc.
So what do you do? Maybe you need to add a little clues in the backtrace, to show what actually happened, and let it run another 3 weeks to get there... or maybe it's already enough of a hint to show what's going wrong.
-- Bernd Paysan
"If you want it done right, you have to do it yourself"
http://bernd-paysan.de/
Mark Wills <forthfr...@gmail.com> writes:
> The truth is, if you know the app, you can change it. It really isn't
> a big deal. Sure, there's a cost. The expense is in the re-testing,
> not in the re-engineering.
Well, I was just in this situation with a C++ program. I added a
feature and that caused a double-free crash in another part of the
program. I "fixed" the crash but the fix left a memory leak, which also
had to be fixed. Detecting the memory leak required running the program
for a while, which I had to do several times to observe the leak and
test the fix, burning more time.
None of this was a big disaster--it was just a normal part of a day's
development. But with more civilized (i.e. GC'd) languages, this stuff
just doesn't happen in the first place. Programmers can then focus
their efforts more directly at producing visible end results.
If your testing expenses are that large (outside of critical systems),
it could be because too many bugs are getting through your development
process, and maybe you should re-examine your strategy.
