Technical Debt

[RichAlgeni]

Very interesting article:

http://swreflections.blogspot.com/2012/ ... eally.html

I'd say PureBasic's technical debt is very low, because of it's ease of use, rising some only because it is not very widespread.

The author is surprised that Java's technical debt is so high. On the contrary, it's very clear to me that Java and .Net have a very high technical debt, as the amount of code needed to run a process compared to PureBasic is so much higher.

Thoughts?

[c4s]

Interesting blog and article. Thanks for posting it!

[RichAlgeni]

You're very welcome!

Sometimes we don't think of things in these terms, especially when it comes to middleware or run-times, like Java or .Net.

[Danilo]

What has this article to do with PureBasic?

• errors/mistakes in the software architecture
• missing automated testing
• code that mysteriously works but you don't know why (many people here cut & paste the codes from the forums without understanding it, especially the ASM codes)
• error-prone code, bugs
• out of date (user-)libraries (typical PB problem)
• inconsistent use of patterns
• missing or poor error handling and exception handling
• hard coding, magic numbers, ...

IMHO this has exactly *nothing* to do with PureBasic because it is about
totally different programming systems used for large scale software projects.

How many PB users do automated testing or planning a software architecture
before they start? Error- and Exception handling, patterns, ... many PB users
never heard about those things.

So what do you really want to say, RichAlgeni?

[Blood]

I'd say PureBasic's technical debt is very low, because of it's ease of use, rising some only because it is not very widespread.

Technical debt has nothing to do with a language but how maintenance and refactoring is done and the problems (usually time related) associated with it.

[RichAlgeni]

First, I'd lay off the caffeine Danilo.

Second, I was trying to show that there may be a quantitative way to show the differences between PureBasic and .Net or Java.

It used to be that 'no one ever got fired for buying IBM.' Now it could be said 'no one ever got fired for using .Net.' Well, there's other ways to judge this, other than just deciding to do what everyone else does.

Technical debt has nothing to do with a language but how maintenance and refactoring is done and the problems (usually time related) associated with it.

Nothing to do with a language? Nothing? It's almost all to do with the language! How hard it is to maintain, what platform does it run on, does it need a runtime? All of these are dependent on the language. Danillo and Blood too quickly dismiss ease of use when it comes to maintenance and refactoring.

In my opinion, you could bring PureBasic into a large shop, use it in many ways, and be successful.

[Danilo]

I agree, RichAlgeni: PureBasic is easy to learn and the learning curve is very low.

For a C++/C#/Java guru those languages are also easy to use. I agree again that
the learning curve for those languages is steeper. They include much more features
and support the object oriented programming paradigm.
When learning PureBasic, it is not required to learn about operator overloading,
templates and patterns.

I can not agree when it comes to maintenance and refactoring. The features and
stability of the other languages make this easier, so it could easily be the opposite for PureBasic.
I think you will see the effect better for large sources. Even more if you come back to
a source after 2 years or you get a project from another programmer.

Old sources don't work anymore because PB always changes. Old user libraries are
out of date very often. A procedure with ASM just doesn't work anymore and you don't
understand what the ASM guru wrote few years ago. Missing or poor error handling
is very common. The whole structure of the source is very different for every programmer,
you basically just get a bunch of procedures, structures and constants in a global naming space,
no modules, classes and namespaces for structuring big sources.

Even worse:

Code: Select all

EnableExplicit
Global height.i
Global height.i

This is very dangerous, the compiler does not give a warning or error that the variable
is already declared. Such flaws in the language/compiler help you to introduce hard to find bugs
if you declare a new variable that has already been used before in another include file.
The bigger the source gets, the more such flaws may become very disturbing.
You have to be very careful and disciplined when it comes to coding style, whereas other
compilers/languages help you actively to prevent such errors.
It is a bad thing to use global variables, i know. But you have to admit, it is commonly used PureBasic style.


There is no support for refactoring in the PB IDE. Visual Studio programmers use special plugins
most of the time to speed up development time and refactoring time.
Visual Assist X and ReSharper are common examples for tools that boost your productivity dramatically.
The IDE and tools are very important (key factors) when it comes to maintenance, refactoring, productivity... = technical debt.

