|
Chris, I have to say I quite enjoyed your notes all the responses that you caused.
It shows that people are beginning to wake up from their zombie-like trances that surround current technologies. I have been writing, along with others, about the many issues that are being caused by recent technologies. So here are my notes on the subject...
1)
Mobile technologies were designed and provided to the commercial market for a single purpose; to make as much money as possible. Hence, the constant releases of Apple's iPhone upgraded products and all the copycat junk that follows it.
It was done with the blessings of the intelligence agencies as they would be able to get people to volunteer personal information freely. All they had to do was watch the FaceBook "phenomenon" to come up with some really vile plans.
2)
Steve Jobs in all senses was a megalomaniac, not a visionary considering that practically every idea he ever came up with was just a redesign of existing technologies that the Xerox Parc Labs originally developed in the 1970s. The man was a one-stop horror show and yet people idolize this monster. They should work for him for a day.
3)
Cell phones have two substantial uses only; emergency communications and to transfer important information when other methods are not available. They were not designed so every idiot on the planet could spend hours a day to pass hot air that is supposed to pass as intelligent conversation. However, that has been the result. Parents bank accounts get drained due to the enormous costs caused by their children thinking that everyone needs to yammer on a tiny device to make their lives worth saving. Adults, like their children become nothing more than zombified, unintelligent beings that no longer have any awareness of the surroundings. Many credible sociological studies substantiating these conclusions have been done on this subject alone.
4)
Practically all development on new technologies ended with the refinement of Microsoft's ASP.NET WebForms and Java's increases in performance. Everything that came after has been nothing but redundant garbage that does the same things that has been done for years prior with more mature technologies. Who in their right minds would trade in the easier to use ASP.NET WebForms and WinForms for more difficult to use technologies such as MVC and WPF (though I happen to like WPF a lot and it has been made more difficult from the lack of quality documentation on it). Think about it people; you are doing a heck of a lot more work just to be able to say that you are doing things the "right way". Who ever defined "right"? Some people who wanted to make more money by promoting new paradigms that were not nearly as good as the original software engineering principals that they could have used.
5)
Like Apple, Microsoft has fallen off their path to be all things to all people. This is why Visual Studio has become such a bloated piece of software to use. Their Community Edition is all that one now needs to produce quality applications of any type and it is far slimmer than the paid versions.
6)
ASP.NET Core! What a joke with it's DOS like command prompt interface and Visual Code IDE. What's this all about!? All this effort so a few people can write on Linux?
Developer technologies have reached a point where the only purpose they serve are to fragment even further an already highly fragmented industry while making competition for positions so fierce that people no longer want to enter the industry. Oh, and so stpid technical managers can ask all sorts of stupid questions on interviews to demonstrate to the poor candidates that they aren't nearly as smart as they think. What is this, Reality TV!?
The results of such technologies have added not one iota of quality to anyone's lives. They inflict more frustration as companies try to play every sales trick in the book to steer you to what they want you to but online thereby making people's lives more stressful. They de-normalize natural interactions between people making cognizant socialization a thing of the past. They are buggy, poorly supported, and extremely costly. And the only thing they actually connect are your hard earned dollars to the coffers of major corporations.
It is good to see that people are starting become aware of all this as the complaints here indicate that.
Get rid of all this junk, get a flip-phone, and get a life...
Steve Naidamast
Sr. Software Engineer
Black Falcon Software, Inc.
blackfalconsoftware@outlook.com
|
|
|
|
|
I had the Apple thing all figured out after I got the first IPad (that they supported for about 2 years) and having to deal with ITunes...
The other half bought an IPad Mini recently that became "unusable" after about a month (and which I do not want to touch).
|
|
|
|
|
What happened? I ![Heart | [heart]](https://codeproject.global.ssl.fastly.net/script/Forums/Images/love.gif) my iPad mini (except it's first gen and slow on the latest OSs)
cheers
Chris Maunder
|
|
|
|
|
I should state that I am a crusty old Visual C++/C# developer firmly in the event-driven paradigm camp (NOTE: I detested on principle the clunky macro architecture for the Visual C++ message map, but admit that it do the job), although I appreciate the way that OpenOffice Calc (or Micro$oft Excel) works, which I understand is basically by using the functional programming paradigm. I never got much into XAML as I went into early retirement about the time that got to be the new k3wl thing.
I was reading this article (sent to me by CodeProject) about MVVM:
4 Reasons To Drop MVVM[^]
Reading this article, it seems to me that MVVM is simply the functional programming paradigm used for the GUI. Is this accurate? I understand how the functional programming paradigm makes Calc work so well, but also that it only works well when the processing is simple, otherwise a whole lot of funky cells containing state has to be used. My personal opinion is that a GUI is inherently something that needs to be event-driven, and that trying to shoehorn it into the functional programming paradigm just results in boilerplate processing that an be very inefficient.
I distinctly remember using Excel on a clunky Windows 3.1 386 machine (yes, LOL) and having the status bar give the message "Calculating" along with some percentage for *any* change in cell - and as well remember a project in which I was to make something that was like a GridCell, but out of TextBox controls, and I had to do a lot of careful enabled state design so that it made sense; I can't fathom doing that using the functional programming paradigm.
|
|
|
|
|
From the article: "since I primarily do web applications..."
That automatically invalidates anything he says about MVVM. Beyond that, MVVM isn't about "functional" anything - functional programming is the antithesis of object oriented programming. MVVM is more about separation of concerns (UI and data), and is merely a guideline for providing the UI a method of introducing data to the user.
From the artle: "MVVM is slow"
That is most certainly NOT my experience. If it's slow, he should hire a decent DBA to construct his database and write the associated stored procedures. I'm most certainly not what I would call good at database design, but my MVVM apps freakin scream.
The guy that wrote the article is a freakin idiot.
".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
|
|
|
|
|
|
I think he is writing from the perspective of Angular. I don't think he is referring to WPF or WinRT. That said, his article is not logical and does exaggerate a fair bit.
|
|
|
|
|
Personally I find that MVVM done right is so much more maintainable then other options. Of course it is going to impact speed. If that was a major concern we would still be programming strictly in C, not even C++. It is hard not to impact speed when trying to make programmers more powerful. Using HTML impacts speed so should we abandon HTML. My current design is being taken over by another programmer, and it has been very easy for her to follow the code. What I took over was WPF, but must have been done by programmers that are not really WPF programmers. This is not to say that there may not be the possibility of creating anything better. There definitely is, but it would probably be slower. When I have not used the MVVM pattern, I have sworn because it would not have been that much more difficult and would have made it so much easier to enhance the application.
|
|
|
|
|
Clifford Nelson wrote: Personally I find that MVVM done right is so much more maintainable then other options.
I find that most anything done right is more maintainable than other options.
|
|
|
|
|
 Spot on.
#SupportHeForShe
Government can give you nothing but what it takes from somebody else. A government big enough to give you everything you want is big enough to take everything you've got, including your freedom.-Ezra Taft Benson
You must accept 1 of 2 basic premises: Either we are alone in the universe or we are not alone. Either way, the implications are staggering!-Wernher von Braun
|
|
|
|
|
I think your understanding has been hijacked and muddled by entreprisey people!
Go to this simple and straight to the point MVVM introductory article:
MVVM for beginners[^] (shameless plug!  )
(Remark this article focus on MVVM with XAML, as far as I know MVVM with javascript is still possible but more difficult, look at VueJS[^] or KnockoutJS[^])
And then see for your self when and where you want to use it.
"Big debate" around MVVM are misleaded.. It's a nice GUI code simplification tool to use whenever appropriate....
And if it doesn't simplify things then it's not appropriate (for that particular problem), or maybe you are still confused...
|
|
|
|
|
|
swampwiz wrote: MVVM is simply the functional programming paradigm used for the GUI. Is this accurate?
No. MVVM is simply an abstract architectural pattern. A bit of history:
MVC - Model / View / Controller, was a useful concept in the sense that it separated the concerns of:
- model: managing the persistence of the data
- view: managing the display of the data and wiring up the UI events
- controller: the "business logic", if you will, of what to do to the model in response to UI events.
Hidden in MVC is that model events are wired up by the view, so it updates the UI when the model changes.
The theory of MVC is that each could change more-or-less independently of the other to extend the behavior of the initial design.
MVC doesn't work to well because the model is usually more closely tied to the actual database tables handling the persistence.
MVVM (Model, View, View-Model) attempts to correct that by recognizing that there is a model (usually the database tables) that doesn't map well to the UI, hence there is an intermediate "view-model" for how the UI wants to actually display the data. Think of DB views, but you can't use those as the model because DB views are usually read-only.
Note the controller is also implicit in the "view-model."
MVVM doesn't work well either, because really, the pieces that you need are:
DB model - Application model interface. The DB can still represent things in ways the application doesn't and shouldn't care about, for reasons of DB optimization, whatever. So while the two can be frequently combined, they shouldn't. One way to create a nice clean separation is to not directly have the application talk to the DB, but use a middle tier (like a REST service) that knows how to translate between DB and application models.
View model - Application model interface. This is like the "VM", in the sense that it recognizes that even the application model doesn't translate well to what the view needs.
View - controller interface. This abstraction should still be explicitly implemented so that neither the view, nor the view-model, nor the application model, do anything beyond their limited tasks. The controller is where the smarts are, updating the application model, making the necessary REST calls to update the back end, managing caching, other services (via other controllers) that come in to play, etc.
But nobody wants an acronym like DBVAVMVCRAPI
Marc
|
|
|
|
|
I feel I have to offer minor clarifications here. In MVVM, there may be many models associated with a single view. I am not talking about mapping multiple database tables here, although that may be the case. The model is simply something that isn't view or view model. It's common for the VM to coordinate validation from a validation model, with calls out to cache data and so on. These would all be models and the VM is the glue that binds them together. This is because it's an architectural pattern. If it wasn't, then doing things like n tier design would be incredibly complicated.
This space for rent
|
|
|
|
|
Pete O'Hanlon wrote: I feel I have to offer minor clarifications here.
Thank you -- excellent points.
Marc
|
|
|
|
|
Don't really agree with your characterization of what a "Model" is in MVC/MVVM. It doesn't really have anything to do with the DB. There should be a translation layer between the "Model" and the DB as well as between the "Model" and the view. The MVC pattern can be used for both sides.
#SupportHeForShe
Government can give you nothing but what it takes from somebody else. A government big enough to give you everything you want is big enough to take everything you've got, including your freedom.-Ezra Taft Benson
You must accept 1 of 2 basic premises: Either we are alone in the universe or we are not alone. Either way, the implications are staggering!-Wernher von Braun
|
|
|
|
|
TheGreatAndPowerfulOz wrote: It doesn't really have anything to do with the DB. There should be a translation layer between the "Model" and the DB as well as between the "Model" and the view.
Exactly, which is why I came up with the acronym that would never be used. 
Marc
|
|
|
|
|
Understood.
#SupportHeForShe
Government can give you nothing but what it takes from somebody else. A government big enough to give you everything you want is big enough to take everything you've got, including your freedom.-Ezra Taft Benson
You must accept 1 of 2 basic premises: Either we are alone in the universe or we are not alone. Either way, the implications are staggering!-Wernher von Braun
|
|
|
|
|
The 7y/o autistic granddaughter of a close friend drowned just a couple of days ago. During the 10 minutes it took to prepare dinner, she apparently unlocked the door and walked across the street to a neighbor's pool where she had been swimming just a few days before with her mother. Yes, there was a privacy fence around the pool, but the gate wasn't locked.
Please, if you live in a neighborhood with small or autistic children and have a swimming pool, invest in a childproof lock for your pool gate.
I can't imagine what the family must be going through. 
"Go forth into the source" - Neal Morse
|
|
|
|
|
Very sad indeed! ![Rose | [Rose]](https://codeproject.global.ssl.fastly.net/script/Forums/Images/rose.gif)
In South Africa where we used to live pool safety regulations were strictly enforced. Child proof fences with automatic child proof locks on the gates were mandatory. Something we can really copy here in the USA with all the private pools.
Get me coffee and no one gets hurt!
|
|
|
|
|
That IS the law in many places in the US.
There are only 10 types of people in the world, those who understand binary and those who don't.
|
|
|
|
|
The problem with childproofing things is that it engenders a false sense of security. The most important thing is to take good care of your children, and always know where they are.
|
|
|
|
|
Richard MacCutchan wrote: and always know where they are.
Spoken like someone who never had kids. 
There are only 10 types of people in the world, those who understand binary and those who don't.
|
|
|
|
|
Just as I was beginning to gain some respect for you.
|
|
|
|
|
There are only 10 types of people in the world, those who understand binary and those who don't.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
As for the rest... It takes months of practice to be completely proficient writing your own or modify with confidence existing third party directives... 
