Post Undeleted by Adam Lear
    Post Deleted by user1249
    Post Undeleted by maple_shaft
    Post Deleted by user1249
6 added 7 characters in body
source | link

Notice that the "do"Please do it like this so I am sure I can maintain it" is actually a very good requirement - most programs spend much longer being maintained than being written and keeping a solution in a known technology is usually a good idea.

Just imagine if some new computer kid when asked for writing a C# application wrote it in Haskell in two days and said "Hey, it works and I'm gone, bye" leaving the maintenance on you.

Just imagine if some new computer kid when asked for writing an ANSI C application 15 years ago had written it in Visual Basic 6 in two days and left it. Now you have to maintain it and Windows 7 starts complaining already when the installation media is inserted.

This might be a good opportunity to say - as Heinzi hinted in the comments - that "this is a quick prototype written in C# which happens to look very much like C - shall we make it production ready, or reimplement it in ANSI C like you asked", and then take the discussion now. Having actual source to see, is much better than "Hey, shouldn't we write our next application in Haskell because its faster".

In other words - you now have the opportunity to demonstrate that a new platform could be considered. Bring up that you wrote a prototype before the code review - this will help removing the impression that you are trying to sneak C# in under the radar. I would suggest that you also demonstrate that all existing code written in ANSI C can be used from within C#. Personally I believe you will be told that the target remains ANSI C to stay in a single platform.

Notice that the "do it like this so I am sure I can maintain it" is actually a very good requirement - most programs spend much longer being maintained than being written and keeping a solution in a known technology is usually a good idea.

Just imagine if some new computer kid when asked for writing a C# application wrote it in Haskell in two days and said "Hey, it works and I'm gone, bye" leaving the maintenance on you.

Just imagine if some new computer kid when asked for writing an ANSI C application 15 years ago had written it in Visual Basic 6 in two days and left it. Now you have to maintain it and Windows 7 starts complaining already when the installation media is inserted.

This might be a good opportunity to say - as Heinzi hinted in the comments - that "this is a quick prototype written in C# which happens to look very much like C - shall we make it production ready, or reimplement it in ANSI C like you asked", and then take the discussion now. Having actual source to see, is much better than "Hey, shouldn't we write our next application in Haskell because its faster".

In other words - you now have the opportunity to demonstrate that a new platform could be considered. Bring up that you wrote a prototype before the code review - this will help removing the impression that you are trying to sneak C# in under the radar. I would suggest that you also demonstrate that all existing code written in ANSI C can be used from within C#. Personally I believe you will be told that the target remains ANSI C to stay in a single platform.

Notice that the "Please do it like this so I am sure I can maintain it" is actually a very good requirement - most programs spend much longer being maintained than being written and keeping a solution in a known technology is usually a good idea.

Just imagine if some new computer kid when asked for writing a C# application wrote it in Haskell in two days and said "Hey, it works and I'm gone, bye" leaving the maintenance on you.

Just imagine if some new computer kid when asked for writing an ANSI C application 15 years ago had written it in Visual Basic 6 in two days and left it. Now you have to maintain it and Windows 7 starts complaining already when the installation media is inserted.

This might be a good opportunity to say - as Heinzi hinted in the comments - that "this is a quick prototype written in C# which happens to look very much like C - shall we make it production ready, or reimplement it in ANSI C like you asked", and then take the discussion now. Having actual source to see, is much better than "Hey, shouldn't we write our next application in Haskell because its faster".

In other words - you now have the opportunity to demonstrate that a new platform could be considered. Bring up that you wrote a prototype before the code review - this will help removing the impression that you are trying to sneak C# in under the radar. I would suggest that you also demonstrate that all existing code written in ANSI C can be used from within C#. Personally I believe you will be told that the target remains ANSI C to stay in a single platform.

5 edited body
source | link

Notice that the "do it like this so I am sure I can maintain it" is actually a very good requirement - most programs spend much longer being maintained than being written and keeping a solution in a known technology is usually a good idea.

Just imagine if some new computer kid when asked for writing a C# application wrote it in Haskell in two days and said "Hey, it works and I'm gone, bye" leaving the maintenance on you.

Just imagine if some new computer kid when asked for writing an ANSI C application 15 years ago had written it in Visual Basic 6 in two days and left it. Now you have to maintain it and Windows 7 starts complaining already when the installation media is inserted is inserted.

This might be a good opportunity to say - as Heinzi hinted in the comments - that "this is a quick prototype written in C# which happens to look very much like C - shall we make it production ready, or reimplement it in ANSI C like you asked", and then take the discussion now. Having actual source to see, is much better than "Hey, shouldn't we write our next application in Haskell because its faster".

In other words - you now have the opportunity to demonstrate that a new platform could be considered. Bring up that you wrote a prototype before the code review - this will help removing the impression that you are trying to sneak C# in under the radar. I would suggest that you also demonstrate that all existing code written in ANSI C can be used from within C#. Personally I believe you will be told that the target remains ANSI C to stay in a single platform.

Notice that the "do it like this so I am sure I can maintain it" is actually a very good requirement - most programs spend much longer being maintained than being written and keeping a solution in a known technology is usually a good idea.

Just imagine if some new computer kid when asked for writing a C# application wrote it in Haskell in two days and said "Hey, it works and I'm gone, bye" leaving the maintenance on you.

Just imagine if some new computer kid when asked for writing an ANSI C application 15 years ago had written it in Visual Basic 6 in two days and left it. Now you have to maintain it and Windows 7 starts complaining already when the installation media is inserted.

