Live data from Hacker News

History of Logo

escholarship.org

31–40 of 89 posts

Re: History of Logo

#32
post #6

Logo was a hard pill to swallow in the 1980's. It had some neat features 'on paper' but it was hard to appreciate them because it was agonizingly slow on the computers of the day. It was the first programming experience I ever had where I'd type in my function, and then had to wait a while for the computer to do something to it (it never used the word "compiler"), and then it could run. I remember thinking: this make…

I honestly can't think of anything more "missing the entire point" of a language like Logo than "I could write in assembler faster...".

Re: History of Logo

#33
post #32
post #6

Logo was a hard pill to swallow in the 1980's. It had some neat features 'on paper' but it was hard to appreciate them because it was agonizingly slow on the computers of the day. It was the first programming experience I ever had where I'd type in my function, and then had to wait a while for the computer to do something to it (it never used the word "compiler"), and then it could run. I remember thinking: this make…

I honestly can't think of anything more "missing the entire point" of a language like Logo than "I could write in assembler faster...".

Why? 8-bit assembler was simpler and easier to learn than most programming languages. It kinda had to be, given the constraints on CPU's at the time. (And drawing text or graphics was simply a matter of setting values in a memory-mapped frame buffer. Quite trivial, overall.)

Re: History of Logo

#34
This was an interesting read. I grew up with early personal computers of the eighties and in the geographic area described in the history, so a lot of it is nostalgic. At that time, programming on early home computers generally meant using BASIC (and maybe poke’ing some assembly code) before getting into “real” languages like pascal, Fortran and c in college. I remember thinking logo was a ‘baby’ language and only for kids—-it wasn’t until later on I appreciated some of its features and it’s ties to lisp.

