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 discussion. 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)

My aversion to terseness comes from working on supporting codes for multiple years. It's correct that the natural level of terseness varies with language though. —Donal Fellows 10:56, 1 September 2009 (UTC)

(Need input from all you folks watching the recent changes feed here) I have noticed that vocabulary makes J difficult for me to understand. Is J's vocabulary such that it could be compared or related to other languages on a word by word basis, such as what one might find in a dictionary equating words in one language with words in another? Even if there aren't direct word-word equations, can a word be described as a phrase in another language? I could see such a thing as being equivalent to a study guide, key or legend. --Short Circuit 14:47, 1 September 2009 (UTC)

There is the Vocabulary page of the J Dictionary, however the J Dictionary is not very enlightening for beginners - understandable given its primary purpose is to serve as a specification for the language implementation, rather than a study guide. Instead I'd recommend the book J for C programmers (available free online or as hard copy) as a well written intro to J and array languages, especially for those coming from scalar-oriented languages, not just C. Don't skip the Foreword!!. If you're wanting a Quick Reference, then I'd suggest the J Reference Card. --Tikkanz 21:53, 1 September 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)

I think terseness is a virtue unless it obscures clarity. As you point out it is usually best to make things simple. If you can express a concept in a couple of words rather than a couple of sentences it is easier to digest and quickly get a feel for what is important. Then you can start investigating the "but what if" questions. It is much quicker and easier to keep focused on answering those questions if getting the answer doesn't require you to write half a page of code first or think too much about the details of how the computer might implement it. One of the comments frequently made by people having learned J and APL, is how it helps them think differently about problems even when coding in scalar languages. You may find the following papers interesting: Notation as a Tool of Thought (Ken Iverson's Turing Award Lecture), Language as an Intellectual Tool: From Hieroglyphics to APL(4MB).

Of course as has been pointed out, you first have to learn the language. In the case of J (and APL), "learning the language" means just that (vocab, grammar, etc.), not just syntax. That doesn't mean it takes forever to gain any proficiency - just like any human language, you can usually get a lot of things done even with a limited vocabulary. --Tikkanz 23:13, 31 August 2009 (UTC)

Terseness has nothing to do with readability or understandability. Chinese ideograms provide one symbol for each complete word in the language, much like J or APL. Chinese text is extremely "terse" when compared to English, but I'm sure if you told a native Chinese that their language is harder to understand than English because it is too terse, they would disagree.

Readability/understandability of any text is simply a function of familiarity, not terseness. The reason that many common programming languages are "readable" to many programmers, is because one language will often use constructs that are similar to other languages, which the reader is already familiar with. The reason that J seems hard to read is because the reader doesn't understand the language, not because the language uses fewer symbols. J sacrificed similarity with scalar languages for the higher goal of a simple, consistent, precise, executable notation.

A similar argument can be made for comments. If the reader is very familiar with a specific programming language, well-written code in that language will self-describe its' processes to that reader. Of course, code can be written to disguise its function, and poorly-written code can still be difficult to read. Comments are still useful for readers who are not proficient with a specific language, but who must maintain that unfamiliar code. -- Teledon 1:46 1 September 2009

One of the key purposes of this site is to show to non-experts in a particular language how to use it to do tasks that they may understand from their knowledge of other languages. This suggests that using longer names and more comments than you otherwise would is likely to be a good plan... —Donal Fellows 10:56, 1 September 2009 (UTC)

I think Teledon has a point. J may well be great, but because it is so unlike the C and Lisp and forth based languages that I know more about, it remains impenetrable to me, and probably most other RC readers.

Even so, I think the J guys should write good, maintainable, idiomatic J and maybe help out us poor, non-J readers maybe by answering questions on the talk pages?

This sounds like a good idea, but how do we find the questions in a timely fashion? Perhaps we should introduce a new category (potentially for each language but of course also for J), for people to use when asking for clarification? Rdm 20:28, 2 September 2009 (UTC)

Like one of these? Category:Maintenance ... There are templates that put pages in there, but I don't recall offhand which put pages where. --Short Circuit 21:34, 2 September 2009 (UTC)

At one time I was in the Texas Instruments camp against the HP Reverse-Polish Notation calculators. Then I learnt all about Reverse-Polish when writing an interpreter and revisited my earlier conclusions on RPN and new that they were rubbish. Later, before I learnt a Lisp-like language I was careful not to reject their claims, and I did learn what made it so good to program in at the time. But now I prefer Python for most things, and am being 'tickled' by Haskell/OCaml/D/Oz. --Paddy3118 11:07, 1 September 2009 (UTC)

Writing code that is both idiomatic and maintainable is a good target. (Indeed, that's the case for any language but some have more of a culture of it than others.) Which leaves a suggested thing for the J community to do: go through the existing solutions in J and evaluate whether they are good style (from both technical and pedagogic perspectives, of course); I've already been doing this with the Tcl solutions, but I'm not in a position to be able to do it for every language. There's only a fixed number of hours in the day... ☺ —Donal Fellows 12:28, 1 September 2009 (UTC)