Programming has changed. In first generation languages like FORTRAN and C, the burden was on programmers to translate high-level concepts into code. With modern programming languages—I’ll use Python as an example—we use functions, objects, modules, and libraries to extend the language, and that doesn’t just make programs better, it changes what programming is.
Programming used to be about translation: expressing ideas in natural language, working with them in math notation, then writing flowcharts and pseudocode, and finally writing a program. Translation was necessary because each language offers different capabilities. Natural language is expressive and readable, pseudocode is more precise, math notation is concise, and code is executable.
But the price of translation is that we are limited to the subset of ideas we can express effectively in each language. Some ideas that are easy to express computationally are awkward to write in math notation, and the symbolic manipulations we do in math are impossible in most programming languages.
The power of modern programming languages is that they are expressive, readable, concise, precise, and executable. That means we can eliminate middleman languages and use one language to explore, learn, teach, and think.
Adafruit publishes a wide range of writing and video content, including interviews and reporting on the maker market and the wider technology world. Our standards page is intended as a guide to best practices that Adafruit uses, as well as an outline of the ethical standards Adafruit aspires to. While Adafruit is not an independent journalistic institution, Adafruit strives to be a fair, informative, and positive voice within the community – check it out here: adafruit.com/editorialstandards
Stop breadboarding and soldering – start making immediately! Adafruit’s Circuit Playground is jam-packed with LEDs, sensors, buttons, alligator clip pads and more. Build projects with Circuit Playground in a few minutes with the drag-and-drop MakeCode programming site, learn computer science using the CS Discoveries class on code.org, jump into CircuitPython to learn Python and hardware together, TinyGO, or even use the Arduino IDE. Circuit Playground Express is the newest and best Circuit Playground board, with support for CircuitPython, MakeCode, and Arduino. It has a powerful processor, 10 NeoPixels, mini speaker, InfraRed receive and transmit, two buttons, a switch, 14 alligator clip pads, and lots of sensors: capacitive touch, IR proximity, temperature, light, motion and sound. A whole wide world of electronics and coding is waiting for you, and it fits in the palm of your hand.
Have an amazing project to share? The Electronics Show and Tell is every Wednesday at 7pm ET! To join, head over to YouTube and check out the show’s live chat – we’ll post the link there.
Python for Microcontrollers — Python on Microcontrollers Newsletter: Pi Day, GitHub 2FA and much more! #CircuitPython #Python #micropython @ThePSF @Raspberry_Pi
Interesting concept. The history of programming and programming language development (in my opinion) has been an attempt to make analysis/conceptualization more concrete and to make the coding constructs more conceptual with the hope that they will meet in the middle to reduce the transitions (and associated errors) in the life cycle–analysis->design->coding->deployment. I wrote an article in 1986 that touched on some of this. Although there have been incremental improvements, I think we still have problems in the transition from the front end of the life cycle to the middle and beyond–no programming language will solve that (languages don’t solve problems, people solve problems).
Interesting concept. The history of programming and programming language development (in my opinion) has been an attempt to make analysis/conceptualization more concrete and to make the coding constructs more conceptual with the hope that they will meet in the middle to reduce the transitions (and associated errors) in the life cycle–analysis->design->coding->deployment. I wrote an article in 1986 that touched on some of this. Although there have been incremental improvements, I think we still have problems in the transition from the front end of the life cycle to the middle and beyond–no programming language will solve that (languages don’t solve problems, people solve problems).