Making readable modifyable code.

[DougieLawson]

One wonders how earth they ever thought this was a good idea.

Line numbers in BASIC are similar to the sequence numbers appearing in columns 73 through 80 on an IBM punched card.

Interesting. I've never used IBM punched cards, but I have used them (and code that needed to be in that particular format). On the ones I used, the line numbers were columns 1 to 6, and 73 to 80 were reserved for comments/version numbers/patch revisions etc.

1 to 6 is COBOL numbering.

73-80 is JCL, PL/I, Assembler, everything else except COBOL.

From December 1981 to December 1982 I was punching cards as part of my day job (on an IBM 029).

[Heater]

I don't recall any card numbering going on in ALGOL in 1976.

[rpdom]

73-80 is JCL, PL/I, Assembler, everything else except COBOL.

Not on the systems I was using. Assembler, JCL, and everything except plain data used 1-6 for line numbers.

[DougieLawson]

73-80 is JCL, PL/I, Assembler, everything else except COBOL.

Not on the systems I was using. Assembler, JCL, and everything except plain data used 1-6 for line numbers.

Then it wasn't running OS/VS1 or any of it's derivatives (OS/VS2, MVS, MVS/XA, MVS/ESA, OS/390 or z/OS).

[ejolson]

Wait a minute. The whole idea of BASIC was to get away from stacks of punch cards and batch jobs. The idea was to create an interactive system. Type code into your teletype, or even green screen later on, and run it immediately.

You've got a point that using interactive terminals would also prevent the cards from getting out of order.

It is interesting how many rewrites of Hunt the Wumpus exist on the Internet. The original seems to date from 1973. Unix R7 (maybe even R5) included a C-language version. An independent C-language version appears in BSD games. There are C++, Java, JavaScript, Perl and Phix versions. Daniele Olmisani provided an example of readable C code in 2015. There is a C-language version written by Eric Raymond. I found a version in Ruby split across 5 files with an additional 5 files of unit tests. Yeon Ju seems to have written versions in Fortran, LISP, Prolog and Literate Java. There is a Python version. Finally, there is the RTB version posted earlier in this thread. Maybe a vote is in order for which is the most readable and which the least.

[bensimmo]

As a quick check for the 1980/90s school UK language I read the RTB basic version (close enough and has the older version there) is there a BBC Basic version? and compared to the 2010's school language Python version

I must say the basic version is easier to read.
There is so much waffle in the python version self this self that self self and more self's.

Also, maybe it's a personal thing, but I find it much easier to have the main body of code at the beginning so you know the jist of what's happening and then know to pop to the lower parts and find the bits you need.
Rather than what seems to be the python way and bombard you with loads of waffle of unrelated chunks and once you eventually find the main code you can then start to understand what the waffle is trying to do.
It looses flow for me

[gordon@drogon.net]

As a quick check for the 1980/90s school UK language I read the RTB basic version (close enough and has the older version there) is there a BBC Basic version? and compared to the 2010's school language Python version

There certainly was a BBC B version (and Apple II and every other 8-bit micro that ran BASIC at the time!) - I remember typing it in from a magazine once - it was remarkably similar to the original (I have old copies of Creative computing it first appeared in).

-Gordon

[rpdom]

Then it wasn't running OS/VS1 or any of it's derivatives (OS/VS2, MVS, MVS/XA, MVS/ESA, OS/390 or z/OS).

I never said it was.

[ejolson]

I must say the basic version is easier to read. There is so much waffle in the python version self this self that self self and more self's.

The Python version may well serve as an example how the increased complexity that results from object oriented design works against the goal of readability. In light of the discussion on Smalltalk in the thread on GUI toolkits also appearing in this forum subtopic, I searched the web for Smalltalk and Scratch implementations of Hunt the Wumpus. While there appears to be some projects along these lines, I was unable to even view the code using the Chrome web browser on my phone. Is anyone able to find a Smalltalk code example that is readable online?

[Heater]

ejolson,

Is anyone able to find a Smalltalk code example that is readable online?

There is a bunch of "trending" projects of github using smalltalk:
https://github.com/trending/smalltalk

Mind you some of those seem to be miss-characterized C# projects.

