Goodbye Swift Hello World (part 2)

The practical result of what comes out of the last post is that my son and I are going to write our first real (for sale) application as a web-based application.

It will certainly have user login for keeping track of who has paid and not, and we can easily use anything from Amazon Pay to Apple Pay to handle payments. As mentioned earlier, we do plan to (later) return to Swift and write a Mac/iOS stub for the App Store; thus allowing Mac, iOS and iPadOS customers to log in and pay using their Apple credentials. Similar could be said for the Google Play (Android) market.

To do this we will need to define again what our target environment is; for example, are we going to focus on the server side (PHP and MySQL) or the client side?

Initially, it is the back-end (PHP and MySQL) which is most important; this gives a universal basic interface for the program. There will be a very minimal interface written alongside a JSON-based web API. The web API will be used by stub applications where direct web access is inconvenient,

And there you have it, the logistics of the program have already been written, and in general terms I can already hold the entire application in my head. This is why we aren’t using Swift. At least not yet. But we will. Maybe.

Unfortunately this project is not a part of Programming with Kids. In fact there may be a book coming, called “Programming with Adults” (not really, but a different name). We may discuss aspects of that project in the book.

In any case I really wanted to use C or Java or Swift for something cool, just to say I did it. But as it turns out, time is short, and the web platform is ticking all the boxes I needed and more.

Goodbye Swift Hello Target Environment

Swift is great. For MacOS, iOS and iPadOS. But it’s not good for other things. How is that, you ask, a language which is good for MacOS is not, for example, good for server-side Linux? Or since you can script it, why isn’t it better than PHP?

Well the short answer is target environment, which I have come to understand — as the epiphany of my long programming career — to be the king of all languages and language choices.

As of now my son and I have reviewed more than 10 languages. And one thing keeps cropping up; for each environment there are a series of languages which are best suited to that environment. For example, as long as command lines exist, C will exist — because C is, de facto, the command line; along with it’s stdin and stdout and stderr.

As long as Linux and Windows will exist, C, C++, Java and C# will exist — as well as a handful of other, smaller languages.

As long as MacOS exists, Swift, and likely Objective-C (all rumors to the contrary) will exist. You simply do not deprecate 20 years worth of codebase, 50% of which your OS is written in, overnight. It’s always going to be there, available, even for many years after everyone stops using it.

So when it came time for my son and I to write our first real application, we considered one environment and one environment only; the web. Why is simple; all consumer computing platforms today fall into one or more of of three categories:

  1. The ability to consume media (play games and/or watch tv, movies, music, etc)
  2. The ability to create media (content creation including programming)
  3. The ability to surf the web.

Now look around you. While many computers exist to do #1, and many exists to do #2, and some even can do both, all computing platforms can do #3. In fact, performing #3 is more important than doing #1 or #2. Look at the iPad and iPhone and Android phones and tablets. Long before they could seriously perform tasks #1 and #2, they were designed around being able to perform #3 as a primary function. In fact, it could be argued that without being able to do #3 it would not matter how great a computing product was, no one would buy it.

#3 is really code for “the internet”, which is the target environment which all computers use as a standard environment. By environment I mean a GUI of some sort (Windows, Cinnamon, MacOS, iOS and so forth), a command line (shells of various sorts), server-side, and other. For example a command line program for Linux simply will not run on iOS; the two target environments are different. This is reflected in what is considered a “standard library” to each kind of program.

The Most Interesting Target Environment in the World

The Web is the most interesting target environment in the world because it is not designed as an operating system; and it is not designed as specific hardware; but now, the browser itself has become a virtual machine. But not just any virtual machine. A standardized virtual machine, that looks and acts the same anywhere. The only real major concern is the screen size; and since we know it is variable we can design a flexible (reactive, some call it) way of presenting information on the screen.

And now, with Web Assembly, you can write programs that run on the Web in almost any programming language that you can think of.

But for the ubiquity of it all, JavaScript is the key crux of this environment; as for the server side, PHP is probably the most important language, although really anything from Python to Swift could be used. Look at the algorithm “LAMP” which stands for Linux, Apache, MySQL and PHP. The portions “Linux” and “Apache” are merely servers for the content, and the backend of MySQL and PHP. The front end is assumed — it is actually more assumed and standard than Linux, Apache, and MySQL itself. Including PHP in this equation however is a massive compliment to PHP. For most use cases, PHP should be used merely because nothing else is as tightly integrated; but this is changing, and the reality is you can probablyu replace PHP with whatever you want so long as you can really do what you need to do in some other language. To the point where if you’re using some language like Go, Ruby, Rust or Swift (or God forbid, Haskell) just to spite PHP or because you don’t know PHP, you’re doing it wrong. Find a legit reason.

And it is precisely this need to find a legit reason which makes JavaScript such a compelling choice.

Javascript gave us everything Java promised to do, and helped us fight against the evil MonsterSoft even when Java couldn’t, and more.

But the use case alone is so compelling that I honestly cannot understand why people write native apps for mobile. “To use the app store’s infrastructure” does not make sense since hundreds to thousands of new apps and games are released over various internet program stores every day. If your app is worth it, having the larger target market is going to be worth more than the infrastructure. What you want to do is avoid getting lost in the mix so badly that only a distribution network can save your program. Just remember — in the end, you can always write native stubs which access and interface with your server-side API to leverage the native platform’s secure payment and user identification capabilities, all the while acting mainly like a web browser.

