chandler

>> Damn, why didn't I realize this was happening?

We're not really encouraged to be introspective--we're pushed from one experience to the next, without stopping to think how the experience affects us.

Moreover, unless you put in the time to assimilate your experiences (why did I behave this way? why did I react this way? why did this trigger emotion X? etc), you're unlikely to have these self-reflective a-ha moments.

Where I work, I've noticed several trends:

- Duplicate work; as long as the wiki doesn't replace existing processes, placing things there is simply additional work. Moreover, because it's additional, there's no guarantee that any desired piece of information will exist in the wiki.

- People don't like not having an "owner" to a document, especially regarding private edits and such.

- Wiki's make you search for a topic (i.e. they require work), whereas email threads are pushed to you by others motivated enough to CC. Unfortunately, my motivation in tracking an issue will never be the same as the person directly affected by the issue.

- Mostly, however, wiki's don't provide a substantial functionality improvement to what I'm now going to dub the "enterprise wiki": i.e., Word documents on a shared drive. Here, Windows provides structure (well, technically Solaris does, but it's accessed by the user via Windows Explorer), while Word provides the standard document editing interface (although we do work with many document types).

The main drawbacks are terrible search, manual (and content limited) revision control, and an inability to track updates.

The main upsides are a rich editing environment for documents (compare Word to a textarea), support for any document format (don't like doc files? Use something else), and the opportunity for private collaboration & edits without implementing temporary ACLs (i.e., copy a file to the local drive, and email back and forth until publishable).

Personally, I think wiki's are great for collaboration between a heterogeneous, dispersed population. However, at the large corporation where I work, Word + Explorer is a ironic example of the worse-is-better Unix approach (many tools, barely working together) clearly beating the wiki/web-based Monolithic design.

>> Then maybe I'm misunderstanding the point of your reply.

I was pointing out that your examples don't make sense, as it's trivial to translate the Haskell code into another general purpose language (such as Scheme, C, Perl, Fortran, etc), while impossible to translate into an eager (strictly evaluated) language (such as...?).

Additionally, the reason monads are cumbersome in other languages has nothing to do with eager/lazy evaluation, or conditional computation, and everything to do with the fact that monads exist in Haskell to solve it's sequencing problem (arising from the fact that it's a declarative language). Imperative languages have no problem with sequencing, and therefore have no need for monads.

Agreed; neither of the translations use monads, because monads are a semantic hand-job proscribing order within a declarative language. However, Scheme is not a declarative language, therefore order is implied in the structure, therefore monads aren't necessary.

>> Your print-n-times doesn't return an action...