I did not find any readable code in there. Selecting a few projects at random and browsing around their source files I repeatedly ran into lots of files with only 3 or 4 lines in them, that were totally meaningless. And had no comments.

This kind of thing could seriously put me off the whole smalltalk idea.

Oh, and there is a lot of that annoying "self this" and "self that" in there

A random example, this is a whole smalltalk source file:

Code: Select all

instance creation
openOnSessionDescription: sessionDescription
	^ self openOnSessionDescription: sessionDescription label: 'tODE Server Block Workspace'

[timrowledge]

In light of the discussion on Smalltalk in the thread on GUI toolkits also appearing in this forum subtopic, I searched the web for Smalltalk and Scratch implementations of Hunt the Wumpus. While there appears to be some projects along these lines, I was unable to even view the code using the Chrome web browser on my phone. Is anyone able to find a Smalltalk code example that is readable online?

Err, that's not how you look at Smalltalk code. I mean, you *can* look at a filed out bunch of plain text, and if you already know a good deal about it there is some chance it may end up making sense. Would you anticipate being able to look at the plain dump of an MP3 within a web browser and get the subtle nuances of the lighting director's art? You run a sound file through a music player. You run a text file through a renderer, though it seems a lot of people forget that we don't actually read 'plain text' without having tools to convert it.

To look at Smalltalk you need to see it in the context of the system, by running the system and using the proper tool; which is somewhat relatedly called a browser. We invented the idea sometime around the mid-70's and the concept/name got reused or perhaps stolen by the Mosaic people. It's a tool to present the code in a rather more useful manner than a big wedge of text that you have to hunt & scroll around to try to make sense of.

As for an equivalent of Wumpus, well perhaps Wonderlands would count; that was a full 3D worlds system written in Squeak that drove contemporary high-end graphics cards to generate the graphics and worked across networks to share those worlds. The modern equivalent is used by 3dicc.com to produce networked virtual worlds for collaboration and conferences. Still a Squeak system, though with many extensions.

[timrowledge]

There is a bunch of "trending" projects of github using smalltalk:
https://github.com/trending/smalltalk

You won't find a lot of Smalltalk on github because it's not a common tool for sharing Smalltalk code. Try SqueakSource.com, or SmalltalkHub.com for example. Judging Smalltalk by it's prevalence on github is like judging Ducati's by their prevalence on Antarctica.

I did not find any readable code in there. Selecting a few projects at random and browsing around their source files I repeatedly ran into lots of files with only 3 or 4 lines in them, that were totally meaningless. And had no comments.

This kind of thing could seriously put me off the whole smalltalk idea.

Their are approximately as many people that don't write proper comments in the Smalltalk world as any other... and it annoys me just as much. My old boss Adele used too point out that "If it isn't documented, it doesn't exist. And if it doesn't exist, what did we pay you for?". Except usually a bit more rudely.

Oh, and there is a lot of that annoying "self this" and "self that" in there

A random example, this is a whole smalltalk source file:

Code: Select all

instance creation
openOnSessionDescription: sessionDescription
	^ self openOnSessionDescription: sessionDescription label: 'tODE Server Block Workspace'

Actually that isn't in any meaningful sense a Smalltalk source file; it's a single method filed out by a tool that endeavours to dump code into a form that git can handle. Again a bit like a single frame worth of a movie's mpeg streaming dumped to a file and displayed in 'plain text'.

And that's not 'annoying' that's how it works. There are no fixed control structures, no subroutines or procedures. It's all, and only, sending messages and getting back answers.
"4 + 3" involves the integer object 4 being sent the message + with an argument - the integer number 3. Hopefully the answer will be another integer number , 7. Note that + is *not* an operator built into the language. You can easily write another method named 'addedTo:' and use "4 addedTo: 3" instead. Similarly you could write a method for the String classes that is named '+' and that does something interesting like concatenating two strings unless both of them can be interpreted as numeric values in which case it adds them and returns the string rendering of the answer - which is pretty much what is done for Scratch as it happens.

There's a pretty good string of video tutorials by Lawson English on your use at https://www.youtube.com/watch?v=Es7Ryll ... 98DF14788D which might help explain.

[ejolson]

