User talk:Duplode

Welcome message

Hello, and welcome to Wikibooks!

Here are some tips to help you get started:

• To learn the wiki-markup-language syntax, see Help:Editing.
• Make sure to sign your posts and comments with four tildes, like this: ~~~~
  • There is a box at the top of the edit window (if javascript is enabled on your browser) that will insert it too (looks like part of a signature). This will let others know who left it, and make it easy to reply back to you.
• Remember to conduct any editing experiments in the sandbox (global to the system) or in a page on your own userspace.
• Remember to use Commons project for image uploading.
• You can tell the community something about yourself in your userpage.
  • You can get to this page by clicking the tab at the top of the page labeled with your registered username.
• Wikibooks are open-source textbooks. (What is Wikibooks).
• If you are a Wikipedian, see Wikibooks:Wikibooks for Wikipedians for a primer on how things work here (it's a little different).
  • If you want to base your work here on materials from Wikipedia, please use WB:RFI.
• If you're an instructor and plan on using Wikibooks for a class project, see Wikibooks:Guidelines for class projects
• Please say hello at the Reading Room with any questions or ideas.
• Eventually, you might want to read the Manual of Style and Policies and Guidelines.
  • Help us by participating in policy and guideline creation.
  • Please take a look at Wikibooks:Naming policy before starting a new book.
• Remember to keep a Neutral point of view.
• Explore, be bold in editing pages, and have fun!

You will find more resources in Community Portal. If you have questions, visit the Study help desk, the Reading Room, IRC channel or ask me personally on my talk page. For site news, see the Bulletin board. It might be a good idea to add that page to your "watchlist" so that you can see when any new information is posted there. You can do that by clicking the tab labeled "watch" at the top of the page.

(This is not an automated message, I'll be watching during a time for any reply you make to it...)

Good luck! --Panic (talk) 08:32, 29 April 2010 (UTC)

Thanks! The great thing about editing Wikibooks is that it is much easier to contribute while you are still learning a subject, even if it is just by writing notes from your metaphorical (or real!) school notebook in the margins :-) --Duplode (talk) 13:17, 29 April 2010 (UTC)

Yup, but on the downside some aspects can be very obscure and consume to much time and attention from the real task of providing free content. In any case you are doing a great work handling it, keep it up :)... --Panic (talk) 19:57, 29 April 2010 (UTC)

Fun stuff

We have fun stuff like Wikibooks:Userboxes here too. :) -- Adrignola ^{talk contribs} 01:04, 17 May 2010 (UTC)

In fact I was about to phrase that as "you can find silly stuff...", but decided to tone down the cuteness a little bit :-) In any case now I will debut one userbox I have conceived here instead of in WP for good measure ;-) --Duplode (talk) 01:17, 17 May 2010 (UTC)

Re: Role playing games

Myfatson (talk) 01:11, 1 June 2010 (UTC) MYFATSON- Hi, I apologize for the PRINT (command) stub, you may delete it, I did not understand wikibooks and I am now getting serious. Thanks, myfatson...

Trans-wiki cooperation

If any of your contacts at Wikipedia stop by, I've worked to bring in {{WPBannerMeta}} so that they can more easily set up cross-project WikiProjects. – Adrignola ^{talk contribs} 21:29, 10 June 2010 (UTC)

That's very useful! I am going to mention it on the Village Pump thread (yes, it is still active). By the way, pretty much all of the concrete plans arising from that discussion were in the technical realm (integrated watchlists proposals, etc.) - it seems that those Wikipedians who embraced the idea of cross-projects could not find a concrete project/subject to propose the idea to. I am considering surveying topics in an attempt to find an ideal scenario - a promising but half-finished book that could be improved by a strong Wikipedia wikiproject - and then proposing collaboration at Wikipedia. A shot in the dark maybe, but things have to start from somewhere... --Duplode (talk) 05:12, 11 June 2010 (UTC)

Hey I don't know if your still interested in transwiki collaborations, but after my blowup and wikibreak I spent some time thinking about it, and I have at least one way people who would like to have a transwiki watchlist could build their own outside of the mediawiki software. In fact I have two methods for doing so, but both have the draw backs, and they are really the basically the same idea.

The idea is that a RSS/ATOM feed is generated both for someones watchlist and for recent changes. The recent changes feed is somewhat nicer because it contains diffs, where the watchlist feed just contains titles. The question becomes how does one filter a feed? I know of two methods, The first is to use Mozilla Thunderbird to read the feed, and it contains various conditionals that will let you move items to a somewhere else (aka an inbox you call "watchlist"). So you end up with some number of silly recent changes feeds which you don't look at a global watch list. This one I have tested personally and works well. The downside is you have to add the pages you want to watch by hand, the plus side is that it becomes easy to watch a whole book at once. On the other hand if you use your watchlist feed instead of recent changes, things will appear in your feed any time you add them to your watchlist on the site, but the watchlist feed doesn't contain diffs, only the page, most recent editor and most recent edit summary. So you need to actually follow the link back to the site to see what happened.

