What's wrong with C++?

What's wrong with C++ and where does the name sepples comes from anyway? I mean apart from the sometimes fucked up syntax rules.

Oh, just about everything.

Here's an easy one: write a program that reads a file and creates some objects of types X and Y, then put those objects in the same container. Now iterate over that container the object is of type X call method A, if the object is of type Y call method B. Now pass that container around make copies of it and the like.

Now in a separate file to where you defined X and Y (or a common supercalass) extend them with a method C.

Here's something a bit harder: Read a file with C++ program text into a string. Now compile that string into a function and call it.

Finally write a function that accepts as its argument another, arbitrary, function (which returns a numerical value), and an argument number (assume the argument is numerical), and returns a function which is that functions derivative with respect to the argument number.

where does the name sepplies come from anyway?

Are you serious?

The name sepples comes from the immediate need to seppuku after reaching satori and realizing you had spent time with sepples.

>>2
So your complaint is that C++ is not Lisp? That's a valid complaint, but do you also extend it to C, which is often compared favorably to C++ 'round these parts, or to Java, which is often compared favorably to C++ not 'round these parts?

I have my own complaints about C++, but I would need to compose my thoughts for a good while to say anything more substantial than ``Turing-complete templates, but no proper ABI? shite!''

>>5
Yes I extend my complaint (although not quite your understanding of it, but it is close enough) to C and all ``minimal'' and ``elegant'' languages that mature or branch of into something very ugly (C11, Objective C, C++) when (very intelligent (Stroustrup), but not very wise (Alexandrescu, Stroustrup)) users realize they can't write large systems very well in these ``minimal'' and ``elegant'' languages (some of them, are still in denial, and are thus still ``elegant'' and ``minimal'' e.g. Go)

You mention Lisp. I love Lisp. Pertinently, a great Lisper once wrote:

it is often said that small is beautiful. now, anything can be beautiful when it is small. the ugliest person you can think of was probably a quite pretty baby. it doesn't take much effort to find a beautiful 16-year-old girl, either. in fact, our modern notions of beauty and elegance are _defined_ in terms of size and maturity, so the chance of anything small and immature being beautiful is vastly higher than anything big or mature. Now, despite all the marketing that seems to be aimed at telling me that I should dump a girlfriend when she becomes 25 and get a new 16-year-old (or even younger), I plan to stay with mine partly because of her ability to grow older in a way I like. consequently, I take exceptions to the pedophilic attitudes to beauty and elegance that our societies have adopted over the years. this is why I don't like the "small is beautiful" model of aesthetics. this is why I think that almost anybody could make something small and beautiful, but only a few can create something that grows from small to huge and still remains beautiful.

I do not have much love for Java, but now that I am faced with maybe writing in ENTERPRISE SEPPLES again (after writing a bunch of Smalltalk and Common Lisp), I wish it was Java. Java has a little bit of the essence of Lisp in it (indeed the language specification cites Smalltalk (Lisp's cousin) and CLOS and the Great Quux himself (infamously) wrote ``We were not out to win over the Lisp programmers; we were after the C++ programmers. We managed to drag a lot of them about halfway to Lisp. Aren't you happy?'')

I remember when I first learned programming at university (I elected to take a COMP rather than ISYS unit as part of my degree in economics) and it was Java. I wrote some arcade game clones, a raycaster, all these wonderful things, I had the kind of fun someone new to programming has. Everything was magical and beautiful. Anyway I wrote this texture mapper and I couldn't get real time performance, and being a novice I blamed my tools, specifically Java (I was upset at how many layers there were between me and the framebuffer memory). Then I wanted to get ``closer to the metal'' and all these people on Gamedev.net were using Sepples, and all my favorite programs were written in Sepples, and everyone who hated Sepples seemed to hate it because it was too difficult, but that was no obstacle for me. So I learned Sepples and was proud of it. Moreover, I became a modern Sepples programmer, complete with BOOST WIZARDRY. I got a job and evolved into an ENTERPRISE SEPPLES DEVELOPER.

I kept the job and changed majors, and was introduced to just plain C through classes on networks and operating systems. I loved plain C. I loved it's elegance and simplicity. I loved it so much that I re-wrote part of my project at work in C (which took a month). This experience taught me something; and that was to never attempt something so stupid again. I re-wrote it in Sepples shortly after.

Now my attitude then was to lay landmines for anyone going to use my programs incorrectly. I really liked to model my data and be const correct and statically assert all sorts of everything. I was rigorous. No one would dare use my functions incorrectly. Moreover, I wrote in ``functional style'' (you see I was introduced to Haskell at university, and I loved it very much too) I didn't have classes, I had methodless structs, I had namespaces and functions. I was really into concurrency and GPU stuff too. I taught myself OpenCL, I learned the (then boost) threading library, I understood my compilers memory model. And whenever, I'd see someone bagging Sepples I'd think ``prfft amateurs''.

But then I came across a problem which wasn't so easy to solve. Something not numerical, but symbolic. I solved it using a CAS (I introduced myself to CASes just so love this problem, a love that lasts to this day), and I needed that power at run time. So I looked up symbolic computation and found this book called ``Introduction to symbolic computation'' using Common Lisp which seemd like it would put me on the right track. I read on the net about the Lisps and I thought Common Lisp was the worst of them, CLOS sounded disgusting. I hated the word object, I hated object oriented programming after all I was a modern Sepples programmer with my second tongue being Haskell, everyone knew object oriented programming was some gay thing old people did, and what was cool was being functional. So I stumbled around with Scheme and Clojure which were elegant, minimal and functional and not old and gay like Common Lisp. However, I eventually learned Common Lisp. The rest is, as they say, ``history''.

So what happened to Sepples? Well remember how I learned it cause I wanted to get close to the metal? What a joke. What a lie! I can't mmap video memory any easier in Sepples and C than I could in Java (mainly thanks to the kind of terrible operating systems and computer( system)s which dominate the market today). There's nothing ``low level'' about Sepples. There's machine language, and there's everything else. Sepples falls into the everything else category. It's just shitty everything else. The most you can say is that Sepples (or more appropriately C) has a more natural mapping to a register based Von Neumann machine (pointers, fixed width integers, jumpy control flow) than other languages (so there's less hidden costs) but otherwise it's all the same. Change the ISA to something quite different and there's nothing low level about C anymore.