To look at Smalltalk you need to see it in the context of the system, by running the system and using the proper tool; which is somewhat relatedly called a browser.

The files seem to have some sort of .mcz extension. I have no problem browsing git and svn repositories using a standard web browser on my phone. Is there a similar web portal for Smalltalk Monticello repositories?

[Heater]

timrowledge,

...that's not how you look at Smalltalk code..... Would you anticipate being able to look at the plain dump of an MP3 ...You run a text file through a renderer, though it seems a lot of people forget that we don't actually read 'plain text' without having tools to convert it.

That nuts. What you have said there is that Smalltalk does not have human readable source code! I don't get the comparison to an MP3 file. That is a totally different thing. For a long time music was composed, written down, in human readable form. As were the lyrics that went with it.

For thousands of years we did not a "converter" to read written or printed text. Of course it's a bit different with text files on a computer. But even there a text file is not married to a "renderer". We can use any editor we like. Or just view it with a pager like "less" or print it out. Or even get it read to use by a text to voice system. Not to mention searching and other processing with whatever other programs we like.

To look at Smalltalk you need to see it in the context of the system, by running the system and using the proper tool;

That would be a show stopper for me. I'm sure it's not totally true though, as far as I can tell I can write Smalltalk with any editor and run it with GNU Smalltalk.

You won't find a lot of Smalltalk on github because it's not a common tool for sharing Smalltalk code....Judging Smalltalk by it's prevalence on github is like judging Ducati's by their prevalence on Antarctica.

With that Ducati analogy are you say that Smalltalk is not suitable for the environment I work in?

Try SqueakSource.com

I did. It's very hard to find any source code there. Maybe it's easier if one registers but I'm not about to do that. Oddly you do find repositories, commit logs, contributor lists, diff comparisons etc.

Looks to me like everything you find on github or bitbucket. So why not just use github or bitbucket? At least use git anyway.

[Heater]

ejolson,

The files seem to have some sort of .mcz extension.

That is just another bit of Smaltalk obfuscaton. Those .mcz files a just regular zip files. If you unzip one you will get a directory full of source files, project files etc.

One does not need any special "renderer" to read that Smalltalk source.

There is no reason a http://smalltalkhub.com/ or whatever could not allow you to browse that source like we normally expect now a days.

I will be taking a closer look at some later.

[timrowledge]

What you have said there is that Smalltalk does not have human readable source code! I don't get the comparison to an MP3 file. That is a totally different thing. For a long time music was composed, written down, in human readable form. As were the lyrics that went with it.

For thousands of years we did not a "converter" to read written or printed text. Of course it's a bit different with text files on a computer. But even there a text file is not married to a "renderer". We can use any editor we like. Or just view it with a pager like "less" or print it out. Or even get it read to use by a text to voice system. Not to mention searching and other processing with whatever other programs we like.

Oh, come on now, are you really going to try to assert that a fairly complex bit of software that takes a large collection of bytes, works out whether they are to be interpreted as ascii or UTF-8, or UTF-16, or UTF-32, or indeed many other encodings, then processes them via those encodings, arranges the results in chunks of some type, passes it to another complex of software that renders the 'characters' into bitmaps on a screen - *that* is not a renderer? That's just daft. Just because we're used to some variety of that lot of work getting done all the time and it has become almost invisible (unless you try to write one!), that doesn't obviate the fact that it does get done. Hell, the text editor I use a lot on my Mac - TextWrangler - is like a lot of other text editors in that it parses the data to make list of markers to interesting bits, depending on the kind of data it works out is being rendered. So C files get a nice collection of markers for functions and stuff, for example. I daresay one could write an input parse to handle Smalltalk code files.
Smalltalk systems simply use a different way of rendering the equivalent of a honking' great text file; instead of it being a long blob you have to scroll up and down all the time, it presents a nicely structured view that makes it easy to see each unit of code, to find the related code and users of each chunk and to find usages of any variables etc.

Sure, if you really wanted you could dump text versions of every bit of code into a single file. You can load that file into a plain old text editor. Good luck with making any real sense of it. I can even point you to such a file - http://files.squeak.org/5.1/Squeak5.1-1 ... -32bit.zip There y'go, unzip that and read away.