The second method which is the same as the first but probably less clumsy is to to use yahoo pipes to do the filtering. The downside to this over using Thunderbird is that you have to have an account with yahoo. On the other hand it may be more flexible. But I haven't test this option out as carefully, I just set up a silly test case to see if it would work.

Of course the optimal solution is if wikimedia set up something that would do it, but I won't hold my breath on that. Anyways I thought you might be interested. Thenub314 (talk) 05:56, 17 September 2010 (UTC)

Wikipedic creations

Messier Index (This is a great piece of work, done with much love for the subject matter) I believe it had some background on Wikipedia (refusal of the content). I'm mentioning here just not to cause unnecessary and premature RfD but because it illustrates well the issues we have. Now a parallel solution would be creating a specific namespace for those works on Wikibooks, especially for encyclopedic aggregations around specific subjects but then without a technological alteration that supports avoiding duplication of effort and content with Wikipedia I don't see it being possible to resolve. --Panic (discuss • contribs) 05:01, 7 November 2013 (UTC)

Interesting example indeed. In the Wikifiction discussion I mentioned the "restrictions of form" that apply to anything that is part of Wikibooks. The insight here, and it is a quite powerful one, is that there is no reason why there should be only one set of restrictions. We do not even need to depart from WB:WIW to see that "instructional books" could take a number of different forms (for obvious reasons, I am disregarding the textbooks-only literalist stance). In fact, Cookbook: and Wikijunior: are established instances of that already. Other possibilities of form codes - and, as you suggest, of namespaces - include (please forgive the uninspired names):