Moreover, I find it much much easier to write low level programs in Common Lisp than I ever did in C or Sepples ``What I like about Lisp is that you can feel the bits between your toes''.

I never thought I'd be one of those people with an axe to grind against Sepples, my former love, and you know till maybe three weeks ago I didn't. I'd say ``yeah Sepples is no Lisp but we had our fun''. But now, do I really want to be fucking around with Sepples bullshit again? idk. I wish I had 6 years experience in Java instead.

>>6

it doesn't take much effort to find a beautiful 16-year-old girl

This guy does not have standards at all. Also he pulled all of that shit out of his ass.

>>6
Are you talking about this book? https://www.cs.cmu.edu/~dst/LispBook/

>>6
six years of seeples isn't that different from six years of java. You can do things with reflection in java, but few try or even know how. It's good to know that exists, but you could also do it just as well using javashit. So I don't know, take it with a grain of salt. There is something more important than the language of use that is being learned when you are working on something.

>>8
Yes. It doesn't actually teach you about cool symbolic algorithms (with regards to integration, differentiation, simplification, solving). If you want to learn that, read SICP, PAIP, SICM and ``Computer Algebra and Symbolic Computation'' (at first this looks like it just teaches you how to program an existing CAS, but it actually does more than that) both volumes (also read Maxima source).

>>10
nerd

>>6

I didn't have classes, I had methodless structs, I had namespaces and functions.

Did you just say that you used sepples as an extension of C without doing any OOP in it? Also, const correctness isn't everything, lol.

Change the ISA to something quite different and there's nothing low level about C anymore.

Well, on the other hand, that's not a bad perspective... but it assumes that you change it to something very different.

he most you can say is that Sepples (or more appropriately C) has a more natural mapping to a register based Von Neumann machine (pointers, fixed width integers, jumpy control flow) than other languages (so there's less hidden costs) but otherwise it's all the same.

As far as I heard those hidden costs can be quite big in some cases. Also many optimizations which can be done in sepples can't be done in just some random high level language.

>>9
I agree in principle.

>>12

As far as I heard those hidden costs can be quite big in some cases. Also many optimizations which can be done in sepples can't be done in just some random high level language.

Hidden costs Schmidden costs. All you need is lap (or vop or whatever your compiler calls it), time and disassemble.

Your second statement is correct in the real world.

>>12
Actually, your second statement might not be correct.

If you meant that there exists a set of optimizations which can be done using Sepples by the programmer which cannot be done in other languages, well that's not true for a large set of other languages in the real world (any language (implementation) which gives you an escape hatch to machine code means you can make all the same optimizations, and really who is doing the optimization? you're just tricking (instead of asking) the compiler into giving you the machine code you want be restructuring your program, and that's not very clever (if you've already broken that barrier of abstraction, dont be in denial, write that part of your program in the langauge of the machine)).

If you meant there exists a set of optimization which compilers for Sepples can do but compilers for other languages cannot then I know this is empirically correct for x86 and a large set of compilers for other languages.

