And one other thing: just because early Prolog interpreters were implemented on punchcards doesn't mean that Prolog programs run by those interpreters needed to be. It's quite possible that basically nobody ever wrote Prolog programs using punchcards, given that Prolog has the ability to read in files of code and data.
By 1979 at the latest -- probably closer to 1975 -- the primary Prolog implementation of the day (Warren's DEC-10 version) had an interpreter, where you could load files of code in and modify the code and you had a REPL with the ability to do all kinds of things.
I posted an excerpt of the manual, with a link to a PDF of it, in a reply to another comment [0]
(And, since even the earliest versions of Prolog were interpreted, they may've had features like this too).
And, as far as editors are concerned, people still use versions of vi (and, of course, emacs) to this day by people who don't necessarily do lots of planning and correctness before deciding to input the code into the computer.
The following is from David H.D. Warren's manual for DEC-10 Prolog, from 1979 [0]. It describes how Prolog development is done interactively, by being able to load code in dynamically into an interpreter and using the REPL -- note that the only mention of using paper is if the developer wants to print out a log of what they did during their session:
Interactive Environment Performance is all very well. What the programmer really needs is a good inter-active environment for developing his programs. To address this need, DEC-10 Prolog provides an interpreter in addition to the compiler.
The interpreter allows a program to be read in quickly, and to be modified on-line, by adding and deleting single clauses, or by updating whole procedures. Goals to be executed can be entered directly from the terminal. An execution
can be traced, interrupted, or suspended while other actions are performed. At
any time, the state of the system can be saved, and resumed later if required.
The system maintains, on a disk file, a complete log of all interactions with the user's terminal. After a session, the user can examine this file, and print it out on hard copy if required.
Languages like Prolog just don't offer that sort of freedom.
Yes, they do -- that's why people have enjoyed using such languages.
It might help to think of them as being like very-high-level scripting-languages with more rigorous semantics (e.g. homoiconicity) and some nifty built-ins, like Prolog's relational-database. (Not to mention REPLs, tooling, etc.)
Read, for example, what Paul Graham wrote about using Lisp for Viaweb (which became Yahoo Store) [0] and understand that much of what he says applies to languages like Prolog and Smalltalk too.
Like Lisp and Smalltalk, Prolog was used primarily in the 1980s, so it was run on Unix workstations and also, to some extent, on PCs. (There were even efforts to create hardware designed to run Prolog a la Lisp machines.)
And, like Lisp and Smalltalk, Prolog can be very nice for iterative development/rapid prototyping (where the prototypes might be good enough to put into production).
The people who dealt with Prolog on punchcards were the academics who created and/or refined it in its early days. [0]
...these things were mostly written(and rewritten till perfection) on paper first and only the near-end program was input into a computer with a keyboard.
Not if you were working in a high-level language with an interpreter, REPL, etc. where you could write small units of code that were easily testable and then integrated into the larger whole.
From less than 2 weeks ago: "How MongoDB Atlas’s Forced Upgrades and Support Policies Drove Us to PostgreSQL" [0] -- TL;DR: MongoDB lost a $50K/yr Atlas contract due to the way they do things.
FYI, the term was first used in Britain in 1750, according to the term's Wikipedia page[0], which discusses how the term was used in different countries in a neutral way until about 1860 in Germany, at which point it was used in a more antisemitic context.
That's not likely to be a problem since these days every board game has a number of instructional videos (and that's in addition to video reviews, which typically show how a game works, though not in as much detail).
From the Leo Frank Wikipedia page [0]: "In modern times, despite strong evidence pointing to Frank's innocence, the case has become a modern focal point for neo-Nazis and anti-Semites. This is partly because it led to the creation of the Anti-Defamation League but also because it fed into anti-semitic conspiracy theories claiming Jewish control of the media. As a consequence, in recent years a number of websites have been established by white supremacists disputing the prevailing consensus of Frank's innocence."
Just a reminder that HN's official "Who is Hiring?" post is put up on, or about, the first of each month. So the September post should be up by next Tuesday at the latest (i.e. assuming it's postponed till after the weekend and the Labor Day holiday).
Well, for starters, you don't have to have your apps containerized to work with Nomad (though it can handle containers as well as executables).
But for some deeper details, I'd suggest checking out the comments in this reddit thread[0] (as well as some of the linked articles therein).
E.g. From a comment by /u/Golden_Age_Fallacy: A great use of Nomad is on reduce the burden of on-boarding a team(s) of developers who are unfamiliar with cloud native deployments / systems(even containers!).
Nomad jobspecs are very simple and straight forward, as compared to the complexity and pure option overload you get in k8s and helm.
From /u/neutralized: It's much easier to use than k8s. Easy to setup, easy to manage, much more shallow learning curve. Nothing super fancy. Just works. I migrated a startup I was at off of a self-managed k8s setup to Nomad a few years ago and they've never looked back.
From /u/esity: My team is currently building out a fully automated nomad cluster service offering internally(fortune 10)
It's super awesome. Easy. Little headache. Integrates with consul and vault. We are literally planning to replace thousands of vms for K8s with nomad. Containers are faster, more resilient and writing hcl is actually fun once you learn it
Now, there is a rather more lengthy comment, by /u/thomasbuchinger, that goes through the pros and cons he experienced in trying Nomad out and his conclusion is that, while he wouldn't discourage anyone from using it, "k3s and a few well-known simple projects give you 80% of Nomands [sic] features. Are as easy to operate, afford you more options in the future and have a ton of documentation/tutorials...available."
There are more comments in the thread and again links to a bunch of blogposts/articles/etc., including one from fly.io that seemed pretty detailed, discussing the Googly origins of both k8s and Nomad (fly.io used Nomad but found that it wasn't the best fit for them, which is also discussed in their post -- actually, I'm going to put the link to their post below[1], since I think it is worthwhile).
BTW, for anyone interested in learning more about Lisp macros, Paul Graham's book about advanced Lisp programming, On Lisp, covers the topic pretty extensively and it's freely downloadable from his website:
[0] https://en.wikipedia.org/wiki/Spaceballs:_The_New_One