Why is C++...

...so bad? Why does it have such a bad reputation?

I'm an experienced C++ programmer and, while the language has warts, I can't understand the reason for the enormous amount of criticism against the language.

I'd like to hear the honest opinions of /prog/rammers in this regard.

C++ isn't as minimalistic, uniform and elegant as Lisp.

>>1
Why is C++ so bad? Why does it have such a bad reputation?
You are asking wrong questions. The second one is better, but still not quite there.

The correct question is, "Why does C++ have such a bad reputation in /prog/ and /r/programming?" Asking the right question is half the right answer, isn't it?

>>3

I appreciate your remark, but I suppose that the intent of the thread is still clear.

The most vexing parse?

Seriously, C++ has a weird design. No matter how good you code, it will always seems broken.

>>5

Why does it have a weird design? I would suggest that most problems in this regard, which are applied exclusively to C++, are problems in the OO-paradigm itself.

>>2
TOO BAD LISP IS SLOW AS BALLS

It's badly designed.

See also http://yosefk.com/c++fqa/

just look at "the c programming language" book and "the c++ programming language" book. one is rather concise, the other goes on and on forever with millions of keywords, rules and exceptions to rules that you will never fully understand. it's madness.

>>8
I know this site. I've read it a number of times in its entirety. I agree with roughly half of the criticism Yossi proposes. He exaggerates the matter.

>>9
I agree with the fact that C++ is well complicated in comparison with C (and most other languages). But I don't think this is specially bad, nor exclusive to C++: many languages have a lot of complex concepts which aren't always easy to grasp, nor easy to express. In my opinion, C++ was intended to hoard a lot of different techniques and "programming paradigms" (I hate that expression). This will naturally yield a gigantic language, both in syntax and in concepts.

<3 C++ - it's relatively easy to get, and you get used to the quirks after years and years of programming

>>9
the other goes on and on forever with millions of keywords, rules and exceptions to rules that you will never fully understand. it's madness.
Not me, you!
WOW SON, U BUTT ANGREY
gb2 pussybaby land where u git own3d by dick
"omg im so dumb i cant understand c++" -You
SUMBUDY IS ANALLY ANGUISHED

^ lol

C++ is better than all the GC languages combined. Sometimes it's even better than C.

GC is shit.

>>14
allocation is expensive
memleaks are shit

>>10
``Programming languages should be designed not by piling feature on top of feature, but by removing the weaknesses and restrictions that make additional features appear necessary.''
- Wizard

>>15

Memleaks are shit

Maybe you should clean them up then, yes? Like so:
delete MyShittyPointer;

“If you think it's simple, then you have misunderstood the problem.” -- Bjarne Stroustrup when designing C++

>>6
I don't think so. Exceptions, (lack of) runtime type system, superb chain of template headers, duplicated template instantiations in object files, (possibly infinite) obscure rules for implicit casts, lack of a better preprocessor, awful parseable grammar... I mean, just try to debug some template errors and you've got work for a week.

I'll never learn C++ entirely, and don't care!

“I have always wished for my computer to be as easy to use as my telephone; my wish has come true because I can no longer figure out how to use my telephone.” -- Bjarne Stroustrup

C++ is constipated shit.

>>15
How about allocating most of your shit from the stack, ``faggot" ??

>>17
What can I do if myShittyPointer are deep inside the library I'm going to use? Rewrite everything from scratch?

>>20
''IHBT''!

>>20
Implying that shared data must be global static variables.

>>18
Despite the problems regarding exception specifications, unexpected() and such, exceptions in C++ are rather ok in my opinion. I have never had problems with them, and I think they're particularly well design for their purpose. The feasibility of exception handling, on the other hand, is another matter, and is not restricted to C++ in any way.

About the type system, C++ offers typeid and dynamic_cast when it is necessary, but I agree the language should offer some means of providing some reflection, even compile-time reflection would be very useful (that is, automatically create code from the structure of a known class). The header chains and preprocessor issues are really the compilation bottleneck in any C++ program, and it is derived from C; however, this problem is greatly alleviated by precompiled headers (which, I agree, are a terrible solution for the problem, but they work nonetheless).

Duplicated template instantiations are not much of a problem in modern compilers with template repository control. And I sincerely don't see much obscurity in the implicit type conversion rules -- there are a few cases, and one quickly grasps them once he becomes familiar with the language.

The major problem with C++, in my opinion, is the toolchain. Many problems you've cited would be much better handled if the compiler did it's job a little better, specially when issuing error messages to the user. The fact that C++ inherits many things from C serves it for good and for bad: the limitations of the C toolchain (over which most C++ compilers are written) cannot cope with the complexity of C++, but I disagree that a language should be written towards compatibility with the toolchain. Compilers could produce a lot of information besides mere object files which would help them to locate symbols, handle template instantiations and much more.

>>24
Language should offer uniform syntax, and the only way it can do so is by being Lisp. Else language is a crap.

>>25
Uniform syntax is unreadable shit. Fuck off and die.

>>26
No.

>>25
i can do this with C Macros

>>25
Why? Sounds just like hivemind mentality.

>>28
No.

>>29
No.

>>27,30
Go back to whatever lithp shithole you came from, and take your shitty unreadable cdr-ridden language with you.

>>31
No.

>>32
You're shit.

>>33
No.

>>34
Fuck off and die already.