This might be a good opportunity to say - as Heinzi hinted in the comments - that "this is a quick prototype written in C# which happens to look very much like C - shall we make it production ready, or reimplement it in ANSI C like you asked", and then take the discussion now. Having actual source to see, is much better than "Hey, shouldn't we write our next application in Haskell because its faster".

In other words - you now have the opportunity to demonstrate that a new platform could be considered. Bring up that you wrote a prototype before the code review - this will help removing the impression that you are trying to sneak C# in under the radar. I would suggest that you also demonstrate that all existing code written in ANSI C can be used from within C#. Personally I believe you will be told that the target remains ANSI C to stay in a single platform.

Notice that the "do it like this so I am sure I can maintain it" is actually a very good requirement - most programs spend much longer being maintained than being written and keeping a solution in a known technology is usually a good idea.

Just imagine if some new computer kid when asked for writing a C# application wrote it in Haskell in two days and said "Hey, it works and I'm gone, bye" leaving the maintenance on you.

Just imagine if some new computer kid when asked for writing an ANSI C application 15 years ago had written it in Visual Basic 6 in two days and left it. Now you have to maintain it and Windows 7 starts complaining already when the installation media is inserted.

This might be a good opportunity to say - as Heinzi hinted in the comments - that "this is a quick prototype written in C# which happens to look very much like C - shall we make it production ready, or reimplement it in ANSI C like you asked", and then take the discussion now. Having actual source to see, is much better than "Hey, shouldn't we write our next application in Haskell because its faster".

In other words - you now have the opportunity to demonstrate that a new platform could be considered. Bring up that you wrote a prototype before the code review - this will help removing the impression that you are trying to sneak C# in under the radar. I would suggest that you also demonstrate that all existing code written in ANSI C can be used from within C#. Personally I believe you will be told that the target remains ANSI C to stay in a single platform.

4 added 207 characters in body
source | link

Notice that the "do it like this so I am sure I can maintain it" is actually a very good requirement - most programs spend much longer being maintained than being written and keeping a solution in a known technology is usually a good idea.

Just imagine if some new computer kid when asked for writing a C# application wrote it in Haskell in two days and said "Hey, it works and I'm gone, bye" leaving the maintenance on you.

Just imagine if some new computer kid when asked for writing an ANSI C application 15 years ago had written it in Visual Basic 6 in two days and left it. Now you have to maintain it and Windows 7 starts complaining already when the installation media is inserted.

This might be a good opportunity to say - as Heinzi hinted in the comments - that "this is a quick prototype written in C# which happens to look very much like C - shall we make it production ready, or reimplement it in ANSI C like you asked", and then take the discussion now. Having actual source to see, is much better than "Hey, shouldn't we write our next application in Haskell because its faster".

In other words - you now have the opportunity to demonstrate that a new platform shouldcould be considered. Bring up that you wrote a prototype before the code review - this will help removing the impression that you are trying to sneak C# in under the radar. I would suggest that you also demonstrate that all existing code written in ANSI C can be used from within C#. Personally I believe you will be told that the target remains ANSI C to stay in a single platform.

Notice that the "do it like this so I am sure I can maintain it" is actually a very good requirement - most programs spend much longer being maintained than being written and keeping a solution in a known technology is usually a good idea.

Just imagine if some new computer kid when asked for writing a C# application wrote it in Haskell in two days and said "Hey, it works and I'm gone, bye" leaving the maintenance on you.

Just imagine if some new computer kid when asked for writing an ANSI C application 15 years ago had written it in Visual Basic 6 in two days and left it. Now you have to maintain it and Windows 7 starts complaining already when the installation media is inserted.

This might be a good opportunity to say - as Heinzi hinted in the comments - that "this is a quick prototype written in C# which happens to look very much like C - shall we make it production ready, or reimplement it in ANSI C like you asked", and then take the discussion now. Having actual source to see, is much better than "Hey, shouldn't we write our next application in Haskell because its faster".

In other words - you now have the opportunity to demonstrate that a new platform should be considered. Bring up that you wrote a prototype before the code review - this will help removing the impression that you are trying to sneak C# in under the radar.

Notice that the "do it like this so I am sure I can maintain it" is actually a very good requirement - most programs spend much longer being maintained than being written and keeping a solution in a known technology is usually a good idea.

Just imagine if some new computer kid when asked for writing a C# application wrote it in Haskell in two days and said "Hey, it works and I'm gone, bye" leaving the maintenance on you.

Just imagine if some new computer kid when asked for writing an ANSI C application 15 years ago had written it in Visual Basic 6 in two days and left it. Now you have to maintain it and Windows 7 starts complaining already when the installation media is inserted.

This might be a good opportunity to say - as Heinzi hinted in the comments - that "this is a quick prototype written in C# which happens to look very much like C - shall we make it production ready, or reimplement it in ANSI C like you asked", and then take the discussion now. Having actual source to see, is much better than "Hey, shouldn't we write our next application in Haskell because its faster".

In other words - you now have the opportunity to demonstrate that a new platform could be considered. Bring up that you wrote a prototype before the code review - this will help removing the impression that you are trying to sneak C# in under the radar. I would suggest that you also demonstrate that all existing code written in ANSI C can be used from within C#. Personally I believe you will be told that the target remains ANSI C to stay in a single platform.

3 added 26 characters in body
source | link
2 added 94 characters in body
source | link
1
source | link