Be Excellent To Each Other

Just had a TREMENDOUS iPhone App idea. For reals and everything.

And most basic needs to show a pictures, an animated gifs or video clip, then more pictures and so on. With overlayed text in a nice font. All my programming has been hacking complex physical models that just output text files as they run, so this would be a big stretch for me. Haven't used C++ for yonks either. And it uses some weird version of C too.

But I fancy giving this a go.

Anyone else developing an iPhone app? Any hints? Fancy trying together?

Downloading the xcode and the iPhone SDK (3.2, which might not be worth it with 4.0 round the corner) now.

How long will my enthusiasm last?


I wonder how easy it is to embed google maps in an app.... hmmm....

You should probably find that quite easy, Objective-C takes some getting used to but seems to make sense once you get a grip of the syntax.

I've not quite got to that stage yet, mind.

I'm currently developing a couple of games with iPhone SDK and cocos2d-iphone.

I would love to join your project, but I'm afraid I'm a bit too busy at the moment. For what it's worth though, Objective-C seems to borrow heavily from C's syntax but also borrow from Smalltalk's messaging.

Anyway, good luck - if all else fails, you could use HTML 5, JS and CSS which is what Jobs has been bleating on about as the ideal development platform.

I genuinely want to create my own iPhone/iPod Touch app, and have for a few weeks now. I'd be absolutely thrilled if I could accomplish that. I suppose it's not vaguely plausible for a complete beginner, though?

I pretty much am. Hacking physics into code, is very, very different to being a programmer. And I'm giving it a go.

You only need to pay the $99 fee, if you want to submit the app to the Appstore (or to be fair put it on a real iPhone for bug testing), so you've nothing to lose).

Boingboing has some free access to "Make your own games for iPhone" books at the minute.

Can I admit that I've never learnt programming before? Does that totally rule this out as a possibility?


Is this boingboing.net that you speak of? Would the documentation be aimed at beginners?

Also, you need a Mac to do the programming on.

Being totally new to programming doesn't rule it out as a possibility (and indeed, you may be in a better position than someone who's been programming in the same language for so many years that their brain finds it hard to take on board a new type of language and syntax) but I'd definitely recommend a few books:

Learn Objective-C on the Mac
Beginning iPhone Development: Exploring iPhone SDK

Objective-C is nothing like C++, which is good news for most people. If you are already comfortable with C and familiar with object-oriented programming, Objective-C is very easy to learn. If you are NOT a regular C programmer, it may be quite hard to understand, as it is basically two completely different mindsets smashed together into one programming language.

I would love to join you in learning how to do iPhone apps, but I am sadly not able at the moment to find the energy or time to do hobby programming after work/in the weekends.

That's exactly what it is. It has things like duck typing and dynamic class extension, even of base classes like NSString. Many Java, C++ or C# coders find that rather jarring as they are used to very static compile-time class definitions. Personally, as I've also done quite a lot of Python and Perl over the years I don't mind so much (although I do find the [class methodname argument:value] syntax a bit hard to read still).

App to jump?

That's easily the bit that confuses me the most at present, I'm too used to class.methodname(value).

Wait - so instead of woman.giveBirth(boy), it's [woman givebirth sex:boy]?

That's really quite unpleasant.

Do iPhone Dwarf Fortress. I dare you.

*runs away screaming*

No problem! I have a tradition of being Mac owner, since quite a while ago. Before the iPod and iPhone existed.


Well, I'll investigate further. If (as is unfortunately likely) my girlfriend's university doesn't have either in their library I'll... ask someone.

I've said here before, but I really want to learn to program, but the entrance 'in' to the skill seems impossible to access. In a metaphorical sense, natch.

What's more worrying, of course, is that a lot of programmers nowadays, brought up on languages like PHP, Java, the .Net suite and the like, don't actually understand type-safety or why it's useful, why things like duck typing (and latterly called) "dynamic languages" were invented, let alone how the actual hardware works.

I like abstractions because they make my life easier. I understand why they're useful, but also what the underlying hardware is actually doing (well mostly - I'm not about to write a compiler for a multi-core system, except there's at least one PC in there and multiple registers).

I've had this conversation before with people (who I think should know better!) who claim that it doesn't matter, that the tools should compensate, that programming isn't about bits and bytes any more and these abstractions enable non-programmers to program. Complete rubbish if you ask me. Without a decent grounding in how a processor works, what it's actually doing and why things work the way they do all we'll get is a whole bunch of new Visual Basic'ers.

