> Have you played with Racket at all? There is another concept from the DrRacket tool that I really enjoy. Images have their own print mode, i.e. getting displayed in the REPL just by referencing them.
I haven't played much with Racket, but I have worked with other systems that do this. (I've also developed a feature like this feature myself, many years ago, in a system I was building as a small-scale data analysis tool.) And yes, I agree that the combination of a REPL that both uses the full capabilities of the output device and renders objects that 'know what they are' is transformative. It makes entirely different classes of work that much more interactive.
In addition to the graphics, it still seems like a miss that I can't type 'ls' or 'find' at a terminal prompt and drag a filename from the list into a finder window to move or copy the file. (But getting to that point is work on several different levels... ls would need to produce output that somehow annotates each output filename with the fact that it's a file with a specific full path. Then the terminal would need to be able to intelligently work with those sorts of annotations.)
> There are probably a lot of good reasons for storing code as text, not the least of which are diffing as well as transmitting to/from other authors with their own toolsets.
I think part of it is history... both inside and outside the field of computing. It was technical limitations at the beginning of the field that made text more or less the only choice for early programming systems. (Unless you count the even earlier plugboard machines.)
Outside the field, images alone don't tend to be used to represent the sequences of events that are so common in programming. There's always a convention for imposing a sequence layered atop the visuals. This text, by convention, reads left to right. Pictographic languages have an ordering by convention. Comic books have both a convention to the ordering of frames and (mostly) the text within the frames. I mentioned LabView elsewhere in this thread... it's a visual programming language, but it has an explicit sequence construct (that models a sequence visually as frames of film that can be paged through).
I guess my point is that textual representations have a lot going for them out of the box... including an historically natural modeling of the notion of sequence and a huge volume of tooling and process optimized for the purpose of manipulating text. For a visual language to succeed, it has to offer compelling enough advantages to outweigh the cost of walking away from those things.
I haven't played much with Racket, but I have worked with other systems that do this. (I've also developed a feature like this feature myself, many years ago, in a system I was building as a small-scale data analysis tool.) And yes, I agree that the combination of a REPL that both uses the full capabilities of the output device and renders objects that 'know what they are' is transformative. It makes entirely different classes of work that much more interactive.
In addition to the graphics, it still seems like a miss that I can't type 'ls' or 'find' at a terminal prompt and drag a filename from the list into a finder window to move or copy the file. (But getting to that point is work on several different levels... ls would need to produce output that somehow annotates each output filename with the fact that it's a file with a specific full path. Then the terminal would need to be able to intelligently work with those sorts of annotations.)
> There are probably a lot of good reasons for storing code as text, not the least of which are diffing as well as transmitting to/from other authors with their own toolsets.
I think part of it is history... both inside and outside the field of computing. It was technical limitations at the beginning of the field that made text more or less the only choice for early programming systems. (Unless you count the even earlier plugboard machines.)
Outside the field, images alone don't tend to be used to represent the sequences of events that are so common in programming. There's always a convention for imposing a sequence layered atop the visuals. This text, by convention, reads left to right. Pictographic languages have an ordering by convention. Comic books have both a convention to the ordering of frames and (mostly) the text within the frames. I mentioned LabView elsewhere in this thread... it's a visual programming language, but it has an explicit sequence construct (that models a sequence visually as frames of film that can be paged through).
I guess my point is that textual representations have a lot going for them out of the box... including an historically natural modeling of the notion of sequence and a huge volume of tooling and process optimized for the purpose of manipulating text. For a visual language to succeed, it has to offer compelling enough advantages to outweigh the cost of walking away from those things.