6,363 karma · joined August 30, 2013
This has allowed both to grow in functionality, year after year. Code written by users wanting particular capabilities has led to so many fantastic enhancements. No one user or committee could anticipate the many ways that these programs could be extended. Although, it would be nice if these systems could be cleaned up and modernized, this is only a dream. In practice, nobody has the time to start over on these enormous bodies of work comprising millions of lines of code.
It's too bad, because it's a joy to use ether of these system once you've spent enough time reading their extensive documentation and puttered around with them for a few years, but their eccentricities and anachronisms keep them out of the hands of many users.
Experiments on the development of the visual system in cats revealed that seeing only vertical edges and not horizontal edges while kittens made their perceptions of horizontal edges as adults less sensitive. I suppose that there is similar development of sensitivity to a certain frequencies in humans.
“The second special character, #, is substituted by the tally of format arguments yet abiding their consumption.”
His friends wanted him to give them the app, because they were his friends. His interesting perspective was that they should be willing to pay him more for the app because he was their friend (but he was willing to sell them the app for the official price).
If your friend wanted to he could gift you an interest in the start up if he wanted to. Isn’t it a kind of symmetric situation.
I worked as an OS Architect at IBM and then Chief Scientist at a very successful startup. Subjects like analysis of algorithms, memory management, optimizing disk access, search tries, random number generation, and many more found in TAOCP have all been useful in my professional life. I've had to give many technical presentations and to present my designs to committees of experts and CS professors. Knuth wasn't the only source of my preparation for this kind of work, but he was a very important source.
Are there better books on algorithms? Maybe. I also like the popular Introduction to Algorithms [1], Sedgwick's Algorithms [2], and Skeina's Algorithm Design Manual [3]. All of these are good and all of them sit on the shelf right next to Knuth's books. Depending on the subject, any one of these might have the best treatment. BTW, Sedgwick was a Ph.D. student of Knuth.
To keep up with the literature I also recommend a membership in the ACM with access to their digital library.
[1] Thomas H. Cormen , Charles E. Leiserson, et al. (2022), Introduction to algorithms, MIT Press.
[2] Robert Sedgewick and Kevin Wayne, (2011), Algorithms, Addison-Wesley.
[3] Steven S. Skiena, (1997), The algorithm design manual, Springer.
I'm always impressed with Emacs users that are capable of such discipline. I've use Emacs well over forty years, with only a few years of interruption, but I have never had a stable or well organized configuration. It's inspirational to see other's use of Emacs.
I'm disorganized, and I'm a hoarder (right now, my bedroom has at least 100 books stacked on the floor in different piles). Like my fluid Emacs configuration, the books are all attractive possibilities of what to read or try out next.
The idea of using bitmaps for retrieval on multiple indexes isn't new. Not surprisingly Knuth has a good discussion of the technique [Knuth], it was explained very well with a nice illustration of using notched recipe cards that is worth taking a peek at.
-- straying off topic below this line --
One surprising note, Calvin N. Mooers invented zatocoding in 1947. This technique used the notched cards for information retrieval and cited by Knuth under the subsection superimposed coding. Calvin N. Mooers went on to invent the "Reactive Typewriter" in the 1960s. This was an visionary implementation of how users might interact with computers using a terminal device (like a teletype). Mooers' Reactive Typewriter was programmed using a language he invented named TRAC.
TRAC is a macro based language. It, like the roughly contemporaneous GPM of Christopher Strachey (1965), is a Turing complete language based on macros that can define other macros, etc. I learned about TRAC in the mid 1970s from Ted Nelson's book Computer Lib/Dream Machines [Nelson]. It was one of three languages featured in that book. A fun little book, Etudes for Programmers, which I bought in 1978 inspired me to implement a version of TRAC. It's a nice exercise.
Many years later (I believe it was 1991), during an Open Software Foundation meeting in Cambridge, Massachusetts, I got to meet Mooers in person, he was sitting in the front row during a presentation, and I got to speak with him briefly afterwards.
By the way, Christopher Strachey wrote the first paper on the concept of time-sharing in 1959 and in the 1970's with Dana Scott is credited with coming up with the important development in the theory of programming languages known as Denotational Semantics.
[Knuth] Donald Knuth. (1973).The Art of Computer Programming, Vol 3/Sorting and Searching. Section 6.5, Retrieval on Secondary Keys. Addison-Wesley.
[Nelson] Theodor H Nelson. (1974). Computer lib : you can and must understand computers now. ISBN 0893470023. OCLC 11182412. https://en.wikipedia.org/wiki/Computer_Lib/Dream_Machines
[Strachey] https://en.wikipedia.org/wiki/Christopher_Strachey#cite_note...
[Wetherell] Charles Wetherell, Etudes for Programmers, Prentice Hall, 1977, https://www.amazon.com/Etudes-Programmers-Charles-Wetherell/...
Like other charitable contributions in the US, it is tax deductible. What that means is donating $100,000 has an after tax cost of around $50,000 depending upon one's tax bracket.
Yes there is accountability, and I usually receive a nice note from a couple of the undergraduates that have their undergraduate research projects funded by my modest endowment.
The system was originally called the IBM RT PC, but it wasn't really a PC, it was a Unix workstation. We were going for the market dominated by companies like Sun, HP, DEC, and Apollo. However, IBM already had a range of computers that were important to its business. At the low end, there was the PC-AT running OS/2, but we were shooting for higher performance and higher price point. We had to do this without threatening the interesting AS/400, a mid range business machine, and the large IBM/390 mainframe computers. Traditionally the IBM/390 systems required a dedicated machine room with an elevated floor and fire suppression equipment and so forth. However, they were interested in producing a desk-side 390 machine and didn't understand why we would want to have RISC hardware running Unix, instead of running a personal 390 architecture machine the size of a file cabinet with the VM/390 operating system. I think the name was picked to make us less threatening to other well established lines of business.
IBM's John Cocke did foundational work on RISC systems at IBM Research and won the Turing award while I was at IBM. He didn't work in Austin where AIX and the RT PC (RS/6000) development was going on, but he did stop by to talk to me a few times when he had business down the hall from my office in Austin. He was very interesting. I was just a young OS Architect, but I was working on things he was interested in. I got to work with other IBM Fellows too and learned a great deal from these talented people.
The plan for AIX was complicated because we were supposed to produce a working version of AIX at the same time that the hardware guys finished the PC RT (the first RS/6000 hardware). The compiler was developed at IBM Research (probably T.J Watson Research or Hawthorn Research centers I had occasion to visit both, but I can't remember which was the location for the PL.8 compiler) so the Austin team didn't have to worry about that.
AIX was based on Unix System V with some additions from 4.3BSD. Because we didn't have a stable hardware platform (as it was being developed along side our efforts) AIX adopted a micro-kernel, written in PL.8. The micro-kernel interacted with the hardware while providing a consistent abstraction of the hardware for a traditional Unix kernel written in C running on top of it. For example, the virtual memory manager was written in PL.8 and was in the micro-kernel as were the floating point exception handlers that took care of corner cases to provide a clean IEEE floating point abstraction to higher levels of the OS.
I didn't enjoy PL.8 very much. I had written PL/1 for assignments as an undergraduate years before, and although PL.8 was intended to keep just 80% of PL/1, it still wasn't my cup of tea. In truth, I never had to write any PL.8 code. I attended code reviews, but the team doing the VM was so good that I didn't need to dive into the code very deeply for the virtual memory manager.
Before the first release of AIX, I did work on integrating the Unix file system with the micro-kernel virtual memory management. I was also responsible for the design of the distributed file system DS.
Like you, I've always had an interest in compilers and programming languages. I happen to have John Cocke's 1970 book Programming Languages and Their Compilers. It's one of my oldest books on compilers.
It made me sad because I remember my fellow students, some rich, some poor, some from Philips Exeter, some like me from inner city Detroit schools, some from Asia some from Southern California. The thing was though, they weren't at all well rounded, the very trait that the president seemed so proud of in the current student body.
My classmates were eccentric, creative, nerdy, and most of all so intelligent. My math classes were full of genuses and savants. I still remember a fellow student in my second semester real analysis class (prerequisite chain was five semester long to get into the class: 1yr Calc -> 1 Semester DiffEq -> 1st semester real analysis -> 1 semester complex analysis); he was a Freshman and the best student in the class. Was he well rounded? I don't think so, but he was good at pinball and math.
Then the tragic Aaron Swartz affair.
They didn't sign the Chicago Letter [1].
I started meeting other MIT alumni that are disappointed with the direction MIT went as well.
Every year they still call me asking for more money.
Take back MIT. [2]
[1] https://www.insidehighered.com/news/2016/08/29/u-chicago-let...
For a mediocre player like myself, the advent of chess software that understands the game at a deep GM level has made studying chess fun. I can play computer opponents over and over, rapidly trying out the variations and seeing the outcome. I can ask for help, I can see what I'm doing wrong. I can easily spend an hour solving chess puzzles that improve my tactics.
To me, really not a good player, I enjoy chess more than ever; the article seems not to understand how chess software impacts the game.
The idea for RISC came from the realization that complex instructions in a CISC processor still had to run a set of lower level functions provided by the hardware. Consider, for example, the CISC architecture of the DEC PDP-11 computer (the system that Unix was originally developed on). It's indirect addressing modes where used to store or load from an address found in a register; this is a frequently used addressing mode on both RISC and CISC machines. However, the PDP-11, being a CISC machine, had eight variations of indirect addressing that automatically incremented/decremented the memory address in the register by one or two, before or after the location was used, etc.
As an assembly language programmer I liked this because it seemed like I could get more work done in a single instruction when I was iterating over an array of data. However, this is an illusion. The hardware still had to do the work so that single instruction using autoincrement indirect addressing took more time to run.
RISC machines generally have a few very simple load and store instructions to access memory and most other instruction work on registers alone. The underlying hardware is more straight forward. The instructions have more predictable running time. It is easier to perform out of order execution and speculative execution since the instructions can be arranged to use non-overlapping set of registers. For these reasons, the researchers developing RISC believed that they could achieve the same speed as CISC by running more instructions each running a bit faster than CISC instructions.
At this point, one might think that it is kind of a six of one, half-dozen kind of comparison where there is no clear advantage. But RISC has another advantage over CISC. Because the hardware is so straight forward it is easier for compilers to do very sophisticated optimizations. CISC computers often have special registers used by certain instructions differently than other registers. RISC computers usually have a larger number of basically identical registers. This makes register allocation much easier for compilers. On RISC computers, the instructions are often all of the same size again making it easier for compilers to arrange the instructions to fit better in the highest performing cache memory. The idea is that RISC is friendlier to compilers, and the combination of the fast simple instructions and advanced compilers will outperform the CISC machines.
This all sounds good and I consider IBM's POWER and the ARM architecture a success, but Intel is full of very smart people and they have proven that it's not entirely clear that RISC is better than CISC. Some complex instructions are just very useful, like Intel's vectorization instructions and the 2013 instructions that accelerate the calculation of SHA and SHA-256.
Lot's of factors are important in general purpose processor designs: virtual memory support (IBM's POWER has an inverted page table design for example), multiple compute units, virtualization, multicore, caches, good support for JIT compiler designs not just the AOT compilers envisioned when RISC was first being developed.
Intel's success and the need for backward compatability has shackled its current designs, and they have done very well despite this. Although I like the idea of a simpler faster architecture (RISC), Intel might be developing their own next generation processor architecture right now because this would fend off RISC-v and AMD too. They might come out with a new design that was RISC or CISC or a hybrid; it might even be wildly different like a very long instruction architecture.
My advice with respect to Emacs themes, the built in themes are quite good and especially the modus themes (and also the package ef-themes) both by Protesilaos Stavrou.
Page 6 of the report presents the ideas of the Vw-grammar. Protonotions, Notions, Metanotions, Hypernotions, Paranotions, Symbols, Productions and Production Trees are introduced to explain the grammar! I encourage readers to take a peek at almost any paragraph of the 70 page Algol 68 report and compare it to the The Programming Language Pascal Revised Report by Wirth [2],[3]. It's easy to see why Pascal became quite popular and Algol 68 never did.
Despite the fact that Algol 68 was too difficult to compile efficiently at the time, it introduced a number of features we take for granted today. See Richard Hamlet's Ignorance of Algol 68 Considered Harmful, [4].
On a personal note, I was a young Computer Scientist at the time these reports were published, and I miss how easy it was back then to keep up with the research that was going on at the time. Today it's impossible to be a generalist. So many independent and important branches have sprouted off the trunk of CS that everyone is a novice in major parts of the field.
[1] ACM SIGPLAN Notices, Volume 12, Issue 5, May 1977 pp 1–70, https://doi.org/10.1145/954652.1781176
[2] http://standardpascaline.org/The_Programming_Language_Pascal...
[3] https://www.amazon.com/Pascal-User-Manual-Report-Standard/dp...
[4] ACM SIGPLAN Notices, Volume 12, Issue 4, April 1977 pp 51-56, https://doi.org/10.1145/954654.954659
I'm not a metallurgist, but I did take a class at MIT on the subject and worked in a metallurgy lab for a couple of summers. The temperature of steel has an effect on the nature of fractures that can occur. Ductile fractures start at a crack and the steel deforms as the crack widens. This is the way most everyday metals under everyday circumstances act. The deformation absorbs energy and dissipates the forces acting on the metal. If this occurred in a beam, it might be observed to be deformed before a catastrophic failure happens.
Brittle fracture is different. A crack forms and it travels rapidly like breaking glass. Such fractures travel through the metal at the speed of sound through the metal (over 2000 ft/sec for steel). Pipelines in Alaska can experience such fractures. Such a fracture could travel thousands of feet because at the point of fracture there is no pressure drop at all (since that drop in pressure would travel at the slower speed of sound though natural gas).
This is a concern in Alaska because a piece of steel can exhibit ductile fracture behavior at ordinary temperature but transition to brittle fracture at lower temperatures. This transition point depends on the steel composition and its history. The history of the steel includes heat and mechanical treatments during it's production, but also the stresses put on it during its use such as welding, shaping and forming, vibration, and even exposure to radiation (which will occur in some parts of a submarine since they contain nuclear reactors). I have no idea how the steel was intended to be used, but conceivably there could be good reasons for the -100F requirement even if the steel was never going to come close to this temperature. (For example, I know nothing of the relationship of radiation embrittlement and the ductile-brittle fracture temperature transition.) So while the testing requirement sounds "stupid" it is perhaps even stupider to ignore it.
I had the pleasure of meeting Nicklaus Wirth around 1977 at Texas Instruments. I worked in a department that had developed a PASCAL compiler for TI processors; Wirth had been invited to give us a demonstration of his Pascal/Modula based system. I don't remember the details of the impressive presentation, but I do remember him telling the joke about his name: in Europe they call him by name (sounds like "Virt") while Americans call him by value saying "Worth" for his last name.
I enjoyed his books a great deal and read every published paper of his that I could get my hands on. I learned a great deal from his clear writing during formative years in my programming career.
--- below this line, I stray off topic ---
[1] For example, the Algol 68 Report used a two-level grammar (Van Wijngaarden grammar) to describe the syntax of Algol 68. Such a two level grammar had one set of rules that would expand into an arbitrarily large different set of productions describing the syntax of an Algol 68 program. Vw grammars are capable of defining recursively enumerable languages. In the Algol 68 report it was hoped that more language features could be precisely described by such a formal grammar rather than by prose that stated requirements like "variable must be declared before use".
While admirable, such a goal isn't practical because the set of recursively enumerable languages is essentially equivalent to the set of Turing machine programs or Chomsky's type 0 grammars. We don't want compilers to be burdened with solving the impossible to solve halting problem.
However, I can't imagine riding a bike to work on where I live. First, it's too dangerous. The modern age of cell phones is very different that the days when I grew up when parents allowed kids to ride their bikes in the street to school every day. Distracted drivers now seem to mow down bicyclists regularly.
Furthermore, the cities I've lived in have weather too extreme to ride in:
Buffalo -- on average it snows during 6 months of the year, around 90+ inches/year (242cm/year).
Boston -- very cold four months of the year. I recall 30 consecutive days with a high below freezing. It also has high winter wind speeds (some days as high as 14mph (23km/hr) in December) and rainfall.
Dallas -- averages 97 days per year with a high over 90 degrees (32 degrees Celsius)
Houston -- averages 99 days per year with a high over 90 degrees (32 degrees Celsius) and very humid. Its also 637.4 square miles (1,651 km^2) in size making it very likely that one will have a long sweaty commute.
Austin -- averages 108 days per year with a high over 90 degrees (32 degrees Celsius)
Detroit -- one block from home I was beaten off of my bike by an organized gang of bicycle thieves that took my bike and were never caught. The weather isn't concussive to bike riding either.
There are cities in the US that have better weather. I enjoyed walking to school the year I lived in Marin County in California.
Perhaps we could generate a Martian artificial planetary magnetosphere, but I don’t know how.
See [1] from NASA.
[1] https://science.nasa.gov/science-news/science-at-nasa/2001/a...
The peculiar vagueness of the early C standards with respect to integers was probably due to the variety of hardware we used in the 1970s. For example:
The CDC 6000/7000s had 60-bit words, ones compliment arithmetic, 6 bit chars (but machine addresses were only of the 60 bit words).
The peripheral processors of the CDC machines (responsible for I/O) had 12-bit words as I recall.
IBMs very popular 360 mainframes supported several native hardware number formats: twos complement, unsigned, zoned decimal (one decimal digit per 8-bit byte), and packed decimal (two digits per byte).
I believe C was first developed on the DEC PDP-11. This was a very popular computer with 16 bit words and 8 bit bytes. It was twos complement, but mixed endianess (big endian for the 16 bit words making up a 32-bit long and little endian for the bytes in the 16-bit words).
Other DEC computers of the 1960s used 12 bit program counters and accumulators; I did some assembly language programming on the PDP-6 (it cost $300,000 back then and 24 were sold).
I seem to recall using a system with 18 bit registers and 9 bit bytes, but I can’t remember the details.
One system that I did assembly language programming on for a year was the TI 960. This machine was notable because it had two separate 64KB address spaces, one for data and one for instruction, known as a Harvard architecture instead of Von Neumann architecture. The advantage of the Harvard architecture was that a program couldn’t inadvertently modify the code it was running, a frequent and difficult to untangle occurrence when programming assembly. The Von Neumann architecture became dominant because it didn’t chop the available memory in two and partly because self modifying code was believed to be sometimes useful (yikes).
I like my friends, but they are wine snobs.
I was creative back then, and I remember envisioning VR very similar to today's VR. After studying visual displays and how they were projected on screens for pilots in flight simulators I presented an idea to my computer graphics class that we could put small displays on a helmet one for each eye and have motion and orientation sensors on the helmet to simulate what a pilot would see in 3D as he looked around the virtual cockpit. I said we could even develop multiuser experiences in a big gymnasium with a virtual landscape displayed in each participant's helmet displays. My professor dismissed the ideas as fanciful, and I moved on to other ideas.
It was easy to imagine a future where lots of people owned personal computers and had modems that could be used to log into servers over dial-up lines; I remembered thinking that player verses player games would become a thing because the number of pairs of users online would grow much faster than the number of users [N(N-1) vs N]. But here, I was imagining a single multiuser server, not an internet.
I was aware of the ARPA NET and had even tried out the PLATO timesharing system. I had a copy of Ted Nelson's interesting book of rambling ideas titled Dream Machines where he talked about hypertext, Xanadu, etc. I was also a teaching assistant for a telecommunications course where we talked about the possibility of fiber to the home replacing analog phone lines and providing bandwidth that could replace video rentals for entertainment.
All of these hints foreshadowed the development of the internet, but I didn't see it and neither did any of my colleagues. The scale and importance of the internet just eluded me.
As late as 1989 when I started a software company, it wasn't clear that the company should have it's own domain name!
Spiders aren't the only wildlife to be concerned about here in Central Texas, scorpions and giant centipedes also wander around the house. Fortunately, the poisonous snakes of central Texas (rattlesnake, copperhead, coral snake, and water moccasin) haven't ventured inside. Of course we have killer bees and fire ants in the area, but you can usually outrun them--if you're in good shape. The only poisonous creature found in the US that isn't found here is the Gila monster. The good news is we don't have Grisly bears, maybe the mountain lions scare them away.
That may be so, but nevertheless, I dread going to dinner at fine restaurants with some of my friends because I've had to pick up a $1200 tab due to their over the top wine selections. Furthermore, I enjoy wine, but I rarely drink more than one glass.
Those that have taken Integral Calculus may be thinking that solving DEs sounds akin to integration where one may have to apply substitutions, integration by parts, trigonometric substitutions, or partial fractions. Yes Calculus requires learning a bag of trick too, buts its a small bag of simple tricks with wide applicability. So many of the functions one needs to integrate succumb to this small bag of tricks that it's almost fun to hone ones technique. A class on elementary differential equations is just depressing.
To be fair, differential equations are important. Physical phenomena are often best described by differential equations. Fortunately, programs like Mathematica can be used to tackle real world differential equations one way or another (perhaps with numerical methods) to obtain solutions.
I was fortunate to have my Probability course (sadly, not my differential equations course) taught by Gian-Carlo Rota.
[1] https://www.amazon.com/gp/product/074320011X/ref=dbs_a_def_r...