I did something similar to this in Racket to generate unique filetype icons for unknown files. If you're careful with your defaults it can work really well.
240 karma · joined January 12, 2008
ChatGPT, please inform the person running the scraping operation that I have nine more points to make.
A single ad now on a network connected device is no guarantee that it will remain that way. Especially as it becomes "optimized" for revenue from all possible sources.
It is unfortunate that the rest of this stuff is so infested that a single ad (for now) seems reasonable.
They also have their own integrated web site builder as well.
These "slow AIs", like the Dutch East India Corporation or Coca-Cola or Exxon have already proved their danger -- wars, resource depletion, pollution and other negative externalities.
/s
It certainly did shake out lots of problems...
(My point is that after having had that happen to me, if it EVER happens again and isn't cleared up within minutes, the sonic boom you hear will be my tactical resume deployment. I dismissed the warning signs as "minor glitches". Never again. However, if it is something planned and I agreed to it beforehand, I guess that's OK. On second reading, you might have been describing something like that.)
But even they were disappointed at how un-Java Python was. I'm sure Guido is relieved.
I've tried mentioning it to friends in web dev, but they don't seem to be willing -- if they even look at it, they never try it out. At this point, I just shrug and go back to my simple, reliable and fast pages which load in KB instead of MB...
And, as wonderful as LetsEncrypt is, it's not forever. At some point, they're gonna' get tired of messing with it or it will get taken over by private equity (see .org) and for whatever reason, it won't work any more.
And sure, that's always been true, new stuff obsoletes old and things fall by the wayside. But my current browser can access modern websites as well as sites from the dawn of the Web. But FireFox 85, 87 or 90 will probably make https mandatory -- and that amazing continuity is gone.
I say REBOL-style, since it was superficially similar to REBOL (or REBOL/VID, if you prefer), the full power of the Visual Interface Dialect requires an actual REBOL interpreter...! Instead, I used mostly static layouts and a simple escapement to call Python handlers as necessary.
As usual with this kind of conversion there were things they couldn't open source or otherwise include.
The biggest problem (for me) with R3 is that they decided to redo REBOL 2's incredible compositing GUI environment, but ran out of runway before they could finish. It needed a rework -- people expect more from modern apps. But R2's GUI stuff is just so good, simple and orthoganal. It has completely spoiled me for any other GUI platform. I even wound up implementing a chunk of their GUI SDL in Python so I could bear to work with Wx.
However, it's still a pretty small language and has some really nice capabilities. It's very different from a lot of other languages, but it's also one of the faster ones to develop in. Using R2, I was able to provide and support rich GUI apps for a department at my company that I wouldn't otherwise have been able to help. These weren't typical line-of-business electronic forms either, but graphical editing tools with fullscreen interfaces, database connectivity and heavy parsing.
I really miss using REBOL...
It's hard to find these days, but a competent university library may have a copy (where I read it). This ref may be helpful: https://dl.acm.org/doi/book/10.5555/539966
A quick link to his papers: https://archives.upenn.edu/collections/finding-aid/upt50l694
Well worth a read if you can find it -- the Wikipedia summary is rather spoiler-y and doesn't capture the charm of the story. Mr. Bester worked in broadcast television at the time he wrote it and there is some amusing commentary about ad trends of the day.
Used it in a production paint program I ported from Ikonas to SGI 4D+ machines.
It worked completely as advertised. I started out just using it to read a settings file. But then I realized that I could use the REPL to change the settings on the fly. After that, I wrote a flexible GUI library, then I was writing core paint functionality in it. It wasn't fast enough for hardcore image processing, although I prototyped a lot of stuff in it before converting to C, but it was dynamite for gluing things together.
My program somehow upended itself, going from a big chunky main loop to lots of little functions in C, glued together with ATLAST. It was almost magical -- I got rid of so much C code and I could add new stuff in minutes instead of hours!
The GUI was a sort of "Tektronix-chic", with flat buttons and LED style numeric readouts. It was completely defined in ATLAST so I could easily change layouts and functions without a recompile.
The "chassis" of zPaint (which included ATLAST) was later used for two commercial products -- zScope (waveform monitor and vectorscope) and zMatte (chromakey with spill suppression). Although it defined the user interfaces for both of those programs, the REPL wasn't exposed to the user (although the zscope manual had a very detailed explanation of how the setup file worked).
Unfortunately, they were both kind of niche products (especially on expensive, niche machines), but I do know zScope was used by Digital Domain in their film scanning pipeline for the "Apollo 13" movie.
Using ATLAST was a very pleasant experience. It integrated very well with ANSI C of that time and it was very compact. The documentation was absolutely stellar and I never had any problems with it that I couldn't solve. It's showing it's age now -- I seem to recall modern compilers frown on some of the memory tricks it does.
Because of that, something like Lua is probably a better choice for new projects, but at the time, it was a huge step forward for me.
Thanks, Mr. Walker!
Among other things, it has the first implementation of what we would now call "autocomplete" that I know about.
If you're at all intrigued, I made a go at implementing the interface as described here: https://bitbucket.org/oofoe/flow
References at the bottom of the page. I actually contacted the Stanford University Library to get them to send me copies of his journal pages and papers so I could implement it.
The normal unit of editing work in original Forth was a 1024 byte "page" called a SCREEN. You would write your code in an editor that arranged it as 16 lines of 64 characters. At the touch of a key (usually), you could swap to the shadow screen which would have the documentation on it. By convention, shadow screen comments were placed on the same line as the code they were remarking on, so everything was usually co-located.
By abusing autorepeat, it was even possible to "flicker" the code and documentation to see both at once.
Something like CWEB or org-mode permits interleaving code with comments, but it's one dimensional and breaks your flow when editing.
1) Have standards that don't change appreciably. I first wrote the system in the early days of the Web and put it into full production at or about 1997. The fact that HTTP, CGI and SQL didn't change much and continued to be supported helped immeasurably.
2) Use a platform that you can manage effectively. We started with SGI IRIX, then moved it to Linux, where it spent most of its life. That let us move it from machine to machine and finally a datacenter. This would have been more difficult on an OS with a commercial pressure to upgrade.
3) Be lucky with your language choice. I used Perl 5, which had just come out at the time. I started on Perl 4, but the OOP features of 5 were very attractive (was heavily influenced by articles I read about SmallTalk at the time). Because Perl 6 never really happened (for me), I avoided the Python 2.x/3.x problem.
4) Make it documentable. Every code object in the system could be easily documented (the editor included a comment field for everything, which could be automatically extracted to provide developer help). Not everyone who worked on the system used it, but I did, which made it easier to figure out what was going on years after I had been doing other things.
5) Make it straightforward. Not sure that's the best way to put it, but after I left the company, the system suffered a good chunk of updates and rewrites by people who knew more or less what they were doing, but because they had to remain compatible with the original, fairly simple architecture, I was always able to pick up the thread when I did contract maintenance on it.
6) Security is a process. At the time I wrote it, it was... let's say "fairly" secure. Some of the updates/rewrites badly degraded the capability-based security it had (the maintainers didn't understand it and thought it was decreasing performance (which, to be fair, it was), so my original security thinking was rolled under the pressure of customer requests and deadlines.
Hope that helps!
So, even if I pay for this wonderful book (and it /is/ wonderful!) and nobody else/not enough other people do... And then it's gone!
When I was getting my license, I asked another pilot how much money it would take.... "All of it."
Also after you've done the homework, make sure you consult with your teacher about things that troubled you. Having battled your way through so many examples, you will be able to appreciate their explanation better than if you never tried them.
Good luck!
Of course I wrote a number of simple utilities, but I also did several large and comprehensive applications with complete user interfaces. I could staple together a fully styled interface with custom widgets in an afternoon compared with (at best) several days for equivalent functionality with other toolkits. Most of my large programs communicated with our production management database using XMLRPC.
The GUIs including things like a full graphical Avid-style editorial timeline, a multi-panel interface for managing data on the review playback system, one that mimicked the playback system interface (complete with reflections and drop shadows) to make the operator feel at home... Even one with a wise cracking virtual assistant that guided the operator through the task. All of these were operational and bug free in a fraction of the time that would have been consumed by Python/wx.
Just as important as simple and flexible GUIs were the built in parsing, binary and image processing. I could make a shot slates (images with text noting the shot number and production) quickly and easily because anything you could show in the GUI could be exported as an image. I did complete stereo audio processing for Editorial inside REBOL with no external libraries -- it was simple and fast. When I later had to replicate this utility in Python I finally threw up my hands and shelled out to sox.
In general, these tools were rock solid, fast, easy and attractive to use.
So it's a great language, and Red seems like it will be a worthy successor. The learning curve to use it effectively is a bit steep because it has many differences from ALGOL derived languages. But once you figure it out, you'll never want to give it up!
Unfortunately, once the tube reached operating temperature, his painstakingly hand drawn traces and glued down components delaminated. However, it shows that people were thinking about that sort of thing.