Nope, look again. It returns the results of applying `void'. Who knows what (void) may return in a loosely-typed language?

>> ...it's an imperative function that performs an action.

Well, considering Scheme is an imperative language with side-effects, it's hard to dodge such criticism.

>> The naive translations to Scheme would be as follows...

That's not a translation from Haskell to Scheme, that's writing Haskell using a prefix syntax.

>> Also, both your examples rely heavily on non-strict evaluation. 'and' and 'or' are both macros that non-strictly evaluate expressions.

I went back and re-read your original post:

>> ...you'll note that the translation, strictly evaluated, gives infinite recursion.

Mea culpa--I completely missed your point that translating from a turing complete language to a non-turing complete language might have some pitfalls.

The first example, naively translated to scheme, results in:

    (define (skip-many a)
      (or (and (a) (skip-many a))
          (void)))

This is not infinite recursion. The Parser monad used in the Haskell version is simply a stream dressed in monadic clothes (and even C has streams a-la FILE*).

As for the second example, the naive translation to scheme is:

    (define (print-n-times n s)
      (cond 
        ((zero? n) (void))
        (else (put-str-ln s)
              (print-n-times (sub1 n) s))))

Here, both Haskell & scheme demonstrate constant memory usage; not because of Monads, or strict/lazy evaluation, but because of tail recursion.

Also, in your first sentence, I think you meant "strict".

I do like the idea; however, the site has aesthetic flaws that need to be addressed.

Notice a site like adagio.com (which sells loose teas): earthy colors combined with attractive closeups of leaves & herbs.

As a tea drinker, the design & color scheme you've chosen really does put me off. Remembering that tea is typically made by steeping leaves, buds, and flowers from nature itself, the abstract graphics and pale blue/white motif feels wrong.

Also, the example recipe on the front page (in addition to many of the contributed recipes) remind me of noncarbonated sodas (or nonalcoholic cocktails), not teas; very sugary, and reliant on extracts and juices (whipped cream?) for flavor. Perhaps you could seed the "teas" section with actual tea blends?

If bottle failures are contained within the sacks this shouldn't be necessary. If bottle failures aren't contained within the sacks...well, good luck.

The logical solution would be to have a depth marker of some kind, and to simply add new sacks of bottles whenever it drops below some value (regardless of the cause of the drop).

> If it's a "lines of code" contest, then sure, learn to type fast, but if it's about producing good concise code I don't think typing speed makes much difference.

In my experience, good, concise code is rarely written on the first pass. Also (and unfortunately), more often than not people who don't type well are unwilling to spend time on rewrites...

Whether it's fair or not, I can only knowledgeably critique what I know. However, I've heard (and propogated) this basic comment describing the robust solid development experience that is Visual Studio for more years than VS.NET (or, obviously, 2008) has been around.

(Not that VS6 is terrible--I still think it's a serviceable IDE for small to medium sized projects. However, it doesn't scale well to our large projects, and, personally, I've found that IDEs in general foster a lazy attitude towards improving personal workflow)

It's specifically at two points of the build--firstly, when VS6 is starting the compile (and trying to find modified files, I suppose), and during the link step.

I think the IDE is doing something with the toolchain to give it an incredibly high priority (and therefore build faster). The only evidence I have for that is a) command-line compiles take longer than they do through the IDE (using msdev to process the dsp file, not using nmake/cl/link), and b) windows messages (e.g. Send/PostEvent) don't seem to be processed during the link stage.

Regarding the Intellisense bit, you've reminded me of our "process" used to fix VS when it stops compiling files correctly: try deleting all our non-source controlled files (which includes the VS specific databases for things like classwizard, object files, etc) and see if that fixes things. If not, then restart.

People who use IDEs that add code for them.

Reading these posts about the "excellent, bug free" VS development environment: in my experience, this isn't quite the truth.

I've used VS6 since the late 90's, mostly on small projects (less than ~10 000 lines, four or five source files) until 2004, where I signed up to work maintenance on what is essentially a very large codebase (thousands of source files, between 500-50 000 lines per file). In 2006, my frustration with VS6's inability to handle a codebase of this magnitude finally convinced me to try a different IDE toolset. My specific complaints:

- Starting VS6 is slow, and brings the computer to a halt.

- Compiling & linking through the IDE is slow, and brings my computer to a halt. This doesn't happen when run from the commandline, nor, as follows, from a subprocess within Emacs.

- Intellisense stops working a lot; nothing breaks programming flow like having your favorite crutch be unavailable for half the methods (this seems to affect large files more than small). Incidentally, though Emacs has Intellisense type functionality, I much prefer the generic completion available in Emacs/Vim (M-/ in Emacs, Ctrl-N in Vim), as it works within comments and for undefined/undeclared (and unprocessed) structures.

- The method navigation panel fails often, with it listing a method correctly, but displaying "method not found" when selected (the workaround is to select different methods until one is found, then jump around the file for the desired method). I suspect this is related to the parser not handling default arguments correctly in certain cases.

Finally, VS is the only application that has blue-screened my XP machine (this happened only twice, however, and wasn't involved in my decision to migrate to a different toolset).

Regarding software, either you bend software to meet your needs, or it bends you to meet its limitations. Unfortunately, because VS has a high difficulty regarding the former, I found I was consistently having to integrate workarounds into my day to day coding practices.

>> High rates of heart disease in indian vegetarians...

Have you ever been to an Indian restaurant and ordered a vegetarian meal? While incredibly flavorful, I wouldn't classify it as even moderately healthy--

I doubt I'd recommend replacing fat with carbohydrates, but you're correct in that sugars (starches/carbohydrates break down into...) cause the body to store fat (more specifically, the elevated insulin levels that accompany this).

Regarding weight loss: I work & exercise with a variety of body types (these body types have people names too!), and, within this small sample, I've found that the dominating factor in overall weight is diet, not exercise.

Essentially, exercise controls muscle tone and how "tight" the skin is, while diet seems to control the overall body shape.

>> (or perhaps only hidden until after you vote but I don't see why they need to be there period)

That's an interesting point--why does every site need to quantify for the user the particular score of a comment? Why not indicate popularity by simply ordering the comments?

Is it a trust issue?

Personally, it seems that increasing the number of displayed words allows me to process the text much faster. For instance, I can comfortably read and (mostly) comprehend at ~400 wpm when 30 words are displayed on screen at a time, while with only 1 word-per-frame I'm struggling to read and have zero comprehension.

Comprehension-wise, at the 30 wpf setting, the trouble seems to be when the app splits at sentence boundaries.

It's very interesting that this simple tool gives me personal insight into how I visually process texts.

>> This is a more radical version of the panspermia theory of Crick and Ponampurama ... I think in a hundred years if people do biology they will think it quite silly that people once thought that spores could not be blown from one star system to another by cosmic radiation pressure.

Fungi adapt to feed off radiation? Terence McKenna would be amused.

Exactly; for me, there are periods where my work is challenging and interesting and I have no desire to code outside the office. Conversely there are lulls where I'm flooded with ideas for personal projects, and suddenly have energy and motivation to work these.

It comes and it goes.

> T: <some description involving unverifiable supernatural beings>

Just to argue the point, how do you define supernatural? Where do you draw the line between natural-yet-incomprehensible-phenomena and that-which-is-only-imagination?

>> (which executed Lisp directly)

Uh, the machine's architectures were probably designed to be more amenable to Lisp-esque features (e.g., garbage collection, tagged types at runtime, native pair operations, etc); I suspect the machines didn't execute Lisp directly for the same reason that an x86 doesn't execute C directly...

You're right, that is interesting--yet another reason to get Xen up and running...

I agree with much of your position, however:

> Some people say Ubuntu is finally a usable desktop OS for average Joe. Even if that's true, it took how many decades for free operating systems to reach that mark? They're at least 20 years behind in crossing the line...

Let's look at those 20 years up to the release of XP--would you consider (any flavor of) DOS usable for the average Joe? What about Win95/98, with its dll issues and where simply browsing the internet would blue-screen a computer?

Fact is, by todays standards, it took Microsoft ~20 years to have something suitable for the average Joe.

Additionally, ironically, Free Software is the main advantage Ubuntu has over something like XP/Vista regarding usability for the average. Having a centralized index of freely available software, all of which is downloaded/installed/patched on a regular basis using a unified interface is huge.

(not that a payment system is wholly incompatible with a centralized software repository, but it certainly would be difficult to unify proprietary software due in no small part to the wide variety of DRM implementations)

I didn't like the shell either, until I realized that it's still an editable buffer.

For example, you can take the output of a command, transform the text directly using standard editing commands, fix the weird one-off cases manually, and then pass the results back to the command prompt. Or save the results to a file. Or interleave with code. (etc)

Turning the entire shell into a fully editable/scriptable/keyboard-macro-able scratchpad is a beautiful thing.

Regular disclaimer: I use both vim and emacs equally, and there definitely some things I prefer in vim. However...

> 1) Several options...

One of the nice things about the help in emacs is that, when installed with source, function/variable lookup allows you to jump directly to the implementation from the help page, modify the code, and have the new implementation running in-line. This is useful for both one-off changes to built-ins (just re-evaluate the function), and for immediately fixing bugs in your own scripts as you find them.

> 4) When I first read about this, I was immediately interested. For similar functionality (couldn't claim whether or not it was the SAME, strictly, as I don't actually use Emacs)...

Emacs's kill-ring and mark-ring are actually two separate things--the kill-ring is as you described, while the mark-ring is akin to having a web-browser's "back" button while editing text (e.g., edit some text in a function at the bottom of a file, jump to a separate function, edit some text; typing C-u C-space will then jump back to the original function).

> 6) Sad to say I'm at a loss here -- not to say vim couldn't do this, but rather I've never needed to do this in my range of experiences...

At work we have some servers which have only basic unix commands on them (they're also on a separate floor); it's much nicer to be able to edit files on my workstation using tramp (with vim, there's equivalent functionality, e.g. ftp://user:pass@hostname/path/to/file) than to deal with uploading/downloading files and trying to determine whether the server/my client has the more recent changes.

I suspect it also develops flexibility of the tendons/ligaments.

Excepting the terrible execution, http://expertvillage.com seems to have a variety of how-tos.

So I'm curious--the screenshot you've taken has ~20k less results than mine, and the result-set is wildly different--

> Interesting angle, but I really don't believe nastiness has much to do with it.

My experience is that this is a limitation of communication without subtext, inflection, etc. I don't have a whole lot of time right now for details, but I have noticed a few tendencies that exacerbate emotions in online discussions:

- Deprecating humor seems especially biting without the wink and smile, and the inevitable response from others then appears like an attack

- Posters lump all critics together, and tend to forget who made which argument (but are especially sensitive to having their points glossed over, misinterpreted)

- Often those within technical circles don't realize that different people weigh evidence differently (i.e., two parties may reach separate conclusions simply because they have differing views of which facts are important). Unlike in the math world, discussions and conclusions cannot be reduced to a few simple axioms--there's always the experience of the observer necessary to interpret data.

- There's a tendency to skim critics posts and respond to individual sentences/words (rather than the sum of what was actually written).

Your Kitchen:

> Tortillas, yogurt

You can make:

> Dog Food

You will also need:

> Dog Food

...? Excellent.