A Software Developer's Vacation In Singapore: Coast-to-Coast Trail Edition (Part 4/4)

In the weeks that followed, I would constantly revisit these sub-routes. I would do them again, and in reverse. The point was to get myself familiar with the entire route. Prepare myself for the day I attempted to the entire thing in one go.

And then the day came. I scheduled it, right on Good Friday, 3rd of April, and prayed it wouldn't rain.

In the morning, I had a McDonald's breakfast at Jurong East Mall, then headed off to Chinese Garden MRT where I prepped two bottles of water and a sandwich, and a Snickers bar from the Cheers store. Minimal prep, I know. That's me - minimal to a fault.

There, the Anywheel bike was rented, and I started off from Checkpoint One. Things were smooth-going much of the way; I was pretty familiar with the route by now, after having gone back and forth over it obsessively.

This time, I rode on the other side of Bukit Timah Road just for a more varied experience. This took me right past the Rochor River, and this was surprisingly beautiful. I might have caught it at a good time.

Rochor River was
quite the eyeful.

It was just before 12 noon when I arrived at Checkpoint Four. So far so good. I was feeling fine, and barely even breathing hard.

The First Break

I sat down at the Kheam Hock Park to eat my sandwich. The sky was overcast and I was concerned it might rain and cockblock my entire day. It was maybe ten minutes past noon.

Kheam Hock Park, right at the
end of a boardwalk.

I hadn't had time to really take a look at the tiny park. Charming. Good for a dog walk.

Once I reached the overhead bridge at Lornie Highway, I got over the bridge, passed MacRitchie just like the last time, and audibly groaned when I arrived at the construction going on at Bishan and Ang Mo Kio. Damn, I really hate this part.

Once I got that part behind me, the best part of the journey began - starting from Ang Mo Kio Linear Park to. the entire Waterway stretch at Punggol. I took some time to settle in and eat my Snickers bar.

Huddling under this bridge
for my Snickers break.

Once done, I was on my way again, passing Checkpoint Ten at Coney Island without bothering to stop. The sun was blazing but I soldiered on out of the beautiful cycling paths and onto the hellish landscape of Punggol Tingkat.

By this time, my ass was killing me and my right leg had gone numb. I was conscious of a light but persistent burning sensation on the back of my neck. When I finally crossed from Punggol Barat back to the mainland and was greeted by the sight of the entrance to Rower's Bay Park, it was like water in a desert.

Rower's Bay Park entrance.

The sun was high in the sky, and it was making the water sparkle. The beauty of the sight was indescribable. I'd just completed the Coast-to-Coast Trail, and it was glorious.

The alternative route from Checkpoint Seven

On a separate occasion, just out of curiosity, I returned to Checkpoint Seven at Sengkang Swimming Complex, to explore the alternate route to Checkpoint Ten. This was actually the Sengkang Floating Wetland, a patch of swamp that was somehow eerily beautiful in the day. I had to dismount from the bicycle and push.

The bridge over the wetland.

Nice park after the wetland.

The route led on to Sengkang Riverside Park, which I largely skirted to embark on a long stretch of road leading west, parallel to the Tampines Expressway.

Road leading out of the park
and under a flyover.

Long stretch ahead
next to TPE.

After some riding, I arrived at the Seletar Aerospace Flyover, and headed north again along Seletar Aerospace Way, right up until I came to this idyllic green patch called The Oval. 

Very nicely manicured
infrastructure at The Oval.

I was pretty much winging it at this point, with a rough idea as to which direction to my destination, but no real clue as to the paths I needed to travel to get there.

That final stretch!

Aerospace greenery. Pretty fly!

The next twenty minutes saw me meander around the aerospace until I discovered Seletar West Link, after which I simply rode the green stretch all the way to the welcoming entrance of Rower's Bay Park.

Thoughts on this route

Now this was underwhelming, and I suspect this was because I really didn't know the official route. In fact, part of the problem might be that this part of the Coast-to-Coast Trail simply wasn't meant for cycling. It was akin to trying to find semicolons in a Python code base. Sure, you'll probably be able to find them, but they won't mean the same thing to you especially if you cut your teeth on Java.

I don't feel like revisiting this part anytime soon, though the other parks around the area do look promising for exploration.

Epilogue

This little foray into cycling in Singapore, would soon expand into a more extended exploration of similar trails in Singapore. The fact that I had also quit smoking at this point, also meant that I was able to spend more time in these parks.

This was a side of Singapore I hadn't appreciated up to now. And I intend to remedy that.

Where there's a wheel, there's a way!
T___T

JavaScript's non-existent relationship to Java

Despite the fact that I can no longer, by any stretch of the imagination, be referred to as a "beginner" where my career is concerned, I sometimes do like to read beginner books on tech. It's oddly soothing. There's also plenty I can learn in terms of how to communicate tech concepts and ideas, from the authors of such books, if not the actual tech itself.

And this is one such book that I picked up from the neighborhood library recently - How to be a Web Developer, by Radu Nicoara.

This book.

