|
@OriginalGriff
Just out of curiosity did you ask the guy if he was asking what his options are within installing SQL Server (or something like it) or if he actually was unclear about what the solution was?
In a former job we had very tight security even on developers and you couldn't just install whatever you wanted, you had to get IT to do it or let you do it. Based on the wording of the question which I assume you copy & pasted into your post, indicates (to me) that English may not be his first language and so the communication barrier could add to the confusion. Just a thought.
|
|
|
|
|
Nope - his profile says "student"
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."
|
|
|
|
|
I just installed Linqer to convert some SQL to LINQ. Unfortunately, it bombed out on me, but not before automatically generating this code:
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
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 Function
This 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.
|
|
|
|
|
|
Noooo! Use a Select Case statement instead! 
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)
|
|
|
|
|
AspDotNetDev wrote: 3 lines of reflection code
do you mind explaining how? im novice at reflection 
|
|
|
|
|
See my alternate tip/trick here. That uses reflection to get all properties of a certain type and then sets their values. Using reflection, you can also invoke a method using a string that is the name of the method. I'll leave that as an exercise for the reader.
Driven to the ARMs by x86.
|
|
|
|
|
The machines are taking over... even stupidity isn't save...
(yes|no|maybe)*
|
|
|
|
|
Okay, which would you rather tell your boss at the end of the day:
1: I wrote 3 lines of code.
2: I used a code generator to write 5,000 lines of code for me - saved me 2 full days of work.
I'm mean hey, it's your career but if you keep going for efficiency over productivity you'll be selling hotdogs on a street corner before long. The difference is that of actual value vs. perceived value - one will get you a raise and the other will turn you into a grumpy old man who has an office in the basement next to the dumpster.
|
|
|
|
|
1a: I wrote 3 lines of code instead of 5000, saving me 2 days of work and making the application more efficient.
If your manager truly values auto-generated code volume then getting 'moved on' for writing better code is probably no bad thing, and I'm sure he'd be able to get a job at a better place than that.
|
|
|
|
|
Yeah, my post was serious. 
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.
|
|
|
|
|
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  .)
|
|
|
|
|
Well, no problem.
I've a short fuse today. 
|
|
|
|
|
That's why I've always hated wizards: You never know the kind of magic they can produce! 
|
|
|
|
|
Fabio Franco wrote: That's why I've always hated wizards: You never know the kind of magic they can
produce!
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
|
|
|
|
|
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.
|
|
|
|
|
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.
|
|
|
|
|
 ...hmmm, time to up my daily dose of gingko biloba...
|
|
|
|
|
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. 
|
|
|
|
|
I love how one branch of Microsoft evangelists preach accessors for every single class property (which I actually like), and the other one, preaches the most inflexible total hard binding of everything to the database schema
With the big advantage of automatically generating the joins
modified 20-Oct-19 21:02pm.
|
|
|
|
|
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'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.
|
|
|
|
|
icestatue wrote: We were able to shorten the script to about 12 lines of code when we finished it.
How long these lines were?
Greetings - Jacek
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
