|
 No ... but the boss is
|
|
|
|
|
I've never refused to write code in any language.
When I don't know the language I mention that and I'll have to learn it, which may not be worth the trouble for the work that needs to be done, but I won't refuse it.
I've bashed plenty of languages because it's fun to piss people off (like we have a Java enthusiast at the office, can you believe that guy?  )
And I've a clear preference for C#, although I've started liking JavaScript as well (planning to get into TypeScript).
There are some technologies I really dislike, Crystal Reports comes to mind, I'm not a fan of Oracle, and after having tried Angular I can add Knockout to the list.
But it's my job to provide services and if my employer or client needs me to use Crystal Reports then so it shall be.
I may propose an alternative, but that's about it.
Refusing to write in a certain language because you just don't like the language smells like arrogant elitism to me.
|
|
|
|
|
Sander Rossel wrote: smells like arrogant elitism to me.
Well - let's consider:
A whore observes a leper's finger fall off. She refuses his employment offer.
Does that make her an elitist?
| Ravings en masse^ |
|---|
| "The difference between genius and stupidity is that genius has its limits." - Albert Einstein | | "If you are searching for perfection in others, then you seek disappointment. If you are seek perfection in yourself, then you will find failure." - Balboos HaGadol Mar 2010 |
|
|
|
|
|
That's refusing a customer or project, not a specific language.
C# is my favorite language, but there are C# projects I'd rather not work on.
I don't think I know of any (widely used) languages that compare to a leper (although I know of a lot of projects that are written like lepers).
|
|
|
|
|
Excellent!
I do not fear of failure. I fear of giving up out of frustration.
|
|
|
|
|
There really has to be a good reason that you would have to write something in a different language; it has to have a useful and functional purpose. Refusing to do most things for your employer, will get you fired, or at least put on the sh*t list.
|
|
|
|
|
Slacker007 wrote: There really has to be a good reason that you would have to write something in a different language; it has to have a useful and functional purpose.
Exactly, and if there isn't I'd advice against it.
But at the end of the day it's not my call to make, so if my employer decides to use VB instead of C# from now on I'll be coding VB tomorrow (although I'd advice against it, perhaps even put up a bit of a fight  ).
|
|
|
|
|
Well stated.
I might decline a contract if my initial impression was that the project was likely to be a failure, and we'd certainly discuss any issues with language. But the real issue would not be the language, it would be something else. I've been on one project that failed due to technology -- every other failure was business related.
People complain about VB, PHP, Javascript, etc. <shrug> I do what I'm paid to do, and if I meet my contractual obligations and the client is satisfied, I succeeded.
|
|
|
|
|
I started out in VB and I'm doing C# now.
I've seen horror in both.
But I can certainly write good code in both as well!
But, I'll have to admit it, VB makes it a bit easier to write bad code 
For example, probably the worst code I've seen was JavaScript because JavaScript makes all those hard to read and hard to debug constructs possible (like a huuuuuge function with deep if-else branches that returns a different type based on input  and I had to use it ).
|
|
|
|
|
Not language, but WCF s*cks most of the times.
modified 17-Jul-17 18:04pm.
|
|
|
|
|
bindings...bindings...binding configurations
|
|
|
|
|
NS_DOTNET wrote: Not language, but WCF s*cks most of the times.
Most of the time? 
Marc
Latest Article - Create a Dockerized Python Fiddle Web App
Learning to code with python is like learning to swim with those little arm floaties. It gives you undeserved confidence and will eventually drown you. - DangerBunny
Artificial intelligence is the only remedy for natural stupidity. - CDP1802
|
|
|
|
|
whenever someone says "WCF"
thoughts come about
Address
Binding
Contract
and then I just move out to get some fresh air,
feels like all oxygen in the office is consumed
|
|
|
|
|
... I was once asked to write code for a tiny micro controller in C.
My reasoning for using assembler instead was accepted.
|
|
|
|
|
C on a small processor is not very efficient. Every 8 bit processor with only a few k memory is very quickly bogged down by subroutine calling conventions and managing the heap memory.
|
|
|
|
|
That was one of the arguments.
The main argument for C was that writing the code would take less time. But I argued that I know assembly for that device very well and that I already had a lot of existing (and therefore tested) routines which can be reused and must not be reimplemented (and tested) in C.
|
|
|
|
|
Even the typical 16 bit processors, like the MC68k already were fast enough and had enough memory to justify the use of a compiler. C never was made for 8 bit CPUs, so probably assembly or even machine code may have been the better choice.
|
|
|
|
|
I have written a ton of 8051 code in C and assembler. Keil pretty much killed the C verses Assembly issue for me.
When I first started using 8051 C in the 90's I often examined the assembly output of the compiler looking to see if I could improve on it. I found very little that I wanted to change. This was for a device measuring strain-gage bridge inputs at 20 bit precision, driving an LCD display and outputting data via USB HID Device class messaging (not a virtual UART over USB). Except for the startup code provided by the compiler, the only legacy assembly code that remained was the FIR filters. I honestly think we could have moved that to C as well, but it worked and never needed maintenance so why bother.
|
|
|
|
|
The code that is generated by the compiler by itself is not the problem. Using C also certainly is the more maintainable approach. Old assembly code can be better in two regards, both at the cost of less maintainability.
First, you can avoid calling subroutines, passing parametersand passing return values. You will save a lot of cycles and also some memory if you cut those corners. The downside is that you now will have premium spaghetti code and most probably some redundancy. If you only have a few k memory or the processor is too slow, this may be needed.
The second corner you can cut is dynamic memory allocation. You also could do this in C, but then you must be careful only to use global variables, no malloc() or free(). And you must be careful that these functiones are not included and that no space for the heap is allocated anyway.
I would also prefer to use a C compiler to write stuff for old processors, but there also some very processor specific issues that the compilers do not address at all.
|
|
|
|
|
I would choose C for an 8051 too. I have sometimes to modify existing 8051 code written in PL/M by a former colleague.
But the controller from my original post is a Microchip PIC with only a few KB of flash and less than a KB of RAM. These controllers does not have push/pop instructions (besides a not very deep internal stack for call return addresses) and the stack must be implemented by using move instructions which generates a lot of overhead and memory usage when to be implemented by C compilers.
Most of the existing routines are from high precison temperature and pressure meters. They also have a 20 bit ADC and a small LCD but use an I2C bus internally and as external interface for calibration. All math routines are in assembler using a self designed 32 bit floating point format.
|
|
|
|
|
How did I win the fight? Just quoted very high.
Why... Don't really see a future and want to see a future in it.
I've also refused a certain tool that we perform testing with. How did I win this fight? Quoted that using that particular tool to perform testing with will cost the same as converting the current tests to a new tool we are using and using the new tool to test the additional work.
|
|
|
|
|
... and if the language is fixed it's normally so that it works with an existing code base, or the company / client is moving in a particular direction.
I have turned down work because of the language requirement if I don't know it and can't cost justify the time it will take to learn versus the potential work I'll get out of it.
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
I get to write the first message? Great! Let me put PHP nto this pedestal. It was the administrator, who fought like a lion that we ditch .Net and do everything with PHP. Mr. Setup.exe had no clue about programming, but wanted create some opportunities for a friend of his, who knew PHP only.
As if we did not have enough reasons to reject a weakly typed (understatement!) mess of an interpreter, right?
|
|
|
|
|
You spelled kick wrong. And a high five for Kicking PHP
I do not fear of failure. I fear of giving up out of frustration.
|
|
|
|
|
I wish I could reject to do any coding in ANY interpreted, typeless or weakly typed language. Unfortunately, in today's programming world, you cannot.
I insist on having a compiler give me a smack on my fingers BEFORE we put the code into production. I hate it especially when a fatal error occurs in an exception handler set up to avoid fatal errors, but the code isn't checked for (static or typing) errors until being used.
Sure, there are static code checking tools, but if the language is typeless or weakly typed, they can do only so much. Weak typing and interpreting often goes hand-in-hand.
(The definition of the CHILL language is nice: For each element, it specifies explicitly which static error the compiler MUST detect, which it may detect (but it may be very costly), and which errors may occur at run time that must be detected/handled by the run time system. These specs also forms a very nice check list for how to write your code so that none of the cases apply. Unfortunately, CHILL never crawled out of the phone switches into the general programming world, but at one time (in the early 1990s), more than half of the world's digital phone switches was programmed in CHILL.)
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
