A good third language?

Okay, my main two languages are Ruby and C++. Although I've learned Ada out of school and I'm learning Scheme in school now, I don't consider them languages I'm generally GOOD with. So I'm wondering what third language I could learn to balance myself out.

>>47
This is coming from my limited C++ at work....

Sometimes what happens is that two different programmers will use templates on two different compilers. The final result is that when the code gets merged, the shit just breaks.

Well, yes, C has the same problem. However, C++ seems to take this to the next level.

>>48

yeah, I did this to a coworker. Felt bad man. It takes knowledge and discipline to write complex templates that will work for multiple C++ compilers.

or incorporating a super nifty syntax checker into the build process. I haven't looked for one yet.

>>49
That's the kind of shit that makes me want to break out the nerf gun (at work).

>>44,47
No libraries for you, reinvent the wheel

read http://yosefk.com/c++fqa/inheritance-mother.html and http://yosefk.com/c++fqa/operator.html

Namespaces in C++ wanted to help with modularization, but:
[q didn't fix circular dependencies;

implementation defined naming;
#ifdef __cplusplus]

>>24

Yes, it is.

I have extensive Windows API experience and some Xlib experience too. But more than that I'm a system programmer, and I can say, from my knowledge, that writing drivers, real time tasks and kernel code in general is much tougher than writing GUIs, whether Xlib or WinAPI (or whatever you might be relating to) is "broken".

Listen.

Many people call libraries and languages "buggy" and "broken", but in fact these same people are the ones who write sloppy programs, do not know how to properly use the toolchain, do not know how the language they're using operates on the lower levels, do not follow the relevant documentation, do not know what they're doing, thus do not know what they're talking about in the most preliminary level. This, unfortunately applies to a very wide range of clueless people.

These people were inserted into the computing world by the democratization of technology, internet and so on. But instead of paying the hard work necessary to master the bare minimum techniques required to perform a decent programming task, these lazy bums learn shitty hipster languages, write a couple of ridiculous toy programs and scripts and think they're experienced enough to hold criticism against battle-scarred veteran languages, libraries and technologies in general. And they do this because this same democracy demands that these people hold an opinion (regardless how stupid these might be) and share it out aloud.

A strong sign of this behavior is relying on citations of well-known figures or authorities which endorse their own opinions, thus attempting to legitimize the latter by mirroring on the renown of the former. Most people actually don't have a single clue what real world programming is all about, but they were well fed with FUD and incredibly smelly misknowledge about computing in general.

Now, I'm not claiming you are one of these people, and I even hope you're not. But they're surely around here, in throngs. Look at the enormous volume of criticism against C++. Look at the enormous volume of criticism against Lisp. Look at the enormous volume of criticism against Java.

If you find a bug in Xlib, well, file a bug report. Participate in the relevant mail-lists. Give suggestions. Turn in some piece of code. Many people has employed hard work in it, and many people expended great effort in a number of other respected projects, in the hope it will be useful. Just don't blabber shit around gratuitously -- it puts you straight down in the same level the people I've described above, when sometimes you deserve a higher profile.

This is just my sincere and polite recommendation.

>>25

Qt is a very good C++ library. It is more than just decent on almost every aspect I can think of for the needs of the average application programmer. In my opinion, Qt is a must for every C++ application programmer.

I have just superficial knowledge of Gtk and GLib, and from that faint inspection I state they're excellent works of heavy language abuse, but some sort of abuse that fits rather well in its context. Like a polite and delicate way of raping someone.

>>39

This is not needed if you're using template repositories or other template models available. In the worst case, you can force explicit instantiation, as you would do if you were just using generic C macros.

Most people don't even try to solve the problem before critizing something, ain't it so.

C++ bloat mostly comes from improper inlining and from exceptions -- specially if the code is making heavy use of exception specifications. Exceptions in C++ really offers a number of problems. Without exceptions, the final C++ data model is very similar to the C data model, the only remaining difference being in virtual inheritance (if ever used).

In other words, if you don't use exceptions, and use inlining just properly, your average C++ code is about the same size of your C code.

>>48

Whenever people cite "two different compilers", they're really trying to say "GCC and MSVC". (They don't state that explicitly because the implicit FUD will strengthen their argument.)

GCC employs the Itanium C++ ABI, while MSVC does not. This is why they're not binary-compatible and this is why it is extremely stupid to attempt to link code produced by them together, because it is clearly stated that it will not work. And this is why parroting such a fact is simply fueling the already deep well of misknowledge and stupidity regarding C++.

>>53

There are other c++ compilers you idiot. Take a step outside of your world and see whats out there.

Your response to templates is incorrect you twat. Templates will fundamentally increase the size of the binary, because the templated functions and classes will need to be duplicated in the binary for each use with distinct data types. Your recommendation helps keep down the sizes of object files, which is nice, but not what I was talking about, which was the final binary.

Where did anyone mention trying to link code compiled via different compilers?

Every language has a place where it falls short you dumbass. This is a consequence of trying to address a specific area. One can't hope to make a language that fits every application perfectly. This is why there is more than one language in existence. The fact that you don't understand this shows that you've never programmed anything outside of your domain.

