|
Soricidus posted:you're probably not as stupid as poo poo. i mean function pointers aren't hard or anything but actual honest to god stupid as poo poo coders sure seem to think they are so well done, you're probably in the top 20% Honestly if you can even get the type declaration right for a function pointer you're probably in the top 20%.
|
#
¿
Apr 16, 2014 01:13
|
|
|
|
| # ¿ May 2, 2024 13:46 |
|
|
Soricidus posted:you don't need to write a function pointer type declaration to call qsort yeah, if you give a C-experienced interview candidate a comparator function and ask them to write the prototype for qsort, you get a lot of erase-and-retry and careful counting of parens. (if the candidate asks if they can use cdecl they get full marks and we move on.)
|
|
#
¿
Apr 16, 2014 02:30
|
|
|
Bloody posted:if you have access to libraries that have things like good sort functions in them why the hell are you writing c macho. did I ever tell you I wrote an assembler?
|
|
#
¿
Apr 16, 2014 02:45
|
|
|
Phobeste posted:and of course the other thing is that in a lot of cases you really are riding close enough to the limits of the devices capability that everything really does go, and you really do want macros and bit fields and all that, because embedded development is actually a super broad field. when i'm writing user space software for embedded linux i can follow nice code guidelines. when writing asm or c for the soc's on die real time processor not so much, but they're both in the job description I remember spending a weekend packing a ton of stuff into bitfields to get under a memory budget on a set-top thing that was embedding our library, only to discover that the extra instructions from manipulating them blew the flash budget for code.  Suspicious Dish posted:JavaScript is a good language. I like it a lot. 
|
|
#
¿
Apr 17, 2014 00:50
|
|
|
Malcolm XML posted:in other windows news: the windows source tree is dozens, hundreds of gigs. does it contain a pile of different versions of library binaries? (actually, they might version their toolchain, which can be a good approach if you don't gently caress things up landing branches and whatnot.)
|
|
#
¿
Apr 18, 2014 15:35
|
|
|
Mr Dog posted:but instead it's just this post about something called Duetto that compiles C++ down to JavaScript. I don't know from Duetto, but emscripten is awesome and you should try to have more of it in your life if you like to be happy.
|
|
#
¿
Apr 19, 2014 13:10
|
|
|
Bloody posted:vim owns bones too bad it isnt even more widely supported there have been browsers extensions that do this, idk if any of them work these days
|
|
#
¿
Apr 21, 2014 06:12
|
|
|
LD_PRELOAD and friends are disabled for setuid binaries, unless the library in question has been specially flagged (setuid itself). the same holds for POSIX capabilities. is it easier to write a secure message receiver that performs a privileged action on behalf of an unprivileged sender, or to write a privileged program that does so on behalf of an invoker? (IIRC, Bonobo was a project to provide the semantics of OLE embedding via CORBA protocols. ah, orbit, how you're not missed. CORBA trivia: what company shipped the most ORB implementations to users, by a wide margin that holds even 10+ years later?) 2014 is obviously, finally, the year of the linux desktop. unless we can kickstarter shrughes' drepper-doctrine intervention, maybe.
|
|
#
¿
Apr 21, 2014 21:27
|
|
|
Suspicious Dish posted:Right, I thought this was the case, but I couldn't find any code in GNU ld or the kernel that did environment sanitization, and Googling around told me it was actually an SELinux feature. It's not sanitization, ld.so (not ld) just doesn't process the entries if the binary is setuid/setgid. (This means, I believe, that you could inject PRELOAD into subprocesses executed with elevated privileges. Maybe?) Predates SELinux for sure.
|
|
#
¿
Apr 21, 2014 21:58
|
|
|
teaching programming is a literacy issue, like basic probability or civics or internet. whatever career a person goes into, the odds are pretty good that effective use of computers can enhance their success. could just be Excel macros, could be some little script to massage their linguistics data into a more useful form, could be whatever. programming technology is becoming more accessible, but the practice is still treated as the province of magicians who will devote their lives to illuminating curly-brace manuscripts and building shrines to Hindley-Milner. teach programming by teaching "how to make a cool picture with a software Spirograph" or "how to make a text game", not by Teaching Programming and definitely lot by Teaching Computer Science. i'm on the board of a vocational college (though we offer degrees as well as diplomas), and whether the field is hotel management or aviation, there is a strong correlation between better outcomes and basic programming understanding. understanding what problems computers can help solve is hugely powerful, even if you don't ever do any actual programming in a Real Environment. there are knock-on effects that are good too, as observed in the 7-12 set. kids with some exposure to programming are less likely to be discouraged by initial difficulty in solving a problem, which makes sense: programming is 10% figuring out what to write, and 90% figuring out wtf it doesn't work correctly. there's a real question about availability of teachers and curriculum quality, plus what the time would displace. american schools at least are not exactly bursting with science and art and such classes at the lower grades as it is. it's an area where industry involvement could be helpful, but the industry is mostly people like us who get off on the systems theoretic stuff or optimization and have allegiances to styles of programming or specific technologies. there's peril there.
|
|
#
¿
Apr 22, 2014 20:48
|
|
|
we have a thing that picks a small percentage of read-only requests and plays them a second time against a different code branch, to compare performance and other results. It's pretty great, because it means you're testing real usage on real infrastructure and data sets. You can also do the whole A/B slow rollout thing to see if anything explodes. a bunch of places do that as part of continuous deployment, and we do it as part of every FB push. it's also super handy on Android, where OEMs love to troll you with random platform differences and the breadth of devices is just way too high to admit to systematic verification.
|
|
#
¿
Apr 22, 2014 22:34
|
|
|
uncurable mlady posted:grandpa did you use the autoclose thing?
|
|
#
¿
Apr 22, 2014 22:36
|
|
|
boo. lmk if you remember how you triggered it, i'll try to fix it.
|
|
#
¿
Apr 22, 2014 22:52
|
|
|
Otto Skorzeny posted:make sure your programs handle SIGKILL intelligently! that would be a neat trick
|
|
#
¿
Apr 22, 2014 22:53
|
|
|
qntm posted:testing is hugely important and nobody wants to do it because it's boring, thankless and people only ever pay attention to you when something has gone wrong testing is great because with good tests you can go quickly and keep your barbarian co-workers from loving you over. it's a quality of life investment you make on your own behalf. edit: vvvv is "generative testing" like fuzzing, but without the randomness? my life was dominated by (bugs found by) JavaScript and markup fuzzers for a while, they're worryingly effective. Subjunctive fucked around with this message at 00:00 on Apr 23, 2014 |
|
#
¿
Apr 22, 2014 23:28
|
|
|
Janitor Prime posted:I took a course in my final year of undergrad that was basically a course on Personal Software Process that was about as close to actual engineering as I've ever seen. It was probably the most useful class I ever took and really helped me stand out from the rest right after graduation. PSP/TSP is a pretty great dogma, as they go. a previous smallish (15 ppl) company I was at started to do the training just when I left, and I was always sad I missed out on it. uncurable mlady posted:what happened i think is autocorrect fired off at the same time that an extra character got inserted yeah, sounds like an autocomplete interaction gone awry. i'll take a look tonight, I can reproduce at least one case ("ill" then space making "i'll l" with point after the space rather than at the end).
|
|
#
¿
Apr 23, 2014 01:04
|
|
|
GrumpyDoctor posted:if your code needs lots of comments you done hosed up somehow or the APIs you're calling are hosed up (or the toolchain, or whatever sharp corner of reality might put out an eye)
|
|
#
¿
Apr 23, 2014 03:04
|
|
|
more like dICK posted:Reposting for the nth time: this was a whole thing in the late 90s in Canada, when a university got sued for trademark infringement over labeling a program "Software Engineering" (it didn't include the core physics curriculum and such). the licensure situation is such that putting SE under the umbrella probably wouldn't affect very many people (since you're not considered to be practicing Engineering if you're doing work for an employer vs a client), but for a while people were scrubbing their job postings and such. here's a nigh-unreadable powerpoint that summarizes it as of ~2010: http://www.engr.mun.ca/~dpeters/7893/Notes/presentations/SElicensing.pptx having Real Software Engineers would be neat, but I don't think it makes much of a practical difference. nobody is going to contract a SWE consultant for their mobile app like they do for vetting house plans, and few companies who don't already approach software with that discipline would start just because their new college hires had rings. the risk economics just don't fit. if you want to see more triple-check verification engineering, you might be best off trying to make the failure modes of LOB software more catastrophic? edit: Tiny Bug Child posted:development uses (or should use) engineering processes, thus it is engineering. Why should it? Civil engineers can point to pretty compelling effort/safety tradeoffs in favour of the additional diligence, but most software that has similar significance is already built in accordance with doctrines that would easily fit into a definition of big-boy engineering. most of the arguments I hear on the software side are "that sequence of letters is sacred" or "my coworkers make dumb mistakes". I'm all for better software, but there would be so much less software in the world that the profession would basically collapse for a while. (Those of us posting about this in this thread are unlikely to be called to heaven when the doctrine rapture comes.) "well, I was going to build Skype, but I couldn't afford to verify the codec's failure modes" is not a better outcome, even if the alternative is Skype users getting RCEd by the thousands every month. assuming it changed anything at all, which I think isn't likely for a few reasons, but this post is already  enough
Subjunctive fucked around with this message at 21:07 on Apr 23, 2014 |
|
#
¿
Apr 23, 2014 20:52
|
|
|
Bloody posted:failure modes of software are already catastrophic they just arent screamingly obvious so nobody cares. bridge fails? bridge falls down. openssl fails? well you see let me explain c++ memory allocation to you Heartbleed wasn't really catastrophic, IMO. What were the effects of it, practically? I'm sure more key material leaks every month from lovely server maintenance hygiene than was lost to Heartbleed attacks.
|
|
#
¿
Apr 23, 2014 21:46
|
|
|
Bloody posted:well that's part of the problem - it's difficult to pinpoint and trace the failures. did heartbleed kill anybody? cost anybody large amounts of money? cause other material damage? who knows! idk I guess I figured that if you thought it was catastrophic you might have a catastrophe in mind it's pretty hard to reason about an appropriate level of investment in avoiding a problem if that problem's consequences are guesswork. the engineering process isn't about avoiding all failures, it's about being able to judge risk and mitigate it in accordance with its magnitude. engineers apply accepted rigor as appropriate to address understood problem profiles in individual cases software-system risk is utterly dominated by user error rather than software quality issues like memory management or race condition problems. UI Engineering might well be a more effective direction to reduce the amount of software-delivered damage in the world. (I guess that's called Systems Engineering in some circles.)
|
|
#
¿
Apr 23, 2014 23:09
|
|
|
Spime Wrangler posted:You want catastrophic? Think about control systems for powerplants, or hospital servers, or refineries, or whatever. Your worst-case scenario definitely includes loss of life and property at scale and therefore its time to use the big-boy risk assessment and mitigation tools. Absolutely. My thinking is that in those environments people are already employing at least the level of rigor that we're associating in this thread with capital-Software capital-Engineering. An old friend of mine does nuke-plant control software, and it certainly sounded like it from his stories. When i was in high school I thought "lol paperwork sucker" but now I think "thank god". (He's exactly the sort of person who should be writing that sort of software. He's also the guy who taught me C++, and I defile his generosity every time I push.) The Java source files used to say that you were not permitted to use the software in nuclear, human-life-critical, or similar contexts. I should probably put that on my résumé too.
|
|
#
¿
Apr 24, 2014 02:29
|
|
|
Arcsech posted:you would hope, but I fly too much to want to ask follow-up questions. 
|
|
#
¿
Apr 24, 2014 02:40
|
|
|
Soricidus posted:like in java it's ridiculous that there are methods in the standard library that require a StringBuffer and i can't pass them a StringBuilder instead that's probably something that could have been solved in Java with use of an interface, without having to change the type system.
|
|
#
¿
Apr 24, 2014 14:18
|
|
|
value types would be nice. (this time for sure they have datetime figured out)
|
|
#
¿
Apr 24, 2014 15:35
|
|
|
Sweeper posted:i don't get the hate for them, if you don't want it checked just make it a runtime exception since if you don't want it checked it better not be recoverable recoverability is pretty rare in practice, because it means you need to be effectively transactional in all your operations, or a thrown exception leaves you inconsistent. there are relatively few places in a program where you can throw away meaningful chunks and be in a consistent state; many fewer places than there are method calls. the "have to type something to shut up the compiler" ergonomics are really bad, and leads to way more swallowing IMO. if the exception specification told you more about the context of the failure to guide recovery it might work better, but the Java type system isn't really expressive enough to do a good job there. it might be a better situation if type erasure didn't mean this: Java code:(not being able to parameterize a class' error model the same way you parameterize the class is another gripe) this means you end up with a billion useless little classes whose only purpose is to have a different type signature, and wrapping exceptions all over in bespoke ways. take Runnable.run (please): everything is forced through RuntimeException because you can't be more descriptive in the signature of your own implementation. the prevalence of things like Guava's Throwable.propagate is a sign that the checked-exception experiment is a failure, IMO. maybe with grownup generics it would be OK, because then the type system would help you distinguish RemoteException<HostNotFound> from RemoteException<VersionMismatch>.
|
|
#
¿
Apr 24, 2014 16:50
|
|
|
Scaevolus posted:
two different strings compare as different: a horror I can handle there are lots of different forms of equality/equivalence, many perfectly  languages express different flavours as eq and == and equals and thing.equals(other). (Is -0 equal to 0?)
|
|
#
¿
Apr 24, 2014 19:02
|
|
|
spongeh posted:we should all just band together and use lua and luajit I'm not a huge Lua fan, but Mike Pall is a straight-up badass.
|
|
#
¿
Apr 25, 2014 00:48
|
|
|
Otto Skorzeny posted:i've never met anyone who's ever encountered a snan in the wild in any context hi, come here often? i'm your host for "some rear end in a top hat plugin changed the signaling mode for your whole application" theatre.
|
|
#
¿
Apr 25, 2014 04:41
|
|
|
Shaggar posted:also regarding the "end-to-end" principle or whatever dumb crap, even if code at a higher level cant immediately resolve an exception, sometimes it can add more useful information that can help further up the stack. This is especially true for exceptions that will require human intervention to resolve like a file being missing or w/e. yes, log-and-propagate can be helpful, too bad you end up with everything wrapped in (what does "RuntimeException" mean, anyway? it's not like others are generated statically or something, and the VM internals are hardly the only source of them)
|
|
#
¿
Apr 25, 2014 05:16
|
|
|
Shaggar posted:most of the importance of checked exceptions is in letting you know they can happen so you can plan for them instead of having your code die unexpectedly. ex: even if you don't even try to handle the exception, you may want to clean up something you were doing. if you cant do anything with them or cant add information, then don't. just throw. its not a big deal The type system doesn't tell you enough to plan for what to do, so you still have to read the documentation (or source) to figure out exactly what state you are in once you get an exception back. So at that point you basically just want the C++ nothrow protocol, and in Java that's meaningless because of RuntimeExceptions, so... "Making people think about it" feels to me more like making users click through a browser security warning: they'll do whatever to shut it up, but you can blame the user afterwards for being dumb! Then it *looks* like it's handled, which is even worse than it unraveling to the top and fataling out the app in many cases. People who are diligent will do the right thing with checked exceptions, but they'd do the right thing anyway because they're diligent. People who aren't will effectively stomp out the compiler error like they're clicking through a EULA or browser security dialog. When they're first writing that code they haven't started to think about error handling yet anyway, so they just want it out of the way so that they can see if the main path works. It seems that there's some confusion about the correct use of booleans; luckily I am here to explain the truth. Booleans are for storing the results of logical operations, and use as positively-named properties (gently caress off "isDisabled"). They should not appear as parameters. Please govern yourselves accordingly.
|
|
#
¿
Apr 25, 2014 20:33
|
|
|
AlsoD posted:What do you mean by "parameters" in this context? C++ code:C++ code:
|
|
#
¿
Apr 25, 2014 20:57
|
|
|
Soricidus posted:the thing about checked exceptions is that they provide a useful tool to help diligent but merely human coders avoid mistakes. I get that, and I'm sympathetic to it. I think that an IDE telling you about unhandled things that appear in @throws annotations would be great. I just don't like the ergonomics of Java's checked exceptions, because they motivate you to do *something* right now when you're likely not thinking about the code that way, and then you have to go back and check all the cases again anyway to see if you actually did the right thing or were just shutting it up so you could try something out. And then the IDE *can't* help you, because you've got this stub handling all over. I used to be a believer, but when I watched how I actually interacted with them (and I was definitely trying to be diligent, and I'm pretty sure I'm on the right-hand side of the coding bell curve), I started to really feel that they pushed unhelpfully. We can still be friends, though.
|
|
#
¿
Apr 25, 2014 22:07
|
|
|
MeramJert posted:hey haskellers what's the best http client library? i'm porting a web scraping thing i did in python with requests and was using Network.Browser but it's choking on some redirects for some reason and i'd rather use something that Just Works. is there anything as good as requests? i'm not a haskeller, really, but bryan o'sullivan's wreq looks p good: http://www.serpentine.com/wreq/ re: typesafe parameterized exception types: yes, if you're will to open code the type mechanisms, the world is your oyster. I feel about that the way you would if someone caught Exception and then had a chain of instanceofs. i'm not saying it's impossible, i'm saying that it's pretty gross that Java's type system just throws its hands up, given that it hung the whole checked-exception thing on that very type system.
|
|
#
¿
Apr 28, 2014 03:28
|
|
|
keynote is decent, though probably hard to automate. Omnigraffle is probably the state of the art, if you have a Mac around.
|
|
#
¿
Apr 29, 2014 16:59
|
|
|
Tiny Bug Child posted:whoa this is literally the first valid argument in favor of static typing i've ever seen. that said i guess it's up to you but i personally don't think improved autocompletion is worth the programming equivalent of having someone follow you around all day and yell at you whenever you end a sentence with a preposition more valuable than autocomplete imo is "go to decl/impl/docs". with good analysis tools and consistent coding style you can get a lot of that, but usually not all. also, refactoring is a lot safer with static types, because it provides a simple form of whole-program analysis of usage. changing a type signature when making semantic changes can save a lot of grief. i roll dynamic wherever i can, but i do miss static types when working with 3rd-party libraries. they're a pretty good form of unavoidable documentation. declared types don't have to be static, though, in that objects can change their traits at runtime even if a given variable is labeled or inferred as a given type. late-loading mixins or expandos or whatever can be really helpful in managing incidental state, though they can also be footguns.
|
|
#
¿
Apr 30, 2014 17:37
|
|
|
tef posted:feature switches over feature branches
|
|
#
¿
May 6, 2014 03:40
|
|
|
Suspicious Dish posted:I don't think feature flags are suitable for desktop software chrome and firefox live and die by them; i would have started hammering toes if someone had tried to eliminate them when i was running FF dev Edit: also pretty critical for the mobile apps i've worked on. late binding of deployment decisions and in-the-field issue mitigation, yes please. it's probably not as big a deal if you don't have very many users or devs, or if your software magically only targets a few configurations, i guess Subjunctive fucked around with this message at 04:32 on May 6, 2014 |
|
#
¿
May 6, 2014 04:30
|
|
|
Suspicious Dish posted:I said I don't do web software i was referring to desktop software, as were you. Bloody posted:are you claiming responsibility for firefox? you make it sound so dirty
|
|
#
¿
May 6, 2014 05:35
|
|
|
Sweeper posted:are you or aren't you i was for several years, yes
|
|
#
¿
May 6, 2014 06:37
|
|
|
|
| # ¿ May 2, 2024 13:46 |
|
|
coffeetable posted:do you use chrome nowadays on iphone/ipad yeah, desktop occasionally. i dress to the left, also.
|
|
#
¿
May 6, 2014 06:43
|
|