For budding programmers I recommend downloading and tinkering with an old school processor emulator and assembler (something like the Z80, 6502 or the 68k). Play around with that for 6 months or so and you'll become a better programmer than you can possibly imagine.

That's exactly how it is. I don't mind, but I do find it distracting. This isn't just Apple contrariness; Objective C dates from 1986, so is only three years older than C++, and from a time when the C-style round-bracket curly-brace syntax was just one choice amongst many.

It's extremely hard to teach yourself programming, and there is no right way to do it, or right language to choose. You need a lot of dedication though.

Uhh, seriously?

Seriously.

I would mainly agree.

I don't disagree that anyone doing this would come out a strong programmer, I just think the attrition rate would be so high it'd cripple the industry, and practically no hobbyist's interest would survive that. There's a place for even the most weenie of VB wielders in commercial programming.

Probably.

But you won't write better programs.

/bows

Teach yourself VB. We could do with a VB geek at work.

Learn Perl, and come and work for us! Perl's awesome, honest.

You still won't have any idea what duck typing and overloading prototypers means though, and that's what counts these days.

This is why I've never managed to learn any OO language - the human language attempting to describe it is bloody awful and makes no sense and is impossible to remember.

If you learn Perl, it'll be easy to switch to something like PHP afterward if you want to get a job or something

It's from a quote, innit?
"When I see a bird that walks, swims and quacks like a duck, I'm going to assume it's a duck" or something.

And if it floats it's a witch?

It's no clearer, sorry!

Unless the Reg has been misleading me, doesn't writing an app for the iPhone mean that you have to not only sell your soul to Steve Jobs, together with all patent rights to your DNA, but you have to let him come round your house and shag every female relative, ex-girirlfriend and your current partner in your bed and then wipe his cock on your curtains?

To be honest that seems like a bit too high a price for some boredom-diverting pictures on a phone.

Given some of the things I've seen by people who didn't understand what they were asking the hardware to do with the code they'd written, I strongly disagree.

If you give me two candidates for a junior development role, one of whom has done a standard computer science BSc mostly in Java or C# or some other OO language, and the other has spent the same amount of time working in 68k machine code, maybe moving onto some x86, and perhaps some C to finish off, then I'm not hiring the machine code guy. I get what you're saying Dave, but those skills are such a tiny part of modern enterprise programming. Very few people are writing renderers. An awful lot of people are writing XML wrangling middleware layers.

I'm not too sure you do get what I'm saying. For instance, I've come across both c# and java programs utterly bogged down by the writer not really understanding what he was writing was doing at a lower level. Hello constant garbage collection, hello time spent boxing/unboxing, goodbye speedy program. (Admittedly, this is made worse by the fact that I've mainly dealt with Mobile java and the compact .NET framework for java/c#, which have a lot less grunt to offer uncareful programmers, or ASP.NET, where again, shit programming has the potential to screw a server fairly well - I learned that one the hard way. Did a website to provide the mobile application that I'd written, I thought itwould have a load of about 1,000 odd users, only to find that it got advertised on the BBC and got about 100 times that many. Part of it keeled over fairly quickly.)
I'm basically arguing that knowing what you're writing isactually doing is very much a good thing for being a decent programmer. When learning c#, I made sure to have a good understanding of IL. Not because I was ever expecting to write it (In much the same way I rarely use asm anymore) but because it has quite significant benefits in making sure the code you write is good not only from an understandability point of view, but also one of efficiency and security.

Much of the programming we do at the moment is probably stiching various libraries together, and and extending and adapting them slightly to fit what we need. Not much nitty-gritty hardcore coding goes on.

Garbage collection and boxing/unboxing has nothing to do with hardware or assembly language, though.

No, which is why I was quite sure he hadn't understood my point - it's not about assembly as such, but about knowing what the code you're writing is actually doing under the hood once written. With c++, that's knowing the assembly output (and believe me, knowing assembly here can really help when an obscure bug comes up), with c#, it's the il output, which often contains a fair lot you're not expecting in terms of box/unbox instructions and similar. and if you don't know what's going on, you can find Mr Garbage collector comes along to shit on what you're doing because you're unaware how much you're actually creating.

Slight fix



They are slightly different disciplines, but confronted with a choice of two candidates one who has only used higher level languages and the other has spent time with machine code, C and higher level stuff I'd almost certainly go for the latter.

For one thing it would stop the sorts of idiocy I see all too frequently - such as programmers loading 100's of megs worth of text files into variables - but also because a lower level understanding of the machine often leads to more efficient high level code (and that even applies to languages that get compiled intermediate code).

