What you need to be aware of is the new Pico is bare metal programming. On the conventional Raspberry Pi which is basically a "computer" you have an operating system running (mostly Linux variations). On the Pico this is not the case, this is a naked controller (ARM Cortex-M0), where any program directly interacts with the hardware. They really only have the name sort of in common, but this is a very different product.
Indeed, however from glancing over the docs for the SDK, they've done a good job at 'abstracting' the program from most of the lower-level dependencies, and their cmake environment does a good job at hiding all of the complexities of bootstrapping an MCU properly.
In fact, they appear to have a custom ROM firmware which cannot be modified (e.g., 'unbrickable' via any programming means, which is good for MCU's and beginners), which places the MCU into mass storage mode when a bootsel pin is tied low during bootup, which makes the pico appear as a USB mass storage device where you can drag your executables and they'll be automatically run on startup. No having to set up and use JTAG programmers and debuggers. They've even made setting up cross compilers for ARM pretty simple.
This is a far cry from the normal process, of setting the mcu from 'kernel' mode into 'user mode', setting up stacks and heaps, bootstrapping startup code (almost always in assembler), installing ISR's for HW peripherals, memory mapping control registers, etc...and that's just to get to your main() function. They've made easy the stuff that is always miserable to sort out and is an immense barrier for people to 'just get stuff working'.
The big thing I haven't liked so far is how they are asking programmers to utilize both cores, which involve understanding semaphores and manual spin-locking, however I'm guessing that only a small subset of programmers will be looking for this functionality.
November 10, 2015, 03:11:28 AM