Elegant code is...

• Simple -- leveraging the "natural" way to use the programming language
• Compact -- not cluttered with special cases and boilerplate
• Logical -- like secondary documentation, acting as a clear description of how to solve a problem
• Modular -- functions or classes should be clearly grouped as modules
• Easy to understand -- not full of stupid hacks and "clever" tricks
• Reasonably efficient -- performing reasonably well, not at the expense of simplicity
• Maintainable -- any decent programmer could pick up the code without fear and trepidation
• Commented -- some comments should be present, but not too much
• Correct -- it should do what it is meant to do, and only this

There are also some languages that I view as inherently elegant, and others that I consider not to be so. C, Python, and Ruby all allow breathtaking elegance in their own way. C with its spartan manner of managing the machine, Python with its ridiculously readable pseudocode-like syntax, and Ruby with its pure object system and powers of abstraction. On the other hand, some other languages like C++, Java, Haskell, Javascript, PHP, BASIC, and Erlang will never be languages that lend themselves to true beauty and elegance. All of those languages either have serious flaws, or they do not allow programmers to express their ideas eloquently in code. In a good language, your ideas should pop out as the most important thing, not the language itself.

Great news for anyone who is interested in classic Unix desktop software. For many years, CDE was the standard Unix desktop environment, but one that was always missing from Linux and BSD. Having CDE as open source brings one of the last few pieces of proprietary software into the free Unixes, and it's nice to see that developers are hard at work fixing bugs and improving portability. Congrats to the CDE team for this release.

This is an article helping people understand more about tools that ship in OpenBSD, and how they can be used in neat ways. Maybe you don't find anything informative or interesting, but I did and many others may too. Computing is a broad field, and not everyone has exposure to these networking tools. This is the sort of thing that should be on Slashdot, rather than "Why aren't there more female computer science majors so we can drive down wages?" type of "news items."

You may want to read the article before jumping to conclusions. The authors have identified many of the plants and animals as those of the New World, including specific breeds of cattle introduced from Spain, animals like the Ocelot, and others. Their study is very thorough, and it includes study of texts they have found with similar scripts and languages. Their conclusion is that it came from 16th century Spain, and was written in an Aztec language by natives who had been educated by the Spanish (and their evidence for this is quite convincing). From the conclusion of the research:

We note that the style of the drawings in the Voynich Ms. is similar to 16th century codices from Mexico (e.g., Codex Cruz-Badianus). With this prompt, we have identified a total of 37 of the 303 plants illustrated in the Voynich Ms. (roughly 12.5% of the total), the six principal animals, and the single illustrated mineral. The primary geographical distribution of these materials, identified so far, is from Texas, west to California, south to Nicaragua, pointing to a botanic garden in central Mexico, quite possibly Huaztepec (Morelos). A search of surviving codices and manuscripts from Nueva España in the 16th century, reveals the calligraphy of the Voynich Ms. to be similar to the Codex Osuna (1563-1566, Mexico City). Loan-words for the plant and animal names have been identified from Classical Nahuatl, Spanish, Taino, and Mixtec. The main text, however, seems to be in an extinct dialect of Nahuatl from central Mexico, possibly Morelos or Puebla.

I wrote to Timothy some of my recommendations in this comment), and it seems that some major ones have been addressed -- including the layout and amount of text that is visible. I don't know if that was in response to what I wrote, but either way I appreciate it. At this point, fixing Beta must be the most thankless job on Earth. ;-)

One other big recommendation I have is to not show pictures by default (icons are okay). Often these images are not directly related to the article, so they are just there to add some color to the screen, at the expense of the article text itself. (1) Maybe it's asking too much for the pictures to simply "go away" if they are unnecessary, but I think that would be positive. (2) Another option might be to default the users who are not logged in to see pictures, while default the readers who logged in to seeing just the text. The idea would be if you are not logged in, you're a peon who enjoys colorful irrelevant pictures, whereas if you are logged in, you just want to read the article. (3) Another possibility, the simplest, would be to resize these thumbnails to be smaller, so they intrude less on the article text. Ideas #1 and #3 would be the simplest approaches.

I think addressing the image thing would be a big improvement to Beta, and is one of the major things at the heart of what all the protest is about. Basically, that Slashdot as a technical site is about text, not just a slideshow of pretty pictures. Slashdot can keep pictures, but they should be resized appropriately since they are not really the point of the site (just colorful distractions).

I was reading this review of Slashdot Beta made last October, which shows a variety of screenshots and also has explanations from Timothy in it.

http://www.tweaktown.com/news/33368/slashdot-launches-redesigned-website-in-beta-form-we-check-it-out/index.html

Honestly, I was impressed by at least some of the reasoning, and I can see how some changes would actually be positive. The problem, though, is that not all the changes are good, and it's far too much at once. There is a potential to lose what is special about Slashdot including its moderation system. They need to examine Beta and see and what needs to change for it to be accepted by the Slashdot community. Off the top of my head:

1. Less whitespace, fewer pictures: Slashdot is all about the text and what the community writes here. It needs to be clear and easy to see a lot of information at one time. How many times do we have to say this? Just change the fucking CSS already.
2. The moderation system needs to either stay the same or change only slightly. Major changes are going to disrupt the community and the flow of the discussion. Nobody wants Slashdot reduced to +1 and -1 like this is Facebook and we're all retards posting pictures of hamburgers and ugly babies.
3. It would be nice if someone from Dice had the balls or the ovaries enough to make a formal apology to the community about how this has been handled. This isn't all Timothy's problem, and he shouldn't have to take all the heat. The future direction of Slashdot is the responsibility of Dice and Alice, so they should be responding and taking responsibility.
4. Stop forcing everyone to switch over and stop forcing redirection until the actual site is finished. To do otherwise is confusing and disrespectful. Wait until you have a finished product.
5. Do a better job explaining everything to the community and respecting the community. Hell, we would be doing a lot of this work for you and making recommendations for you, but Beta was forced on everyone without proper feedback (not to mention the fact that Beta is still unusable and broken).

Here's a real and serious recommendation for Timothy if he wants Beta to eventually succeed without disrupting the Slashdot community: do redirections one day out of the week, and on that one day, have a story posted by Timothy asking the community for feedback -- one day each week for experimentation ("Slashdot Labs Day"). Then for the next 6 days, they can fix the site, while readers continue to use the classic interface. Keep doing that until the big problems in Beta are ironed out and the community is halfway satisfied with it. That is seriously a simple and reliable way that they could fix this and make people happy again. You can take that one to the bank. Unfortunately I don't know if they have the sense to do so because they haven't accepted feedback very well and they haven't kept in contact with the community.