Looking to learn something new? Try Rebol

Rebol is an odd language with an odd history.  It was originally put together in 1997 as an answer to the many things that plague modern programmers.  The goal was to create a language construction set using what we've learned from all the crazy trial-and-error in other languages.  For instance, have you ever wondered why we use curly braces?  In Rebol, square brackets are used (saving your shift key a lot of work [0]).

Alright, enough semantics, let's get into the real part of coding.  Download the Rebol binary.  While you're waiting, notice that you're not waiting, because the binaries are only half a megabyte.  This gets really impressive when you realize just how much is in Rebol.  Anyway, don't forget to chmod +x if you're on a good operating system.

So let's run through a basic "Hello World."  Step one:

>> print "Hello World!"

Well, that was boring.  How's about instead of going through the same boring syntactical tutorials, we check out the constructing power of Rebol and write helloworld in our own language?  Alright, now we're cooking.

To do this, I'll need to get a bit academic for a second (sorry, it'll be quick).  Everything you punch into the interactive shell (also known as REPL) is evaluated in Rebol's DO dialect.  In Rebol, a dialect consists of a set of instructions to work with a given input [1].  Let's take a look at the PARSE dialect, which takes the following format:

parse input rules /all /case

Let's ignore /all and /case for now and focus on the cool part.  Let's make an incredibly basic language where "a" is syntax for sending the string "Hello " to system.out and "b" does the same, but with the string "World!\n".  We could implement something like this in JavaScript like so:


While it's only a couple lines, it's still very difficult to extend.  In Rebol, it looks something like this:

parse "abc" [any ["b" (print "world!") | "a" (prin "Hello ")]]

The first two bits are simple: parse enters the PARSE dialect and "abc" is the input we're passing in.  The rules section is what we're really after..  Let's break it down:

[any ;If the parser finds any of the following
  ["b" ;an instance of "b"
    (print "world!") ;Output "world!" with a newline
                     ;parens mean that this code block will be executed in the DO dialect
  | "a" (prin "Hello ")] ;Same as above, but using prin, which doesn't output a newline
]

There you have it, your own special language (an incredibly contrived one, to be sure, but one nonetheless).  However, that's nowhere near as powerful as PARSE gets.  Let's taken on an interesting problem: determining if a mathematical equation is valid.  Benjamin Gruenbaum provides the following example in JS:


As you can see, this task is much more difficult for JS to express. It's a tad harder in Rebol, but not nearly as much.  To simplify things, we're going to do some assignment (using a colon instead of the equals sign, example taken from the Rebol docs slightly modified to reflect the latest version of Rebol):

expr:    [term ["+" | "-"] expr | term]
term:    [factor ["*" | "/"] term | factor]
factor:  [primary "**" factor | primary]
primary: [some digit | "(" expr ")"]
digit:   charset "0123456789"

The important thing to notice here is the recursive nature of the instructions.  "expr" is the top-level one you'll pass to the parse command:

parse "1+2*(3-2)/4" expr

== true

parse trim/all "1 + 2 * ( 3 - 2 ) / 4" expr ;use "trim/all" to remove whitespace

== true

There's much more in Rebol, so come to our our chat room and find out!  (This is a StackExchange chat, so you'll need 20 reputation on StackOverflow to talk).

[0] US keyboard only (sorry!)
[1] It's like a function, only more powerful.  Every expression runs in a dialect.  You can read about dialects in the docs or Wikipedia.

The hardest question on the YCombinator application

For the past two years, I've worked at becoming a better programmer, all with one goal: my own startup.  After lots of work, learning, and discussion, my friend and I have an idea and a half-done prototype.  It's finally time to do what I've been waiting for all this time: Go to YCombinator.

Well, we have to apply first.  Naively, I thought the application would be like anything else I've ever applied for.  I'd fill out my name, answer a few questions about myself and my idea.  I was incredibly mistaken.  Writing up answers took up four days of writing, editing, and thinking.  It forced us to finally look into how we'd split up equity, made us think through our entire pitch (four times), and had one really, really hard question.

