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)

F# RCSNUSP page

I implemented the bloated version and put it in, but the original comments had been placed under a different header and the little box that says "RCSNUSP/F Sharp is an implementation of SNUSP" is covering the edit button for the original comments so I can't change them. I took out the "program" header thinking that maybe that was the problem, but now both edit buttons are covered by their own little box which keeps me from doing any further editing. I don't really have anything more to edit here, but can you maybe see if you can do something about it for the future? Thanks and sorry to bother you. [Preceding comment was made on 14:20, 29 December 2009 by Darrellp]

All fixed up. Just had to move the <br clear=all> line up a little. I took the opportunity to add another heading for the Bloated impl too. –Donal Fellows 18:04, 29 December 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)

math

Fixed. --Michael Mol 05:49, 13 March 2010 (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)

Most of the J code presented in the RC J examples are considered good form - to J programmers. The main issue is that programmers familiar with other languages tend to expect an algorithm statement to have explicit iteration, and perhaps consume several lines of code. What is "good form" to a J programmer isn't necessarily easily readable to programmers familiar with scalar languages.

I agree with Donal Fellows, in that more detailed comments and algorithm explanations are required for every code example in the RC forum, since the whole point is to help readers unfamiliar with that specific language understand what is going on in the code. The more unconventional a language is, the more explanation required. Hence, J examples in RC should display good coding practices (for J) in the example, but that code example should also be accompanied with thorough explanations and comments, all of which should be more thorough than if the audience was just J programmers. For that matter, this advice should be applied for all RC code examples. Teledon 8:47am 13 October 2009

J symbols can easily be assigned English words, just as mathematical symbols can be assigned words.

For example, take the mathematical equation x = y ^ 2 + 3 * z

One can write this this in pure English as: "x equals y squared plus three times z"

However, this is not typically done, because the result is more verbose than necessary.

This is even more true with J. Take the J expression to calculate the average of a group of numbers:

avg =. +/ % #

avg 45 66 35 86 24

51.2

avg i. 100 NB. Find the average of the number sequence from 0 to 99

49.5

For "clarity", one could assign each J symbol or expression an English name:

sum_up_all_numbers =. +/

divide_by =. %

count_the_number_of_numbers =. #

Now we can write our J function in English words:

avg1 =. sum_up_all_numbers divide_by count_the_number_of_numbers

avg1 45 66 35 86 24

51.2

avg1 i. 100 NB. Find the average of the number sequence from 0 to 99

49.5

For someone not familiar with J, the English word approach may be easier to read. However, a typical J programmer would never do this, because it would require too much typing. Anyone marginally familiar with J symbols would immediately grasp the original code much quicker than the English translation. The correct form for J programs is to use the primitive J symbols, which will make the resulting code terse. For J programmers the terse form is much easier to read than an English-substitute version.

The issue here is: Just how far should the J programmer go towards expanding an elegant J expression into a verbose English translation, in order to help newbies understand what is going on? In my opinion, not very far. The whole purpose of an efficient notation is to allow a complex algorithm to be defined in a simple, concise way that can be scanned and understood in a single glance. It is true that this kind of proficiency in reading J code is not obtained overnight. However when one becomes proficient with J, you discover that you can deal with complex processes as a whole, that were not possible before you learned J. The notation you use to describe a problem shapes the way you think about the solution. J will change the way you think, and change how you approach the solution to problems. Whether this is good or bad depends on your viewpoint. Teledon 1:46 10 September 2009 (Skip Cave) Ref. Notation as a Tool of Thought (Iverson) - [1]

It's all your (collective) call. I'm just of the opinion that for the purposes of this site it is worth being more verbose than you otherwise would. Increased comment length is one of the best ways of doing this IMO (not that this is a specific comment). The other thing to watch for is where code is making use of assumptions that are obvious to experts in the implementation language, but which are mysterious to everyone else. Again, it's a universal problem but the more a language has implicit things, the harder it is to grasp a particular solution at a glance. (Of course, you and I probably differ over the definition of the correct level of implicit-ness, but that's just both of our opinions differing. I expect neither of us to change.) —Donal Fellows 08:20, 10 September 2009 (UTC)