Now, this isn't one of my Reference Reviews - I didn't finish reading the book and this would be dishonest. Radu Nicorara probably knows his way around the building blocks of the World Wide Web and has, again, probably done a whole lot more than I have. After all, he published a book. And I give him all the credit in the world for even attempting it.

However...

...once I got to Page 60 (or thereabouts), I encountered a statement that was so egregious that it took me out of reading the book entirely. Not that I ever found the book all that engaging in the first place.

This passage shocked me.

JavaScript is a scripting language (meaning the code is not precompiled) that's derived from the Java programming language, hence the name.

I was in complete disbelief when I saw this. Just to be sure, I sent a photograph of the page to Meta AI, and Meta AI being the nice little bot it was, it described the passage as "a bit misleading".

A bit misleading?! Try "completely false".

The error

For anyone who might be tempted to repeat this, JavaScript is not derived from Java. Aside from the fact that they may both be described as programming languages (coding pedants may insist that in JavaScript's case, it's a loose description) they don't actually have anything to do with each other.

JavaScript began life as a loosely-typed client-side language meant for browsers to interpret. Java was (and still is) a strongly-typed compiled programming language. The names are similar, and the syntaxes are similar. But that's where the similarities end, and even these similarities can't be used as evidence for JavaScript's relationship to Java.

In fact, JavaScript's original name was Mocha. Yes, as in the coffee. It was changed to "JavaScript" as some kind of marketing ploy to mislead people into thinking it was a child of Java. Well, guess it worked!

Fancy a cuppa Mocha, luv?

This reminds me of an encounter on the Clubhouse app where I heard some American woman make the ridiculous claim that in the Chinese language, "the words for danger and opportunity are the same".  John F Kennedy, the 35th President of the USA, was the first to say this back in 1960, and he was wrong. In Chinese, danger is "危机" and opportunity is "机会". Both words contain the word "机", but "机" is also a suffix commonly used to describe machines such as "飞机" (flying machine, a.k.a aeroplane), "手机" (hand machine, a.k.a mobile phone) and "耳机" (ear machine, a.k.a earphones). At the risk of stating the painfully obvious - aeroplanes, mobile phones and earphones have fuck-all to do with danger or opportunity, just as JavaScript has no relation to Java.

Which tells us a couple things - just because two words sound the same or contain subsets of each other, does not make the things they are describing, related. Thus, just because Java and JavaScript both contain the words "Java", it doesn't follow that they're related in any way. The second thing this tells us is, if you don't speak a language, maybe keep the witty quotes to a minimum unless looking stupid brings you deep emotional satisfaction.

As for syntax, both Java and JavaScript's syntax is based on C. Curly brackets, semi-colons, function declarations and so on. But this similarity is not confined to Java and JavaScript. Several other languages such as PHP and C# also have great syntax similarities with Java. In terms of similarity, C# is even closer to Java than JavaScript is.

All in all...

It's not my intention to jump on Nicoara for this error. Whomever his editor was, shares the blame for this. And this glaring factual error aside, what little I read of his book seemed sensible. Therefore, I didn't contact Nicoara and inform him of this boo-boo. What good would it do? It's not like one can un-publish this book.

Besides, I'm not exactly perfect. Early in my blogging days, I probably made my fair share of factual errors. Though, in all fairness, it's not like I'm profiting off my blog, or asking people to pay for it.

All that aside, I used this as a teachable moment. Even if that little piece of programming history I taught was dryer than a nun's coochie.

Java nice day!
T___T

No Blanket Solutions

There exists in the spoken language, a supreme contradiction. A sentence that manages to be simultaneously profound in its humility and stunning in its arrogance.

"If I can do it, anyone should be able to do it." - every douchebag ever.

Why is this humble? Well, on the surface, it seems like people who say this are modestly describing their achievements as mediocre. They feel that they're not special, so if someone as unexceptional as them can do something, there's no reason why most other people wouldn't be able to do it. For example, I quit smoking almost two years ago. I did it far easier than many people did, with no lingering physical or psychological side-effects despite having been a pack-a-day guy for the better part of twenty years. No discipline was required; the struggle was non-existent for me. However, I'm also reasonably certain that this isn't that uncommon. There are plenty of people, wired the same way as me, who could accomplish that. Acknowledging that you're not special, is humility.

Why is this arrogant? At the same time,  if I were to claim that I quit smoking without much fuss, and there is something wrong with people who can't simply follow my example; that's a problematic stance to take. Assuming that oneself is the standard on which everyone else should be based around, is both immature and pretty egoistical. It lacks self-awareness.

And both positions are wrong.

We're not all the same.

They're wrong for the very uncomplicated reason that we're all built different. We don't all come off some assembly line with the exact same characteristics. There are significant variances across data points like culture, upbringing, physical and environmental.

For example, people who spent their formative years in a Southeast Asian multicultural country like Singapore or Malaysia would have significantly less trouble picking up a third or fourth language as opposed to, say, an Englishman born and bred in the UK. Incidentally, that's why people coo and act impressed when a white guy speaks Mandarin (even if his pronounciation is dogshit). Whereas nobody bats an eyelid when an Asian guy speaks English well. Why? Because a white dude even attempting to speak anything other than dodgy English is impressive, whereas for an Asian guy it's just another Tuesday.