So as much as C is “small and beautiful”, Java is “great and terrible, beautiful and treacherous as the seas”, and D (or Swift, or something) is “as good as it gets without designing your own language”, and maybe even Python is “the little scripting language that could” — JavaScript is the language that has seen and done it all, which has stood the tests of time and has finally brought peace to the universe.

Anyone who says differently is selling something.



Goodbye Java Hello Swift

I haven’t given much love to this blog recently, mainly on account of my son teaching himself Java.

Basically I was going to do a whole section on Java for the wiki, but I didn’t have to — he decided to do research on the internet and figure it out for himself. He stuck to the plan; find out how to print a message, find out how to get keyboard input, and find out how to do branching with if-then. After he learned random numbers and a few other methods he began to write short, simple programs. I asked him to write a clock — he did, and his solution for printing the time in-place was very interesting.

But I’ve decided to return to Java at a later date with him and focus on Swift for now. As it turns out, I have quite a good feeling about Swift.

He doesn’t have a MacBook yet, and my MacBook still hasn’t arrived yet, so we began by installing Swift on Linux Mint under Virtualbox. It seems to be working great. We have it set up so he can edit files using sublime text, and then run them via the command line. It’s a little clunky, but I am not aware of any better Swift IDE for Linux (or Windows).

We started with

print(“hello neo!”)

And then I told him to write a short story about something he likes. The results were magical — he has already internalized the print() function!

More tomorrow.

Programming for Kids (Part 3): C Programming

C is the third language I decided to teach my son. The plan was simple; follow the theme of getting up to speed quickly, then continue by introducing components of the language with which we would build ‘interesting’ demo programs. In this case, I had already decided to introduce printf, fgets, rand and if – and using those four components we would immediately recreate the number guessing game in C.

The plan seemed to work well, and once he grasped the MVP in C he started experimenting. The results, were even more fantastic than before; he wrote his best game yet!

C is the first language where there is no arbitrary limit to what you can write on modern computers. All modern computers can understand C code, or rather you can compile C code targeting virtually any modern computer system in use today.

Who is this tutorial for?

If you have completed the Shell Scripting tutorial, then you should be okay with this one. It’s just that we aren’t going to explain anything except Makefiles. If you’re comfortable with that, dive right in!

What will you learn?

As stated above, C is the first language without limits, and with power comes responsibility. It is our goal to teach you this responsibility and above all the use of restraint which will come from a deep rooting in analysis, of which the design document and proper commenting will be paramount.

  • You will learn how to write everything you learned in previous lessons in C.
  • You will learn how to write simple, well-organized code.
  • You will learn by example how to write “safe” code (ex. we use fgets for input vs. scanf).
  • And… you will learn to write amazing video games!

To continue reading, please visit the (wiki version) on the Programming for Kids Wiki!

Programming for Kids (Part 2): Shell Scripting

Just a note to say the Shell Scripting section is up on the wiki. I think it turned out pretty well. We will probably do 6502 Assembly next!

Towards an MVP

As noted in the BASIC section, the MVP is really the name change game. But the number guessing game is of sufficient complexity that it feels more satisfying to create. Recalling our lessons in BASIC, for the number guessing game we are looking to find four distinct components of a computer language which will enable us to write simple programs.

  1. Output data to the user.
  2. Input data from the user (into a variable)
  3. We also need the ability to compare variables (ex. IF..THEN)
  4. We need a GOTO command, or a similar command to control program flow.

These four components are as follows:

Component 1. Print to the screen

Note that the first line of a shell script must contain a comment with the path to the preferred shell script interpreter. All other comments are ignored.

If you would like to read more, please visit this article on our wiki page.

Programming for Kids (Part 1)

VICE C128 Emulator

In the spring of 2019, my wife suggested that I homeschool my 11 year old son, Neo, in Computer Programming. He had already demonstrated an aptitude for creativity and patience by creating some stop-motion lego movies with an old camera I’d given him, and I thought he was the right age to start, so I began.

My intention was that he should have the same experience learning computers that I did. When I learned computers, I taught myself by entering computer programs – the hands-on approach. I believe this is the best way for children to learn programming; by seeing the results of actual code as quickly as possible, and as often as possible. In this way learning to program computers becomes like learning a new language. My goal was to apply the “Acquisition” approach to Computer Programming. Any Stephen Krashen lecture will do, such as this one, off the top of my head.

I also believe that the reason I became good at computers is because when I learned computers they were small and easy to understand. The VIC-20 and Commodore 64 had a small memory and therefore the operating system was very small (unlike today’s Linux, OSX and Windows computers). In addition there was no multitasking – computers could only do one thing at a time. Although today this is seen as a limitation, it is a benefit when you are learning because you can understand how the entire system works together. Once you learn this on a smaller computer, you can easily learn the concepts behind today’s multicore, multitasking systems.

I began by teaching him BASIC programming on a Commodore 128 simulator. And, as we continue our journey, I will journal our progress here!

(wiki version)