Code Density and readability problems

I know this is a highly contentious issue and many people will be angry about me bringing this up. But I’m going to do it anyway, because I believe it’s important. You may not agree with me, but I request that you try to understand my point of view because I have tried to understood yours and I’ve provided a counter argument below.

In my opinion code readability and code density in Xojo is unnecessarily high because of the lack of common operators in the language. Yes, I’m talking about: ++, --, +=, -=, *=, /= and whatever else I’ve forgotten, with the exclusion of heavier operators like <<, >> which I don’t think belong in the language.

My Argument

I will say that i++ is shorter, easier to write and easier to understand than i = i + 1. This is especially true in nested loops and for variables with very long names: Car.Engine.Piston.Width++ instead of Car.Engine.Piston.Width = Car.Engine.Piston.Width + 1. If you have to do this often enough in your program it becomes a very dense thing with a lot to consider. You must ask yourself “Now is this just an increment, or a more complicated operation?” If I see ++ I can stop reading - I know immediately what it does. With the alternative, I have to read the entire equation to figure out what it’s doing. This makes processing code without the operators harder for me to understand and more likely to produce logic errors. It’s also very ugly and contributes vastly to code density, because everything is twice as long as it needs to be.

Opposite argument

Now I understand the argument of the other people here who hate these other operators. They say that:

a) You don’t know what the operator does until you read about it, making it harder for new people to learn

I disagree with this point because this is simply the nature of programming, and it doesn’t stop there. As a beginner you have to go and read up on a lot of things including the various data types, the differences between a for loop and a while loop, what a class is, what observers do, and so on and so forth. These are all more complicated concepts than a ++ operator. Now if I have to look up all of that and understand these concepts, how will a lack of a convenient operator help me? It won’t. It just limits everyone else because of some imaginary beginners.

Beginners aren’t idiots, and programmers aren’t idiots. A ++ operator doesn’t transform a piece of code into rocket science. The truth is that if someone can’t go and look something up then they won’t get far with programming in general.

b) I don’t want to use it!

Ok, you don’t want to use it. That’s ok, you can still write it how you want. It’s the same as many things in life: Live and let live. You don’t want to drive a motorcycle? Ok, don’t drive one. You don’t want to write ++? Ok, write it the long way. It’s your choice. But just because you don’t want to drive a motorcycle doesn’t mean that nobody else shouldn’t be allowed to. That’s a form of extremism. Xojo wants to be an inclusive thing, not something that forces a dogma onto people. If it does, then that’s something very toxic that will hinder Xojo from ever becoming a more popular language.

c) If these operators were in Xojo, I’d have to read your code!

Nobody is forcing you to read my code. I don’t have a gun to your head. You can choose to read my code or choose not to.

d) ++ and += etc are not intuitive to someone with 0 knowledge!

Like I said before, neither are loops, classes, observers and datatypes. These are things you have to look up.

e) Adding these operators will lead to incrementalism. Next thing you “You added those, so why not just add ___ too”

This point has a little more merit to it. I agree with it, I guess. But I think it could be mitigated against. Xojo has to draw the line in the sand at some point. I think the line is this: as soon as someone wants to start manipulating bytes and bits, then they should go and get themselves C. But we aren’t talking about low level manipulation here. We’re talking about shortening a normal expression for readability’s sake - a good idea, hence why it’s so widespread.

f) The biggest downside to adopting any of the -=, +=, /= *= operators is that they break backwards compatibility

A valid point. Easily refuted, however: Xojo is constantly evolving. At some point old code will break no matter what.

g) I don’t want to write C syntax!

C had good ideas. It was written by Dennis Ritchie, someone I consider to be a genius. It’s simply foolish to throw away good ideas because you don’t like their origins.

h) My brain stops working when I see this stuff!

…What? Ok. Just write it the long way then. Limiting the rest of us because of your problem isn’t fair.

i) Xojo’s customers aren’t the kind that want this type of stuff!

Wrong. Many people want this. Especially everyone coming from other languages.

