I asked this question on Stackoverflow: here, but it seems no body interests in. I hope I have some answers here, especially from the perspective of programmers who use Linux as a development platform, since I guess most of the programmers in Linux don't like UML and visual representation in general, seeing how the free and open source modeling tools for Linux are so poor and outdated in general.

It has its uses, just like everything else. I don't think it is a question of 'like' or 'dislike'. Methinks you desire for others to change, so that you would need to expend less effort in understanding and working with them. Perhaps, instead, you should expand your own worldview first.

In particular, I think you do not understand the inherent limitations of the object-oriented paradigm.

I'd be very willing to discuss why I choose not to use an object-oriented programming language for most of my projects, and when I do, I tend to skip C++ and use an interpreted language (like Python) instead. However, I have a serious fault: I get furious when I encounter the old, extremely misguided opinion that "current processors have enough horsepower that the small overhead with objects and related structures do not matter". It is not only wrong, but ignores the actual issues.

There is a reason the Linux kernel is not written in C++. Even if it were, it would use its own C++ runtime (which I believe would mean it would be a different language with C++ features and syntax).

I also find quite amusing that you consider Linux modeling tools poor and outdated. I've had to visualize certain damnably complex models, and graphviz blew me away by its simple interface, versatility, and quality.

I honestly do get the feeling that you're really unhappy about the lack of opportunities for your skill set and preferred business models.