Is it fair? Well, of course not; but if we're going to acknowledge that everyone's built different, then nothing is fair.

The tech space

"There are no blanket solutions" is a favorite refrain of mine, because it's true especially in the tech space. You can have all the best practices in the world, but they have to be evaluated against the exact context in which you're applying them. The concept of best practices is a good thing, don't get me wrong, but only if not applied blindly.

Frameworks aren't always the way to go; I've said this before over and over. They're often the way to go in software development, but not in every situation.

Not every data storage solution has to include a database.

Not every 2FA solution
looks the same.

Not every 2FA solution looks the same - some involve texts to mobile phone and some involve a third-party authenticator app.

You wouldn't use Python to code every damn thing, just the same way you wouldn't use Java to do it. At least, I hope not.

While we're at it, almost every organization's implementation of Agile Methodology looks different from the next.

But while all I've said so far is uncontroversial, that's for the tech space. The software development context.

In a personal context

Someone once told me he wanted to be like me. I had a place of my own. I was doing well financially with no debt. While I wasn't filthy rich, I spent money without needing to think too hard about it. And above all, I was chill. I didn't let what I didn't have, bother me too much.

And all that was before I got blissfully married and really started stepping up my game at life.

Possibly, to an outsider who was just watching me live my life, it looked like I had everything without needing to turn to drugs or alcohol in order to cope. Furthermore, it looked like all that was needed to achieve what I achieved, was to live my life the way I did. Sadly, I had to disabuse this person of that fantasy. He was not going to achieve the same things I did by living like me, simply because he wasn't me.

There's more than
one path to the
rainbow.

My achievements aren't spectacular by any means. An apartment, a job and a spouse. Spare cash in the bank. The means to take care of my immediate family. These things are achievable by the vast majority of people. All I've really done is earn as much money as I can while living a very modest lifestyle. And that's the hard part.

You see, not everyone can, or wants to, live life the way I do, as if I were still drawing an income of just under SGD 3,000 a month. It takes a specific kind of person to happily sacrifice pleasure for stability. Not everyone has the same experience and needs. Not everyone has the same personality. I know plenty of people who would struggle mightily with a simple existence.

Overseas vacations, wine and cheese, cab rides, expensive pets, gym and club memberships - I won't miss any of those things because they're not the kind of things a guy like me cares about. But again, not everyone is like me in this regard. And honestly, for the sake of Singapore's economy, I really hope not. (Part of the reason why I can live the way I do, is because other people have this habit of buying pricey shit they don't need. So keep on doing what you do, guys; you're awesome.)

Therefore, it's not a simple matter of glibly saying "live life this way". Not everyone will take to my chosen lifestyle the way I have, or reap the exact same rewards from doing so. Why should anyone travel the same path and have the same outcomes as me when they're fundamentally different from me? That makes no sense, does it?

In a nutshell...

The mistake most people make is to assume that everyone wants the same things that they do, or at everyone is built the same way. That's why you have well-intentioned but severely misguided people going around advising others to have kids or go to Church or become a vegetarian because those things have benefitted them... and they assume that these things will benefit other people in exactly the same way.

People can certainly achieve the same things I have, or more... but they're going to have to find their own pathway to it.

Stay unique,
T___T

Do techies lean Liberal or Conservative? (Part 1/2)

Since the day I became aware of the Culture Wars over in the good old US of A, there's been a nagging question in the back of my mind. What side do techies really stand on? I'd like to think that we aren't a slave to any ideology - especially coming from Singapore, we're a pragmatic people who believe in whatever works in the most efficient way possible.

Silicon Valley does appear largely Liberal, or at least, that's what they would have us think. Jeff Atwood of Coding Horror, founder of Stack Overflow, actually jumped onto the anti-Trump bandwagon. However, after the recent electoral victory by the Republicans on the 5th of November last year, Big Tech has quite handily changed their tune. As I've often suspected, that's not the tech part speaking; that's the business part. That the appearance of Liberal domination in Silicon Valley was a veneer, and ran no deeper than that.

Nothing deeper than that!

And thus the question was begged. The answer, of course, that software developers, like many people, identify with both. They have some positions that are Liberal, and some that are Conservative.

The funny thing is that I identified three positions that could be considered both Liberal or Conservative, depending on one's perspective.

How Software Developers are Liberal

Identity does not matter. Software development is a field where logic reigns supreme. At some levels, it does not even require a particularly high I.Q, just the ability to do basic math and thick logically. Gender, race and sexual orientation don't determine an individual's ability to do math, and as such, are irrelevant when it comes to the ability to code, test and deploy software. A software developer is not going to automatically think that another software developer is competent based on identity.

Software
development isn't
just mens' work.

In fact, one of the most baffling (and frankly insulting) things I have heard as a developer is being told that I should be better at the job because I'm a man. What, and my years of hard work count for nothing? I'm naturally supposed to be better at it because God made boys engineers by default? Well, that's not what this tech thinks, and any male tech who tells himself that kind of rubbish, does himself (or anyone) no favors.