>>34
plz go away `fgt'

>>35>>36
No.

>>33,35,36
Why?

>>25-38

same poster

>>16

Profound-sounding statement meaning almost nothing in practice.

>>40
Its also what appears at the very beginning of the introduction (page 2) of R⁵RS. But you knew that, and you read your SICP too, right?

>>40

simplicity, clarity of form, absence of clutter.

it is a design principle seen over and over again in industrial product design, modern architecture, etc

>>41

Epigraphs appear in many places, sometimes to help further legitimize an idea. This doesn't readily imbue them with any practical sense at all.

>>43
When your favorite language's full specification, formal syntax and denotational semantics, and documentation of basic libraries fit together in 50 pages we can talk.（　≖‿≖）

>>9

madness?

Madness!

THIS IS SEEPLES!

>>24
The major problem with C++, in my opinion, is the toolchain. Many problems you've cited would be much better handled if the compiler did it's job a little better, specially when issuing error messages to the user.
Anyone who says this instantly reveals how little they understand about why C++ is shit.

erik naggum says it best.

http://www.xach.com/naggum/articles/3103356827666810@naggum.no.html

every C++ programmer I know (including myself, for a few years) turns into a insecure, paranoid, dishonest, closed-minded jerk.

>>46

It's really difficult for a C++ compiler to issue good error and warning messages to the user because the C++ grammar is so freken weird.

I just realized that you aren't allowed to define types when declaring a return type in C++, but you can do it in C. The following is valid C:


struct {
  int w;
}* f() {
  return 0;
}

>>49
Only because ancient C standards assumed that int was the default return value, and could be omitted. This behaviour is highly deprecated nowadays and should never be used (try -Wall).

>>50

Nah, what's going on in that code there, is, a function f is being defined. f takes no arguments, and f returns a pointer to a struct that contains a single int member called w. So if f returned a valid pointer, you could do:


f()->w = 5;
printf("%d\n", f()->w);

But the structure that f returns a pointer to has no name.

>>24
It's like you said, C++ inherited many things from C, but simplicity. If you look at C, it's pretty minimalist and straightforward. That's why there's new languages aiming to be a C++-- (Java, D), and many programmers (and code) restricted to simpler subsets of the C++ language. A good toolchain really can help, but is it really necessary?
Look at the facts, C++ is old, overcomplicated and ugly. There's so much better languages out there that C++ nowadays is just an alternative to C when coding low-level, performance sensitive or time critical functions.

C++11 fixed some quirks and added some interesting stuff, but C++ needs a lot more to become a lovely language.

>>40
“Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away.” -- Antoine de Saint-Exupery

It was nice to know picolisp.com
specially http://software-lab.de/radical.pdf

C++ is a minimalist tight language that's completely sane and logical. It was made by a god. I am the ordained shit poster of the east.

>>54
tight
boner

>>55
you get excited way too easily. you need some discipline :3

>>56
:3
boner

>>57
boner
boner

dickanii

>>44
Good. Thus we might exclude every modern programming language, including C, Java and almost every scripting language out there.

How old are you, by the way?

>>47
I've read it elsewhere, and commented on it. I'll not repeat the entire argument, but just restate that this guy must be living on a reality bubble. He abuses terminological ignorance ("epistemological process"), unwarranted personal judgements and assertions ("C++ is a language strongly optimized for liars and people who go by guesswork and ignorance"), and even poetic verbosity ("C++ has taken premature optimization to the level of divine edict"), instead of trying to analytically pose arguments in his favor.

In other words, his text has a particular effect on people which are already influenced and particularly biased to accept that sort of criticism -- that's exactly the goal of his text. It is not to help forming an opinion, but rather exalt and praise an already present one, inside people without the verbal talent to express it the way he did.

And, as most teenagers, he doesn't even bother writing properly, and jot funky rebel signatures in his emails. In plain English, the guy's simply an immature neckbeard. Too bad he claims himself to be a Lisp hacker: it just helps further mar the image of the average Lisp programmer, in detriment of the very few sane (and socially capable) ones.

For good C++ criticism, Yossi Kreinin's FQA is a much better read, in every aspect. Specially because Marshall Cline's FAQ, its antagonist, is a terrible read: he is arrogant, yield unfunny jokes, and sometimes outright lie to the reader. He wears that damned sort of "expert aura" which has also contributed for the bad reputation of C++, making it sound as a language for pedants and help stratifying the programming community into castes.

>>48
Not really, the compiler already detects such cases. True, the C++ grammar is much harder to parse than the C grammar, but, fortunately or not, that problem has already been solved. GCC, for example, is particularly retarded: ever noticed the "each undeclared identifier is reported only once for each function it appears in" (which happens in C and in C++) messages it spits you, sometimes uselessly consuming three lines in your screen? The message's intent is probably to avoid build log pollution, but that's exactly what it does. This is just an example: that's the compiler team's way of being "helpful" to the programmer.

>>52
The fact that most C++ programmers restrict themselves to some subsets of the language is actually necessary, and rather intentional. Concerning the fact that the language contains a lot of different thinking models imbued in it, it is good that a program is itself restricted to a couple of these models, instead of attempting to apply all of them in the same program, which would be awkward and difficult to understand. Whether a language with such characteristics ("multiparadigm", in buzzwords) is itself "good", is just another matter.

Uglyness and complications are highly subjective factors. The C++ syntax I consider ugly is related to the standard libraries and to legacy C constructs, but in general I find it much pleasant to read than Java or Python code, for that's sake. The C++ syntax fits quite well for its purposes.

I like minimalism. I enjoy the idea of taking instead of putting, of having less instead of more. It fits my style, but that's not the point -- I'm not applying personal judgements to a piece of work as it appeals to me, but rather try to evaluate it as it is, in the context where it was intended to fit in. C++ was not meant to be minimalistic; stating it is not so is just reiterating a known fact, and remarking that it is (therefore) bad falls within the scope of subjectiveness and personal opinion.

C++ is indeed old: thread support just came in with C++11, and it still lacks a lot of important things for proper application development, such as networking support. This is, nonetheless, a characteristic of the (official) standardizing process, specially because one of its goals is to provide a lowest common denominator between all platforms the language is intended to target. It follows the C mentality of "if PDP-11 doesn't have it, C++ doesn't have it either". Most C programs are non-compliant, as most C++ programs are.

Aside the entire toolchain problem, one point also worth noticing is that there is a relative lack of good libraries for C++ (and there ain't nothing such as POSIX for further extend the possibilities). Boost is always there, but I personally don't consider it to be a good library.

There's nothing wrong with C++, it's decent at what it was designed to do. I.e., to be an OO superset of C. If you need an OO language that is a superset of C, then you should use C++ (or Objective-C), otherwise there are better languages out there.

>>61
There's nothing wrong with brainfuck, it's decent at what it was designed to do. I.e., to be a turing tarpit. If you need a useless language that is a turing tarpit, then you should use brainfuck (or befunge), otherwise there are better languages out there.

>>62

Is /prog/ particularly retarded today, or just trolling?

Is >>63 particularly retarded today, or just trolling?

>>61
Endless ignorance. Do you seriously think that adding OO to C could only be done by C++ retardation? What the fucking fuck.

>>60


fyi epistemology is the branch of philosophy that is about how knowledge is obtained. C++ encourages you to use your magic prediction powers to be able to tell what the program will look like before you write it. That's what he was complaining about. Any language that isn't good for exploratory programming isn't good for programming at all. And that's the essence of 'premature optimization is the root of all evil' It is IMPOSSIBLE to make something both flexible and optimized. You have to optimize later, when the design is settled. C++ does not allow this attitude.

And this DOES affect personality. Someone who prides himself on his ability to anticipate needs is known as "codependent", and it's an unhealthy way to live your life. It comes along with intense fear of vulnerability and distrust of anyone around you to take care of themselves. The parallels that these traits have with the semantics of the C++ language and how it is idiomatically used are pretty obvious, I think.

And yeah, I'm projecting my own experience. But I've seen it in my peers and others on the internet (including Naggum) have seen the same pattern. Some programmers can write code all day without it affecting the way they think, but the parallels between how C++ works and genuine psychological dysfunction don't speak well for the language either way, I think.

>>60
Uglyness and complications are highly subjective factors.
related to the standard libraries and to legacy C features

No.

template <typename T>
bool write(const T& obj) {
    typename T::iter i = obj.iter();
    // ...
}
Is typename really necessary? Oh wait. There's this nice feature auto type inference in the C++11.

template <typename T>
bool write(const T& obj) {
    auto i = obj.iter();
    // ...
}
auto type inference

template<class A, class B>
auto add(const A &a, const B &b) -> decltype(a+b) {return a+b;}
If this isn't ugly, at least it's verbose.
Seriously, C++ is going to break.

>>66

I know what epistemology is. I know about every term used in the post means. Many people don't, however, and using such terms with almost no adequate context for that just creates communication noise. Communication noise is both a consequence of bad communication skills, and of intentional blabbery in order to induce confusion, excitement and anger, disguised as intellectually profound reasoning. The point he possibly wished to express in the post is deeply buried behind an intentionally confusing verbosity -- even comparable to the "C++ complexity" he so much condemns, if you permit me an alias.

In other words: what he really intended is to cause public commotion and exasperation, and to impress the audience. Gain the argument through aesthetics. Or at least that's the way I judge it, since by no means I take the guy for a stupid man.

Apart that, I agree with some things you've said. The language induces some behavioral patterns on people, as much as human languages do that (that is called "Sapir-Whorf hypothesis"). However, do other OO languages induce "better" behavior and mental discipline than C++? Do they differ at all? C++ is not much different from other OO languages. As it is already clear from what I've been arguing, OO itself numbs people down to their bogs, but that's just my opinion.

I don't see such a need of foresight in C++, or, if I do, I don't see why it differs from other object-oriented languages. The need of such an ability -- to foresight what your needs will be, before even having any sketch of your layout --, assuming it exists, is bound to the object-oriented mentality itself, not the language. I'm not particularly fond of the OO mentality itself, but C++ can't be blamed for it. What I see is that everything in the object-orientation world is difficult, but C++ doesn't contribute to make it harder. Design issues are bound to the paradigm, and the language -- by offering "too much" in any regard -- can't make it more difficult. For example, I don't consider whether a reference or a pointer will be used to be a design decision in itself, neither whether some symbol will be in some namespace or another (since the language allows you to do mostly anything you want to do in many dimensions), and so on. I consider that people who lose themselves in these problems, and need some language constraints to keep them in track, have failed to grasp the greater design problem of their projects.

I will make an exception: weak-typed languages (Python comes to my mind), where you don't have to explicitly declare types and they may vary in the runtime, ward off a lot of problems you usually have in OO. Duck-typing allow you to boost enormously your code, writing future-compatible code without the need of even specifying what future code needs to do in order to communicate with your design: they just need to provide a compatible interface. But they do introduce another gigantic pack of problems which are automatically solved in strong-typed languages, and I suppose you are well aware of those problems. Well, C++ has simply opted for one of this problem/solution pairs.

>>67
automatic type inference is my new waifu

>>69
Haskell
- Just like C++, Haskell is very hard to learn, and takes years to master. Things like Monads, Functors, Monoids, Higher-Order Types and a myriad of morphisms are hard to understand, especially without mathematical background. So most programmers probably don't have the ability or will to learn Haskell. Learning Haskell's syntax, libraries, functional programming techniques won't bring you closer to understanding: the true path to understand Haskell lies through Monoid-Functor-Applicative-Arrow-Monad. And even if you mange to learn Haskell, programming it still hogs a lot of brain resources, which could have been put to something more useful than just showing off about how clever you can be. "Zygohistomorphic prepromorphism: Zygo implements semi-mutual recursion like a zygomorphism. Para gives you access to your result à la paramorphism." -- HaskellWiki
- Haskell is slow and leaks memory. GHC's inefficient stop-the-world GC does not scale. A good understanding of evaluation order is very important for writing practical programs. People using Haskell often have no idea how evaluation affects the efficiency. It is no coincidence that Haskell programmers end up floundering around with space leaks that they do not understand. "The next Haskell will be strict." -- Simon Peyton-Jones
- Haskell's API lacks higher levels of abstraction, due to absence of variadic functions, optional arguments and keywords. Macros aren't possible either, due to overly complex syntax of Haskell. API documentation is very lacking: if you want to use regexes, you start at Text.Regex.Posix, seeing that =~ and =~~ are the high level API, and the hyperlinks for those functions go to Text.Regex.Posix.Wrap, where the main functions are not actually documented at all, so you look at the type signatures, trying to understand them and they are rather intimidating (class RegexOptions regex compOpt execOpt => RegexMaker regex compOpt execOpt source | regex -> compOpt execOpt, compOpt -> regex execOpt, execOpt -> regex compOpt where). They are using multi-parameter type classes and functional dependencies. The signature really wont give you any clue to how to actually use this API, which is a science in itself. Haskell is a language where memoization is a PhD-level topic.
- Haskell programming relies on mathematical modelling with type system (a version of mathematical Set Theory). If one does not use the type system for anything useful, it obviously will be nothing but a burden. Programs are limited by the expressiveness of the type system of the language - e.g. heterogeneous data structures aren't possible w/o reinventing explicit tagging. All that makes Haskell bad for prototyping or anything new, due to need of having design document with all types beforehand, which changes often during prototyping. Any complex project have to reinvent dynamic typing. For instance, Grempa uses dynamic typing because the semantic action functions are put in an array indexing rule and production numbers (Ints) to functions, and they all have different types and so can not be put in an ordinary array expecting the same type for each element.
- The IDE options cannot be as good as those of dynamic programming languages, due to absence of run-time information and access to running program's state. Haskell's necrophilia forces you to work with "dead" code. Like other static languages, Haskell isn't well-known for its "reload on the fly" productivity. No eval or self-modifying code. Haskell code can't be changed without recompiling half of application and restarting the process. GHCI - is the best Haskell's interactivity can get, and still wont allow you to change types during runtime, while the single assignment semantics prevents redefinition of functions. As said Simon Peyton-Jones, "In the end, any program must manipulate state. A program that has no side effects whatsoever is a kind of black box. All you can tell is that the box gets hotter."
- Type system produced compile-time and link-time errors are distracting and make it harder to run and test your code, while type-checking isn't a substitute for testing, it is about correspondence to mathematical model, which has nothing to do with correctness - i.e. two numbers can be integers, but their quotient can still result into division by zero. Even though you may hear strong static-typing advocates say, "When your program type-checks, you'll often find that it just works", this is simply not true for large, intricate programs. Although type-checking may help you find model-related errors, it is not the same as testing.
- Absence of dynamic scope, implicit open recursion, late binding, and duck typing severely limits Haskell, since there are things that can't be done easily without these features: you can't implement dynamic scope in general (and be type-safe) without converting your entire program to use tagged values. So in this respect, Haskell is inferior to dynamic typing languages.
- Haskell makes it easy to write cryptic programs that no-one understands, not even yourself a few days later. Rich, baroque syntax, lazy evaluation and a tradition defining an operator for every function - all help obfuscation a lot. As a general rule, Haskell syntax is incredibly impenetrable: who in their right mind thought up the operators named .&., <|> and >>=?

>>67

I agree with you there. typename is simply a cue for the parser to be able to parse the grammar, useless to the programmer. Template parsing yields ambiguities, and the way C++ solved it is hinting the parser with extra tokens to avoid reduction conflicts. This is one huge wart in my opinion.

Nonetheless, G++ and MSVC are able to parse the code without the typename keyword prefixing a dependent type whatsoever. Maybe these usages will futurely disappear.

Some choices for keywords in C++11 sounds ridiculous to me too. nullptr, decltype, typename and more. This obsessive need to have a single-pass compiler (forcing the language to be polluted with non-intuitive syntax) is also a botch.

However, when people don't like something, they should manifest the discontent in order to yield changes. In my humble opinion, C++11 could have been much better if the community -- not the language, not the technical needs -- behaved better during these ten years the language gained popularity, both C++ aficionados and C++ haters. Aficionados behave as if they were programming gods, praising complexity and further legitimizing the criticism the C++ haters themselves shoot against them.

>>71
No.
While there's ridiculous choices, they were mostly proposed along the years by some expert programmers. One example is how Modern C++ Design and Effective C++ lead to some practices, libraries and idioms that heavily influenced the TR1. Even with enough care, some verbosity and weird constructs will never be erased of the C++ language.

I really believe that people need redesign and create a completely new language. D and Go were nice attempts, but don't fit my tastes yet.

But I don't think this is a big deal. C++ looks bad just because there are more interesting alternatives, but they still can't fit the high-performance computation marketshare.

Here at my (CS) department 80+% of lab mates use C++, in various fields: machine learning, image processing, database extensions, language processing, fluid dynamics... because they demand speed. The other 20% mainly use Java/Ruby/Python when working on not so sensitive apps, like software engineering tools and HCI prototypes.

The engineering dept. people here pretty much use MATLAB for everything, and some prefer Fortran for high performance computing.

It's sad that functional and logic languages almost have no users here, despite their high level abstraction and power. It was an interesting fact that people that learned these “strange” languages (Haskell, Prolog, LISP...) well usually took them to heart and did very fruitful things like 3D games and SQL query engines.

>>68
the thing is, C++ basically invented modern, typical OOP. Java and C# in particular base their models directly on C++. Languages like Smalltalk and CLOS were perhaps in the background, but, funny enough, these languages are both all about duck-typing and extensible, future-proof design as a consideration above and beyond performance.

In a general comparison of CL and C++ you see a reoccurring pattern. It isn't that C++ made a different, arbitrary choice of problem/solution pairs. It's that C++ ALWAYS chooses the option that corresponds to premature optimization. And CL isn't even the best example, just a convenient reference point.

Multimethods: flexible and generic.
vtables: optimized

lambda: flexible and generic
classes: optimized

garbage collection: flexible and generic
the stack, shared_pointer, etc: optimized

numerical tower: flexible and generic
int,float,double, iirc STL has not standardized a bignum class yet: optimized

macros, essentially a "scriptable compiler": flexible and generic
leave the compiler alone so it can micro-optimize better: optimized

So, if C++ made any arbitrary choice of problem to tackle, it was to design a language that is easy for compilers (human or non, to borrow a Paul Graham-ism) to optimize, not to make it easier for programmers to write better software. This isn't in and of itself a problem. It's what C does. The difference is that C is honest about what it is and what it's for. It's a language for implementing a solved problem in an efficient and portable way. C++ OTOH has a pretense that it's not just fancy assembly.

>>74
the thing is, C++ basically invented modern, typical OOP.
You have to be joking. Have to be. Have you ever used those other languages? They have actual features like reflection and encapsulation. C++ showed everyone one think with crystal clarity: how not to do anything.

>>74
multiparadigm + optmization + C compiler → C++

C++
http://img.0chan.ru/b/src/13233783418939.jpg

>>72

Indeed. But think again: what is an expert programmer for you? I won't completely discredit the authors you've mentioned, but I wouldn't really call them "expert" either -- specially because, seeing some code they augment, I wouldn't use nor recommend some of the practices; I wouldn't hire them for my team. These authors respond more to the financial interests of the companies which support them than to the community of which they claim to make part. They drive the development of things like Boost, turning them into models to follow, naming them "expert" code -- and in the same time offering advice and consulting at expensive fees; a very interesting market strategy indeed. It seems even natural for me that these people will separate themselves from the crowd, and protect their reputation as "experts".

Besides, while Java, C# and others are leading technologies owned by the same companies which pay the "experts", C++ is rather owned by no one -- why would a company invest on something it doesn't own if it can invest on it's own technology, which is already deployed and already popular in the language battlefield? It could be argued that the "experts" have even intentionally worsened a number of things out in C++11, but I won't go too far as to sustain this idea. The fact is that C++ is of few commercial interest compared to technologies which are so aggressively pushed by companies nowadays.

Expert programmers are programmers with good experience, which have good knowledge of the technology they use, and which have passed through some tough situations during their careers. They have sensible notions regarding many aspects in a project, even if they wouldn't agree on every such aspect. And there are a lot of experienced programmers out there: not only those inside the C or C++ fandom, but in particular there are a good number of them in these groups. There are a lot of people which could have done much better if they just expressed their points objectively and neutrally, instead of bashing themselves senseless with petty discussions regarding specific "tastes".

C++ is a package of FUD, well wrapped in a foil of vanity.

Ultimately, C++ designs can be simple and tidy. Even if the problems they attempt to model are complex, the solutions can be simple, easy to use, easy to understand, easy to maintain. They can be nonetheless extremely cluttered and complicated, and even "wrong" in a OO perspective, specially because OO is a design pattern particularly difficult to implement: writing bad code is not a problem specific to C++ itself.

>>77
ru
Back to your russian imageboard.

>>78
C++ is a package of FUD
I wanna be a FUD
http://en.wikipedia.org/wiki/Female_urination_device

>>74

But why "optimized" in straight contrast with "flexible and generic"? Specially, why "prematurely" optimized? I see these design decisions as simply the most natural, direct and even simple way to implement some functionalities. I don't see them as premature optimizations. For example, I would categorize some ridiculous C++ idioms such as CRTP into the "premature optimization" moniker, but in general, C++'s execution model is just extremely simple, not "prematurely optimized". These decisions are not performance-driven.

Just to illustrate my point, one could argue that garbage collecting, multimethods and other things you've mentioned are just "premature flexibility". I have faced just very few situations in which I really needed things like that, for projects of different nature.

Not that these things are bad, much for the contrary: they're good tools when applied in the correct problems. C++ simply opted not to impute these tools to every program beforehand. And many, if not all, of them can be implemented, nonetheless, in C++, with the particular advantage (if it could be said so) that the programmer knows these things are present in their program, and exactly where they are, if it matters to him. I understand that syntax is not just sugar and, for example, while lambdas cannot be compared with functors, since they're much more expressive and syntactically easy to manipulate, functors usually fill in well the gap lambdas were supposed to fill, and these objects fit even better (in my opinion) with the overall rest of the language. And these features can be implemented in different ways, with different goals in mind. This is a very important degree of "flexibility and genericity", in my opinion, which is often overlooked because they don't come in the shape people are used to.

And lastly, well, C++ surely isn't easy for compilers. It is possibly the most difficult language to parse and to optimize; that's why compilers fail so badly in providing good, human-level responses and results to the user.

>>80
oh wow talk about feminism's greatest invention

>>78
Okay, maybe I wasn't clear enough.
Expert programmers are programmers with good experience,...
... they were proposed along the years by some expert programmers.
I mean, people with good experience naturally avoided common problems and started better designs. Some of these practices were just collected by these authors, so they can't take full credit for this “awesome” TR1.

specific “tastes”.
I consider any individual opinions as a matter of taste. When a group of people has the same taste, then this makes a pattern that could evolve to a future standard taste.

For example, S-expressions in Lisp.
“... a community of S-expression Lisp programmers quickly developed. M-expressions fell into neglect, and were never implemented.” -- http://en.wikipedia.org/wiki/M-expression

>>81
If you don't care about performance right off the bat, there is no reason at all to use C++. If you do care about performance, C++ makes it extremely difficult, if not impossible, to measure in general cases. So the target audience for C++ are projects with well-defined requirements, known in advance, and well-defined use-cases, known in advance. In such cases using a restricted subset of C++ is not unreasonable (though only because nothing else quite applies).

We call them "games."

Lisp is shit.

>>85
How many syntactically equivalent ways do you need to cry more faggot?

>>74
the thing is, C++ basically invented modern, typical OOP.
lol no HIBT?
That title goes to Simula-67. C++ is an evolutionary dead-end spanning straight from Simula-67 with Algol syntax changed to C, multiple inheritance added, GC stripped out, and coroutines ignored, in fact, Stroustrup wrote Cfront because he wanted a Simula with manual memory management. If you look at 1967 language's code it looks like modern OO. All later language designs re-borrowed back giving back GC, single inheritance and almost coroutines.

>>86
Fuck off and die, faggot storm. Lisp is shit.

>>82
I don't think so because this doesn't have anything with political, social or economic, but anatomical equality, which reminds me of female sexists. While I do love women in general, I don't like female sexists.

>>88
I'm already dead. What now, faggot?

>>90
Kill yourself.

"Lisp" stands for "Lisp Is Syntactically Pure"

                __ __
      /    /   /  /_/
     /__  / __/  /

        /  .  \
       /   '   \
      /    |    \
     /           \
    /      |      \

>>93
That was 1993 quality!

Lisp, for me, has always been a place where anything is possible--a refuge, a magical world where anyone can go, where all kinds of people can come together, and anything can happen. We are limited only by our imagination.

"Why is C++?"

why a duck

>>99
wow amazing dubs bro

>>99
nice lv99 dubs bro

check 'em

>>99
>>100
HOLY FUCKING FUCK FUCK DUB DUBS FUCK ME IN MY TIGHT TEEN ASSHOLE I'M CUMMING UNCONTROLLABLY

>>101
sweet, you got me a boner

>>81
I have faced just very few situations in which I really needed things like that, for projects of different nature.

This is called "blub"

For instance, functional code (both in the sense of "avoiding mutation" and "not dysfunctional" -- there is no difference, practically) is exceedingly difficult to write without a garbage collector. Automatic ref-counting in destructors can help, but it doesn't take you all the way there.

>>84
as a professional in the games industry, this kind of makes me rage. It is exactly this kind of attitude (and you have correctly identified its corollary: C++) that is keeping us from making better games. We can't iterate on designs; we have to keep reimplementing the same shitty, inflexible engines over and over.

>>103

He does have a bit of a point in that, the more assumptions are are able to make about the problem you are trying to solve, the more opportunities for optimization there are. One example would be the use of ray casting in wolfenstein 3D. Because all walls in the game were either vertical or horizontal, it was really easy to solve for the intersection point of a ray with a wall. So their limited solution could perform better than a more general solution. However, the limited solution cannot handle the general case of levels with walls that are not all vertical or horizontal. You could try to extend the limited solution until it handles the general solution, but it is likely that it would be more reliable and more productive to just start from scratch again.

>>103
we have to keep reimplementing the same shitty, inflexible engines over and over.
U MENA FROSTBITE?

>>111
Check 'em!

>>103
as a professional in the games industry, this kind of makes me rage. It is exactly this kind of attitude (and you have correctly identified its corollary: C++) that is keeping us from making better games.
It seems like you understood, but just to be clear, I wasn't trying to rag on abstract game programming, only how most in the industry seem to do it. As a gamer of 30 years I agree, things are very stale.

>>83

I understand better what you intended to mean now. However, doesn't it sound paradoxal? That is: if the community has indeed directed the language development, why does the community criticizes it so badly?

I still personally believe that the true C++ community, and the true programming community for that's sake, is totally apart from the people who actually decides things for the language. This must happen in many committees, but this is specially true in the C++ case, because of the problem of the economical interests I've proposed. Anyway, that's only my personal opinion on the matter.

>>84

Nothing could be further from the truth. First, why shouldn't C++ be used by people which don't care about performance? As I stated, C++ wasn't designed with straight performance in mind, but rather implementation simplicity in the lower level. Even in the frontend level, writing a template is not harder than writing a complex C macro which would perform the same task, writing a class hierarchy is not harder than writing the same hierarchy in parallel languages, and applying "expert" techniques and practices is not at all needed to write a good, working piece of code in C++. The lack of libraries, indeed, is an inherent problem, but there are excellent C++ frameworks out there; Qt is one which comes to my mind. The bottom line is, C++ can be (and should be) used by "normal", "non-expert" people.

Second, why does C++ make it much more difficult to properly profile code?

Profiling C++ code is not much different from profiling C code, maybe except in areas where templates are involved -- but templates are usually restricted to some specific parts of the program, mostly containers and special pointer types. Using them in most other situations, as I have stated, is indeed a symptom of premature optimization, and it's comparable, in form and content, to abuse C macros which generate syntax. (Curiously, one can't easily debug or profile easily those macros also: even the compiler will mess up the error message line numbers when compiling a macro which has expanded to invalid code.)

Profiling is, in general, difficult to perform, independently of the language; however, once more, C++ doesn't make it specially harder. Most arguments in this aspect denounce things like, "syntactically one can't know whether a sum operator was overloaded into a O(n2) operation"; however, no sane design does that; no sane design binds semantics to methods and operators too far from what they're subjectively intended to mean, and if the operation is costly, no sane design would hide that fact under a "convenience" disguise. This is not specific to C++ either.

>>103

I understand the need for a garbage collector when writing functional code, and it is legitimate. But the Blub argument, for me, is not.

First of all, the entire idea of people "not knowing they need something", or "not knowing they could use of some other thinking paradigm or technique" is faux. Assembly language programmers know they could use of some more parsing power. C programmers know they could use of some more metaprogramming facilities, or some more object-orientation techniques in some cases. C++ programmers know they could use of some garbage collecting, or some sort of automatic memory management. Java programmers feel the need for proper closures when such a need really appears. People with some experience know what they need, when they need it, even when they're unaware those techniques already exist elsewhere: that's the root cause of the creation of language "idioms" in programming communities. Many newcomers to the programming world quickly "invent" simple data structures, such as linked lists and trees, without having ever touched computer science literature.

Second, pushing "new paradigms" to people is, at the best, an argument against simplicity and minimalism. At the worst, I would say it is an extremely pedantic way of selling "dreams" to people, dreams of developing awesome productivity, or of developing a revolutionary mindset. I go to an extreme and claim that it is even right-winged in the sense that it inevitably culminates on the always implicit idea that "everyone thinks the same, and I'm special because I don't". Not really: people are not completely stupid. Java programmers are not stupid because they don't know all the power Lisp macros offer, or all the power monads and zygomorphisms in Haskell offer, or all the power C++ templates offer. They're not bound to an "inferior" mindset because their language has less "power" (which is, par excellence, an extremely subjective aspect) than others. Needs grow outwards, and are not pushed inwards someone.

Lastly, I'll develop a little this "powerful language" part. A "powerful" programming language to one person is a terrible language to another. Ask Steve Hutchessen or Randall Hyde about assembly programming and they will be quite comfortable to claim it is the most powerful language around, unbeatably. Ask Paul Graham, he'll defend Lisp. Ask Stroustrup, he'll naturally claim for C++. Are they wrong? Are they lying? These people are not stupid, and don't work on simple summer projects. Each one of them does have a strong point to make. Apart this, there always will be people who claim something is better than something else, and will even appeal to intellectually elaborate arguments (such as the Blub argument) in order to convince, or maybe make feel people uncomfortable about the subject. Objectively speaking, each one of the most popular languages have good, clear and mensurable traits, and bad ones also. So does C++, albeit I feel these traits are never brought up to surface precisely due to the amount of bashing between programmers claiming the poison they've picked are better than the others'.

Claiming something is absolutely superior to something else almost immediately proves  not raw stupidity, but rather a degree of narrow-mindedness.

>>108
If you don't know the answers to your own questions, you either haven't used C++ enough, or you haven't used other languages enough. It is hard to say exactly where your fault is.

>>108
I don't believe. While the C++ commitee may be distant from the programming community, programmers could fork their way around if they felt too much suffocated. I agree that Qt is really a good piece of decent C++ software, and that didn't come from the C++ commitee.

Now, about people... I completely disagree. It isn't that people can be dumb sometimes. They are always retards. Myself included. It just happens that humans are very afraid of new experiences, just like the fucking old Myth of the Cave. You can just see here the amount of jokes directed to homossexuality or [dumbproof,enterprise,bloated] languages/softwares.

People with strong wording are just scared blockheads, and try to use (obscure) technical words to put challengers away, just because they are absolutely sure that their knowledge is the truth. Hyde, Graham, Stroustrup, and many others have different point of views because their usages of computers are also different. I can guess they have enough experience to judge what is most appropriate, but depending on the person you're asking, implementing something in CL instead of C++ can be either “done in a weekend with 2-3x slower” or “done in a week and 100-200% faster”, and both can be right, depending on the actual situation.

The only true abomination really is the people that don't go out of the cave and keep blabbering that their choice is way better than yours. How can someone say that coke is better than pepsi if he didn't taste both? But what really makes me mad is that when I try to show these people something they just turn around yelling crap!

(And that explains why “smart” people are: [a] extremely anti-social or [b] almost divinely humble.)

>>110
you can't just judge homosexuals without taking in the ass once?

>>111
you can't just drug addicts without taking in heroin once?

>>111
you can't judge homosexuals without trying Lisp once?

>>111
you can't judge jews without trying Haskell once?

>>>111-114
When you are shithe full of yourself, no.
Sage learns through these unfruitful discussions indeed.

LISP
NOT
EVEN
ONCE

>>108
first off, disregarding Blub is kind of silly. Everyone who has ever said Blub is a real thing does so because they've personally experienced it, myself included (and apparently >>110 as well.) Maybe you're special. But I'll talk about your particular points anyway.

the problem is that those "new idioms" and design patterns tend to form a reputation as harmful or useless or over-engineered, because the language rarely makes it worth it to use them.

For instance, most C programmers hear "macro" and think about Microsoft's shitty macros in their API and other shitty macros they've used. They think, "oh, Lisp programmers must be those guys who write clever macro hacks and confuse everyone. I bet every Lisp DSL is an unreadable mess that only the author can understand, just like C DSLs. I guess Lisp is a toy language and would be harmful in a large project."

The Lisp programmer on the other side is thinking "writing C is such a pain. Its macros are so crappy that I can't even really use them for anything beyond simple little things or else it just turns into a huge mess."

I don't usually consider macros as "important" part of language, more like generic building blocks to save the building time.
You use C macros not to invent a mini-language but to do what macro is intended to do since first assembler macros:
to save typing time. Abstraction level of macro is just a bonus, not something C macros are very good at(its just text juggling).
You could just as well remove or expand macros yourself, with some productivity loss. it won't change a single thing in C.
In Lisp you really need the macros, or the language would feel crippled. Macro extends lisp since the syntax/functionality extension via new functions to macro is trivial: lisp functions are forced to be syntax-free soup of words which can be macroed to infinity with prefix notation: it will just be a stack of macro on top of macro on top of macros....plus its abusing the entire language power at runtime.
If you don't find this unmaintainable and complain about simple C macros which are pristine sights of clarity and simplicity compared to Lisp macros which are using everything to manipulate code(as i understand you can also manipulate string of C code and output it similar to this but the process will be incredibly messy compared to plain C macros(it would be emulating a Lisp interpreter at run-time to construct the final code and compile/execute it) and much longer, so normal C programmers avoid this type of design).

>>118
>I don't usually consider macros as "important" part of language
You use only gotos, because for-loop is a macro?

>>118
it would be emulating a Lisp interpreter at run-time to construct the final code and compile/execute it) and much longer, so normal C programmers avoid this type of design
Blub doesn't allow it, so it must be shit. Perfect logic, moron!

The only thing I hate about C++ is how it makes it really easy to create huge thick lasagnas of abstraction and overcomplicate things a lot.

D is better that is all

>>110

Having already mentioned that I don't always expect people to be complete morasses of stupidity, I agree with everything else you've said, wholeheartedly. You have actually summarized what I've said (or intended to say anyway). It too makes my blood boil whenever people blindly refuse to receive new ideas, but what can we do? We ain't responsible for that, anyway. I strive to save my energy for people which are worth any cause.

The C++ fandom is incredibly filled with people who abuse wording power. And the C++ enemies (such as that guy in the mailing list) are no weaker with respect to this. Language wars are particularly funny (if they would not be rather sad) because people engage in them with such a passionate and zealous spirit that it really sounds like a religious argument. C++ battles are particularly epic.

>>117

I'm not special in any way, and I don't disregard the Blub sentiment. I just don't think it holds as an argument for inducing (or rather pushing) mentality changes, for the reasons I've written before. Ultimately, I think that applying the Blub argument is just a too easy way to win any debate, because it sounds like religion. Compare: "Of course you disagree with me, after all you have never been exposed to the X thinking paradigm and thus you're unable to think otherwise" with "Of course you disagree with me, after all you're not Christian and thus Satan's influence is on you." (This is just an example, please don't take it personally or even religiously :)

Once in a while one will have the Blub feeling. However, as I told you before, people will rather develop a degree of creativity in response to it, instead of being permanently locked inside a mental cage as Graham's argument will suggest. I'm absolutely sure even you have done it, too, specially if you're a self-taught programmer: haven't you ever "invented" things during your initial programming experiences? I'm sure you did, everyone else I know did that. Sure, there is a limit up to which this phenomena will go: seldom will a person reinvent lambda-calculus or abstract logic-programming through C syntax, but one is nevertheless well aware and well open to consume and understand these new ideas in the moment one's exposed to them.

The whole problem regarding the wordplay in your macro example could not be more true. Language is tricky in the sense that it is not guaranteed that one word or expression ("macro" in your example) will correlate to the same concept people are expecting them to. This is a very dangerous degree of communication noise, and the most important problem, in my sole opinion. I often think that many of the world's problems themselves are caused simply because people misunderstand each other -- and they do it often at the very basic language level. As it is expected, people concerned with this kind of problem will appeal to a more verbose and more carefully explained way of expressing themselves, in order to attempt to diminish this misunderstanding noise.

C "macros" and Lisp "macros" are not the same thing -- unfortunately, the same word suggest they are alike.

>>121

Yes, I agree with you. It is very easy, very easy indeed to write a problematic OO design. And C++ is no different from that, unfortunately. Just look: people in C++ can't even decide what damn source file extension to use in their projects: .cpp, .cxx, .c++, .cc, .C... how come they could ever agree on other, deeper aspects of their designs?

Are these language problems? Do people need barriers to help them decide (or rather impede them to choose) between possibilities -- including that one?

I'm well aware of the so-called "paradox of choice". It is very likely that C++ suffers from the "too many choices" disease indeed.

--

Also, thank you people for replying to my posts. I've been enjoying the discussion. I hope I have contributed to something.

>>123
I don't disagree too strongly with your take on the blub stuff. However, I'd argue that there's a professional responsibility to understand what your colleagues (and not just coworkers) are doing.

In fact, if you only have your blub then you probably don't even understand it. For years I wrote nothing but C and Perl (sysadmin+programmer at an ISP), but after learning other languages I felt I was blind about the very languages I was using. Sometimes, for example, there's a non-local but accessible minima within your blub, but just outside the perspective it presents. But it's also about understanding limits.

Re: inventiveness, I'm always amazed by this. I haven't seen lambda calculus re-invented, but I have seen fixed-point combinators reinvented in more than half the cases I've seen them used. (It's hard to solve until you actually need it.)

>>123
Listen, guy.

You seem different from the average /prog/ scum, so I'm going to try to enlighten you.

The only purpose of a practical programming language is to allow writing of useful programs. The only measure of usefulness of a programming language is the usefulness of the programs written in it. Everything else, how helpful the language really was, how much did it boost the programmers' productivity, which features of it were most useful, are secondary details encompassed and relying on that one and only measure.

The purpose of a practical programming language is most definitely not to inspire flames on anonymous textboards, mailing lists, usenet groups, etc.

The usefulness of a programming language most definitely can't be appraised by discussing its merits, in the abstract. How many times have you designed a moderately complex system that seemed absolutely perfect in every respect, only to discover that it absolutely sucks in practice, that all problems that it purported to solve are either irrelevant or not really solved at all? Myself, one too many, so I simply don't trust abstract reasoning any more.

So. The only valid kind of discussions about programming languages begins with a demonstration of a useful program, or, better, several useful programs, written in some language or in some dialect, or using some new approach, which, supposedly, made writing that program somewhat easier. Then you get people who want to write useful programs with less effort, asking you: OK, can you tell us more about your experience and explain the thinking behind it working in that exact way?

You see, the fundamental hurdle is overcome by definition this way: they aren't, like, "I think that your thing sucks, prove me wrong", they are already convinced that your thing might be useful and now only politely request clarifications.

The discussion no longer looks like: "why do I think this thing must be useful", but "this thing is useful, here's how, exactly". The latter kind of discussions can be useful, the former -- can't, ever.

My point is, go do some motherfucking programming, motherfucker: http://programming-motherfucker.com/, instead of wasting your intelligence on pointless discussions.

>>125

Slow day at Burger King?

>>125
I don't know what all that follows from, but if you have to demonstrate everything from the ground up every time you want to discuss a topic you're probably not talking to the right people. For example, it's more productive to have a discussion about programming with experienced programmers than with goldfish.

If you're introducing something new or even a new combination of features in a PL, then sure, by all means you'd better demonstrate it. But if there's an established language or technique which improves quality and productivity for certain types of problems then demanding a personal demonstration is just willful ignorance. Besides, if I write the code, you will not learn much at all. The blub argument isn't merely about ones ability to judge a language or technique, it's about ones inability to assess it due to ignorance, having failed to fully understand the demonstration.

Blub isn't really a serious problem, except that it keeps people writing terrible PHP, Ruby and Java code. I see a lot of this and think "if they'd only try something that made them think differently they'd come back and write the best blub of their lives!" Getting back to the demonstration, it usually looks like more work even if just conceptually. The hill is a little steep but not as high as it seems, and the valley on the other side is quite deep. But you may never know. I can show you pictures, but you need to travel there yourself to understand its relationship with your side of the hill.

>>123
I think that Lisp and C macros have some important similarities that warrant the same term. They're both systems for transforming code before it is evaluated. The only major difference really is that C's macro language is a non-Turing-equivalent text copy-paster, and Lisp's macro language is Lisp.

And as for inventiveness, it is often a matter of standing on the shoulders of giants. If it's hard to reinvent lambda calculus in C, try monads and state-less programming, which builds very heavily on lambda. People don't do these things in C because C doesn't make it worth it. That's what I keep saying. People certainly CAN make complex data structures in asm, but they don't. Not typically. People CAN write an immutable array-mapped hash tri in COBOL, but COBOL does not make it worth it.

And that's what language features are to me. It's when a language makes it worth it to use a particular strategy. And I really think it takes a language. In C++ and old-style (pre-closure) Java you always see the big systems: a) make an 'architecture' which implement half of a higher level language and b) lots of XML, which makes up the syntax of that language. It seems downright unavoidable.

Blub programmers don't stumble in the middle of coding and say "i need some high-level functions to simplify this or Lisp macros to generate this". They code. They produce software. They write pages of docs. Blub is very useful and easy in what it does. Blub would lose some abstract fights, but Blub uses abstraction in a limited way that is enough for most programmers.
And thus Blub is "worse is better" personified since it does not pay for any abstraction it does not use.

>>127
You don't understand. It's not about demonstration for the purpose of explanation, it's about demonstration for the purpose of proof.

Imagine someone claiming that he considered various possibilities and concluded that spherical cars (which he calls "cudders") are in every possible way superior to traditional car-shaped cars. They have better structural integrity, dissipate less heat, etc. The logic is irrefutable. So you ask, where's your prototype, dude? Are you an engineer or a fucking philosopher? You don't logically prove that your design is superior, you build a prototype and prove by demonstration, that's the only kind of proof acceptable in engineering.

The blub argument isn't merely about ones ability to judge a language or technique, it's about ones inability to assess it due to ignorance, having failed to fully understand the demonstration.
The Blub argument is horribly misguided, because it assumes that people are supposed to judge a language by learning it, but then they are too lazy and remain ignorant, blah blah blah. People judge a language by observing the programs written in the language. Not even reading them, just noticing that they exist, are developed at such and such pace, have such and such defect incidence, etc.

You don't hear Blub programmers saying that yes, from seeing various useful Lisp programs they can infer that Lisp is clearly superior to Blub, but, sadly, they are too stupid to understand why. What you hear instead is them saying "proofcode or get the fuck out", and rightfully so.

>>128
What is the saying? If it is easy to use, but hard to do right, it should be part of the language.

The whole "Blub is bad" spouted by Paul Graham is more of "Blub is primitive and does not have X built-in"
Notice he doesn't mention speed, memory use, any real world characteristics but only abstracted out "power" since obvious this "power" is free(in performance) and does not require any "mental resources" unlike Blub.
    "Our hypothetical Blub programmer wouldn't use either [Cobol or assembly]. Of course he wouldn't program in machine language. That's what compilers are for. And as for Cobol, he doesn't know how anyone can get anything done with it. It doesn't even have x (Blub feature of your choice).

    As long as our hypothetical Blub programmer is looking down the power continuum, he knows he's looking down. Languages less powerful than Blub are obviously less powerful, because they're missing some feature he's used to. But when our hypothetical Blub programmer looks in the other direction, up the power continuum, he doesn't realize he's looking up. What he sees are merely weird languages. He probably considers them about equivalent in power to Blub, but with all this other hairy stuff thrown in as well. Blub is good enough for him, because he thinks in Blub.

    When we switch to the point of view of a programmer using any of the languages higher up the power continuum, however, we find that he in turn looks down upon Blub. How can you get anything done in Blub? It doesn't even have y.

    By induction, the only programmers in a position to see all the differences in power between the various languages are those who understand the most powerful one. (This is probably what Eric Raymond meant about Lisp making you a better programmer.) You can't trust the opinions of the others, because of the Blub paradox: they're satisfied with whatever language they happen to use, because it dictates the way they think about programs."

>>130
Don't be retarded. Lisps have been used to excellent effect for good and evil for years.

>How can you get anything done in Blub? It doesn't even have y.
because you don't do y, you do Z. Thats is the Blub way, its not as generic or complete, but its in Blub.
You want some Lisp? You have to add it yourself. Thats the Blub way.
Blub isn't better or worse, its just a niche thats wide enough for most tasks.
C++, Cobol, C, Fortran all been a form of Blub dominating the niche, and they all feel deficient, but every step in that niche in another Blub improving the former Blub. In the end Lisp will be a part of Generic Blub, and the reason for using Lisp at all will disappear.
Another worse-is-better victory.

C++ is seriously the most bloated motherfucking pile of shit ever created. When I think about all the brainpower wasted on C++, I cry a little bit.

>>133
Now it's not, at least not visibly, and that's all anyone needs to know about it.

And please don't start with the entire "you need to be popular to become popular" bullshit, languages and platforms get routinely bootstrapped based on their merit.

In 2005, people were choosing Ruby not because there was a lot of Ruby vacancies. And not because somebody convinced them to learn it on a dare, and they managed to understand the superiority of monkey patching.

In 2005, people were choosing Ruby because they saw DHH in a $1000 shirt and could smell easy money (also, Axe).

In 1970s, people were choosing C because they saw Unix and how it was ported on new hardware in the matter of days.

Contrary to the popular amongst lisp weenies belief, software industry is not "fashion-driven", Blub programmers actually have rather sensitive bullshit detectors.

>>136
I think lisp is about as popular as it can be with programmers as retarded as they are. I don't mean that as a snob, right now we need a metric fucktload of retarded programmers. I'd go so far as to say the reason we have so many retarded programmers is because we've gone about creating them because we need them.

Those who need lisp's power often find a way to use one. The naughty dog dude is still using lisps, I think actually he went from hand-rolling a lisp to hacking with mzscheme last I checked. I use Racket at work, but I'm not going to start a blog about it.

I don't really care if lisp-like languages are popular. If I cared about popularity I'd use C++.

>132

http://c2.com/cgi/wiki?PrematureOptimization

>>136

I'm not sure what you're trying to say.

Very little selects against unproductivity in the computing ecosystem. I don't think "it's what people are doing" is necessarily a good argument because of this. In the professional/enterprise world, which dominates the culture of the open source world (in the sense that the open source world is mostly professional programmers in their spare time, not full-time open source writers), productivity is essentially selected against. Your job security is improved by writing inflexible crap that takes a long time to develop. Secretly and subconsciously, few of us care if we can be more productive.

There are occasionally miracles, like Rails. But it's no surprise that it was born out of web startups and otherwise people who had a vested interest in the success of their company and not its failure. (And, again, having an interest in your company's failure is the norm.) But claiming that Ruby isn't a product of fashion is pretty... stupid. It's like the poster child for fashion in computing. "rockstars" anyone? Come on.

And, qualitatively, a lot of what Rails offers would really be better in a language with macros. But the thing is, a Lisp just doesn't superficially look as nice/familiar as Ruby. It's like getting programmers to use high level language is a matter of giving them a "spoonful of sugar" to help the medicine go down.

The problem with Blub programmers' "bullshit detectors" is that the practical effect is "everything new (to me or otherwise) is bullshit." Which is mostly true. The problem is that they don't see how bullshit their day to day work really is. If their bullshit detectors were half as 'sensitive' as you say, they'd see that spending all day debugging incidental problems caused by C++ is complete bullshit.

Because Linus and Theo say so

>>137
I think lisp is about as popular as it can be with programmers as retarded as they are.
Yeah. I want to point out one thing. Read some PG's essays back from early 2000s. He also says that all this stuff with lambdas and higher-order functions is waaaay over the head of an average (read: retarded) programmer. And that's why Lisp is unpopular. That's basically your argument, right?

Yet in 2011 if you want a job as a Visual Basic code monkey, you must know what an anonymous function is and how to use them to filter/map/reduce through your data. And the code monkeys learn that shit. And Lisp is still unpopular, and you still blame the fact on it being waaay to complex for an average programmer, now in some other ways, like macros, I guess. Funny, isn't it?

>>138
Yeah, this totally makes sense. Average FOSS programmers produce crappy, buggy, slow, bloated code at a snail's pace, such is the pervasive Enterprise culture. At the same time the Lisp master race churns out perfect code a couple of hundred times faster. But every evening they delete all the code they wrote during the day, because the world just isn't ready for it yet.

>>140
That's basically your argument, right?
No. It has nothing to do with it. I don't doubt most coders could understand anonymous functions, closures, continuations, and so forth. But the thing is that they don't understand them, they don't usually gravitate to languages which exploit them, and they continually reinvent poor solutions to problems which are aided by them. Furthermore, they continue to insist on syntax which makes much of it very difficult.

Now, before you shit your pants over a lisper blathering on about syntax, I have no problem with syntax. I quite like nice syntax, actually. But because I like nice syntax, I want the syntax to be flexible, so I can bend it to my needs, when I need it---but not before. If I do it before, then the syntax could get in the way of something nice. (Metaprogramming, for example.)

Yet in 2011 if you want a job as a Visual Basic code monkey, you must know what an anonymous function is and how to use them to filter/map/reduce through your data.
2011!!!! TWO THOUSAND FUCKING ELEVEN. This is DECADES too late. C++11 finally got anonymous functions. Are you fucking kidding me?

2011. This is a point against you, my friend.

Lisp is not complex, its just too different from normal ALGOL-type languages and the syntax is making it cryptic.
Average programmer would not choose Lisp even if Lisp was faster. The features average programmers needs are already there in Blub and Blub is fast enough.

>>140
At the same time the Lisp master race churns out perfect code a couple of hundred times faster. But every evening they delete all the code they wrote during the day, because the world just isn't ready for it yet.

Well if you were as well read of PG as you say, you'd know that is almost the case. Viaweb made Yahoo Stores in Common Lisp with 2 guys in a couple of years, and then they sold to Yahoo. Turns out, they couldn't find CL programmers to work on it, so they decided to have a couple dozen C++ programmers reimplement it in twice the time. The rumor is that they actually resorted to implementing Lisp for some of it, consciously confirming Greenspun's Tenth Rule.

The model of "high level stuff isn't used because programmers are uneducated about them and lack ambition." explains a lot more of what I see and personally experience than "high level stuff isn't used because it isn't actually valuable."

The problems with Lisp are cultural, both within and without, and solved in both cases by Clojure. Within - just needed a reboot.  Without - just need a stepping stone, like Java. Java programmers are finally seeing the value of lexical scope and immutability, but their language treats this stuff as special cases. I think Clojure will look more and more attractive to Java programmers.

>high level stuff isn't used because it isn't actually valuable.
The problem such stuff is not valuable outside of the language.
If you could port features to Blub they become valuable,thus making Blub more important and useful.

>>143
The rumor is that they actually resorted to implementing Lisp for some of it
I thought that was just PG's guess because he couldn't imagine how they'd do some of what he did without dark macrology. I know nothing of his coding skills, and I usually don't write macros because they aren't needed often, and since he agrees they aren't needed often and still felt the need to use them, I'd guess that his guess is probably correct. Sometimes you just need a fucking macro and C++ metaprogramming is a fucking joke.

>>145
macros ... aren't needed often...
...when one works on a toy problem, that has no need for it's own language.

>>146
Yeah, thats sad. All Lisp programs which don't integrate a toy language are deficient and need to be refactored.

>>146
Do you actually write programs or read about other people writing them? Even if you're going to implement a DSL, you're still not writing macros often. What the fucking fuck.

>>147
Well, I've a bunch of code, that looks like following:

(let ((var (expr)))
  (if (eq var :fail)
      (fail-expr var)
      (progn ...)))
I'll define a macro `try`:

(try (expr) (fail-expr it)
  ...)


How would you solve that?

>>130
You don't logically prove that your design is superior, you build a prototype and prove by demonstration, that's the only kind of proof acceptable in engineering.
lolwut? Anyway, software is intangible, thus it can't be engineered as it is application of the natural sciences.

The Blub argument is horribly misguided
It is not, Blub is easy to observe, if someone is exposed to BASICs (as I have when I was young), they'll write in the confines of most of BASICs paradigm.
The BASICs (incl. "structured BASICs" like QuickBASIC) were notorious for having a set of general case simple stuff intended to be BASIC, with a small bunch of cryptic shit for those who just happened to already know machine architecture and assembler like PEEK, POKE, VARPTR, VARSEG, which of course none of the BASIC manuals ever cover.
BASIC runtimes basically often had a lot of limitations like a bounded string space, limited number of string concatenations in some contexts (70 in QB45), and absolutely no advanced abstraction devices which all require a reference model to be part of the language. Despite the language, people managed to write fairly advanced things like games in it.
Exposure to C requires significant mental realignment after that as that language provides for raw references. What many attribute as object oriented being a significant improvement is mainly only having a referencing mechanism over record types, which was in assembler in raw manner and then Lisp in safe manner but with the first argument syntactically moved to the left side of the function call.

>>137
I think lisp is about as popular as it can be with programmers as retarded as they are. I don't mean that as a snob, right now we need a metric fucktload of retarded programmers. I'd go so far as to say the reason we have so many retarded programmers is because we've gone about creating them because we need them.
Indeed, Blub is used because common programmer livestock only need to write CRUD for their masters and that can be written in any language.
Most likely companies actually do use these other languages with advanced features despite speed tradeoffs because the experts the companies rely on require it but its always company secret.
Remember the russian dude that is going to prison for leaking Erlang code of Goldman Sachs.

>>140
Yet in 2011 if you want a job as a Visual Basic code monkey, you must know what an anonymous function is and how to use them to filter/map/reduce through your data
Is there a job posting with this requirement as proof? VB.NET cevolved a lot since VB6 but it still allows stuff like ON ERROR RESUME NEXT, proficiency in anon funs would seem like a outlier skill.

>>141
No. It has nothing to do with it. I don't doubt most coders could understand anonymous functions, closures, continuations, and so forth. But the thing is that they don't understand them [...]
They do understand them now, when they are in Visual Basic. The fact that Visual Basic only got them about five years ago is completely irrelevant to your argument, unless you want to argue that the average programmer's IQ jumped up forty points since then (and then you'll have to explain why Lisp still isn't popular). Which means that the "Lisp paradox" can't be explained by the stupidity of the average programmer. No matter how much the argument flatters you.

>>143
Well if you were as well read of PG as you say, you'd know that is almost the case.
You missed the point. Which was that if Lisp really boosts productivity that much and is used by good programmers, then programs written in Lisp should dominate FOSS at least. It doesn't matter how many morons are churning retarded code out there, all it should take is ten or twenty good programmers equipped with the superior tool to make all the difference. Fucking Reddit was implemented in Lisp by three or so guys, who then rewrote it in Python, ha ha.

You don't need to understand Lisp to be attracted to quality software. The premise of the Blub paradox doesn't work here. So if it is not happening, then there must be something wrong with theoretical justifications of Lisp superiority, seeing that Lisp programmers totally fail to produce superior software.

Also, I find it hilarious how you get in your rut and claim that the problem is with the incompetence of the majority of FOSS programmers, because the more incompetent they are, the easier it should be for hypothetical competent Lisp programmers to leave them in the dust. You are literally arguing for my point.

>>151
They do understand them now, when they are in Visual Basic. The fact that Visual Basic only got them about five years ago is completely irrelevant to your argument, unless you want to argue that the average programmer's IQ jumped up forty points since then
Whatever, you can continue to willfully misinterpret what I say ad infinitum so there's no point in trying to correct you.

But for those following along at home, the point is that these programmers easily handle and adopt solutions to problems already yielded decades ago by lisps. Only when a lisper points out, "Hey lisp does this," the first response is always, "When would I ever need to do that?" Then some pet language full of syntactical blunders throws in a lambda or something and there's a million blog posts about how cool language X is for doing this.

They are retarded because the solution has been there the whole time, they've been told about it, and they choose to remain willfully ignorant. Like >>151 actually.

Which was that if Lisp really boosts productivity that much and is used by good programmers, then programs written in Lisp should dominate FOSS at least.
Non sequitur. You must be the most naive motherfucker on the entire planet.

>>151
They do understand them now, when they are in Visual Basic. [...] programmer's IQ jumped up forty points since then (and then you'll have to explain why Lisp still isn't popular).
Visual Basic has a lot of stuff, it always had lots of stuff, that doesn't mean anybody is using it. It will also be avoided because the language has persisted for decades without it, all the blogspam tutorials won't cover it because they just in for the Adsense monies, and books just want you "proficient" in X hours, etc. Also, whenever anything is added to Visual Basic its because it is also in C#, VB.NET is just C# without braces, and things are added to C# to band-aid over limitations of the primary paradigm, those languages can do without the lambda, whereas lambda are central to the actual functioning of all functional languages. OTOH for Lisp's actual killer feature (protip: it is not lambda) does VB.NET have macros?

Which was that if Lisp really boosts productivity that much and is used by good programmers, then programs written in Lisp should dominate FOSS at least.
I don't know about others, but by the time I've been writing in Racket I just don't care about releasing anything, I do use it to analyze stuff like patterns in Wikipedia's dumps. Conversely, you'll find metric tons of stuff (mainly games) written in noob friendly languages because these people just want an EXE out, and have motivation to impress or some other similar desire.

>>153
these people just want an EXE out, and have motivation to impress or some other similar desire.
Sergey Brin just wanted a search engine out, he used noob friendly Python. Where is Brin with Python now and where is you with your Lisp? Q.E.D.

Just kill all lispers. Problem solved.

>>154
noob friendly Python.
I was actually thinking more along the lines of the various game optimized BASICs.
Where is Brin with Python now and where is you with your Lisp? Q.E.D.
（　≖‿≖）
(ﾉಥ益ಥ）ﾉ 彡┻━┻

>>155
Killing lispers won't kill Lisp.

>>157
Of course not. It's already dead.

>>158
doesn't look any deader than usual to me

>>152
They are retarded because the solution has been there the whole time, they've been told about it, and they choose to remain willfully ignorant.
Yes, but why have they choose to remain wilfully ignorant, this is the question! Not because they are too stupid to understand lambdas and higher-order functions (as PG argued), VB proves this. Why then? "Retards' ways are inscrutable", is that what your argument boils down, to wilful rejection of any attempts at explaining the phenomenon?

Here's an idea: maybe the immediate reason is that on one hand there are useful programs written in VB with lambdas, which makes VB codemonkeys to recognize the superiority of using lambdas, on the other hand there are no useful programs written in Lisp, which makes everyone with a grain of common sense to ignore Lisp?

Which was that if Lisp really boosts productivity that much and is used by good programmers, then programs written in Lisp should dominate FOSS at least.
Non sequitur. You must be the most naive motherfucker on the entire planet.
Nope. I see RoR mounting the webdev world precisely because it boosts productivity that much, and there are countless examples of that. There were no corporate backing, no aspie-flattering propaganda compared to PG's, just DHH in his $1000 shirt with a clear and loud message: I'm rich and famous because I developed such and such websites in a fraction of time it would take you with your PHP or whatever. You can be like me.

Similarly, C took the world by storm purely by virtue of demonstrating UNIX, how useful it is and how easy it is to port it on any platform.

This approach works. You show the virtue of your language by demonstrating useful programs written in it, and you get the snowball rolling, with more and more people contributing useful libraries, programs, examples, books.

Naturally, this approach doesn't work for Lisp, because Lispers don't practice it. Instead of writing useful programs and showing them to the world they produce innumerable arguments about Lisp superiority on purely theoretical basis. That doesn't work, no shit, Sherlock!

I repeat: programming is a branch of fucking engineering, it's not maths, it's not philosophy, your "logical arguments" are not worth half a shit. Like in physics, the experiment is what proves the theory, and nothing else.

>>160
"Retards' ways are inscrutable", is that what your argument boils down, to wilful rejection of any attempts at explaining the phenomenon?
Nope, which makes your entire post really pointless.

>>160
Yes, but why have they choose to remain wilfully ignorant,
Because they feel like it? Lispers don't care that others don't care? Seeking meaning in things that are meaningless is the sign of one who has yet to attain 悟り.

VB proves this. [...] VB with lambdas, [...] VB codemonkeys
Doesn't per >>153 , consistent argumentation by tunnel vision.

recognize the superiority of using lambdas, on the other hand there are no useful programs written in Lisp
Great things are best given in small amounts, else they overwhelm the uninitiated. Of course, there are useful Lisp programs, they just won't fit your troll narrative.

I see RoR mounting the webdev world
Plateau'd

and there are countless examples of that.
Selective memory.

I'm rich and famous because I developed [...].
If this tool was making you enough money to get that second yacht why are you on world4ch spilling the secret. In economic theory, that would irrational.

Similarly, C [...] UNIX, how useful it is and how easy it is to port it on any platform.
They were pimping UNIX as a word processor and later on as an operating system, C is just a bundled thing that succeeded B which was after BCPL in the grand scheme of things.

[...] doesn't work for Lisp, [...] Instead of writing useful programs and showing them
The only people that pimp a language despite popularity are bloggers as a hobby and the ones that benefit the most from language's proliferation (companies, sponsors, language designers), this is why we get exposure to COBOL and Ada "industry articles" on a yearly basis even though the number of FOSS projects using those is a meager fraction of any of the individual Lisps in use. People wrote a lot of stuff in Lisp when Lisp was the only symbolic cruncher, people wrote stuff in it to get things done, academics pushed papers and entrepreneurs got bought out, nobody said anything, nobody cares.

I repeat: programming is a branch of fucking engineering
Repeating things won't make them true. And, just because you suck at logic as this thread chronicles doesn't mean anything.

>>160
C took the world by storm purely by virtue of demonstrating UNIX
C/C++ had AT&T backings. AT&T was like Google back then.

>>130
You don't understand. It's not about demonstration for the purpose of explanation, it's about demonstration for the purpose of proof.
The exact same argument applies, in fact I had this interpretation in mind. The fact is if you can't understand it you won't understand the proof either. In both senses this work has already been done independently by language authors, researchers, evangelists and so on. The first question on an experimental language designer's mind is "how can I prove this is TC" and it goes from there, for a remotely successful language all the code you'll need is already written.

If you want to assert the null hypothesis in whatever regard, you'll have plenty of working programs out already—I don't have to write a new one for you—to contend with. It's the same problem as before and you're just trying to justify ignorance.

The blub argument hinges on abstractions, so it's not just about learning languages. It's about being able to think and understand thought in certain abstractions. The point it's trying to make doesn't have anything to do with how good blub is. In fact, if you cut the head off (the hypothetically 'most abstract'), it just boils down to how irresponsible it is to downplay concepts you don't understand. On the other hand, since the argument is about degree of abstraction, understanding it really does put you in a position to judge how well abstracted other languages are.

What you hear instead is them saying "proofcode or get the fuck out", and rightfully so.
No, actually I don't and never have. What I hear is "Lisp is shit." When it comes to a language someone doesn't understand, they either want to learn enough of it to understand what's going on, or they hate it out of prejudice, fear or whatever.

If someone ever actually uttered "proofcode" to me I would probably stop talking to them, and at least they aren't worth proving anything to. Maybe in a few years when they mature their opinion will carry some weight, but only if they've learned to do their own research in the mean time.

>>160
OK, I've had some beer and I am feeling charitable towards you.
Yes, but why have they choose to remain wilfully ignorant, this is the question!
No one deliberately chooses to be ignorant. They are willfully ignorant because people have answered their questions: why is lisp better? Because for example A B C. But I don't use A or B and I can work around C just fine! Yes but working with these problems means you have all kinds of unmaintainable boilerplate bullshit because your language doesn't allow metaprogramming worth a damn. Etc.

Then time passes, and these people who have been ignoring A and B because it wasn't their problem and working around C because they could find some way are getting a little tired. The workaround is unmaintainable garbage, and A and B were actually more relevant than they realized. Then someone comes up with a fancy new language that has some special forms for handling C, which incidentally now allows workarounds for A and B, and it is the second coming.

So lisp always loses on two fronts to these retards. First it loses because the kind of problems they deal with are small enough to not matter. Then it loses because some new fashionable language close to their own sort of kind of kluges a solution. So it lost when they didn't care, and it loses when someone else handles it anyway.

Software is engineering---and despite your insistence to the contrary, I am an engineer by trade, not a programmer---and in engineering the best solution is almost never chosen. This is because the best solution to an engineering problem is the tiniest bit of a small fraction of a problem that a firm faces. Why did facebook get so popular when livejournal didn't? Who gives a shit? Livejournal is better than facebook, qualitatively, hands down. But fuck it, there's a gazillion non-technical reasons why things fail or succeed and language choice is really, really low on the list.

Then you bring up the old "but what has lisp done besides paul graham." There's so much shit on the internet about lisp success stories it isn't even worth reviewing them. But lisp's success in these venues is likely due to post hoc ergo propter hoc fallacies. The kind of people that are attracted to lisp might just be expert fucking hackers in general. They will succeed if they're banging out lisp or working on the Java spec.

Lisps are better languages, hands down. But your metric has almost nothing to do with language quality and if you can't see that, you're more retarded than the programmers I jokingly disparage.

So, Anon, have you solved >>149, because I want to see how it's done without macros?

It's a part of parser, used like that:

(defun /mul ()
  (try a (/term) :fail
    (try o (/op "*" "/" "%") a
      (try b (/mul) (/error "`~a`: missing right operand" o)
        (vector o a b)))))

(defun /add ()
  (try a (/mul) :fail
    (try o (/op "+" "-") a
      (try b (/add) (/error "`~a`: missing right operand" o)
        (vector o a b)))))

>>1
>>3

There's nothing wrong with C++ as a language. The fact is, it's the #1 programming language when it comes to coding PC games.

I can't speak for r/programming, but people on /prog/ are fucking retarded, and would rather jabber on about sub-par, shitballs languages while bashing the mainstream languages that are actually useful. (C++, C#, Java)

>>167
see >>166

Popularity and quality are extremely tenuously related. This applies also to programming language.

>>167
when it comes to coding PC games.
Back to /v/, please!

>>169
football is popular, but does watching some niggers throwing a ball gives you anything of quality?

>>169
argumentum ad populum

Adjective:
1. Very weak or slight: "the tenuous link between interest rates and investment".
2. Very slender or fine; insubstantial: "a tenuous cloud".

>>172
Lisp is shit nonetheless.

Its ironic to see languages on the level of C and C++(which are insanely complex below the surface:try writing anything more than a Hello World) mentioned as Blub, while things like PureBasic(which are dead-easy and filled with anything Blubbers need, the whole modern Basics niche are epitomes of Blub design) outBlub anything that exists on planet with exception of retard-level software like "Instant.exe" and DSLs for visual software generation(which are all much less useful and have less features for EXPERT BLUB SOFTWARE ENGINEERS).

>>175
I've written some PureBasic, its just too unoptimized vs C. Its useful for some quick apps(alot of builtin stuff, though most BASICs tend to include as much) but for optimization of algorithms and performance oriented software you can't beat the speed of C.

The QuickBasic programmers moved on to Visual Basic, the Pure/Blitz/Gfa/Real/Power Basics were largely ignored.

>>175
wait... are you saying that "complex" and "powerful" are the same thing? Or something?

I'd rather code in assembly than Basic.

>> 176
performance oriented software
Behold the [i][b]POOP[b]: Performance object oriented programming![/i]

>>179
You'll code in what jewish manager orders you, goy.

>>165
No one deliberately chooses to be ignorant. They are willfully ignorant because people have answered their questions: why is lisp better? Because for example A B C. But I don't use A or B and I can work around C just fine!
That's fucking insane. A study in cognitive dissonance. I tell you: your entire mode of reasoning is wrong, it's based on a false premise, that people decide that a language is good based on a laundry list of features. Your brain short-circuits: all your miserable life you argued about various laundry lists of features, that's the only thing you know, what's going on? Then you just suppress the entire traumatic experience and go back to talking about Blub retards who don't understand features A, B, and C.

Consider this: someone claims that a spherical car (codename: Cdr) is superior to normal cars. You ask: huh, why is it superior, show me! If Lisp has not yet spread to the rest of your brain from the programming-related areas, what you mean by that is: show me the prototype, how fast does it go, how much fuel does it use, how it is superior. If not then you are beyond logical discussion, goodbye!

If you are still reading: so then that person instead of demonstrating a prototype explains that sphere has the lowest surface-to-volume ratio of all shapes, and also the best structural integrity. Also, spherical cars can easily fit through round holes, and have very good aerodynamic characteristics! "What the hell," -- you reply, confused, -- "these characteristics are either useless or easily approximated!" "Ha-ha-ha, you are a typical Blub engineer," -- declares the Smug Cdr Weenie. Then she adds something about how regular car designs started using aerodynamic shapes only recently, and damn blubbers praise it as the best thing in the world, instead of going all the way and using Cdr already.

Or, as it happened here, you tell her that she is fucking insane, that a laundry list of features doesn't make a car design useful, that discussing features is pointless, and that the only criterion of usefulness is how actual, real cars built according to the design perform in the real world. She looks at you empty-eyed for a minute, then her brain self-resets and she starts again, "Damn Blub programmers, one tells them about features A, B, and C, but they just remain wilfully ignorant!"

But fuck it, there's a gazillion non-technical reasons why things fail or succeed and language choice is really, really low on the list.
I commend your doublethink. Next step: to claim that Enterprise Blub programmers are positively selected for incompetence, and that Lisp makes programmers literally hundred times more productive, in the same post with this assertion. The remark about the "unmaintainable boilerplate" is close, but you need to be more aggressive, to be more explicit about why you argue about Lisp, that it is really important that everyone understands that it's a clearly superior language, which is unpopular because the choice of language doesn't matter.

Lisp has
1.Horrible syntax with prefix notation
2.Much less libraries than C++
3.Horrible elitist community
4.Success stories repeated ad infinitum:Naughty Dog wrote a Lisp-like language==LISP++, Paul Graham wrote a shitty webapp==LISP IS SUPERIOR TO EVERYTHING.
C++ has
1.normal syntax with minimal quirks
2.Fuckton of libraries, compiler, tools, IDEs
3.Many people eager to solve problems for each other
4.The language proved itself by dominating the entire industry
Guess which one average programmer will choose?

>>183
lisp?

>>183
Ah, but lisp has GC.  CHECKMATE

C++ has 1.normal syntax with minimal quirks
laughingwhores.jpg

>>183
>C++ has compilers
You know usually the first task after learning a lisp-like is to make a compiler right? Usually following that you make your own DSLs, and if you're not making DSLs with set types for your variables you're doing Lisp horribly horribly wrong.

the first task after learning a C++-like is to make a video game right?
The first task is not something you decide.
This thread proves point 3.Horrible elitist community

>>182
Most of your post is the same fucking garbage you've been spewing the entire time, constructing some fanciful strawman of a lisper's arguments, which you've obviously never understood in the first place, and them knocking them down.
I commend your doublethink. Next step: to claim that Enterprise Blub programmers are positively selected for incompetence, and that Lisp makes programmers literally hundred times more productive, in the same post with this assertion.
Why would that be the next step, when I never took the first step you seem to think I have? You obviously have no idea what kind of tradeoffs happen, or why they happen, in any project whatsoever.
Or, as it happened here, you tell her that she is fucking insane, that a laundry list of features doesn't make a car design useful, that discussing features is pointless, and that the only criterion of usefulness is how actual, real cars built according to the design perform in the real world.
That is a totally ridiculous analogy because I really use a lisp in the real world for real world things and I am not the only one. All you have to fall back on is some popularity contest. You can argue that Kim Kardashian is better than Shakespeare because material science isn't popular but I'd suspect you wouldn't take that very far. Yet that is all you have to offer so far.

I tell you: your entire mode of reasoning is wrong, it's based on a false premise, that people decide that a language is good based on a laundry list of features.
When I contrast items in a class, I look at their differences. What do you do?

>>189
You can argue that Kim Kardashian is better than Shakespeare because material science isn't popular but I'd suspect you wouldn't take that very far.
Fuck me and changing analogies mid-typing. Ignore the material science bit.

Why would that be the next step, when I never took the first step you seem to think I have? You obviously have no idea what kind of tradeoffs happen, or why they happen, in any project whatsoever.
I have a pretty good idea, actually. And in fact that's kind of my entire point: that there's much more to the usefulness of a language than a laundry list of supported features. With a very important clarification: the popularity of the language amongst 99.99% of programmers is not anywhere near the top by importance.

A case in point: the inclusion of Mono in Ubanto, caused by the existence of a couple of useful applications written specifically for Mono. How do you think, who was swimming against the stronger current, the guys who decided to write a FOSS, Linux based application in _fucking C#_, or lispers? However you look at it, by the number of Linux users who know Lisp vs C#, by the amount of effort spent on SBCL vs Mono, by prejudices against each, you can't help but smell something rotten in the kingdom of Denmark.

That is a totally ridiculous analogy because I really use a lisp in the real world for real world things and I am not the only one.
A lot of people use COBOL in the real world as well, in their little niches with guaranteed job security. Yet we don't see a lot of useful applications written in COBOL in the FOSS world, nor in the desktop-oriented proprietary programs, because apparently the language sucks at helping to write programs that can withstand the competition.

All you have to fall back on is some popularity contest.
It's not the popularity contest between programming languages, it's the popularity contest between applications. That's where the entire Blub argument falls flat on its face, and that's the quite simple point that you are unable to grasp.

When I contrast items in a class, I look at their differences. What do you do?
When I contrast items in a class for the purpose of flaunting immediate properties of the chosen one on anonymous textboards, I look at their differences, true enough. When I want to choose an item that maximises some complex utility function, I compare values of that function across the items. And, since I'm not a fool to learn on my own mistakes, I look at what other people have managed to achieve using each item.

Hey, guys! This is fucking BBS, over 90000 characters posts make you look frumpy.

C++ is good because programmers are stupid. If we had more intelligent programmers we'd have more Lisp applications. This faggot is basically arguing obtaining a Bachelor's Degree is better than obtaining a PhD or heaven forbid, a DoE or otherwise, because Bachelor's are easier, more common, use by more people, are cheaper, etc, without regard to the consequences of this analysis. [spoiler]There are only consequences in Computer Science, have you read your SICP today?

>>193
Programmers are stupid because C++ is popular. If we had a better language we'd have more intelligent programmers.

Are SICP reading friends assholes by nature, or did SICP make them so?
rapotor.jpg

>>195
Assholes by nature.

>>192
Go back to twitter, please.
This is the autism board.

>>191
I look at what other people have managed to achieve using each item.
And there we have it.

The problems with Lisp are not philosophical. CL and Scheme are just too platform-agnostic. Clojure is the future.

At any rate, C++ is certainly the past. C++ is shit in just about every way, and there is basically no reason not to use C instead.

>>199
Iterative constructs aren't the end of the world but making a lisp that cannot even in principle eliminate tail calls at this late date is just stupid, I'm sorry.

>>199

Error: dumbshit detected!

- C was developed in 1973, almost a decade before C++ even showed up.

- The latest revision of C was 2000

- The latest revision of C++ standards was 2011

Derp.

>>201
The latest revision of Fortran was approved in 2010, what are you saying?

>>201
C++ was fucking garbage when it arrived, and it is still fucking garbage now. Deal with it.

>>202
Yes, but everyone knows that anything in existence that even remotely resembles the term "4chan" or any form of rhyme, soliloquy, implication or comparison is complete, indisputable, utter shit.

>>203

Then what would you consider a GOOD language? (inb4 LISP or some other 20-year outdated bullshit language suitable only for wiping your ass with)

>>203
Do you play PC games? If you do, get on your knees faggot and prepare to suck off the C++

>>205
People lived every day under Stalin. He was still a piece of shit asshole and this is objectively a fact. C++ is garbage and you can't handle the truth.

>>206

You haven't given me any valid reasons for your argument that C++ is garbage, nor have you offered an argument in favor of another language as a superior alternative to C++.

Fuck, lrn some shit sometime, would you? It won't hurt you.

>>207
http://yosefk.com/c++fqa/

Please use sage. Your contributions aren't great enough to warrant bumping.

what would you consider a GOOD language?
`
anything but the C++

