|
"As you protect people from simple dangers, they get themselves into new and less obvious problems. Someone who avoids the simple problems may simply be heading for a not-so-simple one. "
http://www.research.att.com/~bs/bs_faq.html#invention
-c
Smaller Animals Software, Inc.
|
|
|
|
|
Programming tools are not getting "easier" at all. They are simply taking care of some of the low-level tasks that have become needless. The reason that more modern languages have added features like automatic memory cleanup is that memory is not as critical as it used to be. Most apps running on today's boxes don't have to worry that taking up another big chunk of memory is going to kill a system.
Losing the minutiae of memory management and sandbox restrictions allows programmers to spend more time concentrating on the finer points of UI and application design.
Sef Tarbell
|
|
|
|
|
from Stroustrup:
I am no fan of proprietary programming languages. Nor do I like the idea of closely integrating a programming language with a proprietary systems architecture. Finally, I consider the much-hyped "simplicity" of these languages a result of immaturity and a focus on novices at the expense of experienced system builders, and a focus on small programs at the expense of larger systems.
That said, someone who doesn't share my worries about vendor lock-in and who doesn't have my needs for scale and performance can gain some advantages from using a more constrained language with more direct support for some common applications.
Christian
I have come to clean zee pooollll. - Michael Martin Dec 30, 2001
Sonork ID 100.10002:MeanManOzI live in Bob's HungOut now
|
|
|
|
|
I picked "Better tools means higher productivity".
Some assumptions behind C#/.NET:
1) we have enough spare CPU cycles to give the computer more of the grunt work, and
2) the new CLR provides way more functionality at a higher level than C++/Win32 API does.
Are these assumptions right or wrong? In the final analysis, the market will tell us which one developers prefer, but I think the success of Java and VB already tell us what most developers will lean toward.
For myself, I remain a C++ junkie. I'll transition to C# as I get the time.
CodeGuy
The WTL newsgroup: over 1100 members! Be a part of it. http://groups.yahoo.com/group/wtl
|
|
|
|
|
I've picked "Making programming easier means dumber programmers will be writing apps".
Thinking about working on predefined platform, your opinion is correct.
Productivity means the choice of the market.
But my point of view is rather differenct.
I have a vision to be able to design and build a new platform like "X-Box" or "Palm" someday.
And I hope not to be in subordination to MS(or any other big brother) after 10 years.
C#, one of the coolest language until now on this planet, is good choice but I don't think it will enable me to realize my illusion.
Every engineer and developer has his own standpoint and that's the difference.
Regards,
Ryan
-p.s I'm a memeber of WTL groups too. 
|
|
|
|
|
|
agreed 
"No one knows what power lies yet undeveloped in that wiry system of mine."
Ada Lovelace 1815-1852
|
|
|
|
|
I think this is a bad trend. When the tools start hiding how things actually work you always lose control. Remember it's always a trade off between ease of use vs. power. I don't want to lose the respect of being a programmer, because I might if every language becomes like Visual Basic. I don't want something such as garbage collection because I can free memory myself.
This is a dangerous trend because if it continues the only real programmers will be at MS and everyone else will be VB losers.
<marquee style="filter:blur(Add=1, Direction=90, Strength=4)">I ![Heart | [heart]](https://codeproject.global.ssl.fastly.net/script/Forums/Images/love.gif) Microsoft
|
|
|
|
|
Martin Marvinski wrote:
When the tools start hiding how things actually work you always lose control.
Absolutely agreed.
Martin Marvinski wrote:
I don't want to lose the respect of being a programmer, because I might if every language becomes like Visual Basic.
There's *respect* ? Seriously, I'm surprised that you don't like VB, it comes from microsoft, after all.
Martin Marvinski wrote:
This is a dangerous trend because if it continues the only real programmers will be at MS and everyone else will be VB losers.
Watch out for Paul when you say things like that....
your statement is not quite true for two reasons.
1/ There will always be jobs outside the Microsoft domain.
2/ Just because the tools available allow sloppy programming does not mean all programmers will be sloppy. I may pay a performance hit for garbage collection, but that does not mean that moving to a GC language will make my programs suck, or somehow suck the life force from me. The percentage of people who call themselves programmers and have no idea will obviously rise, but there will still be good programmers, regardless of where they work.
I don't believe it is impossible to write good programs in VB. I do believe it is not a terribly good tool and I would certainly never seek to use it, but that does not mean that every VB programmer is an idiot, only that the language fails to punish idiocy the way C++ does.
Christian
I have come to clean zee pooollll. - Michael Martin Dec 30, 2001
Sonork ID 100.10002:MeanManOzI live in Bob's HungOut now
|
|
|
|
|
Martin Marvinski wrote:
I think this is a bad trend. When the tools start hiding how things actually work you always lose control.
Well, they are hidden only from programmers who dont mind them being hidden. For those who want to explore, know more and find out how things actually work, there are always ways to do that.
I mean MFC hides a lot of stuff from programmers. But the good ones dig in and figure out what actually happens. The same for .NET. I bet we'll soon be having books on .NET internals and MSIL
Nish
Nish
Sonork ID 100.9786 voidmain
www.busterboy.org
If you don't find me on CP, I'll be at Bob's HungOut
|
|
|
|
|
Martin Marvinski wrote:
When the tools start hiding how things actually work you always lose control.
I think this is what many felt when C, Pascal or whatever the language was that came after Assembly. Then when OO stuff came out like C++ people used the same argument to favor coding in C. And examples like this could go on and on with Java, C#, etc.
The thing to realize is that a specific language is not for everyone and not for every project. Use which ever one you feel fits your individual and project's needs. If we stopped making tools that are easier to use for fear of losing control then we won't be bettering ourselves in this profession since we'll be stuck with archaic tools. I'm for anything that'll make me productive and still allow the project to meet its functional/non-functional requirements thus greatly reducing implementation time. I'd rather go home at 5:00pm than work 12-14 hr days trying to find resource leakage issues, etc. when a tool could automatically take care of that for me.
If I were developing a web server, a 3D game engine, etc. I wouldn't even think about using C# or Java to do it. However, if the client wanted a simple way to edit some columns within a table and to perform some simple validation, then I'd use C# or VB to bind the datasource to a data grid. I could care less how much more efficent it would be to write it in C++, etc. in that instance whereas I would be concerned about efficency issues in the web server and 3D engine projects.
|
|
|
|
|
I agree with most of what you said, but I wouldn't compare the current trend to the move from C to C++. After all, most of us were using C++ principals in C before C++ was available. ie: creating a structure with pointers to functions to emulate a class - C++ didn't change how we did things (in those respects), just provided a better way to implement what we were already trying to do - and for the most part left us with all the control. As long as we build solid classes that extend the language, we aren’t using the same old archaic tools. We get to choose our level of abstraction.
Joshua Page
josh@terminaltechnologies.com
"The software required Windows 98 or better, so I installed Linux...."
|
|
|
|
|
I agree, and you've said it very well.
As much as I love C++ and Visual C++, I can't help but marvel at how great it is to work with Visual Basic (the tool) when it comes to small database-centric apps and components.
Regards,
Alvaro
|
|
|
|
|
In my experiences with the Visual Studio.NET beta 1 and 2, the tools are much less likely to 'hide' stuff from you. MFC, Visual C++, and especially COM tools--those hid things.
The tools in Visual Studio.NET generate code. That's it. You can look at the code, change it, whatever.
You can write stuff for the .NET platform with notepad and a the command-line compiler. That's all you need. (Now, I'd prefer to use the project management tools, the source control, GUI layout tools, etc...but one doesn't have to).
--Tim
|
|
|
|
|
Just want to comment that mfc doesn't hide anything. The source code is shipped with Visual C++. You can browse through it, even copy and paste parts of it if you find errors or problems.
swine
Check out Aephid Photokeeper, the powerful digital
photo album solution at www.aephid.com.
|
|
|
|
|
I see a couple of opposing trends in C++-like software development currently.
There is the standards driven trend, using ANSII/ISO C++, supported by open source, multi-platform libraries like BOOST, and WxWindows. This approach requires that you can (a) use a text editor, and (b) actually understand the language that you are working with. You have *total* control over your app, and are never tied to a particular platform, be that a hardware or software placform.
The other powerful trend, is what I always imagine as the marketing department guy, or some monkey from management banging away at a copy of Visual Basic. (Insert IT department and C# if it fits.). You are usually tied to one platform, and soon find yourself banging your head against something your tool won't let you do.
As soon as tools start forgiving ignorance, ignorance is what you get. I'm blown away by the number of Visual C++ programmers that can't even create classes without the aid of the IDE. I can't trust software written by people who don't have a working understanding of their software. The latest, flashy looking, but horribly designed offerings from many software houses are a testament to this.
Tools can make your life easier. Tools can give you leverage. But when tools try to make your life easier by hiding implementation details, I would argue that they are doing us all a disservice...
Am I just a grumpy old(26!)-school programmer?
Could be...
What do you think?
-- Leon
|
|
|
|
|
*Leon* wrote:
As soon as tools start forgiving ignorance, ignorance is what you get.
I think I'm going to have to use that as a quote - it is a simple truth, and all the more powerful for it.
*Leon* wrote:
I'm blown away by the number of Visual C++ programmers that can't even create classes without the aid of the IDE.
You're kidding, surely ? That's PATHETIC.
*Leon* wrote:
Am I just a grumpy old(26!)-school programmer?
I'm 33 - if you're old school, I think I need to be put down. But I agree with you totally.
Christian
I have come to clean zee pooollll. - Michael Martin Dec 30, 2001
Sonork ID 100.10002:MeanManOzI live in Bob's HungOut now
|
|
|
|
|
Christian Graus wrote:
*Leon* wrote:
I'm blown away by the number of Visual C++ programmers that can't even create classes without the aid of the IDE.
You're kidding, surely ? That's PATHETIC.
I see that all around me every day. Actually some can't even do that because they don't know there is an IDE aid for classes - they only know that classes have dialogs and so they insert a dialog and then hit Ctrl+W to create a class with class wizards, unaware that they could create a generic class instead using the menu.
Oh well...
|
|
|
|
|
*Leon* wrote:
Am I just a grumpy old(26!)-school programmer?
As a young man (31  ), I agree with you 100%.
I vote pro drink ![Beer | [beer]](https://codeproject.global.ssl.fastly.net/script/Forums/Images/beer.gif)
|
|
|
|
|
|
I agree that there is a growing group of ignorant programmers afoot. In my opinion, this has more to do with companies valuing cost/education over quality/experience than just ignorant programmers.
I started out as an ignorant programmer, but was fortunate enough to work with a quality programmer who "taught me the ropes". I consider myself to be 75% of the time a high quality programmer and the other 25% I just look like a high quality programmer while staring with wonder at code I wrote 6 months ago. (WTF was I thinking?)
I think the assumption that new tools making things easier will create more ignorant programmers is false. If anything, it will enable high-quality programmers to develop quality code faster and with less unnecessary overhead. We can still use best-practises, but we are now presented with more options to enable us to expedite our projects. There are bad-programmers programming in WTL, MFC, ATL, C++, VB, Java, etc. Adding more languages will not change this fact.
My current project has lasted almost 2 years. Most of that time was spent developing the back-end data management system, rules, processing, etc. The remainder of the time was spent developing an MFC front-end. The front-end is the part the average user cares about, but the back-end system was the most critical to overall success. I had to spend much of my GUI time developing custom-controls and other "fancy" interface stuff, tracking down little input bugs, etc. If I had access to a powerful tool for developing the GUI that would have limited my exposure to some of these issues, the back-end system could have been further developed, thus improving the overall product. A small performance cost in the GUI would not have mattered.
I welcome the addition of new languages and tools, I just realize they are only tools. In the proper hands they will work wonders, in ignorant hands they may cause fewer problems that earlier languages/tools.
Just my $0.02.
Thanks,
Matt Gullett
PS. None of the new languages/tools prevent me/us from using good old C++, STL, etc.
|
|
|
|
|
Pointers are for code monkies...and "garbage collection and sandbox" are for developers that want to solve their clients' problems rather than mess with memory tricks.
I know what pointers are. I know how to use them. Yep, there are somethings that you can only do (or do quickly) with pointers. But in the rest of the cases, I want my language and framework to help me solve the problem, not get in my way.
--Tim
|
|
|
|
|
Pointers do not get in the way, the provide an *option* for management of memory. This code monkey can't think of another way to do a lot of the stuff I do elegantly.
kaleid wrote:
But in the rest of the cases, I want my language and framework to help me solve the problem, not get in my way.
How does the *option* of dynamic memory allocation get in your way ? Is it too confusing to have more than one way of doing things ?
Christian
I have come to clean zee pooollll. - Michael Martin Dec 30, 2001
Sonork ID 100.10002:MeanManOzI live in Bob's HungOut now
|
|
|
|
|
Oops, you're right, I misspelled 'monkeys'. Anyway:
Christian Graus wrote:
Pointers do not get in the way, the provide an *option* for management of memory. This code monkey can't think of another way to do a lot of the stuff I do elegantly.
Let's compare to say, MFC/C++. There's not much of an option as far as pointers go. You _have_ to use them if you want to get anything done. Right, you don't have to allocate memory dynamically if you don't want to...but if you do you have a bunch of code in there to do clean up and allocation that the compiler or runtime should be smart enough to do.
That is why I'm glad to see that C# and the .NET platform offer memory management (gc), but still allow you unmanaged access to raw memory, should the need arise.
#end troll
--Tim
|
|
|
|
|
But building the garbage collection and memory managment into the common runtime should slow the program(s) down, since they have someone else doing their dirty work for them... who knows if .NET's memory management is optimized? If it is, great...but if not, then that's a performance hit that you can maybe code away if you're clever...
Another reason why garbage collection by the common runtime should slow programs down is that the programs now have to call out to the runtime each time the garbage collection needs to happen, and then switch back into the program code to continue on... I smell lots of expensive context-switches on the part of the processor. Maybe it's not an issue with the blazing-fast processors available now... 
Sincerely Yours,
Brian Hart
"And that's the news from Lake Wobegon, where all the women are strong, the men are good-looking, and the children are above-average." - Garrison Keillor
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
