GNU Texinfo 5.0 Released

← Back to Stories (view on slashdot.org)

Posted by Unknown on Sunday February 17, 2013 @11:14AM from the aged-to-perfection dept.

Four years after the last release, version 5.0 of Texinfo, the GNU documentation language, has been released. The primary highlight is a new implementation of makeinfo info in Perl rather than C. Although slower, the new version offers several advantages: cleaner code using a structured representation of the input document, Unicode support, and saner support for multiple output backends. There are over a dozen other improvements including better formatting of URLs, improved cross-manual references, and a program to convert Perl POD documentation to Texinfo.

173 comments

Min score:

Reason:

Sort:

Will an end user notice this speed degradation? by bogaboga · 2013-02-17 11:19 · Score: 2

Although slower, the new version offers several advantages: cleaner code using a structured representation of the input document, Unicode support, and saner support for multiple output backends. (emphasis mine).
Whether a end user will notice, I don't know for sure! Who does?
1. Re:Will an end user notice this speed degradation? by larry+bagina · 2013-02-17 11:25 · Score: 5, Insightful
  
  how often do you run makeinfo? Probably never directly. And only indirectly if you're compiling and installing a GNU package from source (I mean, who else even uses it? )-- in which case configure checks and compilation times are the bottleneck, not makeinfo
  
  --
  Do you even lift?
  These aren't the 'roids you're looking for.
2. Re:Will an end user notice this speed degradation? by Anonymous Coward · 2013-02-17 11:46 · Score: 0
  
  Although slower, the new version offers several advantages: cleaner code using a structured representation of the input document, Unicode support, and saner support for multiple output backends. (emphasis mine).
  Whether a end user will notice, I don't know for sure! Who does?
  If you're typing man whatever, no, since it's run as part of the build process. Even if you're building from source, it's still going to be marginal compared to other steps.
3. Re:Will an end user notice this speed degradation? by ais523 · 2013-02-17 11:57 · Score: 1
  
  It'd only be even potentially noticeable if the end user compiles their documentation from source. That's only likely to happen if they're also compiling their binaries from source, i.e. on source-based distros. (I doubt it'd be particularly noticeable even in such cases.) Most people would get the compiled version of the documentation, rather than compiling it themselves.
  
  --
  (1)DOCOMEFROM!2~.2'~#1WHILE:1<-"'?.1$.2'~'"':1/.1$.2'~#0"$#65535'"$"'"'&.1$.2'~'#0$#65535'"$#0'~#32767$#1"
4. Re:Will an end user notice this speed degradation? by Zontar+The+Mindless · 2013-02-17 17:12 · Score: 1
  
  Hooray. Nice to see they finally got round to supporting Unicode. Structured docs. Woohoo. Multiple formatting backends. Yippee.
  DocBook XML has had all these things from the beginning, and thus we (ubiquitous FOSS project) dumped TexInfo in favour of DBXML 6 or 7 years ago as the source format for all our end user docs.
  I do not miss TexInfo one bit.
  
  --
  Il n'y a pas de Planet B.
5. Re:Will an end user notice this speed degradation? by Anonymous Coward · 2013-02-17 20:08 · Score: 0
  
  I don't see speed as an issue here. What bugs me is the portability.
  There are C-compilers available for a lot more platforms than Perl is ported to. This pretty much means that the documentation have to wait until someone decides to port Perl. (Yep, that sounds like a lot of fun.)