You haven't given me any valid reasons for your argument that C++ is garbage
grammar
nor have you offered an argument in favor of another language as a superior alternative to C++.
parseable grammar

>>208
I don't use sage because I love to annoy the idiots on 4chan

>>209
Derp-to-English Translation: "This is why no one cares about /prog/"

>>210
Lolwut?

Parsing is fuckballs easy, even hard-coding that sort of shit is relatively simplistic, though a bit more involved. There are over 90000000 C++ libraries to accomplish this sort of shit super-easily.

The only argument I've seen against C++ in this shithole, all probably posts made by the same person(you), is that C++ doesn't have parseable grammar.

>>211
Parsing [C++] is fuckballs easy
I lol'd. There are probably people that believe this, though, that's the sad thing.

>>212

That's because it is, and if you cbf, which most people can't, get a fucking lib, like I said.

"Oh god C++ is so complex!" That's because it has all the features you will ever need, and then some.

As for that site that points out all of the flaws in C++, big fucking deal. Every programming language has its flaws, it's not like your shitty 20 year old irrelevant language is going to have less flaws in usability than C++ has.

People who aren't willing to take the time to learn/understand functionality of such a versatile, mainstream programming language will never be good programmers, plain and simple.

>>208

What kind of shitballs, nix-boon website is that shit? That's probably your shitty website, that's what it is

