|
Mustach posted:That and "embedded programming" is just every coder's attempt at "manly" and irrefutable evidence for hating things. "GARBAGE COLLECTION? IF YOU WERE ON A 15-BITS OF RAM TINKERBELL NIGHT-LIGHT LIKE ME YOU'D KNOW THAT'S ALL BULLSHIT" I've heard this complaint a bunch of times but never seen it. Are you sure you aren't projecting here?
|
# ? Sep 13, 2012 14:28 |
|
|
# ? Jun 4, 2024 02:53 |
|
Yes, aside from the hyperbole, I've seen it. This blessed oasis that is CoC is mercifully free of that kind of thing. (at least since teapot got permabanned)
|
# ? Sep 13, 2012 15:13 |
|
teapot and Unabomber were the two best posters in CoC (well SHSC I guess since CoC wasn't a thing for most of their tenure). Honorable mention to AvengingDentist of course
|
# ? Sep 13, 2012 15:52 |
|
shrughes posted:(The hand-rolled code can be less susceptible to bugs if it's just a better written implementation, which you're not likely to see for Boost libs but you are likely to see for, well, a lot of libraries out there.) It's not just the susceptibility to the bugs, too - there's also the matter of support. Being dependent on a third party with unresponsive support to identify and fix issues can really suck.
|
# ? Sep 13, 2012 15:55 |
|
Zhentar posted:Being dependent on a third party with unresponsive support to identify and fix issues can really suck.
|
# ? Sep 13, 2012 16:12 |
|
That Turkey Story posted:I find this to be the case with most languages. It seems like for every language that introduces something useful, they get rid of something else that is useful because it's "complicated" (who cares if it's useful and correct -- it's scary!). I'm curious what your list of retained features would be to make a successful successor to C++. My biggest issue is that the first thought when replacing C++ always seems to be "So this language is going to be like C++, except with garbage collection! Then we can get rid of those nasty, confusing destructors."
|
# ? Sep 13, 2012 19:15 |
|
Contero posted:I'm curious what your list of retained features would be to make a successful successor to C++. Garbage collection isn't nice because destructors are hard, garbage collection is nice because keeping track of object lifetimes is cognitive overhead and if you can get rid of it then why the hell not?
|
# ? Sep 13, 2012 19:42 |
|
They really need to have designed templates for metaprogramming instead of discovering accidentally years down the line that the system you put in for creating generic containers happens to be turing-complete.
|
# ? Sep 13, 2012 19:58 |
|
tractor fanatic posted:They really need to have designed templates for metaprogramming instead of discovering accidentally years down the line that the system you put in for creating generic containers happens to be turing-complete. And so D has compile-time code
|
# ? Sep 13, 2012 20:09 |
|
GrumpyDoctor posted:Garbage collection isn't nice because destructors are hard, garbage collection is nice because keeping track of object lifetimes is cognitive overhead and if you can get rid of it then why the hell not? I think the more substantive point here is that any successor to C++ would have to have GC that is optional at most. In 2012 any system that can meet its performance requirements with a GC is already implemented in a language with a GC, so there is no point to making a C++ replacement that forces one on you. An optional GC would make a putative C++ successor attractive by making it easier to develop systems that don't have as stringent specific performance requirements (and I should state pre-emptively that 'speed' as in average framerate or whatever isn't the requirement that kills a GC for most things that can't stand a GC) without sacrificing suitability in the niche where C++ excels. It should also be noted that the combination of pervasive value semantics and numerous deterministic semi-automatic memory management schemes can make memory management in C++ a non-issue (or at least rather tractable) in most cases, and that designing around the pathological cases of a GC that may well change in the next version of your language's VM is often a non-trivial consideration when you measure performance in something other than hundreds of requests per second.
|
# ? Sep 13, 2012 20:24 |
|
I generally agree with you, but I'd like to make the point thatOtto Skorzeny posted:the combination of pervasive value semantics and numerous deterministic semi-automatic memory management schemes
|
# ? Sep 13, 2012 20:57 |
|
Contero posted:I'm curious what your list of retained features would be to make a successful successor to C++. Contero posted:My biggest issue is that the first thought when replacing C++ always seems to be "So this language is going to be like C++, except with garbage collection! Then we can get rid of those nasty, confusing destructors." GrumpyDoctor posted:Garbage collection isn't nice because destructors are hard, garbage collection is nice because keeping track of object lifetimes is cognitive overhead and if you can get rid of it then why the hell not? Realistically, garbage collection is fine in cases where 1) non-deterministic memory management is acceptable, 2) you actually want shared ownership of a given object (garbage collection is pointless for clearly scoped objects), and 3) where disposal of the type is trivial and predictably will be trivial in the future (i.e. in C++ terms, any C++ type with a trivial destructor or that only directly or indirectly dynamically allocates types that have trivial destructors). In terms of #1, most people are okay with it, and that's fine. I'm including this for completeness and because it isn't always acceptable. If you really are trying to make a general-purpose language, this is definitely important to understand. Optional garbage collection is one thing, but if you force it for all dynamically allocated objects then you're ruling out a whole class of users for no reason. In terms of #2, you should already be striving for minimizing or eliminating shared ownership to begin with -- you use value semantics in C++. Take a look at all of the C++ standard libraries and all of the boost libraries, for example. Specifically, which of their components would be significantly, if at all, impacted by the presence of garbage collection and how would it make their implementation better, easier to understand, or even easier to write for that matter? Since they use value semantics, pretty much none of them (you could probably stretch and say something like shared_ptr could be metaprogrammed to have a different implementation in cases where types have trivial destructors). Further, as for #3, even if you're not dealing with value semantics, if your types are nontrivially dispoable or if your code (especially generic code) is to contain anything that is potentially not trivially disposable, then you want or need deterministic disposal anyway, which garbage collection itself cannot provide. Because of this, you need some other way to keep track of when disposal can take place that is actually deterministic and timely -- if you have to keep track of when to dispose anyway, then the benefits of garbage collection in that scenario go out the window (if you know when to dispose of the object, you know when its memory is ready to be reclaimed). Garbage collection is fine for dynamic memory allocation of trivial types, but it falls flat on its face with respect to deterministic resource management. In something like C++ with garbage collection, there's nothing detrimental about the facility being there and it's very welcome, but good practice will still always be to use value semantics unless you have a solid reason not to, use unique_ptr in places where you have simple lifetimes of dynamic objects, and use shared_ptr in places where you have dynamic objects with shared lifetimes (though again, that's something you should strive to avoid if possible anyway). That Turkey Story fucked around with this message at 21:28 on Sep 13, 2012 |
# ? Sep 13, 2012 21:15 |
|
I've been tasked with fixing up our company's website, and this is a small snippet of one CSS file (out of four total):CSS code:
|
# ? Sep 13, 2012 21:16 |
|
Optimus Prime Ribs posted:I've been tasked with fixing up our company's website, and this is a small snippet of one CSS file (out of four total): Thanks the colourizing, it looks like something has vomited blood all over the thread. Can't say that's inappropriate, either.
|
# ? Sep 13, 2012 21:29 |
|
FWIW my experience has been that I end up spending about the same amount of time thinking about resource management in C# and C++, and both are way simpler than Objective-C with automatic reference counting. The learning curve for C++ memory management is definitely steeper than for garbage collected languages, though that's a problem with the language in general.
|
# ? Sep 13, 2012 22:51 |
|
That Turkey Story posted:Any list I try to quickly make here is bound to be incomplete, but of the things that many other modern, mainstream, statically-typed languages don't have, such a language would need something analogous to templates that allows for generic programming with the efficiency and genericity that templates provide. Note that "generics" are not it. Have you seen Clay. It's in early stages but it seems to be going in a nice direction.
|
# ? Sep 13, 2012 23:26 |
|
Zombywuf posted:Have you seen Clay. It's in early stages but it seems to be going in a nice direction. No, but from the listed features and design philosophy I'm already interested. Edit: Skimming the language reference, I like how they handle a lot of things, often better than C++: overloading, discriminated unions (though I'm not entirely sure they should be a language feature as opposed to a library feature), and function return type deduction. Edit2: In IRC someone is claiming that development on the language isn't really active anymore, even though it looks like it was updated relatively recently. :/ Edit3: I really like this language a lot. That Turkey Story fucked around with this message at 01:55 on Sep 14, 2012 |
# ? Sep 13, 2012 23:35 |
|
That Turkey Story posted:Realistically, garbage collection is fine in cases where 1) non-deterministic memory management is acceptable, 2) you actually want shared ownership of a given object (garbage collection is pointless for clearly scoped objects), and 3) where disposal of the type is trivial and predictably will be trivial in the future (i.e. in C++ terms, any C++ type with a trivial destructor or that only directly or indirectly dynamically allocates types that have trivial destructors). 4) You want memory safety and don't want every piece of broken code to be a security flaw.
|
# ? Sep 13, 2012 23:43 |
|
shrughes posted:4) You want memory safety and don't want every piece of broken code to be a security flaw. If by that you mean you don't want somebody to be able to accidentally write to something that's been deleted and/or destroyed, I agree, but unless you're disallowing holding references to non-dynamically-allocated objects, or you are always implicitly dynamically allocating and garbage collecting all objects, you're still going to have that potential problem anyway. That's a gigantic trade-off. You could sort of have it both ways, though -- keep track of traceable memory references ala GC, and if other pieces of code are still holding onto them at the time delete is called or the object is destroyed, produce some kind of error (probably something like terminate without stack unwinding, allowing some kind of hook). The thing is, even if you avoid trampling over memory, your program is still in some erroneous, unaccounted for state by the programmer. Something still should be done other than silently continuing.
|
# ? Sep 14, 2012 01:03 |
|
That Turkey Story posted:discriminated unions (though I'm not entirely sure they should be a language feature as opposed to a library feature) It looks like it's how they do their OO: the FAQ posted:Unlike mainstream object-oriented languages such as Java, C++ and Python, Clay does not provide class definitions or inheritance. However Clay provides excellent support for polymorphism using an overloaded function dispatch system and variants (which are basically tagged unions). Rather than calling a method of an object as you would in a traditional OO language, in Clay you call a function and pass in arguments that determine which specific overload of the function will be called. The overload may be determined either at compile time or at run-time.
|
# ? Sep 14, 2012 02:05 |
|
Plorkyeran posted:FWIW my experience has been that I end up spending about the same amount of time thinking about resource management in C# and C++, and both are way simpler than Objective-C with automatic reference counting. The learning curve for C++ memory management is definitely steeper than for garbage collected languages, though that's a problem with the language in general. Are you saying that ARC is complex to think about? If you aren't working with CF classes, the only gotcha I can think of is making sure you don't have retain-cycles, which would be an issue in any language. And those are easily solved by using weak references where appropiate.
|
# ? Sep 14, 2012 02:13 |
|
GrumpyDoctor posted:It looks like it's how they do their OO: A lot of the ideas look like they're directly influenced by Stepanov's Elements of Programming. The only thing is, it doesn't look as though it's yet at the stage where it has full concept and concept map support, or if they're necessarily planned in the sense that they are for C++. That Turkey Story fucked around with this message at 02:44 on Sep 14, 2012 |
# ? Sep 14, 2012 02:17 |
|
Carthag posted:Are you saying that ARC is complex to think about? If you aren't working with CF classes, the only gotcha I can think of is making sure you don't have retain-cycles, which would be an issue in any language. And those are easily solved by using weak references where appropiate.
|
# ? Sep 14, 2012 04:03 |
|
Optimus Prime Ribs posted:I've been tasked with fixing up our company's website, and this is a small snippet of one CSS file (out of four total): CSS code:
They did just list every instance of their a tags using unnecessarily specific selectors, right?
|
# ? Sep 14, 2012 12:02 |
|
code:
...gently caress... At least I'm getting paid well for this.
|
# ? Sep 14, 2012 13:03 |
|
Wheany posted:
You fool! Now the one DIV where they didn't want those colors is all wrong!! Put them back! My guess is that whoever wrote than has no clue what a .class is.
|
# ? Sep 14, 2012 13:47 |
|
Lumpy posted:You fool! Now the one DIV where they didn't want those colors is all wrong!! Put them back! I wanted to believe it was generated from a WYSIWYG, but the comments indicate otherwise.
|
# ? Sep 14, 2012 13:55 |
|
Clay looks like it shares some DNA with Haskell, so I'm all for it
|
# ? Sep 14, 2012 14:23 |
|
Wheany posted:They did just list every instance of their a tags using unnecessarily specific selectors, right? Nope. There are plenty of anchor elements in the HTML that are not being referenced by that verbose CSS. For example there's this (modified to prevent table breakage): HTML code:
Lumpy posted:My guess is that whoever wrote than has no clue what a .class is. Pretty much exactly what I thought when I first saw it.
|
# ? Sep 14, 2012 14:50 |
|
Probably been posted before, but..."Tough times on the road to Starcraft posted:
Who in their right mind would make something as integral as a unit in a RTS game inherit from three seemingly totally unrelated classes?
|
# ? Sep 14, 2012 15:06 |
|
Guys with absolutely no experience at all using a new language.
|
# ? Sep 14, 2012 15:12 |
|
Optimus Prime Ribs posted:Nope. There are plenty of anchor elements in the HTML that are not being referenced by that verbose CSS. Oh, that is adorable
|
# ? Sep 14, 2012 15:20 |
|
Wheany posted:Oh, that is adorable It only gets better! Check out the code for those functions: JavaScript code:
|
# ? Sep 14, 2012 15:31 |
|
Just saw this in a codebase I'm working on. It made me chuckle.C# code:
|
# ? Sep 14, 2012 15:36 |
|
Optimus Prime Ribs posted:
|
# ? Sep 14, 2012 15:46 |
|
Optimus Prime Ribs posted:It only gets better! Check out the code for those functions: Well the MM_swapImageBullshit were functions generated by old-school Dreamweaver, so it's likely the CSS (complete with nested ID selectors?? really???) was autogenerated too :\
|
# ? Sep 14, 2012 15:48 |
|
PrBacterio posted:I wanted to say "what can't you just look that up in your version control system" but then it dawned on me what the answer to that suggestion might be... No version control of any kind. I can't wait to leave this place. Xenogenesis posted:Well the MM_swapImageBullshit were functions generated by old-school Dreamweaver Well at least it wasn't all hand written then. I still don't know why the hell someone thought using that was a good idea though.
|
# ? Sep 14, 2012 15:57 |
|
Ithaqua posted:Just saw this in a codebase I'm working on. It made me chuckle. We do stuff like that here (only with try/catch blocks) because some of our services talk to a Microsoft CRM server (in the background) that's so slow that the first call is overwhelmingly likely to fail with a timeout. Of course, we can't get rid of CRM because it lets idiots make pretty drag-and-drop UIs to enter and display their data.
|
# ? Sep 14, 2012 16:15 |
|
Munkeymon posted:We do stuff like that here (only with try/catch blocks) because some of our services talk to a Microsoft CRM server (in the background) that's so slow that the first call is overwhelmingly likely to fail with a timeout. Of course, we can't get rid of CRM because it lets idiots make pretty drag-and-drop UIs to enter and display their data. It seems like a better approach would be to handle the timeout within the methods requesting the data. The calling code shouldn't have to worry about it. I'd classify doing Method() ?? Method(); as a horror in pretty much any circumstance.
|
# ? Sep 14, 2012 16:32 |
|
|
# ? Jun 4, 2024 02:53 |
|
Ithaqua posted:It seems like a better approach would be to handle the timeout within the methods requesting the data. The calling code shouldn't have to worry about it. I'd classify doing Method() ?? Method(); as a horror in pretty much any circumstance. I'd have to check, but I think the exceptions get thrown by framework internals when the other service just doesn't respond because it's waiting for CRM*, so there might not be a better way around it. I just try to avoid those parts - it's dark in there * we go through some third party (purchased) library that's not actively developed anymore, so we can't even be sure what's actually going on there
|
# ? Sep 14, 2012 17:11 |