That’s cool, I didn’t know punch cards ever supported more than Assembly.

​@@xWatexx COBOL is also 1 of the punch card languages

@@xWatexx Punch cards are just an input method, that has two obvious advantages over a keyboard: they are very fast (no human can hope to type that fast) and they have intrinsic memory (you could store your program on punch cards in a drawer somewhere, and input it into the computer whenever you needed). This was very convenient when computer storage was limited and you couldn't store your programs on a computer, so you had to input them every time you ran them. Being an input method, punch cards are language-agnostic, they are just a sequence of characters. How these characters are interpreted by the computer depends on the software running on the computer. If that software was a FORTRAN compiler, it expected correct FORTRAN code on the punch cards, etc.

​​@They are language agnostic if you limit the line length to fit on the punch card. You can always add more lines by adding cards, but you can't make the cards wider.

Ditto. I can't recall which version of Fortran we were using, but we used punched cards too. I also did a project for the university in Fortran on punched cards. It was in a huge box 300-400mm long. I was terrified of dropping it. What I find odd in this video was his use of lower case characters. Back in those days, upper case was the norm.

I remember that same donut animation for the terminal already done like 4 years before, but I see this individual explaining, between jokes, like he is creating the logic for it for the first time and inventing the wheel.

@@AetherStreamer you literally see him bring up a guide like 3-4 times wtf you on about lol of course its not a new concept

Because time is the 4th dimension and the object is moving through time lol

I don't think you can really blame the "horrible mess" on Fortran, though. That has more to do with how physicists, unfortunately, tend to write spaghetti code that "just works." Part of that is likely due to years of modifications by different graduate students that were probably using Fortran for the first time when they made their contributions.

@@latt.qcd9221 Part is because of the language it self, Fortran has these "common" blocks wich allows you to share variables between subroutines. The problem is that you only need to include a subset of the variables in your common block (the compiler may or may not complain) which result in the fact that you one don't know how many variables a common block has. Furthermore, you can't know which subroutines uses your common block so you have no idea if one of the variables will change when you call a different subroutine. While what you say is true that many phycists write spaghetti code, Fortran makes spaghetticode easy to write and sometimes necessary.

@@tordjarv3802 Common blocks? Are you talking Fortran 77? Fortran 90 replaced those with modules which are great to work with. Fortran 77 was definitely more frustrating to work with, but Fortran 90 on are substantial improvements that are nice to work with. I would agree, though, that Fortran can make spaghetti code easy to write. Not sure I'd say it's necessary, though, with Fortran 90 onward.

@@latt.qcd9221 Fortran 77 is still in use bro. There are some old guys who thinks that it is the only "real" programming language.

I inherited a g77 mess for my PhD, the problem wasn't fortran, the problem was the attitude of "don't bother to learn how to code properly, this spaghetti just works, add yours at the end" by the senior colleagues.

Specifically, FORTRAN is one of the easier languages to do very efficient and scalable supercomputing with, as the language has built-in features that make parallelization of array and matrix operations far easier than, say, C. Plus, the weird constraints of FORTRAN allows for insane compiler optimizations that wouldn’t work reliably within C’s syntax. This is part of why Rust code can occasionally be faster than C: the compiler can safely make more assumptions, hence better optimizations.

@@romannasuti25 neat!

Can confirm that old-head physicists use it today too

I think the big reason is that there is a lot of battle tested numerical code in Fortran. I think that is partly a consequence of computers being used as an aid to engineering from some earliest days.

​@@christopheroliver148 To this day NASTRAN is still (arguably) the gold standard for FEI despite being FORTRAN software from the 60's.

I started in Political Science and History, wound up writing code for a living. Life is strange and takes us on journeys we never dreamed of. I loved the ride.

I studied art. Now I'm unemployed.

Imagine programming in brainf......

_cough cough_ *c* _cough cough_

VT100 escape codes! All that's left of Digital Equipment Corporation oh VMS still lives with VSM Systems after it migrated from VAX to Alpha to Itanium to now X86_64 and survived Compq and HP.

