Make a business app without writing a single line of code

If you’ve been here before, you know that I always express skepticism when I encounter this kind of claim. But when someone like Scott Hanselman tweets it, then I pay attention and will give it a shot. That’s what I did and here is how it went.

I visited the site, followed the link to create an app, picked a template/example and simply accepted all defaults. I chose to download the source codes. Within about 3 minutes I had three apps downloaded to my mac. The web site looks clean, it’s easy to follow.

App Control panelApp Control panel

There’s an option to download the fully built and ready-to-go app.

Trigger app build process App's being prepared for download Download your app

When you install the app, you get something that is really basic but functioning.

login view

main view

I then loaded the iOS version on Xcode to take a look at the source code. Browsing around I saw a source tree that is reasonably well organised, clean, simple and straightforward. You see that it doesn’t have much feature. I wouldn’t call this a foundation to base anything evolved on, but the basic hierarchical navigation views are in place.

Sample app in Xcode

I tried to build from Xcode and straight away the code wouldn’t compile. I saw there were missing dependencies, could try to solve that manually but decided to use cocoapod for that (everybody does these days). Indeed the presence of podspec file was another give away. After refreshing the dependencies, the code still wouldn’t compile, the Test target failed. So I deleted the Test target, then the code runs. I couldn’t be bothered to spend much time on this.

There’s also Android and Windows app source codes available. I didn’t take time to go through those, but I expect they would be similar: basic structure, quick and easy, but not much feature to see. To be honest, the basic app structure created by Xcode would be much like what you get here, one benefit is that through the theme feature of the web site, it’s possible to make it a bit more proprietary and get going.

Brief summary

For a beta service, this looks like a good start. It certainly will help people who just need a decent looking prototype to get started. The concept of App Builder, aiming at people who don’t want to write code, seems to be in motion. I’m not sure how much success they’re getting, but it is worth checking them out regularly. There might be situations where even a professional developer would want to get something simple out quickly, particularly throwaway ephemeral apps that are not worth over-engineering. This one looks good for that kind of purpose. For more elaborate needs however, writing code is still going to win the day.

To write good code, you need to think carefully about what you’re trying to do, what the context is and what the constraints are, then design a solution that cater for those things.

This is really about mechanical sympathy

Damien Katz blog post about C programming is interesting. It has a number of funny quotes, typical of programmers, any experienced developer would benefit from pondering them.

Here is the article: The Unreasonable Effectiveness of C


Tetris point is where everybody is making the same claims

I read a huge amount about information technology, of which I see a lot of open source code. The more you do that, the more you see something of a pop culture across the board. It’s just like fashion, everybody talks about the same thing. Everybody is (seemingly) doing the same thing. It should perhaps work a bit like the game of Tetris:

  • Our technology is built with performance and simplicity: strike!
  • My open source library is fast and lightweight: ka-t’ching!

If you never see anything else, it may be time to move on to something new.

Good essay by Bret Victor, but he’s got one thing wrong in the opening chapter

I read Bret Victor’s latest essay, it’s very good. But he started off by refuting one argument, which I think he’s got the wrong end of.

In the opening section Bret quotes Alan Perlis as saying that “To understand a program, you must become both the machine and the program.”. Then Bret adds in the same sentence:

This view is a mistake, and it is this widespread and virulent mistake that keeps programming a difficult and obscure art. A person is not a machine, and should not be forced to think like one

Yes, it is quite obvious that people aren’t machines, but that is besides the point. I think Bret got that argument completely wrong for a simple reason: if two persons don’t speak each other’s language, there is no common ground to hold meaningful discourse on. When a person writes a program, they are effectively engaging in a future discourse with a computing environment (computers, operating programs, and everything that defines the operating context of the program being written). So if this person has no idea what his/her writing (code here) could mean to the computer it is destined to run on, then the outcome is uncertain and bad things are more likely to happen. What makes programming difficult, to learn and/or practice, is the fact that people are dealing with infinitely more complexity than they think or assume that they are.

Alan Perlis wasn’t trying to be pedantic, which some people clearly are when they drivel on esoteric things in order to mystify others as a way to show off their skills and expertise. That is not what Alan Perlis was doing, Alan was simply saying that unless someone is truly aware of what  they are getting themselves yourself into, hence the metaphor of embodying those things, that person can be almost certain that bad things will happen. And that, I think was a sound judgment. Perhaps the prose could be different and more elaborate, elegant in the way that Bret himself writes, but that says nothing about the real content.

Learning about programming is difficult because the student (let’s call it that) has no idea what to expect. Some programming languages become popular because they simplify and reduce the amount of concept that the student needs to learn. Other programming environment, C language for example, are complex because virtually on each line one could be easily making several mistakes and it takes a long time to learn them all and become proficient with it.

