Return Styles: Pseud0ch, Terminal, Valhalla, NES, Geocities, Blue Moon.

Pages: 1-4041-

F#

Name: Anonymous 2008-04-21 21:11

So anyway I have begun my foray into F#.  Because I plan to use .net in my next project I think it will be fun to learn F# in addition to C# and use both languges in the project.  To this end I just ordered Expert F#.  Knowing /prog/ is infinitely more expert then me: 

what does /prog/ think about .net?
what does /prog/ think about F# (ocaml)?
What type of tasks are better to be performed in F# vs C# (Math type tasks heavy)?

Name: Anonymous 2008-04-21 21:12

>>1
You best be trollin' nigga.

Name: Anonymous 2008-04-21 21:14

>>2
Why the fuck would I troll this?

I want honest oppinions on F#, .net, and what type of things you would do in F# vs C#.

Name: Anonymous 2008-04-21 21:16

>>3
Shut up troll.
We don't take kindly to your types round these parts.

Name: Anonymous 2008-04-21 21:17

C#3/Linq has added functional parts, although probably nothing like what F# has to offer.

Name: Anonymous 2008-04-21 21:17

5GET

EVERY THREAD WILL BE RESPONDED TO

NO EXCEPTIONS

Name: Anonymous 2008-04-21 21:19

>>6
failGET is fail

Name: Anonymous 2008-04-22 0:05

>>2>>4
No, actually, that's a good thread.

I don't have an opinion on .net, because I avoid it like a fire. Ah, where is my parrot..?

Name: Anonymous 2008-04-22 0:47

Too many trolls in my/prog/

Name: Anonymous 2008-04-22 1:14

>>8
>>2,4
Fixed. Please submit your posts with at least -O1 next time.

Name: Anonymous 2008-04-22 1:17

>>10
Better to just set your BBFLAGS and forget about it.

Name: Anonymous 2008-04-22 3:44

Knowing /prog/ is infinitely more expert then me
I don't think you know /prog/, enjoy your illiteracy.

Name: Anonymous 2008-04-22 3:47

>>12
He did not say he knows /prog/, enjoy your inability to comprehend.

Name: Anonymous 2008-04-22 3:51

>>13
enjoy your inability to comprehend

Name: Anonymous 2008-04-22 3:55

>>13
I don't think you know [anything about] /prog/, enjoy your illiteracy.
What else could it mean? That he doesn't know /prog/ personally? Enjoy you're inability to comprehend.

Name: Anonymous 2008-04-22 3:56

And so the conversation turned... until the sun went down.

Name: Anonymous 2008-04-22 4:03

>>15
Knowing /prog/ is infinitely more expert then me
He aknowledges /prog/s superiority. It does not mean he knows /prog/.

Name: Anonymous 2008-04-22 4:27

>>15
Enjoy you're inability to comprehend.
Enjoy you're inability to
you're inability
you're
you're

Name: Anonymous 2008-04-22 5:02

>>18
Ah yeah, your're.

Name: Anonymous 2008-04-22 5:28

>>17
He knows a fact about /prog/, that it is superior. Are you stupid?

Name: Anonymous 2008-04-22 5:30

>>18
YHBT

Name: Anonymous 2008-04-22 5:34

>>20
By your logic, >>12 is ultimately incorrect, since it's impossible NOT to know anything about something; Because you will know that you don't know anything about it.
That logic doesn't work, and you're wrong. So is >>12 for different reasons.

Name: Anonymous 2008-04-22 5:36

>>22
>>12 is ultimately incorrect
That's why it's called irony, you idiot. I am facepalming so hard right now.

Name: Anonymous 2008-04-22 5:42

>>23
So you proved I am right and that both >>12 and you are wrong in an ironical way?
Yeah, after that if I were you I'd facepalm too.

Name: Anonymous 2008-04-22 5:51

>>24
IHBT

Name: Anonymous 2008-04-22 7:44

>>1
How would you compare F# to, say, haskell? I don't care about C#.

Name: Anonymous 2008-04-22 8:16

F# is basically Ocaml with .NET libraries. I suppose you could say, now you have two probloms

Name: Anonymous 2008-04-22 11:11

>>12-25
Stop trolling me before I rage.

Name: Anonymous 2008-04-22 14:00

Wow interesting discussion of .net/F#

I definitely love /prog/

Name: Anonymous 2008-04-22 15:39