>>214
Cry more.

>>213
IHBT :(

>>213
>1:44
I bet you were shitposting on /g/ huh faggot

HURDURR LISP IS LIMITED AND HAS NO EXTENSIBILITY
LISP HAS SHIT SYNTAX
LISP = SHIT PERFORMANCE
LISP CODE IS UNMAINTAINABLE IN A GROUP THEREFORE NO ONE SHOULD LEARN IT

>>213
I hate the fact that I mostly agree with this.  I mean, C++ is a convoluted, cumbersome piece of shit, but it really is kind of the best convoluted, cumbersome piece of shit option you have, if you want to write anything useful.  I guess it depends on your definition of "useful," though.

>>218
I hate the fact that I mostly agree with this.
I hate the fact that you mostly agree with that.

>>200
tail calls in Clojure are merely explicit, not non-existent.

At any rate, the sequence abstraction makes it so that you can use all the built in list-processing functions on any kind of data structure, making it very rare to write your own lazy recursive algorithms. Most functions are just map/filter/reduce/partition/mapcat/etc in some combination, even with sets and hashmaps.

>>213
it's not like your shitty 20 year old irrelevant language is going to have less flaws in usability than C++ has.

Virtually everything has fewer flaws in usability than C++ has. (including C!) If you had ever used anything other than C++, you'd know that.

People who aren't willing to take the time to learn/understand functionality of such a versatile, mainstream programming language will never be good programmers, plain and simple.

Did you even read the FQA? People don't conclude C++ is shit out of fucking ignorance. (You're thinking of Lisp.) They conclude its shit from wasting thousands of man hours on it. Have you really never heard, "If you like C++, you don't know it." ?

