|
I haven't written anything in Perl for some time now and can't say for certain whether I ever will again. It can be quite productive and satisfying when you're "in the zone", but I've always found it so difficult to come back to my own work that it's almost not worth it in the first place.
I'll take C# over Perl any day, although they don't really lend themselves to comparison. I certainly use C# for different reasons than I used Perl.
Charlie
if(!curlies){ return; }
|
|
|
|
|
Charlie Williams wrote:
but I've always found it so difficult to come back to my own work that it's almost not worth it in the first place.
That's why Perl has been described as "write once, read never." See "What's wrong with Perl?" http://www.garshol.priv.no/download/text/perl.html[^]
Yes, Perl should be compared with other scripting languages rather than C#. At the time I was pulling out what's left of my hair over Perl, I discovered Python and found it far nicer and much more congenial to C/C++ developers, despite its initial strangeness.
Kevin
|
|
|
|
|
Kyle Edwards wrote:
write the least amount of code possible to get the job done
That's a worthwhile goal, as long as you keep it in the view of Keep It Simple Stupid. 'Clever' code, where you manage to take a simple but verbose algorithm and turn it into tight but convoluted code, is a monumental pain in the ass over the long term. While the verbose version may have been annoying to write, it will be a lot easier to maintain as time goes on because it won't take you as long to remember how it works.
Kyle Edwards wrote:
typically means less readibility for other people, but I don't care
That statement tells me several things:- Your work by yourself, or in a very small group.
- Other people only use your code in its executable form; coworkers don't have to step through your code in a debugger, for example.
- You have limited experience. I doubt you've ever been on a programming project that lasted more than a couple of months, or required the efforts of more than two or three people.
I'm going to take a harpoon to your bubble here. As long as you're willing to stick to working on little projects, this attitude will work. Unfortunately, little projects that support you are not easy to come by.
Your approach wouldn't work on my team. We're working on phase 2 of a piece of software. Phase 1 took 2 years to complete, and it started with an initial framework from another product. Phase 1 is running successfully at a number of customer sites.
We are a team of only five programmers. Almost every day we end up stepping through each other's code as we debug our own. If any one of us didn't care about writing readable and understandable code, the whole project would either bog down or fail outright. If I can't understand what your code is doing as it interacts with mine, how can I judge whether the bug is in my code or yours? My initial reaction, if I can't understand how your code works, is that the bug is yours.
Software Zen: delete this;
|
|
|
|
|
Kyle Edwards wrote:
that typically means less readibility for other people, but I don't care
That worries me. I get worried when people say things like they don't care with issue that are actually quite important. As others have said it is quite normal to revisit code that you may have thought was finished with. 8 years on I still get calls occasionaly about code that I wrote when I was fresh out of university - luckily I quickly realised that maintainability was important and wrote code accordingly so at least if a call comes through I can see what I was doing.
Kyle Edwards wrote:
The main thing to me is bug free, fast and resource efficient code
Bbug-free is near impossible in modern software and fast and resource-efficient are usually trading off against each other.
Kyle Edwards wrote:
The end user is not going to see how much work you put into readibility, but they are going to see if the code is slow or buggy
Depends who the end user is. One of the projects I am currently working on the end users are other developers (I'm working in a team that is developing an API for the end client), so readability is a major factor. However, even if the end user is just a person who will use your web application, readability and maintainability are still very important because most software will go through many revisions and upgrades and RFCs (requests for change) will arrive and so on and frequently bugs arrive just as the person who wrote the code has gone on holiday or just left the company and some one else has to pick up the pieces.
I see from your profile you're still quite young, so you have not been exposed to the commercial world of software development yet. Once you have been I am sure you'll discover that readability is a major factor in writing good solid code.
"You can have everything in life you want if you will just help enough other people get what they want." --Zig Ziglar
The Second EuroCPian Event will be in Brussels on the 4th of September
Can't manage to P/Invoke that Win32 API in .NET? Why not do interop the wiki way!
My Blog
|
|
|
|
|
Sorry, I was wrong. Thanks for the input all of you, I'll rethink my methods. I have only been programming for a couple of years, and am still learning.
|
|
|
|
|
Kyle Edwards wrote:
Sorry, I was wrong
Few people ever admit that. That is a major plus, even if you only ever admit it to yourself. I used to work with a guy who, when he realised he was wrong, would change his mind and never admit to having had any other thoughts - but at least he saw the light in the end.
Kyle Edwards wrote:
and am still learning
That never ends. I've been programming for 21 years and I am still learning. I don't ever expect, or intend, to stop.
"You can have everything in life you want if you will just help enough other people get what they want." --Zig Ziglar
The Second EuroCPian Event will be in Brussels on the 4th of September
Can't manage to P/Invoke that Win32 API in .NET? Why not do interop the wiki way!
My Blog
|
|
|
|
|
You admit that you were wrong and that you'll rethink your methods. That's a great attitude. Few people are prepared to do that (or aadmit it). So, after earlier saying I wouldn't hire you, I'll admit that I was wrong and I would hire you.
Kevin
|
|
|
|
|
As you become a more experienced programmer you will understand that there are two kinds of efficiency relating to code design. The first is run time efficiency, which is very important. The second is maintainability and extensibility efficiency, which is probably even more important to a typical application developer.
The end user is probably not going to care much about whether your code runs a few nano-seconds slower than it might. But they will certainly notice when it takes you six months to get promised feature improvements in their hands because your clever code was not originally designed with that in mind.
You should always design your code keeping in mind the very real probability that it will need to be changed, possibly radically, during its lifetime. The faster you can respond to changing user demands the more succesful your application will be. You are probably not going to be able to do that by working "with the variables" (A comment which I'm not sure I even understand, but which leads me to suspect that you are already corrupted with a vb mindset.)
|
|
|
|
|
I fully agree with you. Few miliseconds difference in performance hardly matter to customer. They always want a finished product within specified time frame. Whether it is a bug fix or new enhancement request customers expect it in time. If our code is not organised enough then it is very very hard to finish the request in time. I have a lots of experience in this regard.
|
|
|
|
|
I would not hire anyone with this attitude.
Kevin
|
|
|
|
|
I realise a lot of nice people here have disagreed with what you have stated. But I happen to agree, under one condition, that you are a good enough coder to do it.
Just last Friday I had a IT chap call me to say that an algorithm that I had implimented 21 yrs ago was to celebrate it's birthday. The business' only issue is how to port it from FORTRAN 66 to a newer technology. (Information was left as to how the problem was initially solved, but guessing at future porting is silly.)
Anyhow if you are really good nobody will ever need to alter the internals of your code, however its useful for extendability to elucidate on how functions and procedures should be correctly used. This is turn should give enough clues in the rare case that anyone actually needs to modify your code.
Regardz
Colin J Davies
Attention: It's finally arrived, The worlds first DSP.
|
|
|
|
|
I see that if you make the code to be easily extensible, then it is also easy to maintain. To make bug free code is rather impossible task to do, if we keep in mind that bug doesn't need to bee pure programming technical issue (e.g. null pointer etc.) And what a bigger the app is, the more bugs it will have. E.g. end user will sooner or later do something that you never thought about. As parthchak said somewhere above, more important is to find and fix bugs as quick as possible when they occur.
|
|
|
|
|
..but maybe its extensible in that the way that you can add classes and objects to the project... but the internal messaging is so screwed up... it's not maintainable and takes a lot of figuring out and experimentation to get it to work.
)
|
|
|
|
|
See my thread titled "Some inter-relationships" above. To express it precisely, extensibility implies maintainability but not vice-versa. In other words if it's not maintainable then i twon't be reliably extensible.
Kevin
|
|
|
|
|
What about the reverse?
Maintainable is also extensible.
And what about some other possible views?
Maintainable is also being easily readable by others.
Maintainable also means it is easier to fix bugs..
|
|
|
|
|
I disagree. It might be a complete mess, and yet it might be clear that you just have to copy a chunk of mess and tweak it to add a new feature.
On the other hand, if it's easily maintainable then it's easily extensible.
|
|
|
|
|
Stupid users are incredibly good at finding bugs
|
|
|
|
|
I think that extensible is maintanable, but not the reverse.
First, I don't agree that multiplying the existing bugs procedure to add new feature makes the product extensible - said so, it turns that each product is **somewhow** extensible, wich deteriorates the term.
In the same time we can call each product maintanable - i.e. it could be maintaned, **somehow**.
So we call a code, maitanable if it takes a relatively small amount of time to keep it running and extensible if it takes a relatively small amount of time to keep the product growing.
And since a growing product has to be running, but the reverse cannot be said - a product can be well-running and still adding a new feature could be close to impossible - this leads to a conclusio states at the beginning.
|
|
|
|
|
...modular = more extensible and more bugfree, so I work towards that as much as possible.
|
|
|
|
|
I have done bug fixing of well known software for years. Bugs are inevitable. Important is that how quickly we can detect and fix it. More experience you are less the chance of occurrence of common bugs. Practically it's impossible to simulate all possible problems at the time of writing. It's applicable to all programmers. Here maintenance issue commes into picture. It's very painful to detect a simple bug if the code is not organized and even more painful to fix it completely without any regression. No body can fell necessity of maintenance if code size is small. Once source code size exceeds 100MB fix of a bug leaves more bugs in product. I have the sweet/sour test of fixing bugs in 400+MB source code.
Partha K Chakraborti
|
|
|
|
|
I agree! In the passed I've inherited some large and maintenance unfriendly projects (in C). One required that if you made a change in one of three arrays you had to make changes to the other two, which where in different files. I combined them into one large array and provided a set of functions to access the data. In that way when a new feature had to be added, I only had to go to one place to make the changes. All the functions, that used to have direct knowledge of there respective arrays, no longer needed to have that knowledge, to function without change. The result: code that could be modified in 15-20 minutes, as opposed to hours.
INTP
|
|
|
|
|
|
one of the other
I'll write a suicide note on a hundred dollar bill - Dire Straits
|
|
|
|
|
Thats was me
If you vote me down, my score will only get lower
|
|
|
|
|
So you are the one who keeps answering CListCtrl
I'll write a suicide note on a hundred dollar bill - Dire Straits
|
|
|
|