>>29
I definitely love /prog/
posts like >>29 and >>30 are just fagging it up.

Name: Anonymous 2008-04-22 16:56

The faggots on /prog/ don't know enough to make informed decisions. They love old out-dated shit like C and C++. Yet they fail to realize C++'s default of passing objects by value is:
A. Fucking retarded
B. Not very object oriented
Passing object by reference is the rule, not the exception. But C++ fails to recognize that because its old and was designed to solve problems from decades ago.

/prog/ hates .Net solely because its Microsoft with no actual and factual complaints. Trust me, I have asked and not one /prog/ nigger can give significant cause to say .Net sucks.

.Net is actually one of the best and most complete development frameworks to come around in a long time. /prog/ is too busy reinventing the wheel with each app to appreciate something like a world class garbage collector, complete libraries, complete documentation and support from knowledgeable programmers.

As far as F#, it depends on what problems you think it will solve. What are you looking to get out of it that you can't get in C#?

Name: Anonymous 2008-04-22 16:59

INSTRUCTION SETS INSTRUCTION SETS INSTRUCTION SETS INSTRUCTION SETS INSTRUCTION SETS INSTRUCTION SETS INSTRUCTION SETS INSTRUCTION SETS INSTRUCTION SETS INSTRUCTION SETS INSTRUCTION SETS INSTRUCTION SETS INSTRUCTION SETS INSTRUCTION SETS INSTRUCTION SETS INSTRUCTION SETS INSTRUCTION SETS INSTRUCTION SETS INSTRUCTION SETS INSTRUCTION SETS INSTRUCTION SETS INSTRUCTION SETS INSTRUCTION SETS INSTRUCTION SETS INSTRUCTION SETS INSTRUCTION SETS INSTRUCTION SETS INSTRUCTION SETS INSTRUCTION SETS INSTRUCTION SETS INSTRUCTION SETS INSTRUCTION SETS INSTRUCTION SETS INSTRUCTION SETS INSTRUCTION SETS INSTRUCTION SETS INSTRUCTION SETS INSTRUCTION SETS INSTRUCTION SETS INSTRUCTION SETS INSTRUCTION SETS INSTRUCTION SETS INSTRUCTION SETS INSTRUCTION SETS INSTRUCTION SETS INSTRUCTION SETS INSTRUCTION SETS INSTRUCTION SETS INSTRUCTION SETS INSTRUCTION SETS INSTRUCTION SETS INSTRUCTION SETS INSTRUCTION SETS INSTRUCTION SETS INSTRUCTION SETS INSTRUCTION SETS INSTRUCTION SETS INSTRUCTION SETS INSTRUCTION SETS INSTRUCTION SETS INSTRUCTION SETS INSTRUCTION SETS INSTRUCTION SETS INSTRUCTION SETS INSTRUCTION SETS INSTRUCTION SETS INSTRUCTION SETS INSTRUCTION SETS INSTRUCTION SETS INSTRUCTION SETS INSTRUCTION SETS INSTRUCTION SETS INSTRUCTION SETS INSTRUCTION SETS INSTRUCTION SETS INSTRUCTION SETS INSTRUCTION SETS INSTRUCTION SETS INSTRUCTION SETS INSTRUCTION SETS INSTRUCTION SETS INSTRUCTION SETS INSTRUCTION SETS INSTRUCTION SETS INSTRUCTION SETS INSTRUCTION SETS INSTRUCTION SETS INSTRUCTION SETS INSTRUCTION SETS INSTRUCTION SETS INSTRUCTION SETS INSTRUCTION SETS INSTRUCTION SETS INSTRUCTION SETS INSTRUCTION SETS INSTRUCTION SETS INSTRUCTION SETS INSTRUCTION SETS INSTRUCTION SETS INSTRUCTION SETS INSTRUCTION SETS INSTRUCTION SETS INSTRUCTION SETS INSTRUCTION SETS INSTRUCTION SETS INSTRUCTION SETS INSTRUCTION SETS INSTRUCTION SETS INSTRUCTION SETS INSTRUCTION SETS INSTRUCTION SETS INSTRUCTION SETS INSTRUCTION SETS INSTRUCTION SETS INSTRUCTION SETS INSTRUCTION SETS INSTRUCTION SETS INSTRUCTION SETS INSTRUCTION SETS INSTRUCTION SETS INSTRUCTION SETS INSTRUCTION SETS INSTRUCTION SETS INSTRUCTION SETS INSTRUCTION SETS INSTRUCTION SETS INSTRUCTION SETS INSTRUCTION SETS INSTRUCTION SETS INSTRUCTION SETS INSTRUCTION SETS INSTRUCTION SETS INSTRUCTION SETS INSTRUCTION SETS INSTRUCTION SETS INSTRUCTION SETS INSTRUCTION SETS INSTRUCTION SETS INSTRUCTION SETS INSTRUCTION SETS INSTRUCTION SETS INSTRUCTION SETS INSTRUCTION SETS INSTRUCTION SETS INSTRUCTION SETS INSTRUCTION SETS INSTRUCTION SETS INSTRUCTION SETS INSTRUCTION SETS INSTRUCTION SETS INSTRUCTION SETS INSTRUCTION SETS INSTRUCTION SETS INSTRUCTION SETS INSTRUCTION SETS INSTRUCTION SETS INSTRUCTION SETS INSTRUCTION SETS INSTRUCTION SETS INSTRUCTION SETS INSTRUCTION SETS INSTRUCTION SETS INSTRUCTION SETS INSTRUCTION SETS INSTRUCTION SETS INSTRUCTION SETS INSTRUCTION SETS INSTRUCTION SETS INSTRUCTION SETS INSTRUCTION SETS INSTRUCTION SETS INSTRUCTION SETS INSTRUCTION SETS INSTRUCTION SETS INSTRUCTION SETS INSTRUCTION SETS INSTRUCTION SETS INSTRUCTION SETS INSTRUCTION SETS INSTRUCTION SETS INSTRUCTION SETS INSTRUCTION SETS INSTRUCTION SETS INSTRUCTION SETS INSTRUCTION SETS INSTRUCTION SETS INSTRUCTION SETS INSTRUCTION SETS INSTRUCTION SETS INSTRUCTION SETS INSTRUCTION SETS INSTRUCTION SETS

