Testing SlickEdit 2014 and I don’t like it

I used SlickEdit Programming Editor until a few years ago when Visual Studio 2012 came out. SlickEdit was quite the only usable development environment in those days because the previous versions of VisualStudio were really a joke, just good enough to manipulate the project file and debug. And that’s how I used SlickEdit in those days, as a text editor only. I did compiling and debugging in VS and editing in SlickEdit because it had macro capabilities.

With VisualStudio 2012 things got better because they added macro capabilities to C++ (before they had that only for C# presumably to coerce people into using that horrible language) and when used in conjunction with Whole Tomato’s VisualAssist, it is actually quite good. The version of SlickEdit I had did not support the new project file format so I gave it up. I tried to use it once again with Ada, but it was horrible with that language so I dumped it.

I gave it another try today because they have a new version. So here is my result.

Working with the new VS project file format works of course, as expected. Compiling from SlickEdit works too. Debugging is not good, especially when you debug multiple projects at the same time as I have to due to my client-server development, but they bring up VS to debug by default, so that’s OK. Editing however is a nono for me. I use namespaces a lot. In VS I can simply drag a classname from the browser into the editor and get a copy decorated with all namespaces, which I need since I dont use “use namespace” clauses. SlickEdit can not do this. You have to remember the namespace sequence and type them in. It brings up context sensitive fragments in a window to presume what you are typing, but this is so slow that you can rather look it up yourself (I have a fast 8 core machine). So this is already a showstopper for me. There is really nothing in SlickEdit that I need that I can’t do in VisualStudio.

I also think they rushed this out. They still had bugreports coming into the forum when they released it and that looks to me like they wanted to push it out the door.

I then tried the editor again with an Ada project. The browser works nice now and the beautifier too, so that’s good. Compiling is also possible, but debugging is a big disaster. I was not able to start the Ada gdb debugger from within SlickEdit and integrate the output with slickEdit so that I could set brakepoints. I also don’t know if it would support the special Ada language features that the Adacore gdb version supports since I could not run it.

So I will stick with Adacores GPS IDE for Ada. I might check out Emacs as a text editor. You can configure GPS so that it opens a file in an external editor, so I will check out Emacs tomorrow since I need an editor with some macro capabilities, to fill out a new file with a skeleton template etc. I am pretty sure Emacs can do that.

All in all, SlickEdit isn’t worth the 300$ they want for it (plus 60$ maintenance contract per year so you get the next major upgrade). I stick with what I have. Shame there isn’t anything better out there, but you can’t always have the ideal solution.

 

Advertisements

First Work With MetaEdit+

I am currently working my way through MetaEdit+

This is a quite sophisticated tool with which one can define a “domain specific graphic language”. What does that mean?

Well, UML for instance is a general graphic language. Supposedly, it allows you to express planning of your program in the symbols and rules of the UML system. The only problem is that UML is very broad and doesn’t really fit all programming approaches. Certainly not the one I am favoring at the moment. UML is some sort of Moloch. It’s gigantic and it is hard to master. I looked into it several times, studied the symbols and the the type of diagrams. I have tools that help with editing UML diagrams and yet every time I decided to sit down and do some planning with UML I ended up in front of an empty screen with the thought “What the hell am I supposed to do here?”

It is my conviction that UML is nothing but a work creation program to keep those people in gainful employment who have studied it so much that they can actually create diagrams with it and who have managed to convince companies, that their work is valuable and irreplaceable. Once you start using UML seriously, you can’t get rid of those people. It is very cumbersome and some diagrams (like the class composition) is nothing but a copy of the actual C++ class definition.

Well, MetaEdit+ allows you to define your own set of symbols and define your own connections between these symbols. In other words, the person using the symbolic language can define it based on the problem he want’s to solve instead of forcing the problem into the fixed symbolic of the UML. Once it is all defined, the language can be used to create diagrams in MetaEdit+ with the build in modeling application.

So, that’s what I’m doing right now, learning MetaEdit+ and actually defining my own symbolism with it. Of course the ultimate goal is to use these diagrams eventually to facilitate Structured Software Development. What I am doing right now is designing my own rules for making a structured design. Why and how is a topic for another post.

 

Starting To Learn The Tools

As my main game project has entered a phase where we have some people testing the bare basic mechanism, I mostly stand by there to fix important bugs, or enter other bugs into my tracking software for later fixes.

My intention is, to use this time to work on another important project which is the improvement of my current debug logging system.

For a while now I have been thinking about ways to improve the day to day debug process. My usual way of working is that I write a piece of code and then run it manually in a debugger and follow each code branch and every step to see that everything works. This is certainly a good way of doing things but it is far from evidence that the code is bug free or even works under most circumstances. When you think about it, it is more a form of calming down ones own conscience.

Given the current circumstances, I will not be able to change the way I work on my current project especially not to a more waterfall oriented development model with more planning ahead before I get into coding. So what can be done to improve error finding?

My idea is, that better logging capabilities will help finding errors quickly. Instead of checking a given error or crash in a JIT debugger, it would be possible to browse through a logfile and trace back what happened and then find the reason for an error. Being able to see that a pointer goes to the wrong memory address is one thing, but finding out why it has the wrong value in the first place usually involves looking back in time and a debugger is only of limited use there.

So I went and wrote a logging system that runs on any machine and the debuggee connects to it and writes out logging messages, similar to OutputDebugString() in Visual Studio, just with enhanced capabilities. The general idea is to log as much information as possible and then, when checking the log output, be able to select certain parts of the output for visualization, while blending out other parts that are irrelevant.

My current logger does that to a degree, but it leaves lots to be desired. I wrote the system in 2013 when I was incapacitated after a hospital stay and while recovering. In order to make things more interesting, I used Ada as the language to implement it, partly because I wanted to check out with this project, if Ada is a possible candidate for more coding in the future.

My conclusion, after the system was finished, was that Ada is fine language, but the available IDE was inadequate compared to Visual Studio so I put that idea aside. However, now that the new SlickEdit version is out with somewhat improved Ada features, I want to give it a new try. The common Ada IDE GPS from AdaCore is not good enough, but I hope that SlickEdit will be. Also, I could use SlickEdit to replace VisualStudio as an IDE for C++ so that I could use the same IDE for C++ and Ada programs which will make things easier.

So this is my plan for the next 2 months, to make a better debug logger. There’s more to the story than just a choice of language and an IDE, but that is another story.

Link Page Added

I added a link page in which I will collect links I consider important regarding the discussion of advantages and disadvantages (obviously) of OOP.

Since there has been quite some debate going on I don’t really see fit to repeat all the arguments here. Instead I think it’s best if you read the arguments on these sites.

Welcome

I wanted to title this post “About Me” but everybody does this, so….

Let’s get the obvious over with first. My name is Patric Lagny and I have been a programmer and Software developer all my life. Well except during my school time of course. After high school I started a lengthy study of Information Technology at the University of Hagen in Germany where you study at home and just go there for tests etc. During that time I was always sidetracked by programing projects, especially in the fields of gaming and simulations. I also made money teaching IT related classes at a public school for adults.

In 1993 I got my first job at a company named “Blue Byte” in Germany that made computer games. I worked on a game named “Battle Isle 2” and later I was put in charge of another game sold as “Battle Isle 3” (you can find traces for both on the internet). Battle Isle 3 was originally planned and commissioned as a Window version of Battle Isle 2 with a few new features, nothing more, but marketing came up with the brilliant idea to market it as Battle Isle 3 since that would mean many more unit sales.

Well it turned out not to be so. The customers were smarter and we got lots of comments like “That’s only Battle Isle 2 on Windows” Duhh… yeah, that’s what it was supposed to be. Well that episode of my life taught me that just lying to the customers without having a product to back up your promises wont make you money in the end.

It was the first or second game that appeared on the market exclusively for Windows though and technically was well made if I say so myself. It ran on Windows 3, Windows 95 and Windows NT 3.1 at the time. I don’t think it runs on todays Windows (tried to install it recently), but I basically learned Windows programming while I was making that game and the experience from that time has helped me until today.

Later I moved to Los Angeles to work for a company here that closed down about a year later. It was one of those companies that lived from one “round of financing” to the next without ever finishing a product. I guess that’s what you call the “Dot Com Bubble” nowadays. After that, I started working on indy roleplaying games .

I have always worked best alone, which is the reason this latest project of mine is taking so long. I suppose I could take in other people to shorten development time, but my experience with volunteers or people working on commission has always been bad. First they are all full of enthusiasm and when you give them actual work to do, they disappear. So that’s why I rather work alone even if it takes longer.

I run a facebook page in which I post about my daily progress in my current project Mikaboshi but I don’t post much in depth technical stuff there, because it is mostly read by players of Sociolotron and I’m afraid if I get too technical I will just bore them. However, I would like to blog about some technical questions that came up over the years, so I finally decided after much procrastinating to make this blog here.

So, what to expect?

Like the title suggests, I have my own ideas about software design and they don’t always go hand in hand with what is taught at Universities these days. I am not a deeply academical or theoretical person. My thoughts about software emerge from 20 years of practical experience. Some of my ideas have undoubtedly been discussed elsewhere without me being aware of it, so I may make a fool out of myself with some points, or maybe not. I have always been fascinated with a description I heard about Allan Turing where it says that he “addressed problems with an enthusiasm as if they had never been addressed by anybody else before him”.

I think that’s what you need to do sometimes, and that’s how I’m going to go about things here. I will just post about problems I have been facing, ideas I had about solutions, practical experiences I got over time and solutions I found in my area for those problems.

I will also post some source code, either here or on sourceforge.net when it is to the degree that it can be used by other people in their projects.

Don’t expect a daily update here. It took me nearly a year to start this blog and I won’t put too much effort in it since my main job is working on my current game project. However, I have a lot of ideas that I’m afraid I might loose sometimes unless I write them down somewhere, so the main reason for this blog is basically that I’m doing it for myself to sort my thoughts, because as somebody once said “unless you have written about a problem, you haven’t understood the problem”.

I don’t expect many people (or anybody for that matter) to read this blog, but who knows. Maybe there will be some people who take interest and perhaps even comment on my posts with constructive criticism.

I would welcome that.