|
Never tried to keep up. Early adoption is costly.
|
|
|
|
|
The pattern I see regularly is:
There's this amazing new way of doing things call FrogrooAPI and the code is open source.
One week later - we need to also download CatrooAPI for FrogrooAPI to work.
Six months later - so as long as you have FrogrooAPI, CatrooAPI, MouserooAPI, GerbilrooAPI and DogrooAPI everything should work...
“That which can be asserted without evidence, can be dismissed without evidence.”
― Christopher Hitchens
|
|
|
|
|
... and by the way, the developers on GerbilrooAPI have all joined an anti-technology commune and have changed their license such that all users of GerbilrooAPI are retroactively members as well, and their membership fees are now due.
If you're thinking that sounds like the GPL...
Software Zen: delete this;
|
|
|
|
|
I think I caught up... 
I don't have this feeling anymore... I am right where I want to be and it seems good! 
I find it strange too...
The one reason perhaps, is that I care not for javascript framework (of which zillion sprout up every single day)
And also, even though I haven't done Xamarin Phone app in like 5 years, I think I am still good (the XAML love and API stability is strong  )
(And WinForm and WPF do not change anymore! ^_^ )
The one thing I just gave up on is 3D/game programming.. never even touched Unity!
|
|
|
|
|
This is why good developers and development shops intercept the CxO postal mail looking for malware such as CIO Magazine.
|
|
|
|
|
Reaching for Private Parts - The Daily WTF[^]
Modifying a class using reflection only in production...
What do you get when you cross a joke with a rhetorical question?
The metaphorical solid rear-end expulsions have impacted the metaphorical motorized bladed rotating air movement mechanism.
Do questions with multiple question marks annoy you???
|
|
|
|
|
Why, just yesterday, I wrote an extension method which fiddles about in the private parts of a .net class.
This is how it's done when Microsoft makes things too elephanting rigid.
The alternative would be to reinvent this particular wheel, which would very likely kill performance.
|
|
|
|
|
PIEBALDconsult wrote: I wrote an extension method which fiddles about in the private parts of a .net class.
There may be (extremely rare) cases when such perversions may be necessary, but a difference in behaviour between development and production?! 
Isn't the whole idea of a development environment to be as close as possible to the production environment, but without changing production data?
Freedom is the freedom to say that two plus two make four. If that is granted, all else follows.
-- 6079 Smith W.
|
|
|
|
|
Shouldn't there be a test database (recent copy of the production database) to test code against?
|
|
|
|
|
I've developed frameworks, and it's virtually impossible to anticipate all user requirements. At least I was dealing with in-house frameworks, where it was easy to interact with users and quickly respond to their needs. For the kind of things that Microsoft is providing, I'm not at all surprised that what you're doing is occasionally necessary.
|
|
|
|
|
Greg Utas wrote: I've developed frameworks, and it's virtually impossible to anticipate all user requirements.
This is the fundamental flaw with all frameworks. Despite it's name the dotNet Framework isn't so much a framework as it is a collection of useful and related classes. It's more of an OS level API for most programmers.
|
|
|
|
|
Another flaw with frameworks is a monotonic increase in their surface-to-volume ratio. It stems from a reticence to introduce "breaking changes" when evolving the framework, because existing users who want to migrate to the next major release think it should be transparent. I have no sympathy for them.
To me, a framework embodies a powerful object model, which means that it must typically be used as a whole, whereas a library is a collection of disparate classes whose collaborations are up to the user.
|
|
|
|
|
One of the reasons I keep falling in love with C++ over and over again is
A) source level polymorphism
B) selective linking
leading to
C) Frameworks that aren't frameworks as long as they aren't coded like garbage
What I mean is you can have a bunch of things that all work together (the STL, a framework more than a library considering how many different things it covers, but all the core bits are used together) and you can only include bits you need.
This encourages me to code even things that may be used rarely, because if you don't need it it's never compiled in.
That leads to very little framework bloat. Plus it's as modular as you develop it to be. If you update <iostream> library you can theoretically, simply update that header as long as you don't change exiting source level interfaces
Real programmers use butterflies
|
|
|
|
|
Please elaborate. I think I might learn something.
Source level polymorphism? Never heard of source level as an adjective for polymorphism. What's it mean?
Selective linking? By this, do you mean that code that isn't used doesn't get linked into the .exe?
I see the STL as being in a half-world between library and framework. Iterators, for example, cut across many of the classes, but the higher-level classes stand on their own. That's quite different from what I'm doing, where it's impossible to use any component on its own, because those in the same static library use each other freely. When I read about this dependency injection fetish in light of what I'm doing, I just throw up my hands and chortle at the endless boilerplate that would be needed. Besides, toy test harnesses will never exercise a framework as well as a few serious applications.
|
|
|
|
|
Greg Utas wrote: Never heard of source level as an adjective for polymorphism. What's it mean?
It means if I have a template
template<typename T> struct A {
T t;
A() : t() { t.foo(); }
};
Then this will compile
struct B {
void foo() { printf("hello!\r\n"); }
};
A<B> c;
but this won't:
struct B {
void bar() { printf("goodbye!\r\n"); }
};
A<B> c;
template A will take any class "of a type" that exposes a public foo() method.
This allows you to create a kind of polymorphism at the source level. There is no explicit binary contract like there is with traditional polymorphism. It's a source contract. You don't actually need a binary interface to be fulfilled for the class.
The bottom line is, you don't inherit to do it. You just call the methods you need. It works because templates aren't resolved until they are instantiated.
One of the chief advantages of this over traditional inheritance based polymorphism is that there's no source dependency on a base class. Most of the STL does it this way, preventing much of the cross header dependencies that would otherwise be needed
Greg Utas wrote: By this, do you mean that code that isn't used doesn't get linked into the .exe?
Yes. I don't know if there's a better name for it, that's just what i've always called it. It's so critical for so much of what i do in C++. My code I'm writing would be so not viable without it.
Real programmers use butterflies
modified 27-Mar-21 21:38pm.
|
|
|
|
|
Your first example makes sense. Instantiating the second A<B> will fail when it tries to resolve B::foo. It's like A is defining an interface that its template arguments must support.
Not linking dead code into an .exe is great. It allows my main() to #include the subset of static libraries that are wanted in a build, which omits all the others without any fuss at all. It's gross to contemplate the code bloat that would otherwise occur.
|
|
|
|
|
I'm glad it made sense to you. It wouldn't have compiled, but it conveyed the idea, it seems, because you're exactly right about how it works. And it's bril, because you don't need to include a header for a common base to use it.
I agree with you about the linking. I write a lot of IoT code, and i couldn't without it.
Real programmers use butterflies
|
|
|
|
|
you should probably refresh. my first several edits were a mess. code was bad. i'm out of coffee. 
Real programmers use butterflies
|
|
|
|
|
I gathered that, and refreshed. If I had coffee now, we'd be here all night.
|
|
|
|
|
Hang the perpetrator from the nearest lamp post, pour encourager les autres! 
Freedom is the freedom to say that two plus two make four. If that is granted, all else follows.
-- 6079 Smith W.
|
|
|
|
|
Damn good way to wreck production code when the originator changes the way his code works internally - which is why such things are private, obviously.
I'm hoping he deploys at 17:00 on a Friday ...
"I have no idea what I did, but I'm taking full credit for it." - ThisOldTony
"Common sense is so rare these days, it should be classified as a super power" - Random T-shirt
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
To paraphrase Frank Zappa, you shouldn't let just anyone spew on your private parts.
"They have a consciousness, they have a life, they have a soul! Damn you! Let the rabbits wear glasses! Save our brothers! Can I get an amen?"
|
|
|
|
|
1- the link refers to Java, not .Net. MS has nothing to do with this.
2- if this fragment is required, the developer is doing it wrong. He is using the wrong class for the wrong job or has not properly configured the app ( a cache in this case)
3 - the class is defective, perhaps one of 100 open-source jars to choose from, perhaps another “vendor” is in order
4- is this H1-B code? That would explain it.
|
|
|
|
|
Building a web scraper I had the pleasure to abuse JavaFX's WebView browser module by modifying byte code to hook onto http requests and the trick of this post to get at the url in an intercepted UrlLoader call. I wouldn't care using it in production. But also in test, I'd like to mention.
|
|
|
|
|
Using Visual Studio 2019:
When I write code for an article, I write the article in an html file that lives in the project itself. As I progress, I eventually want to see what the article looks like in the browser. In .Net Framework projects, this works fine, but in .Net Core projects (in this instance, it was a .Net Core 3.1 project), the menu item "View in browser" does not exist in the context menu for the file.
Why would that be?
".45 ACP - because shooting twice is just silly" - JSOP, 2010
-----
You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010
-----
When you pry the gun from my cold dead hands, be careful - the barrel will be very hot. - JSOP, 2013
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
