Everything That Has a Beginning Has an End (Eventually)
-
Yeah, my post was serious. :rolleyes: My entire career is based upon using code generation tools to enhance perceived value. My last performance evaluation: Boss: So, how many lines of code did you create this year? Me: Four million, thanks to the power of code generators. Boss: Wow, high productivity and automation combined. You get a 20% raise. Instead of using obvious jokes as a launching pad for grinding axes against code generation and bad management why don't you create your own rant thread. This is the perfect place to do it. Sheesh.
-
Noooo! Use a
Select Casestatement instead! :laugh:Real men don't use instructions. They are only the manufacturers opinion on how to put the thing together. Manfred R. Bihy: "Looks as if OP is learning resistant."
CodeDOM doesn't support switch; and I have seen the C# equivalent of that out and about.
He who asks a question is a fool for five minutes. He who does not ask a question remains a fool forever. [Chineese Proverb] Jonathan C Dickinson (C# Software Engineer)
-
That's why I've always hated wizards: You never know the kind of magic they can produce! :doh:
Fabio Franco wrote:
That's why I've always hated wizards: You never know the kind of magic they can produce! :doh:
They've been complaining about that ever since the first "wizards" (compilers, in this case) began generating assembly code from more readable "high-level language" code...sometimes with good reason :-D
-
Apologies, didn't get that it was a joke. It is too believable :( (My management is not like that, or I wouldn't be working here ;).)
-
Fabio Franco wrote:
That's why I've always hated wizards: You never know the kind of magic they can produce! :doh:
They've been complaining about that ever since the first "wizards" (compilers, in this case) began generating assembly code from more readable "high-level language" code...sometimes with good reason :-D
You used compilers that generated assembly code?
Driven to the ARMs by x86.
-
You used compilers that generated assembly code?
Driven to the ARMs by x86.
AspDotNetDev wrote:
You used compilers that generated assembly code?
LMAO, I may be missing the joke here, but yes, I did...I remember articles about MS 5.0 C's code generation vs. Borland's (now Symantec's?) Turbo C 6.0, arguing about code density vs. efficiency across memory architectures which might one day exceed sixteen bits available for data on the average person's desktop, especially with the expanding presence of the 32-bit 80386 processor in the business workplace...yes, those days. I actually entered a program in machine code into Debug which, after I saved it as reboot.com, dutifully rebooted the system every time I ran it. Bare-metal stuff, indeed...though I never got that (expletives deleted) COM port driver to work. But then, these intermediate languages in use now often operate in environments where sequences of bytecodes can be compiled directly into the native machine code of the executing processor, so at that point we can either request a listing (if available) or use a procesor-specific disassembler (if, ahem, our license permits) to determine whether this Just-In-Time code is actually as efficient as it can be for that processsor. Or so I assume; I'm less ambitious these days about bare-metal efficiency, I just hope it's better than running the bytecode through the interpreter and leave it at that.
-
AspDotNetDev wrote:
You used compilers that generated assembly code?
LMAO, I may be missing the joke here, but yes, I did...I remember articles about MS 5.0 C's code generation vs. Borland's (now Symantec's?) Turbo C 6.0, arguing about code density vs. efficiency across memory architectures which might one day exceed sixteen bits available for data on the average person's desktop, especially with the expanding presence of the 32-bit 80386 processor in the business workplace...yes, those days. I actually entered a program in machine code into Debug which, after I saved it as reboot.com, dutifully rebooted the system every time I ran it. Bare-metal stuff, indeed...though I never got that (expletives deleted) COM port driver to work. But then, these intermediate languages in use now often operate in environments where sequences of bytecodes can be compiled directly into the native machine code of the executing processor, so at that point we can either request a listing (if available) or use a procesor-specific disassembler (if, ahem, our license permits) to determine whether this Just-In-Time code is actually as efficient as it can be for that processsor. Or so I assume; I'm less ambitious these days about bare-metal efficiency, I just hope it's better than running the bytecode through the interpreter and leave it at that.
I thought perhaps you meant that the compiler generated machine code, but maybe you actually did use a compiler that generated assembly code. :)
Driven to the ARMs by x86.
-
I thought perhaps you meant that the compiler generated machine code, but maybe you actually did use a compiler that generated assembly code. :)
Driven to the ARMs by x86.
:wtf: ...hmmm, time to up my daily dose of gingko biloba... :laugh:
-
Fabio Franco wrote:
That's why I've always hated wizards: You never know the kind of magic they can produce! :doh:
They've been complaining about that ever since the first "wizards" (compilers, in this case) began generating assembly code from more readable "high-level language" code...sometimes with good reason :-D
cpkilekofp wrote:
They've been complaining about that ever since the first "wizards" (compilers, in this case) began generating assembly code from more readable "high-level language" code
I surely hope our wizards today don't become the compilers of tomorrow, then I'll have to hang myself. X|
-
I just installed Linqer to convert some SQL to LINQ. Unfortunately, it bombed out on me, but not before automatically generating this code:
'''<Summary>
'''The method returns the view for the index given.
'''</Summary>
Protected Overrides Function GetViewAt(ByVal index As Integer) As System.Collections.Generic.KeyValuePair(Of String, String)
If (index = 0) Then
Return GetView0
End If
If (index = 1) Then
Return GetView1
End If
If (index = 2) Then
Return GetView2
End If
If (index = 3) Then
Return GetView3
End If
If (index = 4) Then
Return GetView4
End If
If (index = 5) Then
Return GetView5
End If
' ...lots and lots of lines...
If (index = 1461) Then
Return GetView1461
End If
If (index = 1462) Then
Return GetView1462
End If
If (index = 1463) Then
Return GetView1463
End If
Throw New System.IndexOutOfRangeException()
End FunctionThis is about as bad as my 558 lines of QuickBasic glory. :(( This is probably one of those instances where 3 lines of reflection code is better than 5,000 lines of auto-generated code.
Driven to the ARMs by x86.
I was exposed to a similar situation but it didn't involve an auto generated tool so much as a terrible programmer. We had a stored procedure that used 13 parameters to be used as filters for a set of data that we would return to the users. After getting a complaint that the filter was acting strange I was told to review the procedure to find the bug. When I opened the procedure I noticed that an if then else chain of about 3000 combinations of variations of the select statement had been hand written to account for every scenario that could exist. The only problem was that we figured that this was only a small fraction of the coverage of code needed to work correctly we also noticed when coping the procedure it was more the 5 megs in length. We were able to shorten the script to about 12 lines of code when we finished it.
nothing
-
I was exposed to a similar situation but it didn't involve an auto generated tool so much as a terrible programmer. We had a stored procedure that used 13 parameters to be used as filters for a set of data that we would return to the users. After getting a complaint that the filter was acting strange I was told to review the procedure to find the bug. When I opened the procedure I noticed that an if then else chain of about 3000 combinations of variations of the select statement had been hand written to account for every scenario that could exist. The only problem was that we figured that this was only a small fraction of the coverage of code needed to work correctly we also noticed when coping the procedure it was more the 5 megs in length. We were able to shorten the script to about 12 lines of code when we finished it.
nothing
:laugh: I've seen some long stored procedures in my day. Perhaps 100 or 200K. But nothing like what you describe. Though, there was one grouped stored procedure that was composed of a hundred or so individual stored procedures (e.g., procedure;1, procedure;2, procedure;100, procedure;101, and so on). Still, that was due to decades of hopelessly complicated business logic and workarounds, not one very simple but bloated function, like the one you described.
Driven to the ARMs by x86.
-
I was exposed to a similar situation but it didn't involve an auto generated tool so much as a terrible programmer. We had a stored procedure that used 13 parameters to be used as filters for a set of data that we would return to the users. After getting a complaint that the filter was acting strange I was told to review the procedure to find the bug. When I opened the procedure I noticed that an if then else chain of about 3000 combinations of variations of the select statement had been hand written to account for every scenario that could exist. The only problem was that we figured that this was only a small fraction of the coverage of code needed to work correctly we also noticed when coping the procedure it was more the 5 megs in length. We were able to shorten the script to about 12 lines of code when we finished it.
nothing