No, it wasn't the money one (though I'm still not sure how to answer).  Nor was it "What is your company going to make?" (though that was the second hardest).  Surprisingly, the most difficult question for me was:

If we fund you, which of the founders will commit to working exclusively (no school, no other jobs) on this project for the next year?

Founding a startup is a big risk.   I could find myself penniless in two years with no property and fewer prospects.  I owe it to my parents to finish my degree, and to my fiancee to have a secure job after we get married.  The startup life can't promise either of those.

Every startup founder has an incredibly tempting out: the day job.  As Dilbert-esqe as they are, a day job is a siren call to the guy who has been subsiding on Ramen singing the promise of a salary and a solid night's sleep.  I know at any time, I could drop the whole pretentious startup thing, finish my degree, and get a nice comfy job somewhere where someone else will make all the decisions.

Answering yes means that I'm giving up on finishing my degree in a timely manner, if at all.  It means I'm accepting one of the most stressful jobs I could have.  I spent a lot of time staring at the screen, wondering if I could be daring enough to put down an emphatic YES.  I almost didn't do it.  I almost said "I'd like to work on a startup, but..."

You may not be an entrepreneur.  In fact, you don't even need a job to hit a decision like this.  Our culture (and parents) emphasize a conservative lifestyle, playing it safe at every turn.  Today, take a risk.  Do something different.  Don't let yourself worm out of it.  You'll be surprised at the results.

If you've read this far, you probably should join the discussion on Hacker News.

Is JavaScript's ubiquity a bad thing for Node?

There's no doubt about it, JavaScript is as close to a universal language as one can get, at least in terms of developers with passing knowledge about it.  Regardless of server-side language preference, virtually all web developers know some level of JavaScript.  Unfortunately, most only have a very basic level of JS ability, instead using jQuery or the like.

The truth is, it's pretty easy to write bad code in JavaScript.  Consider the following:

$(document).ready(function(){
    $(document).ready(function(){
          a = $("*").find("*").find("#myDiv")
          a.onclick=function(){
              alert("U CLIKD")
          }
    })
})

Ouch.  Two document.ready, horrid abuse of jQuery's universal selector and not a semicolon in sight.  I don't know what's worse, the code itself or the fact that it'll work on every major browser.  The web's been incredibly forgiving to programming mistakes and it's showing.

This isn't a rant about terrible software.  Instead, let's talk about one of my favorite technologies: Node.js.  One of the biggest advantages that Node brings to the table is the ability to use one language across the board in your project, but Node is a lot less forgiving of poor code.  The big question is this: will the use of JS for node help or hinder the Node ecosystem?

As a part-time optimist, I see this adaptation of a universal language as a net benefit for Node.  Many great programmers attempt to be always learning new things.  Why not chose that cool new framework that's in a language that you already know?  That's how I got sucked into Node awesomeness.

