Daily Learnings: Wed, Sep 20, 2023
Aim for the moon. If you miss, you may hit a star. — W. Clement Stone
Thoughts from the Changelog Pod on AI Assistance in Programming
Yesterday I was listening to the Changelog podcast, interviews episode 11, featuring Justin Searls and Landon Gray, from the company Test Double. In the conversation, they ended up discussing their thoughts on AI-assisted development, and what it might mean for the future of programmers.
Several different points of view were shared, and I found some of their thoughts insightful. Ultimately, I took away the following:
- AI will indeed allow a large number of new developers to enter the field that might not have been able to before
- This is a 2-edged sword:
- Pro: Giving many more people the opportunity to get into a potentially profitable career that might not have been able to before
- Con: AI is and will be a crutch, and will result in even worse quality software if we’re not really careful about it
- The best programmers are those that approach development like an engineering endeavor:
- Thoughtful
- Well-designed
- Slow, not fast
- Understanding the broader context
- Learning the skills of approaching development with an engineering mindset is something that will become increasingly important as more people simply copy/paste from ChatGPT / Github Copilot without really understanding what they’re authoring
History of the Apex Programming Language
I heard one time from someone (potentially Spencer?) that Apex, the programming language for the Salesforce platform, was created by the same person that wrote Java and C#. I’ve said it to multiple people since, but I’m not actually sure if it’s true. In fact, about 2 months ago, I heard on an episode of the Salesforce Developers’ podcast that the CTO of Salesforce created it.
So, in the spirit of trying to stop learning just enough to get by, and not really as much as I can, I decided to dedicate some time this morning to learning more about its history.
- Apex stands for Advanced Programming Experience
- Was originally created for internal use only in the Winter ‘07 release by Parker Harris, CTO and cofounder of Salesforce
- For reference, Java was originally created by James Gosling, who actually did NOT create C# as well
- In fact, there’s some beef between the two different language creators…
- Original intent for Apex was to be another layer of abstraction over database transactions
- Never intended for building UIs; Harris introduced Visualforce that same year instead
- For reference, Java was originally created by James Gosling, who actually did NOT create C# as well
- The introduction of Apex + VF transformed Salesforce from “No Software” to “Platform-as-a-Service”
- Dreamforce ‘08 had them change their name to “Force.com” to highlight that it wasn’t just a CRM, but instead a platform
- First implementation had no compiler, it was interpreted during execution, and had some limitations
- Used a lot of heap RAM, and you were limited to 3MB at the time
- Couldn’t deserialize JSON
- 2012 - Introduction of the first Apex compiler (all done in the cloud, nothing locally)
- Apex began to be compiled directly to bytecode
- Heap RAM increased from 3->6MB
- The original compiler was coupled way too tightly to the entire platform
- “Like the tentacles of an octopus”
- 2017 - Introduced the new compiler with the ability to leverage the Microsoft-based language server protocol
- Included a VS Code extension for building Apex
References
More on Rust
During lunch today I continued my study of the Rust programming language through the YouTube course offered by freeCodeCamp. In it I learned more about heap memory and stack memory, core computer science principles that I’ve never really stopped to try and learn.
The biggest learning that I took away from today’s study (if I actually understood it right) is the fundamental question of how most programs actually loaded into memory to prepare to run. Using Rust as an example:
- The
main()method is loaded into stack memory, along with all locally-declared variables and their values - Starting from the top down, the method is inspected to determine if there are any other functions called
- If so, each function is inspected and is loaded onto the stack, along with its related locally-declared variables
- This process continues till the stack is populated with the contents of the program
- The stack runs the program by popping off each method / function call following LIFO
The more I think about it, the more that I believe that this is a really grand over-simplification, and likely I’m getting some things wrong, but it’s a good starting point to understanding how computer programs work today.