To extend your analogy: if the house is a listed building (UK concept; apparently US equivalent is listed in National Register of Historic Places), by law you cannot just tear it down. You need to do much more work to renovate what can be done without disturbing the original structure. This obviously costs much more and is generally done by different specialists, who have harder job and hence are better paid. So the question comes back to: what kind of work do you want to do...
And, of course, the next level of procrastination is to develop your own programming language, which you will use to write the engine to use in creating the game :-)
Definitely hats off to Jon for pulling it off - he had a lot of focus and some previous experience - and it also helps to have re$ource$ from past successful games. For many of us, the lure of developing better tools, rather than the end product, proves to be too strong to resist. At least Jon stopped short of developing own OS :-)
True for many, but I actually have been acquiring some computing books I had enjoyed reading in my youth (e.g. Organick's Multics). Perhaps living permanently abroad strengthens nostalgia...
Thanks for feedback, in some cases, we use a NLP lib to detect to language of the word since we support multiple languages, this may be due to language detection failed on some words.
Absolutely. As an Electrical Engineer turned software guy, Ohm's/Kirchhoff's laws remain as valid and significant as when I was taught them 35 years ago. For software however, growth of hardware architectures/constraints made it possible to add much more functionality. My first UNIX experience was on PDP-11/44, where every process (and kernel) had access to an impressive maximum of 128K of RAM (if you figured out the flag to split address and data segments). This meant everything was simple and easy to follow: the UNIX permission model (user/group/other+suid/sgid) fit it well. ACLs/capabilities etc were reserved for VMS/Multics, with manuals spanning shelves.
Given hardware available to an average modern Linux box, it is hardly surprising that these bells and whistles were added - someone will find them useful in some scenarios and additional resource is negligible. It does however make understanding the whole beast much, much harder...
Indeed. Coming from UNIX tools (sed/awk/sh/grep/tr etc), perl had a lot of appeal and almost intuitive syntax - alternatives in the '80s being C, awk, or if you were unlucky, FORTRAN IV without string type :-). The benefit of having a single language with all of the functionality of these tools was amazing at the time and ability to use familiar syntax was a benefit. However expectations for programming languages grew somewhat since...
Does anyone have experience using any of these for scientific paper PDFs, in particular containing equations (I'm guessing graphs are still well beyond their reach)? The workflow for these seems to involve converting PDF->text...
Could be worse of course: Multics (the first system with hierarchical names) used greater-than (>) as separator. Unix/DOS use of slashes gives us the sane pipeline/redirection syntax we all love (see [1] for the Multics redirection syntax).
I understand what you mean (although I "grew up" on UNIX, don't find this a problem); however, it would be better if the long (i.e. readable) options were prefixed by double dash to follow usual UNIX convention.
Using single dash for single character options allows you to combine them, which is really useful (if you do remember these options of course), so `-exc` means `-e -x -c` etc.
Excellent Sci-Fi yarn, with nostalgic references. I particularly liked the VAX-11 and LISP reference ("ideograms in a formal language full of parentheses")
reply