The graphical dataflow languages that are popular for music and audio programming (thinking Pure Data, Max/MSP, Reaktor etc) do this in a way that makes the value of "namelessness" a bit more clear. When you connect the output of one unit to the input of another unit, there's no need to name that linkage, but it's still perfectly clear what's flowing over it. I really enjoy trying to think through programming problem…
Have you tried visual programming, e.g. Labview and the like?
Tacit programming
81–90 of 95 posts
Re: Tacit programming
#82Earlier quoted context omitted.
I've been using tacit programming intensively to the extent I get rid of most variables. I use both syntactic threading macros and functional combinators to achieve this. It is a double-edged sword in that it can make code as ugly as the original code it is trying to improve upon, but working without variables isn't that difficult nor does it lead me to intense clusterfucks. Composing lambdas contribute to this a lot…
Could you share the code for some of the custom threading macros you created? Looks very useful.
Sometimes, the repetition of encounters is just as meaningful as the people we meet.
https://en.wikipedia.org/wiki/Small-world_network https://www.quantamagazine.org/new-proof-shows-that-expander... https://telecom-paris.hal.science/hal-03814119/document
Re: Tacit programming
#83Absolutely every single time when I use functional programming, I store my intermediary calls in a variable, specifically because naming that variable forces me to explain what that intermediary result should be. If the intermediary result makes no sense, and only the function composition makes sense, I'll create a new well named function that does the chaining, even if it's single use. This is literally the only way…
Doing this for every intermediate result badly harms readability. Consider McIlroy's famous 1-liner: tr -cs A-Za-z '\n' | tr A-Z a-z | sort | uniq -c | sort -rn | sed ${1}q Adding intermediate variables like "newline_delimited", "lowercased", "sorted", etc... is just pure noise. It's the equivalent of a newb programmer putting a comment over each line of simple code explaining in English what that code does, despite…
I don't fully agree. Even when each step is fully descriptive it greatly helps to see the intermediate result, and names can be used for that as well. It is true that some intermediate names are not required, partly because some steps are best understandable in conjuction with neighboring steps (e.g. `sort | uniq -c` is a very common idiom and splitting them would do much harm than good), but a healthy dose of names would help in general.
I would say that there are three major steps in this particular pipeline: normalization (`tr -cs A-Za-z '\n' | tr A-Z a-z`), frequency calculation (`sort | uniq -c`), and extraction of first ${1} largest entries (`sort -rn | sed ${1}q`). So it is reasonable to have two additional names between them. Or you can name each step with a function so that you don't need intermediate results to understand that (`norm-words | calc-freqs | keep-largest ${1}`).
> It's the equivalent of a newb programmer putting a comment over each line of simple code explaining in English what that code does, despite it being clear already.
That is more about repeating functional parts without describing any intention. Comments about intents and clarifications are absolutely fine. For example:
counter += 1; // increment the counter by one (bad)
counter += 1; // increment the global counter, don't need synchronization here (better)
g_counter.incr_without_sync(); // (even better, but not always possible)Re: Tacit programming
#84I love the concept of point-free programming - write your function by simply concatenating the transformations you want. I just hate reading the resulting code written by others. What information is expected to come in, and exactly what data passes from one step to the next, and in what position? Data type signatures only go so far. Point-free means you have all that wiring in your head, without assistance from the n…
Just like there is "decision fatigue" [1] I believe there is "naming fatigue", and naming are one of the three great problems of computing, as everyone knows. I'd say that at least point-free prevents naming fatigue, but for the result to be nice to the reader, the naming and factorization is much more important than with explicit code, which has sort of much more "safeties". On the specific question you ask, let's h…
ChatGPT is quite good at coming up with names.
It can map a description of a thing to a name. And the descriptions can vary between developers and probably still end up with the same name. So if everyone relies on its naming-prowess then everyone ends up naming things consistently.
Aside: I wonder if it can name parameters from tacit-style...
Write this in non-tacit style:
sort input.txt | uniq -c | sort -rn > output.txt
sort input.txt > sorted.txt
uniq -c sorted.txt > counted.txt
sort -rn counted.txt > output.txt
Seems it can. Look how the output of `uniq` was `counted`.Maybe we should just let ChatGPT name everything.
Interesting to think what programming is you no longer have to name things. A lot of programming is grouping code and coming up with names for the groups.
What if we didn't worry about grouping or naming, and just dealt with the data, and let chatgpt provide names on-the-fly.
Functions could even be replaced by descriptions of the actions.
I wonder if you could let an LLM evolve a graphical operating system from just the hardware definition.
We went through ~70 years of trial and error for programming languages going from low-level to progressively higher-level, and kept all the baggage along the way.
How would an AI go about this...with all the knowledge of today? How would it reason about each step in evolving a language.
I'm guessing it would probably be a LISP :D
Re: Tacit programming
#85Earlier quoted context omitted.
tacit means a definition doesn't name it's arguments, not that it isn't applied to arguments. the word tacit means implied, so arguments are implicity worked upon, instead of explicitly. tacit doesn't mean functions are nullary.
Yes, but that is the same as not applying a function to arguments on the left hand side of an equation, but still doing so on the right hand side. The question is, what is the point of not doing that on the left hand side, if you then go and still do it on the right hand side? Let me say it again: It's pointless.
Re: Tacit programming
#86Earlier quoted context omitted.
Yes, but that is the same as not applying a function to arguments on the left hand side of an equation, but still doing so on the right hand side. The question is, what is the point of not doing that on the left hand side, if you then go and still do it on the right hand side? Let me say it again: It's pointless.
If you tried to understand as hard as you're trying to argue, you wouldn't be having this argument.
From the Wikipedia article:
> Tacit programming is of theoretical interest, because the strict use of composition results in programs that are well adapted for equational reasoning.
Now this is bullshit. See my explanation, as equations are symmetric, and you can swap left and right hand side.
Maybe you should try to understand harder.
Re: Tacit programming
#87Earlier quoted context omitted.
If you tried to understand as hard as you're trying to argue, you wouldn't be having this argument.
There is nothing to understand here. As I said, it's pointless. From the Wikipedia article: > Tacit programming is of theoretical interest, because the strict use of composition results in programs that are well adapted for equational reasoning. Now this is bullshit. See my explanation, as equations are symmetric, and you can swap left and right hand side. Maybe you should try to understand harder.
It has little to do with the idea of LeftSide = RightSide. In fact you don’t even need an “equation” in that sense, or any equality sign, to do equational reasoning.
Equational reasoning is when a program is evaluated (ie.: like when you simplify or factorize an equation in maths) by using substitution (or rewriting) rules: https://en.wikipedia.org/wiki/Rewriting
Re: Tacit programming
#88Earlier quoted context omitted.
There is nothing to understand here. As I said, it's pointless. From the Wikipedia article: > Tacit programming is of theoretical interest, because the strict use of composition results in programs that are well adapted for equational reasoning. Now this is bullshit. See my explanation, as equations are symmetric, and you can swap left and right hand side. Maybe you should try to understand harder.
No, you’re just failing to understand what “equational reasoning” means. It has little to do with the idea of LeftSide = RightSide. In fact you don’t even need an “equation” in that sense, or any equality sign, to do equational reasoning. Equational reasoning is when a program is evaluated (ie.: like when you simplify or factorize an equation in maths) by using substitution (or rewriting) rules: https://en.wikipedia.…
I recommend this book for you, you should read it. I have: https://www.cambridge.org/core/books/term-rewriting-and-all-...
Re: Tacit programming
#89My favorite resource on Tacit programming is Point Free or Die: https://www.youtube.com/watch?v=seVSlKazsNk
I didn't agree on it. It's like stating the principle of procreation and someone quoting a pornstar, and now we name it James Deen. Hope this helps, mrn.
Re: Tacit programming
#90Earlier quoted context omitted.
No, you’re just failing to understand what “equational reasoning” means. It has little to do with the idea of LeftSide = RightSide. In fact you don’t even need an “equation” in that sense, or any equality sign, to do equational reasoning. Equational reasoning is when a program is evaluated (ie.: like when you simplify or factorize an equation in maths) by using substitution (or rewriting) rules: https://en.wikipedia.…
This is becoming funny. I recommend this book for you, you should read it. I have: https://www.cambridge.org/core/books/term-rewriting-and-all-...