.'"". I LIKE PYTHON BECAUSE I ENJOY HOMOSEXUAL
c' )"/ S/M. OH GUIDO MAKE ME USE THAT FUCKING
__> /_ INDENTATION. OH BABY I'M CUMMING.
.-`_ ._'-.
( -' \ :/ )/ THERE IS ONLY ONE WAY TO DO IT: GUIDO'S
\\._| ( // WAY! THAT MEANS YOU CAN'T USE ALL
'-/) \(, CONTROL STRUCTURES. IF YOU NEED A DO-
/ ) ) WHILE LOOP, A SWITCH OR BREAK OUT OF A
/ .'\ | NESTED LOOP, TOO BAD. GUIDO SAYS IT'S TO
/.' \| KEEP THE LANGUAGE CLEAN, BUT IT'S ACTUALLY
|| || TO PUNISN HIS SLAVES. THIS DOESN'T MEAN
__|/ |/__ THAT PYTHON IS FLAWED, JUST WORK AROUND IT.
_._) (,__; FUCK I'M CUMMING AGAIN.
Javadocs are still the best organized, easy to use, and more importantly easy to create documentation system around, and I've used/made man pages, used MSDN's shit, and various others that fail even harder.
Name:
Anonymous2008-09-05 20:54
>>23
Oh, and I have no idea why Doxygen even exists. The vomit it produces is absolutely useless.
Javadoc sucks. Haven't used Apple's HeaderDoc because I'm not a macfag, but I bet it blows and tries to install a DRM service that will control how many times you can check the help for a function before paying.
The Python stuff is good for what it does, but it needs to come with a full-text search client. And it's horrible when you want to know how a function will react in edge cases, like what exceptions a function will cast. Javadoc is much better here of course, because of their Forced Handling of Exceptions, but at what cost?
I wish they'd do some static inference of this, with an option to supplement/override it in the doc.
Name:
Anonymous2008-09-07 15:04
>>33
One word: The forced handling of exceptions. Thread over.
Name:
Anonymous2008-09-07 15:13
Java needs less javadoc and more literate programming. If the person consuming the API docs can't read code, then what the hell are they going to do with the API docs in the first place?
>>36
Doesn't order hits on relevance, and is thus almost useless for finding the description of anything that is also used in a lot of example code elsewhere. And nice sage. Worst thread on the front page, I'm sure.
>>33 The Python stuff is good for what it does, but it needs to come with a full-text search client.
Make/adapt/use one yourself; it's not really realated to Python.
Javadoc is much better here of course, because of their Forced Handling of Exceptions, but at what cost?
At the cost of being a toy "best practices" enterprise language for morons and bad programmers, so it's a bad idea.
I wish they'd do some static inference of this, with an option to supplement/override it in the doc.
You can't trust static inference in a dynamic language.
>>36
Enjoy your O(1) search. Though nowadays it's fast enough for small and medium projects.
>>43
Honestly, I think that's pretty reasonable. The language itself lacks quite a few constructs to make the implementation really usable though -- the generics support is useless at best, and lack of first-class functions makes collection manipulation excessively verbose.
But as far as that example, it's a fairly sane code snippet.
Name:
Anonymous2008-09-08 20:18
>>43
The code itself is pretty concise, it just has a shitload of Javadoc comments.
Name:
Anonymous2008-09-08 20:33
>>44,45
The code itself is almost as concise as it could be, and pretty close to how I'd write a hashmap in Java, but it's still much longer than it has to be because Java is such a crap language. Literate programming in it is a pain in the ass compared to even Javadoc documentation.
Name:
Anonymous2008-09-08 20:45
`D\D\.-
(0.0 \
\`-'J )
- -\
(|| ( J_
c_|-c_J--,)
i am a JAVA. i ahev a long doc and i make programs w/ my API. if you dont repost this comment on 10 other pages i will hax your anus tonight and make a mess of your computer and ass
Name:
Anonymous2008-09-08 21:07
>>43 a good example of what's wrong with XML-based autodocumentation.
Not really. The docs aren't meant to be read in that format; they're pretty good in the normal browser.
No human should EVER have to be exposed to XML; it should be equated to hex dumps for usability purposes.
Name:
Anonymous2008-09-08 21:51
>>48
Yet the entire reason for using such a ridiculous format is so it can be read and manipulated in a text editor.
Name:
Anonymous2008-09-08 21:55
>>48
The docs aren't meant to be read in that format, but the source code is. They reduce the legibility of the source by cluttering everything up.
And they may not be meant to be read like that, but they're meant to be written like that.
>>51
Human readability is the most important reason XML was developed in the first place.
Honestly, the only sensible application I've ever seen of XML is XHTML. Which, I guess, makes sense.
Name:
Anonymous2008-09-08 23:40
>>44 useless at best
Useless how? It's far superior to SEPPLES' take on generic programming. I suppose the fact that Java generics are purely a compile-time construct is limiting somehow, but I haven't used anything with runtime generic type information, so I can't speak to the advantages of, say, C#'s approach.
>>53
Templates in Sepples aren't so much generics as they are a demented compile-time language which can be used to implement generics. Having a Turing-complete static language is fucking overkill, and opens the floodgates for terribly monstrous over-engineered attempts to add functionality to an otherwise lacking language (ie, Boost et al).
Java's generic support has the exact opposite problem -- they're just glorified type-checking sugar. There's no support to do any kind of compile-time specialization. Because all parametrized instances of a template are reduced via type erasure to the same class, you can't safely use static members of a generic class. Type erasure also means that you have to explicitly state which interfaces parameter types must implement before you can have any reasonable interaction with them.
Rather than comparing it to C# (since I don't really have much knowledge of C#'s generics, but I hear they've got some pretty cool shit in 3.5; too bad Mono's only at 2.0) which has a fairly similar generics model; I'd take it a step further and put Sepples/Java/C# generics next to a duck-typed language or a type-inferred language, which make everything essentially a generic, or allow implicit generics, respectively.
Name:
Anonymous2008-09-09 1:30
C# generics themselves didn't really change much for C# 3.0 (which ~= .NET 3.5), the main things were LINQ, extension methods and lambda stuff. Also, the Mono C# compiler now supports C# 3.0, even though its runtime is older (I think).
As I understand it, C#'s generics are slightly better than Java's in that reference types boil down to the same class but value types get their own optimized version (no boxing), though they don't actually permit any form of specialization.
Name:
Anonymous2008-09-09 17:10
>>54 Having a Turing-complete static language is fucking overkill, and opens the floodgates for terribly monstrous over-engineered attempts to add functionality to an otherwise lacking language
So, what you're saying is "Lisp macros considered harmful" ?
Name:
Anonymous2008-09-09 17:16
>>52
XHTML is pig disgusting and should never be used. Instead, try: HTML 5
>>60 XHTML without any of the elegance XHTML elegance
lol
Name:
Anonymous2008-09-09 19:57
>>63
1. Beauty is subjective.
2. It has more goals than just readibility. I cannot think of any other way to hierarchically markup some text and still remain as readable as XML.
>>67 1. Beauty is subjective.
Are you saying you've got an XML fetish, or just that there may be someone somewhere who does?
Name:
Anonymous2008-09-09 23:31
It compresses excellently. The problem is the decompression.
Name:
Anonymous2008-09-10 11:01
>>72
I don't care for the physical look of the textual elements ordered in the manner required to describe XML. I also happen to work well well with deeply nested Scheme code.
Name:
Anonymous2008-09-10 18:09
I'd like to work deeply nested in Leah Culver's Scheme code, if you know what I mean.