Name: Anonymous 2008-04-22 17:00

MAYBE IF I KEEP SAYING IT IT'D BORE INTO YOUR THICK HEADED BRAINS

Name: Anonymous 2008-04-22 17:00

>>31
.NET sucks because it is not really portable. Mono works, but not as well as Java. That said, the .NET library is clearly superior to the Java library. For one thing, it's not self-obsessed (i.e. no "MSButton"s in .NET, unlike Java/Swing/whatever's "JButton"s).

However, if you're just doing Windows programming, then .NET is the clear way to go, unless you NEED the program to run on a vanilla Windows XP install with no internet connection.

Name: Anonymous 2008-04-22 17:10

>>34

You are only half way there. Since C# and the CLR are published standards they can be ported to any platform. The only real problem is that they are not yet ported to many pltforms, not that it can't and never will be.

There are .Net implementations from MS on:
Windows
OSX (not Mono)
Moible Devices

And the only non-MS one is:
Linux

The mono guys seem to have their priorities wrong. Instead of implementing the newest version of the core framework, they are implementing things like Silverlight and DLR.

Name: Anonymous 2008-04-22 17:22

>>35
Oh, yes, the Mac OS X support is just so great.

[quote]
The current version of SSCLI is 2.0, which contains most of the classes and features of version 2.0 of the .NET Framework. Unlike the previous version however, it is only supported on Windows XP SP2.
[/quote]

Microsoft is not committed to portability in the same way Sun is. If Microsoft had really cared to fully port .NET to OS X and/or Linux, then it may have had a really good chance of displacing Java.

Name: Anonymous 2008-04-22 17:35

Basically, if you're writing an application for mass market appeal, you want to target Windows 2000 and higher. Maybe Mac OSX too. But certainly not Linux or any of the BSDs or anything else similarly esoteric.

Name: Anonymous 2008-04-22 17:41

>>36

The SSCLI isn't meant to be a consumer technology. Its a learning tool. A tool developers are supposed to use to implement versions of .Net on other platforms.

Name: Anonymous 2008-04-22 17:45

>>35
It's not portable. Period. The reason comes back to the whole Microsoft thing, but not in the way that you might so casually brush off as Microsoft-hatred. It's because they control the specifications and write them with their own interests in mind -- regardless of how well-designed the .Net platform is, it's still written by one single proprietor targeting one OS family (Windows), and many of the design decisions they made reflect this. Even if a third party creates a .Net implementation for some other OS, it's not going to get first-party support and won't affect the decisions MS makes in the future.