Just as you said, everything has its use. However, I don't intend to force everyone to use, but simply asking a solution for a problem. You may not care about modeling business process, but other people do. It's fine if you keep programing in low level forever and doing nothing else (which is good because there's a chance you may become someone significant in society with your knowledge and experience). You may not care, but what if you have your own business? What if you want to run your hobbyist project but don't want it to fail because of management? How do you manage and automated the management with tools in order to reduce your workload? How do you manage the complexity of your project/business? I don't think keeping it in our brain or (a bit better) text file is enough. Here, with the BPMN, I can visualize the process of my business and/or my software project, so instead of reading hundred pages of document, a few diagrams can help to grasp the overall picture of the process.

Programming language, ultimately, is just a tool. Instead of writing machine code, programmers are abstracted with the programming language, and the compiler does the job, as you already know. I don't worship a tool. I just want to evaluate the possibilities of what works best and get the job done in the quickest possible way. Don't get me wrong. It does not mean I don't want to involve in technically challenge tasks, but I would rather use code generation for repetitive code instead of manually typing it and feeling smart. Automated every repetitive tasks in order to focus on the real problem is my goal.

C++ is hated by many people. Object oriented in general (except C++) is hated by many people. But it gets the job done, it is easier to use for lesser gifted people, and good programmers got productivity increase because it is easy to use for them. It's good if you don't have to use C++. But other job requires it. Microsoft and Sony provide only C++ compiler for their gaming platform. What do you do? For serious game programming, C++ is required and the language serves its purpose really well. You can read here to see why C++ is the top choice for this industry: Why C++. But this is Linux forum, which means game programming is not considered to be a serious thing. Not until the X system becomes better for heavy weight graphics. I used Linux for over a year, but I really want to learn game programming. In the future, I may eventually return to Windows. Religions, in any form, are generally bad.

Different programming language solve different problem. I learn a new programming language either for expanding my knowledge, or if my job requires it to solve specific problem which the language is designed for. Graphiviz is good, but I don't think it's for end user. I don't want to waste time on learning another language just for the sake of modeling. I want tool like Doxygen, which uses Graphviz. What free and open source modeling tool do you suggest me to use? In particular, free UML tools are bad and not supported anymore. UML is limited by making itself more coupled with Object Oriented. However, the upcoming SysML is something promising for system engineering. People said it can even replace the UML because it's simpler but more expressive. I will have a look at it in the near future. Eclipse plugins for modeling only supports Java.

Sometimes, real world problems need simpler solutions compare to academic solution. Consider this problem (I got it from the comment Tricky Question (he probably took it somewhere else) in here: The Perils of Java Schools):

It depends on the situation to choose which solution to use. For this simple problem, I and most of people would choose answer (b). Writing (c) does not mean you are smart. But if the loop contains lots of conditions and/or mathematical formula, I would choose recursion.

By the way, to determine someone who is smart or not, please don't judge based on their professions. Smartness does not rely on form, but rather the complexity of a problem. You maybe smart to program real time system, but that doesn't mean a business person is more stupid than you. Not if their brain can manage and process tons of dependencies in a logical, and sometimes mathematical way. One more thing, undereducated != stupid.

Don't worry I'm working in a company which writes telecom software, which uses Linux as a development environment. I am currently studying more about POSIX (aside from my basic knowledge).

Seriously, I used to be a Linux zealot, who blindly thought that Linux is a superior development environment. Not anymore (to be fair, I am more comfortable with Linux environment than Windows, since I am in control of the system more). You're probably right, I need to open my mind more. Please remember, I don't want to force anyone to follow my way, but rather convince them with reasons.

To be honest, I don't think learning something lesser people know will make you superior. The concepts of functional programming does not seem too challenging to absorb. I intend to learn Lisp, but in the future, not now. Still, during the process of learning and using Emacs for my C++ development, I learned quite a few syntax and how it works in general. I will dig into the theory behind it later.

My original intention for opening this topic is not to criticize anyone. I just simply ask for opinions.

In your first post here you stated that "I guess most of the programmers in Linux don't like UML and visual representation in general, seeing how the free and open source modeling tools for Linux are so poor and outdated in general."

Quickly glancing at your post at the other site brings up these questions:

• how do I organize the BPMN with the UML
• What are your opinions/experience on the usage of these diagrams in software engineering process?
• What's your opinions/experience on this issue?

This is the Programming forum. I ignored the first question, because I do not use UML. I've found it easier to use informal flow charts to describe business processes to clients. (Looking back, my clients have had a research, art, or human resources background, so this certainly is a bias on my part.)

The second question: Graphviz, for example, can be used to generate diagrams and charts of very complex relationships, using a language that is easy for those with a programming background to master, and is highly capable. I did find it offensive and irritating that you characterize those as "poor and outdated". (The logic behind it is peer-reviewed, and as far as I know, pretty much the sharp end of the stick.) While it has no price tag nor a glitzy GUI to show to your colleagues, I have yet to see a commercial offering that has even a fraction of its versatility. This is why I believe you have just decided these do not exist, or if they do, they will be inferior to whatever commercial tools you have trained yourself to use.

The third question: Some of the best projects I've ever seen do not adhere to the object-oriented programming paradigm. Most of the visualization tools that exist in Linux are more general, not limited to UML, and not specifically geared towards OOP or object or class structures. It seriously offended me that you directly jumped from the lack of emphasis on UML to "visual representation in general". You obviously are oblivious of Graphviz, and the related programming and software engineering tools.

Just because I do not use formal BPMN or UML, does not mean I don't use visualization tools to model business processes.

I did, actually. (If you suspect I'm confabulating here, just drop me an e-mail and I'll send you the details you can check for yourself. I only ask you to respect my privacy, and either confirm or deny my assertions here, not provide the details to anyone.)

I admit, the IT company I ran (as the CEO) for about six years was really a small-time business -- but we were international and never failed a project. I made a personal value choice a few years back to get back into university, study physics (computational material physics, it turns out) with the intention of spending the rest of my life on what I love -- research, development, and problem-solving -- instead of getting paid a shitload of money. It is not something I recommend anyone else to do, but it was something I felt I needed to do.

I am, and have always been, quite sensitive to perceived injustice and unfairness, which in real terms makes me unsuitable for a business role. (Not because a business person cannot be just and fair; they can, and I know a few; but because there will always be those that are not, and you must be willing and able to handle them.)

I used a number of tools, whatever I found worked best.

I found I could use a spreadsheet program (Excel at that time) to handle my project timelines and team allocation.

On the software side, I've never felt the need for a formal approach, mostly because a formal approach would have been too rigid for my clients. When the funding was by a governmental organization or by university, the contract language provided fixed boundaries (learned that the hard way, btw). Prior to signing, I would personally spend a dozen or two hours to design a rough outline, presenting only the user-facing issues to the client. It is a risk I chose to take. Most of that would be paper-and-pencil sketches, but anything formal I'd draw in a vector graphics program.

I've tried Dia a few times, but it just feels a bit too clunky for me. Inkscape I like, especially with a suitable grid to snap to.

It might be interesting to leverage DHTML and the DOM support for SVG objects in browsers for something like diagramming.
Actually, that is not true. Very few languages are fully compiled anymore. C++ for example has a pretty hefty runtime. It is the features of that runtime, for example the implementation of exception handling, which makes it unsuitable for e.g. kernel work.

One of my research interests is to make distributed and parallel simulations more efficient.

Abstractions are only useful when they make the overall task easier. The systems we have are already so complex that it is the interactions between features and abstractions that cause many of the hard-to-overcome problems. For example, most simulators currently eschew threads, opting for a process model instead. The main reason for this is that without careful consideration for the hardware cache architecture, a threaded simulator using exactly same algorithms and hardware resources than a process-based one, will be a fifth to a third slower (due to cacheline ping-pong and lock overhead).

While simulators are a very domain-specific problem, do realize the number of embedded devices that are created and developed now. Already, phone application development is a serious business for many independent software vendors.

You might think that throwing more hardware will solve all software problems, but the fact is, thermodynamics alone place limits on that approach. Flipping bits will always require power, and that power will be dissipated as heat.

We are resource-limited, whether you accept it or not. Our programming practices should reflect that.

Most of the hate I've ever seen or felt toward either is directed to specific features or problems, perceived as bad enough to use something else. Most of the hate or disdain directed towards OOP or C++ proponents is because they do sometimes look like it is the only tool they have, and are therefore trying to twist every problem into something that is best solved using OOP.

For example, look at the struct file_operations in the Linux kernel. It is a structure that is used to define and interface a char driver to userspace. Many other such structures are used throughout. Why? They're certainly not traditional C; some of the structures might not even compile on a non-GNU compiler. Why is this? Simply: Because it gets the job done best, not because it is dictated by the paradigm.

Many C++ features are nice, but some of us just feel the drawbacks don't offset them enough, and prefer other tools.

OOP is actually very well suited for games and UIs, I think. Just look at Supertux2.

I'd personally never write an UI in C, for example. I might skip C++, though, and use Python instead.

I beg to differ. (Except that X is old, and does not suit our hardware anymore. We'd be better off with framebuffer-based devices, even for nonlocal displays. Wayland might be a solution, but we'll just have to see. Fortunately, development continues.)

And I guess these games do not exist, either? Nor these?

It is true that the Linux kernel developers made a grave error years ago, when they let video card manufacturers to provide binary-only drivers. Quality-wise, they're utter crap. Some of them work well for some people, but to a serious developer, they're like an outer-space alien standing in the background. It might not bother you, but you get these weird, weird interactions nobody can really figure out. (That's why we have the 'tainted' flag in the kernel. Not because of any ideological reasons.)

The last time I regularly used Windows, it was still not stable enough to stay up a week, let alone a month. With that kind of (lack of) stability, users don't care if their workstation locks up or has to be forcibly powercycled every now or then, it becomes part and parcel. Who knows how much of that was due to buggy graphics card drivers? (Based on what I've read, quite a lot. Enough to bug Microsoft engineers, too.) Are Windows users still willing to trade stability for graphics features?

Nowadays the situation is extremely difficult due to patent and IP wars. The devices are complex, and developing the drivers is not just frustrating, but ultimately very unrewarding.

So yes, Linux graphics subsystem is a problematic area. I personally happen to be quite happy with my integrated AMD HD3300 with open-source radeon drivers -- the games I like are nice on it, and I can play back any media I want, unless the copyright police find out I play media I own on this Linux machine and throw me in a dungeon --, but it is lightyears from top of the line graphics hardware.

That's the viewpoint difference right there. In the FOSS world, there are no end users. Not in the same sense.

In the non-FOSS corporate software world, you have vendors, clients, and end users. Clients are the businesses who need the tools, and end users are those who use the tools. Vendors provide the tools, sometimes/often working with the clients to enhance and fix them.

To the FOSS world, this view is incorrect. It is wrong in the technical sense, not in the value sense. Software projects are hierarchical, meritocratic communities, where your needs are only important to yourself, unless they impact, affect, or coincide with the needs of other members. It simply works by different rules. Indeed, an average developer is quite low in the hierarchy, too; a good tester (that can identify and pinpoint bugs) or user interface specialist (that can show easier and better ways to use the tools) are often more important to the community. (Yes, I am crudely hinting that programming is by far not the most influential role one can have in a FOSS project.) None of this precludes doing lucrative business. You just might have to learn new ways to do business first.

I would like to point out that the Linux kernel, the Apache server project, the GNU toolchain, and Mozilla Firefox are excellent examples that this world does work, despite the enormous indirect financial pressure from large multinational companies. (Currently, software patents and the threat of expensive litigation are the preferred weapon.)

Apache license for example does allow the development and distribution of commercial, closed source derivatives, but they all died out years ago. The web server survey is certainly something to ponder.

The correct answer is, of course, that either you develop it yourself, or you pay for someone to develop it for you.

Because this is the FOSS world now, that does not mean you have to pay cash money, nor does it mean you have to learn a yet another language. If you apply your experience, and describe what the tool would have to do, and how that will help others working with software modeling or engineering or whatever you find important, you might find someone who has the effort to spare for the development, but lacks the experience and design skill to apply to it.

Just for a trial run, why don't you start a new thread here, and describe how and what that ideal tool -- or actually its first prototype -- should do. If it does, as you imply, help so much in business process modeling or software engineering, I'm sure many others would like to use such a tool; at least one of them should have the skills and time to start coding it.

If you are unwilling to devote any money, time, or effort for such a tool, then you are just another greedy bastard complaining about other people not giving you a share of their hard-earned resources.

If you feel I have slighted your intelligence, I must apologize. I have mentally ascribed to you some attributes I do not find admirable, but I have not made any assumptions about intellect or capability. If there is a passage where you feel I have implied, in any way, or accused anyone of lacking capability or intellect, please drop me a private message pointing it out, and I'll try to fix it.

What I admit to, is implying you lack effort and willingness to cross your comfort zone boundaries.

1 members found this post helpful.

It seems like you're a veteran in software industry already, and your experience is at higher level than me. Still, I will still voice my ideas and opinions, because nothing is perfect after all.

I did not intend to include Graphviz to be a modeling tool, but instead a library/framework to work with. To me, a modeling tool need to have a GUI for the user to interact visually with. Using text to visualize seems awkward to me, since you have to visualize in your mind what you want to model. Imagine a graphic designer, instead of using GIMP. he uses a scripting language to draw?

Process visualization can be very simple, sometimes it only needs boxes and arrows to draft and communicate ideas. However, the problem arose when the visualization needs to be documented. Different people use different ways to visualize business process, and later the other people rather than the ones who involve can't comprehend the diagram. Thus, the need for a unified modeling language as a tool to communicate. Some of those modeling tools are BPMN and UML. It may not be universal yet, but I do think its motivation is correct and valid. Still, it needs time for people to accept and it needs time for evolving to satisfy more real world requirements. Most importantly, its motivation is good. Without the diagram, the traditional way is to write text document, which costs more time to produce and take more time to read as well.

It's ok. I can see how you are through your post. I don't want to involve the confidential information of unrelated business, as it will endanger both of us.

This is my aim as well. I intend to save up money for more education for better understanding the world. The problem with small business is that if it does not evolve, most people will perceive it as no future and leave soon enough, since most people want fame and money, and serious research should be performed in University, Institute or Huge Corporation, since they have a lot of resources (but climbing the ladder high enough to have the right to use the resources is another story).


What I want is far more than just drawing. One of the feature is something like this: Round-trip engineering. Sadly, UML Lab is only available for Java, and is expensive. The best tool I found so far, in terms of price and value, is Enterprise Architect from Sparx System. The tool helps us to manage from business process down to implementation and deployment. It helps such tasks be automated, and it enables collaboration between people in the team (through its server). The tool is available for many other OOP language rather than Java, such as VB, C++, Delphi. With feature such as round-trip engineering, whether I want to code, it will be reflected to the model, and if I am unsure and want to having an overall picture, I work on the diagram and it will generate the source code for me. Very convenient.

The old and persistent problem with UML is that the design had to be kept in sync with the actual source code. If it can't, the design became useless, thus wasting time and effort (also, it's not true for higher level diagram such as use cases, since those artifacts stay more statically through the development process than artifact like class diagram). With the help of tool, this problem is fading away.