Maybe I missed a point that someone brought up. If so, you can write it below and I’ll consider it. Maybe you can even change my mind. This thread isn’t some mindless or offensive trolling. It’s for level-minded discussion. If it becomes locked then I would certainly see Xojo Inc in a different light. I don’t see any reason for anyone to be angry about this, actually. Anger has no place anywhere. It’s just childishness.

  • Your mixing two things in your example: augmented assignment (i += 1) and the increment operator (i++).
  • Augmented assignment could fit into the Xojo language, but surely not the increment.
  • Is augmented assignment necessary: no (actually a big NO). And I’m a C programmer… What I like about Xojo is that there is almost no punctuation noise (besides being cross-platform).
  • File a Feedback request and …
  • … leave it to Xojo Inc. to decide if they want to implement it or not, because discussing it here won’t change it.
  • Choose a different programming language - I say that because you seem to be very upset…
  • …and calm down.

Not mixing. I like both augmented assignment and the increment operator. I’d be happy if the increment wasn’t there but at least the augmented assignment was there.

I can’t file feedback requests. It’s already there and been locked beyond consideration, hence why I wrote this post instead. I think a “Never!” is not a good answer. That’s what I’m unhappy about.

In this case necessity is a matter of opinion.

I like Xojo, make no mistake. In fact, I love Xojo.

For what it’s worth, you can extend the integer, and other, classes

For example-
Add a module to the project ( any name )
Add a method…

Sub AddThis ( ByRef Extends value as integer, amount as integer ) value = value + amount return

Then just use…

dim mynumber as integer = 0

mynumber.AddThis(1)

Those operators hinder readability for many of us… More than a few came to CrossBasic/REALBasic/ REALStudio/Xojo because they did not find C type syntax readable.

In any case no matter what the language, long term readability is helped by obviousness and explicitness. Also readability and code density are best dealt with by making good use of whitespace.

Xojo addresses human beings needs. C forces human beings to think like machines. You may like being a machine. I do not. Switch to C and stop asking Xojo to become C.

Thank you :\

I would want “variable++” to be usable only as a complete stand- alone line (or the entirety of the “then” or “else” in single-line if statements). That said, I wonder if TextExpander or one of its competitors could be set up to auto-expand those operators…

This could be done with an IDE script to change +=, -=, etc. to standard Xojo syntax before you compile if you really want to write it like C.

I would accept adding those as a feature (once EVERY OTHER MAJOR BUG … ESPECIALLY THE RANDOM CURSOR JUMPING IN THE IDE IS FIXED)… as in when Xojo engineers have nothing better to do… sure add those…

I however emphathically disagree with the statment

Dense… not at all… a bit verbose perhaps… and in a good way. If you think Xojo is “bad”… .try COBOL someday

I push my engineers to make sure their code meets 3 criteria… IN THIS ORDER

  1. readability… and yes every engineer is expected to be able to read and understand all the code (there is no “gun to the head”)
  2. maintianablity. this ties right into readability… if you can’t read it, you can’t understand it… if you can’t understand it. you can’t maintain it.
  3. execution… Of course the code has to work… surprised that this is not #1? of course it has to run… but if you have spagetti code then you may or may not have the “best” code… and you can still have optimum code and still follow criteria 1 and 2.

[quote=64916:@Chris Carter]For what it’s worth, you can extend the integer, and other, classes

For example-
Add a module to the project ( any name )
Add a method…

Sub AddThis ( ByRef Extends value as integer, amount as integer ) value = value + amount return

Then just use…

dim mynumber as integer = 0

mynumber.AddThis(1)[/quote]

I’ vote then adding an inline option for the compiler (methods). AddThis is not very efficient…

[quote=64919:@Michel Bujardet]Xojo addresses human beings needs. C forces human beings to think like machines. You may like being a machine. I do not. Switch to C and stop asking Xojo to become C.

Thank you :\[/quote]

Asking doesn’t hurt, and adding a ++ or – to xojo doesn’t make xojo like C nor make anybody think like a machine. I think these can be added as an option. If you want to use them, use them.

But please, stop telling people to stop asking what you don’t like.

You missed
j) Xojo doesn’t see this change as important or necessary in the grand scheme of things

Joshua, I feel your pain. Xojo is verbose and I miss those feature too. But as you can notice, Xojo users are very tied to the feel that they are using a 80’s BASIC with few updates, and very vocal about don’t wanting upgrading the operator sets following the current practices on almost other languages, even modern BASIC, like: http://www.tutorialspoint.com/vb.net/vb.net_operators.htm

Some says that Xojo will lose their BASIC roots, and I feel it’s not really true, as Xojo already is not standard BASIC. An example:

