Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

How I coded in 1985

blog.jgc.org

Post reply on HN
Print view View original

101–110 of 120 posts

Re: How I coded in 1985

#101

Post by bricestacey »

buro9 wrote: post #22

Brain debugger. I honed mine early enough that the most I need from a program is a few Sprintf statements just to give the brain debugger some context when the application is dealing with external data or data transformation. I personally find it hard to turn off the brain debugger and rely on software. Originally this was because you'd very much be used to the debugger being wrong. As in, "Ah, but in this case the d…

In my experience this only works if the feedback cycle is quick. If working with a language like ruby or python and just refreshing webpages or running a script, no big deal. However, I then would have to wade through logger output to filter out the information I needed. I ultimately found I appreciated a debugger such as pry.

Then I started writing for Android and the time between compilation, installation, running the app, and then reproducing the scenario was too long and a debugger was a godsend.

Re: How I coded in 1985

#105

Post by robomartin »

kragen wrote: post #95
robomartin wrote: post #92

Earlier quoted context omitted.

Perhaps your last few words reveal the reason for the bugs? Forth --or any other language-- is hard to read only when someone doesn't know it or does not use it frequently enough. For example, I programmed in Lisp nearly every day for a couple of years. I could read Lisp without even thinking about it. That was fifteen years ago. Today I would struggle to make sense out of a non-trivial Lisp program for a couple of w…

All bugs can be traced to the programmer, of course. I find Forth error-prone because it's untyped (not even dynamically typed) and you have parameter-passing errors, where you pass a parameter or get a return value from the wrong place. Traditionally, too, you don't have local variables, but I think that's not actually nearly as big a problem as it sounds. That said, my last few words were exactly backward from what…

You are not looking at Forth correctly. It isn't C, C++ or Java. It's a "raw" language that you should use to write a DSL. It's just above assembler yet many orders of magnitude faster to develop with.

Even with your comment backwards it makes little sense. I have developed in nearly every language between typing raw machine code with a hex keypad and Objective-C (not to moly that O-C is at the opposite end of the scale). I did years of Forth. Not one thing you are saying rings true. If you know a language you speak it. It's as simple as that.

Re: How I coded in 1985

#106

Post by kamaal »

lake99 wrote: post #14

I did my bachelors (in India) in the mid-90s, and we all coded this way in our 8085 labs. Many of us even did final-year projects on similar-looking 8085 kits. Given that such kits are still sold [1] in India, I guess quite a few engineering students still learn to code like that. My bosses, though, had all worked on punched cards. [1]: http://www.dynalogindia.com/products/education-solutions/808...

>>Given that such kits are still sold [1] in India, I guess quite a few engineering students still learn to code like that.

Did my Bachelors(in India) in 2010's, and yes even we coded this way in our 8085 labs!!! Nothing has changed. Talked to my cousin who is now in his 3rd semester, They to start out coding the same way. Its 2013 and NOTHING has changed.

Re: How I coded in 1985

#107

Post by jacquesm »

greenyoda wrote: post #58
jacquesm wrote: post #45

Earlier quoted context omitted.

> Why did it all get so complicated? Two words: 'the web'. Slightly longer: we're re-inventing the wheel through a very roundabout path, I think right now we've gone back in time to roughly the mainframe area, it won't be long before someone will invent the mini computer all over again only this time it will be a local cluster in a box. Next after that the PC, a 'personal cluster' with a few 100 nodes the size of the…

I don't think it was the web. The pre-web applications with GUI clients running on PCs and servers on mainframes were already pretty complicated (remember Microsoft's ever-changing object APIs, or CORBA?). What made things increasingly complicated was the ever-growing power of computer and communication hardware, which made it possible to create larger and more complex systems. If you're limited by having to run your…

We were building clusters of PCs in the 1980's using arcnet. Those were pretty large and complex systems, they used a very elegant message passing protocol. And that definitely wasn't the only game in town for large and complex systems (but it was one of the most productive ways of constructing those systems with a small team).

Re: How I coded in 1985

#108

Post by jacquesm »

robomartin wrote: post #105
kragen wrote: post #95

Earlier quoted context omitted.

All bugs can be traced to the programmer, of course. I find Forth error-prone because it's untyped (not even dynamically typed) and you have parameter-passing errors, where you pass a parameter or get a return value from the wrong place. Traditionally, too, you don't have local variables, but I think that's not actually nearly as big a problem as it sounds. That said, my last few words were exactly backward from what…

You are not looking at Forth correctly. It isn't C, C++ or Java. It's a "raw" language that you should use to write a DSL. It's just above assembler yet many orders of magnitude faster to develop with. Even with your comment backwards it makes little sense. I have developed in nearly every language between typing raw machine code with a hex keypad and Objective-C (not to moly that O-C is at the opposite end of the sc…

The difference between 'grok' and 'use'.

Re: How I coded in 1985

#109

Post by bwang8 »

Articles like these make me realized I am completely spoiled. I am in no position to complain about debugging when modern technology afforded me a much easier time than 30-40 years ago.

Re: How I coded in 1985

#110

Post by kragen »

robomartin wrote: post #105
kragen wrote: post #95

Earlier quoted context omitted.

All bugs can be traced to the programmer, of course. I find Forth error-prone because it's untyped (not even dynamically typed) and you have parameter-passing errors, where you pass a parameter or get a return value from the wrong place. Traditionally, too, you don't have local variables, but I think that's not actually nearly as big a problem as it sounds. That said, my last few words were exactly backward from what…

You are not looking at Forth correctly. It isn't C, C++ or Java. It's a "raw" language that you should use to write a DSL. It's just above assembler yet many orders of magnitude faster to develop with. Even with your comment backwards it makes little sense. I have developed in nearly every language between typing raw machine code with a hex keypad and Objective-C (not to moly that O-C is at the opposite end of the sc…

Oh, I know that about the EDSL nature of Forth, and it's entirely possible that if I really knew Forth, my experience would be different.

On the other hand, if you were right that Forth is many orders of magnitude faster to develop with than assembler, we'd see people writing HTML5-compliant web browsers in Forth in a few hours. (I'm figuring: 100 person-years for e.g. Chromium, multiplied by ten for assembly, divided by six orders of magnitude (because five isn't "many") gives you about 8 hours.) So I suspect you're living in some kind of a fantasy world.

Post reply on HN