|
They mean a lot, and are enormously valuable...
... to the people who get paid to give out such certifications.
Think about it. Without certifications, where would the certification industry be today?
|
|
|
|
|
|
Prestigious investment bank predicts an $80 billion market by 2025. If so: invest in anti-nausea pills
|
|
|
|
|
At last - we can put banner adverts on the sky, the sea and the setting sun. Oh this VR will be such fun!
(Douglas Adams' anti-peril glasses are probably on the plans too)
|
|
|
|
|
C++ provides two calling syntaxes, x.f(y) and f(x,y). This has bothered me for a long time. A call about calls, from Bjarne
|
|
|
|
|
|
Not really relevant in this case.
First, there remains only one C++ Standard.
Second, they are not adding a new type of call, simply saying that two existing types become closer to equivalent.
It is one of those rare cases when they are actually simplifying the language. These are so uncommon they should be a cause for celebration.
"If you don't fail at least 90 percent of the time, you're not aiming high enough."
Alan Kay.
|
|
|
|
|
 Quote: To my surprise, many people came out strongly against x.f(y) finding f(x,y) – even if member functions were preferred over free-standing functions by the lookup rules. I received email accusing me of “selling out to the OO crowd” and people whose experience and opinion I respect insisted that x.f(y) finding f(x,y) would seriously compromise their ability to design stable interfaces. I think those fears are greatly exaggerated, but I could be wrong. Also, I prefer the dot syntax in some cases; for example, I find x.f(y).g(z) more readable than g(f(x,y),z). However, there was no chance of acceptance of a proposal that included x.f(y) finding f(x,y). Maybe modules will eventually help here. Furthermore, David Vandevoorde pointed out that because of the two-phase lookup rules having x.f(y) find f(x,y) would complicate the task for compiler writers and possibly be expensive in compile time.
So, we are left with a simple proposal to allow f(x,y) to find x.f(y) where f(x,y) wouldn’t work today.
Could someone explain why allowing f(x,y) to find x.f(y) is apparently so much easier than allowing x.f(y) to find f(x,y)?
Also, while not explicitly stated, the article's implying that f(x,y) to x.f(y) is going to be less bad for API maintainers. I'm not really seeing why one version would be less of a potential problem than the other. Also, while there probably are legacy APIs where the two aren't the same - preventing the simplest implementation - I can't think of a reason for doing so that isn't a cluster elephant. That being the case, any argument on the line of "mapping one to the other would limit my future options by preventing me from having both and making them work differently" sounds like "I want to be able to do something stupid". Again, am I missing something here?
Did you ever see history portrayed as an old man with a wise brow and pulseless heart, waging all things in the balance of reason?
Is not rather the genius of history like an eternal, imploring maiden, full of fire, with a burning heart and flaming soul, humanly warm and humanly beautiful?
--Zachris Topelius
Training a telescope on one’s own belly button will only reveal lint. You like that? You go right on staring at it. I prefer looking at galaxies.
-- Sarah Hoyt
|
|
|
|
|
|
|
Ooops. I even did a search of the forums for "apple" and "ios" before posting.
|
|
|
|
|
The real question to ask, though, is why this figure is so important to Microsoft. Misleading market share numbers? I thought they were always carefully caudally extracted
Or pulled from a popo with precision?
|
|
|
|
|
Kotlin is a pragmatic programming language for JVM and Android that combines OO and functional features and is focused on interoperability, safety, clarity and tooling support. There you go: I know you wanted a new language to learn
|
|
|
|
|
XAML Behaviors have long been a frustrating part of WPF/Silverlight development. Though incredibly useful, the libraries were distributed and maintained in a strange fashion. That problem has finally been resolved with the announcement that XAML Behaviors would be open sourced and a matching NuGet package created. Which probably means they're stopping active development
|
|
|
|
|
Kent Sharkey wrote: Which probably means they're stopping active development
Or they need the community to finally solve all those bugs?
Skipper: We'll fix it.
Alex: Fix it? How you gonna fix this?
Skipper: Grit, spit and a whole lotta duct tape.
|
|
|
|
|
We gravitate toward familiar tech because it's the comfortable, low-risk route. "Any one who thinks is an agnostic about something, otherwise he must believe that he is possessed of all knowledge."
|
|
|
|
|
In an ideal world, it would be nice to be capable of developing on every platform/language/technology. In practice, this should be tempered by the skill set of developers available. There's no point adopting a technology without the skills to use it.
"If you don't fail at least 90 percent of the time, you're not aiming high enough."
Alan Kay.
|
|
|
|
|
So - an uncomfortable high risk route is beneficial because...?
(I agree we should try to be tech-agnostic using things like repositories, micro-services and interfaces etc. but it is not the case that "language agnostic" is a component of "technology agnostic" and it is not always the case that newer means better)
|
|
|
|
|
But of course! After all all we do is for fun and learning and passing the time...It has nothing to do with earning money, deploying applications or all those real-word bullocks...
Skipper: We'll fix it.
Alex: Fix it? How you gonna fix this?
Skipper: Grit, spit and a whole lotta duct tape.
|
|
|
|
|
The article sounds like a rant directed towards executives and not developers. The projects with serious problems due to a bad tech stack choice are the exception and not the normal case.
By saying "You should be tech-agnostic in every development project", he actually means "Hey, executives, don't make us use a wimpy development technology like PhoneGap when we need something more substantial. Be flexible and do things my way."
And he's diplomatic enough to make his point with a positive-sounding over-generalization that we developers should ignore.
|
|
|
|
|
In my experience, I've found that the wrong tech stack occurs more frequently than it should. The main problem points to non-technical managers (or washed-up engineers) who insist on using some outdated piece of s*** framework, stack or tool that cripples future functionality.
"Computer games don't affect kids; I mean if Pac-Man affected us as kids, we'd all be running around in darkened rooms, munching magic pills and listening to repetitive electronic music."
-- Marcus Brigstocke, British Comedian
|
|
|
|
|
I agree with your first sentence, but have just as often observed developers doing just what the opinion piece suggested. Rather than using outdated stuff, I've found they tend to steer toward cutting edge (with managers often being worse than engineers.) This results in projects being worked on by novices (who are often experts in what they abandoned) that stall when they can't hire anyone to take over (or the "new" think turns out to be a turkey.)
|
|
|
|
|
I think - if you translate the buzzword-manager-speak to normal English - his point is is that cross-platform mobile app frameworks like Cordova seem nice, but don't work out in practise. Probably true, but he doesn't explain why.
|
|
|
|
|
There's so many things that are ridiculous about that article, I can only say that he sure nailed it on the head when he prefaced the title with "Opinion".
Marc
|
|
|
|
|
Close on the heels of Marc Andreessen's anti-colonialism comments about India, a second billionaire Silicon Valley VC has exploded his ego all over the internet. 2*b |~ 2*B
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