Innovation versus tradition. Don't get me wrong, we do have our traditions. But technology itself is a result of innovation and experimentation; daring to try new things. Thus, you will never hear a software developer saying that we should do something this way just because that's how we've always done it. That kind of argument holds no water for us. It runs counter to everything that drives a techie.

Tradition has its
charm.

We may respect tradition, but we are not slaves to it. There are no sacred cows. Tradition has its place, but tradition should also know its place.

We have tech innovations today precisely because we dared to go against tradition. We dared to challenge the pre-existing ideas of what was possible, or acceptable. What separates us from the herd is the willingness to ruthlessly drop tried and tested methods in favor of demonstrably better methods.

The collective versus the individual. Skillset-wise, you will never see a more diverse group. That's because in the tech landscape where there are very frequent changes and new things to learn, people end up learning across different (but often related) tech disciplines or going deeper into existing ones.

Tech skillsets come in all
shapes, sizes and colors.

There are no unifying standards as to what makes a techie, though there's been no shortage of would-be gatekeepers trying to keep things neatly classified. It's a lost cause.

Take any two developers, even from a broad collection of, say, back-end developers, and you may end up with one mostly trained in Java and one trained in Python. Take your two developers from a less broad group of Python developers, and you might get one who's more of a web scraper and one who's more of a data analyst.

Yes, tech itself is a huge domain, and evolving as I write this. Consequently, its practitioners are similarly varied.

Next

How we're Conservative.

Five Reasons to learn Web Development in 2025

Recent events such as the rise of generative AI, have made tech work a little less attractive than it used to be. Web development, in particular, has suffered. That's probaby because a large chunk of web development is automatable, and even before AI came on the scene, there had been numerous tools such as Content Management Systems and Low-code development platforms.

Thus, web development being automated by AI was par for the course.

Robots writing websites.

Still, not all is lost. While web development might have lost much of its luster, there are still good, strong reasons to pick it up in ones tech career. Unlike the tech reporters and HR executives who write listicles like these, I have actually been a web developer before. I speak from experience, my dudes. And following are some of the most compelling reasons I had, in no particular order of importance, for going down this path.

1. No complicated installation

Ever tried to learn a language like PHP or Java? Every single one of these languages requires you to set up some kind of compiler or interpreter environment. PHP requires an Apache server. Java needs the Java Runtime Environment. You can write all the code you want, but until the code gets compiled or interpreted by the environment that you have to install and set up, you're not getting even a Hello World program done.

All you need is a browser.

HTML, CSS and JavaScript, however, do not. All of them already run in any major browser - Firefox, Chrome, and so on. In effect, the environment is right there for you.

This is not to say that you will never need to do any complicated installation. But for the basic building blocks - again, HTML, CSS and JavaScript - of web development, you don't. You will need to do that when you want to pick up a server-side language and maybe databases and definitely for the NodeJS style of development. But for basic stuff? Even the slightly more advanced stuff? Nope, not even a little bit. That is a lot more than you could ever say about other programming languages or platforms.

2. Good skill spread

When you learn web development, you learn HTML, CSS and JavaScript as a base starting point. That's already a good spread right there.

HTML and CSS are where you learn front-end and possibly even design. When you learn JavaScript, in addition to all the things you pick up when learning a programming language such as operators, arrays, branching and iterative logic, you also learn asynchronous operations and DOM manipulation.

A good spread of tools.

That's not to say that other tech disciplines don't have their own unique perks. But where it comes to the skill spread, web development wins. I don't think anything else even comes close.

Once you get past the basic toolset of HTML, CSS and JavaScript, back-end programming and databases will come into play. It's never just web development. Even if you are averse to the thought of being a humble web developer for the rest of your career, there are far worse places to start.

3. Resources

Now, when I say "resources", I don't just mean documentation, references and learning materials, though there's plenty of that, yes. But web development is not special in that regard because any other tech discipline boasts plenty of learning resources and a community dedicated to helping each other learn.

A good learning
community.

Though, in this case, web development has something extra.

You see, every humble HTML page on the internet can have its source viewed and played with in the browser, reverse engineered, and so on. Every URL on the internet is potentially a resource for learning, much like how I learned to cobble together JavaScript widgets decades ago.

In contrast, it's not possible to just take any desktop application and reverse-engineer the code, because the code has already been compiled and is no longer human-readable.

4. Ready use case

Often, when learning a programming language, it's helpful to be able to use newly-acquired skills to build something, so as to really hammer home the muscle memory. Something both relevant and useful, preferably. Not that Hello World programs don't have their place, but if one wishes to level up, better use cases are the order of the day.

And with web development, those use cases are almost too easy to find. Web development creates web pages, at the minimum. And after that, at varying levels of complexity, web applications. One does not have to stretch too far to find something worth building... and because it already exists, you know that it is both worth building and possible to build.

Applying what you learn.