6. Re:Will an end user notice this speed degradation? by Ed+Avis · 2013-02-17 21:09 · Score: 2
  
  What still-alive platform has a decent C compiler (crusty K&R ones don't count), but doesn't have a port of Perl?
  
  --
  -- Ed Avis ed@membled.com
7. Re:Will an end user notice this speed degradation? by deepsky · 2013-02-17 21:50 · Score: 3, Interesting
  
  Texinfo produces very nice paper manuals effortlessly. With Docbook one has to dive into XSL-FO unpleasantness.
8. Re:Will an end user notice this speed degradation? by Anonymous Coward · 2013-02-17 22:52 · Score: 0
  
  Pretty much any platform that isn't Windows, BSD, Linux or Mac?
9. Re:Will an end user notice this speed degradation? by Anonymous Coward · 2013-02-17 23:40 · Score: 0
  
  texinfo is vastly nicer and much less verbose to read and write than XML. You made the wrong choice
10. Re:Will an end user notice this speed degradation? by tibit · 2013-02-18 05:36 · Score: 1
  
  So, nothing you'd care to run makeinfo on. Point taken. Er, what were you saying, again?
  
  --
  A successful API design takes a mixture of software design and pedagogy.
11. Re:Will an end user notice this speed degradation? by K.+S.+Kyosuke · 2013-02-18 06:16 · Score: 1
  
  Texinfo produces very nice paper manuals effortlessly.
  With those changes and the advent of LuaTeX, perhaps it will be possible to produce even better paper manuals even more effortlessly. (But I still bet my money on Pandoc...)
  
  --
  Ezekiel 23:20
12. Re:Will an end user notice this speed degradation? by larry+bagina · 2013-02-18 08:00 · Score: 1
  
  Seriously? Perl Platforms
  
  --
  Do you even lift?
  These aren't the 'roids you're looking for.
13. Re:Will an end user notice this speed degradation? by cduffy · 2013-02-18 12:00 · Score: 1
  
  There are also places where Perl is supposedly compatible, but an utter bitch to build.
  Think about anything small enough you can't host your compiler there. The compilation process depends on being able to build and run miniperl, and a bunch of other tiny little test programs locally. If the system you're doing the compilation on can't run the target's binaries... well, it's an interesting day.
The truth about the Free Software Foundation by Anonymous Coward · 2013-02-17 11:20 · Score: 0, Troll

Tabloid newspapers have speculated for years that Timothy Geithner is a prominent supporter of the Free Software Foundation. Too bad we didn't believe them sooner!
You may not know it, but the concept of currency inflation was invented by the Free Software Foundation, which wanted an easy way to increase the numerical value of their investments in MDMA. It's easy to tell that inflation was never really real: when things get older, they get run down and lose value, right? But inflation is about numbers getting BIGGER. It doesn't make any sense!
There's evidence that Reverend Al Sharpton's rise to power was engineered entirely by the Free Software Foundation, which profits from Reverend Al Sharpton's influence in ways we do not yet completely understand.
Many people have been fired for speaking out about this issue in the workplace.
You may think free speech ensures your right to talk openly about Timothy Geithner's true beliefs, but powerful people won't let that happen: in the past, brave citizens who have questioned them about these issues have been silenced with crippling libel lawsuits.
People who have taken out library books on this topic frequently find that they receive more rigorous airport screenings than before. Definitely not a coincidence!
"There are no facts, only interpretations." -- Friedrick Nietzsche
1. Re:The truth about the Free Software Foundation by Anonymous Coward · 2013-02-17 11:45 · Score: 0
  
  woot woot
2. Re:The truth about the Free Software Foundation by Anonymous Coward · 2013-02-17 13:01 · Score: 0
  
  Someone is posting shit they get off of verifiedfacts.org
Things you don't hear every day by Anonymous Coward · 2013-02-17 11:21 · Score: 5, Funny

"Nobody could understand the source code anymore without massive doses of caffeine... ao we decided to rewrite the whole thing in Perl."
1. Re:Things you don't hear every day by Anonymous Coward · 2013-02-17 11:53 · Score: 1
  
  seeing as it's perl, the next step is obviously: rinse. lather. repeat.
2. Re:Things you don't hear every day by c0lo · 2013-02-17 13:40 · Score: 3, Funny
  
  "Nobody could understand the source code anymore without massive doses of caffeine... ao we decided to rewrite the whole thing in Perl."
  Oblig xkcd
  
  --
  Questions raise, answers kill. Raise questions to stay alive.
3. Re:Things you don't hear every day by Anonymous Coward · 2013-02-17 14:07 · Score: 0
  
  "Nobody could understand the source code anymore without massive doses of caffeine... ao we decided to rewrite the whole thing in Perl."
  Citation needed.
4. Re:Things you don't hear every day by murdocj · 2013-02-17 15:25 · Score: 1, Redundant
  
  That is pretty scary when you rewrite it in Perl to make it intelligible.
5. Re:Things you don't hear every day by one+eyed+kangaroo · 2013-02-17 16:48 · Score: 5, Insightful
  
  A witty response, but really this is getting a bit tired.
  I suppose people are free to keep reading the same old, self-reinforcing sources that insist that Perl is somehow a language of the past. And if they read enough of these cliches, the anti-Perl FUD may seem to be accurate, but as any developer who spends time wrestling with real-world problems in modern Perl will attest, the so-called modern Perl ecosystem is, (just like the modern Python or PHP ecosystems), a fabulous place to work in.
  I work in all three.
6. Re:Things you don't hear every day by VortexCortex · 2013-02-17 17:29 · Score: 5, Interesting
  
  "Nobody could understand the source code anymore without massive doses of caffeine... ao we decided to rewrite the whole thing in Perl."
  Oblig xkcd
  Obligatory Rebuttal xkcd
  This is interesting for two reasons:
  0. It was Perl's built in features, such as regex, system calls, and ability to be terse enough to enter a solution on a single swinging pass that make it an obvious choice -- It was made for this type of job.
  1. I'm confident that if we have not already, we will soon reach a point where entire discussions can be composed of no text other than xkcd links.
7. Re:Things you don't hear every day by c0lo · 2013-02-17 18:08 · Score: 1
  
  Obligatory Rebuttal xkcd
  This is interesting for two reasons:
  0. It was Perl's built in features, such as regex, system calls, and ability to be terse enough to enter a solution on a single swinging pass that make it an obvious choice -- It was made for this type of job.
  Whenever the problem allows for a single pass.
  
  1. I'm confident that if we have not already, we will soon reach a point where entire discussions can be composed of no text other than xkcd links.
  Due to limited contexts available on xkcd, I surmise we are quite far at that point. E.g. I challenge you to find the very basic "laser on sharks" or "car analogies" cartoons on xkcd.com.
  "grits" (hot or not), "petrified/statue" etc??? Not a chance in hell.
  
  --
  Questions raise, answers kill. Raise questions to stay alive.
8. Re:Things you don't hear every day by Anonymous Coward · 2013-02-17 19:12 · Score: 0
  
  Yes, but would you advice you kids to do the same?
9. Re:Things you don't hear every day by Anonymous Coward · 2013-02-17 20:03 · Score: 0
  
  Due to limited contexts available on xkcd
  Due to the limited contexts available on slashdot I don't see how that would be a problem.
10. Re:Things you don't hear every day by one+eyed+kangaroo · 2013-02-17 21:09 · Score: 1
  
  Yes.
11. Re:Things you don't hear every day by itsdapead · 2013-02-18 00:47 · Score: 1
  
  1. I'm confident that if we have not already, we will soon reach a point where entire discussions can be composed of no text other than xkcd links.
  Indeed.
  
  --
  In a survey of 100 programmers, 111111 thought that duck-typing was a good idea.
12. Re:Things you don't hear every day by murdocj · 2013-02-18 05:18 · Score: 2
  
  Yes Perl has lots of libraries, lots of code, lots of support, and I'm sure if you spend all of your time in Perl, you eventually get used to it. But I spent time working on occasion on some Perl scripts we used for glue, and from that point of view, Perl is a nightmare. Random crap done by random characters depending on random context. Basically it looks like whenever Larry Wall needed to do something, he added some functionality and assigned the next unused character combination to it. I've programmed in a wide variety of languages, down to flipping switches and pressing a button to put the next opcode into computer memory, and Perl is far and away the most annoying.
13. Re:Things you don't hear every day by murdocj · 2013-02-18 05:40 · Score: 1
  
  I must admit, one of my issues with Perl isn't really Perl, it's the Camel book. It seems to be deliberately written out of order so whatever you are reading, it's guaranteed that you need to read something later in the book first.
14. Re:Things you don't hear every day by Anonymous Coward · 2013-02-18 06:09 · Score: 0
  
  "Nobody could understand the source code anymore without massive doses of caffeine... ao we decided to rewrite the whole thing in Perl."
  This might say a lot more about the ability of the reader than anything else.
  I personally have found the vast majority of Perl programs that I've been forced to look at a pile of vague idiomatic expressions and mixed metaphors, even within the Perl language itself.
  But, a program that was authored in 1987 and is just now in 2013 being rewritten to be slower - that's a good run for any piece of software, so so long, and thanks for all the fish.
man texinfo by Anonymous Coward · 2013-02-17 11:22 · Score: 5, Insightful

Can't be much use, it doesn't have a man page.
1. Re:man texinfo by Trepidity · 2013-02-17 15:59 · Score: 1
  
  It does actually have one on my system, though it points you to the texinfo page (of course) for additional details.
  
  --
  10 PRINT CHR$(205.5+RND(1)); : GOTO 10
2. Re:man texinfo by Anonymous Coward · 2013-02-17 20:10 · Score: 0
  
  Maybe you should run Debian or a derivative? Debian are big on man pages and will write them if they don't exist.
3. Re:man texinfo by Anonymous Coward · 2013-02-18 00:29 · Score: 0
  
  Good joke, but, honestly, I much prefer man pages over texinfo anyway.
  Except, of course, for those infuriating man pages that say nothing and point the user to texinfo.
Yes, spin it that way, why don't you. by Anonymous Coward · 2013-02-17 11:27 · Score: 0

Consequence: Instant perl dependency on everything that uses texinfo. Which is bloody everything the gn00 bunch publishes. My, what an improvement. And info and its assumptions (including emacs-y default viewer) already was such a wonderful thing.
1. Re:Yes, spin it that way, why don't you. by Anonymous Coward · 2013-02-17 11:36 · Score: 1
  
  Only for building the software, and even then (at least with Automake) only if you are generating distribution tarballs or building from the bleeding edge vcs repository and need to regeneration maintainer files. If you're using Automake... it's already written in Perl. And it's basically a hard dependency in the base system of every GNU/Linux distro.
2. Re:Yes, spin it that way, why don't you. by Anonymous Coward · 2013-02-17 12:21 · Score: 1
  
  You sir, are full of it.
  Automake does not depend on perl. Perl is not a hard dependency in "the base system" since this concept doesn't exist in "gnu/linux". And it isn't in systems where such a concept does exist, eg FreeBSD (the spurious and wrongful dependency on perl and python listed in the glib2 port Makefile notwithstanding, same with the braindamage brought by the new and improved Xorg with video driver(!) dependencies on dbus(!) and xcb on python).
  It'd be nice if the FOSS world would be a little less careless about its veritable forestry of dependencies. Much of it is rather senseless and on balance not worth the trouble when looking a bit further than the happily hackening developer and his magnificent code mangling machine, like when accounting for the users.
3. Re: Yes, spin it that way, why don't you. by Anonymous Coward · 2013-02-17 12:34 · Score: 2, Informative
  
  You sir, are full of it.
  Automake does not depend on perl.
  $ head -n1 /usr/bin/automake-1.11
  #!/usr/bin/perl -w
  
  Perl is not a hard dependency in "the base system" since this concept doesn't exist in "gnu/linux".
  Sure it does, it means the core, non-optional components of the OS.
4. Re:Yes, spin it that way, why don't you. by Zontar+The+Mindless · 2013-02-17 17:23 · Score: 1
  
  Sorry, but the world works the way it works, and does not magickally conform itself to your views on How Things Should Be.
  I don't like perl, either. ("Loathe" might not be too strong a term.) But neither am I foolish enough to believe that I am likely to wind up with a usable Linux or FreeBSD system if I try to set one of those up without it.
  
  --
  Il n'y a pas de Planet B.
Perl POD is a good man input format by Anonymous Coward · 2013-02-17 11:38 · Score: 0

It's very handy for generating both nroff man pages and their HTML counterparts from the same input text. Being extremely simple, it raises no barrier to writing man-page type documentation.
Although I don't use Texinfo, it'll put another feather in Perl POD's cap.
1. Re:Perl POD is a good man input format by jgrahn · 2013-02-17 12:04 · Score: 3, Interesting
  
  It's very handy for generating both nroff man pages and their HTML counterparts from the same input text. Being extremely simple, it raises no barrier to writing man-page type documentation.
  Neither does nroff -man. If you're in a position where you'd want a man page, a percieved complexity in writing one in nroff is no excuse. Read man(7), groff_man(7) and groff_char(7), and look at some example man pages for inspiration.
  Also, if the cvs(1) man page of CVS 1.12.13 is a typical example of what Texinfo generates, I strongly recommend against using it for this. It's ugly and hard to read; doesn't really look like a man page at all.
2. Re: Perl POD is a good man input format by Anonymous Coward · 2013-02-17 12:28 · Score: 0
  
  Also, if the cvs(1) man page of CVS 1.12.13 is a typical example of what Texinfo generates, I strongly recommend against using it for this. It's ugly and hard to read; doesn't really look like a man page at all.
  It isn't generated by Texinfo itself, it's generated from the Texinfo source by a custom script in the CVS source tree. The GP was talking about generating man pages using Perl's POD system, which is relevant to this article because Texinfo now includes a tool to convert from POD to Texinfo format.
3. Re:Perl POD is a good man input format by Anonymous Coward · 2013-02-17 12:48 · Score: 0
  
  If you're in a position where you'd want a man page, a percieved complexity in writing one in nroff is no excuse. Read man(7), groff_man(7) and groff_char(7), and look at some example man pages for inspiration.
  
  You've very nicely highlighted the barrier that is raised by using nroff -man directly. While it's not totally hieroglyphics, you need to pay careful attention to its documentation every time you use it because it's not obvious.
  In contrast, Perl POD is much less cryptic, and is quite usable without reading anything at all. The barrier is much lower, and given the reticence that many people have in writing any documentation in the first place, that helps. As does its multiple back ends.
  Perl POD is like the wiki of man pages.
Default to HTML yet? by Anonymous Coward · 2013-02-17 11:40 · Score: 5, Insightful

I haven't used TexInfo for years, but what I remember most was the absolutely abysmal standalone "info" reader. That thing was the biggest piece of shit I've ever seen in any program. Hopefully they've abandoned the crappy "info" format and all of the shitty standalone readers to view info documents, and just use HTML by default now.
1. Re:Default to HTML yet? by Anonymous Coward · 2013-02-17 11:51 · Score: 0
  
  have you seen the HTML that gets generated from TeXInfo? It's like you're time warped back to the early 90s.
2. Re:Default to HTML yet? by ls671 · 2013-02-17 12:58 · Score: 1
  
  What's wrong with that? ;)
  
  --
  Everything I write is lies, read between the lines.
3. Re:Default to HTML yet? by Waffle+Iron · 2013-02-17 14:55 · Score: 4, Insightful
  
  have you seen the HTML that gets generated from TeXInfo?
  
  Yes. It's usually broken up into a massive hierarchy with a couple of sentences per page. You'll get cramps clicking on the navigation links while searching for the particular thing you need to find like a needle in a haystack.
  Plain old man pages (especially when nicely rendered in KDE's Konqueror web browser by typing "#program-name" into the URL box) are almost invariably superior to the corresponding Texinfo docs converted to html.
4. Re:Default to HTML yet? by Zontar+The+Mindless · 2013-02-17 17:43 · Score: 2
  
  have you seen the HTML that gets generated from TeXInfo?
  (Did they ever figure out how to output *valid* HTML? */me recalls many hours spent looking out over acres and acres of crossed and mismatched tags, and weeping softly to himself...*)
  
  Plain old man pages (especially when nicely rendered in KDE's Konqueror web browser by typing "#program-name" into the URL box) ...
  Fuck me! Been using KDE since 2004 and I had NO idea you could do that. (Works with Konq in both KDE 3 and 4, BTW.)
  Thanks for the tip!
  
  --
  Il n'y a pas de Planet B.
5. Re:Default to HTML yet? by Anonymous Coward · 2013-02-17 19:07 · Score: 0
  
  I the standalone info is fine it supports most of the emacs keybindings that I actually know off the top of my head
6. Re:Default to HTML yet? by Lemming+Mark · 2013-02-17 22:38 · Score: 1
  
  Unless things have changed, I think you can also ##program-name and get the TeXInfo page for it.
  With file management, web browsing, KParts rendering PDFs, and the integrated man / TeXInfo viewers I practically never used to leave Konqueror.
7. Re:Default to HTML yet? by Anonymous Coward · 2013-02-17 22:38 · Score: 0
  
  the standalone info is fine...it supports most of the emacs keybindings
  Which is precisely why Info is not "fine".
  
  I haven't used GNU info in over five years now (and that last time was out of pure bloody desperation) and I intend to keep it that way. GNU Info Must Die.
8. Re:Default to HTML yet? by Anonymous Coward · 2013-02-18 00:03 · Score: 0
  
  Personally I would prefer XML. It allows for using XSLT to transform the XML into just about any format you want, as well as opening up the option to make your own viewers using whatever XML parsing library you like best.
9. Re:Default to HTML yet? by massysett · 2013-02-18 02:03 · Score: 1
  
  HTML, entirely on one webpage is available for every GNU project I have ever seen.
  
  --
  Penny - plain text accounting
10. Re:Default to HTML yet? by flyingfsck · 2013-02-18 03:03 · Score: 1
  
  Or perhaps more memorable:
  man://whatever
  That works in Dolphin too.
  
  --
  Excuse me, but please get off my Pennisetum Clandestinum, eh!
Perl??? by mark-t · 2013-02-17 11:48 · Score: 2, Insightful

Why on earth would they have picked perl? Perl isn't really a native gnu project. At least gcc is.

--
File under 'M' for 'Manic ranting'
1. Re:Perl??? by Darinbob · 2013-02-17 12:13 · Score: 2
  
  Probably because it's the second most widely known and used language on systems that run makeinfo, next to C?
2. Re:Perl??? by Anonymous Coward · 2013-02-17 12:52 · Score: 0
  
  Javascript? (ducks)
3. Re:Perl??? by ls671 · 2013-02-17 13:08 · Score: 2, Funny
  
  C and shell scripting is good enough for me and it should be for any GNU project. I do not use half-way solutions such as Perl. I use Java when bash and C becomes too messy. The idea is to reduce your inventory to a strict minimum.
  
  --
  Everything I write is lies, read between the lines.
4. Re:Perl??? by ozmanjusri · 2013-02-17 14:40 · Score: 1
  
  Sure, enjoy...
  http://mattsurabian.com/duckhunt/
  
  --
  "I've got more toys than Teruhisa Kitahara."
5. Re:Perl??? by jbolden · 2013-02-17 14:47 · Score: 2
  
  GCC is C. This is a job for a scripting language not a low level compiled language. Typically GNU uses Scheme as their scripting language. But knowledge of Scheme and Scheme syntax is decreasing. Perl has good support for parsing, tons of people know it, It seems like a reasonable choice for GNU to start doing scripting type stuff in. The Perl community has been active with free software for a long time and hasn't gotten involved in anything questionable.
  Seems like a reasonable choice.
6. Re:Perl??? by Unknown+Lamer · 2013-02-17 15:28 · Score: 1
  
  Usually people make fun of the FSF for choosing crappy projects (see: bzr for emacs) because they are part of GNU instead of making pragmatic choices for technical reasons...
  
  --
  
  HAL 7000, fewer features than the HAL 9000, but just as homicidal!
7. Re:Perl??? by Anonymous Coward · 2013-02-17 19:03 · Score: 0
  
  > Typically GNU uses Scheme as their scripting language.
  So you're basically telling: They have an "official" GNU scripting language, which they have been advocating for 20 years now, and now they are avoiding their own fucking dogfood and rewriting their core documentation format to depend on something outside of the GNU system? How is this different than, for example, Microsoft rewriting Office in Java? Fucking ridiculous.
  > But knowledge of Scheme and Scheme syntax is decreasing.
  Source for this bold statement?
8. Re:Perl??? by Anonymous Coward · 2013-02-17 19:33 · Score: 0
  
  It's a new strategy to keep the code 'free' - write everything in a scripting language that you can't compile even if you want to.
9. Re:Perl??? by Xtifr · 2013-02-17 21:00 · Score: 1
  
  How is perl any more "outside of the GNU system" than TeX? Which is, after all, what texinfo is based on.
  The GNU project's goal is to implement a free OS. Not to re-invent every wheel. (Except for the kernel, but that's just follow-through--work on the GNU kernel started before other free kernels were available.) Perl has a GNU-compatible license--why shouldn't they use it?
  Eventually, they'll make guile able to interpet perl code, and the problem will solve itself. :)
10. Re:Perl??? by HyperQuantum · 2013-02-18 00:16 · Score: 1
  
  GCC is C.
  Not anymore.
  
  --
  I am not really here right now.
11. Re:Perl??? by jbolden · 2013-02-18 00:29 · Score: 1
  
  Fair enough I meant it aims at low level high performance languages.
12. Re:Perl??? by mark-t · 2013-02-18 03:51 · Score: 1
  
  Possibly... but here they just made a crappy choice period. And the fact that it's not even really part of GNU means that they don't even have an excuse for it other than ignorance.
  Perl is not a remotely elegant or clean language to develop in, and I have completely lost count of the number of projects I've seen written in it, as they evolved, showed a distinct propensity to quickly *DE*volve into an undecipherable mess. It's a language that is best avoided in the 21st century, because there are many alternatives, equally free, and equally, if not more, useful.
  
  --
  File under 'M' for 'Manic ranting'
13. Re:Perl??? by mark-t · 2013-02-18 08:49 · Score: 1
  
  It isn't. But Perl is an utterly abysmal programming language choice.
  The fact that Perl isn't even a GNU project means that they don't even have an excuse of wanting to stick with GNU for picking a crappy language to work with! If they were going to go outside GNU, there were dozens of free languages that they could have picked that would have been a better choice.
  Honestly, about the only worse programming language choice I think they could have made is if they decided to redo TeXinfo in COBOL.
  
  --
  File under 'M' for 'Manic ranting'
14. Re:Perl??? by Xtifr · 2013-02-18 10:01 · Score: 1
  
  It isn't. But Perl is an utterly abysmal programming language choice.
  
  I suspect the person who wrote the code disagrees--or else he would have used a different language. Working code trumps theoretical BS and religious language wars any day in the real world. If you hate perl so much, write your own version in your own preferred language, and offer it to GNU and see what they say. If you're not willing to put your code where your mouth is, though, then your opinion isn't worth squat.
  And for the record, I disagree as well. Perl has plenty of warts, but it's got plenty of strengths as well. It wouldn't be my first choice these days, but it's powerful and expressive and can be perfectly straightforward. I do slightly prefer python, but I consider both languages fairly annoying, albeit for almost completely opposite reasons.
  Heck, name a language, and I can probably give you a lengthy list of reasons why that language is an "utterly abysmal programming language choice". :)
15. Re:Perl??? by mark-t · 2013-02-18 12:00 · Score: 1
  
  I'm generally not big on language bashing, but the biggest problem I have with Perl is with its complexity, having numerous operators and several special syntaxes. What this almost invariably means is that you can get short, but extremely complex code with many syntax errors which take some time to understand. Even worse, it often also means that reading someone else's code is difficult, and often maintenance of somebody else's Perl project can be an intractable problem. While it's entirely possible to write difficult to understand code in any language, everything that I have ever seen in Perl seems to indicate that the language, through its complexity and especially because of the many operators is possesses, practically encourages people to write extremely terse, and correspondingly highly obfuscated programs to all but extremely trained people who more than likely would have learned Perl when there weren't that many other options for things like web cgi.
  But legacy code maintenance is generally considered an entry-level position, and it stands to reason that people maintaining the code that one writes today will not have as much experience the one creating it for the first time. As such, clarity is paramount. Perl does not achieve this.
  I would maintain that this reason is an objectively valid reason to disregard this language as viable in the 21st century, where there are many other choices.... its best use today should only be that of maintaining older software that was already developed in it... not the writing of new stuff.
  
  --
  File under 'M' for 'Manic ranting'
Speed. by Atzanteol · 2013-02-17 11:52 · Score: 3, Interesting

I love how a language that was "fast enough" in the '90s is now suddenly "too slow" in 2013.
What's with the "I need all my code hyper-optimized" crowd on /. these days? We running a Gentoo help forum I didn't notice?

--
"Ignorance more frequently begets confidence than does knowledge"

- Charles Darwin
1. Re:Speed. by Anonymous Coward · 2013-02-17 11:54 · Score: 2, Insightful
  
  I love how a language that was "fast enough" in the '90s is now suddenly "too slow" in 2013.
  No-one said it was "too slow", if they thought that they wouldn't have released it. They said it was slower than the C version, which is (presumably, as I haven't measured it myself) an objective fact.