So, the programming student is typically going to start off on a bias that is determined by the context where the learning is occurring. If the teacher isn’t good, the teaching will suffer and eventually that student will go off and spread misunderstanding further on. The complexity is compounded by all the human factors that typically add up over time. This isn’t anybody’s fault per se. It is a wicked problem, it starts off as a problem of appreciating the true mileage that lies ahead and how one’s own lung and leg capacity would fare in the journey, to use a sporting metaphor. I think that is What Alan Perlis was probably referring to and I think he was spot on. Bret is wrong in this case.

Having said the above, Bret’s essay is quite brilliant, a league above what we can regularly read on the topic. Kudos for his clarity of thought, and the generosity of spreading it out.

If you are into this topic, you would do very well to read Bret’s essay on his blog:

Getting serious about programming, I mean Clojure

I’ve never been far away from programming over the years. Last three years definitely saw a significant change in my habits, instead of simply analysing the architecture of some newfangled technology I found myself spending more time and enjoying writing code. It used to be that, after a couple of lines I’d be already bored to tears and often moved on swiftly to something else. I didn’t care because it didn’t matter that I’d be an expert in a particular technology, I seldom claim to be an expert in one technology. When a user issue arose, I am usually able to do my bit or could count on someone who’s the programmer on the job.

When I decided to reorient my career, I went back to some earlier loves, being creative, try and crack difficult technology problems, build and ship solutions myself. One by one I opened up my archives looking for something useful, my exploratory paths took me to my university thesis dissertation: implementing TCP/IP stack on an X.25 network. I was shocked to see that my memory of that stuff is still fresh like it was yesterday, what a shame I didn’t carry on working on that stuff. Then, I realised that actually what I’m doing is only a continuation of those earlier efforts. So I thought, let’s find out what the cool kids are toying with and why they think it cool.

Rediscovering functional programming sort of reignited some long lost buzz. Over last years I learned (or re-learned) to program in OCaml, F#, Lua, Haskell, Erlang, Python, Scala and Clojure. Ruby and Rails framework have been with me since 2006 but they never really became a passion. Of all those languages, Clojure is the one that seriously grabbed my attention and retained it for a long stretch of time. I’m discovering the reason that happened every day.

Suddenly I started writing code by thinking naturally about how I would go about solving a problem, with little or no infrastructure stuff getting in the way. What’s more, some times I’d think of a problem and a solution direction, then imagined that someone must have already solved that, set out to find out and I’d usually come across a code that’d be just like I imagined it. I thought mathematics was the most beautiful thing I learned during my study years, I didn’t get a career in Finance but I didn’t realise that that subject would come back rushing in my life. With functional programming it is sort of happening, though I’ve not had to resort to anything complicated yet.

If you read this blog then you probably know that I think that “laziness” is a good attribute for a programmer. Few things thrill me more than finding out that there’s code I don’t need to write. Scala is good, but it’s got too much Java in it and it’s not beautiful to read. Clojure however is just a superb language, and I like the way I don’t squirm at someone else’s code. ClojureScript is the icing on the cake, it makes end to end internet solution crafting a joy.

I am not suggesting that other programming languages aren’t good or anything, I am only saying that Clojure has become my favourite programming language.

Java is the new Cobol, of course. How else can it be? Enter Eclipse Xtend.

I just saw an announcement of a new programming language from none other than the Eclipse group, you know of the Java IDE fame. A very quick scan of this new language, called Xtend, it looks like they’ve borrowed a bit from Groovy, something from Scala and maybe something from CoffeeScript. The fact that this language is directly supported by Eclipse IDE is a huge advantage, and that may be to the detriment of Scala which still hasn’t got a great IDE support yet. I think this move by Eclipse may also be a preemptive strike against JetBrain’s Kotlin. If the community picks up on this then I expect initiatives like Redhat’s upcoming Ceylon programming to struggle in gaining any foothold.

I’ve been wanting to write a post on how I thought Java just wasn’t good for programmer productivity, seeing this announcement encouraged me to finally post it. I did something with JBoss Seam a few months back, took a step back to look at the code and thought to myself what a waste!. I can’t believe anyone in 2011 would want to create new code using JSF for example, it simply feels wrong.

From the moment that I renewed my focus on functional languages, I find pure Java code to be an eyesore, the web tooling around Java are simply atrocious compared to what you can do with functional languages like Ruby, Clojure or Scala. Clojure way well be the most elegant of the lot, I like it so much that I’m increasingly considering doing more hacking than I’ve done in years.

Competition is a good thing. But I’m wondering if Xtend is a more of a Groovy clone and if that could be such a good thing for the wider programmer community. I haven’t written a single line of code with Xtend yet, this is just a spontaneous reaction, in fact a post I had drafted about Java as the new Cobol, but refreshed in the light of this announcement by Eclipse.