Your post is written in language that screams your over inflated ego. I wouldn't care about it so much if I didn't have to sift through it to find out what you were trying to say. Please be more concise in the future.

>>53
Here is the kind of stuff that really sucks my ass when trying to write something useful on *nix. Let's say I have a GUI that sits idle a lot times. I have this program check the mouse and the keyboard for any kind of activity. The problem is that checking for the "mouse click" varies from system to system!

That comes from the inherit idiotic and bug ridden design of X. For whatever reasons, they don't, and still refuse to provide any kind of support for the "mouse click" feature. As a result of this nonsense, some *nix variants have rolled out their own half baked/unportable solution.

There are also some issues with monitor resolution. The concept of a "full screen" doesn't really mean a "full screen"! That's right. Just because the GUI run full screen on a *nix box doesn't really mean it will run full screen on a different PC running the exact same *nix variant. I don't know about you, but that smells like a but to me.

>>55
*smells like a bug to me*

>>56
undefined behaviour

>>53
Some parts of your response sounds pompous, and some parts of your response seems genuine. Based on the post size I suspect YHBT.

I'm confused though how you paint the hipster language users as a ``bunch of lazy bums'' that entered in as a result of ``democratization'' and then defend Lisp against various unwarranted criticisms. What do you consider a hipsterlang?

>>58 Any made since early 1990s I guess.

>>53
I don't like your attitude.
It's true that newcomers always argue about fucking nothing because of their own ignorance. But this isn't an excuse to let older “proven” knowledge untouched.

Erlang, Perl, Oberon, Prolog, Scheme, ML are safe.
Haskell, Python, Oz, Lua are borderline
Java, PHP, Ruby, JavaScript is hipsterlang
D, C# and Scala are hopelessly hipster.
Go and Dart: too hip for this list.

>>54

(Oh, Lord. Need patience to deal with the fucktards around here.)

Listen, kid. If you read what I've said once again, you'll see that I did not claim that there weren't other compilers around, but precisely the opposite: there are a number of them, but often when one claims about binary incompatibility, these claims point to the two most used C++ compilers, when in fact these two compilers are intentionally incompatible, since they use different ABIs. This guy >>48 seemed to have some problem linking code produced by different C++ compilers, just in case you didn't notice.

And you don't know very much about ABIs and how linkers work, do you?

Your single problem is to feature some reading disability. Please take more time in your attempts to properly understand what your peers have written, or just refrain from posting. You create communication noise.

Also, sorry about sounding like a fucking pedantic. Reading again I rather agree with you on that part. I didn't mean to offend with that.

>>55

I've never faced such a situation, so I'm unaware of how difficult it really is. But I suppose you're correct.

I've heard that XInput is being redesigned into XInput2, with major changes. Maybe the new version can address these issues.

Anyway, the bottom line is: be bold. Peer review is essential in real world programming. Write to the developers. Show them some code, there's nothing better than a piece of code to illustrate how ludicrous some programming interfaces can be. Sometimes, the library developers themselves are unaware of how their interfaces are bad, because they don't take proper time in using these interfaces.

>>58

I agree with you. Sorry, I did not intend to sound pompous. No trolling either.

Lisp can be just naively considered a hipster language simply because hipsters (umbrella term for loud, unknowledgeable and unproductive people in general) seem to enjoy it for its "cult" status. However, that's just as far as Lisp can go into this pejorative "hipster" term. Lisp is an excellent language, with a long history of success in the academia, mostly because of the great ideas which it has helped to develop. My particular view on the subject is that Lisp is all about creativity.

Accordingly, this is why people linked to research (specially AI) have a thing for Lisp. These people are creative and need a tool which can reflect and boost their insight, making them trace new lines of thought. I believe that more "rigid" languages, like C, are not adequate for that purpose.

My opinion is: just don't buy too much of the hype, for any language, neither for good nor for bad. People interested on solving problems do not waste time bashing themselves with spurious language criticisms: these are for people interested in showing themselves in a stage, instead of actually getting things done. As I've stated, most don't even have objective reasons to sustain their propositions. Instead, they only have a handful of highly "sensorial" arguments from their own personal (mis)experiences.

Lisp has its applications. C has its applications. C++ has its applications. Even FORTRAN has its applications.

Now, for me, hipster languages are languages designed by people with rather good intentions, but not enough maturity. Languages designed by apparent raw caprice and a high dosage of NIH. Languages which try to "fix" things but they happen to commit a number of crimes, sometimes the very problems they try to tackle from the other languages. They have no mission in mind. No specific problem to solve: just another dead addition to the already fat technological bulk. Python and Ruby are two of them, but there are many, many others. Fortunately most still dwell into unknowingness. The objective statement here is that they contribute nothing to the computer science in general: they're easily replaceable by something which already existed before them, without any loss.

Note that these symptoms applies not only to programming languages, but to many other objects of computer technology (internet protocols, hardware designs, so on). I'm absolutely sure you could cite a number of ridiculously unnecessary and misdesigned things on the modern web technology, for example.

>>62
YHBT

>>62