GeSHi and Tcl

FYI, our Tcl langfile for GeSHi has issues with langcheck. Would you be interested in putting together a better language file? (This comment was made on 06:29, 13 December 2009 by User:Short Circuit)

I don't grasp what the nature of the failure is, but there are a number of things that ought to be done anyway; the set of useful things to highlight has evolved since the Tcl langfile was written and there's at least one significant issue that I know of (namespaced names highlight wrongly). Alas, I don't know how long it will take me though. –Donal Fellows 19:21, 13 December 2009 (UTC)

Just whip it together using AutoGeSHi and send the files my way. I'll drop them in for live testing, and we can iterate through it. :) --Michael Mol 21:36, 13 December 2009 (UTC)

The format of the file isn't the problem. Working out what exactly to put in there is. There are a number of syntactic tricky bits; cases where the language parser works a bit differently to most languages. The most noticeable ones are that the language has no keywords, and comments are handled during parsing, not lexing. Moreover, I've a lot of other things on right now at both work and home; no blame, but that's how it is. –Donal Fellows 23:11, 13 December 2009 (UTC)

You can always drop me a note at BenBE@geshi.org for some more information on what GeSHi expects in the langfile or how to do particular features. Depending on the issue I even might help a bit with putting together the RegExps and some other complex issues of the language file. As I don't know Tcl I won't be able to fix issues in the langfile though - I just can handle updates and testing things. In addition it's always good to get some example sources and a brief description of how it should look. --BenBE 03:12, 3 February 2010 (UTC)

User pages

Please don't edit user pages directly, even if they haven't created it yet. For something like that, I'd leave a friendly greeting and some advice in their user talk page. --Michael Mol 16:30, 23 December 2009 (UTC)

Question on Nan

One of the wonderful (or horrible - your call) properties of Tcl is that it is type-free. Or at least that's the way I understand it: everything is just strings of bytes; code, data, numbers, processes, text - at the bottom it's all just strings of bytes. Whether something is a "number" is an interpretation; "set a 5" creates a length-1 string containing the byte that can be interpreted as the ASCII symbol "5" or the number 5 (or any other way). So it would seem utterly natural to me to

(Tcl) 1 % package require Tcl 8.5
8.5.8
(Tcl) 2 % set nan NaN
NaN
(Tcl) 3 % expr {$nan+0}
can't use non-numeric floating-point value as operand of "+"

as opposed to, say

(Tcl) 4 % set nan Booger
Booger
(Tcl) 5 % expr {$nan+0}
can't use non-numeric string as operand of "+"

Because "NaN" can be interpreted as a number, while "Booger" has no such interpretation. (My 8-year old disagrees with this, by the way). I would maintain that "set nan NaN" does not only have the exact same outcome (generates the same result) as "binary scan [binary format q nan] q nan" but that it is actually more idiomatic, more Tcl'ish, more the way of "Tcl does what you expect".[Edit: sorry about that, wasn't logged in. That was me. :-) Sgeier 01:34, 20 July 2010 (UTC)]

Now that I'm not exhausted, I agree. :-) –Donal Fellows 06:03, 20 July 2010 (UTC)

Chime in on Hough Transform

Could you wander over to Talk:Hough_transform and chime in? I notice you're the originator of the task, and there's been a lot of interest in it lately. --Michael Mol 21:07, 9 August 2010 (UTC)

Filling out Rosetta Code:Add a Task

Could I get you, Rdm and Paddy3118 to give Rosetta Code:Add a Task a thorough treatment of examination, debate and filling? Of the cross section of current users, I think you three are probably the most likely to be familiar with the general pattern and concerns of creating tasks. I added a bunch of my own thoughts in HTML comments in-line, and left a note in the talk page. --Michael Mol 17:15, 21 September 2010 (UTC)