As I said, use the right tools for the right jobs. Some people hate it for no reason, just because it can't use the tools doesn't mean it is bad and should be bad (well, look it another way, it maybe a valid reason, since if it makes our jobs harder, why not hate it. However, not for the case the right tool is used for the right job).

The games you listed, except for the 3D Games (which most of them are first person shooter), the other games are generally not interesting. Flash games, which are more popular than the native games in Linux, since it's cross platform, easier to use and do not require strong graphic capacity, have more interesting games. Since I'm on Linux most of the time, and I don't have much time, I usually play Flash games as an alternative to Windows games. Still, the performance of both Flash games and 3D games are not as good as in Windows.

Ok, it's good to know the alternative. I will learn this. However, I don't think today programmers only need programming skills alone. Other skills, whether in Computer Science, and/or Software Engineering (as defined today by IEEE and by NATO conference in 1968) is needed.


Yes, there's high chance I will pay money for Enterprise Architect, because they produce good piece of software which meets my need as well as many corporates. Of course, I can't complain about the open source project, since it's not for commercial but for the sake of community. If I'm lucky, I have something good like Apache or Firefox or Eclipse... Otherwise, when I'm out of possibilities, it's time to look at the commercial alternatives. As you suggest, I will experiment with the tool and methodology, then make a thread to discuss this topic, so everyone can share ideas and learn (unless everyone already knows and does not care, I won't waste everyone's time).