Others think that bad programmers will give Node a reputation for being incredibly difficult (even though it's pretty simple) as they try to build a Node app and fail.  They'll spread the word that Node is a harsh language and "totally unradical" (or whatever dialect they use).

What do you think?  Post your opinion in the comments here or at Hacker News.

My dumbest productivity hack yet

I've talked about productivity before.  Figuring out new ways to work harder is almost always more fun than actually working harder.  For bonus points, you can efficiently organize how you read all your productivity blogs.

Enough editorializing.  Remember when I wrote about to-do lists?  Yeah, those are still important.  But behind every item on a list is a greater goal that you want to achieve.  "Mop floor", "Do dishes" and "Dust cupboards"  all have the goal of a clean, livable kitchen.  A more difficult challenge is determining what the overarching goal of "Organize Database", "Fix bug #133", and "Check analytics" is.  Clearly one wants to have good code and a better product, but what's the point?

Google knows what their point is, and it isn't "Don't be evil."  It's to organize and index all of the world's information, be it websites, books, or photos.  Whatever you do, there should be a goal.  Currently, our startup is looking at the state of education and saying "Yeah, we can fix that."  But "do something 'bout that" isn't a goal unto itself.  Acknowledging that something needs to be done and actually finding something to do about it are worlds apart (unless you're in politics - then the second bit is irrelevant).

So we've got a subset of the problem identified and are attacking it, slowly but surely.  We already had two pivots, one tech and one ideological.  The problem is that the answer to our Big Question [0] of "Heck, is this even possible?" is quite clearly no.  No matter what action movies say, two guys with computers simply can't change the world.

Our big ideological pivot has been from "Hey, let's build a thing" to "Hey, let's try and create something that other people will want to join."  Our startup will almost certainly fail unless we bring others on.  These others don't have to be additional co-founders (too may cooks will spoil the broth) but investors, supporters, and early clients.

So we now have a goal that all of our to-do items can point towards: Get others on board.  Despite arguments to the contrary, we still think that an accelerator is the best place for us as it will provide "others" better than we could solicit on our own.  Any accelerator worth it's salt will also know what others we need much better than we could.

We won't accept anything less than the best, and the best accelerator is without question YCombinator.  If you need any evidence of that, just read through Paul Graham's essays.  I certainly have, and it's made a world of difference.

The funny thing is that it's not the content of the essays that makes the difference (though it's immensely helpful).  Remember what I said about goals?  It's very easy to lose sight of the overall goal as you're closing bugs and documenting.  When I feel exacerbated and miss the whole point of what I'm doing, I can look at that tab and remember why it's all happening.

So there you have it folks: The dumbest productivity hack to date: A tab in a browser.  It's also one of the smartest - Set up your work environment so you remember why you're working.

[0] The reason that particular post is so poorly-constructed is due to the fact that I was confronting the reality that all startups must face (we'll fail at it alone) with the mentality that we must do it alone.  Die Hard, you're a great movie but you give terrible startup advice.

Winning is easy, you just have to try

I've noticed an odd phenomenon among people in general - they're afraid of failure.  Yeah.  Me too.  So much so that I'd often rather do nothing than risk failure.

Let's move on from the "well duh" department.  There have been plenty of studies, blog articles, and crazy uncles telling you to try something because Failure Isn't Bad.  Bah.  Failure is bad.  Otherwise, it wouldn't be failure.  There are many different good things that can result from something going wrong (say, vulcanized rubber) but on the whole, one wants to succeed.

Learning how something doesn't work is often a step on the path to discovering what does, but we've lost sight of what the whole point is.  Instead of seeing failure for what it is (a step on the path to success), we have made it into an end of itself.  Failure isn't something to be proud of.  Instead, be glad you're further along the road to success.  Focusing on failure tends to create a more-permanent failure.

When I try something new, I want to learn, and I want to win.  I accept that work needs to be done and things will never work out the way I want them to on the first time.  That doesn't mean that success can't be easy.  Instead of looking at failure as the metric, why not break success down into smaller parts?  (astute readers will notice that this is the basis behind A/B testing and to-do lists).

For instance, I've been working to make myself a more sociable person.  I could list off the many times I've "failed" and what I learned from that, or I could look at just how easy small changes for the better can be.  As it turns out, saying "hi" as you walk past someone makes them feel a lot better and more likely to reciprocate.  Making that change was a small success, but it was a success nonetheless.

Not all changes can be as small and simple as that, but when I run git commit for something as basic as adding a <br />, I could let it roll pass me and move on to the next thing.  Instead, I choose to see that as my product becoming one step better, no matter how small that step is.

Is there a place for Java?

While Java hasn't elicited elaborate rants like PHP, there's still a good bit of hate out there.  The disadvantages are well established: Java, while fast at executing, slows down development through an incredibly verbose syntax.  It's also much easier to create tangled webs of classes, so much so, it's coined the term Lasagna Code (Spaghetti code with too many layers).  Still, it's the most popular language out there (or at the very least, in the top #3).  Cynically speaking, this is because Java makes it easy to look like you're working.

In terms of productivity, where does Java fit in?  Is it a dead-end of a language, doomed to be a litmus test for the quality of a programmer?  Will Java's entire contribution to the hacker community be to confuse newcomers to JavaScript or can we find a happy niche for it in some academic job?

Actually, yes.  There just might be a place for Java in learning programming.  There's lots of debate on the topic of a first language (though Python seems to be a consensus).  Don't get me wrong, Java is a terrible first language (I don't care about your "standards").  There's so much overhead (Hello World can barely fit into a tweet), teaching Java to newcomers feels like requiring a full APA paper for each homework question.

So Java isn't appropriate for beginning programmers, nor is it a good choice for those who want to Get Things Done professionally.  However, there's a huge gap between the two, and that's where I think Java might actually be useful.  Remember my rant about the misuse of jQuery (and by extension, all other abstraction libraries)?  Here's me, a fairly liberal programmer, advocating the use of verbosity!  Next thing you know, we'll all be riding our airborne pig-mounts to work.

Seriously though, the one place verbosity shines is learning.  It's much better to learn the system underneath what you're doing in order to write better code when you move to higher levels.  In that case, Java seems designed to teach Object Oriented principles.  Everything is nouns!  Suddenly, absurdly classed systems become teaching examples exaggerated for effect.

This exaggeration also helps teach design patterns.  Here's an admission: I never got around to really learning design patterns until I had to in software engineering.  Up until then, I was using event listeners without realizing that they were a great example of the Observer pattern.  Java's ridiculous explicitness forces students to learn both the how and why of each pattern.

Regardless of how much OO is useful to the professional dev, it's good to know it.  One could almost make the argument that learning Java/Extreme OO at this stage will teach our hypothetical student why they're a bad idea.

The Big Questions

Steve Blank describes a startup as:

a temporary organization in search of a scalable, repeatable, profitable business model

This is the Big Question of any gathering of geeks in some semblance of a business.  They're assembling a product to see if it'll even work - and it seems like it takes forever to start getting that question answered.  It's vastly important to start getting external answers to that question early.

There's a lot more questions than the Big One.  Some are subsets (Will customers want feature X or Y?), others are external to the specifics of running a business.  We've stumbled onto quite a few questions, some even bigger than Steve's.  Some that have crossed our minds:

Can two guys in a technically-conservative city in a technically-conservative college create a startup, one of the most liberal tech things out there?
Is it even possible for first-timers to learn all the intricate parts of a startup and still succeed at some level?
Will we be able to take on an entrenched bureaucratic system that's resistant to change?

Yikes.  I could spend all day worrying about one facet of one of those questions.  Sometimes I catch myself falling into this trap (what happens if this was all a really stupid idea?)  Downward-spiraling negativity can be deadly to my productivity.  There's a counter to this - reading inspiring books/articles that push me onward to build.

It's also important to acknowledge these questions and try an answer them.  The whole startup process is designed to tackle Steve's question above, but there's other questions, most notably, "where are the facts?"  The key to remember is that there are no facts in the building.  As such, I went to interview two people in key positions in our target market.  I'm glad I did.  Turns out there were fundamental assumptions that we got wrong and it's time for discussion and pivot.

How can I do better?

I had a pretty rough/busy weekend and wasn't able to hammer out anything acceptable last night, so I'm turning the tables.  Recently, I got my 10,000th hit on Recoding.  Awesome.  Still, I'd like to improve.  Steve Blank is fond of saying that there aren't any facts inside the building.  So, in the startup spirit, I'd like to ask you guys some questions (you can answer here or in the HN comments, I'll be watching both):

-What are your favorite types of articles?  Is there anything interesting you'd like to see me write about?

-What sort of thing are you likely to comment on?  One of my big goals is to inspire life in the comments section.

-Overall, how can I do better?

What's taking you so long?

As I've alluded to earlier, a friend and I are working on building an MVP for a startup.  Awesome.  We've got the idea, have key connections in the industry, little competition, and are ready to tear into some code.  I had hoped to have the MVP finished by Jan 14th. so I could write about it here and we could start generating hype.  No dice.  We reset our due date to Jan 31st and hacked all weekend.  We got a LOT done, but looked at our to-do list and realized that it had grown.

Obviously, startups are not a walk in the park, even when life's handed you some great opportunities.  We seem to have fallen for the idea that code is trivial.  Technically speaking, the core of the product was implemented in November.  Since then, all we've done is build up awesome things around it (and school, both of us being full-time students).  We've learned a lot in the past few months.  Here's just some of the things we've encountered:

Stuff creep

This isn't scope creep, as the scope has stayed pretty much the same.  Rather, we find ourselves adding page after page to our todo list of things we never thought of that are must-haves (For instance, a user should be able to reset their password).  It's very important to know what done is.  Sadly, one can't determine everything at the beginning of a project, especially if this is the first time.  We've had some issues with figuring out what we should do next.  We're using Trello (an awesome site) to organize everything (have I mentioned it's drastically important to have a todo list?).  Despite the amount of planning we have put into this, there are still things that we completely missed out on.

Technical difficulties

We're building this with Node.js for two reasons:

• We only have to work with one language from start to finish (very helpful for first timers)
• Node.js is just plain awesome.

Still, various frameworks and asynchronous idiosyncrasies pop up and bog us down as we learn new things or fight back bugs.  It's very easy to assume that everything will work just fine the first time you write it, and schedule for that.  Make sure to allocate time for learning and fixing (most likely, you'll be doing more of those two than anything).