2. Re:Speed. by Sulphur · 2013-02-17 14:54 · Score: 2
  
  I love how a language that was "fast enough" in the '90s is now suddenly "too slow" in 2013.
  What's with the "I need all my code hyper-optimized" crowd on /. these days? We running a Gentoo help forum I didn't notice?
  Help me Obi Gentoo Kenobi. You're our only hope.
3. Re:Speed. by Anonymous Coward · 2013-02-18 02:45 · Score: 0
  
  Must be a noob gentoo forum, then. Gentoo is not for speed, it is for the build system (lets you choose version of each library, mix stable software for base system and cutting-edge version of gui software, and easiest access to source code of everything and seamless patching of the code -- just let your patch in your local tree, it will be applied at every version bump), the widest configuration choices even for basic components of the system (systemd/openrc, udev/eudev), the text-oriented configuration, the developer-oriented desktop (you always get the "developer packages", I mean what other distros seem to call "developer packages" and scrap in default installs).
Perl hater by Anonymous Coward · 2013-02-17 12:16 · Score: 0

Those script languages are for kids. Real men program in C, which is, basically, portable Assembly, the real deal.
1. Re:Perl hater by Anonymous Coward · 2013-02-17 12:22 · Score: 1
  
  Real men use an macros to create documentation.
2. Re:Perl hater by Anonymous Coward · 2013-02-17 12:59 · Score: 2, Funny
  
  That high-level C crap is for wannabes, son...real men create their programs in native binary by manipulating the bits on their drive platters with pointy magnets
