Dungeons and Dragons

Lets compare D&D classes with popular programming languages.
(#1 most nerdy thread ever)

Fighter - C++
-Very versatile but more complex and not quite as effective in melee as a barbarian.

Barbarian - C
-Very simple, very powerful.

Ranger - Java
-Easy to play, very popular, vast collection of abilities that help solve problems quickly.

Wizard - Lisp/Scheme
-Most powerful caster, highest intelligence.

Sorcerer - Haskell
-Slightly less intelligent than a wizard, but makes up for it in charisma.

Rogue - Scripting Languages
-Executes behind your back.

Cleric - SQL
-Revives players when they crash.
 
Paladin - Python
-Easiest to play, but forces you to play a certain way.

>>40
You mean after Guido replaces all intendation with )))))))))))))))))))))))))))))))))?

>>39
Guido "no tail-call optimization" van Rossum, you mean.

>>40
no. your Lisp fanboyism is what's laughable.

>>43
Leave.

>>44
why should i leave just because i don't like your flavour of the month toy language?
you leave. silly fanboys can't take even an ounce of criticism.
you're just like apple fanatics.

>>45
why should i leave just because i don't like your flavour of the month toy language?
you leave. silly fanboys can't take even an ounce of criticism.
you're just like apple fanatics.

>>46
you are mistaken.
i am not a python programmer, so i couldn't care less what you say about the language.
you lispers on the other hand go apeshit when someone says even the slightest thing bad about lisp. it's very funny to watch.
most of the time i can't tell if you're trolling or just completely insane.

>>45
flavour of the month toy language?
If I may, I'd like to direct you to the vast archive of /prog/ threads on Lisp available from the link "All Threads" beside the Thread list.

"let's just associate our impression of a programming language with descriptions of game characters"

tHEN YOU GOT "C IS SIMPLE, BUT POWERFUL" WHICH IS PLAIN WRONG. bOY I HATE THESE KINDS OF THREADS, IT'S LIKE I'M A HISTORIAN WATCHING PERL HARBOR (TEH MOVIE).

>>47
i am not a python programmer, so i couldn't care less what you say about the language.
oR:
iMPLIES THAT IF YOU PROGRAM IN A LANGUAGE YOU SHOULD CARE FOR THE THINGS OTHER SAY ABOUT IT
tHAT'S MIGHTY SMART OF YOU TIMYM. FUCKOFF!!

>>50
you are mistaken.
i am not a python programmer, so i couldn't care less what you say about the language.
you lispers on the other hand go apeshit when someone says even the slightest thing bad about lisp. it's very funny to watch.
most of the time i can't tell if you're trolling or just completely insane.

>>48
yes.
in all my years on /prog/ i have seen a lot of lisp threads.
however, only recently has the amount of Lisp weenies reached such a huge amount.
until very recently you were also able to act like normal human beings, not shitposters. now, suddenly you're a bunch of bitching little babies who make sure that every thread is filled with "hay, OP. ur langage is shite lolololol XDDDDD LISP IS BETTAR BECUS MACROS N SHIT lolololo LISP IS BETR TAHN EVERETHING"

