I don't want this article to be too abstract, I know that I assume that people know what ECS is (It's not an article about explaining it), but nevertheless I need to know if I face things so abstractly that is hard to see how they are applied in real life. I will gather more significant anecdotes before to publish it.
Now take care Object-oriented Reactive Programming is not Reactive Object-oriented Programming there is a big difference between those two you need to decide which you are doing and the difference between them.
The Observer pattern addresses the following problems:
- A one-to-many dependency between objects should be defined without making the objects tightly coupled.
- It should be ensured that when one object changes state an open-ended number of dependent objects are updated automatically.
- It should be possible that one object can notify an open-ended number of other objects.
Now in programmer jargon speak we call observer pattern programming as "Omnipotent god programming" because there will exist an object or function that observes and controls everything. It is often used in games programming but it is not well suited to real world situations where you can't encapsulate all options and you need to "think" about what is going on.
As an example DNS attacks on websites work because they break the observer pattern of the internet standards .. to deal with the attack you need to know past history and apply some logic
Computer languages encapsulate precise physical concepts, english language encapsulates wide range communication.
It is never the language describing a problem that is the issue it is describing the process in terms of a physical concept the CPU can execute as code blocks.
For perspective you could write a book claiming all you need is a screwdriver, spanner and hammer as tools and you can fix anything. Whilst you can probably tackle a vast range of repairs there are jobs that require highly specialized tools that you simply couldn't do. Plain English Programming falls into the same fallacy you conceive situations it might work but you have to close your eyes to the situations it clearly won't.
I suspect the only way to really go after a real concept of english language programming would be via AI and if you went that path specific jargon would be less verbose, clearer and not prone to stupid English language nuances. Take any scientific field the first thing we generally have to do is butcher English into a series of defined jargon and acronyms so we can all agree on what is being said. Read any science journal or book and it isn't english a layman would recognize you need to know what all the jargon and acronyms mean. So I put the chances of any serious programming in english language at close to zero because we can't even do it with science.
On top of everything leon already said, natural languages are too ambiguous to be used as a computer language. The exact meaning of everything you say depends on the context as much as who you're talking to, and often can only be interpreted correctly when also analyzing your gestures and mimics. A simple wink in the context of some statement could mean a world of a difference.
This is the main reason why we misunderstand each other so often in written communication.
Given that high chance of misunderstanding, I'd rather not use a software system that is prone to doing something entirely different than what I intended. If I tell it to "Go to hell" I do not want it to query TomTom for directions. And if I tell it to "Let's eat grandpa!", I better not forget that all-important comma: "Let's eat, grandpa!"
GOTOs are a bit like wire coat hangers: they tend to breed in the darkness, such that where there once were few, eventually there are many, and the program's architecture collapses beneath them. (Fran Poretto)
I have MDI MFC application. For a particular child window, i want to split in to two. Already i have toolbar for topview by using OnCreate() in ChildFrame.cpp. I want to add toolbar for bottom view also.
ChildFrame OnCreateClient() code:
BOOL CChildFrame::OnCreateClient(LPCREATESTRUCT lpcs, CCreateContext* pContext)
// TODO: Add your specialized code here and/or call the base class
if(iWindowNumber == 4)
if (!m_wndSplitter.CreateStatic(this, 2, 1))
if(!m_wndSplitter.CreateView(0,0, RUNTIME_CLASS(CTrendView),CSize(cr.Width(), cr.Height()-200),pContext)||
!m_wndSplitter.CreateView(1,0, RUNTIME_CLASS(CTrendListView),CSize(cr.Width(), cr.Height()-550),pContext))
return CMDIChildWnd::OnCreateClient(lpcs, pContext);
In OnCreate(), im loading toolbar, but it adds only for TopView. I want to add different toolbar for bootmView. Can we add toolbar using CView::OnCreate()? i tried this but it is not happening.
Otherwise i have to create 3 splitter window, middle winodw will have toolbar buttons that can be added using CMiddleView::OnCreate().
How can i get that?
I saw that one show CFrameWnd. My window is CMDIChildWnd. So i didnt try first. I tried now. i create CSPlitFrame as CFrameWnd and i coded like below. But when i want my particular window , it shows error on calling that view in Mainframe.cpp.
In order for a Malware Analyst to be able to read the malware code, they will need to disassemble it. Unfortunately, the highest language derived from binary code is Assembly, which is the last level of human readable code. Therefore, it is imperative that a would-be Malware Analyst, also learn how to read and write Assembly code.
Maybe you want your code to be very efficient (very large program, or very minimal computing resources?).
It is extremely common on hardware interface code, context switching and sensitive task and API areas because there are very exacting requirements that can not be described by a language even as low as C, much less by a high level language.
The last time I uses anything that low level was to optimize some functions for SSE. Several years before that it was to modify the boot loader in an embedded system.
In the late 1980s and early 1990s, I spent the first three years of my career writing the main product code in assembly (6502 and then 8086) with C for the utilities. The benefits in size and speed were enormous. By the late 1990s, that benefit had shrunk. Even in the embedded space, costs of assembly (mostly time) usually outweigh the benefits.
Last Visit: 31-Dec-99 19:00 Last Update: 18-Jan-22 20:59