My larger point is that what you learn can readily be applied. Not just in creating and editing websites, but in general software development. This also means that your chances of landing a job with that skillset cannot be understated. In this day and age, web developers are perhaps not nearly as in demand as they were a decade ago, or paid nearly as well, but the skillset goes beyond just web development.

For example, a lot of existing software already leverage things like REST API endpoints. These are basically URLs, which are pretty much the backbone of the web. REST is an almost inescapable part of the whole web development deal. Ergo, if you deal in web development, at some point you are going to be dealing with REST endpoints, which overlaps a large part of software development regardless of discipline.

Or even mobile development. In case you weren't aware, a large chunk of mobile tech is basically HTML, CSS and JavaScript.

I could go on... but do I really need to?

5. No gatekeeping

In the legal profession, there's the Bar Exam. In the medical profession, there's the Medical Regulatory Authority. In tech? Other than job interviews which exist at almost every industry, there's almost no gatekeeping in tech. Even the requirement for Degrees of Diplomas is not a really hard one.

When I say "no gatekeeping", I don't mean that nobody tries to gatekeep. The fact is that many people try to gatekeep, but it just doesn't work because to gatekeep, one needs a unified set of standards. It's almost impossible to establish said standards in a landscape as varied as tech, whose goalposts shift constantly.

The gatekeeper.

And while this inability to gatekeep exists in many areas of tech, none moreso than web development. HTML, CSS and JavaScript are fairly stable at this point, but these are just the base technologies. Their offshoots - frameworks, libraries and the like - keep springing up like mushrooms. And when you consider databases and backend programming languages, the possibilities multiply even more.

All in all, one could come in anytime in web development, and still be relatively fresh and relevant. No one can stop you from making and publishing web pages and applications, not in the same way they can stop you from practising law. You don't need a license to write code, so nobody can revoke it.

Some clarifications

The reasons stated here are in relation to those for choosing other tech fields. Why, for instance, web development when you could go for Data Analytics or cybersecurity? Reasons specific to web development.

I was inspired to compile this list because there are a lot of vague, generic and - to be brutally honest - trite lists out there on the web that extol the virtues of web development. Hopefully this is a better list.

<html>Bye for now,</html>
T___T

What's the best programming language for beginners?

What should be a programmer's first language?

Often, this is not a deliberate choice, more a matter of circumstance. Perhaps a programmer started on QBasic as a kid. Perhaps, like me, the programmer picked it up in school and was made to learn C++ or Java. I would even venture to say very few programmers start out saying I'm going to begin my programming journey with the best, most modern language out there! To begin with, how would they know what constitutes the "best" programming language, or what even is a good programming language? You don't know what you don't know, after all.

Let's learn!

Also, how suitable a programming language is for your purposes also really depends on what your purpose is. Do you want to crunch data? Write games? Build web portals?

So, obviously, before we can sort out what the "best" programming language is, perhaps it is more useful to figure out what a programmer's first programming language should be. After all, this choice opens different doors.

For that, we should probably look at a few factors. I can only draw upon languages I've coded in before. as examples, obviously.

Syntax

For this, we look at simplicity of writing code in that language. How intuitive the syntax is, and how few extra keystrokes needed to get something done.

For this, my obvious picks would be Python or Ruby. Less of the semi-colons and curly brackets. Anyone picking either Python or Ruby as a first language, I suspect, would be less likely to give up out of frustration.

Code syntax.

C# and Java is probably among the worst for this. Too many namespaces. Overly verbose syntax. I haven't had many projects that needed to be done in either of these languages, and for that I'm truly grateful.

But the one that takes the proverbial cake, in terms of being cumbersome, would be PHP. The function calls structures are wildly inconsistent, and in addition to semi-colons and curly brackets, it also requires a dollar sign preceding every variable name.

As far as syntax goes, the group of programming languages with visually similar styles - PHP, Java, JavaScript, C and its variants - is such that if you pick one up, the learning curve for the others, at least for the simple stuff, isn't so great. Thus, even if PHP is hideously cumbersome in parts, it benefits from being visually similar to other languages mentioned.

Transferable skills

This measures underlying principles or skills that one will pick up while programming in a certain language, that will be useful when transitioning to another stack. It could be something as simple as similar syntax (as mentioned earlier) or strong data typing.

Or it could be something so ubiquitous that no matter what stack you're in, you're almost certainly going to encounter it. A great example of this would be SQL. No matter what kind of programming you go into, the chances of you needing to access a database at some point, are pretty good. I wouldn't go so far as to say that this makes SQL the number one choice for a programmer's first language, but it makes a great case for being a programmer's second, at least.

Data processing.

For a similar reason, if one wanted to go into web development, it's almost impossible not to have to deal with HTML, CSS and JavaScript, but learning JavaScript as a first language just for that, is questionable. As a second language, definitely.

Strongly-typed, class-based languages such as Java and C# would be good choices as a first programming language for learning concepts such as Object-Oriented Programming. (PHP and JavaScript kind of implement OOP as well, but in a way that's a little odd). Python would be the choice if one wanted to have a strong foundation in data structures. However, Python's lack of strong typing might work against it as a first language.

Ease of setup