I suppose it is ambiguous, but if the problem has ever happened to you, you would know that >>48-san was talking about different compilers accepting various syntax for templates. Some require typename in certain places where others wouldn't. The incompatibility has to do with syntax, not object file formats. I don't know why anyone would consider it safe to compile sources to object files with different compilers and then attempt to link them.

Japanese! ^_^

>>60

I agree with you. My attitude was not towards turning well-stabilished knowledge invulnerable, but to plainly denounce the extremely loud argumentation made by some I particularly deem completely clueless.

I speak of that because I've been through it, too. That is: to believe that I knew about something, when experience showed that I truly did not. So, it bothers me a little when I read this special sort of argument, since it follows some pattern.

I actually dread the idea of having "untouched" theories. However I feel that a lot expertise is required before one can attempt to illegitimize well-stabilished knowledge and culture in general. And by expertise I mean truly objective, affordable arguments, reasons and methods. Nonetheless, because these are extremely expensive, people seem to just take naked opinions, sensations and experiences as enough to start a flame.

>>64
For me it is clear that he was pointing to linking object files, but never mind. On that matter, Microsoft has a long history of not following standards. MSVC still has a spotlight on when talking about syntactical incompatibilities, but these differences should not exist. In contrast, ABIs, are not standardized, so differences ought to exist. In either case, it's not the language's fault, or at least not in the largest part.

Object files produced by different compilers can be linked together if they employ the same data model and calling conventions. It's not something widely done but not something extremely unconventional to do, specially if your library is only available in compiled form.

And dynamic libraries themselves can be seen as the process of linking objects made on different build environments. The relevant parts of the process (calling conventions, register usage and preservation, data model) is just the same.

MIPS

>>62
This joint is dominated by autists, toilet scrubbers, and master googlers.

>>66
I'll be more neutral now.

About previous stablished knowledge: it's necessary, because human knowledge won't move if we reinvent the wheel everytime. But we need to be sure if these “previous well-stablished” knowledge is still valid. Maybe it's just that they were completely okay when they were stated.

Look at C, it is from a time where sitting down reading pages of processor instructions were quite common between programmers. So, at least for them, reading C code it's a piece of cake, because it's almost a bunch of macros to output assembly code. Portability? Libraries? The architectures were growing so fast that people hadn't time even to write compilers before the successors come. C of course were a bless on such systems.

Over the 1990s, the computing world changed a lot, main memory grew up to the point that virtual memory is almost useless for most people now [almost!]. Computing power grew up so fast... a smartphone today is more powerful than the 80s top supercomputer (Cray Y-MP I guess). These practical restrictions that made C and C++ popular doesn't make much sense today. And for newcomers, which didn't live back then, talking about it doesn't make sense when they can't even use 100% of their processor just because more than 80% of their code it's just business logic, structured data or fancy UIs.

Look, my computer is a cheap one bough over the internet: AMD Phenom II X3, 4GB DDR3 RAM and a ECS motherboard, and the only thing that can make my processor reach 100% usage is my research (infinite loops also lol). Even if I use KDE with disabled direct rendering I won't use totally of it. The only thing really slow is I/O: disk and network SUCKS.

>>54
Don't forget about ARM compilers.  Half the world of computing is ARM.

PASCAL

>>70
C/C++ is still relevant.  Look at research in motion.  Their 8000 series of smartphones had UI's written in java.  It was unresponsive, laggy and miserable.  The 9000 series of smartphone had UI's rewritten in native code (c/c++) and was way faster and much more responsive.  Android has the same problem nowadays.  My opinion: Java doesn't belong on smartphones.

>>70

C is an old language, indeed. It does not reflect anymore the architectures on which it runs: from parallelism to NUMA, C still lies almost completely in a classical Von Neumann environment.

C is still widely used because so far there has been no better alternative. Or maybe there was, but it didn't acquire proper visibility. C has a lot of momentum. People would rather add extensions and tweaks to the C language instead of developing newer programming languages or environments.

C++, on the other hand, has never had much reason to come into place: my rough opinion is that it has become popular because it promised a lot and a number of big companies had invested millions in the language, and the investment simply would not have any payoff if C++ weren't pushed down people's throat. It does not mean that C++ doesn't offer anything new, or is a bad language by itself, however.

There are some fundamentals that have never changed since the 80s. Most important changes that came in the last years only make sense for kernel developers, for privileged code. In the userland, things have not changed too much: memory layout, register usages, data alignment, symbol resolutions, relocations, calling conventions... these have been present since the very dawn of the third generation languages, and maybe even before. And I believe that having a notion about these things still is relevant knowledge, even if one is limited to writing GUI code or otherwise less "complex" tasks. It's about knowing the tool with which you are working.

>>74

Even assembly language is still relevant on some niche markets, and not only "inline" assembly for small optimizations or preparation before a higher language comes into place. For example, I've been developing multicast receivers for protocols which require extremely low response latencies, using straight assembly language for protocol parsing. It's an environment in which some players even invest directly on hardware technology (FPGAs and the like). Portability is not an issue, and user interface code is obviously still done in higher level languages, but the core code is mostly handcrafted machine language code.

Italian.

>>76
Fuck off, ``il pizza"