• 1 Post
  • 63 Comments
Joined 2 years ago
cake
Cake day: June 14th, 2023

help-circle

  • Java is bad but object-based message-passing environments are good. Classes are bad, prototypes are also bad, and mixins are unsound. That all said, you’ve not understood SOLID yet! S and O say that just because one class is Turing-complete (with general recursion, calling itself) does not mean that one class is the optimal design; they can be seen as opinions rather than hard rules. L is literally a theorem of any non-shitty type system; the fact that it fails in Java should be seen as a fault of Java. I is merely the idea that a class doesn’t have to implement every interface or be coercible to any type; that is, there can be non-printable non-callable non-serializable objects. Finally, D is merely a consequence of objects not being functions; when we want to apply a functionf to a value x but both are actually objects, both f.call(x) and x.getCalled(f) open a new stack frame with f and x local, and all of the details are encapsulation details.

    So, 40%, maybe? S really is not that unreasonable on its own; it reminds me of a classic movie moment from “Meet the Parents” about how a suitcase manufacturer may have produced more than one suitcase. We do intend to allocate more than one object in the course of operating the system! But also it perhaps goes too far in encouraging folks to break up objects that are fine as-is. O makes a lot of sense from the perspective that code is sometimes write-once immutable such that a new version of a package can add new classes to a system but cannot change existing classes. Outside of that perspective, it’s not at all helpful, because sometimes it really does make sense to refactor a codebase in order to more efficiently use some improved interface.


  • This is too facile. First, in terms of capability maturity, management is not the goal of a fully-realized line of industry. Instead, the end is optimization, a situation where everything is already repeatable, defined, and managed; in this situation, our goal is to increase, improve, and simplify our processes. In stark contrast, management happens prior to those goals; the goal of management is to predict, control, and normalize processes.

    Second, management is the only portion of a business which is legible to the government. The purpose of management is to be taxable, accountable, and liable, not to handle the day-to-day labors of the business. The Iron Law insists that the business will divide all employees into the two camps of manager and non-manager based solely on whether they are employed in pursuit of this legibility.

    Third, consider labor as prior to employment; after all, sometimes people do things of their own cognizance without any manager telling them what to do. So, everybody is actually a non-manager at first! It’s only in the presence of businesses that we have management, and only in the presence of capitalism that we have owners. Consider that management inherits the same issues of top-down command-and-control hierarchy as ownership or landlording.






  • No, this is an explanation of dataflow programming. Functional programming is only connected to dataflow programming by the fact that function application necessarily forces data to flow. Quoting myself on the esolang page for “functional paradigm”:

    The functional paradigm of language design is the oldest syntactic and semantic tradition in computer science, originating in the study of formal logic. Features of languages in the functional paradigm are not consistent, but often include:

    • The syntactic traditions of combinatory logic and lambda calculus, carried through the Lisp, ML, and APL families
    • Applicative trees and combining forms
    • A single unified syntax for expressions, statements, declarations, and other parts of programs
    • Domain-theoretic semantics which admit an algebra of programs
    • Deprecation or removal of variables, points, parameters, and other binders in favor of point-free/tacit approaches

    This definition comes from a famous 1970s lecture. The author is a Scala specialist and likely doesn’t realize that Scala is only in the functional paradigm to the extent that it inherits from Lisps and MLs; from that perspective, functional programming might appear to be a style of writing code rather than a school of programming-language design.



  • Corbin@programming.devtoProgramming@programming.devAI Coding
    link
    fedilink
    English
    arrow-up
    4
    ·
    2 months ago

    You have no idea what an abstraction is. You’re describing the technological sophistication that comes with maturing science and completely missing out on the details. C was a hack because UNIX’s authors couldn’t fit a Fortran compiler onto their target machine. Automatic memory management predates C. Natural-language processing has been tried every AI summer; it was big in the 60s and big in the 80s (and big in the 90s in Japan) and will continue to be big until AI winter starts again.

    Natural-language utterances do not have an intended or canonical semantics, and pretending otherwise is merely delaying the painful lesson. If one wants to program a computer — a machine which deals only in details — then one must be prepared to specify those details. There is no alternative to specification and English is a shitty medium for it.




  • The typical holder of a four-year degree from a decent university, whether it’s in “computer science”, “datalogy”, “data science”, or “informatics”, learns about 3-5 programming languages at an introductory level and knows about programs, algorithms, data structures, and software engineering. Degrees usually require a bit of discrete maths too: sets, graphs, groups, and basic number theory. They do not necessarily know about computability theory: models & limits of computation; information theory: thresholds, tolerances, entropy, compression, machine learning; foundations for graphics, parsing, cryptography, or other essentials for the modern desktop.

    For a taste of the difference, consider English WP’s take on computability vs my recent rewrite of the esoteric-languages page, computable. Or compare WP’s page on Conway’s law to the nLab page which I wrote on Conway’s law; it’s kind of jaw-dropping that WP has the wrong quote for the law itself and gets the consequences wrong.








  • Put a rescue distro on a USB stick. When you first boot the laptop, use the rescue distro. Write down the USB IDs (lsusb) and PCI IDs (lspci). Read through the kernel boot log (sudo dmesg | less) and write down the names of any kernel drivers that might matter; WiFi, GPUs, USB bridges, and keyboard layouts are important in particular. For laptops, look up manufacturer-specific drivers for keyboards, fans, and power management.

    Linux requires about 8MiB of RAM to boot. The entire netbook movement relied on machines with 2GiB or less; I remember putting Linux onto a 2GiB Sony VAIO that had struggled to boot Windows. Your laptops aren’t too small, but you may be choosing distros with poor hardware support or large monolithic packages. I bet that one of Debian, Gentoo, or NixOS would boot on those machines that still work; of those, Debian is probably easiest.

    Old laptops sucks. Windows use to be very efficient. XP and 7 has held up very well after all these years. And most importantly Linux isn’t a one size fits all solution.

    Nah, Windows sucked back then too. If a machine boots Windows XP or Windows 7, then it can easily be made to boot an out-of-the-box Linux distro. The Asus machine you listed might have some boot issues, but the Acer and Dell do not appear different from any of the Acers or Dells that I’ve put Linux on in the past decade. My daily driver is a $150 refurbished Dell Latitude 5390 running NixOS.