C can do anything C++ can do and with less "pretend high level" bullshit.

A real high level language can do everything C++ can do WAY better than C++. (except manage memory and other low level shit. But that's what C is for.)

And finally C++'s design is such that you spend all your time thinking about C++ and dealing with C++ and no time solving your actual problem (or even identifying your actual problem.) No human can fit C++ into his head, and programs written in C++ tend to inherit this quality.

Fuck it's like I'm really parroting Linus Torvalds

>>220
tail calls in Clojure are merely explicit, not non-existent.
At least one of the following are true:
1) You don't know what I'm talking about
2) You don't know what you're talking about

>>220
Virtually everything has fewer flaws in usability than C++ has. (including C!)
If you had ever used C and C++ you wouldn't say such nonsense. The first thing I do nowadays when I have to fix some piece of legacy C crap, I make it compile with g++ and then methodically throw out all zero-terminated strings, linked lists and other braindead bullshit from every place that I have to touch. Because in my extensive experience it's a totally worthy investment of effort.

They conclude its shit from wasting thousands of man hours on it.
Yes, a lot of people in IT have mild autism, which makes them latch on an imperfect tool and try to isolate and paint over all of its flaws. C++ attracts such people like 20lb of rotting meat attract flies. Then they come back to their senses with profound mental hangover and write C++FQAs.