3. Re:Perl hater by Anonymous Coward · 2013-02-17 17:51 · Score: 0
  
  Really? Gee, I always thought that real men saved the proving-their-manhood bit for when they're alone with their women, and during working hours just tried to write good code.
4. Re:Perl hater by Anonymous Coward · 2013-02-18 01:20 · Score: 0
  
  Manipulating bits on your drive platters is for wannabes, son ... real men create their programs by using butterflies.
5. Re:Perl hater by gorzek · 2013-02-18 04:09 · Score: 1
  
  Breaking them against wheels until the right bits fall out, I'm sure.
  
  --
  Check out my world simulator thingy.
6. Re:Perl hater by tibit · 2013-02-18 06:05 · Score: 4, Interesting
  
  I think that calling C "portable assembly" is really a bit untrue. One of the core features of most any machine language is that flags are part of the result of many computing operations. Yet C completely removes access to it.
  Suppose you have a code that adds two things, then jumps on overflow. On most machines that's two instructions if the operands have the right size. You look at it, and the intent is obvious: we add, then jump on overflow.
  Things are seriously wrong (IMHO) if a higher level language completely obfuscates this and requires code where it's not obvious at all what you mean! Heck, what's worse, each compiler likely requires slightly different code so that the meaning is extracted by the optimizer and the correct assembly output is produced without paying both code size and performance penalties! In C, the best you can do on a good compiler is to have an inlineable function that returns the numerical part of the result, uses comparisons to "recreate" the detection of overflow, and returns the overflow condition in a char* out-parameter. If the optimizer is good, it'll recognize that the out parameter accesses an automatic variable in the caller, and that your comparison is just checking for overflow. This code, while portable C, will perform horribly as soon as you compile it without state-of-the-art optimization capabilities. I'd think that means that if your compiler wasn't released in the last year or two, and isn't a mainstream decently optimizing one (like gcc, llvm, visual studio), you're out of luck. On many platforms a saturating increment/decrement is also two or three assembly instructions at most, without jumps -- but good luck getting a compiler to actually emit such code.
  I think that providing no way to access the flags part of arithmetic operation results is one of the biggest oversights in C. I'd think that every platform C runs on provides such flags.
  
  --
  A successful API design takes a mixture of software design and pedagogy.