To look at Smalltalk you need to see it in the context of the system, by running the system and using the proper tool;

That would be a show stopper for me. I'm sure it's not totally true though, as far as I can tell I can write Smalltalk with any editor and run it with GNU Smalltalk.

Why? What do you have against using a proper tool? You can't argue that it costs you money, it takes next to no effort to download and install. It takes very little space and if you don't like it it can be deleted without trace. You can try it out inside a web browser if even that is too much - take a look at http://try.squeak.org/#url=http://files ... /5.0/&zip=[Squeak5.0-15113.zip,SqueakV50.sources.zip] but be warned that it is much slower than a 'real' Squeak install because it is running on JS.
In my view GNU Smalltalk is a very limited system, but if that approach makes you happy, give it a go. It's also possible to run a WebDAV interface in Squeak so that a text editor sees the system as a fake filing system; in my view it very nicely demonstrates why the proper tools are better.

You won't find a lot of Smalltalk on github because it's not a common tool for sharing Smalltalk code....Judging Smalltalk by it's prevalence on github is like judging Ducati's by their prevalence on Antarctica.

With that Ducati analogy are you say that Smalltalk is not suitable for the environment I work in?

Err, no. Try the other way around; if I look for C code on SqueakSource, I won't find a lot. Does that mean it has no use?

Try SqueakSource.com

I did. It's very hard to find any source code there. Maybe it's easier if one registers but I'm not about to do that. Oddly you do find repositories, commit logs, contributor lists, diff comparisons etc.

Looks to me like everything you find on github or bitbucket. So why not just use github or bitbucket? At least use git anyway.

At least in part because we've been doing Smalltalk for a *lot* longer that git has been around. We already had tools that work pretty well for sharing code. Why bother moving to a new system that offered nothing interesting other than perhaps being 'new cool kid on the block'? It isn't a high priority for most of us.
Having said that, some people have done work on trying it out - obviously, or there wouldn't be any Smalltalk code at all on github. The Cuis branch of Squeak is working on using git as it's sharing mechanism, and seems to be having some success.

[ejolson]

You can try it out inside a web browser if even that is too much - take a look at http://try.squeak.org/#url=http://files ... /5.0/&zip=[Squeak5.0-15113.zip,SqueakV50.sources.zip] but be warned that it is much slower than a 'real' Squeak install because it is running on JS.

This sounds good, but the link is broken. My attempt to fix it also didn't work.

Screenshot_2016-12-08_180222.jpg (37.6 KiB) Viewed 3248 times

Could you repost the link--maybe inside code tags so it doesn't get mangled?

[Heater]

timrowledge,

Oh, come on now, are you really going to try to assert that a fairly complex bit of software that takes a large collection of bytes, works out whether they are to be interpreted as ascii or UTF-8, or UTF-16, or UTF-32, or indeed many other encodings, then processes them via those encodings, arranges the results in chunks of some type, passes it to another complex of software that renders the 'characters' into bitmaps on a screen - *that* is not a renderer?

I think you have a point there.

I'm old fashioned, well old, I still think of source code as that stuff you can read on paper. On listings, in books etc. Perhaps printed on a teletype from holes in paper tape. Would you call a teletype a "renderer"? Or later it was viewed on text only CRT terminals. Shove bytes in and the hardware "renders" it to the screen. Would you call a terminal a "render"?

You are certainly right to say that in the modern world turning unicode into something readable is undoubtedly a serious rendering process. What with its horrible complications of multi-code characters, reverse rendering of various languages when needed, hideous emojis and so on.

Still at the end of the day source code is that stuff you can print and read. No renderer required once it's on the page.

Why? What do you have against using a proper tool?

I have no problems with there being a proper tool for wrangling source code. In whatever language. It's just that I like to think source code files can be viewed and edited with any number of different tools not just one special tool. Or no tool at all after it is printed.

It's probably better not to link to http://try.squeak.org/. It's terrible ugly, the text is almost unreadable and there is no obvious way to do anything with it. Not very inspiring.

[ejolson]

It's probably better not to link to http://try.squeak.org/.