One of the most daunting tasks of learning a language is setting up the environment for it. Java requires the JRE (Java Runtime Environment). PHP requires an Apache server. Python and Ruby, well, you get the idea.

For this, the most fuss-free option has to be JavaScript, hands down.

All major browsers
run JavaScript.

JavaScript runs on all major browsers. You don't need to install anything you probably don't already have. If you're reading this, unless you're reading it on your phone, you have a desktop browser which you can run JavaScript in. It's almost zero setup. Just write your code, and run it in the browser.

For a Windows environment, VBScript is also almost zero effort. All you need to do is write your script, save it with extension "*.vbs" and you can run it by double-clicking it! Unfortunately, I'm not sure how useful knowing VBScript is.

In essence, in the cases of both JavaScript and VBScript, the environment has already been set up for the programmer.

Popular support

No developer plies their trade without consulting a reference of some sort. Textbooks are a valid source, but for the most updated material, we turn to the internet. Portals and forums provide most of these, with each language having large communities of programmers ready to provide support.

Learn by reading, or
by community.

Which programming language has the largest, or best, communities?

That's hard to say. All communities have their fair share of toxic losers who waste little time being condescending and acting like gatekeepers. At the same time, each community also boasts genuine people. I'm not going to waste time detailing how large each programming language's community is relative to others. Suffice to say, they're all (OK, mostly) large enough to be useful.

Generally, the longer they have been around, the larger they tend to be.

Conclusion

Whatever the choice turns out to be, ultimately, there will be benefits to that choice. That is because no matter what language someone chooses for their first programming experience, the fact remains is that they are still engaging in the activity of programming. It's a start. Some starts are better than others, sure, but it's a step. And hopefully the first of many.

Mind your (first) language!
T___T

Separating Text Editors from IDEs

The acronym "IDE" stands for Integrated Development Environment. There is a little bit of confusion as to what IDEs are, leading to questions like "Is TextPad an IDE?" (Spoiler: The answer is No).

TextPad is a text editor. There are distinct differences between a text editor and an IDE, even though they may look similar to a layperson. Chief of which, a text editor is part of an IDE. An IDE comprises of many components, one of which is a code editor of some sort.

What Text Editors do

Text editors edit text. It could be a block of code, a poem about dinosaurs or a dissertation about why dolphins are such jerks. Think of your text editor as a drum. The thing you beat with a stick so it makes sounds? Yeah, I know, that sounds wrong. But anyway...

Now a text editor isn't exactly a code editor, but it's awfully close. A code editor edits code, which is basically text. It's essentially a specialized kind of text editor, highlighting code structures and syntax errors, autocomplete suggestions and maybe even beautifying it for human eyes.

Now if you think of your text editor as a drum, think of your code editor as a full drum set with cymbals.

Full drum set.

Technically, not all code is text, but for most high-level programming languages, they are. Sublime Text, for example, can edit code for PHP, HTML, Python and a host of other languages. Notepad will edit the text just fine, but won't highlight syntax. That's pretty much the difference between editing code and editing text. Most text editors can edit code in a pinch, and vice versa.

As a web developer, I've had to use text editors to edit HTML, JavaScript and CSS code. And generally didn't encounter many problems. You could still do that for code that needs to be compiled, such as Java or C#, but that would make the process of development way harder than it needs to be.

What IDEs do

IDEs consolidate common developer tools onto one interface, so this potentially eliminates the need to individually configure separate software packages. At the very least, an IDE provides a code editor and an environment for running the code.

Now if following the earlier analogies, think of your IDE as a rock band setup with drums, keyboard, bass guitar and drum set, all in one place!

A full rock band setup.

Some IDEs provide other features, such as:
- file versioning.
- deployment management for DevOps.
- workflow and project management features.
- build automation
- specialized interfaces for mobile development, such as Android Studio.

