|
I worked for a fire alarm manufacturer in the late 1980's, at a time when you absolutely had to fit 10 lbs of code+data into a 5 lb E2PROM.
The project leads chose to implement an extraordinarily tiny, elegant, and fast, FORTH kernel/interpreter and made the rest of us do the main implementation using that mind warping stack-based RPN.
We all balked and bitched and chewed our fingernails, but in the final analysis, we would not have been able to fit everything in that had to be there.
Now, the kernel was elegant, tiny, and fast in and of itself. But overall, the performance of the system as a whole sucked.
Coming from the lab was a constant, "c'mon baby! c'mon baby! c'mon baby! YEAH!!!" It was like standing outside the fence listening to an orgasm festival. 
Cheers,
Mike Fidler
"I intend to live forever - so far, so good." Steven Wright
"I almost had a psychic girlfriend but she left me before we met." Also Steven Wright
|
|
|
|
|
MikeTheFid wrote: listening to an orgasm festival
They still had those in the 80s? 
|
|
|
|
|
I was channelling a previous incarnation from the time of Caligula (~35 AD). 
Cheers,
Mike Fidler
"I intend to live forever - so far, so good." Steven Wright
"I almost had a psychic girlfriend but she left me before we met." Also Steven Wright
|
|
|
|
|
MikeTheFid wrote: a fire alarm manufacturer
MikeTheFid wrote: the performance of the system as a whole sucked
So the alarm wouldn't go off until the whole place was burned to the ground? 
My blog[ ^]
public class SanderRossel : Lazy<Person>
{
public void DoWork()
{
throw new NotSupportedException();
}
}
|
|
|
|
|
Quote: So the alarm wouldn't go off until the whole place was burned to the ground?
No, not quite that bad.
Occasionally one sees in a tele program or a movie someone pulling a red pull-station on the wall and the evacuation signals sound instantaneously.
Well signals never sound instantaneously on any system, but on that particular system, it could take 5 to 10 seconds (an eternity, granted) for all signals correlated to the input to sound. In some jurisdictions that did not meet local codes.
Don't get me wrong. The system was absolutely reliable and the performance issues were eventually fully resolved.
Cheers,
Mike Fidler
"I intend to live forever - so far, so good." Steven Wright
"I almost had a psychic girlfriend but she left me before we met." Also Steven Wright
|
|
|
|
|
The "right" tool for the job depends a lot on the job and its requirements. For me at work, the ability for others to be able to maintain it is an overriding (unstated) requirement, so the answer is always C#.
Sander Rossel wrote: Should I be made responsible for a project with a tight deadline I'd go with... C# and SQL Server, because, well, that's what I know
Which makes C# and SQL the right tool for such a job -- the time pressure requirement forces you to choose tools you already know how to use.
We can program with only 1's, but if all you've got are zeros, you've got nothing.
|
|
|
|
|
I've always found that a bit of a stretch... Sure, code should be maintainable by others than yourself, but if everybody thought that way we'd still work in FORTRAN, because that's what everybody knows (at least 50 years ago), right? So yeah, go with what you know, but let's say I'd have to make a web app and I'm a WinForms developer, and in fact this happened at my previous job. Would I try and make it work in WinForms (good luck with that )? Would I turn down the job (and risk that the client takes ALL his business elsewhere)? Would I hire a third party and lose some control (what we chose to do, which turned out alright after it first turning out a little less alright ).
Or would I actually consider something else than WinForms! Or maybe you already did C# web, but you need a real-time web app. Would you consider node.js?
Sometimes it's just not worth the hassle, but if you can get new clients or keep old ones I think looking at some other languages, databases or frameworks may certainly pay off. And if you're a bit of a developer a new language shouldn't be THAT much of a problem, right?
patbob wrote: the ability for others to be able to maintain it is an overriding (unstated) requirement
I worked at a C# company where I could write C# that no one could maintain anyway (and let's just assume because I used libraries or techniques no one knew, not because I wrote spaghetti)
And that same goes for SQL. I'm writing SQL because it gets my data FAST and I'm not so much worried about what other people know. My job is to write good software for the customer and know how to write that. I assume my coworkers know this too. Although it has been a problem in the past that, apparently, they didn't...
Would you build a straw house because some (or all) people in the team don't know how to use bricks?
My blog[ ^]
public class SanderRossel : Lazy<Person>
{
public void DoWork()
{
throw new NotSupportedException();
}
}
|
|
|
|
|
I take the opposite side of that argument. I once interviewed for a Clipper (Summer of 87) job, having had no Clipper experience, and little dbase experience. My argument was that that FIRST job of a developer should be to correctly identify the problem being solved, and then identify the right solution for the job. After that, the language the solution is written in, is about syntax. And Clipper had a suitably generic syntax.
If I solve the problems perfectly, and implement them correctly, with testing and verification. Then over time, the stability should prove itself.
I won the job, and over the course of my employment, coded myself out of a job. For the first time since the system went live, they did not need a programmer to fix things, and correct reports, etc. etc. It just worked.
So, at ONE end, I could care less about the language (Currently I am working with Cobol, RPG, CL, PHP, Oracle PL/SQL, SQL, ASP, and Delphi) for clients. Meaning, I will hit each of these tools this week and every week for the next few months. Some more than others.
On the other hand, I have a gazillion lines of Delphi code, and tools and components, and I will gladly shoe horn a project into that environment, if it is gui/db based because my tools there rock.
I am in the minority here, in that I don't use Visual Studio unless it is required (it has been a couple of years, maybe 4)...
I consider myself a bit of a craftsmen. Obviously I don't write parsers/compilers in Cobol. And delphi programs have a tough time running on an as400 or an AIX box.
So at some point the language needs to be suitable to the problem. In fact, I needed a DB+parsing solution for the 400... I used Delphi + ODBC. It was a quick and dirty program to generate test data.
I find NOTHING wrong with using one tool for a lot of stuff...
The real question I like to ask is:
Do you REALLY have 5 years of experience with the tool, or do you have
1 year of experience, 5 times in a row?
Do you look for new ways to attack problems with your tools?
Have you used/analyzed C# Excel code to realize you should be using ANYTHING but COM
to control Excel? (We had a 4hr report down to 15 seconds when we stopped using COM,
and used an Excel generator Object).
I think knowing your ONE tool very well makes more sense than being a generalist.
Do I create Cobol programs from scratch.. No. I maintain someone elses code, or
I debug it and find the performance issues. (And nobody writes Cobol from scratch,
they copy an existing file, LOL).
The case being that the environment determines the right tool for the job, as you mentioned.
But honestly, most decent programming languages can do it all. It is a matter of effort,
and understanding of how to solve the original problem...
HTH,
Kirk Out!
|
|
|
|
|
Kirk 10389821 wrote: I think knowing your ONE tool very well makes more sense than being a generalist.
Kirk 10389821 wrote: Currently I am working with Cobol, RPG, CL, PHP, Oracle PL/SQL, SQL, ASP, and Delphi
That's kind of contradicting... 
I agree that there's at least one or two languages that you should know very well. Without knowing something very well you could never write good solutions. But being a generalist helps you in knowing what's out there and may actually help you get better at the thing you're very good at. I really started appreciating and understanding LINQ when I dabbled in functional programming. And because I dabbled in functional programming I can question solutions written in C# that I never would've questioned before. I started looking at SQL completely different after I had tried NoSQL and I could understand the strengths and weaknesses of SQL much better.
I've worked with people who didn't want to know more than C# because that was what they did and that's what they wanted to be really very good at. One of them even refused to do any database work, because it wasn't C#. With such an attitude I can't even take those people seriously (and that person can't ever create an app all by himself because he doesn't know SQL)
Kirk 10389821 wrote: that FIRST job of a developer should be to correctly identify the problem being solved, and then identify the right solution for the job
No language, database or framework could help you if you didn't have that particular skill! And boy do few programmers have it... 
Kirk 10389821 wrote: coded myself out of a job
Always leave a bug in the software and occassionally introduce new ones!
My blog[ ^]
public class SanderRossel : Lazy<Person>
{
public void DoWork()
{
throw new NotSupportedException();
}
}
|
|
|
|
|
If you think about it, your choice of tool (language) is totally dependent upon what you have available in the toolbox. When I started in the industry, there were only six languages, now there's over 2000. I follow the approach of examining the problem, developing a number of approaches to a solution and selecting the best approach. Part of that solution development and selection process is an examination of the tools in the toolbox.
I don't profess to know every language, but I know enough to understand the structure/syntax of the languages to carry a meaningful conversation with the programmers while trying to explain the concepts and objectives of the client. Yes, I'm an old dog, but I still enjoy new tricks.
The difficult may take time, the impossible a little longer.
|
|
|
|
|
|
Got a couple of job titles in mind but they don't involve IT as is commonly associated with that and can't be mentioned because of nondisclosure agreements between myself and said hamsters, but I only have a short time left on the agreement.
New version: WinHeist Version 2.1.0
My goal in life is to have a psychiatric disorder named after me.
I'm currently unsupervised, I know it freaks me out too but the possibilities are endless.
|
|
|
|
|
Condom tester
PooperPig - Coming Soon
|
|
|
|
|
I strongly assume that is an abbreviation for Console Domain Tester.
modified 19-Jan-21 21:04pm.
|
|
|
|
|
That's a job where only a small part of the tools are provided by the employer - to major part is up to you... 
Skipper: We'll fix it.
Alex: Fix it? How you gonna fix this?
Skipper: Grit, spit and a whole lotta duct tape.
|
|
|
|
|
I thought he was self employed, as an entrepreneur?
|
|
|
|
|
It's not clear from his profile, but that's clear that his day and night are occupied too
Skipper: We'll fix it.
Alex: Fix it? How you gonna fix this?
Skipper: Grit, spit and a whole lotta duct tape.
|
|
|
|
|
From his profile picture I'd say he's horsing around a lot.
|
|
|
|
|
Are you calling him a horse?! That's his picture from the wedding night (after the 25th tequila)...
Skipper: We'll fix it.
Alex: Fix it? How you gonna fix this?
Skipper: Grit, spit and a whole lotta duct tape.
|
|
|
|
|
That's aLlama-ing
PooperPig - Coming Soon
|
|
|
|
|
|
Please mark next time your first link as "NSFW". My wife was very surprised what Video I'm watching
modified 19-Jan-21 21:04pm.
|
|
|
|
|
It is safe for work, it is all about how they created the job adverts and the marketing behind the campaign.........there is nothing contentious in it at all.
|
|
|
|
|
well, that was what he was saying, but he forgot to add an "A" to NSFW. It should be NSFWA: Not Safe For Wife Around
|
|
|
|
|
"Young people love sex"
I guess I'll never grow up!
My blog[ ^]
public class SanderRossel : Lazy<Person>
{
public void DoWork()
{
throw new NotSupportedException();
}
}
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
