User talk:Dkf

Welcome to Rosetta Code! My name is Mike Mol, and I write C++, Perl and PHP for a living in a small shop catering to specialized industries. I'm the guy on top around here, but, honestly, I do what I can to avoid interfering with the activity of the site. I watch the Recent Changes feed and step in if I feel my input is needed, or if I simply have questions of the folks involved in an existing disucssion. Otherwise, I just keep the server running and try to help the site grow. If you have any questions, drop a line in my talk page or the Village Pump. Chances are, Mwned, Paddy, Kevin Reid, Shin, Neville, PauliKL, MBishop, Ce, IanOsgood or any of the other regulars around here will have input for you, and I don't often disagree. If you need something from me specifically, well, I'm on break for the next twenty or so seconds. :) --Short Circuit 00:17, 13 May 2009 (UTC)

Ok but

Ok, but this page exists for a reason, and now Object Serialization is there since I've added needs-review (and now I see someone put an incorrect with explanation); both enough to see the page where people should look to fix things. If you want a special "note" for you, you can watch the page... I've a lot of watched pages, there just to rimind me that I've something to do on them, even though still I've not done that something. I believe the categories should be left alone (unless you want to add specific info about the Tcl language, not about specific example). Anyway this is just my opinion. --ShinTakezou 11:14, 14 May 2009 (UTC)

There's a pool of people doing things for Tcl; the reminder is not just for me, but for others too. (Don't worry so much about transient things, OK?) —Dkf 12:07, 14 May 2009 (UTC)

Isn't this enough? (It already automatically contained the task, even though the page wasn't edited; now it is). I am not worried, tried just to keep things clean and coherent (even though it is not my busyness maybe) --ShinTakezou 13:13, 14 May 2009 (UTC)

It's all gone now anyway. —Dkf 12:37, 15 May 2009 (UTC)

That's a good point, though; That should probably get linked to in the language template. Take a gander at the new beta language template staging ground, and see what you can do. Also see if you can add it to the header template for the unimplemented in X pages. --Short Circuit 22:24, 15 May 2009 (UTC)

Language Comparison Table

Hi Donal. Could you have a look at the Language Comparison Table? I had a crack at it a while ago, but I'm sure it would benefit from your perusal. Cheers. --glennj 18:14, 12 June 2009 (UTC)

If you do make changes, could you make corresponding changes to the language pages using the parameters in the language template? Thanks. --Mwn3d 18:31, 12 June 2009 (UTC)

I already was maintaining the parameters in the language template, and the LCT only needed a minor correction (nothing which I thought needed a real change elsewhere). There is a discussion/justification of the categorization parameters on Category talk:Tcl...

Overlapping divs

If you change to the rosetta theme (which I thought was supposed to be default by now) a lot (if not all) of the overlapping div box problems are resolved. --Mwn3d 21:46, 17 June 2009 (UTC)

I merely use the default theme, like most visitors to the site will. —Donal Fellows 21:48, 17 June 2009 (UTC)

I've stopped seriously thinking about the Rosetta Theme myself. I like the colors, layout and text styles, but it has compatibility issues with IE6 that I couldn't get around last time I had time to spend on it. (IE 6 is my current oldest IE browser target. Sadly, I expect it to continue to be fairly common for several more years. It currently accounts for 34% of IE visits, and IE visits account for 22% of overall visits. Oddly enough, IE6 is the version of IE where the user is most likely to go on and use the site, and the most likely version of IE where the user will go on and edit a page. ) Whatever the bit is that fixes the overlapping divs, that should go in MediaWiki:Common.css. --Short Circuit 03:56, 18 June 2009 (UTC)

RCHQ9+/Tcl garbled?

It appears your cut and paste didn't translate well -- the switch statement has gotten garbled. --glennj 20:34, 22 July 2009 (UTC)

nevermind, I see the talk page there.

Ethiopian Multiplication reformat

Liked it. Thanks! --Paddy3118 11:26, 23 July 2009 (UTC)

Your discussion about J

"it's clear that excessive terseness is an issue with J code"

This can be an issue with any kind of code but I'd like to give you an e-high-five for recognizing it with J and pointing it out. --Mwn3d 12:42, 31 August 2009 (UTC)

I believe people are mis-identifying a vocabulary problem, here. People have problems reading J, people see J is terse, people think their problem is J's terseness. But, they would have the same problems, or worse problems, if J was not terse. (Given any J expression, expanding it into a more verbose expression is a trivial exercise. But you still need to know what the words mean, no matter how they are spelled.) Meanwhile, teaching J to non-programmers is easy, but teaching J to programmers can be difficult because programmers "know" things they learned from other languages -- things which usually turn out to be mistakes, in J (for example: how to implement algorithms efficiently using loops or recursion -- that said, programmers with some background in SQL might be more comfortable with this issue). Rdm 21:10, 31 August 2009 (UTC)

The more I write code and work with other peoples', the more I find that terseness isn't a virtue. Clarity of expression is much better, especially since its usually the case that clear code is easier for compilers/optimizers to do something good with. The other thing I've learned (and keep learning) is that getting over clever is not a good idea if it just ends up defeating the hardware's cache management; the core of the Tcl string map command is very stupidly implemented, but switching to a fancy Rabin-Karp implementation was actually a slow down in practice because of the overhead of building the matchers and the difference in memory access patterns. Doing it the stupid way worked best because it allowed the hardware L1 cache predictor in modern CPUs to function most effectively; a real eye opener that indicates why its always worth measuring performance rather than guessing!

I suppose it all comes down to the principle of always try the simplest clearest thing that could possibly work, as that's the best option in such a huge number of cases. And there's a real tendency of many programmers (yes, myself included) to lose sight of these things. Which brings us back to J. They've clearly chosen to go down the short/very expressive path, and the language will attract a number of very smart people who will do amazing things with it in very little code. But they'll only ever attract the very smart, and the very smart are known for being fickle. The language is doomed to remain esoteric, rather like APL. —Donal Fellows 14:27, 31 August 2009 (UTC)