It did my heart good to see Forth listed.
The seven programming ur-languages (2022)
91–100 of 161 posts
Re: The seven programming ur-languages (2022)
#92Reminds me a bit of Bruce Tate’s approach in 7 languages in 7 weeks, which is where I first encountered Erlang. I think from a historical perspective, describing COBOL and Fortran as part of the ALGOL family is a stretch, but I suppose it’s a good reminder that all history is reductive.
Does anybody know whether Fortran is older or younger than Algol? From Wikipedia, it looks like they were both developed around 1957. Was there any overlap in the design?
Algol was published in 1958, and FORTRAN in 1957. I think it's fair to say they were developed concurrently.
Re: The seven programming ur-languages (2022)
#93Earlier quoted context omitted.
Rather COBOL is a living fossil? And today's Fortran is the FORTRAN family with horizontal gene transfer from the Algol lineage of programming languages.
Both languages have their standards updated still, latest year in both cases was 2023. Fortran is one of the reasons OpenCL lost to CUDA, and now even AMD and Intel have finally Fortran support on their own stacks, not Khronos based. https://developer.nvidia.com/cuda-fortran Whereas Cobol, even has cloud and microservices. https://www.rocketsoftware.com/en-us/products/cobol/visual-c... https://aws.amazon.com/mainfram…
> Fortran is one of the reasons OpenCL lost to CUDA, and now even AMD and Intel have finally Fortran support on their own stacks, not Khronos based.
FWIW, I loved using CUDA-Fortran. I think the ease of use of array variables maps very well with the way CUDA kernels work. It feels much more natural than in C++.
Re: The seven programming ur-languages (2022)
#94I wrote something similar here: https://fmjlang.co.uk/blog/GroundBreakingLanguages.html We agree on Algol, Lisp, Forth, APL, and Prolog. For ground-breaking functional language, I have SASL (St Andrews Static Language), which (just) predates ML, and for object oriented language, I have Smalltalk (which predates Self). I also include Fortran, COBOL, SNOBOL (string processing), and Prograph (visual dataflow), which wer…
I like your list better, mostly because of the inclusion of SNOBOL, which I never used, but was one of the first programming languages I read about as a young child after a book about it caught my attention at a public library book sale because of the funny name.
The only languages I was familiar with before this were BASIC, Logo, and a bit of 6502 assembly, though I had only used the latter by hand-assembly and calling it from BASIC following an example in the Atari BASIC manual[1].
Also, it's hard for me to imagine how anyone could make a list of ground-breaking programming languages that doesn't include Fortran and COBOL (or FLOW-MATIC as the source of many of its innovations).
[1] https://archive.org/details/atari-basic-reference-manual/pag...
Re: The seven programming ur-languages (2022)
#95I always enjoy these summaries. I took my bachelor of computer science in the early 1990s. It covered a language in most of these categories. We didn't learn APL (Who is teaching the use of those custom keyboards to 100s of young students for one semester?) The processing power of systems at the time made it clear which language classes were practically useful and usable for the time and which were not. Prolog ran li…
> who
Yale :-) Alan Perlis' intro to CS at Yale back in the late 80s was an APL class (a relatively small one, though.)
Re: The seven programming ur-languages (2022)
#96I wonder if Occam is worth a mention? It doesn't feel like anything else here, and is playing with its hardware synthesis descendants on a FPGA is another "mind expanding" paradigm.
Re: The seven programming ur-languages (2022)
#97I recently revisited a language comparison project, a specific benchmark tallying the cycle decompositions in parallel of the 3,715,891,200 signed permutations on 10 letters. I kept a dozen languages as finalists, different philosophies but all choices I could imagine making for my research programming. Rather than "ur" I was looking for best modern realizations of various paradigms. And while I measured performance I also considered ease of AI help, and my willingness to review and think in the code. I worked hard to optimize each language, a form of tourism made possible by AI.
The results surprised me:
F# 100 19.17s ±0.04s
C++ 96 19.92s ±0.13s
Rust 95 20.20s ±0.38s
Kotlin 89 21.51s ±0.04s
Scala 88 21.68s ±0.04s
Kotlin-native 81 23.69s ±0.11s
Scala-native 77 24.72s ±0.03s
Nim 69 27.92s ±0.04s
Julia 63 30.54s ±0.08s
Swift 52 36.86s ±0.03s
Ocaml 47 41.10s ±0.10s
Haskell 40 47.94s ±0.06s
Chez 39 49.46s ±0.04s
Lean 10 198.63s ±1.02s
Re: The seven programming ur-languages (2022)
#98Which category is TRAC? https://en.wikipedia.org/wiki/TRAC_(programming_language)
Re: The seven programming ur-languages (2022)
#99I might add another class of languages: those intended to express proofs, via the Curry-Howard correspondence. Lean is a primary example here. This could be considered a subclass of functional languages but it might be different enough to warrant a separate class. In particular, the purpose of these programs is to be checked; execution is only secondary.
These are not true programming languages because by definition they are not Turing complete. If they were Turing complete it would be possible to write a false proof that just compiled down to a non-terminating program.
There has never been a requirement for a "true" programming language to be Turing complete.
Also, basically every such language has escape hatches similar to unsafe in Rust to allow expressions that are not provably terminating.
They can then just be accepted as an axiom.
Re: The seven programming ur-languages (2022)
#100there's a few more semantic families: verilog, petri nets and variants, Kahn process networks and dataflow machines, process calculi, reactive, term rewriting, constraint solvers/theorem provers (not the same with Prolog), probabilistic programming, plus up and coming (actual production-ready) languages that don't fit perfectly in the 7 categories: unison, darklang, temporal dataflow, DBSP It may feel like a little b…
>term rewriting In uni we had to make a spreadsheet software. I volunteered to do the formula parser, thinking it sounded like a fun challenge. I was stumped for a week, until I realized I could rewrite the formulas into a form I knew how to parse. So it would rewrite 1+1 into ADD(1,1) and so on. I also refused to learn regex, so the parsing code was "interesting" ;) I recall a comment from a colleague. "Okay, Andy s…
Regular expressions are probably not enough for parsing formulas (depending of course on the exact task given), they usually are at least a context free language.