Programming languages like REBOL (or the modern variant Red http://www.red-Lang.org) seem to build on many of the same ideas.

Re: History of Logo

#35

Earlier quoted context omitted.

On one hand, Lazarus and Free Pascal are great so it is nice to see it being used as an introduction to programming. On the other hand... Lazarus is way too complicated for someone's first foray into programming, IMO. The IDE throws at you a barrage of windows, buttons, lists, etc that can be almost as overwhelming as an airplane's cockpit :-P. I always maintained that Free Pascal should either ditch the text mode ID…

> I always maintained that Free Pascal should either ditch the text mode IDE Why not fix the bugs instead? And it shouldn't look weird to anyone who has used TUI programs. In fact, we really should have support for these TUI features (stackable text windows, mouse-controlled menubar and widgets, context-sensitive status-bar) right inside emacs, or some other generic editor. They have stood the test of time wrt. intui…

For the other reasons besides the bugs. I have used the text mode IDE a lot to write smaller programs and it is always a PITA (just not enough of a PITA to open Lazarus, create a brand new project, etc). And some of that is outside FP's control, like Linux terminal emulators being universally broken when it comes to complex shortcut keys that involve function keys and modifiers. Add to that the the Windows console window now also tries to behave more like a Linux terminal (though even before you still had to manually modify the shortcut to not create a 200 line buffer or whatever that causes the IDE to try and use all those lines as its 'screen' - which is especially annoying when it also decides to display a dialog, which is centered at that 'screen' and you have to scroll to see it, usually after pressing a few keys like Alt+F to open the menu and noticing that nothing happens) and you get even more issues.

Honestly the only environments where the FP seems to work (outside other bugs not related to the UI) is DOS and Linux's own console/terminal when running by itself without a window system.

In any case i submitted that message too quickly, that "either" part should have been followed with the alternative to keep it around as a fallback for the platforms where a GUI isn't available or in case someone wants it (though considering how broken it is, i doubt anyone is actually seriously using it).

Re: History of Logo

#36
post #32

Earlier quoted context omitted.

I honestly can't think of anything more "missing the entire point" of a language like Logo than "I could write in assembler faster...".

Why? 8-bit assembler was simpler and easier to learn than most programming languages. It kinda had to be, given the constraints on CPU's at the time. (And drawing text or graphics was simply a matter of setting values in a memory-mapped frame buffer. Quite trivial, overall.)

With all due respect, bullshit. Preface: I go back to the 70s in programming. I've done 8-bit on 8080/Z80, 68xx/68hc11, 8051, SMT8, 6502 and 2650. I've taught programming. Let's ignore the challenge of finding an assembler running on a common 8-bit home computer and getting it running and how much the early ones sucked. Let's ignore how little doco there was for those early 8-bits (no internet, remember). Let's ignore how user-hostile the debugging and error messages were. Was it easier to explain to a kid "repeat 4 [forward 50 right 50]" or a bunch of memory pokes and all the boilerplate required to get an assembly language program to do anything.

You're special, of course...I get it...superior in your own mind. But based on my own experience, for the vast majority of lesser humans by your measure, Logo is a lot easier than asm as an intro to programming.

Re: History of Logo

#37
post #23

There's a StrangeLoop talk about teaching programming by Felienne Hermans ( https://www.youtube.com/watch?v=g1ib43q3uXQ ) that claims that all fields have an "exploration vs instruction" debate on how to teach their field, but this debate is apparently absent from the field of programming for the most part, wherein the "mess around and figure it out" exploration style of LOGO and Papert ("every time you teach somethi…

OT, but Felienne has a great talk on functional programming in Excel (thanks for reminding me of her name): https://www.youtube.com/watch?v=0yKf8TrLUOw

This is worth watching even if you hate Excel and FP. It's a view of a different way of thinking. Good stuff.

Re: History of Logo

#38
post #3

LOGO changed my life! When I learned it as a kid, it made me realize that software was "castles in the sky" and you could do anything you want. 41 years later and a career programmer, I'm now using Lisp in our most modern product. :-) I'll always be grateful to Papert for his work in creating and teaching LOGO.

You aren't the only person I've met who can draw a line from Logo through Lisp to a successful career.

Re: History of Logo

#39
post #36

Earlier quoted context omitted.

Why? 8-bit assembler was simpler and easier to learn than most programming languages. It kinda had to be, given the constraints on CPU's at the time. (And drawing text or graphics was simply a matter of setting values in a memory-mapped frame buffer. Quite trivial, overall.)

With all due respect, bullshit. Preface: I go back to the 70s in programming. I've done 8-bit on 8080/Z80, 68xx/68hc11, 8051, SMT8, 6502 and 2650. I've taught programming. Let's ignore the challenge of finding an assembler running on a common 8-bit home computer and getting it running and how much the early ones sucked. Let's ignore how little doco there was for those early 8-bits (no internet, remember). Let's ignor…

> Was it easier to explain to a kid "repeat 4 [forward 50 right 50]" or a bunch of memory pokes and all the boilerplate required to get an assembly language program to do anything.

One would think that there's a useful middle ground. My favorite approach would be a FORTHy, postfix-based language where you'd write something like [|50 fd 90 rt] 4 repeat. Something like that would be comparatively easy to implement using a threaded-code approach on a 8-bit machine, which would provide an easy segue into lower-level, assembly programming.

Re: History of Logo

#40
post #36

Earlier quoted context omitted.

With all due respect, bullshit. Preface: I go back to the 70s in programming. I've done 8-bit on 8080/Z80, 68xx/68hc11, 8051, SMT8, 6502 and 2650. I've taught programming. Let's ignore the challenge of finding an assembler running on a common 8-bit home computer and getting it running and how much the early ones sucked. Let's ignore how little doco there was for those early 8-bits (no internet, remember). Let's ignor…

> Was it easier to explain to a kid "repeat 4 [forward 50 right 50]" or a bunch of memory pokes and all the boilerplate required to get an assembly language program to do anything. One would think that there's a useful middle ground. My favorite approach would be a FORTHy, postfix-based language where you'd write something like [|50 fd 90 rt] 4 repeat. Something like that would be comparatively easy to implement usin…

I think Logo is a useful middle ground for novice programmers. But by all means, if you want to do Forth, do Forth. Then you can have all the advantages of the Forth peanut gallery telling any kid that doesn't get Forth they're too stupid to understand computers and all the other toxic baggage that comes from that ecosystem.

Or you can teach a language that caters to programming novices and let them decide if they want to go down towards bare metal or up to more abstract languages or stick to apps like Excel because they really aren't cut out to be programmers.

I prefer the non-screw-you approach.

Post reply on HN