5 ms·
My god c++ is atrocious.
by shmageggy 10y ago
My god c++ is atrocious.
- Roboprog 10y agoLike "Wargames", the best way to win is not to play. Between moving from MS to POSIX environments in the 90s, and the "death" of Borland, this left me with few options other than another Faustian deal with Java-land, alas. I'm actually liking Javascript nowadays, though. Especially as more of an FP-capable language than an OOP-mandatory language.
- tdb7893 10y agoI'm loving the fact fact that languages seem to be moving towards some of the better parts of FP and away from some of the worse parts of OOP. I'm not particularly fond of fully FP languages but they have some really nice ideas that I've been enjoying using.
- jholman 10y agoI agree. And for myself at least, I could also say: I'm not particularly fond of fully OOP languages, but they have some nice ideas that I've been enjoying using. If a thing I want to make is a stateless process, modeling it as a function seems nicest. If that function can be truly a function (i.e. pure), that's best. If it can be semi-pure, in the sense that its only access to mutation is via its arguments (e.g. it takes in a DB handle explicitly), that's alright. If it has other access to global state, perhaps reconsider. If a thing I want to make is a container for state, and its state transitions have some structure to them, then I hear there's this thing called an ADT, and OO seems pretty nice. Neither of those statements is an architectural manifesto, and OO design and functional design both seem like bad ideas to me. That is, requiring modules to be instances of language-syntax-level functions or language-syntax-level objects seems like a bad idea to me. I guess if you go read the plain-English descriptions of Smalltalk objects, that matches my idea of how modules should work, except when they should be functions in a plain-English sense.
- lacampbell 10y agoFP and OO are completely orthogonal in my eyes. I can utilise immutable data with referential transparency just as well with Objects as I can with Modules + Structs, but only the latter is called "FP". I think because Java and C++ championed a very impure OO, based around C-like imperative semantics, people regard huge bundles of mutable state as canonical OO. To me that's not the big idea, the big idea is Objects vs Modules + Structs. But I think I'm on the fringe here.
- mikekchar 10y agoPopular is not always (or even often???) the best way to go ;-) Being on the fringe usually means you've thought about it more than most people. I'm an OO guy who has been moving more and more in the FP direction. I look at it a bit differently that you, but basically have the same conclusion (I think). Rather than saying OO and FP are orthogonal, I tend to feel that OO and FP are essentially the same, but that popular OOP misses the point completely. If I have a struct and a set of functions, where the first argument of the function is always the struct, how is that different than having an object with a set of methods? It might (or might not) be implemented under the hood differently, but whether I write the object on the left, or as the first parameter, it's all the same. With respect to mutability, most FP languages don't allow mutable data structures. I can likewise restrict myself to immutable data structures in OO languages. Most people don't. Unless you have a specific performance issue in mind, I think this is usually a mistake. I think the fact that mutable data structures are popular, is not equivalent to saying the OO encourages mutable data structures. It's equivalently bad in both camps (which I suppose is the meaning of "orthogonal" ;-) ). Immutability has memory management considerations which I will discuss in a minute. WRT polymorphism, with OO languages, ad-hoc polymorphism (operator overloading) is essential, while parametric polymorphism (generics) is optional. With FP, it tends to be exactly the opposite. But if you consider that both ad-hoc polymorphism and parametric polymorphism are useful tools in both approaches, I think it's kind of a moot point. The rest of it boils down to coupling and cohesion. In OO, you have encapsulation which forces you to reduce your coupling in certain ways. You tend to have cohesive code in that all functions dealing with a particular data structure are grouped with that data structure. In FP, you have cohesive code in that all your functions doing a particular operation are grouped together. Coupling is not strictly enforced, but writers of good FP code enforce it themselves. But it's not like you can't do both styles in both systems. It's just that the language implementations make one style easier than the other. The only place that I see which is very different is in garbage collection. If you are using immutable data structures, it is hard to know when to deallocate the memory. So you need some kind of garbage collection (even if it is just reference counting). Having it built in to the language makes it very convenient, but it is hardly a show stopper if you have to write your own (or use a library). With C++ there is an idiom (which I still think is a good one) where you try to only allocate memory on the stack. Everything is a local variable and you send those local variables to functions that fill in the data for you. That way you can explicitly understand the lifetime of every data structure in the system. I've done a lot of embedded code where I needed to keep track of every byte of code and to know exactly where it is allocated and deallocated. Techniques like this help, but it is obviously not immutable. I don't know how to do this kind of thing with traditional FP languages. But really, it's only the very last thing that strikes me as being particularly different. The rest is syntax and how much typing I need to do. It's more that the language designers have idioms that they prefer and make those idioms easier. FP and OO seem to share the same pool of idioms, though.
- Roboprog 10y agoThat said... if you are grinding out games on a $200 piece of console hardware (a "toaster emulator"), C/++ is your gig. Possibly with a thin patina of scripting over the top of it, I suppose.
- yoodenvranx 10y agoI miss Delphi, it was awesome for rapid GUI development :(
- Roboprog 10y agoYeah, I bought a copy, but never really used it. Too much work on unix systems for me by that time. TP for Win and (DOS) TP before that were pretty good, though.
- alyandon 10y agoYou can check out the cross-platform OSS equivalent if you are feeling particularly nostalgic! http://www.lazarus-ide.org/ http://www.lazarus-ide.org/
- pjmlp 10y agoSimilar path, I ended up in a mix of JVM and .NET lands, project wise. I still enjoy using C++ on personal projects, but at work only if there isn't any other way.
- gpderetta 10y agoplease, if you had 10 years of experience in the language, read every article on C++11/14/17, followed closely the evolution of the language, the answer would have been obvious... ... ok, even I can't say that with a straight face.
- aikah 10y agoC++ is hard. If one sticks to a strict subset it is a nice language. The problem is the code one didn't write. Even the STL is ugly to use. They are trying to fix the language by adding features but it's like Javascript, the old ugly ones are still part of the spec.
- Roboprog 10y agoThe worst part of the JS "enhancements" is trying to make it more like Java, rather than bringing it back to its Lispy + Smalltalky roots. I guess the assumption nowadays by The Management is that programmers are too stupid to learn anything new delimited by other than curly braces, or learn how to backtrace data flow between functions, rather than debugging by property-setter breakpoint.
- nommm-nommm 10y agoCan you give me an example of a "JS enhancement" you are talking about? Its not that I don't believe you I just am curious. I haven't changed the way I, personally, written Javascript since jQuery came out so I'm not up with the new stuff.
- rfrey 10y agoClass syntax - https://developer.mozilla.org/en/docs/Web/JavaScript/Reference/Classes https://developer.mozilla.org/en/docs/Web/JavaScript/Referen...
- Roboprog 10y agoYep. TypeScript !== JavaScript, but it's along a similar misdirection. Then there's "let". I guess it's not hurting anything, but how useful an addition is it, really? How many nested, non function, blocks you got in your code, buddy, that you need a new scope for your nested for-loops and else-ifs?!? Between things like forEach, map, filter, etc, I don't actually write very many manual loops anymore, and often use an IIFE for something that outgrows a ternary. Most of my "blocks" are functions.
- pklausler 10y agoBack in the 90's I was working on an operating system kernel that was written in C++. I had read up on the language and had done a lot of compiler work, so I was kind of a local tutor. I'll never forget my boss' reaction when he overheard me tell a coworker "look, if you want to expose your private parts here, you'll need to make a friend."
- nommm-nommm 10y agoThe old idiom I learn in college a long time ago was "only your friends can see your privates."
- weerd 10y agoSo was this comment. Please take the negativity to r/programming.
- jjnoakes 10y agoThere is no need to smear another site.
- mannykannot 10y agoI would not go so far to call it atrocious, but it has demonstrated how a collection of rules, each (for the most part) well thought out, can lead to a combinatorial explosion of complexity, together with some highly unintuitive corner cases. The strong desire for backwards compatibility all the way to C, together with some expedient principle-breaking, has made things more difficult. All of this has been thoroughly investigated and well-documented by Mr Meyers, and I would like to thank him for all his books and articles on the language.