|
Interesting Question.
Without computers, the whole world would look differently.
Assuming we had electricity, and automation was still required.
I would be doing "hard-wiring" of systems to create things.
My skills are simply in analysis and automation. Making peoples lives easier.
A Mechanical Loom. Studying self-playing pianos...
MAYBE an electrician like my father as a fall back.
Kirk Out!
|
|
|
|
|
Before I was seduced by the dark side of programming, I was studying to be an architect.
At the end of high school (where we self taught ourselves how to program), I was looking at 4 years of college and 10 years of apprenticeship, or 6 years of college and 4 years of apprenticeship, or "I can program now."
I was one that found programming incredibly easy, compared to others around me.
For that, I credit my parents giving me plastic model cars, rockets, and planes to assemble to keep me entertained as an only child living on a farm. I learned the importance of following directions. Programming was reversing that, creating directions, instead of following them.
Architecture taught me the importance of planning and design.
Both careers start with a blank sheet of paper and then creating something tangible.
Psychosis at 10
Film at 11
Those who do not remember the past, are doomed to repeat it.
Those who do not remember the past, cannot build upon it.
|
|
|
|
|
|
Happier? Less stressed?
Probably not either; I'd just find new things to stress over.
|
|
|
|
|
I love this thread! Thanks Vincent!
I had a drafting teacher who wanted to apprentice me to an Architecture firm. But my first love before computing was everything else electronic, so possibly an Electronics Engineer. Also was career military, so I'd probably have stayed. My career field there was based around seismology (it was classified as an Electronics career), so I could still be looking at wiggly lines.
Maybe could be building things, writing, playing music (musicing?) or teaching. Of course there's always the possibility I'd be homeless on the street somewhere!  
That's probably why I like development so much: Every job and every day is different! Always learning, always creating, always experimenting. 
|
|
|
|
|
I did enjoy drafting in school (pre-CAD). But I fell into computers in the late '70s and started programming shortly thereafter. I shudder to think what else I would have done. Being paid to write programs for me is like being a kid and playing with 'tinker toys' or an 'erector set', except I am building logic structures in my mind and implementing them. And as a previous post said, I would have likely been a different person.
All my friends have to work all week doing jobs they basically hate. I know I am absolutely spoiled rotten.
|
|
|
|
|
ajhampson wrote: who wanted to apprentice me to an Architecture firm.
I've always wanted to be an architect or atlas an artist, but I landed in computer world because I didn't have a choice that time.  Tale Of A Professional Developer - Untold[^]
|
|
|
|
|
If computers hadn't been around when I was in high-school, I'd have likely ended up a woodworker, making tables, chairs, and the like. I did four years of 'shop' in high-school, and loved it immensely (lathe-work especially!) Sadly, I found computers much more interesting (and distracting!) so that's where I landed.
Who knows, maybe once I retire in a few decades I'll get back to it... Assuming this Earth still has wood in 30-odd years! 
|
|
|
|
|
I'm also a qualified electrician.
...so I'd probably be dead because I'm too lazy to _always_ check whether a wire is live or not before touching it.
|
|
|
|
|
I'd be a sliderule jockey for an engineering firm. That's almost what I ended up doing, anyway, only computer programming was hella more fun.
|
|
|
|
|
I have heard people say that only use partial classes when there is auto-generated code. I have found that I like to use them to separate different parts of the code that are pretty much independent, but not totally. It seems to make working on the code easier since functionality is separated by files, and this reduces the length of each file, which makes it easy to find what I am looking. If I created separate classes for the same thing, I would need to pass information to allow them to change access elements. I have also used, but did not implement, a case in an adapter where all the calls to get database data were through the same class, and each table had its own file which was a partial class. I thought this worked well, and kept code conflicts down. I just followed the pattern.
|
|
|
|
|
I do the same thing.
What do you get when you cross a joke with a rhetorical question?
The metaphorical solid rear-end expulsions have impacted the metaphorical motorized bladed rotating air movement mechanism.
Do questions with multiple question marks annoy you???
|
|
|
|
|
Clifford Nelson wrote: It seems to make working on the code easier since functionality is separated by files,
I do the same thing if a class has a large number of methods, but this is quite rare.
In most cases, my top level facade class will expose a number (e.g. half a dozen) of services, each of which offer specific functionality. This allows me to swap/evolve service provider implementations over time. This pattern has proved useful when maintaining this[^] app over several versions.
/ravi
|
|
|
|
|
Anything for self-promotion. Ever the salesman. 
|
|
|
|
|
But it's true. 
Maintaining a fairly large app (with a large active user base) over 12+ years is no easy feat. I need the benefit of a carefully thought out design to help me do that. I was just sharing my experience.
/ravi
|
|
|
|
|
I was just teasing you, Ravi. I agree with your comments on the topic. 
|
|
|
|
|
Hi Ravi-ji,
Assuming you have not published in depth about this strategy for app structure, I'd really appreciate seeing an article by you on this.
cheers, Bill
«There is a spectrum, from "clearly desirable behaviour," to "possibly dodgy behavior that still makes some sense," to "clearly undesirable behavior." We try to make the latter into warnings or, better, errors. But stuff that is in the middle category you don’t want to restrict unless there is a clear way to work around it.» Eric Lippert, May 14, 2008
|
|
|
|
|
Dunno if it's worthy of an article, Bill-ji. Maybe a tip, at best?
It isn't something I designed - just a pattern I employ. But I'll tipify it if you think it's worth doing.
/ravi
|
|
|
|
|
Sukria,
I accept tips
cheers, Bill
«There is a spectrum, from "clearly desirable behaviour," to "possibly dodgy behavior that still makes some sense," to "clearly undesirable behavior." We try to make the latter into warnings or, better, errors. But stuff that is in the middle category you don’t want to restrict unless there is a clear way to work around it.» Eric Lippert, May 14, 2008
|
|
|
|
|
OK.
But you're giving me more credit for my knowledge of Hindi (and software engineering) than I'm due.
/ravi
|
|
|
|
|
I use them extensively. Particularly for library routines.
.net 1 should not have been released without them.
|
|
|
|
|
Never having used one I now see an immediate use for them. I have a dashboard with multiple tabs, all the data is related but I got annoyed by the size of the code base and split the 3rd tab out to a UC. Now I see I should have create a partial class.
Never underestimate the power of human stupidity
RAH
|
|
|
|
|
Usually when I have tabs I split out into separate classes, but partial classes seems like I good option
|
|
|
|
|
Partial classes is a good thing, but like anything it can be abused.
I have inherited an application with thousands of partial classes spread over just a few files partitioned by funtionality.
If I ever meet the programmer I'll teach him generics with a drill and a cactus.
|
|
|
|
|
For a particular WinForm app, I have a lot of controls on the main page. I use partial classes to break up the handling of the control events into their logical groups.
Otherwise, I never use partial classes, and instead use a publisher/subscriber pattern to communicate between instances, which also has the advantages of:
1) letting me hook in logging so I can see what the heck is going on
2) process intercommunication asynchronously, as the pub/sub I use can make message handler call on a separate thread
3) better exception handling, as the pub/sub will wrap the message handler call in a try-catch and log exceptions
4) because the exception handler uses the pub/sub itself to log the exception, I get can wire up other services, like an email notification, when errors occur
5) and the pub/sub instantiates the receiver class, so I'm enforcing completely isolated processing, which is great for thread safety.
So effectively, all the things that actually do non-UI things become services, and I often write them as runtime loaded modules that register themselves in the pub/sub, which is cool because I can then easily mock the services, change the business logic by loading a different module that implements different behaviors, extend the behaviors simply by adding new modules that handle the same messages, and so forth.
So there, in a nutshell, you have The Clifton Method[^].
Marc
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