People difficulties

I'm an idiot.  We all are.  I'm sure even the best developers have confessions about how they've managed to shove some code through a trash compactor.  It's ok.  We all suck.  It'll slow you down but that's part of life.  Remember to take a break and eat healthy.

Regardless of above, we're not only still working on our MVP, we're accelerating!  Stay tuned for more updates.  Our latest due date is either March 1 or February 22, depending on who you ask.

What you shouldn't do as a boss: Complaints from the trenches

Today's post is adapted from a talk I gave to managers in training.  Even if you're not a manager, I hope that you too can pick up basic principles and help implement them in your organization.  If you're interested in hosting me for a talk, you can find me via email or @RecodingBlog.

My first job was with a small IT-turned-web-development company that accidentally developed a software division.  Most of the people there were playing at their jobs, using congratulatory back-patting to reinforce the idea of how "great" they were, instead of acknowledging weak points and moving to reinforce them.

They had an excellent market position but were slowly losing it thanks to the above reasons.  There's a life lesson here: If you are not pushing you and your team to excel, someone else will and you'll find that your customers don't have nearly as much loyalty as you thought they did.

Management has the biggest impact on the velocity of a team, software or not.  Here are five simple "don'ts" that can have a huge impact on team productivity:

Don't ignore workers

There was a very flat management structure at my old job.  Virtually all of the ~20 people reported directly to the CEO.  This made it very difficult to find direction.  While flat management styles seem to be all the rage nowadays, the studies show that managers should have no more than 8 people reporting to them or else chaos will ensue.  Even if you've got less than eight people reporting to you, make sure that you stay in contact.  I strongly recommend a weekly one-on-one meeting just to check up.  An employee that feels that they are heard is happy.