It's fine. Generally I'm not strict on this one, especially if you realize the problem. I (and most people), don't like elitism which suppresses other people's opinions.

Good; they are always welcome. Opinions, too, but unless you back them with research, people like me are likely to bite. (That does not mean I think I'm right, only that I need to know the basis of the opinions. I'm quite often wrong myself.)

Dot, the language Graphviz uses, is a graph description language. You do not use it to describe the layout or visuals, you use it to describe the models the visuals are intended to represent.

One graph I created was a complete link map of a large website. I didn't even write the Dot for it; I used wget and a PHP script to crawl all the pages, and output the relationships in Dot.

The true power of Graphviz, elaborated in the Theory section at Graphviz web site is that it can draw the graphs based on just the logical relationships, with zero visual or layout help at all.

That is a bad example, since we do have GIMP and Inkscape for just that.

However, consider POV-Ray. It has been, and is, used by a number of artists to describe 3D objects, views, and sceneries using a programming language. For an example, see Bonsais.

I myself don't write POV-Ray scene descriptions, but I do use programs that generate scene descriptions that POV-Ray will then render.

Remember what I wrote above about modularity? I'm trying to show that there are a lot of excellent tools that can be used. Just because they're not wrapped in a simple but effective GUI you like, does not mean they're poor or outdated. I'm trying to tell you that if you can describe how you would like the tools to work, and how using the tool will help you and others in a similar situation, you have a very good chance to develop that tool yourself. This is what FOSS is. You do not need to invest money, or start programming yourself, but you must provide something useful to others so that you get the human resources the tool needs to become real.

