So, decreasing the coding efficiency by about a factor of 10 you call a 'solution'?
(I still use that minimalistic notepad kind of approach for HTML and JavaScript coding, though. And I agree that everyone should start learning coding in such a minimalist environment, so they can learn the concept of programming and thinking ahead without being distracted by fancy tools.)

Quote from wien :

Edit to your edit: I don't see how intellisense will react any worse with your_project::math::<list> than Yourproject.Math.<list> (assuming C#)? If it's a public library function intellisense will show it either way.

Would it really be worth totally overthrowing one of the fundamental concepts (functions cannot exist outside of a class) just to get rid of abstract classes with static methods? I guess what it comes down to is what you're used to - at least for me it's not in the slightest counter intuitive. Surely, if you take "object oriented" literally and say that every object must be instantiable (or even comparable to a real world object) then you might be annoyed by "shoehorning common functions into an abstract class", but in respect to what is technically/conceptually possible, the only alternative would be a MathFunctionCollection that you'd have to instantiate every time and then call a method of that, which would be rubbish.

Actually I don't even remember why I even started this argument, as in real world usage that's really a non-issue. Seems more like an argument for the sake of arguing to me now

Quote from AndroidXP :

the only alternative would be a MathFunctionCollection that you'd have to instantiate every time and then call a method of that, which would be rubbish.

inline assmebly fsin ftw

Quote from wien :

I'm just in favour of calling a spade a spade and sin and cos are standalone functions. They just are. They should not be methods of a class, static or otherwise.

Not necessarily:

Quote from AndroidXP :

Would it really be worth totally overthrowing one of the fundamental concepts (functions cannot exist outside of a class) just to get rid of abstract classes with static methods?

I guess my argument is along the lines of "why is that a fundamental concept of the language?" I don't see the benefit of not providing free functions when you have functions that clearly are, conceptually.

Quote from AndroidXP :

Seems more like an argument for the sake of arguing to me now

Quite possibly, but it is one of my major pet peeves with most "pure OO" languages. It just seems like an arbitraty restriction. OO for the sake of OO.

Quote from IhmisQla :

I think you need to add some Factory classes, Singletons and at least one round trip to XML to be truly Enterprise 2.0 compliant.

Quote from wien :

You make a lot of claims, but I see few arguments to actually back them up. Kinda difficult to argue against. Why is learning procedural programming easier than OO when starting out? You've just asserted that it is, with no explanation as to why.

My claim (and DarkTimes'?) is that OO makes it easier to model concepts from the real world, and as such is easier to pick up for someone unfamiliar with computer programming. It's easier to relate to what they already know. You obviously cover functions (procedures) before you teach classes and objects, but I don't agree at all that OO should be omitted completely.

Imagine a Venn Diagram. With two circles, one encompassing the other. The inner circle is defined as 'knowledge needed to do procedural programming' and the outer circle is defined as 'knowledge needed to do OOP'. Now if you agree with my diagram then you'll have to agree that procedural programming is fundamental knowledge. As such it should be learned first. Unless of course you prefer to learn backwards ... starting with the high level stuff and moving down to the fundamentals .. but .. that's just crazy!

that would only be true if procedural an oop were the only two ways to code... which of course they arent and often either will be completely ill fit for the problem at hand

Quote from Shotglass :

that would only be true if procedural an oop were the only two ways to code... which of course they arent and often either will be completely ill fit for the problem at hand

What's your point? I never said you can master programming by just learning 'procedural' or just learning 'OOP'. All I said, is you should START with procedural.

Besides, if you take just about any other programming paradigm and compare it against procedural, you'd find my Venn diagram to be (mostly) true ...

Avoid C++. Its the worst thing in the world to try and learn OOP programming on because its pretty much the lowest level high level language.

And you can do procedural programming in almost any language, C#, Java, Python, PHP, JavaScript, VBScript, etc.

Learning something about what a function is, what a procedure (or method) is, and when to use them are good starting points. Learning data structures (lists, linked lists, stacks, queues, trees, etc.) are another good exercise and is important when it comes down to manipulating data.

But one of the reasons that OOP came into being is almost any program boils down into data that has methods that act on that data. Classes are simply data with methods that act on them. There is not a huge jump between procedural to OOP (unlike say going from traditional OOP to doing IOC based OOP, etc). In fact the paradigms are usually taught in many data structure classes.

The real problem is not whether OOP is easy/hard, whether it should be learned before or after procedural, but rather that people do NOT how to design and structure programs. Or what data structures to use for different situations, or even what the hell a data structure is. And it can be quite apparent when looking at code.

What you should really not do is start with an RAD language and attempt to make programs that way. You won't learn anything of merit.

As an example, I recently ran into a client who was annoyed at their development partners (to put it mildly) and basically pulled the plug on them. We ended up looking at the codebase to determine what it'd be to complete changes and rebuild. What I saw shocked me. The codebase was obviously done by amateurs masquerading as professional developers. The did exactly what I described above; took a RAD language (this case VB.NET with an ASP.NET project) and slapped together things. Its quite apparent that they had no understanding of the fundamentals of programming (even procedural).

The "Learn X in 21 Days" is a complete load of crock.

If you are stuck on "C" then use something simplier like Pascal and learn the fundamentals, and then switch to C and become familiar with its syntax and issues (i.e. no procedures in C). Then move onto C++ and learning OOP.

Quote from iam220 :

Don't do this. C#, Java, Python are all Object Oriented. While there is less to worry about when you're actually coding, it's a lot more complex for a absolute beginner that has no understanding of the Object Oriented design.

Start with Pascal, it's a procedural language and it was designed to be a learning language. Once you gain some proficiency in Pascal go ahead and move onto C++.

There may be no right choices, but there are bad choices. There is a reason that most advanced languages (C++ being one) are offered as higher level courses at most colleges (at least the good ones). They are not good introductory level languages. That being said any of the modern high level languages in general should suffice although try and avoid the niche ones or the 'flavor of the day' languages.

I would also say learning some assembly (or at least an Intermediate Language such as those in .NET or Java) would be benefitial too. It helps you understand, at a very low level, what the computer is really trying to accomplish. Its actually quite fun.

Quote :

There is no correct language to choose as a first language, it's a choice that the person who is learning has to make themselves. As a general rule I'd say to learn something modern, that's actively being developed, has a large community, and is well suited to making the sorts of programs you are interested in.

Only 100ks of code? Lightweight. But yes, otherwise I would agree fully. Far cry from doing things in vi/emacs. Or even some of the original GUI compilers.

Quote :

But maybe my perspective is just different on this. I'm working on a web based business application with several 100k lines of code, uncountably many business rules and on average five other programmers who work on the same code. I'd rather have everything nicely grouped together than the intellisense exploding with tons of entries because someone needed a math function in one line of code of a business object that is a few thousand lines big. Having all the BO's functions in there is bad enough (though partial classes do help).

Quote from Hollywood :

What you should really not do is start with an RAD language and attempt to make programs that way. You won't learn anything of merit.

It's true, the most flimsy, incomplete, ameteurish apps that circle round (many of which seem to circulate within unofficial add-ons, all abusing the same name) are made in VB(.NET).

I don't think the environment is best suited to anyone that wants to learn programming seriously, as it does not enforce good structure, and until you've tried a language that does, you won't be able/know how to self-discipline.

My early VB programs were pretty damn bad in that respect, hence when I re-designed LFS GRC as VHPA (oh how I love my acronyms) it involved a massive code rewrite (and complied exe sized dropped to a quarter before I started adding the new features).