4 ms·
The arguments in favor of Perl largely favor writability of code over readability. Code needs to be read, and most importantly understood, many more times than
by krupan 15y ago
The arguments in favor of Perl largely favor writability of code over readability. Code needs to be read, and most importantly understood, many more times than it is written, which is the whole reason Perl has fallen out of favor.
Elastic tabstops look interesting, but they won't solve any user experience problems until all major editors support them.
Using actual characters instead of substitutes like >= makes sense, except when I look down at my keyboard and try and imagine where all the extra buttons would go. I suppose you could still type the substitute and your editor could convert them to the actual symbols (LaTeX modes in emacs do something like this for you), but you'd have to get all editors to use the same substitutes to prevent another usability nightmare.
- evincarofautumn 15y agoEasy solution: you enter your source with ASCII approximations, and the language implementation can prettify it in-place with the canonical Unicode characters if you choose.
- masklinn 15y ago> the language implementation No need to touch the language, it can be done on the fly by the editor. It's already possible to do such things in Emacs, for instance: haskell-mode can be configured to replace `\` by `λ`, `>=` by `≥`, `.` (the function composition operator) by `∘`, etc…[0] in the visual display of the file (the underlying source keeps the original tokens). Of course you could add these new characters in the language's definition itself as well, so the editor can perform direct source replacements. [0] http://www.haskell.org/haskellwiki/Haskell_mode_for_Emacs#Using_Unicode_symbols http://www.haskell.org/haskellwiki/Haskell_mode_for_Emacs#Us... for the list
- evincarofautumn 15y agoGood point. Plus there’s something to be said for separating content from presentation, which seems to be a pervasive problem in programming languages, given all the petty arguments about formatting.
- masklinn 15y ago> Plus there’s something to be said for separating content from presentation Indeed, I would enjoy a world where this is done better (and more often), for instance having things like alignments, line-breaks or indentation be completely independent from the actual source. Of course, this generates a number of other problems in turn: different software on a given machine have to all use the same configuration (or be independently configured to match), communications becomes much harder unless new data pointers are invented as the concepts of line and column become fuzzy, some tools/concepts become impractical to say the least (a context diff for instance, would have a hard time working correctly unless it was token-aware and language-aware with diff/patch reader software able to use the global source formatting configuration for the language to display the diff as the user expects), and shared data display (e.g. a github source view) would be rife with strife. At the end of the day, I'm not sure this wouldn't create as many problems as it solves, if not more.
- fmoralesc 15y agoI think this is a very sane approach. The same thing exists in vim for python (https://github.com/ehamberg/vim-cute-python https://github.com/ehamberg/vim-cute-python).
- mikebike 15y agoAn interesting example of going too far the other way (favoring readability without enough thought to writability) is Applescript. It's very easy to read, even for those without too much programming experience. But it turns out that it's very difficult to write Applescript scripts. John Gruber wrote a good essay on the flaws of Applescript a few years back: http://daringfireball.net/2005/09/english-likeness_monster http://daringfireball.net/2005/09/english-likeness_monster