|
Bloody posted:this is unrelated to my previous line of questions the old way to do this was to serialize objects using .NET remoting. it turns out object serialization and distributed computing are Hard Problems so that is officially deprecated. (this makes me sad because it was crazy easy to use if your problem was simple enough) nowadays i think the cool kids use WCF but i don't really know much about that
|
#
?
Sep 29, 2014 19:54
|
|
|
|
| # ? Jun 3, 2024 02:24 |
|
|
Bloody posted:this is unrelated to my previous line of questions dcom
|
|
#
?
Sep 29, 2014 20:08
|
|
|
b0lt posted:is this some sort of fascist movement i think it's the bad guys from killzone
|
|
#
?
Sep 29, 2014 20:09
|
|
|
Notorious b.s.d. posted:the old way to do this was to serialize objects using .NET remoting. it turns out object serialization and distributed computing are Hard Problems so that is officially deprecated. (this makes me sad because it was crazy easy to use if your problem was simple enough) wcf is the way to go and has lots of different bindings and message protocols, not just soap (though soap would work). theres probably one 2 do what you want pretty easily.
|
|
#
?
Sep 29, 2014 20:15
|
|
|
can someone give me the lowdown on why ppl don't like COM? what's wrong with it? admittedly i only used COM very briefly but i didn't have any big issues with it other than some weird terminology (apartment? whaat?)
|
|
#
?
Sep 29, 2014 20:16
|
|
|
Notorious b.s.d. posted:it turns out object serialization and distributed computing are Hard Problems so that is officially deprecated. Old timey lispers would tell you that code as data and s-expressions fixed this over 40 years ago and you just have bad tools.
|
|
#
?
Sep 29, 2014 20:17
|
|
|
Shinku ABOOKEN posted:can someone give me the lowdown on why ppl don't like COM? what's wrong with it? COM was designed to make interop between languages extremely easy and it was massively successful. if someone writes a COM component in c++ you can use it in vb, vbs, c#, or any other language that has access to COM. Its incredibly easy to use. the original design didn't have much in the way of security so that lead to a bunch of problems and that's probably what most people think of when they think of COM, but its not so much a deal anymore. The more serious problems with COM are caused by its success. Because everyone and their mother used COM in all their old rear end code, every time Microsoft added new stuff they would make sure it was available via COM so the people still working in the old world could get the new stuff. This caused 3 problems: 1) COM itself hasn't advanced in forever because it needs to be backwards compatible with all the old poo poo. So if you come in from the new world to work on COM you're gonna hate some of the ways it works. 2) Newer systems get gimped by COM interop because they have to take the time to add it to everything. 3) Because COM still exists, old programs never get updated to newer languages + features which means for big name products (OFFICE. WHAT I REALLY MEAN HERE IS ITS ALWAYS OFFICE'S FAULT) they don't bother to upgrade poo poo because they can just add new lipstick to their existing com pig. This drags down the entire windows platform and its the reason surface was so loving bad. COM is a smart idea that was executed well for the time it was born, but now it is just useful enough to stick around and cause pain.
|
|
#
?
Sep 29, 2014 20:28
|
|
|
MononcQc posted:Old timey lispers would tell you that code as data and s-expressions fixed this over 40 years ago and you just have bad tools. yea if you have serialization problems you're probably doing some Linux poo poo and should just get over yourself and use java or .net cause its a long solved problem there too. I mean hell, in .net there are probably 100 different ways to do network serialization built in cause its on windows.
|
|
#
?
Sep 29, 2014 20:32
|
|
|
Want to access a webservice from your vb6 app? no problem, just create a client in .net and create some methods w/ all the parameters u need and annotate it w/ some COM poo poo. Then compile and register the dll and blammo everyone on the machine, including your vb6 app, can grab your component and call those methods. that takes litterally 10 minutes at most to do. that's why com is so dangerous.
|
|
#
?
Sep 29, 2014 20:36
|
|
|
use orleans, http://orleans.codeplex.com someday i will effort post on it long story short: virtual actors in .NET, scale out in azure
|
|
#
?
Sep 29, 2014 20:39
|
|
|
Shaggar posted:COM was designed to make interop between languages extremely easy and it was massively successful. if someone writes a COM component in c++ you can use it in vb, vbs, c#, or any other language that has access to COM. Its incredibly easy to use. can you or anyone else elaborate on what are the advanced stuff COM is missing? i can create objects in COM and call methods on them just fine, how much advanced do you need to get 
|
|
#
?
Sep 29, 2014 20:40
|
|
|
MononcQc posted:Old timey lispers would tell you that code as data and s-expressions fixed this over 40 years ago and you just have bad tools. i dont bother listening to old timey lispers
|
|
#
?
Sep 29, 2014 20:41
|
|
|
MononcQc posted:Old timey lispers would tell you that code as data and s-expressions fixed this over 40 years ago and you just have bad tools. yeah it didn't work for them, either
|
|
#
?
Sep 29, 2014 20:49
|
|
|
Malcolm XML posted:use orleans, http://orleans.codeplex.com that is really cool and I don't have any use for it.
|
|
#
?
Sep 29, 2014 20:51
|
|
|
Malcolm XML posted:use orleans, http://orleans.codeplex.com that requires real visual studio and not express 
|
|
#
?
Sep 29, 2014 21:00
|
|
|
Shinku ABOOKEN posted:can you or anyone else elaborate on what are the advanced stuff COM is missing? components can have their own internal state that they wont tell you about and you can run into problems where you use a com component and don't realize it spawned a process to handle your request and didn't kill it because it thinks you know you need to kill it. or it will get into an error state and maybe not tell you about it because obviously if you're using this component you're the guy who wrote it so you know about all the garbage you have to handle. office is the worst for this. instead of being able to just have a word doc and do things to it, you essentially launch a copy of word and then start interacting with methods that are basically the same functions that exist in all the menus. its not very developer friendly. a million things can go wrong when you try to do anything in word com so you're constantly adding error handling code to every step and its so gross. if you gently caress up and miss an error, whoops now the word process is sitting there with an error displayed to the user but wait theres no actual user so there will never be any input so this com process is hosed until you kill it. so just grab the process id when its spawned and have a thing hang around to kill hung processes, right? well, no. you cant get the process id from com (afaik), so write up some hack to scan for processes named winword.exe that were created around the time you instantiated your word com object and then when you kill it hopefully it was the right one. now contrast this with the official, pure .net OpenXML framework which is incredibly easy to work with. tl;dr: COM is a minefield which is ok if you set the mines and remember where they all are. Shaggar fucked around with this message at 21:08 on Sep 29, 2014 |
|
#
?
Sep 29, 2014 21:06
|
|
|
Notorious b.s.d. posted:yeah it didn't work for them, either What if we don't see lispers that much anymore because they tend to get everything fixed and working first time around and their systems just become infrastructure people rely on forever without needing to maintain it, and they're putting themselves out of work.
|
|
#
?
Sep 29, 2014 21:11
|
|
|
Malcolm XML posted:use orleans, http://orleans.codeplex.com b/c there's some clod stuff on the horizon at work and with little-to-no background in webshit i expect its gonna be v painful for me. even worse, ill probably be left to my own devices to pick the tech and architecture lol startups
|
|
#
?
Sep 29, 2014 21:11
|
|
|
Shaggar posted:components can have their own internal state that they wont tell you about and you can run into problems where you use a com component and don't realize it spawned a process to handle your request and didn't kill it because it thinks you know you need to kill it. or it will get into an error state and maybe not tell you about it because obviously if you're using this component you're the guy who wrote it so you know about all the garbage you have to handle. office is the worst for this. instead of being able to just have a word doc and do things to it, you essentially launch a copy of word and then start interacting with methods that are basically the same functions that exist in all the menus. its not very developer friendly. a million things can go wrong when you try to do anything in word com so you're constantly adding error handling code to every step and its so gross. how is this the fault of COM? wouldn't you be in the same exact position if say you used lovely dll that spawned processes behind your back, had opaque state, etc.? don't get me wrong the situation you describe is 100% poo poo and an actual file manipulation framework is 100% better but i fail to see why this is COM's fault
|
|
#
?
Sep 29, 2014 21:40
|
|
|
com doesn't provide (afaik) any way to publish the possible errors the component/method may throw, whereas in c# that information is auto generated by the compiler. nor can you alert the consumer thru code w/ something like IDisposable that this is something you need to take good care of. you could update com to include exception definitions, but not all languages are going to support them or you'd have to do something goofy like return some quasi-option type that you have to dig into each time to figure out what happened. its not really something you can solve and retain maximum language compatibility. the assumption for using com is that this is unmanaged code and you have to deal with every problem because the runtime cant help you. if you could get rid of that uncertainty it would make navigating the minefield easier, but it would also possibly break backwards compatibility. tbf this really isn't totally a com problem (p/invoke) has the same problem and you could always have a really lovely .net lib that does dumb poo poo, but there is no way to do it right in com. unmanaged code can make your consumer far to coupled to the failure of the com component. dcom kind of helps solve this because it puts the responsibility of component resource cleanup back onto the server. even if you ignore the minefield problem, its the nature of com to drag old legacy code with you. again, there is no better example than office. without com they might be forced to rewrite chunks of ancient code within modern languages and modern design principles. with com they drag the old poo poo around and tack on new poo poo without fixing the old. this makes the code base far less maintainable. its like every legacy system you've ever worked with except worse because the legacy goes back over 20 years. if you think dealing with java 1.4 hurts, dealing with old com is way way worse. that's 20 years of various programming practices being carried thru to today. i don't hate com and I've used it for sticking new stuff into old stuff, but it has definite flaws that have caused Microsoft lots of pain. and the real problem now is that even if they had new versions of com with new features like better discoverability, it probably wouldn't be used cause people wouldn't be able to bring their old poo poo through. and as long as Microsoft allows office to stagnate back there they will continue dragging the legacy code it relies on thru each version of windows which means users get a subpar experience and developers have no reason to migrate to newer runtimes. these things are com's fault because com is what Microsoft encouraged everyone to use. they've made some attempts to add new features (com+) but they've stopped and there is no push to move people away from old com. tbh the concept of COM is very very good, it just needs to be modernized. A COM for the web where interfaces + models are defined thru existing standards would be pretty cool because you could have real languages automatically bind to it via the WebCOM standard and then browsers could still use it incorrectly in javascript. that's kind of rambly, but w/e. more than the minefield thing (which you're right, can happen outside com too), its the way it fucks up windows as a platform that is my biggest complaint w/ com.
|
|
#
?
Sep 30, 2014 00:07
|
|
|
Bloody posted:this is unrelated to my previous line of questions are the fart-to-odor programs all the same, or different? either way I think this is the sort of thing you'd do with a message queue or service bus these days. butt posts farts to the queue, fart consumers pull them off (under control of the queue) and post odors to the queue, butt (or nose) pulls odors off the queue and does whatever Shaggar posted:dcom com stymie
|
|
#
?
Sep 30, 2014 02:39
|
|
|
Shinku ABOOKEN posted:can someone give me the lowdown on why ppl don't like COM? what's wrong with it? COM can only do things you could do with C++ vtables in 1990 or so, and doesn't support any sort of real extensibility, just adding yet more replicated IFooEx IFooEx2 INewFoo and so on interfaces as the basis for an "object system" it's laughably terrible and it was hilarious to find out the Windows people still did all the new Windows stuff in it rather than in real .NET with its more powerful type system and binary compatibility story it'd be like if the frameworks in OS X were built around the old Component Manager from QuickTime instead of Objective-C, because the OS team wanted to keep doing everything the same way they'd been doing it 25 years previous
|
|
#
?
Sep 30, 2014 02:48
|
|
|
MononcQc posted:What if we don't see lispers that much anymore because they tend to get everything fixed and working first time around and their systems just become infrastructure people rely on forever without needing to maintain it, and they're putting themselves out of work. i only know of two things that fit this category
i mean, i guess it technically "works" for these guys but i doubt either one of them would turn down the opportunity to replace all their lisp code for $100,000 Notorious b.s.d. fucked around with this message at 04:03 on Sep 30, 2014 |
|
#
?
Sep 30, 2014 04:00
|
|
|
eschaton posted:are the fart-to-odor programs all the same, or different? the noses are all the same but on different machines
|
|
#
?
Sep 30, 2014 04:03
|
|
|
eschaton posted:as the basis for an "object system" it's laughably terrible and it was hilarious to find out the Windows people still did all the new Windows stuff in it rather than in real .NET with its more powerful type system and binary compatibility story the really early .net literature pitches it as a complete and total COM replacement. like, a new calling convention for windows, where both managed and unmanaged code would marshal .net data types. sadly, it didn't pan out eschaton posted:it'd be like if the frameworks in OS X were built around the old Component Manager from QuickTime instead of Objective-C, because the OS team wanted to keep doing everything the same way they'd been doing it 25 years previous component manager from quicktime is several years newer than cocoa/objC osx's core objC APIs mostly date to 1987-1988
|
|
#
?
Sep 30, 2014 04:05
|
|
|
oh microsoft thinks I'm a college student until July 2015 so I still have free windows 8 isos and dev licenses I should install windows 8 in a VM and make a billion dollars cranking out windows store fart machines
|
|
#
?
Sep 30, 2014 04:16
|
|
|
Notorious b.s.d. posted:last i heard, circa 2008, they were still buying Symbolics hardware and emulators to try to keep their miserable proprietary system limping along. do note: symbolics essentially went out of business in 1992. the current "symbolics, inc" is two guys who have worked on it part time for the last 20 years it's both better and worse than that, Symbolics DKS is run by a former employee and he occasionally contracts out maintenance work to other folks in that community, they even did things like port the OpenGenera emulator to x86-64 and it's by all accounts pretty awesome then the Symbolics IP was owned by a scammer dude who died and got tied up in probate, now it's finally been bought by the dude who wrote CL-HTTP who is sitting on it (rather than open sourcing it) because it's "valuable" keep in mind any patents they had are literally expired by now. what's the value in that IP?
|
|
#
?
Sep 30, 2014 04:35
|
|
|
MononcQc posted:Old timey lispers would tell you that code as data and s-expressions fixed this over 40 years ago and you just have bad tools. and they'd be idiots
|
|
#
?
Sep 30, 2014 04:41
|
|
|
well yeah their using lisp
|
|
#
?
Sep 30, 2014 04:42
|
|
|
MononcQc posted:What if we don't see lispers that much anymore because they tend to get everything fixed and working first time around and their systems just become infrastructure people rely on forever without needing to maintain it, and they're putting themselves out of work. the blind lispmaker
|
|
#
?
Sep 30, 2014 04:43
|
|
|
Notorious b.s.d. posted:component manager from quicktime is several years newer than cocoa/objC I know full well (given what it is I do, and I've also written CM code) ObjC is still more "modern," Component Manager was basically a standard wrapper for your switch/case dispatch poo poo, ObjC at least abstracts that behind a language feature. there were people in the Mac community post-1996 who seriously suggested ObjC should become a wrapper for CM dispatch instead so they could still write their poo poo in Pascal and C++ instead of accede to the winners of the object wars fortunately none were at Apple
|
|
#
?
Sep 30, 2014 04:43
|
|
|
Bloody posted:the noses are all the same but on different machines definitely sounds like a message bus/queue system
|
|
#
?
Sep 30, 2014 04:44
|
|
|
Notorious b.s.d. posted:last i heard, circa 2008, they were still buying Symbolics hardware and emulators to try to keep their miserable proprietary system limping along. do note: symbolics essentially went out of business in 1992. the current "symbolics, inc" is two guys who have worked on it part time for the last 20 years was replaced by ita software iirc
|
|
#
?
Sep 30, 2014 04:46
|
|
|
eschaton posted:it's both better and worse than that, Symbolics DKS is run by a former employee and he occasionally contracts out maintenance work to other folks in that community, they even did things like port the OpenGenera emulator to x86-64 and it's by all accounts pretty awesome well symbolics had the first .com name so the domain name might be worth something but the IP behind it isn't
|
|
#
?
Sep 30, 2014 04:46
|
|
|
are you more worried about fart throughput or odour latencies?
|
|
#
?
Sep 30, 2014 04:47
|
|
|
Luigi Thirty posted:well symbolics had the first .com name so the domain name might be worth something but the IP behind it isn't dks ended up with the domain, it didn't go with the ip rights. He sold it a couple years ago
|
|
#
?
Sep 30, 2014 05:26
|
|
|
Notorious b.s.d. posted:[*]canada air. this no longer exists
|
|
#
?
Sep 30, 2014 07:48
|
|
|
thank you all (especially shaggar) for taking the time to answer my terrible questions 
|
|
#
?
Sep 30, 2014 07:53
|
|
|
tef posted:and they'd be idiots no but you see if you just run eval on random user input,
|
|
#
?
Sep 30, 2014 12:34
|
|
|
|
| # ? Jun 3, 2024 02:24 |
|
|
I just wasted a ton of time because I forgot to include a script file. jQuery-UI is not jQuery. And to think the hints were so strong when I was beating up nuGet to stop being retarded about version conflicts with JQuery.DataTables and jQuery actual. What's worse is I just had a phone interview, at 8:30, zero caffeine, and I was told it was just a chat, not technical. So I didn't bother to google common interview questions, which I was asked. On the other hand I just fessed up "no, didn't do that, because $REASON" (we never used viewdata or tempdata, we just had viewmodels and carried our own state around, and since we used a tab system we didn't really use MVCs redirects either) but said "what's a modelbinder  " when I had in fact used them. Ugh. From now on I should presume that any interview will have technical things even if it's 8:30 in the loving morning. The place my avatar burns in effigy (no, it's not gently caress IE, that's my old job's logo) hosed me hard but at least the actual devs there taught me poo poo. I hope I find another actual team soon.
|
|
#
?
Sep 30, 2014 16:10
|
|
