I salvated the great as brick VB book from the chute. So I got historic document of the past 20 year.
I wouldnt wonder if anyday in the future I will have to flick cobble on some VB 6 code. It is irrepressible as COBOL and maybe will be the language of my last working days in some years. But confess: I wouldnt like to get a VB 6 consultant.
Press F1 for help or google it.
Greetings from Germany
Ouch!! Whenever parsing needed to be done, perl is my go yo language. And I once improved runtime of a process from 18 hours to impossibly short time, I won't mention the time just to keep thus message sane, just changing comparing mechanism with perl regular expression.
In fact, the comparing mechanism was exceptionally poorly written.
I do not fear of failure. I fear of giving up out of frustration.
I worked at a place where a bunch of Lisp fans convinced management to rip out working C/C++ UI code and replace it with Lisp so it "would be scriptable by customers". Killed the performance of the application and made it nearly impossible to debug because this Lisp engine was a black box inside the debugger, where the rest of the application remained C/C++.
But what I do have had the privilege to reject concrete projects where I saw that they would not end right or where there were too many things I didn't like / wasn't agree with.
Work load was not a factor at all, I had more than enough to keep me busy.
If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about?
Help me to understand what I'm saying, and I'll explain it better to you
Rating helpful answers is nice, but saying thanks can be even nicer.
I've been employed throughout my career for the skills and knowledge I have to offer. Those companies know what those skills and knowledge are, as they recruited and hired me to use them. So it would seem a bit strange to work for a company that tried to coerce me to use a different set of skills and knowledge than the ones they employed me for.
So I can honestly say, it's just never been an issue for me.
"There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult." - C.A.R. Hoare
Ruby in and of itself is pretty much like any other language. But with things like method missing, it is ripe for abuse, and in my short foray into it, I have seen enough abuse in the form of custom DSL's for a lifetime, not to mention consistently horrible OOP practices that seem to come along with most duck-typed languages.
VB - it's just plain ugly, and the code I've seen is almost always consistently horrid. There are notable exceptions here on CP, but it's still ugly.
The conclusion I draw is that it's not the language, but the people that the language draws, that are the real problem.
The irony is, I tell recruiters up front, I refuse to work in Ruby. And what position do they try to get me in? A Ruby dev. WTF???
The place I worked had two teams, one that worked in S/370 Assembler and the other that programmed in COBOL. I was on the Assembler team and the general consensus was that the COBOL programmers needed help getting dressed in the mornings.
I was assigned to work on a phone billing program. We'd get a monthly data tape from the phone company and my job was to break the billing down to departments.
The data tape from the phone company used all the different data types the S/370 supported. I figured I'd spend more time chasing bugs in the data conversion routines than actual programming, whereas COBOL had all those conversions built-in. So I chose to write the program in COBOL instead of Assembler.
The department head gave me a lot of grief over that decision, we were the Assembler team. I argued it was a business problem and therefore it should be programmed in a business language. In the end, they rationalized that they could throw maintenance of the application over to the COBOL team.
I poured my soul into that program. In the end I claimed that if my program couldn't figure out the billing, you couldn't do it by hand either. It was self adjusting and didn't need maintenance. The program found the phone company had been over billing us $5000 a month.
After I left the company, (the phone billing program was the last I wrote for them) the person who was assigned to take over the program called me to say the company had wanted to expand the use of the program. They had gotten an expanded data tape and wanted to know how long it would take modify the program to accommodate the extra information. The programmer was swamped at the time and said that my program produced an error list and they should just run the data through the program and he'd give an estimate from the error log. The programmer was calling me to tell me that the program figured out the new data by itself and didn't need any adjustments.
I about flew around the room in happiness, it was a smart as I had intended.
Psychosis at 10
Film at 11
Those who do not remember the past, are doomed to repeat it.
Those who do not remember the past, cannot build upon it.
Moving to a new job, I was told that a decision was to use Tck/Tk to develop a GUI for their system - it had a CLI, and the GUIs only way to interact with the system was to issue CLI commands. Noone in the company was famliar with Tcl/Tk, but the management had made the decision based on magazine articles praising the language...
After almost two years, and writing 30-40.000 lines of Tcl/Tk with lots of horribly unstable program logic to manage that clumsy CLI interface, I spent a summer vacation rewriting 90% of the logic and data structures in C, using Tcl/Tk only for putting graphical elements up on the screen. After my vacation, I replaced the Tcl logic with C without telling anyone - not until they started wondering why the GUI had become so much faster, and more stable, too. Since the translation work had been done without any sort of advance approval, and "in secrecy", at first I just said that I had rewritten "a few core functions" in C to speed it up. Since I was the only one working on the code, it took a while before the others realized that "core functions" covered everything up to (but not including) the actual graphic drawing.
In those days, Tcl was 100% interpreted directly from source code, so it was really dead slow. A while after I had done my translation, a new Tcl version introduced just-in-time byte code translation, which could in some cases speed up loops by a factor of 5. But the Tcl language was still the same same - that is to say: Terrible! I will never more accept to use that language.
Every time I see a web page displaying tags for e.g. bold/italics, rather than displaying bold/italics text, or devouring characters because they were treated as escape characters because the escape character for marking the escape character as a ordinary printable character was removed in the preceeding HTML processing step... Then I am reminded of Tcl, where you have to know the depth of the call stack before a string is actuall used, to determine the appropriate number of levels of quoting/escaping at the point of call. Actually, escaping/quoting in Tcl gave such traumas that today I avoid handling HTM as well, as far as possible, because HTML to a large degree shares Tcl's "traits" when it comes to escaping/quoting.
I started with writing code in Symitar. Then came the opportunity to move to .NET Web Services. From there, moved to ASP.NET to WinForm applications to SharePoint. All required coding in C#. Now in SharePoint, I am working in lots of client-side technologies using Ext JS and other JS libraries.
So looking back, I think, all these opportunities were great and I was kind of excited to work upon them. So didn't had to refuse writing code in a language, yet!
Coming from Objective-C and Xcode native environment, it felt like I'd been lobotomised trying to code in C# on Xamarin, then swapping to Android Studio or Xcode for anything UI-related. Everything took 10x longer to do. And trying to force MVVM on top of MVC, and having to wrangle that abomination that is Android...
(Yes, I preferred Objective-C over C#... but now I have Swift to play with, so C# is a blunt instrument in my eyes )