A rant on syntax and verbosity, why ruby is not for me

[mouser]

When looking at the new programming languages, sometimes i feel like i'm alone in the wilderness in advocating for verbosity and the value of longer and clearer code.

I've never understood the desire to find shorter and shorter ways of expressing code.  In fact one of the things i always try to hammer home when helping people learn to be better coders is that it's better to write 10 lines of understandable code than 2 lines of perfect concise incomprehensible hacks.  But perl seems to have mainstreamed this obfucation-contest flavored coding style..

here's a blog post from a site i generally enjoy (http://secretgeek.net/ruby_sugar.asp), which i almost took as satire:



and then looking back at the ruby manual (http://www.ruby-doc....4/syntax.html#assign):



when i read stuff like this in a language i know that i'm on a different wavelength from the language/syntax designers and move on to another language..

what's the goal here fellas?
you dont want to write:

[Select]

foo=1;
bar=2;

oy vey talk about lazy.  upgrade from your 10mb hard drive and stop worrying about using a few extra bytes of source code.  maybe it's time for me to dig up my plans on a language whose primary design principle was clarity and readability and unambiguity..

this attraction to having "cool" ways of writing compound complex statements just boggles my mind.

[mouser]

Paul Bartlett posted a reply at secretgooek and showed an interesting example of the kinds of useful things you can do with such assignments.

His example:

It's especially "sweet" when capturing arguments, e.g.:
(source, dest, *opts) = ARGV
would assign the first argument to "source", the second to "dest" and the rest into the "opts" array.

I want to be clear that i agree that being able to grab commandline arguments into such variables is useful functionality.
My quibble is about where you put such functionality - whether you build it into an increasingly opaque and complex internal syntax system - or whether you put such stuff inside proper FUNCTIONS.

My position is simply that it's best to have such elaborate stuff in functions, where it is obvious that something more involved is going on, and where you don't get into a language arms race where we are competing to build in increasingly elaborate processing into the core language syntax through special symbols and increasingly convoluted non-standard and unintuitive expressions.

[f0dder]

I tend to agree with the stuff you've just posted here, mouser. The forms of multi-assign shown is mostly for crap-coders and leetkids.

It can, however, be useful for languages that support returning multiple values from a function - alleviates the need for endless pointer-to-return-value function arguments (but of course, "use a struct" would be a viable option as well.)

[Gothi[c]]

You don't have to feel alone, after my day of playing with ruby, I couldn't agree more.

Things can start looking very messy with stuff like multiple assignments, and anti-intuitive expressions.

Perl still seems somewhat more intuitive to me, but maybe that's just because I've used it too much. But I still wouldn't wanna trade it in for c++.

I just tried ruby on rails, and my first impression seems that it's all Quick and Easy as long as you don't have to write something real. As soon as you want to start doing more advanced stuff you end up coding about just as much as you would in perl. Plus, after having read a bunch of tutorials and having tried a few simple database apps, I have to agree that the syntax is absolutely horrible. Not for me at all.

[mouser]

yes, multiple return value stuff can be quite nice, BUT i tend to prefer a much more standardized syntax and grammar for that. e.g.: define an object called a "tuple" and let functions return tuple objects and assign tuple objects.

[jgpaiva]

It's especially "sweet" when capturing arguments, e.g.:
(source, dest, *opts) = ARGV
would assign the first argument to "source", the second to "dest" and the rest into the "opts" array.

-mouser (July 13, 2006, 06:26 AM)

Ok, this quote takes crazyness to a whole new level. I do agree that it's fast to code and takes less space, but it becomes way too cryptical for my tastes.
I couldn't agree more when you mention that longer code = better code. The code mentioned is unsuitable for those who would like to make a program in which several developers can work. Also, updating such code becomes a giant headache. For me, code needs to be written in such way that when i scroll it, i can actually see what's happening there, so that fixing bugs, changing functionality, explaining to others and code reusing can be done.
I definitelly agree with the "use a struct" statement

[app103]

I agree with the 10 lines of understandable code is better than 1 line nobody can understand, approach.

Squishing everything into 1 line is a crazy thing to teach to a beginner and makes it very difficult to understand things. Also not good if someone else is going to end up having to maintain that code.

Understanding that a program's source is very much like a recipe for cookies, you wouldn't want to make the recipe unclear, now would you? You could end up with some nasty cookies when it comes time for someone else to do the baking or add to that recipe.

This has been my biggest problem with learning. Too much being packed into code and being unable to pick it apart to understand the small pieces of it and how it works. Makes it very hard to see & understand the big picture. Yet too many languages & tutorials do that and assume you are some sort of genius that can decipher it all.

This is most evident in languages & tutorials created for people that are already competent programmers. But you can't get to that level unless you start at the beginning and too many beginners tutorials are written very badly too...because they are written by more advanced programmers that forgot what it's like to know nothing at all. They start off good and then lose you at about chapter 3 with crazy stuff a beginner can't make sense of.

Or worse...

They give you a project to make, meant to teach you...get halfway through the project and stop explaining and then tell you to 'copy & paste this and don't worry about what it all means & does'. How are you supposed to learn anything like that?

I don't want to be a C&P programmer...there are too many of those in the world already, copying someone else's buggy code and never fully understanding how it works. And that is one of the sources of bad software.

Keep things simple and maybe there will be better software and more competent programmers.

[jgpaiva]

I don't want to be a C&P programmer...there are too many of those in the world already, copying someone else's buggy code and never fully understanding how it works. And that is one of the sources of bad software.

-app103 (July 14, 2006, 12:08 AM)

I sure support that statement! There's nothing worse than someone handing you a peice of copy-paste code, which looks like a bunch of different snipplets bound together by duct-tape. Then, you can't understand what the code is meant to do, can't debug it, and even worse: when you ask the person who sent you the code, that person doesn't understand it either!

[Rover]

mouser, et. al. - While I agree that your examples of bad code are indeed bad, I don't condem the language for it.  Just becuase you can use it to write bad code, doesn't mean you should.

Given the right "bad" attitude I think you can make any language look like that.  Not exacltly mind you, but there's always something you can do that just as bad.

 

[mrainey]

Lots of times I see "ten lines packed into one" code described as "elegant".

What does "elegant" really mean, in the context of programming?  Does it mean anything at all?

[f0dder]

What does "elegant" really mean, in the context of programming?  Does it mean anything at all?

-mrainey (July 15, 2006, 07:23 AM)

For me, it's code that you understand on the first read-through. Well-designed classes. And sometimes, just a "gut feeling" when something is done cleverly ("clever" doesn't mean "hackish" in this content, btw!).

mouser, et. al. - While I agree that your examples of bad code are indeed bad, I don't condem the language for it.  Just becuase you can use it to write bad code, doesn't mean you should.

-rover

You're right, of course... some langauges just lend themselves very well to writing hacky code. Heck, for some languages almost only hacky code is written

[app103]

What does "elegant" really mean, in the context of programming?  Does it mean anything at all?

-mrainey (July 15, 2006, 07:23 AM)

To me 'elegant' is code that is written so well, and so obvious, it doesn't need comments...it speaks for itself. And it's author thinks of everything...including the idea that some day someone may have to change it....or add a new feature. And it's ready for that, from the start.

And that can't be done by shoving it all in 1 line.

[cranioscopical]

When looking at the new programming languages, sometimes i feel like i'm alone in the wilderness in advocating for verbosity and the value of longer and clearer code...maybe it's time for me to dig up my plans on a language whose primary design principle was clarity and readability and unambiguity.

-mouser (July 13, 2006, 06:05 AM)

Rexx?

[Rover]

Rexx?

-cranioscopical (July 16, 2006, 12:30 PM)

That was sarcasm right?