The seven programming ur-languages (2022)(madhadron.com) |
The seven programming ur-languages (2022)(madhadron.com) |
Technically, FORTRAN is the oldest. One could argue that ALGOL is the most influential for language design.
in jq, the comma separates expressions, which independently yield values. a span of such expressions is called a 'filter', since they are always run by passing values from the prior filter into them (with the initial values sourcing from json objects on stdin, or an implicit null if you pass -n to the program).
$ jq -nc ' def x: "a", "b", "c" ; def y: 1, 2, 3 ; x, y '
"a"
"b"
"c"
1
2
3
$ jq -c '. + 10, . + 20' <<< '1 2 3'
11
21
12
22
13
23
$ jq -nc ' def x: "a", "b", "c" ; def y: 1, 2, 3 ; [x,y] '
["a","b","c",1,2,3]
$ jq -nc ' def x: "a", "b", "c" ; def y: 1, 2, 3 ; {"foo": x, "bar": y} '
{"foo":"a","bar":1}
{"foo":"a","bar":2}
{"foo":"a","bar":3}
{"foo":"b","bar":1}
{"foo":"b","bar":2}
{"foo":"b","bar":3}
{"foo":"c","bar":1}
{"foo":"c","bar":2}
{"foo":"c","bar":3}
$ jq -nc ' 1,2,3 | 10 + . '
11
12
13
$ jq -nc ' 1,2,3 | (10 + .) * . '
11
24
39
$ jq -nc ' (1,2,3) as $A | $A + $A '
2
4
6
for example, this runs `. + 100` parameters context, with `.` as the 10,20,30 passed to it:
$ jq -nc ' def f($t): 1,2,3|$t ; 10,20,30|f(. + 100) '
110
110
110
120
120
120
130
130
130
$ jq -nc ' def f(t): 1,2,3|t ; 10,20,30|f(. + 100) '
101
102
103
101
102
103
101
102
103
$ jq -nc ' def m(todo): [.[]|todo] ; [1,2,3]|m(. * 10) '
[10,20,30]
for example, I would say what i was taught, that lisp is lists made out of cons cells, which contain references to either other lists/cons cells or to atoms. lisp doesn't "have" parentheses any more than lisp has the rest of the ASCII table, but parentheses were chosen as a convenient way to write list structure down in ascii form because parentheses nest in exactly the way lists do and lists are the important thing.
then there never needs to be another discussion of parentheses and how you feel about them except in a sub-discussion if anybody has any bright ideas about alternative ways to convert list structure to ascii on paper. you disliking parentheses does not mean you dislike lisp; it just means you don't understand lisp, like for instance you think lisp has something to do with ascii.
similar ideas apply to C, wherein the braces and semicolons do not matter, what matters is datatypes that correspond to von neumann architectures including especially pointers, and where binary representation is easily exposed (with a syntax that does not matter but for the record is &, |, ~, ^, <<, or >>. if you hate those choices for operator syntax you could easily convert your own C to use parenthetical lists of CamelCase names of LeftAddRight or whatever floats your boat instead of a + sign), just keep in the front of your mind how data is represented internally and how it's mapped to the syntax you like, and whatever list structure you choose to order the lines of code)
Ur-ness is not interesting, just as the city of Ur was no doubt a lot less interesting than the city of Rome. Study Algol only to learn about call-by-name, then forget it.
I could go on, but, like the ripples from a gold coin thrown in the bay, the effect will soon dissipate as if I had never written anything at all.
Advice to juniors (say) to spend time learning multiple programming languages over good command of a single one, deep expertise in LLM use and basic software engineering principles is going to severely undermine their value in an already tough field for entrants. For seniors there will generally already be a reasonable grounding in multiple paradigms; delving much further into legacy manual coding styles is going to see them leapfrogged by experts in modern (ie AI-assisted) approaches.
[1]: https://www.cambridge.org/ir/universitypress/subjects/comput...
Ruby is object oriented from the ground up. Everything (and I do mean everything) is an object, and method call is conceived as passing messages to objects.
While Ruby is most often compared to Python (an Algol), they come from very different evolutionary routes, and have converged towards the same point in the ecosystem. I think of Ruby as a cuddly Alpaca compared to Python's spitting camel.
I love to point this out to OOP haters,
>>> type(42)
<class 'int'>
>>> dir(42)
['__abs__', '__add__', '__and__', '__bool__', '__ceil__', '__class__', '__delattr__', '__dir__', '__divmod__', '__doc__', '__eq__', '__float__', '__floor__', '__floordiv__', '__format__', '__ge__', '__getattribute__', '__getnewargs__', '__getstate__', '__gt__', '__hash__', '__index__', '__init__', '__init_subclass__', '__int__', '__invert__', '__le__', '__lshift__', '__lt__', '__mod__', '__mul__', '__ne__', '__neg__', '__new__', '__or__', '__pos__', '__pow__', '__radd__', '__rand__', '__rdivmod__', '__reduce__', '__reduce_ex__', '__repr__', '__rfloordiv__', '__rlshift__', '__rmod__', '__rmul__', '__ror__', '__round__', '__rpow__', '__rrshift__', '__rshift__', '__rsub__', '__rtruediv__', '__rxor__', '__setattr__', '__sizeof__', '__str__', '__sub__', '__subclasshook__', '__truediv__', '__trunc__', '__xor__', 'as_integer_ratio', 'bit_count', 'bit_length', 'conjugate', 'denominator', 'from_bytes', 'imag', 'is_integer', 'numerator', 'real', 'to_bytes']Perhaps this is the counterfactual: I program in Python regularly, but don't program in an OOP style; I use dataclasses and enums as the basis, in a way similar to Rust, which by some definitions can't do OOP. So, if Rust can't do OOP (assumption) and I can write Python and Rust with equivalent structure (Assumption), does that mean Python isn't strictly OOP?
CL-USER> (class-of 42)
#<BUILT-IN-CLASS COMMON-LISP:FIXNUM>I wonder if my formal university python training predated this change (~2010), or if the professors were themselves unaware of this.
That seems like a pretty lame gotcha--saying "Aha! The language you write in uses your hated paradigm under the hood" seems to invite the immediate response of "So? I don't use it."
That's a deep cut. :-)
For anyone reading this, O'Reilly was once legendary for their cover-art mascots.
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
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 bit of cheating mentioning the above ones, as most are parallel to the regular von Neumann machine setup, but was meaning for a while to do an article with 'all ways we know how to compute (beyond von Neumann)'.
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 were similarly ground-breaking in different ways.
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...
Also ML is seen as a child of Lisp.
It made learning Elixir years later much easier.
We also had a course that basically summed up to programming agents to play Unreal Tournament in a language called GOAL which was based on Prolog.
For years I've wanted to use Prolog but could not figure out how. I ended up making a spellcheck to allow LLM's to iterate over and fix the dismal Papiamentu they generate.
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.
[0] https://www.cl.cam.ac.uk/teaching/1011/FoundsCS/usingml.html
Also 30 Sept 2021, 29 comments, <https://news.ycombinator.com/item?id=28704495>.
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 like a dog for even simple sets of logic.
We had the best internet access and pretty powerful desktop systems for the time.
I'm still curious why we didn't learn smalltalk. Could have been the difficulty of submitting and marking a system in a particular state rather than a file of code :)
Yale :-) Alan Perlis' intro to CS at Yale back in the late 80s was an APL class (a relatively small one, though.)
Smalltalk VM
Smalltalk image file
sources file (plain-text original source code file)
changes file (plain-text change log, initially empty)
See "OU LearningWorks: a customized programming environment for Smalltalk modules"
One I might suggest is scripting languages, defined loosely by programming tools which dispatch high-level commands to act on data pipelines: sed, AWK, the sh family, Perl, PowerShell, Python and R as honorary members. In practice I might say SQL belongs here instead of under Prolog, but in theory of course SQL is like Prolog. Bourne shell might be the best representative, even if it's not the oldest.
AWK et al share characteristics from ALGOL and APL, but I feel they are very much their own thing. PowerShell is quite unique among modern languages.
At the same time, I don't agree with that it does not matter if one picks "Java, C#, C++, Python, or Ruby". If your goal is to do quick sort, then well, it does not.
If you want to use language for something (not only for its sake), then it makes a day and night difference. A person who wants to do 3D games and being shown Ruby or a person wanting to do exploratory data science and deep learning and being given Java are likely to get discouraged.
1) Advanced Programming Language Design by Raphael Finkel - A classic (late 90s) book comparing a whole smorgasbord of languages.
2) Design Concepts in Programming Languages by Franklyn Turbak et al. - A comprehensive (and big) book on PL design.
3) Concepts, Techniques and Models of Computer Programming by Peter Van Roy et al. - Shows how to organically add different programming paradigms to a simple core language.
Err
"Fortran: The world’s first programming language standard opened the door to modern computing"
One thing the article didn’t touch on was SmallTalk’s live visual environment. It’s not a normal source code / text language.
Do you think source code cannot be compiled and run from the command-line?
https://benchmarksgame-team.pages.debian.net/benchmarksgame/...
- Forth: you can use PFE,Gforth for ANS Forth requeriments. Or EForth if you reached high skills levels where the missing stuff can be just reimplemented.
EForth under Muxleq: https://github.com/howerj/muxleq I can provide a working config where a 90% of it would be valid across SF.
Starting Forth, ANS version: https://www.forth.com/starting-forth/
Thinking Forth, do this after finishing SF: https://thinking-forth.sourceforge.net/
Also, Forth Scientific Library. You can make it working with both GForth and PFE, just read the docs.
Full pack: https://www.taygeta.com/fsl/library/Library.tgz
Helping Forth code for GForth/PFE. If you put it under scilib/fs-util.fs, load it with:
s" scilib/fsu-util.fs" included
- Lisp. s9fes, it will compile under any nix/Mac/BSD out there, even with MinC.
S9fes: http://www.t3x.org/s9fes/
Pick the bleeding edge version, it will compile just fine.
For Windows users: MinC, install both EXE under Windows. First, mincexe, then buildtools*exe: https://minc.commandlinerevolution.nl/english/home.html
Then get 7zip to decompress the s9fes TGZ file, cd to that directory, and run 'make'.
Run ./s9 to get the prompt, or ./s9 file.scm where file.scm it's the source code.
In order to learn Scheme, there's are two newbie recommended books before "SICP".
Pick any, CACS, SS, it doesn't matter, both will guide you before SICP, the 'big' book on Scheme:
Simply Scheme https://people.eecs.berkeley.edu/~bh/pdf/
Simply.scm file, select from ';;; simply.scm version 3.13 (8/11/98)' to '(strings-are-numbers #t)' and save it as simply.scm
https://people.eecs.berkeley.edu/~bh/ssch27/appendix-simply....
Concrete Abstractions
Book:
https://www.d.umn.edu/~tcolburn/cs1581/ConcreteAbstractions....
The SCM files needed to be (load "foo.scm") ed in the code in order to do the exercises:
https://github.com/freezoo/scheme-concabs
If you are en Emacs user, just read the Elisp intro, it will work for a different Lisp family but with similar design.
Spot the differences:
Scheme (like s9):
(define (square x)
(* x x))
>(square 20)
400
(defun square (x)
(* x x))
>(square 20)
400
https://www.t3x.org/mlite/index.html
If you follow the instructions on compiling s9, mlite it's similar with MinC for Windows. If you are a Unix/Linux/Mac user, you already know how to do that.
You got the whole docs in the TGZ file, and the web.
- Agda, Idris, etc. are functional languages extended with complex types
- Isabelle, Lean, etc. are functional languages extended with complex types and unreadable interactive proofs
- Dafny etc. are imperative languages extended with theorems and hints
- ACL2 is a LISP with theorems and hints
Related, typeclasses are effectively logic programming on an otherwise functional/imperative language (like traits in Rust, mentioned in https://rustc-dev-guide.rust-lang.org/traits/chalk.html).
I think they are not. No amount of type level extensions can turn a regular functional language like Haskell into something suitable for theorem proving. Adding dependent types to Haskell, for example, doesn't suffice. To build a theorem prover you need to take away some capability (namely, the ability to do general recursion - the base language must be total and can't be Turing complete), not add new capabilities. In Haskell everything can be "undefined" which means that you can prove everything (even things that are supposed to be false).
There's some ways you can recover Turing completeness in theorem provers. You can use effects like in F* (non-termination can be an effect). You can separate terms that can be used in proofs (those must be total) from terms that can only be used in computations (those can be Turing complete), like in Lean. But still, you need the base terms to be total, your logic is done in the fragment that isn't Turing complete, everything else depends on it.
OTOH if you really want to emphasize "intended to express proofs" then surely Prolog has that covered, so Lean can be seen as half ML, half Prolog. From this view, the Curry-Howard correspondence is just an implementation detail about choosing a particular computational approach to logic.
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.
Incidentally, this is pretty much what Algol 60 was designed for and why to this day many academic papers use it or a closely related pseudocode.
I don't think these results are quite comparable because of slightly differing parallelism strategies; I'd expect the F# implementation of just spinning off threads to be more a little more performant than a Rayon parallel iterator, which presumably has some overhead. But that really just shows how hard it is to do a cross-language comparison; Rust and C++ can certainly be made faster than the F# code by carefully manipulating a ton of low-level OS concurrency primitives. This would arguably also be little misleading. Likewise Chez and Haskell have good C FFI; does that count? It's a tricky and highly qualitative analysis.
[1] FYI, one possible performance improvement with the Chez code is keeping the permutations in fxvectors and replace math operations with the fixnum-specific equivalent - this tells the compiler/interpreter that the data are guaranteed to be machine integers rather than bigints, so they aren't boxed/unboxed. I am not sure without running it myself, but there seems to be avoidable allocations in the Chez implementation. https://cisco.github.io/ChezScheme/csug/objects.html#./objec...
As for parallelism this is a primary concern of mine, and I tried multiple approaches for every language where there was a choice. I used my own work-stealing code only when it beat standard libraries. AI warned me I was in over my head, that writing such a library takes years of experience, but my use case (and my expected use cases in my research) is so uniform that simple can win, minimally touching the required bases such as permuting tasks to avoid false sharing.
I don't believe that the JIT languages (F# on top) do so well because of better parallelism. This is branch optimization. For this use case an AOT compiler with ample benchmark data to influence output should do better. That isn't a thing, and the argument seems to be that few use cases stay consistent. A JIT can adapt.
Given the sane C defaults that are applied by code extraction techniques, the delta really shouldn't be so great. But it's a common pitfall to torture one's own verified code in order to get it proven, and I'm also not sure how good of support there is for parallelism.
Lean 4 is the most interesting language on my list. I didn't reject it on price.
Would be very glad to read this.
In the meantime, I reproduce a part of an article by Steve Yegge:
---
What Computers Really Are
Another realization I had while reading the book is that just about every course I took in my CS degree was either invented by Johnny von Neumann, or it's building on his work in mostly unintelligent ways.
Where to start? Before von Neumann, the only electronic computing devices were calculators. He invented the modern computer, effectively simulating a Universal Turing Machine because he felt a sequential device would be cheaper and faster to manufacture than a parallel one. I'd say at least 80% of what we learned in our undergrad machine-architecture course was straight out of his first report on designing a programmable computer. It really hasn't changed much.
He created a sequential-instruction device with a fast calculation unit but limited memory and slow data transfer (known as the infamous "von Neumann bottleneck", as if he's somehow responsible for everyone else being too stupid in the past 60 years to come up with something better. In fact, Johnny was well on his way to coming up with a working parallel computer based on neuron-like cellular automata; he probably would have had one in production by 1965 if he hadn't tragically died of cancer in 1957, at age 54.)
Von Neumann knew well the limitations of his sequential computer, but needed to solve real problems with it, so he invented everything you'd need to do so: encoding machine instructions as numbers, fixed-point arithmetic, conditional branching, iteration and program flow control, subroutines, debugging and error checking (both hardware and software), algorithms for converting binary to decimal and back, and mathematical and logical systems for modelling problems so they could be solved (or approximated) on his computing machine.
-Steve Yegge, Math Every Day
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 says it works. Don't touch it." XD
Guy from another group used regex and his solution was 20x shorter than mine.
Plus up and coming (not quite production-ready IMO, but used in production anyways): ChatGPT and the like.
Of course, it’s debatable whether they are programming languages, but why wouldn’t they be. They aren’t deterministic, but I don’t think that is a must for a programming language, and they are used to let humans tell computers what to do.
https://www.t3x.org/amk/index.html
You can just get the code without buying the book, learn with Simply Scheme or any other book and apply the functions from the code, the solvers are really easy to understand.
[0] The Art of the Propagator (mit url down for the moment)
Found a working link to the paper about propagators.
The Art of the Propagator, Alexey Radul and Gerald Jay Sussman. https://groups.csail.mit.edu/mac/users/gjs/6.945/readings/ar... (PDF)
For those that never seen it, there are some old videos (taken from VHS) on the language site, https://selflanguage.org/
The article explains that:
> Smalltalk inherited the notion of a value and its type from earlier languages, and implemented the idea of a class. All objects had a class that gave their type, and the class was used to construct objects of that type. Self disposed of the notion of class and worked solely with objects. As this is a purer form, I have chosen Self as the type specimen for this ur-language.
The Unreal Tournament was the coolest thing I've ever seen. I think they shut it down the year after mine. (Now they have boring old regular AI like everyone else!)
I haven't found a good use for Prolog, though I haven't put much effort into it. I admit I was much more impressed by GOAL though, and I didn't realize until recently that you can replicate the whole thing in a more "ordinary" language (and that this gives many benefits). D'oh!
We almost won the tournament, we lost cause we overestimated the enemy.
We programmed our agents to assume that if they have our flag they're bringing it to their base, thus we sent all agents there to await their arrival.
And so they waited while our opponents ran in circles with our flag at the center or the map.
I tried many things in Prolog but ordinary languages often proved to be more suitable.
I recently vibe coded spellcheck.boneiru.online which is fully based on Prolog.
I realized a spellchecker is a perfect use case, since I basically need to check ortography which is a set of facts.
In terms of GOAL the text input would be the perception, and I then resolved whether the goal (correct text) is achievable.
The facts are all valid words in the language and the rules I got from an ortography book.
Even having the thinnest surface level understanding of the other ur-languages is so useful (and even more-so with assembly). I can't do anything useful with them, but it helps keep you from the "when all you have is a hammer, every problem looks like a nail" trap if you're at least aware of the existence of screwdrivers.
And regarding the screwdriver, I fully agree. Especially with AI I can use the right tool for any job, despite me not being able to use it directly.
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/mainframe/
Incredible how being monetary relevant keeps some languages going.
Also note how the beloved UNIX and C are from 1971 - 73, only about 10 younger than COBOL.
I mean, programming languages do not live; and they do not "die", per se, either. Just the usage may go down towards 0.
COBOL would then be close to extinction. I think it only has a few niche places in the USA and perhaps a very few more areas, but I don't think it will survive for many more decades to come, whereas I think C or python will be around in, say, three decades still.
> family with horizontal gene transfer
Well, you refer here to biology; viruses are the most famous for horizontal gene transfer, transposons and plasmids too. But I don't think these terms apply to software that well. Code does not magically "transfer" and work, often you have to adjust to a particular architecture - that was one key reason why C became so dynamic. In biology you basically just have DNA, if we ignore RNA viruses (but they all need a cell for their own propagation) 4 states per slot in dsDNA (A, T, C, G; here I exclude RNA, but RNA is in many ways just like DNA, see reverse transcriptase, also found in viruses). So you don't have to translate much at all; some organisms use different codons (mitochondrial DNA has a few different codon tables) but by and large what works in organism A, works in organism B too, if you just look to, say, wish to create a protein. That's why "genetic engineering" is so simple, in principle: it just works if you put genes into different organisms (again, some details may be different but e. g. UUU would could for phenylalanine in most organisms; UUU is the mRNA variant of course, in dsDNA it would be TTT). Also, there is little to no "planning" when horizontal gene transfer happens, whereas porting requires thinking by a human. I don't feel that analogy works well at all.
Code: https://github.com/norvig/paip-lisp
The EPUB looks broken in my machine, try the PDF: https://commons.wikimedia.org/wiki/File:Peter_Norvig._Paradi...
Altough Scheme and CL are different paths. CL's loop it's really, really complex and Scheme it's pretty much straightforward to understand. Any advanced CL user will have to implement Scheme's syntax (and an interpreter) as an exercise for PAIP. CL in CL... well, CL is too huge, T3X tried with Kilo Lisp 23 http://t3x.org/klisp/22/index.html and I doubt if anyone can even complete anything but the few starting chapters from Intro to Common Lisp with it.
Of Lem with SBCL+Quicklisp:
https://lem-project.github.io/usage/common_lisp/
Huge tip: if you use MCCLIM, install Ultralisp first and (ql-quickload 'mcclim) later: it will give you a big speed boost. Big, not as the ones from Phoronix. Actually big. From 'I can almost see redrawing on a really old ass netbook' to 'snappy as TCL/Tk' under SBCL.
As you can see, you don't need to pay thousands of dollars.
For Scheme, S9 just targets R4RS but as a start it's more than enough, and for SICP you can install Emacs+Geiser+chicken Scheme and from any Linux/BSD: distro command prompt, you run:
sudo chicken-install srfi-203
sudo chicken-install srfi-216
(import scheme)
(import (srfi 203))
(import (srfi 216))
csi yourfile.scm
chicken-csi yourfile.scm
M-x install RET geiser-chicken
if you are lazy. You can install the SICP book with
M-xpackage-install RET sicp
M-x info RET
M-x geiser
Yes.
However that is not the same as Python, which is 100% OOP, when using basic stuff like numbers, from Python language semantics those things are object, and there is the whole machinery in place even for basic stuff like addition.
And yes OOP is fuzzy from CS point of view there are multiple approaches and it doesn't get reduced to the way C++ and Java do it, just like FP and LP are fuzzy as well.
Some folks would swear if it isn't Haskell or Prolog, than it isn't FP or LP, when a CS book and programming language evolution will be more fuzzy.
Rust handles basic OOP, but not all of the characteristics seen in C++ or Java:
"Within each project, a set of changes you make to class descriptions is maintained. … Using a browser view of this set of changes, you can find out what you have been doing. Also, you can use the set of changes to create an external file containing descriptions of the modifications you have made to the system so that you can share your work with other users."
1984 "Smalltalk-80 The Interactive Programming Environment" page 46
~
1984 "Smalltalk-80 The Interactive Programming Environment" page 500
(define (heap-permute! perm j callback)
(with-context 'fixnum ;; same trick works with 'flonum for 64-bit floats
(let ([n (length perm)]) ;; actually fxvector-length
(let generate ([k (- n 1)]) ;; actually fx-
(if (< k j) ;; fx<
(callback perm)
(begin
(generate (- k 1)) ;; fx-
(do ([i j (+ i 1)]) ;; fx+
((>= i k)) ;; fx>=
(if (even? (- j k)) ;; fxeven?, fx-
(swap perm j k)
(swap perm i k))
(generate (- k 1)))))))) ;; fx-
And BTW I misspoke earlier, of course Chez is AOT rather than JIT. From one approach it's sort of a hybrid: really fast on-the-fly AOT kinda looks like JIT, tongue-in-cheek you could say "NoT compilation" (nick-of-time). But proper JIT of course has huge advantages. If you reeaaaallly wanted to sabotage readability, Chez makes it easy to invoke the compiler at runtime, so along with the C FFI I think you could hack together some sort of JIT. But wow, what a mess that would be! You'd better be getting a PhD thesis out of it :) And if the performance is that critical you'd be much better off with F#.
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++.
Is there anything to be gained from rewriting it in Rust? Five years ago would there have been anything to be gained from rewriting it in Haskell? Ten years ago would there have been anything to be gained from rewriting it in Ruby? Fifteen years ago would there have been anything to gain from rewriting it in Clojure? Twenty years ago would there have been anything to gain from rewriting it in Java?
And so on, all the way back.
HTML is not a programming language, it's a markup language - it's in the name, and it's the way it is used (it's not used to describe any kind of computation, it's straight up data that is parsed by algorithms).
Neither is PowerPoint, or game of life a programming language even though both are Turing complete.
Total languages omit partiality and non-termination from Turing completeness.
Partiality is IMO irrelevant when it comes to computability. Any partial function (that is, one whose range is not defined over its whole domain) can be expressed as a total function by either constricting the domain or expanding the range. For example, a "pop" operation on a stack is not defined for an empty stack. You can just loop forever if pop() is called on an empty stack. Alternatively, you can require that pop() is given a witness that the stack is non-empty, or you can require that pop() returns either the top-most element of the stack or a value that indicates the stack was empty. Both let you compute the same set of things as the former.
Non-termination is required to be Turing complete, because being Turing complete means being able to compute functions that one cannot reasonably expect to complete before the heat death of the universe. In _practice_ every function terminates when the computing process dies due to some external factor: process runs out of memory ("real" Turing machines have infinite memory!), user runs out of patience, machine runs out of power, universe runs out of stars, that sort of thing, so _in practice_ doing 2^64 iterations before giving up will generally* give you the same outcome as doing an unbounded number of iterations: it'll either terminate, or the process will be killed (here, due to reaching its iteration limit).
On the flip side, giving up non-termination and partiality only gives you increased correctness. If there's one thing we've definitely established in computing, it's that we will readily discard correctness to gain a little extra productivity. Why make a developer implement code to handle reaching an iteration limit when you can just make the user get sick of waiting and kill your app?
* 18 quintillion is a very large number. Have a try. The most trivial recursive function, on my M4 Mac, when convincing clang to be smart enough to turn it into a loop but dumb enough not to elide it altogether, would take a bit shy of 600 years to complete if iterating ULONG_MAX times; I didn't wait for that, if I'm honest with you, I ran it with a much smaller iteration count and multiplied it out.
Idris absolutely is a general-purpose functional language in the ML family. It is Haskell, but boosted with dependent types.
While reading TFA I thought the theorem stuff deserved its own category, but I guess it's a specialization within an ur-family (several), rather than its own family?
It definitely sounds like it deserves its own category of programming language, though. The same way Lojban has ancestry in many natural languages but is very much doing its own thing.
But I think that the theorem prover that excels most at regular code is actually Lean. The reason I think that is because Lean has a growing community, or at least is growing much faster than other similar languages, and for regular code you really need a healthy ecosystem of libraries and stuff.
Anyway here an article about Lean as a general purpose language https://kirancodes.me/posts/log-ocaml-to-lean.html
> You can separate terms that can be used in proofs (those must be total) from terms that can only be used in computations (those can be Turing complete), like in Lean
What I meant is that the part of Idris that lets people prove theorems is the non-total part
But, I think you are right. Haskell could go there by adding a keyword to mark total functions, rather than marking nontotal functions like Idris does. It's otherwise very similar languages
Despite what the fanatical constructivists (as opposed to the ones who simply think it's pragmatically nice) seem to want us to think, it turns out that you can prove interesting things with LEM (AKA call/cc) and classical logic.
Yes haskell's `bottom` breaks soundness, but that doesn't mean you need to take away some capability from the language. You just need to extend the language with a totality checker for the new proof fragment.
Does not sound that appealing to me. Sounds like little consistency and having to learn a new language for every project.