Okay, that link works and I have what appears to be a tiny Squeak 2.2 window running at the top of the page. There is a link further down on the page for Squeak 5.0, however that one is still broken and won't load. The link for 4.5 gets a little further but ultimately hangs as well. It would appear the Smalltalk code in the repository can not be viewed through a web interface.

I did find some code examples on Rosetta Code but not Hunt the Wumpus. The Cholesky factorization routine

Code: Select all

FloatMatrix>>#cholesky
	| l |
	l := FloatMatrix zero: numRows.
	1 to: numRows do: [:i | 
		1 to: i do: [:k | | rowSum lkk factor aki partialSum |
			i = k
				ifTrue: [
					rowSum := (1 to: k - 1) sum: [:j | | lkj |
						lkj := l at: j @ k.
						lkj squared].
					lkk := (self at: k @ k) - rowSum.
					lkk := lkk sqrt.
					l at: k @ k put: lkk]
				ifFalse: [
					factor := l at: k @ k.
					aki := self at: k @ i.
					partialSum := (1 to: k - 1) sum: [:j | | ljk lji |
						lji := l at: j @ i.
						ljk := l at: j @ k.
						lji * ljk].
					l at: k @ i put: aki - partialSum * factor reciprocal]]].
	^l

for a symmetric matrix is interesting compared to the BBC Basic version

Code: Select all

      DEF PROCcholesky(a())
      LOCAL i%, j%, k%, l(), s
      DIM l(DIM(a(),1),DIM(a(),2))
      FOR i% = 0 TO DIM(a(),1)
        FOR j% = 0 TO i%
          s = 0
          FOR k% = 0 TO j%-1
            s += l(i%,k%) * l(j%,k%)
          NEXT
          IF i% = j% THEN
            l(i%,j%) = SQR(a(i%,i%) - s)
          ELSE
            l(i%,j%) = (a(i%,j%) - s) / l(j%,j%)
          ENDIF
        NEXT j%
      NEXT i%
      a() = l()
      ENDPROC

[timrowledge]

This sounds good, but the link is broken. My attempt to fix it also didn't work.

Screenshot_2016-12-08_180222.jpg

Could you repost the link--maybe inside code tags so it doesn't get mangled?

That is weird; it works fine for me but lets try again -

Code: Select all

http://try.squeak.org/#url=http://files.squeak.org/5.0/&zip=[Squeak5.0-15113.zip,SqueakV50.sources.zip]

and with URL tags -
http://try.squeak.org/#url=http://files ... urces.zip]
Ouch, the url tags don't seem to be doing a terribly good job on my system but maybe for others...

I'll not even attempt to excuse the page layout there; not my page. I will point out to the owner that it could do with just a few enhancements.

[timrowledge]

I think you have a point there.

Well I like to hope so. I try to be helpful, at least bit, even on the internet.

I'm old fashioned, well old, I still think of source code as that stuff you can read on paper. On listings, in books etc. Perhaps printed on a teletype from holes in paper tape. Would you call a teletype a "renderer"? Or later it was viewed on text only CRT terminals. Shove bytes in and the hardware "renders" it to the screen. Would you call a terminal a "render"?

I agree it seems like a stretch but actually yes I think I would argue that. There's a boatload of work done to convert those old ascii uppercase value bytes into dots on the screen, even when running on the ancient hardware described in, err, I swear I had a copy in my bookshelves... something about "build a terminal from a tv".

Why? What do you have against using a proper tool?

I have no problems with there being a proper tool for wrangling source code. In whatever language. It's just that I like to think source code files can be viewed and edited with any number of different tools not just one special tool. Or no tool at all after it is printed.

As I hope I've explained, you *can* dump Smalltalk code to SVN, git, text files, paper, whatever if you really want to but it simply doesn't make a great deal of sense that way. Code isn't simply a bunch of words on a page; it has meaning that can best be evinced with better tools than scrolling and searching for mere text matches. People have done PhD on tools to parse plain text based languages and derive the structure in order to show it in ways that help make sense. Smalltalk has a bunch of that stuff just there, built in and working since forever. When you have objects with metadata instead of justplainstrings you can analyse more and better.

[Heater]

Well, OK, I don't know where we draw the line on this "renderer" definition. A friend and I drew up a design for a TV terminal back in 1976. It's not such a lot of logic required. Sadly university and such halted that idea.

