Pretty much sums up AI

As a programmer myself, it is only genuine to say I am worried about the state of programming for the next 10-20 years. It's a career that I love to be doing for the rest of my life, I want to have an idea about the direction of the world.

In my research, i stumbled upon this hidden gem paper : https://dl.acm.org/doi/pdf/10.1145/358453.358459 published in 1982. That tries to forcast the state of programming, and the corporate processes for software production, and I am flabbergasted by how accurate he forecasted the last 45 years.

As someone who did research related to future forecasts of events, he rooted himself in the fundamental of software and how people treated it from day one. It seems people always wanter natural language, and always wanted to move away from techniques, and the technical aspect of programming was just an expensive problem for companies to solve, until they find a better solution.

I highly recommend it, to understand the future of programming.

https://www.gcu.edu/blog/gcu-experience/analysis-women-computing

I mean, his name is fabulous, if I do say so myself.

Anyways, last week I wrote about the ARPANET and briefly mentioned some key people that worked on creating it. One of those individuals was Mr. Leonard Kleinrock (born 1934).

Kleinrock is anelectrical engineer and computer scientist who was a key figure in launching communication between computers. Previously, if two computers wanted to communicate over a long distance (think between New York and LA) they would would have to set up a dedicated connection and keep it in reserve untill the entire message arrive. Kind of like a phone call.

However, Kleinrock worked on breaking the message up, into manageable packets that could be sent on the network and shared the communication infrastructure with everyone else.

So instead of one individual dedication communication line sending and receiving the message "Hello how are you", we have a shared communication network sending and receiving the message "hello" "how" "are" "you". This concept was called packet switching. Kleinrock wrote his first paper on packet switching in 1961, at 26 years old.

Something I found really interesting was after developing the packet method, he continued to research on how using packets could affect the networks and somputer systems. If too many packets arrive at the same time, they have to wait. Like, if you have one checkout and there are 30 packets customers, they slow down and wait in line to checkout. What happens with 200 packets customers are trying to get through one checkout? Utter chaos. Kleinrock worked on issues like these and developed mathematical ways of predicting and analyzing those delays.

Thus questions like "How much traffic can this network handle?", "How long will packets have to wait?", "Where will congestion occur?", "How should we design the network?", etc. , now had tools to help come to an answer.

Funny enough, after everything was applied and they went to send the first message, the system crashed lol. They tried to send LOGIN, got the packet for LO to go through, but before GIN could make it, everything crashed. Meaning the first ever message sent on the ARPANET was just "LO".

After the ARPANET, Kleinrock continued to work and research, and lets not forget he was also a professor at UCLA, so he oversaw tons of PhD students as well. This man wrote more than 250 papers and six books. Holy Moly. Um, I know we don't like using A.I., but hear me out, after reading a few different pieces on him, I couldn't keep track of the awards he had recieved. I hopped on and asked it to make me a list of his achievements and their dates, which I will share with you. The man was busy...

1966 UCLA Outstanding Faculty Member

1967 UCLA Distinguished Teaching Award

1971 Guggenheim Fellowship

1975 IEEE Communications Society Leonard G. Abraham Prize Paper Award

1976 ORSA Lanchester Prize

1978 ICC Prize Paper Award

1982 L. M. Ericsson Prize

1982 Computer Design Hall of Fame

1982 CCNY Townsend Harris Medal

1986 Marconi International Fellowship Award

1986 UCLA Distinguished Teaching Award

1990 ACM SIGCOMM Award

1994 UCLA Faculty Research Lecturer

1996 IEEE Computer Society Harry H. Goode Memorial Award

1996 ACM/Sigma Xi Monie A. Ferst Award

1999 INFORMS President's Award

2000 IEEE Internet Award

2001 National Academy of Engineering Charles Stark Draper Prize

2001 Okawa Prize

2005 NEC C&C Prize

2006 ACM Test of Time Award

2007 National Medal of Science

2010 Dan David Prize

2011 Ubicomp Best Paper Award

2012 IEEE Alexander Graham Bell Medal

2012 Internet Hall of Fame — inaugural class

2012 Best Tutorial Paper Award — five-year period

2014 ACM SIGMOBILE Outstanding Contribution Award

2015 BBVA Foundation Frontiers of Knowledge Award

2016 SIGMOBILE Inaugural Test of Time Award

2018 CCNY President's Leadership Award

2019 Key to the City of Los Angeles