Do not want by GlobalEcho · 2013-02-17 12:38 · Score: 5, Insightful

Allow me to initiate the inevitable hatefest:
Every time I run man and get a pointer to texinfo, I want to beat my head on the keyboard. I do not have the time, once again, to look up those obscure keyboard commands so that I may navigate laboriously through the documentation. It's time to interrupt my command-line workflow, go to the nearest GUI and run a web search for the nearest HTML manual.
1. Re:Do not want by one+eyed+kangaroo · 2013-02-17 13:10 · Score: 2
  
  I'm with you. The GNU folks we are told "in general, abhor man pages, and create info documents instead.". Tis a shame.
2. Re:Do not want by ls671 · 2013-02-17 13:18 · Score: 1
  
  This, exactly this.
  
  --
  Everything I write is lies, read between the lines.
3. Re:Do not want by Nimey · 2013-02-17 13:21 · Score: 3, Insightful
  
  Agreed. The worst is when a package has a half-assed manpage that points to the info documentation, and when you fire up info it's the exact same stuff as the manpage.
  Texinfo should be retired in favor of HTML for when there's too much documentation for a man page.
  
  --
  Hail Eris, full of mischief...
  
  E pluribus sanguinem
4. Re:Do not want by Anonymous Coward · 2013-02-17 13:23 · Score: 2, Interesting
  
  Both texinfo and man have their place. texinfo is good for learning the deep details of a product. man pages are good for quick "what was that option for doing X again?" checks.
  The attitude of the FSF towards man pages is, to put it politely, stupid. And counterproductive. Damnit, the response to a bug report saying "the man page is out of date/inaccurate/incorrect" should be to fix the damn man page, not to remove it!
  Don't get me wrong, there are times when the texinfo documentation is incredibly useful, and I like having it available ... but I like having quick references as well!
5. Re:Do not want by Anonymous Coward · 2013-02-17 13:24 · Score: 0
  
  man works great for simple commands, but what about complex hairy ones like gcc or gdb (which are really applications), or even 'find'. Then man starts to break down. You want formatted documentation with examples with variables spelled with more than a single letter.
6. Re:Do not want by Chris+Mattern · 2013-02-17 13:30 · Score: 1
  
  texinfo is good for learning the deep details of a product.
  No, it's not. It is clunky and difficult to navigate. A set of linked HTML pages would be good for learning the deep details of a product. Texinfo is just crap.
7. Re:Do not want by nielsm · 2013-02-17 13:39 · Score: 1
  
  No, it's not. It is clunky and difficult to navigate. A set of linked HTML pages would be good for learning the deep details of a product. Texinfo is just crap.
  Isn't that a property of the `info` reader and not so much a property of the format? The idea is good, the user interface is horrible.
8. Re:Do not want by Nimey · 2013-02-17 13:44 · Score: 1
  
  The format exists because of the reader. It has no particular practical advantages vs. HTML so there's no reason for either.
  
  --
  Hail Eris, full of mischief...
  
  E pluribus sanguinem
9. Re:Do not want by Chris+Mattern · 2013-02-17 13:44 · Score: 1
  
  And what other reader is there other than 'info'? They should use the version of the idea that already some some (relatively) non-crap user interfaces available: HTML.
10. Re:Do not want by Nimey · 2013-02-17 13:45 · Score: 1
  
  Right, and it's a lot nicer to read complex documentation through your web browser than through some clunky ncurses utility.
  
  --
  Hail Eris, full of mischief...
  
  E pluribus sanguinem
11. Re:Do not want by Anonymous Coward · 2013-02-17 13:49 · Score: 0
  
  What I really fucking hate is when you read "this man page is a stub, for full documentation see the info pages", and when you do all you get is a texinfo'd version of the man page.
12. Re:Do not want by Anonymous Coward · 2013-02-17 14:08 · Score: 0
  
  exactly
  fuck "info" pages
  nobody likes or uses that shit
13. Re:Do not want by Anonymous Coward · 2013-02-17 14:16 · Score: 0
  
  There is never too much documentation for a man page. Just look at the Perl manpages!
14. Re:Do not want by sombragris · 2013-02-17 14:31 · Score: 5, Informative
  
  Try pinfo. From the description:
  
  Pinfo is an info file viewer. It was created when the author, Przemek Borys, was very depressed trying to read gtk info entries using the standard tools.
  Pinfo is similar in use to lynx. It has similar key movements, and gives similar intuition. You just move across info nodes, and select links, follow them... Well, you know how it is when you view html with lynx. :) It supports as many colors as it could.
  Believe me, it's a lifesaver for reading info pages.
  
  --
  -- Look to the Rose that blows about us--"Lo, Laughing," she says, "into the World I blow..."
15. Re:Do not want by jones_supa · 2013-02-17 14:32 · Score: 1
  
  Allow me to initiate the inevitable hatefest:
  Every time I run man and get a pointer to texinfo, I want to beat my head on the keyboard. I do not have the time, once again, to look up those obscure keyboard commands so that I may navigate laboriously through the documentation. It's time to interrupt my command-line workflow, go to the nearest GUI and run a web search for the nearest HTML manual.
  Thank you, sir. That's something I would have said myself precisely like that.
16. Re:Do not want by swillden · 2013-02-17 14:42 · Score: 4, Funny
  
  I do not have the time, once again, to look up those obscure keyboard commands so that I may navigate laboriously through the documentation.
  What obscure keyboard commands? They're just the keybindings for the help system of the One True Editor. If you are using something inferior and have therefore memorized some truly obscure keyboard commands instead, how is that their fault?
  
  --
  Note to ACs: I usually delete AC replies without reading them. If you want to talk to me, log in.
17. Re:Do not want by jbolden · 2013-02-17 14:51 · Score: 1
  
  Well you can use info to read man pages and then you'll know those keywords when you need them. :) But yeah texinfo is a pain.
18. Re:Do not want by Anonymous Coward · 2013-02-17 14:58 · Score: 2, Funny
  
  What obscure keyboard commands? They're just the keybindings for the help system of the One True Editor.
  You, sir, have no idea what the One True Editor actually is:
  http://www.gnu.org/fun/jokes/ed-msg.html
19. Re:Do not want by jbolden · 2013-02-17 14:58 · Score: 1
  
  Thank you! That was neat didn't know about that one.
20. Re:Do not want by murdocj · 2013-02-17 15:30 · Score: 1
  
  Because lord knows, open source is all about choice.
21. Re:Do not want by Unknown+Lamer · 2013-02-17 15:30 · Score: 1
  
  IGGT 1/10
  
  --
  
  HAL 7000, fewer features than the HAL 9000, but just as homicidal!
22. Re:Do not want by dbIII · 2013-02-17 15:33 · Score: 4, Insightful
  
  It was even worse when you type "man foo", get a message telling you man is evil and to use info, then the info gives you nothing but a placeholder. The gnome stuff was full of that (gconf stuff especially) before they decided to not even bother pretending they had documentation.
  Back in the day doing "man grub", getting a rude message to use info, then "info grub" and getting a "grub is wonderful LILO sux" message and no documentation was definitely one of those moments where I wanted to beat somebody's head with a model M keyboard.
  At least "pinfo" can be used without having to spend more time working out how to use the info tool than reading the documentation.