Most FOSS tools are oriented to work backwards compared to that: you describe or document the thing first, then you create the visualizations based on the description. Those graphs should be in a portable format, for example SVG, so that you can take a generated visualization and finesse it to publication quality if you want.

I can see why that would be useful. Other than the type of programming language parsers needed (that provides the code as mutable strings as well as an AST), I can see no great difficulty in implementing something like that. If you like, I'll happily elaborate on the details.

Quite. Tools like Doxygen keep the metadata within the code, making it much easier for programmers to keep it up to date. Assuming you had an editor with a language parser for Doxygen support, you could have the editor automatically modify the Doxygen metadata.

For the visual graphs, it would be best to use a separate file for layout specification and business process annotations. When no such annotations are needed, that file can be omitted, and something like the Graphviz layout engine used to generate a default layout instead.

For library documentation, you could use a separate file (in XML for example) that only contains the additional descriptions and annotations not included in the Doxygen comments in the code. The dynamically generated actual documentation files themselves would be a combination of the two (or three, if you count any embedded visual graphs of the code).

Perhaps. I don't play games much; mostly Supertux2 custom levels, Frogatto, Magicor, Super Maryo Chronicles, Mahjongg, Sudoku, Mines, and Aisleriot Solitaire. Some of them are visually very good -- for example Frogatto -- but mostly it's about the gameplay.