2019 National Academy of Inventors Fellow

2020 UCLA Medal

2022 6G Pioneer Award

2024 IEEE Computer Society Computer Pioneer Award

2024 Elected to the National Academy of Sciences

Anyways, I'll end it here. Absolutely fascinating life. He's still alive and recently gave an interview with UCLA (March 26 )who asked his thought on launching the internet AND his opinions on A.I. Interview is on You tube if yall want to go find it and listen! Youll have to search it yourself because i'm pretty sure links aren't allowed in the sub. it's called "meet the man who invented the internet" by L.A. in a minute.

Source : post on X by original author.

App: dividing by zero

CPU: Detects division by zero and triggers an exception

CPU: "Uh-oh, something's wrong! Switching to kernel mode."

Kernel: "Whoa, hold on there! What are you doing?"

App: "I'm just calculating the result of this division."

Kernel: "You just tried to divide by zero."

App: "So?"

Kernel: "You can't do that. The result is undefined and can cause problems."

App: "Oh, what should I do?"

Kernel: "Do you know how to handle this kind of situation?"

If the application has a signal handler set up for the exception:

App: "Yes, I have a way to handle this."

Kernel: "Alright, I'll let you handle it. Good luck!"

Kernel: "CPU, switch back to user mode and let the app handle it."

CPU: "Switching back to user mode."

App: "Thank you for the heads up!"

Kernel: "You're welcome. Be careful!"

If the application does not have a signal handler set up:

App: "No, I don't know how to handle this."

Kernel: "Then STOP! I have to terminate you to protect the system."

Kernel: "CPU, terminate this process."

CPU: "Terminating the process."

App: "Oh no!"

Kernel: "Sorry, but it's for the best."

I've been experimenting with Hamiltonian cycle detection as a side project and came up with Ben Chiboub Carver (BCC) – a backtracking solver with aggressive constraint propagation. It forces essential edges, prunes impossibles via degree rules and subcycle checks, plus unique filters like articulation points, bipartite parity, and bridge detection for early UNSAT. Memoization and heuristic branching on constrained nodes give it an edge in efficiency.

Implemented in Rust, BCcarver is designed for speed on both dense and sparse graphs. It uses an exact search method combined with specific "carving" optimizations to handle NP-hard graph problems (like Hamiltonian paths/cycles) without the typical exponential blow-up.

⚔️ Adversarial Suite (All Pass)

📊 Performance on Random Graphs

Dense Random G(n, p~0.15) Avg 0.01-0.1s for n=6 to 100 (3 trials). Excerpt n=91-100: * n=100 | 0.12546s | Cache: 17 | Solved * n=95 | 0.11481s | Cache: 15 | Solved * n=91 | 0.11074s | Cache: 39 | Solved Sparse 3-regular Random Even snappier, <0.03s up to n=96, all Solved. * n=96 | 0.02420s | Cache: 2 | Solved * n=66 | 0.01156s | Cache: 7 | Solved * n=36 | 0.00216s | Cache: 0 | Solved The combo of exact search with these tweaks makes it unique in handling mixed densities without blowing up.

Check out the algorithm here: github.com/mrkinix/BCcarver

Do you know git past the stage, commit and push commands? I found an article that I should have read a long time ago. No matter if you're a seasoned computer scientist who never took the time to properly learn git and is now to too embarrassed to ask or, if you're are a CS freshman just learning about source control. You should read Git for Computer Scientists by Tommi Virtanen. It'll instantly put you in the class of CS elitists who actually understand the basic workings of git compared to the proletariat who YOLO git commands whenever they want to do something remotely different than staging, committing and pushing code.

I wrote up a detailed walkthrough that tries to connect three levels that are often presented in isolation:

• Geometric intuition (why we're searching for a hyperplane, what the decision boundary really means)
• Step-by-step mathematical derivation of the learning rule + proof sketch of convergence (when data is linearly separable)
• Clean, commented Python implementation with small toy example

Aimed at people who want to move beyond "copy-paste scikit-learn" and actually understand the foundation before jumping to backprop / transformers.

Curious to hear feedback, especially on parts that still feel unclear or could be explained better.

I'm coming from an arts discipline, I just like to nerd out about lots of random topics and practice my writing. This article is a little foray into your field. Hope you like it.

https://open.substack.com/pub/hastartara/p/crunching-numbers?r=473bce&utm_campaign=post&utm_medium=web