đŸ Archived View for paritybit.ca âș arboretum âș programming âș programming-philosophy.gmi captured on 2023-01-29 at 02:58:06. Gemini links have been rewritten to link to archived content
-=-=-=-=-=-=-
One does not have to be an expert or engineer to program in a non-professional setting. Programming should be open and available to all. In the same way anyone can pick up a hammer and hang a painting or put together furniture, one should be able to slap together a temperature monitor or work with data with ease. Some great examples of this are Excel and visual programming systems.
I don't like StackOverflow. It's not the best. It's not where I want us to go. 'Cause it's not knowledge, it's just information. The problem is that we have these systems that are so complex that no one could conceivably understand all of them. No one could possibly understand all of the systems that some professional engineer works with in, for example, AWS. So what we have to do is get really good in the whole industry about building tools for partial understanding so that if you know a little bit about one thing you can learn a little bit about another thing. StackOverflow is really good about that. You can get a lot of partial understanding about a lot of different things. Which is good in some sense, but I think the fact that we're not using systems that we can understand deeply is a fundamental problem.
We've gone so far into complexity that no person can understand the whole system or some programming environment top to bottom. Whereas with Forth you can understand the entire programming environment from machine to source code. I can tell you where all the bits and bytes go, and all of the operations and all of the memory access. That is not even remotely possible even with a language like C these days and I think what's unfortunate is that we're moving so far away from that, that people don't understand computers. The future we're headed to is one in which you don't even understand them at the level that we do now because you just have a machine that you feed some input into and it gives you something that you don't exactly understand but maybe kinda fits the problem that you're doing, and it's probably really inefficient, and maybe it's correct? I don't know. Because the machine spit it out. I think that's not where we should be going as an industry.
We should be going more towards understanding systems deeply, and building things correctly as opposed to offloading knowledge onto some other machine that does more stuff for us. People talk about these as if it's this magic system that is like SkyNet that just thinks for you, but that's not how these systems work. You interact with these AI, and they do somethingâand they can do something that's really impressiveâbut it doesn't give you knowledge, it just gives you information. There was something that Facebook released where you just type in something like "give me an encyclopedia article about Bernie Sanders". And you read it. And all but one or two things this machine spit out was wrong. The system doesn't give you knowledge. It's not that these systems are useless, they just don't actually understand the domain and you still need human beings that have abstract understanding of a system or a field in order to create and disseminate knowledge. What I worry is that those institutions are not being invested in. Things like libraries, Wikipedia, universitiesâthese institutions are where knowledge happens and we undervalue and de-value that kind of knowledge work in favour of crazy, flashy AI things.
That's why you have to learn Forth. That's why you have to suffer through the bits and the bytes. You have to suffer because suffering will make you a better person. It will make you a better programmer to suffer. But it's a specific kind of suffering, it's not toil. Toil is how most people do engineering work. Toil is like: "Ugh, why is this code so bad. What does this system even do?" and that's so horrible. To deal with toil as an engineer is miserable but that's what most of Software Engineering is. And so we just proliferate toil. That's how we do engineering. And then we say we'll just hire 5,000 engineers and they'll all toil. Whereas doing something like Forth is a different kind of suffering. It's the suffering of developing an understanding that you didn't have before. It's the suffering of really mastering something really deeply which, I think, unfortunately, is something we do less and less as engineers.
So Iâve been meaning to write a post about my Perl âhot takesâ so to speak, or at least what I like about the language and why I unironically defend it
I first got into Perl back in 2015, after having used C, PHP, JavaScript, and Shell Scripting. I started playing around with different languages to decide on one to learn and decided to make small programs in a few languages to compare how they felt. I tried Go, Python, Ruby, and Perl and out of all of them Perl felt the best and I found myself wanting to do more and more with it
Sure, the semi colon made it syntactically similar to the languages I already knew but it felt like it was super general purpose and in a very expressive way that actively stimulated my mind
I think one of the best ways to sum this up comes in Perlâs motto itself, âthereâs more than one way to do itâ. This is often contrasted with Pythonâs âthereâs only one way to do itâ and I felt this very heavily. While Iâm sure the consistency and standard structure of Python makes it appealing for big projects, I was just doing my own thing and learning Perl felt more like learning to paint or writing a poem. I could express myself and do things in the ways that felt good for my brain
It just felt incredibly expressive and I loved how it flowed, how I could very easily rearrange statements and subroutines, and have as much as I wanted on a single line (or not) to suit my own style. Perl is often insulted as a âwrite onlyâ language but I feel like this is part of the beauty of Perl, in that itâs let the coder put their own personality in. Much like handwriting, youâre using the same words, and some are easier to read than others, but ultimately itâs part of who that person is, a mark left on the world
I think when people criticize Perl they often see it as âitâs either good at making big complex software projects or itâs badâ when it is at its core an expressive hacker language thatâs easy to learn and yet youâll still be learning new tricks a decade later. You can use it to quickly write little automation tools or scripts where writing it in Bash would be pain, but you can go bigger with it too. It has a big module repository (and was one of the first to pioneer the idea I believe) which means you can very quickly build little tools and projects in your own way
I think people get far too hung up on what they see as a very professional and standard set of tools and that the freedom Perl gives is bad for maintainability, but I think that isnât and shouldnât be the whole picture, I think there should be room for a fun expressive language that lets you add a piece of yourself to everything you write, your own quirks, your own style. You can actually have a lot of fun and learn a lot by reworking a single statement of code in many ways, and in fact, thereâs the âJust Another Perl Hackerâ thing where people try to find their own way to write code that simply prints out that string, and there are so many creative and interesting examples including one where the source code is ascii art of a camel
Iâm not saying you should start doing everything in Perl or adopt it as your main language but that you should give it a chance and at least not cast it away as a mistake of the past. I think it very much embodies the late 80s and 90s hacker culture in its very makeup and really does lean into programming as an art not just a science
If you asked 10 artists to paint a horse youâd get 10 different styles, and likewise, the âwrite onlyâ criticism of Perl is that if you asked 10 Perl programmers for a basic program, youâd get 10 different sets of source code but I think itâs honestly nice for that to exist, a project should be an endeavour of passion and creativity, and being able to do that in your own unique way is a good thing imo
https://akko.disqordia.space/notice/ANwg0JFqsFcCFehsvI
Languages like C and Scheme are very barebones. They contain very basic syntax and very few features yet are complete programming languages. I find myself increasingly drawn to these languages over languages such as Python and C++ specifically because of this simplicity. Although these more "modern" languages reduce the work needed to build a robust and correct program, they also feel constraining in a way.
When I program in Python, it feels like I'm building a house out of pre-defined pieces that I'm treating as black boxes. When I'm programming in C, it feels like I'm building a house out of pieces that I'm sculpting and tailoring to the problem I'm trying to solve. Where in Python I use the built-in data structures, in C I craft my own. Where in Python I might throw together a prototype to better understand the problem domain, in C I carefully stitch together a final product that tackles the problem using only what is needed, eschewing any other cruft or considerations. In C, I'm not worried about making generalizable data structures and have no need for functions like `exec()`.