If you are on a Unix system, the CORRECT way to do that is to use high level commands. It looks like your terminal type is vt100 or similar. The correct way to use high level commands is to use "tput" terminal-put with appropriate arguments. ESC[0;0H is "postion cursor position at (0,0)" which is generated by the command: tput cup 0 0 ESC[H is "send cursor home (ie, 0,0) without clearing the screen" which is generated by the command: tput chome ESC[?25l is "make the cursor invisible": tput civis ESC[2J is screen clear: tput clear Note that if you use a newer emulation package from vt100, such as vt220 or vt340, you get more commands. You can do things like clear the screen and choose whether that does a cursor home or not. Mind you I havent dont this since 2004 so I am working from memory here LOL. Embedded raw escape sequences within your program like that is very very bad practice. It ties your program to work on only one terminal type.

Had a course in FORTRAN 90, was quite interesting to see a different approach than C-style languages while still using a low-level language.

I have dipped my toes into Fortran coding a bit on the later variants and I think it's actually a pretty good language that's underrated outside the science world. I can't help to think that languages like Python are creating the same level of programmers as Basic did in the 80's.

You mean "writes"? Actually, the fastest Fortran implementation right now is a Fotran-to-C++ translator!

@@JohnDlugoszNot when LLVM’s Flang will be out.

​@@JohnDlugoszFortran is pure pain when you're forced to write Fortran 77 for college. There are compiler bugs that will never be fixed. And I will not fix them because no one fucking uses Fortran 77

I have heard that from several sources; the problem is that I have never actually found any concrete evidence, just some handwavy arguments about cache efficiency which are mute after the introduction of the restrict keyword in C.

@@tordjarv3802 You mean "moot".

By "GO" did you meant golang?

Everyone knows that manually wiring together a program is the oldest programming language:;)

@@Catterjeeo Nah, it's having a human manually interact with the users

ассембли донат вен?

hmmmmmm... looks like i gotta incorporate your video making style into mine videos 😅

MATLAB is sort of a port of an earlier FORTRAN library

And still are. what do you think is the source of all those numerical libs for, say Python.

Also, the syntax he's showing here seems to be Fortran90 from the late 1980s or early 1990s, not the original FORTRAN of 1956.

​@@herrbonk3635 it's looking like Fortran 77 which is what he said he'd use.

0:36 “I know what you’re thinking. Assembly is the oldest…..”

@@rdspam Machine code is much older than assembly. It took a while before the first assemblers were designed. Old computers didn't have memory enough for such luxury.

I seem to remember a language called Math-Matic as a calculating language perhaps older than FORTRAN. One could argue that machine code is not a language. If anything each computer architecture had its own "way of expressing an algorithm". Og "way of expressing a core dump".

Eh... you can't compare an interpreted language to a compiled one... there's your speed issue.

Hell yeah. Had object pascal (Borland Delphi) as my first language in 2013 and used it for 3 years in an apprenticeship (Embarcadero Delphi). Something about how those languages enforce clean code and project structure just feels good.

@@xormak3935 There is certainly a push towards making cleaner structures but... after years of using Delphi for backend development, I just... seen too much. It's harder to make ugly code when compared to stuff like JavaScript, but holy hell, when you have someone write some arcane curse, it sticks. Still to this day I see stuff like "PInt64(@pBuffer[nOffset])^ := SomeInt64" and other ungodly pointer hacks lol

​@@erikkonstaspure Python sure but, more importantly, how would a numpy-based program perform compared to Fortran? As they say, the most effective way to use Python is to use the least Python possible.

latest Fortran std I know of, is labelled 2018 - it's young. Modern Fortran has interesting features (I wouldn't use it to make web services, or a GUI, though…). I bet there are new projects written in the language, not just legacy code to be maintained. Of course you won't see many of them in the wild, since the language is more suited for certain kind of tasks which aren't so common.

True😂

Try, Matlab for computational physics. Fastest way to break my heart as a python enthusiast

awesome comment!

Correction: it applies to the AI that will replace the youth before they get a chance 😭

​@@josephbrandenburg4373 what're your qualifications?

​@@josephbrandenburg4373 are you, by any chance, a prompt engineer?

Fortran compilers also have a habit of pretending to support the newest features, but then produce horrible bugs if you use them in any way that is slightly more complicated than the example code.

All compilers adding new features have the same issues. Fortran is no worse, and more likely better because it tends to design the features better.

@@roadrunner3563In my experience: No. I have never seen so many compiler bugs in another language. I use ifort and gfortran, and both have their own problems. Final subroutines, mixing associate and or block with openmp, syntax errors involving pointers leading to compiler crash, parameterized len, etc.

That what I was thinking too.

"The reason behind declaring all the variables at the beginning has a good reason"

@@vibaj16 I must have been very tired when writing that. Thank you for noticing it - I've already corrected that.

Dynamic memory allocation has been included in Fortran for ages. There is even automatic deallocation when a variable goes out of scope (when using "allocatable" instead of "pointer"). Some other features are also really nice, for example the lower bound of an array can be set to a custom value, not just the upper. However, overall the language is too verbose and a lot of boilerplate code is necessary if you want to code safely.

GO NORTH EXAMINE DESK TAKE KEY

AFAIR it was an own "game language", realized in FORTRAN. So it internally processed things like 'if near water then...' and so on.

@@petewdev5591 KILL BIRD The little bird is now dead. (Unsaid, you just screwed yourself on completing the game).,

I needed this thx

Both. Algol/Pascal/Matlab influence as well.

@@georgerogers1166 and what is the practical side?

Well, I notice that most programming languages tend to either follow the Fortran model or the C model to varying degrees, what with COBOL proving a bit of a dead end as far as influencing future languages. With Fortran-like languages, a new code statement is generally on a new line, and code blocks are delimited with a phrase like "end" or similar. This includes languages like BASIC, Julia, Pascal, and Python. Python takes this approach to the ultimate logical conclusion by actually using the indents themselves as code blocks, removing the need for an "end" type statement. Other Fortran-like influences include a generally more lax approach to variable typing, with implicit typing often being the case. The C-like languages such as Java, Rust, and Perl, all tend to use curly brackets { } to mark out code blocks, generally ignore spaces or new lines, and require a specific termination character for each statement, such as a semicolon. They also tend to be a lot stricter with variable typing and require explicit type declarations. IMHO Pascal manages to combine the worst of both worlds, with semicolons on the end of statements, explicit BEGIN and END; around every block, and a whole bunch of other pedantry. 😂 Personally I find Fortran and descendants like Python and Julia MUCH more pleasant and clean looking than the C model of curly brackets and semicolons everywhere. But to sum up the answer to your question, there needs to be SOME way to indicate a code block to the compiler or interpreter and "end" is as about as short and clear as you can get without brackets. Yes, Python is even cleaner, but FORTRAN was originally developed at a time when programmers usually didn't even USE indents in their code!

@@calebfuller4713 you forgot "one liner" languages (haskell, erlang, unison and related), where code mostly consists of definitions and expressions, with virtually no statements. and array languages, where everything is a hieroglyph. of course, there is also lisp, which has the one and only correct syntax.

Asking as someone that just learned Fortran as a word. What does it have that you think is better than c for doing calculations?

@@gabrielmourao2854 I am by no means expert in C but - Fortran is literally "formula translator". It's made for that and it shows. It's very handy despite being low level, and it has a good syntax for that. Plus, it feels like you are in total control of what's happening. On the other hand, Fortran is terribile for everything else.

Same

Yeah, it involves physics...

Yeah. Many fast numerical python packages are actually Fortran under the hood

Julia runs natively on a GPU

@ramy8338 oh that's super cool!!! Dam thats like a really good reason to do data scince with it. Can u be clever about memory or are u stack with the gc?

yeah and also oop support - neither necessarily good ideas... modern Fortran rocks , always be wary of bloated bs concepts being introduced...

yeah but Plankalkül wasn't widely used back then. It still kinda exists for historical reasons.