Earlier quoted context omitted.
Wow, you're not kidding about book-length: at 246 pages, that's an epic takedown. Learning all kinds of other things about networking along the way, though. I do remember all nine layers of the OSI stack though: physical, data link, network, transport, session, presentation, application, financial, political.
BTDTGTTS https://shop.isc.org/collections/shirts/products/osi-9-layer...
The Rise of Worse Is Better (1991)
171–180 of 351 posts
Re: The Rise of Worse Is Better (1991)
#172Earlier quoted context omitted.
Prolog, Dylan, Julia, and R are stuff like Lisp, Tcl, and Rebol. I don't know about Erlang, and I don't know what pjmlp means by "Lisp-2", which I normally interpret as meaning a Lisp with different namespaces for functions and variables, following Steele's terminology.
Looking at https://docs.julialang.org/en/v1/manual/metaprogramming/ , I have a hard time considering it "fully" homoiconic, as the parsed data structure Expr(:call, :+, :a, Expr(:call, :*, :b, :c), 1) isn't the same representation as the code itself, even having some new elements like :call. How it this different from tree-sitter, except that you can feed the modified code back to the language to evaluate? I mean, do…
However, that's not a parsed data structure; it's a Julia expression to construct one. Though I don't have Julia installed, apparently you can just as well write that as :(a + b*c + 1), as explained a few paragraphs further down the page than I guess you read: https://docs.julialang.org/en/v1/manual/metaprogramming/#Quo.... That's also how Julia represents it for output, by default. What you've written there is the equivalent of Lisp (list '+ 'a (list '* 'b 'c) 1), or perhaps (cons '+ (cons 'a (cons (cons '* (cons 'b (cons 'c '()))) (cons 1 '())))). The data structure is as simple as Prolog's, consisting of a .head such as :call and a list of .args. Prolog's, in turn, is only slightly more complex than Lisp's. From a certain point of view, Prolog's structure is actually simpler than Lisp's, but it's arguable.
How this is different from having a tree-sitter parser is that it's trivially easy to construct and analyze such structures, and not just at compile time.
Possibly the source of your confusion is the syntactic sugar which converts x + y + z into what we'd write in Lisp as (+ x y z), and also converts back? I would argue that such syntactic sugar is precisely what you want for constructing and analyzing expressions. That is, it's part of what makes Julia homoiconic in a more useful sense than J. Random Language equipped with a parser for its own syntax.
Re: The Rise of Worse Is Better (1991)
#173Earlier quoted context omitted.
The OSI stack was also designed using the packet-switching approach. Rob Graham's "OSI Deprogrammer" is a book -length article about how TCP/IP beat OSI, and how the OSI model is entirely worthless: https://docs.google.com/document/d/1iL0fYmMmariFoSvLd9U5nPVH... I'm not sure he's right, but I do think his point of view is important to understand.
Wow. That is awesome, I skimmed through it and it looks like something I will enjoy. I've still got my Tanenbaum Computer Networks book from 1996 and the first chapter starts with OSI, then TCP/IP, and explains the differences and why OSI failed.
Re: The Rise of Worse Is Better (1991)
#174Earlier quoted context omitted.
The OSI stack was also designed using the packet-switching approach. Rob Graham's "OSI Deprogrammer" is a book -length article about how TCP/IP beat OSI, and how the OSI model is entirely worthless: https://docs.google.com/document/d/1iL0fYmMmariFoSvLd9U5nPVH... I'm not sure he's right, but I do think his point of view is important to understand.
OSI was was two network stacks fighting with each other, the circuit-switched telco X.25 successor and the packet-switched DEC / Xerox anti-Internet. See also https://computer.rip/2021-03-27-the-actual-osi-model.html and https://dotat.at/@/2024-03-26-iso-osi-usw.html
> Teaching students about TCP/IP using the OSI model is like teaching students about small engine repair using a chart of the Wankel cycle. It's nonsensical to the point of farce. The OSI model is not some "ideal" model of networking, it is not a "gold standard" or even a "useful reference." It's the architecture of a specific network stack that failed to gain significant real-world adoption.
Re: The Rise of Worse Is Better (1991)
#175> The good news is that in 1995 we will have a good operating system and programming language; the bad news is that they will be Unix and C++. And 30 years later they show few signs of letting go.
Re: The Rise of Worse Is Better (1991)
#176I remember when I had a lesson about OSI layers, where the teacher has carefully described all the layers in detail and then said something like "most of this is not important, these layers don't really exist, TCP/IP got popular first because it's just much simpler than OSI was"
IMO the OSI layer system (even though using TCP/IP suite) has some merit in education. To most of us, the concept of layering protocols may seem obvious, but I've talked to people who are just learning this stuff, and they have a lot of trouble understanding it. Emphasizing that each layer is (in theory) cleanly separated and doesn't know about layers above and below, is a very useful step towards understanding abstr…
Re: The Rise of Worse Is Better (1991)
#177Earlier quoted context omitted.
Why not? Really, why not? If we had a profitable way to extract CO2 from the atmosphere at scale, to deacidify the oceans, clean up toxic waste, etc., what would be left? How would that not solve the problem?
why are you fantasizing? none of that is going exist (caveat: unless we figure out infinite clean energy).
Re: The Rise of Worse Is Better (1991)
#178Earlier quoted context omitted.
Fair point... it was a coastal California-centric point but there is plenty of nuance or adjustment to be made. At some point in the 90's we'd probably have said "Silver E class Mercedes" is the most expedient luxury sedan, if you wanted a different example.
I think Toyota would have gotten your point across better. Tesla is most certainly not expedient. It is a luxury purchase.
IMO, it destroys its competitors in the value market, and the media is being awfully silent about it. I guess it's far too easy to focus on Elon instead.
Re: The Rise of Worse Is Better (1991)
#179I remember when I had a lesson about OSI layers, where the teacher has carefully described all the layers in detail and then said something like "most of this is not important, these layers don't really exist, TCP/IP got popular first because it's just much simpler than OSI was"
Oh, there's an entirely different feature-length article to be written/found about how packet switching beat circuit switching and the "Internet approach" beat the telco approach. The great innovation of being able to deploy devices at the edges without needing clearance from the center. I don't think very many people even remember X25. The one survivor from all the X standards seems to be X509?
Re: The Rise of Worse Is Better (1991)
#180Earlier quoted context omitted.
> An observation of this idea is that Rust compilers are terribly huge and slow because they use static type-tetris for everything, Rust's typechecking passes are not the reason why the compiler is slow. Code generation dominates compile times. Type checking is pretty quick, and Rust makes some decisions that enable it to do so, like no global inference.
....so why is it so slow to generate code?
On my current project, "cargo check" takes ten seconds, and "cargo build" takes 16. That's 62.5% of the total compilation time taken by code generation, roughly (and linking, if you consider those two to be separate).
In my understanding, there can sometimes be problems with -Z time-passes, but when checking my main crate, type_check_crate takes 0.003 seconds, and llvm_passes + codegen_crate take 0.056 seconds. Out of a 0.269 second total compilation time, most things take less than 0.010 seconds, but other than the previous codegen mentioned, monomorphization_collector_graph_walk takes 0.157s, generate_crate_metadata takes 0.171 seconds, and linking takes 0.700 seconds total.
This general shape of what takes longest is consistent every time I've looked at it, and is roughly in line with what I've seen folks who work on compiler performance talk about.