Ex historian here, now engineer. I would gently suggest you’re underestimating the magnitude of some of the transformations wrought by the technologies that OP mentioned for the people that lived through them. Particularly for the steam engine and the broader Industrial Revolution around 1800: not for nothing have historians called that the greatest transformation in human life recorded in written documents.
If you think, hey but people had a “job” in 1700, and they had a “job” in 1900, think again. Being a peasant (majority of people in Europe in 1700) and being an urban factory worker in 1900 were fundamentally different ways of life. They only look superficially similar because we did not live the changes ourselves. But read the historical sources enough and you will see.
I would go as far as to say that the peasant in 1700 did not have a “job” at all in the sense that we now understand; they did not work for wages and their relationship to the wider economy was fundamentally different. In some sense industrialization created the era of the “job” as a way for most working-age people to participate in economic life. It’s not an eternal and unchanging condition of things, and it could one day come to an end.
It’s too early to say if AI will be a technology like this, I think. But it may be. Sometimes technologies do transform the texture of human life. And it is not possible to be sure what those will be in the early stages: the first steam engines were extremely inefficient and had very few uses. It took decades for it to be clear that they had, in fact, changed everything. That may be true of AI, or it may not. It is best to be openminded about this.
Yeah my experience is that canada has always sucked: I graduated electronics engineering, then did 20 years of technician, IT, software, just whatever shit beneath my abilities that i have been offered. My resume has always been a list of things i clearly don't want to do anymore. Still get offers for photocopy repair, what a shit low paying job that was/is. But that is what life is for many people i think, can't be too picky, do what pays bills.
If you have real skills you are expected to make something of your own on the side. Nobody teaches you how capitalism really works, they want suckers to do the shit work. The ways to win are to work for yourself, eliminate as many middlemen as possible, hide sacred knowledge, come up with scams, hide bodies for rich people.
The thing is that emacs predates Apple developing cmd-z/x/c/v and Microsoft copying Apple in Windows. Before that, the most commonly copied keystrokes in programmer's editors were the freaking Wordstar ones e.g. in all the Borland products.
Also OP apparently has no knowledge of the far better IDEs we had 30-40 years ago including but not limited to:
- Apple MPW, 1986. GUI editor where every window is (potentially) a Unix-like shell, running commands if you hit Enter (or cmd-Return) instead of Return. Also the shell scripting has commands for manipulating windows, running editing actions inside them etc. Kind of like elisp but with shell syntax. There's an integrated source code management system called Projector. If you type a command name, with or without arguments and switches, and then hit option-Return then it pops up a "Commando" window with a GUI with checkboxes and menus etc for all options for that command, with anything you'd already typed already filled out. It was easy to set up Commando for your own programs too.
- Apple Dylan, 1992-1995. Incredible Lisp/Smalltalk-like IDE for Apple's Dylan language
- THINK Pascal and C, 1986. The Pascal version was orginaly an interpreter, I think written for Apple, but then became a lightning-fast compiler, similar to Borland on CP/M and MS-DOS but better (and GUI). The C IDE later became a Symantec product.
- Metrowerks Codewarrior, 1993. Ex THINK/Symantec people starting a Mac IDE from scratch, incorporating first Metrowerks' M68000 compilers for the Amiga, then a new PowerPC back end. Great IDE, great compilers -- the first anywhere to compile Stepanov's STL with zero overhead -- and with a groundbreaking application framework called PowerPlant that heavily leaned on new C++ features. It was THE PowerPC development environment, especially after Symantec's buggy PoS version 6.
- Macintosh Allegro Common Lisp (later dropped the "Allegro"), 1987. A great Mac IDE. A great Lisp compiler and environment. Combined in one place. It was expensive but allowed amazing productivity in custom native Mac application development, far ahead of the Pascal / C / C++ environments. Absolutely perfect for consultants.
Really, it is absolutely incredible how slick and sophisticated a lot of these were, developed on 8 MHz to 33 or 40 MHz M68000s with from 2-4 MB RAM up to maybe 16-32 MB. (A lot of the Mac II line (and SE/30) theoretically supported 128 MB RAM, but no one could afford that much even once big enough SIMs were were available.)
This is a recent trend and one I wholeheartedly agree with. See these position papers (including one from David Silver from Deepmind and an interview where he discusses it):
This article missed a critical point which is "the right way" to select a glibc ABI version: see binutils ld documentation, second part of the page related to VERSION support.
This must include glibc internal symbols.
This will allow to craft ELF binaries on a modern distro which will run on "older" distros. This is critical for games and game engines. There is an significant upfront only-once work in order to select an "old" glibc ABI.
The quick and dirty alternative being having a toolchain configured to link with an "old" glibc on the side.
This article missed the -static-libstdc++ critical option for c++ applications (the c++ ABI is hell on earth), but did not miss the -static-libgcc and the dynamic loading of system interface shared libs.
I think its more than "we just found some math that fits the data" in the sense that its not just a case of adding some terms to match an observed curve - for example like with Rayleigh-Jeans' law vs Wein's Approximation of blackbody radiation and eventually Max Planck's solution by quantizing energy to the curve match experiment, without actually having anything else to say about it.
Spiritually it feels more like what happened later, when people took the idea of quantized energy seriously and began finding ways to make it a theoretically consistent theory which also required a radical new approach of disregarding old intuitive assumptions about the way the most fundamental things worked solely to obey a new abstract, esoteric, purely theoretical framework (an approach which was sometimes controversial especially with experimentalists).
But of course this new theory of quantum mechanics turned out to be immensely successful in totally unprecedented ways, in a manner similar to Relativity and it's "theory first" origin with trying to ensure mathematical consistency of Maxwell's equations and disregarding anything else in the way (and eventually with Einstein's decade long quest to find a totally covariant general theory that folded gravity into the mix).
With physics the more I dug into "why" it was rarely the case that it was "just because", the justification was nearly always some abstract piece of math that I wasn't equipped to understand at the time but was richly rewarded later on when I spent the time studying in order to finally appreciate it.
The first time I solved Schrodinger Equation for a hydrogen atom, I couldn't see why anyone could've bothered to try discovering how to untangle such a mess of a differential equation with a thousand stubborn terms and strange substitutions (ylm??) and spherical coordinate transformations - all for a solution I had zero intuition or interest in. After I had a better grasp of the duality between those square integrable complex functions and abstract vector spaces I found classical QM elegant in an way I wasn't able to see before. When basic Lie theory and representations was drilled into my head and I had answered a hundred questions about different matrix representations of the SU(n) and S0(3) groups and their algebras and how they were related, it finally clicked how naturally those ylm angular momentum things I saw before actually arose. It was spooky how group theory had manifested in something as ubiquitous and tangible as the structure of the periodic table. After drudging through the derivation of QFT for the first time, when I finally understood what was meant by "all particles and fields that exist are nothing more than representations of the Poincare-Spacetime Algebra", I felt like Neo when everything turned into strings of code. And there's no point describing what it was like when Einstein's field equations clicked, before then I never really got what people meant by the beauty of mathematics or physics.
I guess its not really the answer "why" things are, but the way our current theories basically constrain nearly everything we see (at least from the bottom up) from a handful of axioms and cherry-picked coupling constants, the rest warped into shape and set in stone only by the self-consistency of mathematics, I feel like that's more of a "why" than I would've ever assumed answerable, and maybe more of one than I deserve.
You still get an API that encapsulates the behavior. This is not like monkey-patching (directly changing the behavior of libraries), but separating the abstraction layers. Every complex enough system will have multiple layers (for example when working on communications, if you're working with the network layer you don't need to focus on the physical layer below or the application layer above). Multiple dispatch allows the library ecosystem to better work in the same way:
For machine learning models we have the layer that handles the low level operation (sums, multiplication), which are swappable (you can have an implementation that runs in the CPU - Julia's Base - and an implementation that run in the GPU - CUDA.jl - and even a TPU - XLA.jl or Torch as backend). Above you have the tracker (the layer responsible for the autodifferentiation logic, which includes Tracker, Zygote, ForwardDiff). And above you have the library with rules for generating gradients (DiffRules, ChainRules), and above you have ML constructs (NNLib), and above ML frameworks (Flux, Knet) and above more specialized libraries like DiffEqFlux.
Whoever writes the ML framework doesn't need to care about the backend, whoever writes the GPU backend doesn't need to care about ML framework. This is not because the person writing the GPU backend patched the ML framework, but because the ML framework legitimately doesn't care about how the low level operations are executed, it doesn't work on that level of abstraction. And the user of the ML library can still see it like a monolith not unlike Pytorch or Tensorflow when he imports a library like Flux, until he wants to extend them and then he will find that they are in fact many independent swappable systems that compose into something more than the sum of it's parts.
If you are using no-code solutions, increasing an "idea" in a dataset will make that idea more likely to appear.
If you are fine-tuning your own LLM, there are other ways to get your idea to appear. In the literature this is sometimes called RLHF or preference optimization, and here are a few approaches:
Direct Preference Optimization
This uses Elo-scores to learn pairwise preferences. Elo is used in chess and basketball to rank individuals who compete in pairs.
@argilla_io on X.com has been doing some work in evaluating DPO.
KTO is an approach that uses mono preference data. For example, it asks if a response is "good or not." This is helpful for a lot of real word situations (e.g. "Is the restaurant well liked?").
There is a wearable system for researching infants' linguistic environment called "The Language ENvironment Analysis system (LENA)". This review collects and analyses available data[1]. I just took an average AWC (adult word count) per day, and roughly calculated how much linguistic input infants get during their first 4 years. Of course, it's just a kind of a Fermi estimate, but the scale should be about right: 10000 times less input than GPT-3.
It would be an interesting challenge to create a "baby-like" dataset. I guess a system like this could help collecting it.
Hi. We're building The Nose (https://thenose.cc), a safe haven for training data that can't be taken down with DMCA. Since this involves copyright infringement, strong anonymity is a requirement.
The reason Tails isn't an option is because, as others have mentioned, there have been Tor browser exploits which reveal the IP address of the Tails user. While this is unlikely for our case, it's important to approach security from first principles with threat modeling. An attack from the FBI may seem unlikely today, but both Silk Road and one of its successors were taken down by mistakes they made when setting up their site. Learning from history, if you're not careful early, you're in for a surprise later.
Case in point: When I started Whonix Workstation to post this comment, the Whonix Gateway VM failed to boot. So when I tried to start Tor Browser and go to https://news.ycombinator.com, all I saw was a connection error. This kind of layered defense is essential if you're serious about staying out of jail.
Realistically, you'll likely dox yourself through some other means: sending Bitcoin to your pseudonym from your real identity, admitting to someone you know that you control your pseudonym (this work gets lonely, so this is a real temptation), or even accidentally signing off an email with "Thanks, [your real name]". And once you make a single mistake, you can never recover.
glibc 2.34 has a hard break where you cannot compile with 2.34 and have it work with older glibc versions even if you use those version headers. It will always link __libc_start_main@GLIBC_2.34 (it's some kind of new security hardening measure, see https://sourceware.org/bugzilla/show_bug.cgi?id=23323).
Since additionally you also need to build all your dependencies with this same trick, including say libstdc++, it's really easiest to take GP's advice and build in a container with the old library versions. And nothing beats being able to actually test it on the old system.
Love Tails, but I haven't used it in ten years. I have had Tails and Qubes disposable VMs on my mind though.
I switched off of Qubes last year to my own Alpine chroot with a hand crafted kernel and initrd that lives only in memory. I find turning off the computer when I'm finished and having it forget everything to be a very peaceful way to compute. I owe the internet a write up.
I feel like ramfs for root filesystems is an underused pattern more broadly. "Want to upgrade? Just reboot. Fallback? Pick a different root squashfs in the grub menu"
> intellectual property is not like ordinary property at all, but constitutes a government grant of a costly and dangerous private monopoly over ideas. We show through theory and example that intellectual monopoly is not necessary for innovation and as a practical matter is damaging to growth, prosperity and liberty.
The fact that it's for a CRT is the surprising part, but "universal" replacement boards for LCD TVs have been available for a while too. Here's a rare review of one, on a site that has sadly disappeared within only a few years:
IMHO Write it once for the problem; again for the solution.
TFA stresses: finding out what you're building; finding the "unknown unknowns" (the things you don't even know you don't know, encountering those problems)
TFA doesn't say it this way, but I think the fun of throwaway-prototyping is your thoughts can focus uninterrupted on the problem, undistracted by secondary issues. You can hack-around tedious parts, now knowing they are there; and you can get absorbed in the genuinely tricky parts, unobscured (even if you don't succeed, you also know they are there). You're not expected to get it all right.
It's turning an unexperienced developer (on this problem) into an experienced one.
"you should plan to throw one away. You will anyway."
That was the first edition of The Mythical Man-Month. In the second edition, I say that was misguided! You ought to plan to continually iterate on it, not just build it, throw it away and start over. Some of the things I said in 1975 were wrong, and in the second edition, I correct them.
Tesla's sales of approximately 4.5 million vehicles have each offset about 20 tons of CO2 over their lifetimes compared to a traditional gas vehicle [1]. This equates to preventing a total of 90 million tons of CO2 from entering our atmosphere. As we continue to transition to renewable energy, the environmental benefits of each Tesla vehicle are set to increase further.
In contrast, a SpaceX launch generates around 300 tons of CO2 [2], totaling about 72,600 tons of CO2 for the 242 launches to date. We mustn't forget the wide-ranging benefits these launches provide, from improved weather forecasting and GPS services to crewed missions to the International Space Station.
If we subtract the CO2 emissions from SpaceX launches from the CO2 savings attributed to Tesla, we see a net savings of about 89,927,400 tons of CO2.
90,000,000 / 72,600 = 1,240x
The emissions from his remaining companies are comparably negligible. Furthermore, this calculation doesn't account for Tesla's influence on the automotive industry, propelling other manufacturers to accelerate their production of EVs. As Tesla's sales continue to rise and EVs become more accessible through Tesla's charging network, these benefits will be multiplied. Also, this doesn't factor in the positive environmental impact of Tesla's energy division, which likely offsets the emissions from all of his other companies on its own.
The brutal truth of it is that while there is beauty in the craft, in the end shipping is what matters. Getting things in front of the people that need them.
There's a nice concept in theater that says, effectively, "if you blow a line, don't broadcast it to the audience." The subtext of that is, simply, the audience doesn't know any better and what they don't know, won't hurt them.
By and large, this applies to many fields, and certainly to software development. The users, in the large, do not care over a huge amount of stuff that we, as practitioners, care about.
We're in a results business. The users care that they get the report they want or can update the data they're supposed to. How that's done, in the back end, is filed under "blah blah blah".
The reason this is important is not as an excuse to do crummy work, or to not be passionate about the minutiae that consumes us, but to be cognizant that as long as the end result is functional and capable for the user, it's OK for the processes that get to that point to be a bit messy. Don't beat yourself up over a lot of the things we beat ourselves up, or criticize others over.
Ship. Get your code in front of users, interact with them to make their experience better. We are in a service industry. Strive to be better, but you only get better by shipping, and moving on.
The confidence is that, for the most part, "it's just software" and you can fix it. You can change it later. You can correct mistakes.
Another saying is that you're not a professional until you've lost production data. Thankfully in our work, loss of production data rarely kills people, in contrast to the path of becoming, say, a doctor. If you are in an industry where people can be hurt, then that's going to be more rigid, for obvious reasons.
I have lost data, I have been SCREAMED at by clients, I have stood under the withering "What has just happened here" glare from management. It happens. Ah, the warm camaraderie of being thrown into a data entry pool to help rekey some of the 6 months of data you destroyed. A cold truth in our business is that it has to happen, as we only learn through practice, and through practice, sometimes we miss.
But to do that, we have to ship. We have to get the work out there, "I don't test often, but when I do, it's in production". Sometimes you just got to open the firewall up, let the traffic in, and see what happens.
A cynical view is the that the more we ship, the more we learn what we can get away with. There's a truth to that as well. We're all victims of not listening to "you're not going to need it". For all sorts of values of "it". But that doesn't mean we can't keep those concepts close, practice them as best as we can (because, truth is, sometimes you do need it!).
Through the work, and shipping, you learn the balance, and get more comfortable with it.
I disagree with a lot of this for a few main reasons. And some minor ones
Application development technology has considerably improved over time - most applications simply do not need to reinvent the wheel! Yes, over-engineering by designing something that will never see more than 1qps to scale infinitely is bad - I’m sure it happens but I think it’s more a strawman. If you need a simple CRUD application with a good-enough UI you have no need to introduce additional complexity (and potentially maintenance, reliability issues) with custom tooling.
Two, the software talent market is bifurcated. There is basically commodity development of crud apps, and technically complex novel development. If you think there are no rockstars you might just be in the commodity development scene. There literally are these so-called “rockstars” being flown into SF to work on new stuff in the ML sphere or into NYC/Chicago to work on bleeding edge performance. Maybe the dissonance here is that the commodity developer market has grown a lot, and that over time some technology (like web applications - a lot harder to do at scale in 2005 vs now) shifts from rockstar to commodity as it matures.
Reverting to pets-not-cattle and statefulness can be appropriate at low scale. But honestly this is more of a “choose the right solution to the problem” thing and not a rockstar thing. Following this model as you reach large scale allows for cool production heroism and cowboy coding that makes you feel like a true hacker, but that doesn’t mean your users are getting a more reliable experience, or that your dev time is being spent efficiently.
My minor quip is that, I think as you get more experienced what you used to think of as rockstar development just looks routine because you’re better at writing software.
Another minor point: you can’t just engender a rockstar culture at a company that hires commodity developers as easily as asserted here. The big thing not mentioned: PAY. Nobody wants to get paid like a commodity developer to have to perform like a rockstar. Being a commodity developer is more chill and there is less day to day risk and stress. Once you start getting towards the bleeding edge or reinventing the wheel your work becomes riskier and requires more mental effort and attention.
They should compare with other multithreading and GPU approaches for SAT/SMT solving (like https://www.win.tue.nl/~awijs/articles/parafrost_gpu.pdf from Armin Biere, or other works from Mate Soos). There has been a lot of research in this direction.
With arbitrary-precision, you can essentially replace the entire neural network with a single trainable parameter. [1] Likewise, in model checking, one often uses bounded-length bitvectors, because even a PDA with two stacks is Turing-equivalent. The poor separability between theoretical and physically-realizable models of computation is one of the weaknesses of the Chomsky hierarchy and classical approximation theory, and why more descriptive theories to characterize function complexity, e.g., circuit complexity, algebraic complexity theory and/or logical expressivity, are often needed.
When I joined Brain in 2016, I had thought the idea of training billion/trillion-parameter sparsely gated mixtures of experts was a huge waste of resources, and that the idea was incredibly naive. But it turns out he was right, and it would take ~6 more years before that was abundantly obvious to the rest of the research community.
As a leader, he also managed the development of TensorFlow and TPU. Consider the context / time frame - the year is 2014/2015 and a lot of academics still don't believe deep learning works. Jeff pivots a >100-person org to go all-in on deep learning, invest in an upgraded version of Theano (TF) and then give it away to the community for free, and develop Google's own training chip to compete with Nvidia. These are highly non-obvious ideas that show much more spine & vision than most tech leaders. Not to mention he designed & coded large parts of TF himself!
And before that, he was doing systems engineering on non-ML stuff. It's rare to pivot as a very senior-level engineer to a completely new field and then do what he did.
Jeff certainly has made mistakes as a leader (failing to translate Google Brain's numerous fundamental breakthroughs to more ambitious AI products, and consolidating the redundant big model efforts in google research) but I would consider his high level directional bets to be incredibly prescient.
I know you really mean it! but that doesn't change any of the above. In fact it makes it more important, since it's harder to stop posting like this when you really mean it.
It's difficult and frustrating to represent a minority view on the internet, especially one as rare as yours, which the vast majority of the audience are simply not going to understand or accept. What we often see is that contrarian/minority commenters compensate for this frustration by digging in and becoming sort of fixated on the point, intensifying their advocacy for the truth as they see it.
This can get you sucked into a loop where you keep turning up the volume and frequency of your posts in order to try to get a hearing, or to lash out at the majority, who often respond unfairly,—but all this only intensifies the resistance and outrage the majority comes back with. The way this dynamic ends is that we have to ban the account that's provoking the continued conflict—even if they're the one who is right (which sometimes, of course, a contrarian is). That sucks, but the only alternative would be flamewars everywhere, and that would suck worse.
The only thing I know that can help with this is accepting in one's heart that humans are nearly entirely wrong about nearly everything, and making peace with it. For this it can help to realize that it's probably as true of oneself as it is of anyone else. Also, people don't choose their views—for the most part we're conditioned by our backgrounds. Those don't move much, so it's hard for anyone to change their views, and it's certainly not going to happen in response to an internet commenter who appears fixated on a topic.
So it's not in your own interest to post like this, because it will actually entrench the others in their opposing view. If you allow yourself to keep upping the ante, you end up discrediting whatever truth you're trying to advocate. The only way to avoid this to deflate 90% if not 99% of the pressure you're putting on the topic—which I know is not easy, when you probably have many reasons to feel strongly about it.
Here are some past explanations I've made to other users in similar situations, in case any of it is helpful:
Roger Schank was one of the pioneers in Natural Language Understanding with his work on Conceptual Dependencies.
I remember reading, in the late 70s, about his SAM (Script Applier Mechanism) and PAM (Plan Applier Mechanism) and be amazed that a computer program could answer questions about natural language text. I still have my copy of his book "Inside Computer Understanding, Five Programs Plus Miniatures" which gave detailed explanations of how they were implemented.
SQL really sucks. In general I'm not a fan of SQL-like syntax since it makes queries with lots of joins really difficult to read -- it's hard to keep track which value came from where.
GraphQL has some neat ideas and I really love the clarity the nesting provides. But GraphQL is also too limiting: it can't express arbitrary filters, recursion, optional edges (i.e. left joins), etc.
My own take on this is an embeddable GraphQL-like language with all those features and with strong guarantees about execution performance. I've been calling it Trustfall, and you can play around with it (or check out example queries over HN data) in your browser here: https://play.predr.ag/
I am not surprised by your results. However, the system is more robust than your experience would indicate.
OpenCyc is a subset of ResearchCyc, which itself is a subset of (Full)Cyc. OpenCyc is primarily used for mapping between ontologies. It contains 239k concepts from ResearchCyc, but only the basic rules for definitional relationships between them. These relationships include part/whole, disjointness, etc.
You mention DBPedia as being superior for your purpose, but I would counter that the two are complementary. There is a mapping between DBPedia and OpenCyc within the Linking Open Data cloud. In fact, it was one of the first ontologies contributed to the W3C's LOD initiative[1][2].
The concepts in OpenCyc are rigorously organized from most general (e.g. Thing) to more specific (e.g. board game). Each concept may have specific instances (e.g. Yahtzee, Trivial Pursuit, Scrabble, etc.) These primitives all live within a custom Lisp, where they may be reasoned over. DBPedia's structure arises naturally from user activity. It is organized primarily by Wikipedia's category system and includes individual pages.
Unlike Wikipedia, the Cyc project does not aim to contain every instance of a concept. The relationships between concepts are what matter. Once one knows that something belongs to a given Cyc concept, one can leverage the system's knowledge to reason about it.
OpenCyc's reasoning capability is limited by a lack of assertions (facts and rules) -- ResearchCyc's is not. ResearchCyc contains over 5 million assertions not present in OpenCyc. (Things like: water is wet, a dog is a mammal, mammals have hair, etc.) It also contains Natural Language tools not present in OpenCyc: parsers, taggers and more. With these tools, one can go from natural language to a formal logic representation. Or, given a formal representation generate natural language. These capabilities exist today in real world applications[3][4].
Memcpying and executing code could also surface micro-architectural realities of the underlying CPU and memory subsystem micro-architecture that may need attention from the programmer.
For example:
- On most RISCy Arm CPUs with Harvard style split instruction and data caches special architecture specific actions would need to be taken to ensure that after the memcpy any code still lingering in the data cache was cleaned/pushed out to the intended destination memory immediately (instead of at the next cache line eviction).
- Any stale code that happened to be cached from the destination (either by design or coincidence) needs to be invalidated in the instruction cache.
- Depending on the CPU micro architecture, programmer unknown speculative prefetching into caches as a result of the previous two actions may also need attention.
Knowing the history of Prolog can be very useful to make progress in this area, because quite often, progress in this area means returning to what earlier systems already did.
For instance, already in the very first Prolog system, Marseille Prolog, a string like "hello" was treated as a list of characters, i.e., [h,e,l,l,o]. This was great for usability, as one would expect from a language that was designed for natural language processing.
Later systems switched this to lists of character codes, denoting code points in the used encoding. For instance, when using ASCII or one of its supersets, "hello" would then mean [104,101,108,108,111], which is much less readable in answers.
Still other systems introduced their own ad hoc types that were not lists and therefore could not be handled with Prolog's built-in mechanisms for reasoning about lists, most notably Definite Clause Grammars (DCGs), and thus even required their own dedicated and usually moded predicates for reasoning about them, thereby severely limiting their generality while increasing the complexity of application code.
Only the most recent Prolog systems, such as Tau Prolog and Scryer Prolog, are now doing what Marseille Prolog did, namely treating strings as lists of characters, and are also beginning to combine this with efficient internal representations to finally get all advantages at once: usability, generality, simplicity and efficiency.
Type checks are another example where Prolog systems are now going back to the solid foundations of Marseille Prolog, after decades of errands. For instance, to preserve monotonicity of Prolog programs, type checks must raise instantiation errors or delay the check if no decision can be made, e.g., the following would be a logically well-justified response because X can still become an integer:
?- integer(X).
ERROR: Arguments are not sufficiently instantiated
This is also what Marseille Prolog did, for very solid reasons that were very clearly outlined by Battani and Meloni. Prolog vendors soon found out that Prolog systems would sell better to customers who did not care about logical properties if such — to them strange and likely worrying — errors were not shown, and opted to instead answer such queries with silent failure, which is logically wrong and prevents for example declarative debugging techniques and different execution strategies such as iterative deepening:
?- integer(X).
false.
Now, logically sound type tests are appearing again in Prolog systems. For instance, Scryer Prolog already ships with library(si), where we have:
This is correct: We get an instantiation error, because no definite answer can be made at this point. X can become an integer, or a term that is not an integer, so answering either "yes" or "no" would not be appropriate, because the type of X cannot yet be determined.
A third example for this are constraints like dif/2, which is a relation with very desirable logical properties, denoting syntactic disequality of terms, i.e., it is true if and only if its arguments are different, and it delays checks until a definite decision can be made. This was present even in the predecessor of Marseille Prolog, Prolog 0, and then treated at best as a strange curiosity or not present at all in many later systems before it became more widely available again.
Using constraints also enables an even more elegant solution for the above cases. For instance, using CLP(ℤ), constraint logic programming over integers, we can constrain a variable to integers in the most general way:
?- X in inf..sup.
X in inf..sup.
Another very interesting aspect is the commercial context in which these systems were developed. There was a lot of money involved, Prolog vendors would give you a licence for thousands and tens of thousands of dollars, and still do today. Not that long ago, when you did a research project as a university student in cooperation with one of the Prolog vendors, the vendor would personally fly over and hand you a hardcopy of the system manual. Then, after you finished the project, the vendor would visit you again to take away the manual.
If you think, hey but people had a “job” in 1700, and they had a “job” in 1900, think again. Being a peasant (majority of people in Europe in 1700) and being an urban factory worker in 1900 were fundamentally different ways of life. They only look superficially similar because we did not live the changes ourselves. But read the historical sources enough and you will see.
I would go as far as to say that the peasant in 1700 did not have a “job” at all in the sense that we now understand; they did not work for wages and their relationship to the wider economy was fundamentally different. In some sense industrialization created the era of the “job” as a way for most working-age people to participate in economic life. It’s not an eternal and unchanging condition of things, and it could one day come to an end.
It’s too early to say if AI will be a technology like this, I think. But it may be. Sometimes technologies do transform the texture of human life. And it is not possible to be sure what those will be in the early stages: the first steam engines were extremely inefficient and had very few uses. It took decades for it to be clear that they had, in fact, changed everything. That may be true of AI, or it may not. It is best to be openminded about this.