>>14
You're right. My second statement actually tells exactly how most of the hidden costs can be eliminated in sepples. Lol
However rereading >>6, I think I rather meant something like the difference between the language's abstractions and the actual hardware by "hidden costs". Which are not that hidden by the way.
It was a reply to this

The most you can say is that Sepples (or more appropriately C) has a more natural mapping to a register based Von Neumann machine (pointers, fixed width integers, jumpy control flow) than other languages (so there's less hidden costs) but otherwise it's all the same.

>>15

If you meant there exists a set of optimization which compilers for Sepples can do but compilers for other languages cannot then I know this is empirically correct for x86 and a large set of compilers for other languages.

I meant this.
Btw, I'm op and I think my question just got answered by the rest of your post and the previous discussion. (I have been up for quite some time and I'm tired. Sorry if this response will be a little incomprehensible.)
So the point is that...
1.In sepples I can write code which will depend on the desire to generate good machine code, so my abstractions won't be free from this constraint. Just as you said I could as well use an assembler because basically I'm using sepples as a very high level one.
2.Although I don't have to do this in sepples I can also write "proper high level" code without full of tricks and restructuring, when point 1. isn't important.
But then I could as well use a high level language, which focuses more on abstractions/theoretical programming aspects rather than on what's below and as you say implement the critical parts in either asm/c/sepples. So unless I really need sepples in every part of the program I can exchange it for more high level stuff and be happy. Lol

>>6
Well, I can't fault you for consistency.

Now that I'm back into working with Sepples, it's not as bad as I thought it would be. It's not great, but its not terrible. Very different. I especially enjoy it's largesse and history which has a sober Common Lisp feel to it, which I didn't care about before, but appreciate greatly now. While I was away, most of the boost features I used to rely on made their way into the implementations in a better form than I remember them, and have been seemingly well tested, so that's very, very, very good. Compilers seem to produce much less retarded error messages too. Also at a personal level, now armed with some breadth in other languages, I feel I have better judgement in using C++ features (i.e. I'm not using the Haskell subset of C++ anymore (and surprisingly, I've found my approach similar to Stroustrup's approach as espoused in TC++PL 4th ed)), not to mention a much much deeper understanding of absolutely everything.

Also, it's fun to impress coworkers with template metaprogramming wizardry and word for word recitations of the holy ISO/IEC 14882:2011.

So, even though things are far from ideal, I can still be happy in my work.

C++14 is even more pleasant. More type inferencing all round, lambdas can capture by move, and relaxed restrictions on constexprs. I love metaprogramming. I love it! Clang is excellent and pleasant to work with. Much has improved in Sepples land.

Also good to hear that CERN's influence via their work on Cling has provided the impetus to start a WG on reflection.

C++ is too complex.

>>20
That's what happens when you try and make a (more) useful language out of C.

>>21
C++ is designed for perfection. Where other languages give you a feature, C++ gives you meta-features. Instead of built-in strings and vectors, it gives you templates. Instead of garbage collection, it gives you smart pointers. This way, you can (theoretically) implement your own "perfect" (most efficient and generic) strings. In practice, this turns into a nightmare since many different kinds of strings, smart pointers, etc., each perfect in its own way, will not work with each other. C++ sacrifices usability for perfection.

This leads to C++ being outstandingly complex because it deals with a lot in order to give programmers this level of perfection.

>>22
You can do static metaprogramming in Common Lisp without all the retardedness.

>>22
meta programming in C++ is hopelessly primitive. Once you experience real meta programming, the ability to use an actual programming language to generate code that is then compiled, you'll feel constantly restricted without it. Currently you sound like a cave man voicing the prowess of rubbing sticks together to generate fire. I have this thing in my pocket called a butane lighter that just might blow your mind. It is simple, cheap, and nothing to it, but it is more effective than anything you've yet experienced. Just be careful to not blow yourself up.

This is probably a retarded question, but what exactly is the point of having namespaces in C++? Since the language allows nested classes and structs, why can't you just use classes/structs with static member functions, or unique global objects, to organize functions and control name visibility? That's how all the other OOP languages handle it. And especially considering that classes also function as namespaces, but the reverse isn't true.

Really the only advantage namespacees have right now is the using statement, but the language could easily be designed to have that apply to classes instead. So instead of saying using namespace std; or std::cout, you'd say something like import std; or std.cout. It seems it would clean up the syntax quite a bit. If there's some optimization-related reason that namespaces are more efficient since the compiler knows they can't be instantiated as an object, couldn't the same be achieved by declaring a class as static class std {};? That would tell the compiler that the class contains only static members and will never be instantiated (and will result in a compile-time error if we violate that constraint). It just seems to me that namespaces just end up complicating the syntax when another already-existent language feature could do the same thing just as well.

>>25

clean up the syntax

it's sepples we're talking about, what do you think will happen instead