The Joys Of Programming

I did some work for a client that had old vb6 and .net 1.1 badly designed asp.net code. I did a short engagement then kicked them to the curb when I was finished. Some things aren't worth the headache.

If nothing else, the lack of 64-bit support in 6.0 is going to cause problems at some point. But upgrading from 6.0 to 20XX really shouldn't be too hard. The bulk of issues you'll run into are with illegal template code that compiled under 6.0 but doesn't compile under 20XX, and most of those changes are pretty mechanical. I never ran into any differences in, say, which specialization of an overloaded function was picked by one compiler vs. the other or anything that would similarly cause invisible changes in behavior.

complexmath wrote:

If nothing else, the lack of 64-bit support in 6.0 is going to cause problems at some point. But upgrading from 6.0 to 20XX really shouldn't be too hard. The bulk of issues you'll run into are with illegal template code that compiled under 6.0 but doesn't compile under 20XX, and most of those changes are pretty mechanical. I never ran into any differences in, say, which specialization of an overloaded function was picked by one compiler vs. the other or anything that would similarly cause invisible changes in behavior.

Are you programming Mega Man?

Garden Ninja wrote:
complexmath wrote:

If nothing else, the lack of 64-bit support in 6.0 is going to cause problems at some point. But upgrading from 6.0 to 20XX really shouldn't be too hard. The bulk of issues you'll run into are with illegal template code that compiled under 6.0 but doesn't compile under 20XX, and most of those changes are pretty mechanical. I never ran into any differences in, say, which specialization of an overloaded function was picked by one compiler vs. the other or anything that would similarly cause invisible changes in behavior.

Are you programming Mega Man? :shock:

Best of all possible universes?

Bonus_Eruptus wrote:
Garden Ninja wrote:
complexmath wrote:

If nothing else, the lack of 64-bit support in 6.0 is going to cause problems at some point. But upgrading from 6.0 to 20XX really shouldn't be too hard. The bulk of issues you'll run into are with illegal template code that compiled under 6.0 but doesn't compile under 20XX, and most of those changes are pretty mechanical. I never ran into any differences in, say, which specialization of an overloaded function was picked by one compiler vs. the other or anything that would similarly cause invisible changes in behavior.

Are you programming Mega Man? :shock:

Best of all possible universes?

All of Dr. Wily's robots are programmed in Java. True fact.

tboon wrote:

To answer your question more directly: it depends. If something works, why touch it. If the cost to continue to make it work reaches some threshold (being intentionally vague here ) either an update or replacement should be planned for. Sadly, in my experience, even if updating is planned for, something "more important" always comes along. You really need strong technical leadership to go in and fight for the time to keep the company's product up to date.

If I can be guaranteed to not have to touch it, then I am fine with not changing it. Sometime there is some old code that everyone says works and they don't need to change it, but it made some design decisions that data would be in a special format, or that you need to talk to it a certain way. This then forces you to do things in ways that don't make sense with modern technologies but in order to be compliant with this old "working" code means writing new bad code.

These arguments have been helpful though. Thanks everyone. I am going to start looking to see how often my code is effected by these old pieces of "working" code to see how often the "if it works don't fix it" view actually makes things worse.

That line is in a different place for everyone. If you can prove that it's biting you, you might get some traction.

In my case, our production environment is those antiquated technologies, and we're required to keep them because they're government contracts. We can't just willy-nilly move forward. I still have to support Netscape 4.78, for crying out loud.

momgamer wrote:

That line is in a different place for everyone. If you can prove that it's biting you, you might get some traction.

In my case, our production environment is those antiquated technologies, and we're required to keep them because they're government contracts. We can't just willy-nilly move forward. I still have to support Netscape 4.78, for crying out loud.

I believe I have located hell.

When management wants to cut costs and use currently outdated or outgoing tech (or jut be cheap), I feel like I'm fighting for those years down the road where someone (maybe myself) will have to support them and keep them online.

Garden Ninja wrote:

Are you programming Mega Man? :shock:

I ported a 6.0 project to 2003. Just haven't used Visual Studio since then, but I assume the same holds for 2011.

complexmath wrote:
Garden Ninja wrote:

Are you programming Mega Man? :shock:

I ported a 6.0 project to 2003. Just haven't used Visual Studio since then, but I assume the same holds for 2011.

Yeah, if I understand your previous post correctly you are saying it converts up pretty well. And it does. Other than the bad habit sort of things that 6.0 allowed. We just went through the conversion and while we are still hammering things out 4 months later, 95% off the bugs are caused by the code doing stupid, idiotic, things that somehow worked before.

bandit0013 wrote:
momgamer wrote:

That line is in a different place for everyone. If you can prove that it's biting you, you might get some traction.

In my case, our production environment is those antiquated technologies, and we're required to keep them because they're government contracts. We can't just willy-nilly move forward. I still have to support Netscape 4.78, for crying out loud.

I believe I have located hell.

No, Hell is where I get to work a compromise into a single codebase that supports everything from there to IE10 & Firefox 15.0.1. Namely, next week.

I can't blame you for being scarred by Java.