New browser technologies would have been adopted faster, if we didn't have one throwback in the mix (you know the one). Lack of SVG support alone was driving me crazy. If we get SVG DOM support widely available in browsers, you could do Inkscape or graph editing directly in a Web browser. While most web editors are still stuck in the same "type the stuff into this box" paradigm, we could just as well use full WYSIWYG interfaces for web page editing. The Mozilla Demo Studio is a good starting point.

Games are one area where high level of abstraction and abstract libraries (consider Box2D for example) is a good, important thing. Currently, Flash is more full-featured, but it is possible we end up developing something better. In handhelds, for example, Qt + OpenGL ES 2.0 is much better (power consumption and CPU efficiency); Flash being a severe drain on the battery.

At this point in time, Linux graphics development is severely limited by hardware manufacturers reluctance on opening up their hardware programming interfaces. A major reason for this is that competition is severely restricted by threat of litigation, software patents, and poorly defined "intellectual property" threats. We have large internationals and "cartels" (perhaps not cartels in the legal sense, but certainly in the objective sense due to cross-licensing and exclusive marketing agreements) that use the legal system and financial political pressure to restrict or even eliminate competition.

It is quite possible that this situation will not change before graphic devices grow rudimentary kernels providing the type of security partitioning and memory management available in non-Windows systems. I'm very interested in how Raspberry Pi fares. It's graphics system is more or less a separate CPU, running a proprietary firmware, but it provides an OpenGL ES 2.0 and OpenVG interfaces and a full-HD H.264 video decoder interface. If there are no black-box bits on the kernel CPU, this may be the approach we'll have to accept and adopt. (To me, a separate processor running closed firmware is not optimal or preferred, but is acceptable.)

I emphatically agree. Engineering brings dicipline to the programming process. We also need some arts and human sciences to develop sensible, workable interfaces.

I've always preferred teams with eclectic backgrounds to consummate professionals of a single domain. To me, many seem to have a very limited set of approaches to a problem, and this weakens the solutions in my experience. Problem solving is an evolutionary process: the more ideas you have to work from, and to weed out, the richer the process, and the better the final approach. I'd say only logic, and the skill to understand and develop new algorithms, are paramount to a programmer and to a team leader.

That is a very good idea, and I wholeheartedly recommend you do so. I for one would be interested to participate (with a much friendlier attitude, too).

If I may suggest, you might first work out a use case. If you have the experience, describe exactly how the tool would work, and why the tool would be better than the alternatives.

Good. I do have a habit of being harsh when I perceive people to not apply themselves to their full ability.

1 members found this post helpful.