While PB is easy to learn, it has also its problems when it comes to more 'advanced' features,
long time maintenance, refactoring and large sources. Just ignoring this problems and say PB
is better than all other languages and systems doesn't help much in my opinion.
Maybe it is better to admit, talk about, and address this possible problems.

[RichAlgeni]

It's hard to say one is better, they all have advantages and disadvantages. Not that PB was necessarily better, just had a lower technical cost in some ways, in my opinion.

As far as OOP, I've never been a big fan of OOP, I still think it's overrated some. In fact, I like global variables, especially for program control. Otherwise I think the code I write is more 'functional' in type.

I haven't used refactoring tools, besides my own knowledge and experience. I've tried to make a number of small, portable modules that I use as includes or dll's.

I can understand why some could be reticent about base code changes, hopefully that is in the past now with PB. I haven't experienced that yet. The only assembler I have used has had to do with hashing.

I've used runtimes before, and I don't like them. Ok, personal preference, but for those of you who use Java or .Net, how many times have critical patches come out in the past year or two? For me, this is a big cost.

So, in summary, there are advantages and disadvantages to all code. Each of us has to determine what those costs are, and what they add up to. There is certainly more I'd like to see in PB, but I think it's on the right track.

[IdeasVacuum]

In the same way that RichAlgeni is looking on the bright side of PB, you are doing the same for C++/C#/Java Danilo! Indeed, some of your downside points about PB can apply to any language. "How many PB users do automated testing or planning a software architecture before they start?" Same can be said for Users of other languages - it's the developers, not the language that's at fault. Similarly: "You have to be very careful and disciplined when it comes to coding style" and "Missing or poor error handling is very common". I see poor error handling and lack-lustre coding style in C/C++ code all the time! I use C# when I have to but I find .Net to be very cumbersome, as is Visual Studio really - I know many developers who, like me, write their code with a better editor and only use VS for debugging and compiling. A good developer should not need a re-factoring tool, but the use of a better IDE and productivity tools is open to the PB developer too.

Concerning the languages rather than the developers "flaws in the language/compiler help you to introduce hard to find bugs" - that's a feature of every language and every compiler, bar none. I know countless numbers of developers who have the grey hair to prove it!

Nothing is perfect. There is no such thing as a perfect language, perfect compiler, perfect code or perfect developer. In my experience, PB holds it's own very well. For me it's Technical Debt has been lower or comparable to my C/C++ work. In the past year or so I have lowered the Technical Debt of a large C++ project by supplementing it with PB code (consisting of separate executables). At the end of the day, it's all about 'horses for courses' - Sir Clive Sinclair once tried to explain a data recorder spec to Sir Alan Sugar. "I don't care if they have rubber bands in them" replied Sugar, "as long as they work". Touché.

[Danilo]

In the same way that RichAlgeni is looking on the bright side of PB, you are doing the same for C++/C#/Java Danilo! Indeed, some of your downside points about PB can apply to any language.

You are right, IdeasVacuum.

- I read the original post like "look there, Java and .NET have this problems and PureBasic does not have this problems".
- RichAlgeni asked: "Thoughts?"
- I gave some thoughts: PB has the same or other problems. It is not superior to all other languages/systems.

You see posts like
- "PB is superior to everything, why do other languages still exist?"
- "Why don't all developers in the world use PureBasic?"
from time to time here.

Those are questions and we discuss it. If somebody just wants approval that PB is superior
to everything else, it would be better to not ask such questions...

If you look at one side of the medal only, I show you the other side.
I like to do that because i think it is important to know both sides of the medal.
The outcome would ideally be that it makes you more open minded and irrespective
if you think about both sides. I hope you understand what I am trying to say here,
I just can't articulate well in English.

So it can happen you don't like my answer and opinion to such question. Just hate me
for not telling you what you want to hear, no problem. Somebody has to do the dirty work...

[RichAlgeni]

I think you articulated it well Danillo, better than I could in a foreign language!

And nobody hates you! In fact, a calm objective discourse can only help PB! I'm sure Freak and Fred appreciate a calm discourse!

Remember too that everyone's perception is colored by their past, and in my past was a language runtime that did not scale well, used a lot of memory for the simplest tasks, and did not thread. So when I found PB, it was, at least for me, and epiphany!

Rich