In 2023, I read a lot of longer, technical papers for which I took notes (as usual) but that don't really qualify as books, as such. Some of them were of what some might call book-length, though. I present these with original---though very sparse---comments amid the citations I found interesting and relevant from those documents. <dl dt_class="field"> Programming <ol> <a href="#usability">The Usability of Advanced Type Systems: Rust as a Case Study</a> (January, 2023) <a href="#nato1968">nato1968 - Software Engineering</a> (October, 1968) <a href="#IEEE">IEEE-Annals - A Brief History of Software Engineering</a> (February 2008) <a href="#Compiling">Compiling Swift Generics</a> (October 2022) <a href="#Ritchie">How did Dennis Ritchie Produce his PhD Thesis? A Typographical Mystery</a> (June 2022) <a href="#Capability">Capability Myths Demolished</a> (2003) <a href="#Serverless">Serverless Computing: One Step Forward, Two Steps Back</a> (December 2018) <a href="#Algebraic">Algebraic Effects for Functional Programming</a> (August 2016) <a href="#Generalized">Generalized Algebraic Data Types and Object-Oriented Programming</a> (August 2005) <a href="#Fexprs">Fexprs as the basis of Lisp function application or <c>$vau</c>: the ultimate abstraction</a> (August 2010) </ol> Economics <ol><a href="#Regulating">Regulating the Sharing Economy</a> (June 2016) <a href="#Political">Political Aspects of Full Employment</a> (Spring 1942) <a href="#Crypto">Crypto is the Mother of All Scams and (Now Busted) Bubbles While Blockchain Is The Most Over-Hyped Technology Ever, No Better than a Spreadsheet/Database</a> (October 2018) <a href="#Housing">The Housing Bubble and the Great Recession: Ten Years Later</a> (September 2018) </ol> </dl> <img src="{att_link}stack_of_technical_papers.webp" href="{att_link}stack_of_technical_papers.webp" align="none" title="Stack of technical papers" scale="75%"> <h id="usability">The Usability of Advanced Type Systems: Rust as a Case Study</h> <a href="https://arxiv.org/abs/2301.02308" author="Kasra Ferdowsi" source="Arxiv" date="January 5, 2023">The Usability of Advanced Type Systems: Rust as a Case Study</a> <bq caption="Position 4-5">[...] a human-centered evaluation of these type systems and their usability was all but absent, with empirical evaluations limited to testing their expressiveness in programs written by experts, i.e. the creators of the type system.</bq> <bq caption="Position 38-42">Linear Types enable memory management of mutable values without Garbage Collection. If a value cannot be copied or implicitly discarded and it must be used exactly once, then we can reclaim its memory after it is used. This handles memory management, and prevents use-after-free and double-free bugs. By prohibiting aliasing, Linear Types also solve the problem of reasoning about mutations, both in single-threaded code (where aliased references are a notable source of bugs), and in multi-threaded code (where aliasing can lead to race conditions).</bq> <bq caption="Position 87-89">[...] these types were neither widely adopted, nor evaluated on real users. Instead, each extension, implementation or application of these types was only evaluated by the designers of the system, who programmed real-world applications with their type system to argue for its expressiveness</bq> <bq caption="Position 98-100">Linear, Region and Ownership Types are related by their attention to memory management and safety. Each realized that type systems could be used to help programmers reason about complex programs, prevent various errors in using aliased or freed references, and offer a provably correct solution to memory management without the need for runtime checks or garbage collection.</bq> <bq caption="Position 330-332">Note that both of these programs are “safe”, and a more advanced type system involving dependent types could in theory statically verify the safety of Fig. 3a, but the current limitations of the type system means that developers need to learn, not just the rules of Ownership, but how the borrow-checker verifies them.</bq> <bq caption="Position 368-371">In the 5 applications they inspected, [Qin et al. 2020] found 4990 uses of unsafe, with a further 1581 unsafe code regions in the standard library, and concluded that unsafe code is used “extensively”. Though they note that it is “unavoidable in many cases” and “usually for good reasons”, including interfacing with existing libraries written in other unsafe languages such as C, and performance improvements by a factor of 4 or 5.</bq> <h id="nato1968">nato1968 - Software Engineering</h> <a href="http://homepages.cs.ncl.ac.uk/brian.randell/NATO/nato1968.PDF" author="Peter Naur and Brian Randell" source="" date="October 1968">SOFTWARE ENGINEERING Report on a conference sponsored by the NATO SCIENCE COMMITTEE</a> <bq caption="Position 25-28"><ul>the problems of achieving sufficient reliability in the data systems which are becoming increasingly integrated into the central activities of modern society the difficulties of meeting schedules and specifications on large software projects the education of software (or data systems) engineers</ul></bq> The problems that confront us today have been with us since 1968. We have improved our approach, but it's a bit sobering to think how accurately these 56-year-old bullet points capture our current predicament. <h id="IEEE">IEEE-Annals - A Brief History of Software Engineering</h> <a href="https://annas-archive.org/md5/f4094360b5f45fd31daf6b5e6bfe8f74" author="Niklaus Wirth" source="Anna's Archive" date="February 2nd, 2008"> A Brief History of Software Engineering</a> <bq caption="Position 8-13">[...] the rapid growth of computing power made it possible to apply computing to ever more complicated tasks. This trend dramatically increased the demands on software engineers. Programs and systems became complex and almost impossible to fully understand. The sinking cost and the abundance of computing resources inevitably reduced the care for good design. Quality seemed extravagant, a loser in the race for profit. But we should be concerned about the resulting deterioration in quality. Our limitations are no longer given by slow hardware, but by our own intellectual capability. From experience we know that most programs could be significantly improved, made more reliable, economical and comfortable to use.</bq> <bq caption="Position 10-12">The sinking cost and the abundance of computing resources inevitably reduced the care for good design. Quality seemed extravagant, a loser in the race for profit. But we should be concerned about the resulting deterioration in quality. Our limitations are no longer given by slow hardware, but by our own intellectual capability.</bq> <bq caption="Position 58-60">From the point of view of software engineering, the rapid spread of C represented a great leap backward. It revealed that the community at large had hardly grasped the true meaning of the term “high-level language” which became an ill-understood buzzword.</bq> <bq caption="Position 61-64">Computer systems are machines of large complexity. This complexity can be mastered intellectually by one tool only: Abstraction. A language represents an abstract computer whose objects and constructs lie closer (higher) to the problem to be represented than to the concrete machine. For example, in a high-level language we deal with numbers, indexed arrays, data types, conditional and repetitive statements, rather than with bits and bytes, addressed words, jumps and condition codes.</bq> <bq caption="Position 72-74">C provided freedom, where high-level languages were considered as straight-jackets enforcing unwanted discipline. It was an invitation to use tricks which had been necessary to achieve efficiency in the early days of computers, but now were pitfalls that made large systems error-prone and costly to debug and “maintain”.</bq> <bq caption="Position 84-87">The group of Ken Bowles at UC San Diego built a text editor, a file system, and a debugger around the portable Pascal compiler (P-code) developed at ETH, and they distributed it for $50. So did the Borland company with its version of compiler. This was at a time when other compilers were expensive software, and it was nothing less than a turning-point in commercializing software. Suddenly, there was a mass market. Computing went public</bq> <bq caption="Position 88-90">The craft of programming turned to “hacking. Methods were sought to systematize, if not construction, then at least program testing and documentation. Although this was helpful, the real problems of hectic programming under timepressure remained.</bq> <bq caption="Position 88-91">Methods were sought to systematize, if not construction, then at least program testing and documentation. Although this was helpful, the real problems of hectic programming under time pressure remained. Dijkstra brought the difficulty to the point by saying: Testing may show the presence of errors, but it can never prove their absence.</bq> Add this to the workshop presentation <bq caption="Position 106-109">Just as structured programming had been the guiding spirit behind Pascal, modularization was the principal idea behind the language Modula-2, the successor of Pascal, published in 1979 [15]. In fact, its motivation came from the language Mesa, an internal development of the Xerox Research Lab in Palo Alto, and itself a descendant of Pascal. The concept of modularization and separate compilation was also adopted by the language Ada (1984), which was also based largely on Pascal. Here, modules were called packages.</bq> <bq caption="Position 115-117">It is no exaggeration at all to claim that the modern computing era started in 1975 with the Alto. The Alto caused nothing less than a revolution, and as a result people to-day have no idea, how computing was done before 1975 without personal, highly interactive workstations. The influence of these developments on software engineering cannot be overestimated.</bq> <bq caption="Position 128-129">Languages appeared supporting this model, among them Smalltalk (Goldberg and Kay, 1980), Object-Pascal (Tesler, 1985), C++ (Stroustrup, 1985), Oberon (Wirth, 1988), Java (Sun, 1995) and C# (Microsoft, 2000).</bq> <bq caption="Position 137-140">I am overwhelmed, when I compare this with the first, stand-alone minicomputer that I worked with in 1965, a DEC PDP-1: Clock rate, < 1 MHz, memory of 8K word of 18 bits, drum storage of some 200 KB. It was time-shared by up to 16 users. It is a miracle that some people insisted in believing that one day computers would become powerful enough to be useful.</bq> <bq caption="Position 140-144">In the 1990s, a phenomenon started to spread under the name of Open Source. The distrust against huge systems designed in industrial secrecy became manifest. A wide community of programmers decided to build software and to distribute their products for free through the Internet. Although it is difficult to recognize this as a sound business principle – making the idea of patents obsolete – the bandwagon turned out to be rather successful. The notions of quality and responsibility in case of failure seemed irrelevant. Open Source appeared as the welcome alternative to industrial hegemony and abrasive profit, and also against helpless dependence.</bq> Patents are not sound business principle. They are a business principle. The revolution has to start somewhere. <bq caption="Position 150-155">Surely, software engineering has profited too from the many sophisticated development tools. But the quality of its products hardly reflects signs of great progress. No wonder: After all, the increase of power was itself the reason for the terrifying growth of complexity. Whatever progress was made in software methodology was quickly compensated by higher complexity of the tasks. This is reflected by Reiser’s “law”: “Software is getting slower faster than hardware is getting faster”. Indeed, new problems have been tackled that are so difficult that engineers often have to be admired more for their optimism and courage than for their success.</bq> <bq caption="Position 156-160">The consequence is waste of cheap resources – processor cycles and storage bits – resulting in inefficient code and bulky data. This waste has become ever-present and represents a grave lack of sense for quality. Inefficiency of programs is easily covered up by obtaining faster processors, and poor data design by the use of larger storage devices. But their side effect is a decrease of quality – of reliability, robustness, and ease of use. Good, careful design is timeconsuming, costly. But it is still cheaper than unreliable, difficult software, when the cost of “maintenance” is not factored</bq> <bq caption="Position 162-165">A primary effort must be education toward a sense of quality. Programmers must become engaged crusaders against home-made complexity. The cancerous growth of complexity is not a thing to be admired; it must be fought wherever possible [17]. Programmers must be given time and respect for work of high quality. This is crucial and ultimately more effective than better tools and rules.</bq> <h id="Compiling">Compiling Swift Generics</h> <a href="https://download.swift.org/docs/assets/generics.pdf" author="Slava Pestov" source="Swift.org" date="October 17, 2022">Compiling Swift Generics</a> <bq caption="Position 133-136">The standard ownership semantics for a Swift function call are defined such that the caller retains ownership over the parameter values passed into the callee, while the callee transfers ownership of the return value to the caller. This means that the identity(_:) function cannot just return the value x; instead, it must first create a logical copy of x that it owns, and then return this owned copy. This is achieved by incrementing the string value’s buffer reference count via a call to a runtime function.</bq> <bq caption="Position 145-150">As the joke goes, every problem in computer science can be solved with an extra level of indirection. The calling convention for a generic function takes runtime type metadata for every generic parameter in the function’s generic signature. Every type in the language has a reified representation as runtime type metadata, storing the type’s size and alignment together with function pointers implementing the move, copy and destroy operations. The generated code for a generic function abstractly manipulates values of generic parameter type using the runtime type metadata provided by the caller. An important property of runtime type metadata is identity; two pointers to runtime type metadata are equal if and only if they represent the same type in the language.</bq> <bq caption="Position 173-174">Definitions of generic functions are always visible to the specializer within their defining module. Shared library developers can also optin to exporting the body of a function across module boundaries with the @inlinable attribute.</bq> <bq caption="Position 237-239">The witness table for this conformance references the witness (indirectly, because the witness is always wrapped in a thunk, which is a small function which shuffles some registers around and then calls the actual witness. This must be the case because protocol requirements use a slightly different calling convention than ordinary generic functions).</bq> <bq caption="Position 269-270">While metadata for generic parameters is passed in directly, for dependent member types the metadata is recovered from one or more witness tables provided by the caller.</bq> <bq caption="Position 415-418">Operator symbols are declared at the top level of a module. Operator symbols have a fixity (prefix, infix, or postfix), and infix operators also have a precedence group. Precedence groups are partially ordered with respect to other precedence groups. Standard operators like + and * and their precedence groups are thus defined in the standard library, rather than being built-in to the language itself.</bq> <bq caption="Position 523-525">The request evaluator framework was first introduced in Swift 4.2 [ 5]. In subsequent releases, various ad-hoc mechanisms were gradually converted into request evaluator requests, with resulting gains to compiler performance, stability, and implementation maintainability.</bq> <bq caption="Position 640-642">The Swift ABI was formally stabilized in Swift 5.0, when the standard library became part of the operating system on Apple platforms. Library evolution support and textual interfaces became user-visible features in Swift 5.1</bq> <bq caption="Position 727-729">The difference between the type representation Array<int> and the type Array<int> is that the type representation only stores identifiers, with no connection to the declaration of Array and Int. The semantic type points at the declarations themselves.</bq> <bq caption="Position 932-934">The utmost care must be taken when working with type variables because unlike all other types, they are not allocated with indefinite lifetime. Type variables live in the constraint solver arena, which grows and shrinks as the solver explores branches of the solution space. Types that contain type variables, and other structures that recursively contain such types, also need to be allocated in the constraint solver arena.</bq> <bq caption="Position 2007-2009">In contrast, the second case would introduce significant complexity to the language design, by allowing “generic protocols” with more generic parameters than just the protocol Self type. Such a protocol would be what Haskell calls a “multi-parameter type class.” Unlike the prior generalizations this one carries profound implications and tradeoffs and it is not clear that it belongs in the Swift language.</bq> <bq caption="Position 2006-2009">The first case is a relatively straightforward; the non-generic declaration contexts acts as a namespace to which the protocol declaration is scoped. In contrast, the second case would introduce significant complexity to the language design, by allowing “generic protocols” with more generic parameters than just the protocol Self type. Such a protocol would be what Haskell calls a “multi-parameter type class.” Unlike the prior generalizations this one carries profound implications and tradeoffs and it is not clear that it belongs in the Swift language.</bq> <bq caption="Position 2103-2109">[...] imagine if there were two different conformances of some concrete type K to Hashable. Then it would be possible for two different modules to construct values of type Set<k> with incompatible hash functions; passing such a value from one module to the other would result in undefined behavior. For now, there’s no real answer to this dilemma. The compiler rejects duplicate conformance definitions if an existing conformance is statically visible, so this scenario cannot occur with Int and Hashable for instance, because the conformance of Int to Hashable in the standard library is always visible, so any attempt to define a new conformance would be diagnosed as an error. However, if the concrete type K is defined in some common module, and two separatelycompiled modules both define a conformance of K to Hashable, a module that imports all three will observe both conformances statically, with unpredictable results.</bq> <bq caption="Position 2117-2119">In the absence of proper compiler support for addressing this problem, there is a rule of thumb that, if followed by Swift users, mostly guarantees coherence. The rule is that when defining a conformance on an extension, either the extended type or the protocol should be part of the current module.</bq> <bq caption="Position 2123-2125">A conformance where neither the conforming type nor the protocol is part of the current module is called a retroactive conformance. Today, retroactive conformances are allowed without any restrictions. In a future compiler version, they might generate a warning.</bq> <bq caption="Position 2127-2132">A client might declare a subclass of BaseClass and conform it to MyProtocol, concluding this it is safe to do so because the conforming type, DerivedClass, is owned by the client, and thus this is not a retroactive conformance: 1 import OtherLibrary 2 3 class DerivedClass: BaseClass {} 4 extension DerivedClass: MyProtocol {} However, in the next version of the framework, the framework author might decide to conform BaseClass to MyProtocol. At this point, DerivedClass has two duplicate conformances to MyProtocol; the inherited conformance from BaseClass, and the local conformance of DerivedClass.</bq> <bq caption="Position 2397-2401">You might wonder why archetypes exist at all, when at first glance, they appear equivalent to a reduced type parameter together with a generic signature. In the case of primary archetypes at least, the reason is partly historical. However, the additional indirection provided by creating multiple generic environments from a single generic signature allows archetypes to represent abstract types which are not described by the generic parameters that are in the scope of a generic declaration, namely opaque return types and existential types.</bq> <h id="Ritchie">How did Dennis Ritchie Produce his PhD Thesis? A Typographical Mystery</h> <a href="https://www.cs.princeton.edu/~bwk/dmr/doceng22.pdf" author="David F. Brailsford, Brian W. Kernighan, William A. Ritchie" source="" date="2022">How did Dennis Ritchie Produce his PhD Thesis? A Typographical Mystery</a> <bq caption="Position 70-73">It may be hard for readers today to appreciate just how labor-intensive it was to prepare documents before the creation of word processing programs, when there were only mechanical typewriters—better than clay tablets or quill pens, to be sure, but any change of more than a few words in a document could require a complete retype. Thus most documents went through only one or two revisions, with handwritten changes on a manuscript that had to be laboriously retyped to make a clean copy.</bq> <h id="Capability">Capability Myths Demolished</h> <a href="https://srl.cs.jhu.edu/pubs/SRL2003-02.pdf" author="Mark S. Miller, Ka-Ping Yee, Jonathan Shapiro" source="" date="2003">Capability Myths Demolished</a> <bq caption="Position 70-72">By shifting to this new visualization, where the references are explicitly visible, we see a difference between the models that was previously obscured: the direction of the arrows. To see why this matters, let us consider how subjects and resources refer to each other.</bq> <bq caption="Position 78-81">In a capability system, each capability points from a subject to a resource. Consequently every capability can serve both to designate which resource to access, and to provide the authority to perform that access. This change provides us with the option to avoid introducing a shared namespace into the foundations of the model, and thereby avoid the complex issues involved in managing a shared namespace – issues rarely acknowledged as a cost of non-capability models.</bq> <bq caption="Position 88-90">Although Lampson’s definition of the access matrix does not prohibit the possibility of fine-grained subjects4, even in an ACL system, the difficulty just explained strongly motivates ACL systems to define subjects at a coarse granularity so as to keep the set of subjects relatively static.</bq> This is exactly what you end up doing. But it also applies to claims. <h id="Serverless">Serverless Computing: One Step Forward, Two Steps Back</h> <a href="https://arxiv.org/pdf/1812.03651.pdf" author="Joseph M. Hellerstein, Jose Faleiro, Joseph E. Gonzalez, Johann Schleier-Smith, Vikram Sreekanti, Alexey Tumanov and Chenggang Wu" source="Arxiv">Serverless Computing: One Step Forward, Two Steps Back</a> <bq caption="Position 94-95">[...] serverless computing today is at best a simple and powerful way to run embarrassingly parallel computations or harness proprietary services. At worst, it can be viewed as a cynical effort to lock users into those services and lock out innovation.</bq> <bq caption="Position 101-103">Recent studies show that a single Lambda function can achieve on average 538Mbps network bandwidth; numbers from Google and Azure were in the same ballpark [26]. This is an order of magnitude slower than a single modern SSD. Worse, AWS appears to attempt to pack Lambda functions from the same user together on a single VM, so the limited bandwidth is shared by multiple functions.</bq> <bq caption="Position 103-105">The result is that as compute power scales up, per-function bandwidth shrinks proportionately. With 20 Lambda functions, average network bandwidth was 28.7Mbps—2.5 orders of magnitude slower than a single SSD [26]</bq> <bq caption="Position 111-115">[...] two Lambda functions can only communicate through an autoscaling intermediary service; today, this means a storage system like S3 that is radically slower and more expensive than point-to-point networking. As a corollary, a client of Lambda cannot address the particular function instance that handled the client’s previous request: there is no “stickiness” for client connections. Hence maintaining state across client calls requires writing the state out to slow storage, and reading it back on every subsequent call.</bq> <bq caption="Position 120-121">[...] serverless functions are short-lived and non-addressable, so their capacity to cache state internally to service</bq> <bq caption="Position 121-124">FaaS routinely “ships data to code” rather than “shipping code to data.” This is a recurring architectural antipattern among system designers, which database aficionados seem to need to point out each generation. Memory hierarchy realities— across various storage layers and network delays—make this a bad design decision for reasons of latency, bandwidth, and cost.</bq> <bq caption="Position 132-134">[...] with all communication transiting through storage, there is no real way for thousands (much less millions) of cores in the cloud to work together efficiently using current FaaS platforms other than via largely uncoordinated (embarrassing) parallelism.</bq> <bq caption="Position 153-157">[...] we trained the same model on an m4.large EC2 instance, which has 8GB of RAM and 2vCPUs. In this setting, each iteration is significantly faster (0.14 seconds): 0.04 seconds to fetch data from an EBS volume and 0.1 seconds to run the optimizer. The same training process takes about 1300 seconds (just under 22 minutes), which translates to a cost of $0.04. Lambda’s limited resources and data-shipping architecture mean that running this algorithm on Lambda is 21× slower and 7.3× more expensive than running on EC2.</bq> <bq caption="Position 171-174">The first replaced Lambda’s role in the application with an EC2 machine to receive SQS message batches—this showed a latency of 13ms per batch averaged over 1,000 batches—27× faster than our “optimized” Lambda implementation. The second experiment used ZeroMQ to replace SQS’s role in the application, and receive messages directly on the EC2 machine. This “serverful” version had a per batch latency of 2.8ms—127× faster than the optimized Lambda implementation.</bq> <bq caption="Position 185-186">[...] there are two classical dual patterns to implement concurrent communicating systems: eventdriven execution over shared state (the natural FaaS approach), or message-passing across long-running agents with distributed state [16].</bq> <bq caption="Position 196-198">[...] communicating via cloud storage is not a reasonable replacement for directly-addressed networking, even with direct I/O—it is at leaste one order of magnitude too slow. “Pure” functional FaaS programming style exacerbates that expense to an inordinate degree, and should be avoided at all costs.</bq> <bq caption="Position 202-202">To model this, we implemented one of the simplest of these protocols in Python: Garcia-Molina’s bully leader election [7].</bq> Why always Python? Are there no numeric libraries in other languages? Of course not. C# 7 has SIMD and vectorization and parallelization. It has AOT in version eight. Why on Earth is Python still so popular? Is it the omly thing peope know? Is it inertia now? Are data scientists just shitty programmers withnofeel for memory or performance efficiency? It's kind of like the JS/Node everywhere thing. There are far, far better runtimes. We have LLVM. Why did the shitty hack win? <bq caption="Position 210-211">FaaS limitations favor operational flexibility over developer control, a theme we generally agree is critical to the scale and elasticity of the cloud—and a major design shift from the traditional data systems ethos.</bq> <bq caption="Position 213-217">Developers are forced to compose larger programs out of asynchronous tasks, with no guarantees like sequential consistency or serializability to reason about the semantics of global state mutation across tasks. These limitations can be challenging for developers used to writing sequential programs or transactions. But the result may be both healthy and manageable: this kind of “disorderly” loosely-consistent model has been at the heart of a number of more general-purpose proposals for scalable, available program design in recent years,</bq> <bq caption="Position 247-249">Any reasonable system design will need the ability to selectively co-locate code and data on the same side of a network boundary, whether that is done via caching/prefetching data near computation or pushing computation closer to data. Neither feature is provided in a meaningful way by today’s FaaS offerings.</bq> <bq caption="Position 264-266">[...] we see autoscaling (and hence pay per use) as a big step forward, but disappointingly limited to applications that can work over today’s hobbled provider infrastructure. We acknowledge that there is an enormous market of such “narrow” applications, many of which consist of little more than business logic over a database.</bq> <bq caption="Position 270-271">[...] serverless computing could produce a local minimum: yet another setting in which the compute and storage potential of the cloud is lost in the noise of refactoring low-tech and often legacy use cases.</bq> <bq caption="Position 274-276">We see the future of cloud programming as far, far brighter than the promise of today’s serverless FaaS offerings. Getting to that future requires revisiting the designs and limitations of what is being called “serverless computing” today.</bq> <bq caption="Position 284-286">High-level, data-centric DSLs—e.g., SQL+UDFs, MapReduce, TensorFlow—can make this more tractable, by exposing at a high level how data flows through computation. The more declarative the language, the more logical separation (and optimization search space) is offered to the infrastructure.</bq> <bq caption="Position 291-293">[...] recognizing hardware affinity does not mean that we advocate tight binding of hardware to services; the platform should make dynamic physical decisions about allocation of code to distinguished resources, based on logical performance requirement specs either provided by programmers or extracted from code.</bq> <bq caption="Position 298-300">[...] elasticity requirements dictate that these agents be virtual and dynamically remapped across physical resources. Hence we need virtual alternatives to traditional operating system constructs like “threads” and “ports”: nameable endpoints in the network. Various ideas from the literature have provided aspects of this idea: actors [11], tuplespaces [4] pub/sub [18] and DHTs [21] are all examples.</bq> <bq caption="Position 318-320">[...] if cloud programming is achieved via higher-level abstractions, it will offer the opportunity for program analysis and constraint enforcement that could improve security. However, some of our desired architectural improvements for performance in this paper make achieving security more difficult for the responsible parties.</bq> <h id="Algebraic">Algebraic Effects for Functional Programming</h> <a href="https://www.microsoft.com/en-us/research/wp-content/uploads/2016/08/algeff-tr-2016-v2.pdf" author="Daan Leijen" source="Microsoft">Algebraic Effects for Functional Programming</a> <bq caption="Position 491-497">It has long been recognized that one can selectively CPS transform only parts of the program that need it [8, 9, 37]. In our case, we only have to use CPS translation on those parts that may issue effectful operations. Moreover, since effects are tracked in the type system, we can use a type-directed selective CPS translation (as used by Scala [38] for example). We built on the translation by Nielsen [31] who introduces a sound selective CPS translation for the simply typed lambda calculus extended with callcc and throw. However, the translation by Nielsen applies to monomorphic effects only and we will see that in the presence of polymorphic effect variables the translation becomes more complex.</bq> <bq caption="Position 508-512">The built-in effects consist of exceptions (exn), non-termination (div), non-determinism (ndet), polymorphic state (st⟨h⟩), and general I/O operations (io). All of these are usually provided directly by the target system (like JavaScript) and can thus be directly compiled without needing CPS translation. This turns out to be a very important optimization as many (leaf) functions do not use any user defined effects and can thus be compiled directly – and implies there is no cost for effect handlers for any code that does not use them.</bq> <bq caption="Position 517-520">In the case of polymorphic functions, the simplified types of Section 3.2 turn out to have a performance impact as well: many functions that would otherwise get a type with an open polymorphic effect, are now closed and thus do not need a CPS translation as H will be false. In the Koka core library, this reduced the set of CPS translated functions by over 80%.</bq> <bq caption="Position 562-567">Here we take another approach: we are going to try to not change the runtime representation of functions that are CPS translated, even if they are called from a nonCPS context and the continuation argument is lacking. We assume that our target environment supports some form of variadic functions and that we can check at runtime if the k argument is present or not. This is well supported in JavaScript but it works well in typed environments too. For example, for the .NET target, first-class functions are represented by function objects and we can modify to the Apply methods to check if the k parameter was present.</bq> <bq caption="Position 591-592">Since only the tail of an effect row can be polymorphic, there is no risk of exponential code duplication. Even for the Koka core library which contains many of these higher-order effect polymorphic functions, the code size increased by a modest 20%.</bq> <bq caption="Position 608-611">[...] the original Links type system can be naturally extended to handle algebraic effects too. Their system is also based on row-polymorphism but they use instead Remy style rows [36] where the kind system is extended to record presence or absence of effects in the row. We believe our approach based on scoped labels [22] is simpler in practice, but the Remy style can be more expressive as it can describe the absence of effects.</bq> <bq caption="Position 623-625">Algebraic effect handlers concisely describe many complex control-flow constructs in various programming languages. We hope that the language design, the direct operational semantics, and compilation scheme described in this article will contribute to wider adoption of algebraic effects.</bq> <h id="Generalized">Generalized Algebraic Data Types and Object-Oriented Programming</h> <a href="https://www.microsoft.com/en-us/research/wp-content/uploads/2016/02/gadtoop.pdf" author="Andrew Kennedy and Claudio V. Russo" source="Microsoft Research">Generalized Algebraic Data Types and Object-Oriented Programming</a> <bq caption="Position 121-123">We identify a surprising expressivity gap compared to functional programming with parameterized algebraic datatypes (PADTs): operations with natural definitions in ML and Haskell require unnatural and nonextensible object-oriented encodings to ensure safety. With the introduction of generics, virtual dispatch is no longer as expressive as functional case analysis.</bq> <h id="Fexprs">Fexprs as the basis of Lisp function application or <c>$vau</c>: the ultimate abstraction</h> <a href="https://web.cs.wpi.edu/~jshutt/dissertation/etd-090110-124904-Shutt-Dissertation.pdf" author="John N. Shutt" source="Worcester Polytechnic Institute Computer Science Department">Fexprs as the basis of Lisp function application or <c>$vau</c>: the ultimate abstraction</a> <bq caption="Page 5">[...] mostly avoids this element by concerning itself with semantics. However, the background chapters are also meant to discuss language design motivations, and psychology is integral to that discussion because it often dominates programmer productivity. Semantics may make some intended computations difcult to specify, but rarely makes them</bq> <bq caption="Page 5">background chapters are also meant to discuss language design motivations, and psychology is integral to that discussion because it often dominates programmer productivity. Semantics may make some intended computations difcult to specify, but rarely makes them impossible — especially in Lisp, which doesn’t practice strong typing; whereas psychological bias may prevent entire classes of computations outright, just by preventing programmers from intending them</bq> <bq caption="Page 21">The acts of the mind, wherein it exerts its power over its simple ideas, are chiefy these three: (1) Combining several simple ideas into one compound one; and thus all complex ideas are made. (2) The second is bringing two ideas, whether simple or complex, together, so as to take a view of them at once, without uniting them into one; by which way it gets all its ideas of relations. (3) The third is separating them from all other ideas that accompany them in their real existence: this is called abstraction: and thus all its general ideas are made. — John Locke, An Essay Concerning Human Understanding ([Lo1690]), Bk. II Ch. xii §</bq> <bq caption="Page 23">Classically, an extensible language consists of a sourcelevel base language together with meta-level defnitional facilities to extend the base language ([Chr69]). A program then consists of two parts, a meta-level part that specifes an extension of the base language followed by a source-level part written in the extended language</bq> <bq caption="Page 24">Syntactic abstractions do not have to be macros. A class of non-macro syntactic abstractions is proposed, under the name micros, in [Kr01]; a micro specifes a transformation directly source-to-target (rather than source-to-source, as macros), which is clearly syntactic since its processing must be completed before the target abstract machine begins computation.8 Micros are a universal syntactic abstraction, in that they can be used to assign any possible (computable) semantics to source programs. (However, they won’t play a signifcant role in this dissertation, because they aren’t a traditional abstraction, so aren’t within the scope of the thesis.9)</bq> This sounds like source generators. <bq caption="Page 25">[...] the measure of the abstractive power of a programming language is the class of programming languages that it can readily specify — or, more to the point (but also more subjectively), the class of problem domains that the language, including its readily achieved abstractive extensions, can readily address.</bq> <bq caption="Page 25">Each extensible language is surrounded by an envelope of possible extensions reachable by modest amounts of labor by unsophisticated users</bq> <bq caption="Page 26">(Smoothness Conjecture) Every roughness (violation of smoothness) in a language design ultimately bounds its radius of abstraction.</bq> <bq caption="Page 26">The intuition here is that a butterfy efect occurs, in which the consequences of roughness are compounded by successive abstractions until, sooner or later depending on the degree of roughness, cumulative resistance drags down further abstraction through the fuzzy threshold from feasible to infeasible</bq> <bq caption="Page 30">Programmers spend much of their time reasoning informally about programs. Formal reasoning about programs may be used, on occasion, to prove that particular programs are correct; but more powerfully, to prove that general classes of program transformations preserve the meanings of programs. The general transformations are then safe for use in meta-programs —such as optimizing compilers— and also for use in subsequent program correctness proofs</bq> <bq caption="Page 32">Some languages, such as Haskell, allow argument evaluation to be postponed past the application of a compound function — lazy argument evaluation; but in general this takes out too much of the order of operations, so that the language interpreter must either do additional work to put back in some of the lost order, or else lose efciency.21 A few languages, such as Haskell, have taken the applicative trend to its logical extreme</bq> <bq caption="Page 32">Some languages, such as Haskell, allow argument evaluation to be postponed past the application of a compound function — lazy argument evaluation; but in general this takes out too much of the order of operations, so that the language interpreter must either do additional work to put back in some of the lost order, or else lose efciency.21 A</bq> Also, performance predictability, with unforeseeable lumps in the execution profile. <bq caption="Page 32">It is not yet clear whether the mathematical models used in ‘monadic’ programming will eventually fnd a useful balance between expressiveness and simplicity</bq> Hasn't really happened yet. <bq caption="Page 36">We’re really referring to the notion of frst-class object, which was discussed in the Preface, and for which nameability by variables is just one particular requirement; but in Lisps, most objects nameable by variables have all the rights and privileges of frst-class-ness. Christopher Strachey, by the way, originally evolved the notion of frst-class value from W.V. Quine’s principle To be is to be the value of a variable ([La00]); and Quine, after deriving the principle in his essay “On What There Is” [Qu61, pp. 1–19], had applied it to reifcation in another essay, “Logic and the Reifcation of Universals” [Qu61, pp. 102–129].</bq> <bq caption="Page 41">Technical simplicity would favor always using the double-quotes — but technical simplicity is a primary goal for expressions to be read by formal systems, not by the human audience. For the human audience our goal is accuracy of understanding, which is enhanced by ease of understanding but does not always correlate with technical simplicity, nor even with technical unambiguity</bq> <bq caption="Position 61-61">The distinction intended is that modularity hides implementation, while abbreviation merely shortens expression.</bq> <bq caption="Page 87">Programming languages should be designed not by piling feature on top of feature, but by removing the weaknesses and restrictions that make additional features appear necessary.</bq> <bq caption="Page 88">Programmer-defined facilities should be able to duplicate all the capabilities and properties of built-in facilities</bq> This is the principle I found most interesting, but it wasn't discussed. <h id="Regulating">Regulating the Sharing Economy</h> <a href="https://www.researchgate.net/publication/321069512_Regulating_the_Sharing_Economy" author="K. Erickson, I. Sørensen" source="">Regulating the Sharing Economy</a> <bq caption="Position 350-353">[...] sharing platforms disrupt some of the fundamental assumptions underlying common law “special relationships.”75 Unlike two-party relationships between service providers and consumers, sharing platforms create three-party relationships between the platform, provider, and user. These new relationships require a different allocation of liability and statutory protection.</bq> <bq caption="Position 370-372">Sharing platforms must navigate rules promulgated by multiple agencies at both state and local levels. Second, the relevant local codes are complex and, as discussed in the previous Section, impose heightened compliance burdens on service providers.</bq> <bq caption="Position 419-421">[...] sharing platforms also generate negative externalities for third parties. Short-term rentals can change the character of a building or even a community,97 and many residents object to finding strangers routinely entering the common areas of an apartment complex.</bq> <bq caption="Position 636-639">P2P auction houses and per-task contractor services allow users to purchase temporary licenses, such as a position in line for a movie, a table in a coffee shop, or a public parking spot. Blurring these lines creates difficult legal issues because these categories affect determinations of liability in almost every field of law, from tax149 to civil rights.</bq> <bq caption="Position 646-648">While Expedia, Priceline and Hotwire are best defined as retailers or resellers and, as such, can be controlled and taxed accordingly, it is much more difficult to find a comparable taxing analogue for the Internet-sharing economy.”).</bq> <bq caption="Position 688-691">Insurance Commissioner Jones aptly summarized the “moral hazard” argument of TNCs: “(1) drivers may be running personal errands; (2) drivers may have multiple applications open at the same time; (3) drivers with low limits on their personal automobile insurance policy will turn on the application in the event of an accident to secure more robust coverage; and (4) drivers start to look more like employees or independent contractors if the TNC covers this period.”</bq> <bq caption="Position 772-777">The two primary examples are auction platforms for public parking spaces and for seating in coffee houses or restaurants.177 Neither sellers nor purchasers “own” or “provide” the temporary license; the municipal government is responsible for maintaining public parking and restaurants are responsible for providing seating to customers. Many have criticized these platforms as parasitic, and claim that these services interfere with third-party rights. Bloggers have even coined the term “jerk tech” to describe these platforms.178 Others contend that auction houses optimize efficient use of scarce resources and prevent congestion; users who value a parking spot most can pay for that privilege, and price-sensitive users will accept less conveniently located spots.</bq> In other words, a pathologically sociopathic society that distributes resources only to those able to pay stupid amounts of money, a society that bubbles asshole criminals to the top. Kudos. This is obviously how it already works, but maybe don't supercharge it? You could do first come, first served, which this is, I guess. Feels wrong. <bq caption="Position 983-985">Unlike internet service providers, sharing companies are not passive; most platforms exercise at least some control over provider and user transactions, and almost all platforms have a financial stake in transactions between users and providers.216 This suggests that immunity for platforms is not appropriate.</bq> <bq caption="Position 999-1006">The proper allocation of liability between users and providers on sharing platforms is highly contextual because both the least-cost avoider and the easiest target for enforcement agencies vary between and within 216. Sharing platforms impose a wide range of transaction fees. See supra note 27. Interchange fees might serve as an indirect measure of the degree of control a platform exercises over transactions.</bq> <bq caption="Position 1005-1008">Since sharing platforms often operate on a large scale over multiple jurisdictions, the least-cost avoider for compliance may often be users and providers, who are most familiar with local rules and their own property. Moreover, casual and high volume providers may require different treatment. Yet in other situations platforms may be best positioned to address user or provider misconduct.</bq> <bq caption="Position 1031-1034">Tiered regulation properly allocates risk to repeat players who benefit most from the platform. For instance, providers who transact at volumes comparable to bed and breakfasts should incur similar liability to a traditional service provider. And TNC drivers who operate like full-time taxis should comply with safety standards comparable to taxis. In addition, tiered regulation levels the playing field between sharing platforms and traditional service providers, and discourages abuse of the platform.</bq> <bq caption="Position 1040-1042">For example, several ordinances on TNCs restrict the maximum number of hours that a driver can operate per day, but some TNC platforms do not directly restrict drivers’ hours.226 If a TNC driver leaves the app on twenty four hours a day and recklessly accepts fares without adequate rest, should the platform have a duty to terminate that driver? The platform exercises sufficient control such that it represents both the least-cost avoider and easiest enforcement target.</bq> <bq caption="Position 1137-1139">In some cases the public interest in allowing disclosure of rider logs may outweigh the rider’s privacy interest. For example, consulting firm Hamilton Places Strategies calculated based on congressional campaign filings that Members of Congress relied on Uber for sixty one percent of rides during the 2014 election cycle.</bq> <bq caption="Position 1425-1427">[...] regulators should not simply allow the sharing economy to grow in the shadow of the law. Allowing the sharing economy to self-regulate would not adequately safeguard consumers. Thus, responsible regulation of sharing platforms is a necessity, not a choice.</bq> <bq caption="Position 1433-1436">Tom Slee, <a href="http://tomslee.net/2014/11/why-canada-should-de -activate-uber.html">Why Canada Should De-Activate Uber</a>, WHIMSLEY (Nov. 22, 2014), (“Contrary to the way some articles are written, we do have a choice here. A lot of the links above talk as if Uber were some kind of inevitable future. . . . Conflating Uber with the broad advance of technology is just wrong, and it’s also exactly what Uber wants us to do.”).</bq> <h id="Political">Political Aspects of Full Employment</h> <a href="https://pluto.huji.ac.il/~mshalev/ppe/Kalecki_FullEmployment.pdf" author="Michael Kalecki" source="" date="1942">Political Aspects of Full Employment</a> <bq caption="Position 59-64">Under a laissez-faire system the level of employment depends to a great extent on the so-called state of confidence. If this deteriorates, private investment declines, which results in a fall of output and employment (both directly and through the secondary effect of the fall in incomes upon consumption and investment). This gives the capitalists a powerful indirect control over government policy: everything which may shake the state of confidence must be carefully avoided because it would cause an economic crisis. But once the government learns the trick of increasing employment by its own purchases, this powerful controlling device loses its effectiveness. Hence budget deficits necessary to carry out government intervention must be regarded as perilous.</bq> <bq caption="Position 76-78">In practice, however, this is not the case. Indeed, subsidizing mass consumption is much more violently opposed by these experts than public investment. For here a moral principle of the highest importance is at stake. The fundamentals of capitalist ethics require that 'you shall earn your bread in sweat'—unless you happen to have private means.</bq> <bq caption="Position 81-82">[...] under a regime of permanent full employment, the 'sack' would cease to play its role as a disciplinary measure. The social position of the boss would be undermined, and the self-assurance and class-consciousness of the working class would grow.</bq> <bq caption="Position 115-118">In current discussions of these problems there emerges time and again the conception of counteracting the slump by stimulating private investment. This may be done by lowering the rate of interest, by the reduction of income tax, or by subsidizing private investment directly in this or another form. That such a scheme should be attractive to business is not surprising.</bq> Those ideas are still working great, nearly a century later. <bq caption="Position 124-128">The rate of interest or income tax is reduced in a slump but not increased in the subsequent boom. In this case the boom will last longer, but it must end in a new slump: one reduction in the rate of interest or income tax does not, of course, eliminate the forces which cause cyclical fluctuations in a capitalist economy. In the new slump it will be necessary to reduce the rate of interest or income tax again and so on. Thus in the not too remote future, the rate of interest would have to be negative and income tax would have to be replaced by an income subsidy.</bq> Ding, ding, ding. <bq caption="Position 136-139">This state of affairs is perhaps symptomatic of the future economic regime of capitalist democracies. In the slump, either under the pressure of the masses, or even without it, public investment financed by borrowing will be undertaken to prevent large-scale unemployment. But if attempts are made to apply this method in order to maintain the high level of employment reached in the subsequent boom, strong opposition by business leaders is likely to be encountered.</bq> You got that right. <bq caption="Position 143-145">The pressure of all these forces, and in particular of big business—as a rule influential in government departments—would most probably induce the government to return to the orthodox policy of cutting down the budget deficit. A slump would follow in which government spending policy would again come into its own.</bq> Nothing new under the sun. <bq caption="Position 154-156">The rest of government spending necessary to maintain full employment should be used to subsidize consumption (through family allowances, old-age pensions, reduction in indirect taxation, and subsidizing necessities). Opponents of such government spending say that the government will then have nothing to show for their money. The reply is that the counterpart of this spending will be the higher standard of living of the masses.</bq> <bq caption="Position 154-157">The rest of government spending necessary to maintain full employment should be used to subsidize consumption (through family allowances, old-age pensions, reduction in indirect taxation, and subsidizing necessities). Opponents of such government spending say that the government will then have nothing to show for their money. The reply is that the counterpart of this spending will be the higher standard of living of the masses. Is not this the purpose of all economic activity? 2.</bq> Not according to the winners. <bq caption="Position 158-159">If capitalism can adjust itself to full employment, a fundamental reform will have been incorporated in it. If not, it will show itself an outmoded system which must be scrapped.</bq> <h id="Crypto">Crypto is the Mother of All Scams and (Now Busted) Bubbles While Blockchain Is The Most Over-Hyped Technology Ever, No Better than a Spreadsheet/Database</h> <a href="https://www.banking.senate.gov/imo/media/doc/Roubini%20Testimony%2010-11-18.pdf" author="" source="Nouriel Roubini" date="October 2018">Crypto is the Mother of All Scams and (Now Busted) Bubbles While Blockchain Is The Most Over-Hyped Technology Ever, No Better than a Spreadsheet/Database</a> <bq caption="Position 73-77">That means if a steady- state supply of Bitcoin really did gradually replace a fiat currency, the price index of all goods and services would continuously fall. By extension, any nominal debt contract denominated in Bitcoin would rise in real value over time, leading to the kind of debt deflation that economist Irving Fisher believed precipitated the Great Depression. At the same time, nominal wages in Bitcoin would increase forever in real terms, regardless of productivity growth, adding further to the likelihood of an economic disaster.</bq> <bq caption="Position 160-161">[...] that mining is highly concentrated in oligopolies in shady and nontransparent and unsecure jurisdictions – China, Russia, Belarus, Georgia, etc. It also goes beyond the possibility and reality of massive and regular 51% attacks.</bq> <bq caption="Position 159-161">Fundamental flaws of lack of security in crypto land go well beyond the fact that mining is highly concentrated in oligopolies in shady and nontransparent and unsecure jurisdictions – China, Russia, Belarus, Georgia, etc. It also goes beyond the possibility and reality of massive and regular 51% attacks.</bq> Adorable that one of the most criminally damaging financial powers is never considered shady. <bq caption="Position 192-195">Blockchain’s ideology is politically born out of the same mentality as libertarian right wing conspiracies or extreme left anarchism: all governments, central banks, moneys, institutions, banks, corporations, entities with reputation and credibility build over centuries are evil centralized concentrations of power that literally need to be destroyed.</bq> <bq caption="Position 227-228">Everything that this study argues about the nefarious impact of China on Bitcoin can be said and applied to any other crypto-currency and to the role of Russia in the crypto eco-system.</bq> China has since forbidden mining, but sure the holy U.S. Need not be mentioned as nefarious. <bq caption="Position 238-245">[...] wealth in crypto-land is more concentrated than in North Korea where the inequality Gini coefficient is 0.86 (it is 0.41 in the quite unequal US): the Gini coefficient for Bitcoin is an astonishing 0.88. <a href="https://davidgerard.co.uk/blockchain/ethereum-smart-contracts-in-practice/">6</a> <a href="https://www.coindesk.com/the-dao-bitcoin-development/">7</a> <a href="https://www.cbc.ca/news/technology/ethereum-hack-blockchain-fork-bitcoin-1.3719009">8</a> <a href="https://davidgerard.co.uk/blockchain/ethereum-smart-contracts-in-practice/">9</a> Quite a feat to create an asset class where inequality is greater than that of Kim Jong-un land. So decentralization is just a total myth invented by a bunch of whales whose wealth is fake; now that the retail suckers who bought at the peak have literally lost their shirts these crypto “whales” are fake billionaires as liquefying their wealth would crash the price of the “asset” to zero.</bq> <bq caption="Position 245-248">Blockchain’s boosters would argue that its early days resemble the early days of the Internet, before it had commercial applications. But that comparison is simply false. Whereas the Internet quickly gave rise to email, the World Wide Web, and millions of viable commercial ventures used by billions of people in less than a decade, cryptocurrencies such as Bitcoin do not even fulfill their own stated purpose.</bq> <bq caption="Position 253-255">Crypto has been around for over a decade now and in 2018 the number of crypto wallets was only 22 million and out of this figure the number of active bitcoin users is only between 2.9 and 5.9 million and falling. And the number of crypto transactions has collapsed by at least 75% between 2017 and 2018.</bq> And it did it again in 2022. <bq caption="Position 312-314">The fact that everyone within a given country or jurisdiction uses the same currency is precisely what gives money its value. Money is a public good that allows individuals to enter into free exchange without having to resort to the kind of imprecise, inefficient bartering on which traditional societies depended.</bq> <bq caption="Position 454-456">While every successful technological revolution includes some bubbles and some scammers, most of the real ones – like the internet - create real goods and services that billions of folks use around the world even after the initial frothiness and bubble has burst. And the criminal and scamming element in real technological revolutions is the exception, not the systemic rule that it is in crypto land.</bq> <h id="Housing">The Housing Bubble and the Great Recession: Ten Years Later</h> <a href="https://cepr.net/images/stories/reports/housing-bubble-2018-09.pdf" author="Dean Baker" source="CEPR">The Housing Bubble and the Great Recession: Ten Years Later</a> <bq caption="Position 233-236">It is common to speak about the collapse of the housing bubble and the financial crisis as unpredictable events that fell out of the sky without warning. While this may be a comforting view for the economists with jobs that required monitoring the economy, it is far from the reality. The housing bubble and the risks it posed were easy to see. It was only due to incredibly narrow-minded thinking that the vast majority of the economics profession managed to miss it.</bq> <bq caption="Position 272-277">Greenspan’s testimony should have served as a wake-up call to anyone who had not already been paying attention to the surge in house prices. At the time, Greenspan was by the far the most widely known economist in the world. He had been appointed as Fed chair by four different presidents. He was the subject of a fawning biography by Bob Woodward, appropriately titled “Maestro.” The business press largely revered him. Yet, in spite of Greenspan calling attention to the run-up in house prices, and providing no remotely plausible explanation based in the fundamentals of the housing market, the topic received virtually no attention from economists or the business press.</bq> Also, nobody fired Alan Greenspan. <bq caption="Position 293-294">Some conservatives actually argued for eliminating the FHA, claiming that Wall Street’s sophisticated ability to manage risk had made it obsolete.</bq> How is that in any way a conservative position? Deregulation is quite radical. <bq caption="Position 319-322">There was no money in raising a warning flag that this story was not likely to have a happy ending. And, it turned out there were really no negative consequences for not raising a warning flag. Few, if any, economists lost a job or even missed a scheduled promotion because they didn’t see and warn about the dangers of the housing bubble. And as we all know, economists respond to incentives.</bq> <bq caption="Position 390-393">In terms of total indebtedness, the key issue is not levels of debt, but ratios of debt service to disposable income. This ratio is actually at relatively low levels, according to data from the Federal Reserve Board.22 (The Fed constructs this ratio using both debt alone and also adding in rents since the latter can be viewed as a debt-like obligation that substitutes for a mortgage payment. Both ratios are near 40-year lows.)</bq> <bq caption="Position 394-396">Credit cards do tend to be variable rate, and a small portion of mortgage debt and auto loan debt is variable rate, but there is no plausible story where a rise in interest rates will lead to large-scale defaults, even if it can be a major burden on the people carrying this debt.</bq> Sometimes he's just cold. Could spare a word or two about a system that drives the poorest into high-interest debt, that they're vulnerable even when the system is not. <bq caption="Position 401-403">Nothing like this can happen with student loan debt. If a student defaults, it may lead his friends to give more thought to default also, but it doesn’t directly reduce the earnings power of other students, which is the basis for loan repayments.</bq> You can't even default on those debts, can you? <bq caption="Position 404-405">But the fact that many former students face bleak financial prospects does not mean that the economy is facing an imminent crisis due to student loan defaults.</bq> See? Again, the fact that the next generation is in crisis is decoupled from the stability of the economy. The system works, even if everyone's miserable. Not a crisis!