An example of an IDE would be Eclipse (for Java and Python, among others) and Visual Studio (which handles C#, HTML and so on). They are called IDEs because they also run the code in addition to editing it. They can debug the code and point out syntax and (some) logical errors.

In a Nutshell

Text editors basically process and format text. IDEs almost always include a text editor of some sort, but the function of an IDE goes beyond text editing.

Text you later,
T___T

Branching With Switch Statements

Decision blocks constitute a large part of programming. Much of the time, when someone mentions a decision in programming, the first thing to come to mind is an If block. And indeed, If blocks are amazingly versatile, able to handle just about all decision-making requirements in programming.

However, there are other options. And I would like to talk about Switch statements, which, while not quite as versatile as If statements, are better in certain use cases.

The Anatomy of a Switch statement

We begin a Switch statement with the keyword. In the case of C++ (and JavaScript, and Java) it's "switch". It then includes the variable, x, in parentheses, and the curly braces.

switch (x)
{

}

Assuming that the value of x is an integer, we populate the Switch statement with cases using the case keyword.

switch (x)
{
    case 1:
    case 10:
    case 35:
}

Optionally, there's a default case in the case that the value of x is not 1, 10 or 35.

switch (x)
{
    case 1:
    case 10:
    case 35:
    default:
}

If x is 1, we run the function a(). If x is 10, we run the function b(). If x is 35, we run the function c(). If it's none of the above, we run the function a(). Now that I say it like that, it sounds like this could be a multiple If statement block. However...

switch (x)
{
    case 1:
        a();
    case 10:
        b();
    case 35:
        c();
    default:
        a();
}

... we need break statements if we just want this to operate like a multiple If statement block. We'll get back to this soon.

switch (x)
{
    case 1:
        a();
        break;
    case 10:
        b();
        break;
    case 35:
        c();
        break;
    default:
        a();
        break;
}

In the meantime, this is what the same code would look like in PHP. Other than the mandatory dollar sign in front of the variable name, very little has changed.

switch ($x)
{
    case 1:
        a();
        break;
    case 10:
        b();
        break;
    case 35:
        c();
        break;
    default:
        a();
        break;
}

In Python, switch has been replaced by match, with no parentheses needed. This being Python, no semicolons are needed either. And Python automatically assumes you want a break statement, which may or may not be such a great idea.

match x:
    case 1:
        a()

    case 10:
        b()

    case 35:
        c()

    case -:
        a()

The anatomy of the Switch statement, barring keyword and syntax differences across these languages, are astonishingly similar. Some languages, like Python, omit the break statement altogether, in favor of a break by default.

The Flow-through

The break statement tells the compiler (or interpreter) that after executing the code associated with that particular case, execution should resume outside of the Switch statement. For the vast majority of programmers, that is what is intended. However, when the break statement is excluded, execution goes onto the next case (whether or not the case is a match), and so on until a break statement is encountered.

This is what is known as a "Flow-through".

How useful is this? Well, in the case below, if you want the code a() and b() to execute when x is 1, and only b() to execute when x is 2, then yes this would work.

switch (x)
{
    case 1:
        a();
    case 2:
        b();
        break;
    case 3:
        c();
        break;
    default:
        a();
        break;
}

However, this case is so obscure and (in my opinion) unintuitive that doing this deliberately will not register immediately to someone reading the code. A programmer is far better off simply relying on the classic If-else.

Advantages over If blocks

In terms of switching execution for simple comparisons, especially in multiple simple comparisons, a Switch statement is far more readable. The following is a series of If blocks. Each of these is a simple comparison, with each If block containing multiple statements. The comparison is read three times.

if (x == 0)
{
    // multiple program statements
    // ...
    // ...
}

if (x == 1)
{
    // multiple program statements
    // ...
    // ...
}

if (x == 5)
{
    // multiple program statements
    // ...
    // ...
}

This can be condensed into a single Switch statement for the variable x. The cognitive load on the one reading this code is less. We understand the intent immediately; these are all the permutations of the variable x.

Also, the comparison is read one time in this scenario. The performance gain here is minimal; but what if there were ten, or fifty different values to cater for?

switch (x)
{
    case 0:
        // multiple program statements
        // ...
        // ...
        break;
    case 1:
        // multiple program statements
        // ...
        // ...
        break;
    case 5:
        // multiple program statements
        // ...
        // ...
        break;
    default:
        // multiple program statements
        // ...
        // ...
        break;
}

Disadvantages compared to If blocks

The Switch statement is meant for simple comparisons against enumerated or string values. For more complex cases, the If or If-else statement is still the way to go.

Something like this, for instance, is not possible in a Switch statement. This has two comparisons involving three variables - x against y and y against z.

if (x == y || (y < (z * 10.5)))
{
    // multiple program statements
    // ...
    // ...
}

We could use more complex comparisons using the Switch statement, but then one of the main advantages - readability - would be compromised.

switch (x)
{
    case (y * 10.5):
        // multiple program statements
        // ...
        // ...
        break;
    case (z / 10):
        // multiple program statements
        // ...
        // ...
        break;
    case "hello world":
        // multiple program statements
        // ...
        // ...
        break;
    default:
        // multiple program statements
        // ...
        // ...
        break;
}

In a nutshell

There are use cases for the Switch statement, and it's incredibly useful for simple comparisons against one variable. For everything else, use the If or If-else block as a fallback.

Your Iffy programmer,
T___T

Ode to my Lenovo

Two weeks back, my trusty Lenovo Z51-70 laptop gave up the ghost. It was showing signs well before that; consistently dropping my network connection, lagging severely when saving files and most tellingly, a noticeable flicker on the monitor. Can't say it didn't give me fair warning when on Saturday, it refused to power on.

Now, that was a sentimental moment.

Rest well, my friend.

I first obtained this flat white beauty during a Christmas Sale in 2014, when I was about to begin a Specialist Diploma in Mobile Apps Development. While my company at the time had issued me a decent notebook, I didn't feel comfortable using company property for my personal enterprise. I had a personal laptop, but it was on its last legs. Thus, I went for an i5 Intel Core that would meet my programming needs.

2015 to 2017

2015 was the second semester of my Specialist Diploma in Mobile Apps Development. With Java being the operating language, I installed Eclipse and the Java Runtime Environment. I also had NodeJS installed, and wrote apps in jQuery Mobile to deploy onto the mobile phone. This would perhaps be the most serious and intensive period of using the Lenovo.

Mobile app development.

Somewhere along the way, in addition to my steady diet of HTML, CSS and JavaScript experimentation, I experimented with things QBasic, LESS and AngularJS. An odd mix, I know, but I was having fun.

MeteorJS came along for me in early 2017. The lessons I learned here would help me years later when I experimented with ReactJS.

2017 to 2019

This was the period of my life where I settled down into a regular nine-to-five. I still experimented on weekends, writing D3 and ReactJS code. It was also the time I picked up Ruby and Rails, for whatever reason.

Like a stallion.

The Lenovo handled it all like a champ. It was tireless, inexhaustible, like a stallion in its prime.

Around the latter half of this period, I started working on my ACTA. Whatever work I needed done, I did it on my trusty laptop.

At some point during this period, I also got married. Late nights at the console were no longer viable, not if I wanted to sleep in the same bed as my wife. Still, I squeezed in whatever time I could.

2019 to 2023

This was the year the COVID-19 pandemic hit, and marked one of the longest durations my wife and I were geographically separated. During this time, my work on the Lenovo intensified, with me trying out Highcharts and VueJS.

During this period, however, I had acquired a MacBook and was gradually transitioning away from my faithful Lenovo which was starting to show its years.

Getting pretty old.

It was also when I embarked on my yet another Specialist Diploma, this time in Data Analytics. The MacBook handled Python and Tableau, but only my Lenovo could run Spotfire and  Power BI. It creaked and groaned, but ultimately delivered.

Why is this particular laptop special?

Why do I feel so strongly about this fella? It's not the first laptop to die on me, after all. I've lived more than forty years. But the last nine years of my professional life have been pretty tumultuous, and also represented the bulk of my career advancement and tech education, spanning two Specialist Diplomas and a Higher Certificate. This Lenovo was with me through all of it. I played no games on it. All I did was write code, and run code. (Some of that code were games I wrote, but we're just splitting hairs at that point!)

Much of whatever important files I have are saved on the cloud - on Google Drive, GitHub and Trello. Thankfully, I can resume my work on a new machine with little trouble. But I'll always treasure my time with this machine.

Rest In PC,
T___T

TeochewThunder: Year Nine (Part 2/2)

Much of this blogging year's content was strong. Few made it to extreme highs in terms of readership, or broke existing records. On the other hand, plenty of them garnered a respectable amount of views.

Red hot

Those posts in this category simply reinforce my point that it is my views about politics and the workplace, rather than my tech, that get the most attention.

Damn, that's hot.

Quiet Quitting: Do Or Do Not? examined the phenomenon of Quiet Quitting in the workplace.

Film Review: Black Mirror Series Three was a surprise - I didn't know people were that interested in a series that isn't even all that recent. It definitely overperformed.

The Real Reason Behind Political Resignation rode upon the wave of awareness generated by the recent (at the time) scandals in the Singapore Government.

Remote Work Is A Moral Issue For Elon Musk was basically me roasting the world's douchiest techbro millionaire. I don't know why, but people seem to pay more attention to these. That's sad.

Decent

These got a fair amount of attention - some of which was expected, and some which weren't.

Well done!

That Sinking Feeling At Twitter was a post talking about Elon Musk and Twitter (now X) and this always gets attention.

Film Review: M3GAN, Film Review: Missing, Film Review: Black Mirror Series Two and Film Review: Black Mirror Series Three, Redux were film reviews and these usually do well. No real surprise here.

Five New Workplace Buzzwords, Does Skin Art Affect Your Career Prospects?, What we think we deserve, does not matter, On job applicants who want work-life balance, Didn't get that promotion? Blame The Peter Principle and It's Not Personal were some of my views on the workplace. Could have done better, but I'm not complaining.

ChatGPT's capabilities and their implications in Software Development, Big Tech Layoffs in Progress!, From Twitter to X? and  TikTok Congressional Hearing: The Good, The Bad and The Ugly were about recent tech developments. I honestly expected these to do better, especially the last one. I mean, I worked really hard on the TikTok Congressional Hearing. Oh, well.

The How And Why Of One-Hot Encoding and Let's Unpack The CSS Box got a surprising amount of attention. I've never labored under the delusion that people bother about my more technical posts.

A Software Developer's Vacation in Kuala Lumpur was a WTF moment for me when I saw it had gotten this many views. I really wasn't under the impression that people care about my vacations, or about Kuala Lumpur. 

Meh

These were the underperformers. The ones that I expected a better reader reception for, and just didn't get it. Thankfully, there's not that many of them.

What a letdown.

Meta's new platform: Threads or Threat? now this one definitely underperformed. I don't know why.

Five Java Exceptions Personified was a fun listicle that bombed. I had higher hopes for this one.

Here's to Year Nine!

The blog has survived. It's often on life support, but it's there. I haven't been a huge success, but that was never the goal. The goal was to build muscle memory, keep me sharp, help me stay current and relevant. And on that front, it's worked wonders.

On cloud nine,
T___T