#DebuggingFeb Entry #1: Base to codon #code #debug #story
By Armani Willis, github.com/awillis4

#DebuggingFeb Entry #1: Base to codon #code #debug #story By Armani Willis, github.com/awillis4

#DebuggingFeb #Entry #Debug #Article

Table of contents

No heading

No headings in the article.

It is now 3pm in the afternoon. It was 12pm noon when you started typing. You look deep onto the screen staring. Sweat is dripping over your eyes. What could you be seeing? What could you be thinking? That movie runs through your head again. It is the same movie that has been running through your head since this project was first imagined. It is the sequence of events of successful project completion. Every line of code in every file working in perfect sequence, with perfect timing, to produce results, like machines in a factory.

But there is a problem with this movie. When comes the time to press the button, which looks like a green triangle, the whole system comes crashing. Why? Is this not the sequence which logically follows? Your experience says yes, but your compiler says no. You look at the verbose messages that appear in the compiler window.

at processing.serial.Serial.<init>(Unknown Source) at processing.serial.Serial.<init>(Unknown Source) at sketch_211210a.draw(sketch_211210a.java:85) at processing.core.PApplet.handleDraw(PApplet.java:2475) at processing.awt.PSurfaceAWT$12.callDraw(PSurfaceAWT.java:1547) at processing.core.PSurfaceNone$AnimationThread.run(PSurfaceNone.java:313)java.lang.RuntimeException: Error opening serial port /dev/tty.wchusbserial620: Port busyjava.lang.RuntimeException: Error opening serial port /dev/tty.wchusbserial620: Port busy

This tiny message block is the culmination of your work up to this point. This is what will appear as you try new code over and over and over and over again. Give up. It dosnt matter. Throw in the script. Whats the worst that will happen. It will never work. You will never find the answer. Why do you persist? The movie crashes and fails over and over and over inside your head, and on screen. But why is there no solution? There must be a solution.

This is what my head was thinking, as I tried to generate my new program. Deceptively simple, the same thing kept happening for hours. I was used to this by now. These were the kinds of things that happened every single time I tried to program. Why did it not work? What could it be? What does the compiler say? Why is the compiler saying that? Which lines of code is it? The answer is probably simple. I had gone through so many simple solutions, that I decided to comment out the parts that did not work, instead of erasing them. That way I could keep track of what I tried before … and why it did not work.

I comb the docs of oracle and processing, trying and knocking out solution after solution. By then I did not expect it to work, I was trying it to see whether it would work. When I finally stumble upon the solution, a way to do the same thing that I was trying to do since the beginning, but in a way that the compiler would accept, I had reformed the entire body of the code at least 3 times. I was not as amused or relieved that I finally got it to work than I thought I would be. I did not even know and could not determine why this was the solution and not anything else. Great, I got this file to actually work. … Now do the same thing with the other files in the program!

Trial and error is part of the daily struggle of anyone trying to design something. At least in programming, there is nothing to physically build most of the time. In designing something that must be physically built, the architect must be able to use known patterns to predict whether what was created on file would work in real life, even before the building starts. Implementation is the same way, as code that works by itself in its own environment fails to communicate with the other compilers.

You can find this and some of my other works in the link below. They were working programs when I uploaded them. I make a point not to upload something that did not work. They may not work now because architectures of programming languages change over the years. This is why I recommend introducing new features as parallel solutions, or as parallely implementable packages. Otherwise every new change made will fundamentally change the nature of the language, and give programmers the headaches they had with the now finished projects when they started.

#DebuggingFeb #Entry #Debug #Article

https://github.com/awillis4/Audio-base-codon

#please #like #share #subscribe #follow #donate :)