I'd agree with that, but I'd say that if it's a choice between one or the other for an average dev role, you're probably better off going for the one with the higher level OO experience.. Most of the server crippling slowness I've seen is due to daftness at high level design rather than mis-judging garbage collection. You don't need to know about machine code to know not to put a time-consuming function inside a loop if you can avoid it, but that's what happened haf the time.

I'd take the OO chap. Soz, hackers.

The other side of the coin, of course, is the programmer who produces unreadable code due to misguided "optimization", because he believes his code produces superior machine code, when, first of all, compilers these days can do much better automatic optimization than most programmers, and secondly, the code in question wasn't a bottleneck in the first place.

I used to belong to that category of programmers, before I got my CS degree, and I would say it held me back rather than aided me. I now treasure my knowledge of CS theory infinitely more than my experience with assembly language.

I far prefer readable code that eloquently expresses the logical content (to the human reader!) than some garbled mess that someone felt "cut to the metal".

And I think producing code that trashes the garbage collector or trying to load everything into memory at once is more to do with being generally inept than not knowing what goes on under the hood.

By the way, taking a CS degree also involves learning about RISC/CISC assembly, operating systems, network protocol stacks, garbage collection and so on.

I utterly lash in huge amounts of cowboy code to get things done. I bet I've still got more stuff up and running and doing the job it was written for than most full-time coders though.

I have to say, though, that since I did have years of assembly language/low level experience before learning the more abstract ways of thinking, I don't actually know what the world of programming looks like for someone who doesn't. Moreover, all the really great computer scientists all had similar low level experience, what with them actually building the first computers and writing their operating systems and whatnot. So maybe that sort of knowledge actually is a prerequisite to being a really good programmer.

Always begin by declaring your variables. I suggest starting with "Good programmer".

Getting stuff up-and-running is only the start of the battle; things really start kicking off when the inevitable change requests come along. This is what some aspects of OO (dependency injection, IoC containers, enterprise patterns etc) try to solve, the intent being that new functionality can be added to a system quickly, cheaply and without breaking existing functionality.

When you start off with a Butch Cassidy foundation, over time this becomes more and more difficult. Hacks get built upon hacks which get built upon other hacks. Eventually that festering code base becomes completely unmaintainable and the whole thing needs to be re-written from scratch.

HELLO MY WORKING LIFE



Joy.

Yup. We call that "a production environment".

If there's one thing I've learned from working, it's that there's always a better way to do something, and if you spend too much time trying to get it perfect from the beginning, you'll never get it done.

“If you're not embarrassed by V1.0, you didn't release it soon enough.”

What I dislike also, though, is when things go too far the other way. A previous architect on my product believed comments were evil and all methods should be no more than half a dozen lines and all objects should be instantiated through factory methods. Trying to quickly scan through some seemingly simple code to get a feel for how it works takes hours longer than it should because it's just so damned fragmented over dozens of namespaces and hundreds of generic interface classes, each with a single implementation behind them.

The real evil with all programming is unthinking dogma. I can't think of a single rule that applies in all circumstances.

That reminds me of something, that same architect wrote a centralised logging app with stupid SQL in it that doesn't scale[1] and a ridiculous multi-database architecture[2]. If there's any area of modern programming where you benefit from understanding the underlying structures below the language you're typing in, it's databases, not IL or JVM bytecode or the like. Java and C# and the rest don't do a perfect job of hiding the machine from you, but they're a lot better at it than SQL is, and you won't get caught out anything like as often wonder why something doesn't work.

[0] he put the zipped XML logs for a session into a BLOB column alongside the log data in a single table, meaning when you do reindex operations the server has to table scan through the BLOBs. We never index on or search on the contents of the BLOBs, just the metadata columns, so he should have put them into a secondary table and just kept a foreign key in the main log table.

[1] app server needs to log something. We don't want the database to be a central point of failure. So it maintains a list of log servers and uses them in turn for failover and round robin for load balancing. Each log server consists of a tiny JSON web service and a MySQL instance. Now, this is the critical bit: each log server only logs to its own MySQL. So if someone does a dozen things in one session, the log entries are scattered over the three servers. The "show me log entries" webapp polls all three servers and stitches the session together. This means I cannot run a simple SQL query against the database for more complex queries and performance stats have to be evaluated against all three servers.

I can't take advice from someone who tries to mix zero indexing with non-zero indexing in his footnotes.