Don't demand perfection

Scope creep is a very real danger to any software project.  Yes, there are many cool features that your product can have, but there's a limited time.  In most industries, you're racing against your competitors.  The (unwritten) spec of my project was subject to the whim of the CEO and all changes must be implemented before we release 1.0.  The project has been going on for over 1.5 years and still is in development

"If you are not embarrassed by the first version of your product, you’ve launched too late." -Reid Hoffman, Founder, LinkedIn

Don't keep information away

We woke up one infamous morning to discover that the CEO had announced that we'd be developing a mobile version of our product.  Now, he announced it to our customers, and us employees were CC'd in.  Ouch.  How "the boss" communicates with employees says a lot about their attitude toward them.  Instead of CCing, become an information conduit.  Remember those one-on-one meetings?  Use them to bring relevant information.  Make sure you don't assume that an employee doesn't want to know something.  Asking only takes ten seconds.

Don't make status reports anything significant

I once got three requests for project status on the same day.  I don't know what management expected to change over my lunch break.  Status reports only slow progress, as the employee has to put time aside to write the reports.  Instead, use that one-on-one meeting (aren't these handy?) to find out what's going on.  Need more information?  Chances are, your team is generating a lot of data through commits, bug trackers and other useful tech.

Finally, don't let bored people quit.