• Annex: (for appendixes and other auxiliary material that might be shared by different books - wasn't there a discussion about that years ago?)
• Primer: (for pamphlets and intentionally short books. The Messier example might be a case in point - in its talk page, Arjan says "I think this book should be short and to-the-point", presumably in contrast to the articles linked from w:List of Messier Objects);
• Perhaps even Universe: (for book-like fictional universe reference guides).

The open questions are what are the implications with respect to content overlap between sister wikis, including the decisions about what goes where and, as you point out, the technical needs to support reuse without duplication (i.e. something to the effect of cross-wiki transclusion). --Duplode (discuss • contribs) 06:51, 7 November 2013 (UTC)

In any case in any Wikifiction and Wikibooks discussion we may have there needs to be a better clarification of what would Wikifiction entail (what content it will support and why it can't be done on Wikipedia), and I don't think that this is yet fully established.

I like to use Wikipedia due to its centralized search capability (especially for fictional characters and plot summaries that link in site to real world sources, authors and similar creations), if encyclopedic articles start to fragment unnecessarily across projects this advantage is lost.

As for specific encyclopedic aggregations, yes we need some sort of cross-wiki transclusion, but I doubt that this alone prevents topic specific aggregation of articles since this can be done with a bit of goodwill on Wikipedia, for instance using the subject namespace...

(note that as I said before I'm not a Wikipedian so I don't really have a clue about previous discussions there, or at other Wikimedia projects on the subject)

I can see a monetary incentive to try to break fictional data away of Wikipedia. In the heads of market droids and sadly IP controllers that fear a public playing field, that tends to be leveled, and permits easy comparisons and background information and non-corporate sanction information. --Panic (discuss • contribs) 09:57, 7 November 2013 (UTC)

Inteview

Hi Duplode

We are two M.Sc. students looking for people to interview for our thesis. Would you be interested? it would help us a lot!

The interview is going to be about motivation to contribute top open educational resources, such as wikibooks.

Regards Otto Velander OXp1845 (discuss • contribs) 09:10, 28 April 2014 (UTC)

Hello Otto,

I will be glad to help. How do you plan holding the interview?

Cheers, Daniel (aka Duplode (discuss • contribs) 06:45, 29 April 2014 (UTC))

Hi Daniel, so glad that you are willing to help us!

We are interview people over skype, if you send me an email to ottve507@student.liu.se we can setup a time when we can talk. The interview doesn't take that long and will be fairly open.

Thanks again, Otto & Fredrik OXp1845 (discuss • contribs) 13:14, 29 April 2014 (UTC)

Okay, mail sent.--Duplode (discuss • contribs) 08:59, 1 May 2014 (UTC)

Organizing Haskell

Suggestion: 1. I think Monoids should be moved to Intermediate section. 2. Applicative Functors needs a rewrite so that it is up to the standards of the rest of the beginner's track, but that should be done with the plan of building directly on the stuff only through the intermediate section, and we should then put Applicative Functors into the Monads section as the first chapter there before introducing Monads themselves. We can reference then that Monads are Applicative Functors and that this will be recognized in GHC 7.10. Backfromquadrangle (discuss • contribs) 15:33, 14 May 2014 (UTC)

I was thinking about the pros and cons of both reorderings yesterday. It would make a lot of sense to move Monoids to Intermediate (it would be a second early example of a type class, and would make it easier to discuss things such as MonadPlus). My only worry is whether moving it mould force us to dilute the examples too much; perhaps not. We certainly would not be able to mention Foldable, Traversable or Writer, though that won't be much of a problem once they get their own chapters.

As for Applicative, the situation looks much trickier to me. It is clear that presenting Functor, Applicative and Monad in decreasing order of generality would make some discussions less awkward (doubly more so once GHC 7.10 implements the AMP), and that it would not be difficult to introduce Applicative by presenting <*> as a generalisation of fmap to multiple arguments, as done by LYAH. However, building clear intuitions about Applicative seems harder than doing the same for Monad (that might be just personal bias though, YMMV!); that being the case, the discussion of applicatives might benefit from the experience gained in dealing extensively with monads. Furthermore, I think it might be desirable not to delay the full discussion of monads too much, given that in one way or another they are there almost from the beginning. In Cartesian terms, I think that when presenting results sometimes it might be a good thing to stick to the order of discovery, rather than following strict geometric order. I am not certain of any of that, though; it will probably be easier to tell once I carry out the rewrite of the Applicative chapter.

Duplode (discuss • contribs) 17:16, 14 May 2014 (UTC)

Good thinking overall. So it sounds like we agree about moving Monoids, and I like your thoughts about how to do it. For the Monoid topics not introduced by the intermediate stage, a mix of "we'll learn more about these items later" and actually have a later "advanced monoids" or "more Monoids" or something seems good.

My view, on Applicative: I totally got the Monad concept without Applicative as an intro. In fact, in many cases, showing more specific first and then broadening to more general is great, and much of the best parts of the book so far are in that order (specific first, general later). Both orders can work, depending on the approach. So, I'm not sure that Applicative should be first!

As is, Monads are explained so much better than Applicative that it appears to me that Monads are pretty easy and Applicative is baffling. I'm sure that's largely because of the difference in the quality of the chapters. So indeed, I agree with you, everything about Applicative depends on what we can achieve in better writing that chapter. Applicative could be used as intro to Monads or it could still come later as it does now. I don't think there's a single right answer. For example, I love how do is introduced early on even though the mathematics of it aren't introduced until Monads.

Whatever we do, I like the step-by-step reasoned examples approach that much of the beginning track has. That is more important than forcing a particular logical ordering in a meta sense. But maybe they can be compatible. Maybe we can both achieve that nice pedagogy and introduce Applicative before Monads. But if not, I definitely think the clear teaching is more important than the conceptual order. So I just think it'll be good to consider these options when rewriting Applicative. Backfromquadrangle (discuss • contribs) 19:01, 14 May 2014 (UTC)

The Duplode for POTUS (sort of) Discussion

I've read at least parts of more than a dozen programming instruction books for Python, C, C++, Ruby, web development, OCaml and Haskell. Duplode's Wikibooks book on Haskell strikes me as 1,000% better than any of them. Duplode always uses examples that relate to existing library functions and therefore avoids the pitfall that every other instructor I"ve seen falls into, of inculcating the habit of writing silly procedural code in both OO and functional languages. Also, it wasn't until I read the introductory material in this book that I became aware of how crucial library knowledge and solid skill in searching for libraries that do what you want to do, really is. Other instructors have unintentionally encouraged me to make a fool of myself by attempting to develop applications long before I knew enough about the language in question. With this book there is opportunity for plenty of practice, but I'll have a much clearer idea of when I'm ready to develop applications that don't cause other programmers to die laughing. So thank you. Miroslav65 (discuss • contribs) 00:34, 13 November 2015 (UTC)

@Miroslav65: I'm glad you are finding the Wikibook useful :) Note that I shouldn't take undue credit − I am just one co-author (among quite a few others) who happens to be an active maintainer right now. There are parts of the book originally written long before I even began to learn Haskell.

The point you make about libraries is indeed very important. Even though this book doesn't have a particularly strong practical bent, we do make an effort to encourage readers to look outwards, towards code and libraries they might find in the wild. Thanks for your feedback, and please keep asking questions and adjusting things as you feel like. In the near future, the first half of the book will be updated in order to complete the transition to 7.10, which should provide a nice opportunity to fix any other remaining rough edges early on.

Cheers, Duplode (discuss • contribs) 04:42, 14 November 2015 (UTC)

Word on the mailing list is that version 8 is in the works, so you'll end up having to update the book all over again. :D. Miroslav65 (discuss • contribs) 05:48, 14 November 2015 (UTC)

@Miroslav65: We're keeping an eye on that, but the changes won't be as drastic. The thing about 7.10 is that it implemented two long-desired proposals (often referred to as AMP and FTP) which affected some really fundamental things that appear everywhere. The changes that will land in 8.0 are much more localised.--Duplode (discuss • contribs) 03:31, 15 November 2015 (UTC)