23. Re:Do not want by ais523 · 2013-02-17 15:48 · Score: 3, Informative
  
  info shows the manpage by default if the info documentation isn't installed. So what you're seeing is probably a packaging problem, where the documentation exists but, for whatever reason (perhaps you're using a Debian-based distro and forgot to explicitly ask for it), wasn't installed on your computer.
  
  --
  (1)DOCOMEFROM!2~.2'~#1WHILE:1<-"'?.1$.2'~'"':1/.1$.2'~#0"$#65535'"$"'"'&.1$.2'~'#0$#65535'"$#0'~#32767$#1"
24. Re:Do not want by ais523 · 2013-02-17 15:53 · Score: 2
  
  Regex search over the entire info document is something I use a lot, and HTML doesn't (natively) support. (Index search via typing the name of an index entry, and then jumping to other entries that match the same string, is another thing that HTML doesn't do well.) These are arguably deficiencies in HTML, and could be fixed with mindboggling amounts of JavaScript or by doing things server-side, but both seem to be missing the point to some extent.
  I've been reading a lot of info pages recently, and learning the viewer was worth the effort (tip that helps a lot: 'l' undoes navigation commands, for when you've got completely lost due to pressing the wrong button). It'd be great if we had something that replaces Info without all its conveniences, but sadly nothing seems to have obsoleted it yet.
  
  --
  (1)DOCOMEFROM!2~.2'~#1WHILE:1<-"'?.1$.2'~'"':1/.1$.2'~#0"$#65535'"$"'"'&.1$.2'~'#0$#65535'"$#0'~#32767$#1"
25. Re:Do not want by Nimey · 2013-02-17 16:00 · Score: 1
  
  Kill yourself.
  
  --
  Hail Eris, full of mischief...
  
  E pluribus sanguinem
26. Re:Do not want by chronokitsune3233 · 2013-02-17 16:22 · Score: 1
  (warning: rant follows)
  Nearest HTML manual...generated using info2html. Seriously, using the mouse will interrupt your workflow as well because it takes more time to scroll and slide and click than it does to press keys.
  By the way, here's a quick list of key bindings for you:
  
  u: Up to the parent node if it exists
  n: Next sibling node if it exists
  p: Previous sibling node if it exists
  C-s*: initiate/repeat a case-insensitive forward Search throughout the documentation
  C-r*: initiate/repeat a case-insensitive Reverse search
  Arrow keys, Page Up/Down: move as expected
  C-n, C-p, C-v, M-v: Next line, Previous line, Page Down, Page Up
  Tab - move to the next cross-reference after the current cursor position
  M-Tab - move to the next cross-reference before the current cursor position
  Enter/Return - activate the cross-reference the cursor position is inside, navigating to the node to which it points
  * - In the standalone info browser, it's actually a regexp I-search while in the info browser in GNU Emacs, it's just a string I-search; use C-M-s and C-M-r in GNU Emacs.
  By the way, C is the Control key. Also, M is the Meta key, which is bound to the Esc key. You can also use the Alt key instead of Esc, but this may pass the key combination such as M-Tab as Alt-Tab in a GUI environment, so the Esc key works best.
  Overall, both man pages and info documentation have their places. I personally feel that it's simply a case of knowing where certain information fits in a certain medium. You wouldn't use an encyclopedia to find a definition or a dictionary to learn about the variety of bears throughout the world, so why would you expect every bit of library documentation to be in man pages?
  --
  I have been a captive in America my entire life. Everybody and everything uses customary units instead of metric.
27. Re:Do not want by Anonymous Coward · 2013-02-17 16:59 · Score: 0
  
  Emacs
28. Re:Do not want by fa2k · 2013-02-17 22:01 · Score: 1
  
  It's weird, I've seen a reference to texinfo many times while using man, but I have never actually followed through. Texinfo was just the weird disclaimer on some man pages to me. I just did info grub now, and it's not that bad if you stick to page up / page down and searching, like with man. Maybe I'll start actually using the texinfo pages now...
29. Re:Do not want by Anonymous Coward · 2013-02-17 22:41 · Score: 0
  
  Allow me to initiate the inevitable hatefest:
  Every time I run man and get a pointer to texinfo, I want to beat my head on the keyboard. I do not have the time, once again, to look up those obscure keyboard commands so that I may navigate laboriously through the documentation. It's time to interrupt my command-line workflow, go to the nearest GUI and run a web search for the nearest HTML manual.
  If you actually read the documentation, you would find that there is a "--vi-keys" flag to the standalone info reader allowing you to use the same keys as less/vi/etc.
30. Re:Do not want by Anonymous Coward · 2013-02-18 00:12 · Score: 0
  
  WhineWhineWhine
  all you really need to browse info docs (on a default ub untu install ) is
  -arrow keys (cursor movement)
  -enter key (follow link)
  -'u' (go one level up)
  Now that's not so very hard now is it?
  And it is *much* better than html manuals, (doxygen *shudder* ) where each manual has its own conventions and I need to use the mouse to browse through.
  HMTL could do the job , but you would need to agree on a default subset of html, and a default formatting with a clear hierachy. And I would like a viewer which supports better keyboard navigation. I suppose HTML + conventions + lynx could emulate info, but the main advantage of info is that it forces everybody to use the same layout.
  All the whiners are just scared when they see a textmode app :-)
31. Re:Do not want by flyingfsck · 2013-02-18 03:28 · Score: 1
  
  Goddammit, and I thought edlin was bad.
  
  --
  Excuse me, but please get off my Pennisetum Clandestinum, eh!
32. Re:Do not want by gorzek · 2013-02-18 04:43 · Score: 1
  
  Choice for the developer, not the end user. The end user is stuck with whatever the developer picked. ;)
  
  --
  Check out my world simulator thingy.
33. Re:Do not want by Rozzin · 2013-02-18 05:52 · Score: 1
  
  Every time I run man and get a pointer to texinfo, I want to beat my head on the keyboard. I do not have the time, once again, to look up those obscure keyboard commands so that I may navigate laboriously through the documentation.
  Then just pipe it through your pager, and you'll have basically the exact same experience as if it was a man page. e.g.:
  
  info info | less
  OK?
  
  --
  -rozzin.
34. Re:Do not want by Anonymous Coward · 2013-02-18 06:09 · Score: 0
  
  Why aren't you using BSD?
35. Re:Do not want by Trogre · 2013-02-18 07:51 · Score: 1
  
  HTML that still renders legibly in a text terminal, that is. Test case: lynx
  
  --
  "Nine times out of ten, starting a fire is not the best way to solve the problem." - my wife
36. Re:Do not want by Nimey · 2013-02-18 07:55 · Score: 1
  
  Naturally. I wouldn't necessarily restrict it to just lynx, though; there are at least two other families of decent ncurses browsers (links, w3m) and they can handle complex pages better.
  
  --
  Hail Eris, full of mischief...
  
  E pluribus sanguinem
HTML from the 1990s by tepples · 2013-02-17 12:50 · Score: 4, Insightful

The 1990s, when HTML documents were readable and not stuffed to the gills with ads and social recommendation detritus. Really all a plain-jane HTML document is missing is a max-width:36em on body to make line lengths sane and a width=device-width on the viewport to make tablets not render it zoomed out.
1. Re:HTML from the 1990s by tibit · 2013-02-18 05:43 · Score: 1
  
  This is perhaps the most informative thing I've read all day. Thanks!
  
  --
  A successful API design takes a mixture of software design and pedagogy.
Archaic and unfree. by Anonymous Coward · 2013-02-17 13:06 · Score: 0

Who needs this? Why?
Who prints to dead trees these days?
Better to use the modern Web stack instead.
WebKit / Chromium has an almost-entirely-copyfree implementation of HTML5, SVG, MathML, etc.
For an easier syntax there are things like Markdown.
For ye olde UNIX man pages, there's now mandoc.
--libman
It would be nice if... by Anonymous Coward · 2013-02-17 13:25 · Score: 0

Textinfo actually said anything useful. Man certainly isn't the best documentation on the planet, but fucking hell, document command line switches, at least.
1. Re:It would be nice if... by Anonymous Coward · 2013-02-17 14:47 · Score: 0
  
  PowerShell is super. Detailed documentation, always plenty of good examples.
So... by viperidaenz · 2013-02-17 13:26 · Score: 1

How do you compile the documentation when you're building Perl's prerequisites from source?
This reminds me of a Dilbert strip. by sidragon.net · 2013-02-17 13:37 · Score: 1, Funny