C can do anything C++ can do and with less "pretend high level" bullshit.
You are an idiot.

A real high level language can do everything C++ can do WAY better than C++. (except manage memory and other low level shit. But that's what C is for.)
You are an idiot.

No human can fit C++ into his head
Third time is a charm, you really are an idiot!

Fuck it's like I'm really parroting Linus Torvalds
Don't flatter yourself, somehow you managed to omit all and every of his usual points in your rant ^^

JVM can't do tail recursion
Clojure uses JVM
therefore Clojure can't do tail recursion

>>222

It seems like you can't decide whether you think C++ is shit, or C++ is great.

Well, WHICH IS IT FAGGOT?

>>224
True understanding of sepples comes from accepting both as the only truth.

>>223
JVM cannot optimize tail calls
Clojure uses JVM
therefore Clojure can't optimize tail calls

>>223,226
I'm not sure this is a valid argument...
C does not have GC
JVM is written in C
therefore JVM does not have GC

>>227
The general form is not valid, so don't use it at home! But the argument in this particular case is sound.

>>227
It's not stated very well. The details are equally fascinating and boring so I'll spare you. The upshot is you could convert it to iteration but that doesn't suffice to eliminate mutual recursive calls.

>>222
I have to fix some piece of legacy C crap, I make it compile with g++

>>218
I asked some people about their work.
From C++ programmers, everyone uses C++ because they want maximum speed, and either (a) don't like or (b) don't care about the language.

Everyone agress that C++ is overcomplicated and sometimes distract you from the problem you're trying to solve.

EDIT: two interviewees use Qt and somewhat like to program in C++.

EDIT(2): one of them spotted me writing some python scripts, and he moved on to PythonQt.

>>221
neither is the case. "automatic tail call optimization" is basically impossible, so you just be explicit about it with the 'recur' form and Clojure uses constant stack space.

http://clojure.org/special_forms#recur

Since Clojure uses the Java calling conventions, it cannot, and does not, make the same tail call optimization guarantees. Instead, it provides the recur special operator, which does constant-space recursive looping by rebinding and jumping to the nearest enclosing loop or function frame. While not as general as tail-call-optimization, it allows most of the same elegant constructs, and offers the advantage of checking that calls to recur can only happen in a tail position.

In practice it makes almost no difference because you tend not to write non-lazy (manually) recursive functions.

>>222
If C is bothering you, you're solving the wrong problem with it. And the problems that C isn't good at solving are generally better solved by things higher level than C++. The advantages that C++ has over C only seem impressive if those are the only two languages you've used. C++ is still woefully inadequate at abstraction, and the price it pays for the meager capabilities it does have are glacial compile times and ridiculous complexity. I'm not just overusing the word "ridiculous." C++'s complexity deserves ridicule.

Everything high performance is going "data-oriented" these days anyway, where as much as possible is done on the stack and lots of attention is being paid to how blocks of memory fit into cache and complex object models are being thrown out the window.

The desire for optimization and abstraction at the same time is essentially stupid. Optimization means specified and inflexible. Abstraction means preventing implementation details from affecting your design.

It's like, if I'm gonna have desert, I'm gonna eat a bunch of fucking ice cream. I'm not going to have have sweetened tofu. It's like you look at C and it's tofu, right? And you're like, "no, this isn't sweet enough!" The solution is to go to a different fucking restaurant.

>>232
desert
delicious cacti

"data-oriented"
true

>>232
In practice it makes almost no difference because you tend not to write non-lazy (manually) recursive functions.
Fuck you, bitch! I frequently use continuation-passing style, instead of frigid single path return.

>>232
In practice it makes almost no difference because you tend not to write non-lazy (manually) recursive functions.
But that's wrong, not all tail-recursion is tail-recursive:
(define (remove-duplicates xs) ; removes the consecutive duplicates in a list
  (cond ((or (null? xs) (null? (cdr xs))) xs)
        ((equal? (car xs) (cadr xs))
         (remove-duplicates (cdr xs))) ; tail recursion
        (else (cons (car xs) (remove-duplicates (cdr xs)))))) ; no tail recursion
And there are more reasons why loop/recur are just an ugly workaround for proper tail calls.

>>236
It's like you don't even know what ``tail position'' means.

>>235
much more often than not CPS can't benefit from tail calls...

at any rate, it's all silly because with lazy sequences, you so rarely write recursive functions. that's what I keep saying.

It's way more idiomatic Clojure to write


(def factorial #(reduce * (range 1 (inc %))))

than it is to write

[code]
(defn factorial [n]
    (loop [cnt n acc 1]
       (if (zero? cnt)
            acc
          (recur (dec cnt) (* acc cnt)))))
[code]

Seriously, the lack of laziness in a lisp is a bigger deal breaker form e than the lack of automatic tail call elimination. Not to mention immutable sets/vectors/associative arrays.

>>238
Clojure is useless for anything but factorials.

Also
(inc %)
wtf is this obfuscation?

>>239

I am not a clojurer, but I would guess that it stands for the the first argument, so you can express things without names, in the convenient way one would be able to in a stack based langauge.


/factorial {
  inc 1 exch range {mul} exch reduce
} def

>>240
What about nested lambdas? And what is `#`? Clojure is abomination!

>>240
stack based langauge.
enjoy your swap [uncons uncons pop] dip uncons uncons pop dip uncons swapd cons cons cons cons dupd swap ;

>>241

that's a good point. It is kind of typical in functional languages to have constructs that allow for quick writing of correct code, but if you were to go and try to extend the code a bit, it becomes impossible, and the entire routine ends up having to be replaced with something that is equivalent to a c/c++ for loop.

>>242

swap dup mul ery day

>>237
The (remove-duplicates (cdr xs)) call is a tail call, the (cons (car xs) (remove-duplicates (cdr xs))) is not. The first reuses the caller's stack frame, the second does not. (remove-duplicates '(a b b c c c d d d d)) will use only 4 stack frames in languages with proper tail calls, Clojure will use (length '(a b b c c c d d d d)).
That's what I meant with ``tail recursion isn't always tail recursive'': the recursive call doesn't have to be in tail position in all cases to benefit of proper tail calls.

>>238
Seriously, the lack of laziness in a lisp is a bigger deal breaker form e than the lack of automatic tail call elimination. Not to mention immutable sets/vectors/associative arrays.
And that's also wrong, or at least, it's wrong in Racket and some Scheme implementations, and probably in CL too.
SRFI-45 (lazy/eager/delay/force) isn't rocket science either, it's implementable in half an afternoon of macros, but you can't understand that without, you know, using a real Lisp.

And, laziness (which is not a silver bullet) and proper tail calls aren't mutually exclusive.

>>238
Someone hasn't read his SICP today

Chapter 4.2.3, truly lazy lists.

>>236
All I see is


(cudder (cudder (cudder (cudder (cudder 'autism)))))

That being said, please take your extraordinarily pointless waste of parentheses, and remove yourself from this thread, 'chap'.

>>244
But what you describe as tail call is in tail position wrt cond as described by your favorite RⁿRS.

>>241
You can't nest #()'s in Clojure, (Though I don't see why not)

But it's just a reader macro over fn, which is the same as lambda in other lisps, but is 3 fewer keystrokes.

But for little lambdas (like ones going in map/filter/reduce) I use it all the time. It's just fewer parens.

>>239
I'd say Clojure is useless for anything but processing data structures and dealing with state intelligently.

(not a joke. Sometimes you want to deal with state unintelligently, say, for performance reasons. Clojure is not your man, in these cases. It's also no Erlang -- no model for distributed computing (yet.))

But after working on some things in Clojure, I can't look at the way I dealt with data structures before (by mutating them) the same way. I see it as an optimization. (Clojrue calls them 'transient's.) Clojure lets you see the functional light without having to deal with category theory and  type systems. It's laid back functional programming, which is just groovy. But moreso than Groovy.

>>247

here ya go:


struct refc {
  int count;
  void (*destructor)(void*);
};

#define INC_REF(p) if(p) ((struct refc*)(p))->count++
#define DEC_REF(p) if((p) && (--(((struct refc*)(p))->count)) == 0); ((struct ref*)(p))->destructor(p)

struct list {
  struct refc refc;
  void* car;
  struct list* cdr;
};

void destroy_list(struct list* lis);

void* cons(void* car, struct list* cdr) {
  struct list* a = malloc(sizeof(struct list));
  assert(a);
  a->refc.count = 0;
  a->refc.destructor = (void(*)(void*))destroy_cons;
  a->car = car;
  INC_REF(car);
  a->cdr = cdr;
  INC_REF(cdr);
  return (void*)a;
}

void destroy_list(struct list* lis) {
  DEC_REF(lis->car);
  DEC_REF(lis->cdr);
}

void* remove_duplicates(void* xs, int(*eq)(void*,void*)) { // removes the consecutive duplicates in a list
  if (xs == NULL || xs->cdr == NULL) return xs;
  if(eq(xs->car, xs->cdr->car)) return remove_duplicates(xs->cdr); // tail recursion
  return cons(cs->car, remove-duplicates(xs->cdr)); // no tail recursion
}

>>250

I forgot to pass in eq into the recursive calls. shame on me.

>>250
#define INC_REF(p) ((p) && ((struct refc*)(p))->count++)
#define DEC_REF(p) ((p) && (--(((struct refc*)(p))->count)) == 0 && ((struct ref*)(p))->destructor(p))
This way they're expressions instead of statements.

>>252

that's cool and all, but the expressions don't really have sensible values to evaluate to. INC_REF(p) is true whenever p is not null. DEC_REF(p) is true whenever p is not null, and p's reference count went down to zero, and p was successfully destroyed by its destructor. I guess it could come in handy to know these values, so it doesn't hurt to have them.

Although I suppose the main advantage is that if the programmer types:


int t = c*INC_REF(p);

then the compiler wont say something completely strange after expanding it to:


int t = c*if(p) ((struct refc*)(p))->count++;

why u try to multiply c by an if statement?

>>250

and destroy_list should have called free at the end.

>>248
Tail positions are transitive, and cond itself is in tail position wrt the whole procedure.

>>249
But it's just a reader macro over fn,
Clojure has no reader macros (yet), just special syntax.
Also, fn is a bad name for such a fundamental special form, they could've called it x, f or obj as well. I would bitch less if it was called fun.
which is the same as lambda in other lisps, but is 3 fewer keystrokes. But for little lambdas (like ones going in map/filter/reduce) I use it all the time. It's just fewer parens.
I use λ or cut anyway for small procedures.

As for the rest of your post, although Clojure is not the first Lisp with purely functional data structures, I do envy its first-class STM support, and things like transients.

>>244
This idea that Clojure is not real Lisp because of the (seeming) extra syntax is just a kneejerk reaction. Clojure is a language defined in terms of its own data structures -- it just has 4 of them instead of 1. The thing that makes lists convenient for homoiconicity is their immutability. Invent immutable sets, vectors, and maps, and suddenly they're fine to have at the meta level as well. It does NOT make writing macros harder. #{1 2 3} is not syntactic sugar for (set 1 2 3). It's just a set. Both at compile time and run time. It does NOT become irrelevant after a few levels of macro, because they're always there, just like lists, symbols, and numbers. I think a lot of Lispers and Schemers don't realize this, or don't internalize it properly.

I gave up on Racket/Scheme when I tried playing around with hash tables and found that there were like 12 of them, all mutable. fuck that. There are some basic things I want served to me on a silver platter when I grab a high level language. Associative arrays with a literal form is one. call/cc? Less so.

I like that Clojure doesn't treat general purpose good ideas as domain specific ideas.

like Scheme does

>>256

I agree. When I see scheme code that other people have written, all I see is imperative stuff that relies on set! and pseudo object systems. It's like it tries to be this different, simple language, but people end up using it to mimic all the normal stuff they are used to in mainstream imperative languages, but the lack of direct support for these techniques make it more inefficient, and more awkward for reading.

Standard scheme only encourages by convention functional style writing but it never forces it like the pure languages. From my experience scheme code usually gets slightly shorter if you do avoid set!, usually by rewriting in tail call style.

>>256
I find call/cc quite useful actually, and 6 of those 12 hash table types are immutable, what's the issue with them? Btw there is 12 to accommodate the 3 equalities (hasheq is faster than hash when your data can be compared with the simple eq? instead of the all-powerful equal?) and weak/nonweak.

For what its worth on immutability, Racket actually dropped the R5RS standard set-car! and set-cdr!, mutating variables across modules isnt possible and DrRacket highlights mutating variables in red.

>>257
Because that's a common solution to some problems, so why wouldn't you use it? Scheme isn't magic, it's just a better programming language. If at the end of the day, state is the best way to model a problem, you use state. The only people that would cry would be the Haskell Nomad.

>>256
First, both CL and Scheme have more than one data structure, Scheme has strings, vectors, and conses, and most implementations have more, like Racket and hashes.

#(1 2 3) is not syntactic sugar for (vector 1 2 3). It's just a vector. Both at compile time and run time. It does NOT become irrelevant after a few levels of macros, because they're always there and they would be there even if they were some kind of crippled data structure.
#hash[eq[v]]((x . 1) (y . 2)) is an hash (in Racket). See why there are 12 of them in >>258. Immutable hashes are backed by Red-black trees (IIRC), to achieve sharing. I agree the syntax for them is a little (too much) heavyweight. It also has box literals, regexp/perl-compatible-regexp literals, and bytestring literals. What Racket is really missing is set literals, I wish it had them on {}.

CL has #An() literals for arrays. They really are arrays and blah blah blah. I can't talk much for CL since I don't use it.

Conses are mutable both in CL and Scheme, so that's not why they are used for homoiconicity, but because conses can make trees, and Lisp source code is, well, an abstract syntax tree.
Being defined in terms of a data structure doesn't mean forcing it on lambda-lists (i.e. on fn and let).
Do you want vector lambda-lists? It's ok:
(define-syntax-rule (fn #(x ...) bd ...)
  (lambda (x ...) bd ...))

((fn #(x y) (+ x y)) 2 3) ; => 5
(vector? #()) ; => #t
Why aren't vectors used in macros? Because there's no point to use them instead of lists.

So, you want hash literals so much to renounce to call/cc? That's too bad, because I have both. Now stop posting these uninformed idiocies on Scheme and Lisp in general.

Clojure has a better support for sequence abstraction than most Schemes (that I know), though. CL and Racket are ok in this regard, but Racket's feels kind of unnatural. Maybe it's just me.

>>257
set! and pseudo object systems are not idiomatic Scheme, except when writing those pseudo object systems (like SICP's).

>>260
>Why aren't vectors used in macros? Because there's no point to use them instead of lists.

actually I think in cases where the car is not interpreted significantly differently from the cdr, using a vector instead of a list makes a lot of conceptual sense and gives better visual cues as well. That's basically Clojure's idea...

>>261
using a vector instead of a list makes a lot of conceptual sense
For lambda-/argument lists, vectors? Scheme's basic lambda-lists make much more sense than using vectors with some special & keyword to mark rest arguments, because it kind-of pattern matches with the argument list.
((lambda (x y) ...) 1 2) => '(x y) '(1 2) => ((x 1) (y 2))
((lambda (x . y) ...) 1 2) => '(x . y) '(1 2) => ((x 1) (y (2))
((lambda x ...) 1 2) => 'x '(1 2) => ((x (1 2)))

and gives better visual cues as well.
Where's the difference between ))))))))) and )))])])))]))), except the second is harder to type?
Also, R6RS has [] aliased to (). I wish they were vectors, though.

>>262
harder to type
only if you use notepad

>>263
If you've got the editor to hold your hands, I see no point in having []s in first place.

>>264
derp