It's a good platform but fundamentally unsustainable for cross-platform development. This is why people make independent design groups for these things -- to keep any one vendor's interests from clouding the overall design with decisions specific to their own implementation.

Name: Anonymous 2008-04-22 17:47

>>39
A bit like OOXML, etc.

Name: Anonymous 2008-04-22 18:43

>>39

>targeting one OS family (Windows), and many of the design decisions they made reflect this

The strange thing is that MS admits the Windows API is way too convoluted. Their design descion was to abstract the Windows API to something more manageable.

So its hard to argue that MS is polluting the .Net framework with Windows specific implementations to make it unuseable on other platforms.

But you are contratdicting yourself:
>Even if a third party creates a .Net implementation for some other OS, it's not going to get first-party support and won't affect the decisions MS makes in the future.
Contradicts:
>This is why people make independent design groups for these things -- to keep any one vendor's interests from clouding the overall design with decisions specific to their own implementation.

Either MS makes it avaible on other platforms, or removes itself and gives you the resources to do it yourself for a platform. It makes no sense to do both. You seem to not agree with the former as being a good path, and apprently so does MS because they went with the latter.

Name: Anonymous 2008-04-22 19:02

>>31
I don't know exactly.  I want to get into fractals and procedurally generated content so I'm guessing a functional language will help a lot with the structure of such a thing.  I expect to use C#/F# together and just pick and choose based on what algorithm I am making.  Just another tool to pick from :/  Since .net seems to offer easy interoperability it seems to me that having access to F# for certain implementations should help.  A lot of the stuff would not be runtime that I would want to implement in F# so I don't think speed will be huge factor.  TBH though I'm just beginning to dive into this new project.

Name: Anonymous 2008-04-22 19:11

>>42

You should be aware that a given .Net assembly needs to be entireley in the same language. It won't create 1 assembly from multiple languages.

Don't confuse that with the fact that .Net doesn't care what language an assembly is written in.

Creating a class in F# and another class in C# and trying to put them in the same assembly (dll) won't work.

Creating a class in F#, compiling it to an assembly and then referencing and calling that class from a C# assembly will be 100% fine.

If you are creating a library of algorithms, it would be strange to have 2 assemblies for a common library. So the best approach would be to implement each unit of functionality in the same language, but your entire app can be written in many.

Name: Anonymous 2008-04-22 19:19

>>43
Couldn't you use ILMerge to merge two separate assemblies?

Name: Anonymous 2008-04-22 19:26

>>44

Holy shit, that's fucking brilliant! I just got leanrt. I was unaware such a utility existed.

It makes sense since no matter what the language, an assembly is compiled to the same IL language.

Name: Anonymous 2008-04-22 21:34

.NET makes it easier to generate bytecode from custom languages, which is nice. And it has a halfway decent library.
But the CLR is slower than the JVM. And the Mono project is veering left and right to implement shit like Silverlight. They're just too busy kissing MS's butt, and MS is waggling it to keep them off-balance.
All in all I really can't recommend the .NET platform, on the basis that using punctuation in a proper noun is very poor form, and that PascalCase is almost as ugly as javaCase is.

Name: Anonymous 2008-04-23 0:16

>>41
But you are contratdicting yourself:
>Even if a third party creates a .Net implementation for some other OS, it's not going to get first-party support and won't affect the decisions MS makes in the future.
Contradicts:
>This is why people make independent design groups for these things -- to keep any one vendor's interests from clouding the overall design with decisions specific to their own implementation.

Negative.
I am claiming that the implementation should be created by a non-partisan group comprised of several different entities, which may have conflicting views. .Net has been created by a single entity and a third party implementation is unlikely to change Microsoft's decision-making.

Name: Anonymous 2008-04-23 2:31

>>46

The CLR is certainly not slower than JVM. The way Sun lazily implements shit on JVM will always keep it slow.

Did you generics in Java are just a boxing to and from Object macro. That is some insanely lazy incredibly non-per formant shit. With Sun being that fucking lazy it is actually a benefit to everyone if they hadn't implemented generics in Java.

At least .Net creates the code as a static class and then keeps variable tables for each instance. Probably the best implementation. (And no, while C++ template macros are better than Javas generic macros, it still lacks competent compiler checking).

>>47