Lisp is too hard. :(

>>49
OP here. I'm a C/Lisp programmer. C is simple, powerful, and oh wait... IHBT

DANGEROUS EROTIC SHITS

>>52
Sounds like someone is upset they fucked up when they spent 5 years learning useless languages like ENTERPRISE, FIOC, and of course, the worst of them all: ^DEAD _DOG, when they could have learned just ONE language that could have solved anything the previous languages could better, faster, and easier than the aforementioned (not to mention being able to solve problems outside of the previous languages' capabilities).

>>52
wELCOME TO THE /prog/ ENLIGHTMENT ERA. iT'S NOT A LIE - LISP IS BETTER. aLL HAIL LISP! TOADZ

>>54
wHAT DO YOU MEAN WHEN YOU SAY THAT c IS SIMPLE?

>>57
Very low level, close to machine code, not OO.

>>57
i MENA HASKELL

>>58
implying that OO is not simple

LISP

Haskell

I haven't read this thread, but I'm sure it would've contained a shitstorm back when /prog/ was still good.

>>60
OP here again. You try and write an OO compiler that isn't more complicated than a C compiler.

Oh! I see the confusion here.

When I say 'simple' I don't mean simple to code. I mean simple to implement the language itself.

>>62
I guess that makes a little more sense

We should write /prog/&dragons

>>64
Yes YES VERY YES!

>>58
OO is not something you need compiler help to accomplish. Most of C++'s OO support is just syntactic sugar; indeed C++ started out as just a preprocessor to C code. Most well-written C libraries tend to drift towards an OO model anyway, where structs represent object state, and a series of functions taking that struct pointer as the first argument behave as methods. Take a look at any good floss C library like sqlite, zlib, libpng, etc; they are all very object-oriented (some use even more high-level constructs, for instance libpng has C++-style exception handling with longjmp!)

Polymorphism and inheritance are quite easy to accomplish with C code in a variety of ways. Unfortunately they are massively overused which makes C++ seem far more necessary than it actually is.

>>62, 63

This is why people that try to be serious on /prog/ just make themselves out to be such fucking idiots.  Which language is more complicated?  Assembly or C?  Assembly doesn't have a compiler, but C is basically a higher-level (easier) version of Assembly. 

Hell, even most OO languages compile into bytecode, which is much simpler than compiling into Assembly.

IHBT / go2/g/

>>66
Most of C++'s OO support is just syntactic sugar
What OO principles does sepples support? Encapsulation? No. Reflection? No. C++ is less OO than Lua.

>>68
So Smalltalk > Python > JavaScript > Lua > C++ ?

>>69
Smalltalk is less than everything else because it has a stupid name and I've never used it.

And because it's OO.

>>69
Is that really so hard to believe?

>>69
Nice job ordering languages that, for the most part, have different problem domains.  Also, bonus troll points for putting the language designed for teaching rather than being useful on top.

>>68
Um, I agree on reflection, which is what I mean why I say you don't need compiler help for it. That was sort of my point; these people saying OO compilers are more complex than C compilers are crazy, because it's a nonsensical statement to begin with. The most reflection C++ actually supports is dynamic_cast<>, which imho is a bad thing because it poses some fairly serious overhead.

But how can you possibly say OO doesn't support encapsulation? You make variables private, inline accessors/mutators, provide factory classes that return implementations of pure virtual interfaces...

>>69
I didn't imply any heirarchy.

>>73
I assume you meant "[H]ow can you possibly say sepples doesn't support encapsulation?" Well, I suppose in some obscure, sepples-land technical sense, it supports it because it has the private keyword, but heaven forbid you actually change a private variable (or add a virtual function), then it is lolrecompilan. Why? Because C++ isn't OO. If you have to recompile when I change an aspect of my class that you know nothing about, then my private members are suddenly somehow very public.

Lisp

>>74
That has to do with how the compiler organizes the code, and has nothing to do with whether the variables are encapsulated.

>>76
Oh, it is the compiler's fault? I suppose they'll be fixing that any moment now.

>>74
Why do people care so much about recompiling? And what does recompiling have to do with language semantics anyway?

Encapsulating stuff like member variables and the vtable is certainly possible in C++. You just provide a pure virtual interface, and have factory methods that return instances of it. If you want to add virtual methods, just subclass the old interface with a new interface that adds the methods you want. That way old code still works, and new code uses the new interface (and new factory function). This is not just a hack; according to some, this is the proper way to design large, scalable applications.

The reason people don't do it though is because it entails dynamic runtime function calling for everything. All that function call indirection is very costly. This runs directly counter to *speed*, which is one of the main reasons programs are written in C++ at all rather than higher level languages. Design arguments for this paradigm are largely academic and just don't relate to the real world.

If I have to recompile my app to use a newer version of a library where a class's private variables have changed, so be it. I'll gladly trade that for the speed it needs to be fast and responsive to the user.

>>78
Why do people care so much about recompiling?
They don't want to break production code when the semantics haven't changed? extern "C" is how you solve a massive fucking problem with C++ everything is fine ignore the man behind the curtain.

If I have to recompile my app to use a newer version of a library where a class's private variables have changed, so be it.
Thankfully most vendors don't agree with you and provide C interfaces which, unlike sepples, can actually manage to behave in a sane manner.

Thank god for C.