When I started learning Xojo, I asked how I could make multiple statements per line as the standard BASIC, as:

a = getAfromX(x) : b = getBfromA(a) : c = getCfromB© // Init a, b, c as expected

And people told me that there is no such thing in Xojo, colons where modified to be the not standard Pair operator, and this alone, made Xojo unique, far from being standard BASIC, as the colon statement separator is part of the core BASIC language definition.

So, evolving the set of operators, pushing it more near to the modern practices, doesn’t make it more incompatible than it already is.

Readability and Maintainability are styles.

I can write a very confuse code using the current Xojo syntax if I wish.

I could write a clear, dirt fast, one liner, short code too in a rich of features and operators BASIC and reinforce the understanding using the operator “// comment” at the end.

Readability and Maintainability are choices and training. But speed of execution and writing depends on choices of the language.

And, if you’ve ever tried to follow the code of folks that don’t add the spaces, you end up with gibberish like:

theClass.theSubclass.member=theClass.theSubclass.member+1/(theotherProperty*theMultiplier)

As one of the original proponents for the ++ additions, I’ve simply given up after all of the flareups that occur every time this subject is broached. Even though adding the ++ operators doesn’t limit anyone from retaining he current method, it seems to frighten so many that they may have to learn something that it will never happen.

++ is unlikely to happen (ever) in any form - certainly not with the pre increment / post increment semantics of C/C++ and their progeny.

+= and that short notation might

They just have VERY low priority

Joshua, how long are your typical methods? Keep them to a couple scrolled screens, and code density isn’t that big of an issue. Also, throw in some blank lines. I like a blank line before else, elseif, end if, wend, etc. If anything, I’d like something like half a blank line for those. And I regularly write C/C++, so I most certainly understand that perspective.

Stop asking people not to say what they think :\

Thank you for the replies. I’m sorry if I sounded a little cranky, but I must admit I did have a bit of a bee in my bonnet earlier. Of course I love Xojo and wouldn’t leave it because of some operators. Xojo Inc is also a very good company.

I think that conforming to this old basic style is a much bigger factor than any good, practical reason for these things not to be in the language. I’d be perfectly happy with just the += -= and so on. The ++ and – can stay out.

i+=1 is already so much better than i = i + 1.

@Brad Hutchings I just had a few nested loops with something graphical and became frustrated at the absurdity of these verbose increments. It made my code appear quite ugly. I’ve also been silently cursing about it ever since I started using Xojo.

@Norman Palardy Ah I know it’s not important in the grand scheme of things, but it sure is an eyesore and occasional headache.

@Karen Atkocius just imagine that I have the exact same problem as you, only in reverse. The difference is, you have the option to write your code differently.

Thanks @Chris Carter. I’m aware of this but it just isn’t as elegant.

I’ve also been a longtime proponent of this, and given up the fight since it gets beaten down so hard every time it comes up.

But here is a perspective that I think needs at least a little consideration: Xojo is trying very hard to become mainstream and attract many more developers than it currently has. Which I think is awesome! The tool is great, and being able to cross-platform compile from one codebase with native ui is fantastic, and MANY MANY MANY more developers should know about and use Xojo.

But here’s the thing: Whenever I discuss my work with other developers I know and respect, NONE of them have ever heard of Xojo in the first place, and then when encouraged to give it a try by me, they come back with the attitude that “it’s a nice toy” - that in effect it is good for prototyping but is too… basic… to handle any large they want to do with it.

“I mean, I can’t just ++ an int? What the heck?”

There are other features of mainstream development environments that are missing from Xojo that while not strictly necessary, really do make the seasoned developer more at home: I’m talking stuff like Categories and mixins in Objective-C, abstract classes, multiple inheritance, etc. By taking the attitude of “these are not important because the language is perfectly functional as it is and adding these makes it hard” we are shunning the professional developer who is used to, comfortable with, and expects to find such creature comforts.

In short: Catering so hard to the hobby crowd will keep Xojo from ever gaining widespread professional acceptance. And that’s a shame.

Xojo is more like Java than Obj-C in design philosophy and has many of the same issues but I doubt anyone would say its not a professional language

Protocols - extends behave much the same way

Doable with a private constructor

MI is used so poorly so often there are many languages - like Java- that do not support it