Let me get this straight. These guys ported and anachronistic piece of software from one dead language to a slightly less dead language, and then bragged about using structured programming techniques as a feature.
Hang on, I think Scott Adams has something to say about this.
http://dilbert.com/strips/comic/2013-02-11/
1. Re:This reminds me of a Dilbert strip. by Trepidity · 2013-02-17 16:03 · Score: 1
  
  As an aficionado of old computers, I feel this strip really speaks to me...
  
  --
  10 PRINT CHR$(205.5+RND(1)); : GOTO 10
2. Re:This reminds me of a Dilbert strip. by JDG1980 · 2013-02-17 16:59 · Score: 1
  
  Let me get this straight. These guys ported and anachronistic piece of software from one dead language to a slightly less dead language
  C is by no means a dead language.
3. Re:This reminds me of a Dilbert strip. by Anonymous Coward · 2013-02-18 04:27 · Score: 0
  
  Perl is dead. Well, not so much dead as very much alive. Hundreds of thousands of people can dance with Perl, dance around in circles, around the people who claim Perl is dead... Getting more and more user groups and workshops and conferences every year. Proud to be Perl.
4. Re:This reminds me of a Dilbert strip. by Anonymous Coward · 2013-02-18 04:32 · Score: 0
  
  Don't feed the trolls. Let them die hungry. Dead trolls are the only good trolls.
5. Re:This reminds me of a Dilbert strip. by Anonymous Coward · 2013-02-18 05:13 · Score: 0
  
  Great! That means you're no competition to some of us who've figured out that modern tools save time and facilitate higher quality products. While you're busy figuring out how to publish rich REST APIs or tracking down a memory leak, the rest of us will be shipping software.
  Enjoy your GDB sessions.
Oblig oblig XKCD by swm · 2013-02-17 13:58 · Score: 3, Funny

Lisp
http://xkcd.com/224/
1. Re:Oblig oblig XKCD by Unknown+Lamer · 2013-02-17 15:25 · Score: 4, Interesting
  
  What I find interesting about this Perl rewrite is that Guile, ostensibly the official scripting language of GNU, has had excellent structured texinfo support for years now. It uses stexi which has the same structure as sxml, so you gain access to all of the really great Scheme XML processing tools, including SXSLT which is basically ideal for spitting out arbitrary formats.
  
  --
  
  HAL 7000, fewer features than the HAL 9000, but just as homicidal!
2. Re:Oblig oblig XKCD by TheRaven64 · 2013-02-17 20:25 · Score: 3, Insightful
  
  Being the official anything of the GNU project pretty much guarantees that no other part of the GNU project will use your stuff.
  
  --
  I am TheRaven on Soylent News
3. Re:Oblig oblig XKCD by LizardKing · 2013-02-17 22:20 · Score: 3, Informative
  
  Whenever I install Debian or a derivative of it, I always find it includes Guile, but that no packages depend on it. The only reason it exists is because RMS didn't like Tcl, which was the up and coming glue language at the time. Despite its shortcomings, Tcl was a very nice language to extend, whereas Guile was (and probably still is) an incomplete dialect of Scheme that only satisfies the Lisp obsessives.
4. Re:Oblig oblig XKCD by fatphil · 2013-02-17 23:41 · Score: 1
  
  Debian stable:
  
  $ dpkg -l | grep guile
  $
  
  To be honest, I have written a few programs in tcl, and it was a very clumsy syntax that I had to fight with constantly. I have better experiences with LUA, but wish they'd stopped adding "meta" smarts to it earlier than they did, they went a bit over-the-top.
  
  Of course, in the real world I just hack everything in Perl still no matter what other scripting languages come and go...
  
  --
  Also FatPhil on SoylentNews, id 863
"Cleaner code" and "Perl" on the same paragraph? by Anonymous Coward · 2013-02-17 13:58 · Score: 1

MWHAHAHAhahahahHAHhaHahAHahAHahAHa.
oxymoron by csumpi · 2013-02-17 14:05 · Score: 2, Informative

...perl...cleaner code...
1. Re:oxymoron by tyrione · 2013-02-17 16:58 · Score: 2
  
  ...perl...cleaner code...
  True, not to mention with C11 you get Unicode and much more. C resurgence as a popular language is widely quantifiable. Perl as a dying language is widely quantifiable.
2. Re:oxymoron by arielCo · 2013-02-17 17:06 · Score: 2
  
  No oxymoron here. Perl frees you to create real messes, but that's mostly because it's very expressive, which also helps you code with less temp variables, shorter loops, etc., which can be actually easier to read if you know the language (Perl has a higher "cognitive load" than other languages that may alienate casual participants).
  OTOH there are best-practices and style guides to ease things for the next lucky person to read your masterpiece (possibly a future you). So don't blame the language; hell, there's even a module that critiques your code.
  So with some discipline and common programmer smarts you can write succint code that may be more readable than "fluffier" implementations. In practice, I've found that in any language, superfluous steps and variables, bad naming, and not-so-logical flow is a bigger penalty to readability than anything else. No language forces good style on you.
  
  --
  This post contains no rudeness or derision of any kind. All arguments are friendly. Terms and exclusions may apply.
3. Re:oxymoron by Anonymous Coward · 2013-02-17 20:15 · Score: 1
  
  Having too many ways to express the same thing and a huge amount of implicit meaning IS the weakness of Perl.
  That's what makes it so hard to write clean code in Perl, even worse than C. You just detailed why we understand this as an oxymoron.
4. Re:oxymoron by Anonymous Coward · 2013-02-17 22:00 · Score: 0
  
  Just because there's more than one way to do it, doesn't mean you should do it every way. Quoting from the wiki:
  
  [T]he point is to use the first way that occurs to you. Often this will be the SimplestThingThatCouldPossiblyWork, and any given programmer will probably be fairly consistent.