It happens, man.

I ended up going with Python and started a class with the University of Toronto along with the Code Academy Python track. So far, I'm enjoying it. Some of it I remember from college and Java and some of it is new. So far I really like Python compared to Java.

Anyways, I found this Python visualizer that I wanted to share with you all as it's really helping me debug code and see how things are working. I hope this helps you out.

Also, whoever recommended Practical Programming: An Introduction to Computer Science Using Python, thanks. It's a great book. I'm actually enjoying this unlike doing Java in college. I swear I had programming PTSD or something.

That visualizer is pretty cool.

While certainly not as handy as the visualizer, if you want to check variable assignment and values at various points in your program you can use pdb.

Last month I had to deal with a hellish merge from a release branch, into Main, then into Dev. We had a ton of conflicts because in addition to bug fixes in Release and normal changes in Dev, Dev was also in the process of being reorganized. It took me a week to deal with them all.

Nothing has been pushed into Main in the last month. This morning, I start the Main -> Dev -> Main merge and a bunch of the conflicts I already dealt with showed up again.

f*ck TFS.

Edit: after thinking about it for a bit, I realized that we never pushed Dev back into Main last month, so this is actually user error. Oops. TFS still sucks though.

Garden Ninja wrote:

Last month I had to deal with a hellish merge from a release branch, into Main, then into Dev. We had a ton of conflicts because in addition to bug fixes in Release and normal changes in Dev, Dev was also in the process of being reorganized. It took me a week to deal with them all.

Nothing has been pushed into Main in the last month. This morning, I start the Main -> Dev -> Main merge and a bunch of the conflicts I already dealt with showed up again.

f*ck TFS.

Edit: after thinking about it for a bit, I realized that we never pushed Dev back into Main last month, so this is actually user error. Oops. TFS still sucks though.

I find it is best practice to develop out of main. My team likes to work out of branches and it just creates headaches.

kazar wrote:
Garden Ninja wrote:

Last month I had to deal with a hellish merge from a release branch, into Main, then into Dev. We had a ton of conflicts because in addition to bug fixes in Release and normal changes in Dev, Dev was also in the process of being reorganized. It took me a week to deal with them all.

Nothing has been pushed into Main in the last month. This morning, I start the Main -> Dev -> Main merge and a bunch of the conflicts I already dealt with showed up again.

f*ck TFS.

Edit: after thinking about it for a bit, I realized that we never pushed Dev back into Main last month, so this is actually user error. Oops. TFS still sucks though.

I find it is best practice to develop out of main. My team likes to work out of branches and it just creates headaches.

Use git.

kazar wrote:
Garden Ninja wrote:

Last month I had to deal with a hellish merge from a release branch, into Main, then into Dev. We had a ton of conflicts because in addition to bug fixes in Release and normal changes in Dev, Dev was also in the process of being reorganized. It took me a week to deal with them all.

Nothing has been pushed into Main in the last month. This morning, I start the Main -> Dev -> Main merge and a bunch of the conflicts I already dealt with showed up again.

f*ck TFS.

Edit: after thinking about it for a bit, I realized that we never pushed Dev back into Main last month, so this is actually user error. Oops. TFS still sucks though.

I find it is best practice to develop out of main. My team likes to work out of branches and it just creates headaches.

Yeah, more branches just means more headaches. Giving everyone a personal branch and having one main branch seems to work best for us.

Although I do dream of the day we're allowed to use git

As someone who works exclusively in the Microsoft stack and general loves Visual Studio... yeah, TFS often isn't fun, I prefer Git.

Though I have a theory that since TFS bolts on a lot of features that many of the headaches caused are due to most organizations not actually training on TFS.

SixteenBlue wrote:

Use git.

While you're at it, you might as well switch the whole office over to UNIX as well.
(;) What are dreams for?)

And vim.

I created a Git repro to house all the stuff I write as I teach myself Python. So far I have a function template.

https://github.com/EdwinGarcia/Teach...

Malor wrote:

And vim.

Yes.

Edwin wrote:

I created a Git repro to house all the stuff I write as I teach myself Python. So far I have a function template.

https://github.com/EdwinGarcia/Teach...

Remember that indentation matters in Python. You'll get an IndentationError: expected an indented block unless you indent your function bodies by one level.

ha, Vim. You people...

Much as I like Java as a language for writing stable well structured code; there is nothing about Java File IO that is enjoyable.

DanB wrote:

ha, Vim. You people...

I'm willing to accept emacs as an alternative.

Edwin wrote:

I created a Git repro to house all the stuff I write as I teach myself Python. So far I have a function template.

https://github.com/EdwinGarcia/Teach...

Somewhat related I finished off my Ruby implementation of my trainyard solution: https://github.com/Mixolyde/ty_ruby

Seems overall Ruby is a bit slower than Erlang with my implementation of this algorithm stuff, but that's not too surprising. Erlang does some pretty nice optimization in the functional style.

Now, what's my next self-taught Ruby project? Game? GUI app? Rails app? Personal utilities? Google code jams? Who knows?!

Don't get into arguments over religion, politics or text editors. Them's the rules!