While that would probably be ideal, in the real world we most likley will never see anything like that. Left to their own devices, people would rather just fragment the shit out of everything: see Linux.

Name: Anonymous 2008-04-23 4:50

>>46
>But the CLR is slower than the JVM
[citation needed]

Name: Anonymous 2008-04-23 5:38

megapigs

Name: Anonymous 2008-04-23 10:50

>>48
we most likley will never see anything like that.

Nonsense. How about JPEG, MPEG, WHAT-WG, WebDAV, RSS, Ethernet... There's six examples of standards formed by independent groups. There are many more.

Name: Anonymous 2008-04-23 18:18

>>49
I don't know why'd you find it hard to believe that the JVM, being a very mature product, have implemented more optimizations and been tweaked more extensively than the CLR, but you can benchmark it for yourself and see. You won't find any published results though. MS probably have one of their retarded "you can't benchmark this" clauses in their EULA, like they do on their database.
Why the hell anybody would use anything released by anybody who so blatantly refuse honest comparison to competitors by a third party is beyond me. It's like an admission of vast inferiority.

Name: Anonymous 2008-04-23 18:39

How about hax, my, anus... There's 3 examples of standards formed by independent groups. There are many more.

Name: Anonymous 2008-04-23 19:47

>>51

You got anything better than some file formats? And example of what you are trying to say is that since lugnuts are the same size, all cars should be made according to the same standard.

>>52

You obviously missed my real world example of ho un-optopmized the JVM really is. Generics in Java are a fucking joke.

Only a really stupid nigger would trust striaght benchmark numbers. Benchmarks are hardly ever honest.

But don't take my word for it:
http://portal.acm.org/citation.cfm?id=957341

An independent group of real computer scientists did the study. The study concludes that both the CLR and JVM can create and run Object Oriented programs. But the CRL is superior (and not just to JVM).

Name: Anonymous 2008-04-23 20:28

>>54
You should feel dirty for using a car analogy.

How about Parrot? It's not solid or widely accepted yet, but it's still closer to what I'm referring to. However what you're asking for an example of doesn't necessarily exist -- or if it does, it's simply not coming to my mind at the moment,. In fact I believe one of the problems with the selections of VMs is that the most common ones are only most common because they've been developed by a corporation with large financial backing, not because they're actually any good. It's kind of sad, really. The ABSTRACT BULLSHITE research projects that people draft up for grad school etc., if supplanted with equivalent funds and man-hours dumped into producing crap like the JVM and CRL, would have so much potential for being tons better.

Er... I'm rambling pointlessly but feel like clicking reply anyway, so I'll sage.

Name: Anonymous 2008-04-23 20:38

>>54
You briefly mentioned how generics in Java works, which I knew, but failed to give any examples of why it mattered much performance-wise. I'd pay more attention to things like function call overhead.

Benchmarks are pretty much the only thing we have to guide us in performance questions. It's hard to do right, and you can skew the results pretty easily. Still, reviewing enough benchmark tests from differently associated third-parties would give a better basis than doing the tests myself and risking screwing up, and is certainly more reliable than just reading blurbs from the company webpages and going by gut feeling.

As for the study... Maybe I'll skim it later, but really, look at the language used...
a case study that proves the superiority of the Common Language Runtime as a target for imperative programming language compilers
The author list does not really indicate a group either, though it's reassuring to hear you call him a real computer scientist, as opposed to all the fake ones.
No huge surprise that
Citation Count: 0

Name: Anonymous 2008-04-23 20:48

>>56
I see your point, but - assuming that it was a normal sized bucket, and it was indeed full to the brim with cocks, I imagine that if one was forced to submerge one's face into said bucket, choking and gagging would be very likely to occur.

Name: Anonymous 2008-04-23 21:08

>>56

Assuming you understand generics...

In Java, a generic just takes the object in and boxes it to the type object. When you then reference the object in the generic, it then unboxes it from object to the type you expect.

Lets imagine you are using a generic class as a collection, a very popular and useful thing to do. As you populate the collection you incur those extra instructions boxing to object. Now if I iterate over the collection, I incur the unboxing instructions for each object.

Lets say I need to populate a collection with 100 items.
Then iterate over that collection and change the value of each item.
Then later persist the collection to a database or some other medium.

I have just incurred 300 sets of boxing and unboxing instructions for a very simple task.

This is odd because generics are normally implemented to avoid this sort of thing.