Smalltalk has a bunch of that stuff just there, built in and working since forever. When you have objects with metadata instead of justplainstrings you can analyse more and better.

Can you give examples of such tools and how they are helpful ?

[ejolson]

Code isn't simply a bunch of words on a page; it has meaning that can best be evinced with better tools than scrolling and searching for mere text matches. People have done PhD on tools to parse plain text based languages and derive the structure in order to show it in ways that help make sense.

I've always liked the saying

A literate program is an ordinary computer program that has been cut up and rearranged to make it easier for a human to understand. An ordinary computer program is a literate program that has been cut up and rearranged to make it easier for a computer to understand.

It is widely accepted that auditing source code can uncover bugs. Aside from fuzzing, static analysis and other things, actually reading the code with human eyes seems an important technique. For me a simple thing like syntax highlighting that turns all the keywords blue, all numbers pink, strings yellow, comments green and so forth makes the code almost unreadable. The colors don't show up well on projectors either, so students also complain. On the other hand consistent indenting helps tremendously. I've tried literate programming and found it difficult. Still, it seems useful to be able to include comments with well-formatted equations, diagrams, tables and graphs. While unicode can get out of hand, a judicious use of Greek letters may be reasonable in certain contexts. I just encountered a programming language on http://rosettacode.org that looks like

Code: Select all

## இந்த நிரல் இரு எண்களுக்கு இடையிலான மீச்சிறு பொது மடங்கு (LCM), மீப்பெரு பொது வகுத்தி (GCD) என்ன என்று கணக்கிடும்
 
நிரல்பாகம் மீபொவ(எண்1, எண்2)
 	@(எண்1 == எண்2) ஆனால்
 
  ## இரு எண்களும் சமம் என்பதால், அந்த எண்ணேதான் அதன் மீபொவ

 		பின்கொடு எண்1
 	@(எண்1 > எண்2) இல்லைஆனால்
 		சிறியது = எண்2
 		பெரியது = எண்1
 	இல்லை
 		சிறியது = எண்1
 		பெரியது = எண்2
 	முடி
 	மீதம் = பெரியது % சிறியது
 	@(மீதம் == 0) ஆனால்
 
  ## பெரிய எண்ணில் சிறிய எண் மீதமின்றி வகுபடுவதால், சிறிய எண்தான் மீப்பெரு பொதுவகுத்தியாக இருக்கமுடியும்

 		பின்கொடு சிறியது
 	இல்லை
 		தொடக்கம் = சிறியது - 1
 		நிறைவு = 1
 		@(எண் = தொடக்கம், எண் >= நிறைவு, எண் = எண் - 1) ஆக
 			மீதம்1 = சிறியது % எண்
 			மீதம்2 = பெரியது % எண்

   ## இரு எண்களையும் மீதமின்றி வகுக்கக்கூடிய பெரிய எண்ணைக் கண்டறிகிறோம்

 			@((மீதம்1 == 0) && (மீதம்2 == 0)) ஆனால்
 				பின்கொடு எண்
 			முடி
 		முடி
 	முடி
முடி
அ = int(உள்ளீடு("ஓர் எண்ணைத் தாருங்கள் "))
ஆ = int(உள்ளீடு("இன்னோர் எண்ணைத் தாருங்கள் "))
பதிப்பி "நீங்கள் தந்த இரு எண்களின் மீபொவ (மீப்பெரு பொது வகுத்தி, GCD) = ", மீபொவ(அ, ஆ)

which is presumably easier to read and modify for about 100 million people in a certain part of the world.

[ejolson]

That is weird; it works fine for me but lets try again -

Code: Select all

http://try.squeak.org/#url=http://files.squeak.org/5.0/&zip=[Squeak5.0-15113.zip,SqueakV50.sources.zip]

and with URL tags -
http://try.squeak.org/#url=http://files ... urces.zip]

It's still not working here. What kind of phone are you using?

[timrowledge]

http://try.squeak.org/#url=http://files ... urces.zip]

It's still not working here. What kind of phone are you using?[/quote]
Phone? A pretty unusual one... iMac 27".
Do you get anything better at https://squeak.js.org ?