↘↘↘↘↘↘↙↙↙↙↙↙
Checkout my Biography.
↗↗↗↗↗↗↖↖↖↖↖↖
Johannes C. Mayer
Karma: 821
The Model-View-Controller architecture is very powerful. It allows us to separate concerns.
For example, if we want to implement an algorithm, we can write down only the data structures and algorithms that are used.
We might want to visualize the steps that the algorithm is performing, but this can be separated from the actual running of the algorithm.
If the algorithm is interactive, then instead of putting the interaction logic in the algorithm, which could be thought of as the rules of the world, we instead implement functionality that directly changes the underlying data that the original algorithm is working on. These could be parameters to the original algorithm, which would modify the runtime behavior (e.g. we could change the maximum search depth for BFS). It could also change the current data the algorithm is working on (e.g. in quicksort we could change the pivot, or smaller_than_list just before they are set). The distinction is somewhat arbitrary. If we were to step through some Python code with a debugger, we could just set any variables in the program.
Usually, people think of something much “narrower” when they think about the Model-View-Controller-Architecture.
We could also do the same for a mathematical description. We can write down some mathematically well-defined thing and then separately think about how we can visualize this thing. And then again, separately, we can think about how would we interact with this thing.
I like this a lot. You are programming for the human brain now.
It also seems nice that can implement each step in this program in executable code, and then you don’t need to perform that step manually. You might even write little helper programs to perform the tasks, which can then later be used if you decide to automate the script more.
It also seems useful for developing an algorithm. Often I might want to understand what my brain is doing and have an algorithm that emulates what my brain is doing.
Maybe this method can be used to write down a very high-level description of the steps that I think my brain is doing and then see whether me now following that procedure blindly leads to the correct result. If you get the correct result, you can then try to fill in more details, automating each individual step a bit more, and then checking if you still get the same result, and so on.
How to write Pseudocode and why you should
Whiteboard Program Traceing: Debug a Program Before you have the Code
I think this post would be much more effective in achieving its goal if it would provide alternatives.
What are the advantages of posting your research ideas on LessWrong? Are there other ways in which you can get these advantages? Are there maybe even alternatives that give you more of the thing you want?
I expect telling people about these alternatives (if they exist) would make them more likely to make use of them.
One of the main things I think people can get by publishing their research is to get feedback. But you could also search for people who are interested in what you are working on. Then you can send your write-ups only to these people.
Also seeing people engage with things that you write is very motivating.
These are just some rough examples as I don’t think I have very good models about what you can get out of LessWrong and how to get the same benefits in different ways.
[Question] What are the Activities that make up your Research Process?
[Question] How do you Select the Right Research Acitivity in the Right Moment?
Seems pretty good to me to have this in a video call to me. The main reason why don’t immediately try this out is that I would need to write a program to do this.
Detangle Communicative Writing and Research
One reason why I never finish any blog post is probably because I’m just immediately starting to write it. I think it is better to first build a very good understanding of whatever I’m trying to understand. Only when I’m sure I have understood do I start to create a very narrowly scoped writeup?
Doing this has two advantages. First, it speeds up the research process, because writing down all your thoughts is slow.
Second, it speeds up the writing of the final document. You are not confused about the thing, and you can focus on what is the best way to communicate it. This reduces how much editing you need to do. You also scope yourself by only writing up the most important things.
See also here more concrete steps on how to do this.
In principle, you could use Whisper or any other ASR system with high accuracy to enforce something like this during a live conversation.
Be Confident in your Processes
I thought a lot about what kinds of things make sense for me to do to solve AI alignment. That did not make me confident that any particular narrow idea that I have will eventually lead to something important.
Rather, I’m confident that executing my research process will over time lead to something good. The research process is:
Take some vague intuitions
Iteratively unroll them into something concrete
Update my models based on new observations I make during this overall process.
I think being confident, i.e. not feeling hopeless in doing anything, is important. The important takeaway here is that you don’t need to be confident in any particular idea that you come up with. Instead, you can be confident in the broader picture of what you are doing, i.e. your processes.
The best way to become confident in this way is to just work a bunch and then reflect back. It is very likely that you will be able to see how improved. And probably you will have had a few successes.
Ok, I was confused before. I think Homoiconicity is sort of several things. Here are some examples:
In basically any programming language L, you can have program A, that can write a file containing a valid L source code that is then run by A.
In some sense, python is homoiconic, because you can have a string and then exec it. Before you exec (or in between execs) you can manipulate the string with normal string manipulation.
In R you have the quote operator which allows you to take in code and return and object that represents this code, that can be manipulated.
In Lisp when you write an S-expression, the same S-expression can be interpreted as a program or a list. It is actually always a (possibly nested) list. If we interpret the list as a program, we say that the first element in the list is the symbol of the function, and the remaining entries in the list are the arguments to the function.
Although I can’t put my finger on it exactly, to me it feels like the homoiconicity is increasing in further down examples in the list.
The basic idea though seems to always be that we have a program that can manipulate the representation of another program. This is actually more general than homoiconicity, as we could have a Python program manipulating Haskell code for example. It seems that the further we go down the list, the easier it gets to do this kind of program manipulation.
I am also not sure how useful it is, but I would be very careful with saying that R programmers not using it is strong evidence that it is not that useful. Basically, that was a bit the point I wanted to make with the original comment. Homoiconicity might be hard to learn and use compared to learning a for loop in python. That might be the reason that people don’t learn it. Because they don’t understand how it could be useful. Probably actually most R users did not even hear about homoiconicity. And if they would they would ask “Well I don’t know how this is useful”. But again that does not mean that it is not useful.
Probably many people at least vaguely know the concept of a pure function. But probably most don’t actually use it in situations where it would be advantageous to use pure functions because they can’t identify these situations.
Probably they don’t even understand basic arguments, because they’ve never heard them, of why one would care about making functions pure. With your line of argument, we would now be able to conclude that pure functions are clearly not very useful in practice. Which I think is, at minimum, an overstatement. Clearly, they can be useful. My current model says that they are actually very useful.
[Edit:] Also R is not homoiconic lol. At least not in a strong sense like lisp. At least what this guy on github says. Also, I would guess this is correct from remembering how R looks, and looking at a few code samples now. In LISP your program is a bunch of lists. In R not. What is the data structure instance that is equivalent to this expression:
%sumx2y2% <- function(e1, e2) {e1 ^ 2 + e2 ^ 2}?
The Science Algorithm—AISC 2024 Final Presentation
Adopted.
[Concept Dependency] Edge Regular Lattice Graph
[Concept Dependency] Concept Dependency Posts
A few adjacent thoughts:
Haskell is powerful in the sense that when your program compiles, you get the program that you actually want a much higher probability compared to most other languages. Many stupid mistakes that are runtime errors in other languages are now compile-time errors. Why is almost nobody using Haskell?
Why is there basically no widely used homoiconic language, i.e. a language in which you can use the language itself directly to manipulate programs written in the language.
Here we have some technologies that are basically ready to use (Haskell or Clojure), but people decide to mostly not use them. And with people, I mean professional programmers and companions who make software.
Why did nobody invent Rust earlier, by which I mean a system-level programming language that prevents you from making really dumb mistakes by having the computer check whether you made them?
Why did it take like 40 years to get a latex replacement, even though latex is terrible in very obvious ways?
These things have in common that there is a big engineering challenge. It feels like maybe this explains it, together with that people who would benefit from these technologies where in the position that the cost of creating them would have exceeded the benefit that they would expect from them.
For Haskell and Clojure we can also consider this point. Certainly, these two technologies have their flaws and could be improved. But then again we would have a massive engineering challenge.
Research Writing Workflow: First figure stuff out
Do research and first figure stuff out, until you feel like you are not confused anymore.
Explain it to a person, or a camera, or ideally to a person and a camera.
If there are any hiccups expand your understanding.
Ideally, as the last step, explain it to somebody whom you have not ever explained it to.
Only once you made a presentation without hiccups you are ready to write post.
If you have a recording this is useful as a starting point.
Mathematical descriptions are powerful because they can be very terse. You can only specify the properties of a system and still get a well-defined system.
This is in contrast to writing algorithms and data structures where you need to get concrete implementations of the algorithms and data structures to get a full description.