C++ and .Net don't do this. The value of each item always remains as the type you specified in your type parameter.

As for the ACM, I mean real as in they do not serve the interest of any group such as Sun or MS. It's as good as your gonna get for peer reviewed studies in computer science.

Name: Anonymous 2008-04-23 21:59

>>58

You are obviously responding to a moron Java user.  If he doesn't even understand something a novice programmer should know like boxing/unboxing performance hits than it is obviously a waste of time to reason with him.

Name: Anonymous 2008-04-24 5:35

>>58
Yes, but the JVM usually highly optimizes box and unboxing in such cases so it is not a performance hit.

Name: Anonymous 2008-04-24 10:53

>>58

Assuming you understand generics...

In C, a generic just takes the object in and casts it to type void*. When you then reference the object in the generic, it returns the void* which you must then up-cast to the appropriate type.

Lets imagine you are using a I honestly don't know what the fuck you're talking about in this sentence, a very popular and useful thing to do. As you populate the collection you incur those extra instructions casting each pointer. Typically this compiles to a cost of an immediate add for each cast. Now if I iterate over the collection, I make the callee upcast from the raw void*.

Lets say I need to populate a collection with 9001 items. Because my language isn't some niggertits thing and can actually handle the production-sized load which my cock regularly delivers.
Then iterate over that collection and change the value of each item.
Then later persist (or should I say ``serialize'') the collection to a database or some other medium like XML stored as a blob in a database because that's enterprise and cool.

I have just incurred over 9001 casts
Unknown to javac
Nor known to gdb
Have withstood pain to create optimized generic containers.
Yet, -O3 is still considered harmful.
So as I type, "UNLIMITED GENERIC WORKS"
You're all faggots.

Name: Anonymous 2008-04-24 11:50

>>58
Ah, primitives. Yeah, boxing sucks. If you want performance for the things you described in Java, you use an array unless you need a more advanced collection.
In your specific example it sounds more likely that the items in the list would be objects, in which case .NET generics will use code sharing too.

Name: Anonymous 2008-04-24 12:20

A REAL programming conversation on MY /prog/?

It's more likely than you think.


This is great, guys.
I'd join the discussion, but I there's not much I can contribute that hasn't already been said.

Continue.

Name: Anonymous 2008-04-24 12:46

>>62
Yeah because an example of changing the values of objects in a collection is usually done on objects not specified types.  So lets add five to all those vectors, strings, and ints. 

Name: Anonymous 2008-04-24 13:33

>>64
Objects of a specific type, of course, but as opposed to pass-by-value primitives like ints, whom you would seldom lug around in a collection, run a transform on and then store in a database.

Name: Anonymous 2008-04-24 15:19

OK, I am an idiot. Java generics apparently don't support primitive types. You have to explicitly box/unbox your primitives to use them in a generic.

Thats incredibly gay.

Java implements generics using some gay technique called type erasure. The type is checked at compile time, but completely removed at run time and replaced with object. It then inserts casts to and from object and the expected type at runtime.

At no point on some generic piece of code in Java can you actually get what type you are actually using. If you try, the compiler will bitch. If you use reflection it will tell you its just object.

So if you want a bunch of unnecessary casts all over your code, or boxing primitives to get them in a generic function then go ahead and loves Java's implementation. Then kill yourself.

At least .Net allows value types and is implemented in such a way that it improves performance.

Name: Anonymous 2009-03-06 13:40


Boxing in such cases so it is   in C Nowadays.

Name: Anonymous 2011-02-03 7:55

Name: Sgt.Kabukiman 2012-05-22 23:14

All work and no play makes Jack a dull boy
 All work and no play makes Jack a dull boy
 All work and no play makes Jack a dull boy
 All work and no play makes Jack a dull boy
 All work and no play makes Jack a dull boy
 All work and no play makes Jack a dull boy
 All work and no play makes Jack a dull boy
 All work and no play makes Jack a dull boy
 All work and no play makes Jack a dull boy
All work and no play makes Jack a dull boy
 All work and no play makes Jack a dull boy
 All work and no play makes Jack a dull boy
 All work and no play makes Jack a dull boy
 All work and no play makes Jack a dull boy
 All work and no play makes Jack a dull boy
 All work and no play makes Jack a dull boy
 All work and no play makes Jack a dull boy
 All work and no play makes Jack a dull boy

Don't change these.
Name: Email:
Entire Thread Thread List