h a l f b a k e r yPoof of concept
add, search, annotate, link, view, overview, recent, by name, random
news, help, about, links, report a problem
browse anonymously,
or get an account
and write.
register,
|
|
|
Please log in.
Before you can vote, you need to register.
Please log in or create an account.
|
A picture is worth a thousand words. This applies to programming as well. I propose an editor add-on for displaying certain variables in the form of an icon instead of as text. For example: When you type the variable name upArrow, the editor would automatically convert it into an icon. Exactly the
same way how in MSN Messenger (@) gets converted to a cute cat. How would the editor know which variables are which icons? Basic ones could be predefined, but you'd have the ability to define your own icons just as you can in Messenger.
This will make for some interesting looking code. Just imagine:
foreach(bee in beehive){ ... }
If as a professional programmer this is beneath you, just think of the children learning to program for the first time.
[link]
|
|
Programming with pictures is Well Baked. There's even one that let's you program with Sims. |
|
|
Pictures are good whenever 2D-relationships mean something. Here, they don't. This would just introduce another layer of obfuscation, tuning something that is accessible to all and universally available (text) into something that you need to use specific, proprietary software to view. |
|
|
Not to say that you couldn't sucker people into doing this - especially in the guise of doing something "for children" - but it would be a bad deal. |
|
|
//Pictures are good whenever 2D-relationships mean something.// |
|
|
That's what I said. There is obviously no point representing a variable called mCoordinate with a icon. Using an icon in such a case would be obfuscation. I would have to say that representing a variable called sharpTurnFromWestToNorth with that exact picture would be a great idea. Using an icon in this case would be far from obfuscation, in fact it would create a more readable, more quickly understandable code. This is true for both children and for any professional programmers who follow the philosophy of "self documenting code". Not all do.
To give an analogy with regards to MSN messenger or any other chat that supports emoticons, using emoticons for every single word is a horrible idea. Using emoticons in well chosen circumstances is extremely helpful.
I should add that anyone using codicons should not rely on them being always visible. Most the time others view the code outside of this special editor. In other words the variable sharpTurnFromWestToNorth should still be typed in full as a good programming practice. Those who have the plugin will see an appropriate codicon, those who don't will read and try to mentally figure out what makes that variable different from sharpTurnFromEastToNorth. |
|
|
This could be useful in Excel VBA where you need object variables to refer to ranges and other visual things. Instead of naming it "rngHorizontalSection -BelowLabels", you could draw a little icon that's a picture of the spreadsheet with a rectangular section highlighted, and use the picture as the variable name. |
|
|
Just program in Labview. Everything's an
icon. And the different wire-types have
different colours too. If you put your mind
to it, you can braid together string-
connectors, cluster-connectors and
floating-point connectors to make a pretty
plait. |
|
|
This is very different than Labview. Codicons are for regular code except that certain keywords are converted to icons as they are typed. For example:
System.out.writeline could be represented as <<Console Icon>>.writeline
or screen.Fill(Color.Yellow) would appear as screen.Fill(<<Yellow Colored Icon>>)
I'm definitely with Jutta regarding the possibility of overuse (abuse) to the point of obfuscation. Just as emoticons, codicons are meant for very specific and limited areas of source code where they actually enhance readability. |
|
|
[MaxwellBuchanan] Wow, someone who uses Labview. You are a rare beast indeed. |
|
| |