David Crayford wrote: >It may sound like dogma but It's a psychological theory known as Millers
>law. Seven is a magic number for people's comprehension. Psychological >research has found that people generally cannot keep track of more than >about seven chunks of information at once (Miller 1956) [1]. It's been >applied to computer science for decades. And ISTR was one of the reasons for seven-digit phone numbers. Either that or it was a happy accident, but I know I've read at least someone claiming it was chosen because "seven is magic". How many of us remember shorter numbers? I remember four-digit dialing when I was a kid; my brother-in-law has that beat: his home phone number when he was little was.4. Small town. >[1] https://en.wikipedia.org/wiki/The_Magical_Number_Seven,_Plus_or_Minus_Two >TBH, I don't like it. The interface is brittle and if there were 100 >tuples it would be easy to make a mistake in the argument list. My first >instinct would be to use a container of tuples but if you're handicapped >by your language and it doesn't support containers I would write an ADT >that keeps track of counts and maintains an internal array. I've been >coding in OO languages for the last 15 years so I instinctively think >along the lines of encapsulation and well defined interfaces. If you >needed to support unlimited tuples you could change the array to a >linked list and none of the client programs would need to change. >handle = tuples_create() >tuples_add(handle, tuple(thing, data, length)) >tuples_process(handle) >tuples_destroy(handle) How would it be easier to make a mistake in a (reasonably formatted) call of 100 tuples than in doing 100 tuples_add() calls? I don't get it. Either way, ya gots ta get it right! I dislike multiple calls to do one thing, because it's easier to break that with maintenance (although admittedly in this case it would be Very Stupid maintenance). But atomicity is A Good Thing in my book. >So if your tuples are different types then your programming language is >not strongly typed which to me is also a concern. I prefer the compiler >to catch my bugs :) >tuples_process(tuple(thing, data, length)) >or if your language doesn't support generics use a generational naming convention. >tuples_process2(tuple(thing, data, length)) Um. This is for the real world, where we don't get to say "Use this new-fangled fancy language"; we're stuck with lowest-common denominator, which is COBOL. Or perhaps assembler. I guess I didn't make that clear enough. >Theology is the wrong word. Software engineering is not about religion >or art it's an engineering discipline. I've been in this game over 30 >years and when I look at the quality of code being produced now compared >to the COBOL and PL/1 programs I used to work on in the 90s it's a >completely different world. A lot of that has to do with game changing >advances in programming languages and the paradigm shift towards OO >and functional programming. You're saying newer code is higher quality? Not from what I've seen. There's a lot of it, that's for sure. But the sloppiness I see in products makes me cringe. Color me unconvinced that OO and functional programming are actually an improvement (I'm willing to believe they are, just haven't seen the evidence). And I maintain there is a theological aspect to some of it, like "GOTOs are bad" or "strong typing is good". Either statement CAN be true but need not be, and folks take ideological stances on their goodness. Personally, I'd rather write code that validates the parameters than depend on the compiler. Not that I think the compiler will get it wrong, but if it's the right type but the wrong color (flavor, length, whatever) at runtime, I want my code to tell me that. What I see with strongly typed languages is folks saying "I don't need to validate this because the compiler did it for me", and then they get to debug it the hard way. Not to mention the time spent tinkering with casts just to make the compiler happy. >Unfortunately that's an anti-pattern that is all too common because the >designer was too lazy to use enumerated types. Of course modern language >like C#, Kotlin, Swift etc all support default arguments and named arguemnts >so that would become: >MyFunc(isLazy: true, isHungry: false, isThristy: false). Again, real-world doesn't let us choose the language. >In languages that don't support named arguments like C++ and Java you can >design a fluent API. For example an HTTP client: >// Execute a GET with timeout settings and return response content as String. >Request.Get("http://somehost/";) > .connectTimeout(1000) > .socketTimeout(1000) > .execute().returnContent().asString(); Um, ok. You've lost me at this point. "fluent"? ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
