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 )
Back in the dark ages, I did a university course something along the lines of "Survey of Computer Languages", which involved writing a simple program or two in various languages of the day. FORTRAN, APL (!), a couple of others I forget and the dreaded COBOL.
At the top of the second COBOL program I wrote
THIS IS THE SECOND COBOL PROGRAM I HAVE EVER WRITTEN.
I SINCERELY HOPE IT IS THE LAST.
It got rejected, and I was asked to write another. I never did.
Software rusts. Simon Stephenson, ca 1994. So does this signature. me, 2012
Many years ago I interviewed for and got an asp classic role with a bank in the city (of London). Cool - so I turn up for the first day and go through all the usual on-boarding stuff and meet my co-workers. The manager puts me with the guys I'll be working with and says they'll show me the ropes.
Then we start to talk and it turns out that the role is not for asp classic, but jsp and java beans or some-such non-microsofty fluff.
So I go talk to the manager and he tells me that they had decided to go with asp for new projects and, between interviewing and starting, had changed their minds and decided to stay open source.
Quite a few years back, a client asked us about providing a web-based system. (I'll leave out the details.) My colleague found an open source system using php/mysql (and untouched for over 5 years at that time) and asked if I could rebrand it and get it working for a demo. A week later, after much swearing we had something that worked and presented it to the client. More than two years passed when they asked to see that system again, and this time decided they wanted it. 4 months before the final product was to be delivered, I made a stand and refused to do any more work in PHP. The product was rewritten from scratch in a proper maintainable language/framework and delivered on time. I hope I never see php again!
I have (so far ) succeeded to avoid the situation by listing the languages I know and want to work in in my resume. I do not mention ADA, COBOL and several others because I do not want to work with them.
I am relatively language agnostic - I am not such a purist that I will refuse to work in any modern .NET language, including Visual Basic.
I had a series of Windows Services to write and my boss said I had to use VB instead of my preferred C# as "all the company code" was in VB. I then noticed we had a couple of stand-alone applications written in C#. Everything else was web-pages in VB.
I pointed these applications out as C# and that my boss had been the one to write most of them!
He conceded that I could use C# for the services as long as all my web-pages were in VB. Success!
- I would love to change the world, but they won’t give me the source code.
I had a consulting gig where I was asked to write the same product in multiple programming languages. I listed the reasons why this is a terrible idea. After some back-and-forth, they understood why using 1 programming language for 1 product (a simple Web app) was the right approach.
In full-time gigs, I pushed back, but ultimately relented because that's what I was being paid to do. And since the company was willing to pay for training, I would've been foolish to say no.
It has been my experience that if you refuse to do a task then you get dismissed, and that includes being forced to code in VB/VB.Net. Now, if you are self-employed then you call the shots and no one can force you to do anything...mostly.
So, you try to negotiate, but in the end, if management want's to abuse you, then they abuse you, and you will take it, and like it, or you will go work for another pimp.
... most customers care about their problem being solved not how it is solved (and if they do, then I stay clear of them since they have heard something out of context which would make the project hell and convincing them otherwise would be a waste of time and effort).
I do however stay clear of languages which force you to do compilation in your head before writing code (like c++, php) or don't have debuggers.
to do compilation in your head before writing code (like c++, php)
PHP is an interpreter, so you are one step ahead if you already compile it in your head before writing the code. But yes, interpreters are worthless, especially because they are unable to detect many errors before finally hitting the row at runtime.
But what's the problem with C++? It usually is a compiler, so why do you need to compile the code in your head? Knowing beforehand what kind of code you can expect may be enormously helpful, but the greatest part of all C++ programmers apparently have somehow managed to stay afloat with obviously not even as much as a clue to what they were doing.
Nonetheless, I did a work-around and duplicated the entire VFP application as my first C#, excusing it as a way to learn that language. The VFP ran for a few months, the C#, for about eight years. The interfaces were made nearly indistinguishable - although the change wasn't a guarded secret (just unannounced until asked).
At the time, by the way, MicroSloth had already announced they were dropping all support for VFP. The IT Director who insisted on that, knowing, in fact that I hated the language and hardly knew it, was eventually give the Pink Slip.
I was asked to develop a prototype of something in Java 15 years ago. What they wanted was not feasible. They argued that I did not know Java. I actually did not (zip, zilch, nada), but I knew I was right. Showed them the code and documentation. They looked at it and determined that I was right. Not sure what happened afterwards because it never got developed.