Four Languages from Forty Years Ago - Scott Wlaschin 

Did you know that Borland had a "Visual Prolog" in the 80's? If there was ever a chance that it could take off...

LISP's still ahead of time nowdays.

Between Lisp and Algol-68, all language features were known.

Prolog IS cool. That’s why they called it Prolog: PRObably the Language of God.

My advice: first really learn Prolog (not only toy applications), then learn SQL. Prolog is from the domain of artificial intelligence, and SQL is quite similar to Prolog (all about relations). A lot you can do in Prolog, you can do in SQL, only with a lot more typing…

Thanks for the tips! I know SQL from my workplace and I've done a little bit of Prolog in the past in my AI course at university (and disliked it, mostly because the academic examples didn't seem all that practical). I guess now's the time to delve deeper into Prolog :).

@@Ghi102 If need some assistance in Prolog or in translating concepts from SQL to Prolog and vice versa, give me sign.

Yeah, I'd really love to know what's going on behind the scenes

Terminal is not *the* best way to interact with a computer. Different types of interaction are best supported by different types of interaction. GUIs are great if you don't know anything and need to find your way around, but if you do know everything a GUI's very liable to slow you down :Ü™

@@Darker7 I'm not advocating for drawing graphs is terminal, or anything like that. In the context of this video, it was meant as keyboard driven coding in terminal vs mouse driven interactive IDE. To clarify, I don't have anything against the abstract idea of an IDE. In practice however, it gets in the way of programming. For example, it often tries to enforce syntax conventions, which often lead to boilerplate code, or simply aren't applicable is the current situation.

@@Jagi125 Interestingly, the Smalltalk IDE does not enforce syntax conventions. It understands messages and can help you out in the same way intellisense does in other IDEs by allowing you to choose a message and put in placeholders to replace but it doesn't do much else. The Smalltalk IDE is really there to help you navigate the entire code of the system allowing you to change that code in real time. Obviously, the text portion of the interaction is still done with a keyboard but then again, NOBODY actually programs on a terminal anymore. That is equivalent to using cat to enter your text into a file. Most people still use an editor of some kind that allows for convenience while entering and editing that text. The Smalltalk IDE is different in that it supports other interactions beyond entering and editing text. It really is something worth using personally before passing judgement.

Yep. Basically. I wouldn’t say they’re consoles though. But full blown GUI IDEs. You really can’t do things like conditionals and loops effectively in GUIs.

yeah i agree. it also decouples the act of saving your work somewhere and testing it. i think there's a good reason that most people actually save python to files rather than use the REPL/IDLE since it's just more convenient for anything more than a few lines and i think it's easier to compose/generate code across multiple programs. like it's easier for one program to modify a file than try to pull up an IDE and interact with it.

"There is no file" is an illusion: in the end your code is saved somewhere. The important part is that choosing how to organize stuff on disk should not be an important decision for the programmer. In a certain way Java, enforcing to a certain extent that classes have to be in a file named in the same way inside a directory structure that is a direct representation of the package structure goes in the same direction. In javascript what happens is that the path of the file where an identifier is implemented is a visible property inside the source code, and thus part of the identifier itself. These are good ways to stop thinking about where some stuff is without losing the ability to organize the code in different places. On the other side we have C and C# where the files that are being used inside the compilation are defined as part of the build system configuration, and have nothing to do with how things are identified in code. Arguably this makes even harder to understand code without using external tools (e.g. telling if a file is included or not in the build just by looking at the code may be difficult if it is a C project that uses CMake), such as when reviewing it or solving conflicts (for example, if filename is not enforced there is nothing preventing two developers from using the same identifier for two different items and put them in separate files - not even a conflict)

@@pqnet84 Java is too serious about their filesystem convention, which I don't really like. I like the way it is done in Go. You have a package, in which everything is shared, and you can make some thing public, to be used outside of the package. This way you have both encapsulation and detachment of specific filesystem structure. You still have packages and other things, that are mandatory, but this gives you quite a lot of freedom.

It does fit into the video's theme, it changes the way you think about programming since it works so differently from other languages. Some people hate on COBOL without realizing how important it still is, or maybe they're just repeating what others say without knowing why they hate it.

Have you ever used it? It is insanely verbose. I once wrote a COBOL program to read in a deck of cards and sum the columns. It took three pages. I similar program in a language such as C would have taken ten lines or so.

@@ktsnowy Just because a language is important doesn't mean it can't be ugly. And it doesn't really do things differently---conceptually different, that is---from other imperative languages. It just does things more awkwardly and verbosely.

@@michaelsommers2356 I have used it, I'm one of the maintainers of the Exercism COBOL track. I imagine you must have used an older version of it since you mentioned pages instead of lines, was it COBOL 85? Newer versions have a lot of nice features that would help reduce the number of lines, COBOL 2022 even has async messaging.

@@michaelsommers2356 It is very verbose yes, but that's a plus for me. I can easily read through a well written COBOL program and instantly know what it's trying to do because it's mostly English. Sure, you have to write more stuff when starting a new COBOL project, but if it's well written anyone will be able to understand and maintain it without having to learn and memorize what a bunch of different symbols mean. Some newer languages try to compact the syntax into a bunch of symbols and that, in my opinion, makes it harder and more time consuming to read. Makes it easy to write for the first time, but then who will be able to understand and maintain that symbol soup without taking a huge amount of time "unpacking" what everything means?