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

Microsoft GW-Basic Interpreter Source Code

github.com

Post reply on HN
Print view View original

91–100 of 101 posts

Re: Microsoft GW-Basic Interpreter Source Code

#91

Post by zozbot234 »

unfocussed_mike wrote: post #87
pjmlp wrote: post #83

Earlier quoted context omitted.

Python seems to have taken its place, specially with all school calculators having some variant of MicroPython. It isn't the same thing though.

Yes -- I think sort of the most basic BASIC programming is done with Scratch, and then they graduate to Python. In the UK I gather kids are taught Scratch and Python in an overlapping fashion, so they see the structure on the Scratch view and then have a better chance of understanding how the code works without being thrown off by the symbols. This is probably better in a pedagogical sense, and I am sure Scratch prog…

Scratch and especially Python are a lot more complex than BASIC. OTOH, Scratch having a structural rather than solely text-based interface might also make a more complex language immediately usable, by removing the difficulty associated with keywords and surface syntax. This is the kind of thing that would really benefit from a well-designed usability experiment.

Re: Microsoft GW-Basic Interpreter Source Code

#92

Post by billforsternz »

phkahler wrote: post #90
billforsternz wrote: post #86

Earlier quoted context omitted.

Yes, around 8 spare opcodes, and they were the ones Zilog used to escape into a large set of extensions for the (backwardly compatible to 8080) Z80.

Can a Z80 be dropped into an 8080A socket? I'm thinking there were hardware differences.

No absolutely not. 8080 was a 3 chip solution from memory. The 8085 was, like a Z80, a 40 pin DIP, but even here the compatibility was strictly software not hardware. And in fact the software compatibility was a little less than 100% because Zilog decided to add an overflow flag by changing the 8080/8085 parity flag to actually reflect overflow instead of parity on arithmetic instructions.

Re: Microsoft GW-Basic Interpreter Source Code

#93

Post by jaxrtech »

wvenable wrote: post #68
notacoward wrote: post #6

All of the "comments are useless because they get out of date" folks should look at this code, which is still comprehensible 40 years later because of the comments.

75% of assembly programming is writing comments.

Agreed, commenting assembly is bit different "environment" to explain the "why?". You're explaining why you're putting a value in a register vs why you're calling some particular API or whatever in a higher-level language. And then you have COBOL...

Re: Microsoft GW-Basic Interpreter Source Code

#94

Post by ncmncm »

I remember being shocked to find that every GOTO (and even a NEXT) would do a linear search for the right line number starting from the beginning of the program image.

They really, actively did not care about performance. Manifestly, it was the right choice for the time, place, and circumstances, but it is hard to see how, today.

Re: Microsoft GW-Basic Interpreter Source Code

#95

Post by krylon »

GekkePrutser wrote: post #88
krylon wrote: post #20

Earlier quoted context omitted.

Likely something like that. My money is on them being unable to locate someone who needs to give permission, and it's probably not a very high priority issue. I vaguely recall reading a blog post when Sun opened the Solaris source code, that it was a tremendous effort tracking down every single person they needed permission from.

And then Oracle went and undid almost all that work :'(

To make it even worse, they laid off most of their Solaris developers a couple years ago.

Somebody who used to work on Solaris before the Oracle takeover commented at the time that just by looking at the number of layoffs, Oracle Solaris was effectively dead.

I am not even a big Solaris fan (although it was the most beautifully named OS ever), but I cannot help but think of Rutger Hauer's dying speech from Blade Runner: I have seen things you people would not believe [...] All these moments will be lost in time like tears in the rain.

If somebody who has been there would write a book about the development of SunOS and Solaris, I would probably buy two copies. If the title included the word Eclipse, I'd buy three copies.

Re: Microsoft GW-Basic Interpreter Source Code

#96

Post by krylon »

bobochan wrote: post #25
krylon wrote: post #17

Earlier quoted context omitted.

I knew that it used to stand for that (and as an acronym should be upper-case), but I thought they maybe dropped that somewhere along the way. Fortran and Cobol used to be "FORTRAN" and "COBOL", too, but once systems with support for upper- and lowercase-letters became widespread, they went mixed-case. I recall there was some debate if the name BASIC had been intended as an acronym initially, but in time, evidence (A…

Dartmouth celebrated the 50th anniversary of BASIC a few years ago and they were pretty consistent in keeping it all upper case. https://www.dartmouth.edu/basicfifty/basic.html True BASIC, a company that Kemeny and Kurtz founded in 1983, is all upper case too. https://www.truebasic.com/about

Well, Happy Birthday BASIC!

Love it or hate it, BASIC has left a footprint in the IT world that few languages could match.

Re: Microsoft GW-Basic Interpreter Source Code

#97

Post by krylon »

dragonwriter wrote: post #79
krylon wrote: post #17

Earlier quoted context omitted.

I knew that it used to stand for that (and as an acronym should be upper-case), but I thought they maybe dropped that somewhere along the way. Fortran and Cobol used to be "FORTRAN" and "COBOL", too, but once systems with support for upper- and lowercase-letters became widespread, they went mixed-case. I recall there was some debate if the name BASIC had been intended as an acronym initially, but in time, evidence (A…

> Fortran and Cobol used to be "FORTRAN" and "COBOL", too, but once systems with support for upper- and lowercase-letters became widespread, they went mixed-case COBOL is still “COBOL” (at least per the IBM page on the language and the ISO/IEC 1989:2014 standard for the language.

My bad then. Thank you for pointing that out.

Re: Microsoft GW-Basic Interpreter Source Code

#98

Post by arantius »

ncmncm wrote: post #94

I remember being shocked to find that every GOTO (and even a NEXT) would do a linear search for the right line number starting from the beginning of the program image. They really, actively did not care about performance. Manifestly, it was the right choice for the time, place, and circumstances, but it is hard to see how, today.

Optimizing for time and optimizing for memory are different things. Choosing one over the other doesn't guarantee the author "did not care about performance".

Re: Microsoft GW-Basic Interpreter Source Code

#99

Post by kwertyoowiyop »

TedDoesntTalk wrote: post #53
JohnBooty wrote: post #33

Earlier quoted context omitted.

This is why I've always been an advocate of inline code comments. With just the slightest amount of professionalism, you can keep them up to date, and only a real psychopath would update code without updating the comments directly above it. (So, of course, 50% of programmers don't...)

I can’t count the number of PRs I’ve rejected because code was changed but the corresponding inline comments were not.

Thank you for being part of the professional 50%!

Re: Microsoft GW-Basic Interpreter Source Code

#100

Post by ncmncm »

arantius wrote: post #98
ncmncm wrote: post #94

I remember being shocked to find that every GOTO (and even a NEXT) would do a linear search for the right line number starting from the beginning of the program image. They really, actively did not care about performance. Manifestly, it was the right choice for the time, place, and circumstances, but it is hard to see how, today.

Optimizing for time and optimizing for memory are different things. Choosing one over the other doesn't guarantee the author "did not care about performance".

Nothing guarantees anything. But the extra stuff needed to compensate for being extremely slow can often cost more than the cost not to be extremely slow.
Post reply on HN