C++ Programming for Financial Engineering
Highly recommended by thousands of MFE students. Covers essential C++ topics with applications to financial engineering. Learn more Join!

Python for Finance with Intro to Data Science
Gain practical understanding of Python to read, understand, and write professional Python code for your first day on the job. Learn more Join!

An Intuition-Based Options Primer for FE
Ideal for entry level positions interviews and graduate studies, specializing in options trading arbitrage and options valuation models. Learn more Join!

Reply to thread

Message: <blockquote data-quote="cgorac" data-source="post: 55324" data-attributes="member: 1689">Once again: Qt and Gtk are not relevant for the discussion here - albeit primarily written on Linux, these are multi-platform toolkits. Motif is Unix native toolkit, and it is not replacing Xlib, but complementing it instead - Xlib has no functionality included for creating GUI widgets (Xlib is mostly about dealing with windows, and then basic user interaction and 2D drawing), and Motif is created to support this sort of higher-level functionality.Let me try to clarify my point through an example: If an app is written 15-20 years ago, say that it was about fetching some stock values over the network and then updating some charts on screen, developers would probably use POSIX sockets interface, Xlib and Motif for implementation on Unix, and Win32 GDI and Windows controls stuff plus Winsocks (if they existed at all back at the time - shall I remind you that MS CEO didn't believed in Internet back at the time, so at the end they just had to rip off BSD TCP/IP implementation in hurry) for implementation on Windows. Fast forward to now, and most of the code in Unix implementation is probably the same (OK - Motif part would be ugly, but Unix people don't care much about GUI anyway), and fellow Unix programmers would certainly have no objection to keeping this old code. Windows application would probably get through two or three rewrites: first in C++ with MFC, then some stuff would be changed to make it work with COM, and finally it would be probably rewritten again in C# to use WinForms etc. I'm not claiming that all of these rewrites would be started by rational reasons - oftentimes it's matter of "being modern" hype, but there are other reasons too. Sometimes, new features are just not accessible through old API (see about ribbon example I've mentioned above), and sometimes MS is indeed creating serious interoperability problems between old and new API. Also, if not doing these rewrites - can you imagine your fellow Windows programmer if you show him your original Win32 code? So if for nothing else, you have to update your application just because every time after couple years there is no one else that would understand your code.</blockquote>

Verification