The tech world brings about an incredible amount of mobility.  It has become incredibly important to nurture professionals.  I don't mean pampering them, but rather ensuring that they have the ability to gain new skills.  I've moved on from my first job and settled into a place using cutting-edge technology developing a product that's never been made before.  Needless to say, it's much more exciting.  An important, but oft-overlooked point here is to respect free/learning time.  It's very easy to override this as it doesn't produce anything short-term.

Being Programmers

Today's post comes from Ryan Kinal and touches on something very important to us here at Recoding: people who can't program.  Unfortunately, we have met the enemy and he is us.

A common source of frustration in the web development community is programming done by non-programmers. There is plenty of code out there written by people who have little understanding of data structures, efficiency, and architecture, and that can be frustrating to those of us who have some training in those areas. When we're hired to work with this kind of system, we wonder how the hell it could have gotten to be like that.

Why on earth would someone store all that data in plain text? Why is the login system a flat file? Why is this web service one gigantic file? Why is everything so tightly coupled? This is miserable!

The cause is, often, that the people designing and building the system just didn't have the knowledge necessary to do it well. Maybe databases were foreign to them. Perhaps they had never heard of an event-based architecture, SOLID and DRY, or even taken a class in Object Oriented Programming (or whichever programming paradigm you prefer). And even if there is knowledge of these concepts, perhaps the implementation of them is confusing or not intuitive in the current environment.

It is easy to look at this from a perspective of knowledge and experience, and say "Those people are not programmers." After all, these are fundamental concepts - essential to writing good code - and they have never even heard of them. I'll be the first to admit to thinking these kinds of things.
But here's the truth: If this kind of knowledge is essential to being a programmer, then none of us are programmers.

If we, as developers, are doing our jobs correctly and passionately, then we will always be learning. Just as Ryan from today looks back two years (or one year, or six months), and sees serious flaws in fundamental areas of architecture, design, elegance, and efficiency, Ryan two years from now will likely look at what I write today and think largely the same things. It's inevitable.

So, when you next encounter a bad piece of code, keep that in mind. Yes, it's frustrating, and I don't blame you for being frustrated. But keep in mind that it could have been a younger you writing that code, on a step to wherever you happen to be now. I would be unlikely to berate my former self, for fear of scaring myself away from the profession I sincerely enjoy.

Do the same for others.

About me

My name is Ryan, and I enjoy learning. I also enjoy teaching, though I don't think I could teach professionally. Like many others, I find that teaching promotes learning. Writing a blog post, such as my previous Object Oriented JavaScript posts, I have to think critically about the subject matter. I have to clarify it for myself before I clarify it for others, and that forces me to learn. I end up with a better understanding of the subject matter.

I've been interested in the web for a long time. I've written JavaScript for a long time, and can honestly say it is my favorite language (and I will likely write more on that subject over at Blogascript). I consider myself lucky that I have found a profession that allows me to be creative and expressive, allows me to truly own what I create, has such a great culture of teaching and learning behind it, and is considered monetarily valuable.

I'm one of three full-time web developers at McKissock Education, where I work with great people to provide professional education to those who need it. It's also where I met my partner in SlickText Text Message Marketing, my fairly-young startup.

When you have nothing to do

We're in the thick of our second weekend trying to bang out an MVP to launch our first startup.  It's harder than it seems (already).  There are tons of stuff they never taught us in class (proper password resets, for starters) that we've got to learn.  Node's modularity has helped immensely, having the ability to drop in a single module in to do a single thing is so useful.  I don't know how I developed without it.

Still, we can't slam a bunch of packages and Bootstrap together and call it a day.  We're building a quality product and there's still a lot of work to do.  Our problem is figuring out what work to do.  I'm sure those of you who could rattle off all sorts of nitty-gritty that needs to be done are laughing at us right now [0] but we're new and this is difficult.  Give us time.

