Showing posts with label language design. Show all posts
Showing posts with label language design. Show all posts

Wednesday, January 18, 2012

IT going backwards - Objective C is 90s retro

I've ranted quite regularly on how Enterprise IT just hasn't really developed in the last 5 years and my personal task for 2012... learning Objective C and programming for iOS has taken my disbelief to another level. Back in 2008 I learnt Python and for me it sucked. Its 'advantage' over scripting languages of the 80s and 90s was minimal and it had the most hated (for me) of things... indent sensitive code. Objective C however really has stepped it up a level.

I remember learning Ada, C and Eiffel (along with bits of LISP, Prolog, Assembler, etc) and most of all I remember being confused as to why people like coding in languages like C, where the syntax is terse bordering on emo, over languages like Ada where even non experts can have a crack. Through my career people have claimed the stupid 'less characters = language efficiency' which again matches up by saying that Martin Luther King was a crap communicator while a grunting teenager is much more efficient.

But all of this couldn't prepare me for the horror that is Objective C. SIGFAULTS in 2012? Seriously? Have years and years of exception handling been ignored? No even better than that... Objective C has exceptions but you are discouraged from using them, yup they are there but are 'resource intensive' so you shouldn't use them.

Second off we've got the wonder of memory management again, although now with 'ARC' it actually does some garbage collection, yup folks its 2012 and Apple have just caught up with the mid-90s.

All of this is annoying, and rubbish, but that would be nothing if the language had a nice syntax and logical way of working... but Objective C is like people have looked at Java, C, C++ and then sat down and though 'how could we make this really suck?'.  Yes its the same old .h/.c (or .m in this case) combination of header and code but just basic things like function calls are made excessively silly.  No simple .(, ) for Objective C... well not always, sometimes and you can do it but not normally... ahh consistency avoidance always a great way to have sucky code.  No in Objective C you call a function like this
[instance method]:param1 param2:param2
This means you end up with wonderful code that looks like
[[[eventHistory getEventAt:location date:date] calculateDistance:newLocation].doubleValue
Notice that '.doubleValue'?  Yup when using NSNumber (object for doubles) you use the old '.' notation. Perfect eh?

Then we have XCode, an IDE that seems to crash if you do anything it doesn't expect rather than a warning saying 'Fail: you didn't mean to do that'.  Some bits are nice, like some of the code generation and some of the bits, like refactoring, are pretty much up to Java IDE standards from 2001/2002.

The layout model in XCode is okay, with some nicer bits around chaining screens but seriously is it that hard to implement XmForm?  With the multiple display layouts that you get with mobile devices it really would be a cracking layout manager to have.

Then we have the iOS simulator, its great, except if you want to simulate locations that Apple hasn't thought of... the 'accuracy' if you use custom locations (for instance if you want to test something using European locations) is 150,000m... or to put it another way... a level that every decent piece of code should ignore.    Application development speed wise I'd clearly be faster in Java, but as a new language I'd say that Objective-C ranks behind C++ in terms of 'complexity' to learn and ranks significantly behind both C and C++ in terms of language efficiency.

But that said the example code pieces are good and the online manuals are good as well and I knocked up the second stage of my application on a flight across the Atlantic.  Basically however it feels like using C++/Motif with Emacs and the TeleUSE UI builder.  Its 2012, shouldn't it feel like we've progressed?  What it really feels like is some sort of retro homage to the 90s wrapped in a shiny and expensive new package.

From now on I'm only coding for iOS while listening to an iPhone playlist 'Songs of the 90s', it helps get my mind in the iOS Zone.

Technorati Tags: ,

Sunday, May 11, 2008

Green IT - save the characters

Around JavaOne there was a lot of buzz around Java becoming a bit bloated. Now I've argued for a long time (including in the dreadful JavaSE 6 group) that Java should have a basic core and then architects should be able to decide on the extensions they want for their project. So the issue with Java isn't the bloat, its the process by which the JCP and (from experience) the Sun JavaSE team want to add more "features" into the language.

But the thing I really don't get is the obsession with the "new" languages on using the character saving, comprehension limiting syntax of C. Back in the wild and crazy 80s the focus on language design was as much on the syntax of the language as it was on the semantics and function of the language. In the 21st century we seem to have abandoned that strategy in favour of a "lets just use similar syntax" approach.

Take Scala


/* Defines a new method 'sort' for array objects */
object implicits extends Application {
implicit def arrayWrapper[A](x: Array[A]) =
new {
def sort(p: (A, A) => Boolean) = {
util.Sorting.stableSort(x, p); x
}
}
val x = Array(2, 3, 1, 4)
println("x = "+ x.sort((x: Int, y: Int) => x < y))
}


(stolen from the scala site)

What is this some sort of Green IT campaign based around the idea that characters are in short supply and should be rationed? This is the homepage example of the language.

# The Greeter class

class Greeter

  def initialize(name)


    @name = name.capitalize

  end

 

  def salute


    puts "Hello #{@name}!"

  end

end

 

# Create a new object


g = Greeter.new("world")

 

# Output "Hello World!"

g.salute


From the Ruby homepage.

Seriously do these really represent the sort of syntax that will help more people adopt the language and make support of the programmes developed in that language easier? My money is on no.

Here in lies the problem as pointed out by Jim Waldo (via DanC).

there is still the worry that engineers who aren’t producing code are not doing anything useful.

And this is where I think the focus on a limited syntax comes from. Its the certifiably insane idea that the time taken typing in characters is the sort of time that needs to be reduced. The reality is that it is the time taken to read someone else's code that is the primary problem especially in larger systems. The focus on limited syntax and on saving a couple of characters is nonsensical in a world where the number of developers is increasing and the complexity of systems is increasing at pace. It also isn't the sort of approach that helps in making sure that the code from the majority of developers is of a reasonable quality and can be easily maintained by other majority developers.

Scala won't be Java 3, Ruby won't be the next Java. Java might have problems but solving them by having an even more obfuscated syntax is not the way to make the languages an operational rather than a blogsphere success.

Unfortunately part of the problem is the lack of professionalism and engineering in IT which means that there is a huge body of opinion that rates the quality of a language based on how few characters it takes them to write the code, not on how many minutes or hours it takes someone else to understand them.



Technorati Tags: , ,