Code Readability. Break Rule Number 5?

Replies are listed 'Best First'.
Re: Code Readability. Break Rule Number 5? by jdporter (Paladin) on Apr 19, 2007 at 20:32 UTC
Well, Perl 6 is going to have much fuller support for Unicode at the source code level, so you may be happy with that. But perhaps you'd like to discover APL? :-) A word spoken in Mind will reach its own level, in the objective world, by its own weight	[reply]
Re^2: Code Readability. Break Rule Number 5? by Zaxo (Archbishop) on Apr 20, 2007 at 07:00 UTC
Though APL used a funny alphabet (ever seen a selectric typeball for APL?), its data types were no richer than Perl's. The difference (iirc) was that there were different operators for different types. I believe that Perl with PDL can do everything APL could do, without special fonts and remapped keyboards. APL's character set exists in unicode, code points in the 2300's. After Compline, Zaxo	[reply]
Re^2: Code Readability. Break Rule Number 5? by TGI (Parson) on Apr 20, 2007 at 01:28 UTC
This also calls to mind the Fortress programming language. (links to a biggish pdf) TGI says moo	[reply]
Re^3: Code Readability. Break Rule Number 5? by DACONTI (Scribe) on Apr 20, 2007 at 13:11 UTC
Thank you for sending me this very interesting link, however Fortress is strongly focussed on scientific computing. In contrast in my proposition I don't think only at using math symbols for formulas, although the examples in the presentation are very attractive. Moreover I think what it could happen if we abandon plain text source coding for everyday programming: would we really land in a chaos of patented signs, proprietary editors and languages, or would we get at the end a much more compact and readable code? I think this question is not easy to answer. Ciao, DACONTI	[reply]
Re^4: Code Readability. Break Rule Number 5? by TGI (Parson) on Apr 20, 2007 at 16:39 UTC
Re^5: Code Readability. Break Rule Number 5? by blazar (Canon) on Apr 22, 2007 at 13:14 UTC
Re^2: Code Readability. Break Rule Number 5? by apl (Monsignor) on Apr 21, 2007 at 13:58 UTC
But perhaps you'd like to discover APL? :-) <DumbJoke>Hi, pleased to make your acquaintance.</DumbJoke> I did program in APL back in the mid-70s, in small part just so I could say that...	[reply]
Re: Code Readability. Break Rule Number 5? by GrandFather (Saint) on Apr 19, 2007 at 20:48 UTC
I think rule 5 is another way of saying "Do not expect everyone els to use the same editor configuration and a color printer as you do". It is nothing do do with editability and all to do with presentation. There are two issues with your added richness: those keys don't exist on most keyboards and Perl already has a very rich set of operators, sigils and special variables. Adding another several layers of meaning by using special markup (that has to be composed) and borrowing syntax from APL will simply exacerbate the problem for people who already struggle to remember the full richness provided by their chosen form of expression. Why, some people even struggle to remember simple stuff like </br> is not HTML - how do you expect them to cope with anything truly complicated? DWIM is Perl's answer to Gödel	[reply]
Re^2: Code Readability. Break Rule Number 5? by DACONTI (Scribe) on Apr 19, 2007 at 21:08 UTC
Perl already has a very rich set of operators, sigils and special variables Exactly, and If you would use new symbols to rework/consolidate/make more expressive the old ones, you would have a more condensed way to code (see example nr 3 with the arrow). About </br> ... it is fixed now... Regs, DACONTI	[reply]
Re^3: Code Readability. Break Rule Number 5? by blazar (Canon) on Apr 22, 2007 at 13:51 UTC
Exactly, and If you would use new symbols to rework/consolidate/make more expressive the old ones, you would have a more condensed way to code Well, that's fine and all, but don't forget that except in specific situations, we do not strive for extreme condensation per se, we want conciness to optimise typing requirements but also clarity. Yes: conciseness increases clarity and readability, but if you exaggerate, then you degrade them instead. So all in all you want to stay balanced. If you consider for example Perl 6, which has been mentioned several times in this thread now, you may easily see that in some respect it is more condensed than current perls and in some others it is less: for example all those punctuation special vars are going away. So what can we deduce from this? Probably that at extreme forms of condensation, like those of golf, it will perform worse than Perl 5. But golf is, in fact, nothing but a game. So what about "normal" uses? Well, there's at least one pseudo-scientific (attempt at a) study in Perl6 burns 18% fewer calories. In it, the author claims to have compared equivalent Perl 5 and Perl 6 portions of code, both supposed to be "reasonably written" (i.e. we're not talking again about golf or obfu) and Text::TypingEffort suggests that "typing the Perl5 code takes about 18% more physical effort than typing the Perl6 code". see example nr 3 with the arrow The dereferencer is going to be replaced by a single dot anyway (still talking about Perl 6), which will be implicit in some cases, and although I had some attachment for the good old arrow, I see that there are good reasons to prefer the dot instead. How would the unary dereferencer look like, as an arrow? `->say for @list;` [download] No, plain horrible, even with a single charachter arrow as in your example.	[reply] [d/l]
Re: Code Readability. Break Rule Number 5? by robot_tourist (Hermit) on Apr 19, 2007 at 23:11 UTC
I think the point about not requiring syntax highlighting is meant to mean that the syntax of the language should not be so complicated that the majority of users need the fancy colours and bold/italics (and even syntax error underlines) to be able to understand it easily. I've been reading a lot of Edward Tufte's website recently and it got me thinking about this in terms of helping the user be more productive with the tools available, but still with the end goal of better tools. For the minute, though, Perl, while not as much of a soup nazi as the machine on which it runs, is still a strict language, where word order and type matters and it helps the programmer to see rather than read errors as seeing is faster than reading. Differentiating by colour is faster still than parsing the difference between a heredoc and code. I was going to say that syntax highlighting benefits maintainers, especially those who may not be as familiar with the language as the original 'guru', so that when they open up the editor, their vision is challenged by the colours on screen and then it is easier to skip visually through the code as it is not just one lump of black and white marks on the screen (HT/HP Basic, I'm looking at you, with your lack of spatial freedom and primitive monochrome IDE). But then I thought that functional higlighting rather than syntactical highlighting would be a great useful addition, e.g. so that you can tag related bits of a program with the same colour as you try to read it and understand the flow. I think VS may already have it, I was using it today at work, but can't remember, I never thought about it before this thread. I don't think XCode has user highlighting. On your point about extra operators (1 and 2), apart from not having the glyphs visible on the keyboard, I think a good programming language should not cause Carpal Tunnel Syndrome or force it's users to learn too much over and above the normal set of characters in order to use it. However, I think captial Sigma and capital pi are probably good suggestions for extra operators as they are likely to be well understood by any programmer who has even an high school education. As for the arrow, I think the period is slightly better for OOP and I don't tend to use arrows for hashes anyway. Rereading your point 5 I think that it is a little more useful than I first thought, but still sounds like another way to create a watch list. My original thought was that in general, I think the value of plain text as a way of writing code is the benefit of speed of entry without too much worrying about formatting other than lining up lists vertically and stuff. At the minute, most editors and even Word 2007's ribbon, don't have the facilities to enter even rudimentary formatting faster than the average programmer can type. Speed of entry is crucial where you need the throught process to flow. Having said that, most problems could well be designed out. When you think about it CTRL+I for italic is little different from SHIFT+[ to open a curly bracket. What you then get down to is more a carryover from the UNIX philosophy/tradition of human readable plaintext wherever possible, although if you go down the rich text route you could have xml and a stylesheet, but that complicates things too much for me. I think the goal of code should be what you see is what is done. I supose as well, that code could be thought of as cash. Not always the best transaction medium, e.g. debit cards can be more efficient, but everyone accepts cash, like text flowing through data pipes. Debit cards need more infrastructure than cash in a similar way to rich text and diagrams needing more infrastructure than ASCII. Finally, I think a slightly different take on syntax highlighting would be useful for something like LilyPond source files, e.g. each beat in a bar gets a different colour (most music doesn't go past about 12/8 and even that could be argued to be similar to 4/4). I hope everyone here will read Tufte and his forum contributors so that they can be more creative and productive in creating user interfaces and presenting output. How can you feel when you're made of steel? I am made of steel. I am the Robot Tourist. Robot Tourist, by Ten Benson	[reply]
Re^2: Code Readability. Break Rule Number 5? by chromatic (Archbishop) on Apr 20, 2007 at 06:18 UTC
Differentiating by colour is faster still than parsing the difference between a heredoc and code. Perhaps for people with normal color vision it is.	[reply]
Re^3: Code Readability. Break Rule Number 5? by halley (Prior) on Apr 20, 2007 at 12:40 UTC
Er, that makes little sense. I can't think of an editor that offers syntax coloring that doesn't also allow you to choose your colors. If red/green give you problems, don't use red for heredocs and green for comments (or some such). Even if you were unable to see ANY color, you could pick strong and weak shades of gray that would help you parse visually. I agree in general with the "don't depend on syntax coloring" but I won't go so far as to say that syntax coloring is unhelpful. -- `[ e d @ h a l l e y . c c ]`	[reply]
Re^4: Code Readability. Break Rule Number 5? by chromatic (Archbishop) on Apr 20, 2007 at 18:44 UTC
Re^3: Code Readability. Break Rule Number 5? by polettix (Vicar) on Apr 21, 2007 at 18:55 UTC
An interesting comment made from someone whose nick is chromatic `:-)` Flavio perl -ple'$_=reverse' <<<ti.xittelop@oivalf Don't fool yourself.	[reply] [d/l]
Re^2: Code Readability. Break Rule Number 5? by DACONTI (Scribe) on Apr 20, 2007 at 13:34 UTC
Thank you for the very interesting Link. I'll look at your stuff, it will take me however much time... Regs, DACONTI	[reply]
Re: Code Readability. Break Rule Number 5? by roboticus (Chancellor) on Apr 20, 2007 at 03:33 UTC
DACONTI: But nowadays we are on the 21st century, and we program on specialized and powerful IDEs, so why to stick with ascii? Erm... That's equivalent to saying "But everyone runs Windows!" or "The only browser you'll ever need is IE". Just because you like something doesn't mean it's best for all. </rant> My "powerful IDE" is a few console windows, one running vi. Not everyone likes running in an IDE. Most IDEs I've tried force you to change your habits unnecessarily. I've not tried Eclipse yet, but it sounds a lot closer to something that I'd like. In my day job, I have to use Visual Studio 2003, and I find it quite annoying. Just as you'd probably find vi annoying, or Marty would find emacs annoying... Currently, ASCII is the lingua franca for programming. I'm certain that we'll start a drift to unicode, but as a touch-typist, I'm hoping that we'll not go crazy with odd symbols just because we can. ...roboticus ...who wonders if he's just feeding the trolls.	[reply]
Re^2: Code Readability. Break Rule Number 5? by robot_tourist (Hermit) on Apr 20, 2007 at 09:45 UTC
I don't think working with an IDE has enforced anything on me, although I did spend a while fixing what I think is the silly and ugly way VS automatically puts in curly braces. I also admit I don't have a clue about linking and makefiles because in any project I've worked on VS or Delphi has built everything for me at the hit of a couple of keys. I suppose it's like deciding whether to use iTunes or Winamp. For me, iTunes's ease of use trumps even Winamp's AVS, and even when you use Winamp's excellent Super Mario skin. I don't mind working with vim and have almost liked it for doing some cgi work where JEdit couldn't ftp to the server, but for me, when working on a big project a big IDE like Delphi, or especially VS, is great for its code completion and automatic hyperlinking. That is something I think is fantastic for navigating around my code, kind of like increasing the screen's resolution virtually. Vim does have the benefit that in most cases it is white on black. At first I thought coding white on black was stupid, but Delphi's Twilight (which I had to tweak a bit in version 8) converted me. VS's flaw as an editor is that it doesn't have a white on black mode and it took me a while to set all the colours manually. JEdit is even worse in that regard - I just made the background light grey because there were so many other colours it used for highlighting that clashed with black. How can you feel when you're made of steel? I am made of steel. I am the Robot Tourist. Robot Tourist, by Ten Benson	[reply]
Re^3: Code Readability. Break Rule Number 5? by roboticus (Chancellor) on Apr 20, 2007 at 11:35 UTC
robot tourist: You might not notice things that IDEs force on you unless you have a particular way of doing things. Some IDEs will limit you to a particular editor, a particular coding format, a limited ability to lay out your windows the way you want to see them. Some may decide to help you by reformatting your code, or typing partial names for you, or some other thing. Some people really like the instant feedback and helpful suggestions--so I'm not saying that IDEs are dumb or useless. But one size never fits all. I find many of those "helpful features" quite intrusive and distracting--like Clippy(tm). I'd prefer the system wait for me to ask for assistance, than to just keep throwing help in my face. So when I have to use an IDE for a project, the first thing I do when I'm forced to use an IDE is to configure it to be as tolerable as is possible. Unfortunately, none of the IDEs gives me the choice to set things up the way I want them. (A little bit of OCD is enough to make using an IDE feel like a stint in Hell.) Finally, I tend to switch around machines and environments frequently. It's destructive to productivity to have to do things differently on every environment. I find a large monitor with multiple consoles quite comfortable. I can put the windows anywhere I want, and have any (or all) of the features that IDEs provide. I typically have a wide window at the bottom of my screen for compile/run. I have my source code in multiple windows, and on the other monitor I use a couple of windows for help screens. Any time I want to change things, I'm free to do so. I can switch editors quite easily in my NIDE (Non-integrated Development Environment). ...roboticus Sorry for the rant! But at least I didn't mention that when I have to use an editor other than vi that I keep having strings of "jjjjjllllll" and such in my code..... 8^)	[reply]
Re: Code Readability. Break Rule Number 5? by Fletch (Bishop) on Apr 19, 2007 at 20:38 UTC
Quoth the Barenaked Ladies, "It's all been done before". Sure those glyphs exist, but I can't find them on my keyboard (c.f.* space cadet keyboard).	[reply]
Re^2: Code Readability. Break Rule Number 5? by robot_tourist (Hermit) on Apr 19, 2007 at 21:02 UTC
Sure those glyphs exist, but I can't find them on my keyboard Yeah, Apple took the octothorpe off my MacBook keyboard. It took me a few minutes to find the <ALT>+3 keystroke. If they could print the € beside the @ sign, they could print the # beside the �. How can you feel when you're made of steel? I am made of steel. I am the Robot Tourist. Robot Tourist, by Ten Benson	[reply]
Re^2: Code Readability. Break Rule Number 5? by DACONTI (Scribe) on Apr 19, 2007 at 20:51 UTC
I supposed there was already somebody before... However APL was born 50 years ago and then it was dying again. I think this idea has a right to a 2nd chance... UPDATE: sorry APL seem actually to be alive. In wikipedia they speak very good about this language, so why do not port these ideas also to other languages? Ciao, DACONTI	[reply]
Re^3: Code Readability. Break Rule Number 5? by rodion (Chaplain) on Apr 21, 2007 at 06:37 UTC
I remember writing APL for a part-time job in college, quite some time ago. The language was powerful, and compact. However, when I went back to a piece of code that I hadn't looked at in two weeks, the compact and powerful nature of the language made it hard to read. It was often denser and harder to read than mathematical proofs. Sometimes it was faster to re-write the code from scratch than to read it, so it was, to some extent, a write-only language.	[reply]
Re^4: Code Readability. Break Rule Number 5? by holli (Abbot) on Apr 21, 2007 at 14:11 UTC
Re^4: Code Readability. Break Rule Number 5? by rodion (Chaplain) on Apr 22, 2007 at 03:05 UTC
Re^3: Code Readability. Break Rule Number 5? by blazar (Canon) on Apr 22, 2007 at 13:20 UTC
UPDATE: sorry APL seem actually to be alive. In wikipedia they speak very good about this language, so why do not port these ideas also to other languages? Who tells you they're not? Again I don't have fresh references, but I'm sure to have heard it mentioned in p6l, along with a ton of other known and less known languages. And you bet that if it's a good idea, than `$Larry` won't ignore it!	[reply] [d/l]
Re: Code Readability. Break Rule Number 5? by DrHyde (Prior) on Apr 20, 2007 at 09:43 UTC
so why to stick with ascii Because it works everywhere, unlike any of the various other character sets. Using non-ASCII characters in your code is stupid because it restricts you to only using certain machines (you won't be able to just borrow a terminal from someone and fix a bug); and it means that a huge number of your users won't be able to contribute patches. Using ASCII is lazy, in a good way. You might at this point start to rail against "neanderthals" who don't use your chosen flavour of character encoding. People say that to me a lot. It's funny though, they all blame my "obsolete" software. They are all Dead Wrong, as my oldest machine was set up just three years ago, which is well after the invention of all the various incompatible encodings that everyone seems to think I should use (although they all have different opinions about which one it should be). And of course, your chosen flavour of encoding is precisely that - your chosen flavour. Other people with whom I deal have settled on other encodings.	[reply]
Re^2: Code Readability. Break Rule Number 5? by DACONTI (Scribe) on Apr 20, 2007 at 13:30 UTC
...because it restricts you* to only using certain machines.* I don't believe this.There's a lot of OSF software for unicode characters. ...and if you want to avoid spreading out of different types of unicode character sets for programming, there is a remedy: Make standards, do them early....	[reply]
Re^3: Code Readability. Break Rule Number 5? by DrHyde (Prior) on Apr 23, 2007 at 09:03 UTC
You've obviously never tried to fix a critical bug while away visiting friends for the weekend, or from your PDA, or ever wanted to have a nice relaxing hacking session on a borrowed laptop at a conference. It was having to do all those that made me stop using pound signs as delimiters some years ago.	[reply]
Re: Code Readability. Break Rule Number 5? by samizdat (Vicar) on Apr 20, 2007 at 13:44 UTC
What a great topic, DACONTI! I, like others posting here, often sneak code into embedded environments through hokey serial port consoles. Forget ASCII, my stuff is just a bunch of binary bits. However, I'm absolutely not against making my development system more powerful. In my first college course, we studied a potpourri of languages including APL and SNOBOL (Ralph Griswold was a senior prof at U of Arizona ;-). I, too, was taken by the compact mathematical elegance of APL with its rich set of operators. Certainly there were some really good ideas in there. Expressing everything as an array of data points that are operated on by simple expressions with automatic iteration makes a lot of problem solving algorithms crystal clear. For scientific and statistical data, APL rocks and rolls. Since that time, with twenty years of reflection hard work, and legacy maintenance, I've come to take the opposite approach. I hate syntax. I hate having to remember anything, because I'm always switching contexts (and languages!) from one project or portion thereof to another. I love having a mouse-oriented development environment with element highlighting and object browsers and hyperlinking embedded in the presentation of my code. I just wish I could use it everywhere, and therein lies the rub. There will be languages that operate on the level you describe, and that's a good thing, but there will also be down-and-dirty kitchen-sink-and-garbage-disposal languages like Perl that get down to real work. Think for a moment about Macintoshes versus x86 PCs. The Mac had its nifty little toolbox and GUI, and lots of people thought it was the cat's meow, but I didn't see a whole lot of Macs in factories or embedded development. More to the point, I saw a whole lot more PCs everywhere than I saw Macs. Sure, programming PCs and x86's in general was a lot more messy than programming Macs, but the point was that you COULD program a PC to stand on its head in a pile of doo-doo and get it to work, whereas you could never get far enough into a Mac to do anything beyond its GUI and its filesystem. Methinks it'll be a long time before the natural selection of languages and the systems they operate on will get us beyond the command line of some form of text interaction, at one level or another, just because SOMEBODY always has to be able to come in the back door or lift the hood. Doesn't mean it isn't a great arena to explore. Now that displays and display controllers are being embedded into the simplest widgets, who can tell what the future will bring in terms of the available capabilities in targets? UPDATE: to the general question: Is the pen still mighty in the computer age?, think "ASCII-based programming" where they talk about "the pen" "One little girl said, 'I don't like to write, because when you make a mistake you have to erase. On the computer, you just go back.�� James Miles, senior associate, International Center for Leadership and Education, regarding the transformation of typing from handwriting in society. Don Wilde "There's more than one level to any answer."	[reply]
Re: Code Readability. Break Rule Number 5? by grinder (Bishop) on Apr 20, 2007 at 06:34 UTC
The biggest problem I have with syntax highlighting is the garish colours the average geek will come up with. They don't call it angry fruit salad for nothing. I find it interrupts my train of thought. I find meta-editing features like block collapsing much more useful (hmm, and I don't even use that very much). I have a sysadmin who has run around and added stupid config settings to all the servers at work, and even shell scripts get the treatment. It's nearly as ugly as SQL done in all caps. • another intruder with the mooring in the heart of the Perl	[reply]
Re: Code Readability. Break Rule Number 5? by TomDLux (Vicar) on Apr 26, 2007 at 20:53 UTC
I don't understand the question. I use emacs, with cperl-mode and fontlock-mode colourizing the fonts. I find it convenient for quickly detecting missing close quotes and such. There's syntax highlighting for vi, though I don't use it there. However, if the topic were languages that can't be used outside a complex and slow IDE, that would definitely disrupt my ability to develop anywhere, anytime, even over a slow dial-up modem. I understand you can connect to a server with a BlackBerry and get some work done, with vi, but not with Eclipse... or did I misunderstand that part> -- `TTTATCGGTCGTTATATAGATGTTTGCA`	[reply]
A reply falls below the community's threshold of quality. You may see it by logging in.


laziness, impatience, and hubris
	PerlMonks