5. Re:oxymoron by arielCo · 2013-02-18 00:04 · Score: 1
  
  That TIMTOWTDI meme is somewhat exaggerated, and not the same as expressiveness (which is what I was talking aboui). Likely, among the 3-4 ways that you may find to do something, some are obsolete or too complicated, some are misleading to anyone else reading the code, and you're left with one that's simple and "natural" for your purpose. Let me explain:
  
  for ($i = 0; $i < $#names; $i++) { . . . $names[$i] = transform( $names[$i] ); . . . }
  
  An atavism from C, unneccessary in Perl.
  
  map { . . . $_ = transform($_) . . . } @names;
  
  As the name suggests, map() is most useful to do something (hopefully short) to every member of a list and get a second list with the results, at the price of putting your variable at the end, so why?
  
  for (@names) { . . . $_ = transform($_); . . . }
  
  A-ha! Plus, if you're already using $_ because you're inside a typical while(<>){...} loop, you can always use another variable for iterating through @names.
  This "good taste" is acquired after a bit of experience. Maybe it's a bit like cooking - you have so much available and no book could tell you all good combinations or all the bad ones.
  
  --
  This post contains no rudeness or derision of any kind. All arguments are friendly. Terms and exclusions may apply.
6. Re:oxymoron by Anonymous Coward · 2013-02-18 02:13 · Score: 0
  
  As if that's a defense. You've obviously been drinking the same kool-aid as Larry Wall. "Perl is very EXPRESSIVE, that means it's of course very easy for someone to write Perl that works but is a completely unreadable mess! That's not a problem, it's a FEATURE!"
  "Higher cognitive load," indeed, this whole post smells like a load. Probably related closely to the orifice you pulled that explanation out of. Python, there, a language that forces good style on you for better or worse. I don't even like it, but at least if you read a mess of a Python script you know it will be indented properly. Thank heaven for small miracles, and dead Perl programmers.
7. Re:oxymoron by Anonymous Coward · 2013-02-18 04:24 · Score: 0
  
  Don't feed the trolls who try to feast on Perl... since Perl is very much alive and will feed of dead trolls, like it has to be.
8. Re:oxymoron by arielCo · 2013-02-18 08:49 · Score: 1
  
  *sigh* ... I can hardly defend something that's not under attack. I posted some information that may or may not be useful to someone afraid of Perl, and it's up to said person to consider it, take it at face value, or throw it away with prejudice. Everyone is free to use it even if someone else hates it or trolls against it, and I'm happy using it for what it's good for. Cheers.
  
  --
  This post contains no rudeness or derision of any kind. All arguments are friendly. Terms and exclusions may apply.
perl dependency by manu0601 · 2013-02-17 14:33 · Score: 2

Now we will have a perl dependency for all GNU stuff, and this to read documentation that is even less nice to read than man pages. The best thing they could have done to texinfo is to get rid of it, IMO.
1. Re:perl dependency by Anonymous Coward · 2013-02-17 22:33 · Score: 0
  Now we will have a perl dependency for all GNU stuff, and this to read documentation that is even less nice to read than man pages. The best thing they could have done to texinfo is to get rid of it, IMO.
  You do realize that this dependency is:
  
  Only needed to build the documentation, and
  Man pages, as a rule, aren't hyperlinked, and are generally more concise.
2. Re:perl dependency by Anonymous Coward · 2013-02-18 06:17 · Score: 0
  
  automake already depends on Perl.
3. Re:perl dependency by manu0601 · 2013-02-18 14:18 · Score: 1
  
  Right, I did nor realize it was only for building the doc. The info(1) command is still in C?
  Man page concision is an advantage, IMO. The info pages are so confusing that I never use them. When I need some GNU in info format, I read it online using a browser.
texinfo is good for writing documentation by Per+Bothner · 2013-02-17 15:14 · Score: 2

Texinfo is is a decent format for writing documentation in - nicer and less verbose than HTML or DocBook. You can generate either HTML or DocBook or XML from Texinfo, and then do a bunch of processing on it. For example the documentation for Kawa is written in texinfo, then makeinfo converts it to docbook, which is then converted to html. The result isn't splashy but (if I say so myself) fairly nice.
1. Re:texinfo is good for writing documentation by Anonymous Coward · 2013-02-17 15:21 · Score: 0
  
  It looks like vomit but at least it's a bit easier to navigate.
2. Re:texinfo is good for writing documentation by Zontar+The+Mindless · 2013-02-17 18:19 · Score: 1
  
  Texinfo is is a decent format for writing documentation in - nicer and less verbose than HTML or DocBook.
  You have got to be kidding. That's true only in the sense that making the trip from Stockholm to Vladivostok via dogsled might be a "decent" mode of travel.
  Aside from the fact that it's Just Plain Horrid(TM) to read or write in source format, TexInfo suffers from the same problem that HTML does: No semantics.
  The reason that DocBook is so "verbose" is that it actually indicates what things are.
  And knowing what things are can be very helpful.
  
  --
  Il n'y a pas de Planet B.
3. Re:texinfo is good for writing documentation by Per+Bothner · 2013-02-17 19:28 · Score: 1
  
  Aside from the fact that it's Just Plain Horrid(TM) to read or write in source format, TexInfo suffers from the same problem that HTML does: No semantics.
  You don't seem to know much about Texinfo. It is definitely very much about semantics - quite like DocBook. I agree DocBook takes the semantics thing slightly further than Texinfo - but it has big holes too: For example DocBook doesn't have a standard way to specify the structure of a command/function synopsis except for the C language.
  The reason that DocBook is so "verbose" is that it actually indicates what things are.
  One reason DocBook is so verbose is because it is XML, which by definition is verbose and human-unfriendly.
  I've written plenty of documentation in both Texinfo and DocBook. They're both reasonable formats, but it is clear that DocBook is very tedious if you have to write it "by hand" rather than use a word-processor. Texinfo is much easier to both read and write, and it handles the "semantics" pretty well.
4. Re:texinfo is good for writing documentation by fatphil · 2013-02-18 00:23 · Score: 1
  
  It's clear that DocBook was written by a couple of groups who each had their own documentation needs in mind. So firstly there are more-than-one-way-to-do-similar-things clashes, and if you're not trying to write something that's just like one, and only one, of theirs - you'll end up with a bit of a 3-legged camel.
  
  --
  Also FatPhil on SoylentNews, id 863
Just an End User by rueger · 2013-02-17 18:45 · Score: 3, Interesting

I very happily gave up on man pages (and variants thereof) years ago because they were too obtuse and circular to be useful to me, a mere end user. Early on I figured out that the basic rule of man pages was that the one you need relied on you already having read and digested fifteen others, each of which relied on you having read an digested fifteen others.... actually finding what you needed was an endless exercise in frustration.

Google + Forums is what real people rely on.

--
Three Squirrels
1. Re:Just an End User by Anonymous Coward · 2013-02-17 23:33 · Score: 0
  
  You mean Google+Forums people rely on other kind people who have read the man pages. Great way to build a civilization.
2. Re:Just an End User by flyingfsck · 2013-02-18 03:35 · Score: 1
  
  Oh my goodness, you also started with Caldera. I salute you my dear sir...
  
  --
  Excuse me, but please get off my Pennisetum Clandestinum, eh!
3. Re:Just an End User by Anonymous Coward · 2013-02-18 05:09 · Score: 0
  
  That's kinda what compiling things that rely on a lot of libraries from scratch feels like, except that after 5 hours of getting it to "compile" it'll just show some error nobody can possibly understand and you just give up and delete the working folder, just to try again the "right way" and get the same results.
4. Re:Just an End User by Anonymous Coward · 2013-02-18 09:18 · Score: 0
  
  Google + Forums is what real people rely on.
  So man/info users are what, cartoon characters?
Compile to HTML instead by Anonymous Coward · 2013-02-17 18:59 · Score: 0

That would have been a lifesaver...
I have always hated texinfo by e70838 · 2013-02-17 20:24 · Score: 2

It has been used as a pretext for not providing correct man pages. For example man sed:
COMMAND SYNOPSIS
This is just a brief synopsis of sed commands to serve as a reminder to those who
already know sed; other documentation (such as the texinfo document) must be con-
sulted for fuller descriptions.

When I have learned unix, man pages were complete, concise, accurate and uptodate documentation of all the system. I feel that because of this textinfo mess, man pages on Linux are incomplete and vague and that the documentation dislayed by info is not very clear.
1. Re:I have always hated texinfo by Anonymous Coward · 2013-02-17 22:04 · Score: 0
  
  When I have learned unix, man pages were complete, concise, accurate and uptodate documentation of all the system. I feel that because of this textinfo mess, man pages on Linux are incomplete and vague and that the documentation dislayed by info is not very clear.
  Have you tried to continue using unix?
2. Re:I have always hated texinfo by Anonymous Coward · 2013-02-17 23:41 · Score: 0
  
  To be frank: if it's man pages you want, the very best Unix-alike OS out there is probably OpenBSD (maybe one of the other BSDs.) They consider man pages to be the definitive source of information on their userland utilities; if a man page is wrong, or missing information, it will be fixed when it gets noticed.
  Linux's man pages are very hit and miss, which is a very real shame.
3. Re:I have always hated texinfo by e70838 · 2013-02-18 00:16 · Score: 1
  
  This net bsd documentation of sed is incredibly better that the one I have on Linux. It is almost perfect. In 5 minutes, I have found only one point of ambiguity: it says it is a superset of posix.2, but I do not find the possibility to use a dash instead of a file to mean stdin. Maybe there are others issues, but this is clearly a better documentation (should I switch to netbsd ?).
4. Re:I have always hated texinfo by Anonymous Coward · 2013-02-18 20:05 · Score: 0
  
  You should find man pages to be roughly the same quality on any of the four major BSDs, so you are free to choose. Subjectively, I'm finding OpenBSD's and NetBSD's to be the easiest to read.
  (GNU has a beef against man pages -- many of their utilities have zero. They've been betting heavily on texinfo for the past ten plus years.)
HTML 2 by SgtChaireBourne · 2013-02-17 20:59 · Score: 2

I'd rather see the format scrapped and replaced with either better man pages or else HTML2. With HTML 2 you can use a text based browser like Lynx, which is more polished and gives you better navigation capabilities. There are also more modules, libraries and packages that can work directly with HTML, so less time is spent trying to reinvent the wheel.

--
Beta is broken and the link to classic doesn't work. Stop wasting our time or there won't be anybody left here.
Comment removed by account_deleted · 2013-02-18 02:51 · Score: 1

Comment removed based on user account deletion