|
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