I have found myself sitting down to get some more coding done and having no idea what I should do next.  Yes, we've built a to-do list.  We've had several mini-discussions where we determine what the next iteration will look like.  And yet, I find myself at a loss of things to do.

This is partially due to my resistance to lean into the pain and work on things I really don't want to do (writing a Terms of Service, repeating code just to add Yet Another Form).  I've had some success challenging myself to come up with inventive ways to refactor.  Some refactoring leads to security holes, but at least fixing those is interesting and we still end up with better code.

I alluded to our bigger problem earlier: We're first-timers.  There's a lot out there that can only be learned by doing.  One of those things is what to do.  I've found myself going to other sites that have features like ours just so I can see what features they've got.  It fills in a lot of holes in my knowledge.

Simply having something to do doesn't completely solve our problem.  Once we've got something, we're flooded with different ways to accomplish that task.  Most of the time there isn't a general "best practice" for everyone.  Instead, we're stuck with the ubiquitous "do what's best for you" mantra that almost never is followed by a discussion of the options and who they're best for.

We are stumbling in the darkness but at least we're stumbling toward something and that gives me hope.

[0] If you are one of those people, could you rattle off that list into a comment for me?

In defense of strong types

Anyone who knows my coding style probably thinks I'm going to completely contradict my title.  Nope.  I've found a new appreciation for strong checking [0], if only a little bit.  As it turns out, the additional security found in strong typing can be a cure for my least-favorite part of programming - those that absolutely shouldn't be programming at all but still managed to get higher-paying jobs than me.

Those in the strong typing camp claim that their method helps produce better programs, thanks to the additional compile-time testing.  This is absolutely true, and helped me find a handful of errors back when I wrote Java on a regular basis.  The trouble is, this extra security comes at the expense of language verbosity (ArrayList<String> stuff = new ArrayList<String>(); anyone?).  Being a liberal when it comes to programming, I prefer to have a concise language that allows for rapid prototyping and development.  This does create errors but not nearly as many as my CS Professor would predict.

Of course, this entire entry depends on strong typing being used exclusively as a sort of baseline test (My freshman mantra: "It compiles!  Ship submit it!").  It's not, I know.  Compiled, strong languages do have significant speed improvements over "lesser" languages like PHP (Others say that speed of language usually isn't nearly as important as speed of development).  However, strong typing does act as a rudimentary test.  Whenever a variable is declared, there's a "test" to ensure that it's correct, otherwise ERROR.

Liberals argue that this provides false security.  "How can we tell if the variable's value is correct, not just the type?  We need more tests!"  In either case, more tests are needed.  If you're building something significant, you need tests.  Liberal programmers are free to throw caution to the wind and depend on their own tests, claiming that the time lost to writing tests is made up by writing in a simpler language.  (I haven't found any studies to back this up, I'd love to hear it if you've got one).

So far, I agree with the hippie liberals.  It's much better to write your own tests to determine what's going wrong.  Who knows your code better: You, or a compiler?  Using strong typing for testing purposes also breaks separation of concerns, but that's a nitpick.

If you can't tell, I don't really like strong typing.  Oddly enough, I also don't like it when a program doesn't fail on what should be an error, but continues soldiering on with weird results.  (thank heaven for 'use strict';).  Back to where I was: People who get paid more than me to write terrible code.

It's a sad reality that there's a huge amount of terrible code out there.  A large portion of this code is glue between several plugins mashed together into a "website."  Scary.  However, strong typing (thanks to that very breaking of separation of concerns) forces basic testing onto whoever is using the plugin/API. The "programmer" (and I use that term loosely) must provide semi-correct data.

Of course, those who write glue code are looking for the easiest plugins to steal use.  Ones that force them to provide better code will be dumped by the wayside by both glue coders and higher quality coders with liberal leanings, so this is mostly a pipe dream.  (Conservative coders will already be working in a language with strong typing.)

So strong typing is bad because it forces you to write extra code that amounts to more tests that you'll have to rewrite anyway.

[0] In this case "strong typing" means that the language gives an error if a variable is of a type that wasn't expected.  This means that the programmer