What is LFS programmed on?

[swisscosmo]

hey guys just searched the forums to see if there is anything and i didn't see anything. So i'm just wondeirng what Code is LFS programmed on? Is it programmed on C++? I'm thinks its programed on C++ but i just want to make sure cause i want to learn how to program a bit just for fun.

[GP4Flo]

It's progammed on Visual C++.

http://www.lfsforum.net/showthread.php?p=852117#post852117
http://www.lfsforum.net/showthread.php?p=851932#post851932

[SabersKunk]

a computer

[Trekkerfahrer]

a computer

good one :D

[Hollywood]

All hail DirectX.

Probably C and some ugly COM interfaces. :D

[Hollywood]

Seriously, C++ isn't a great place to learn to program (especially just for fun or hobby). Check out the programmers forum.. there is quite a bit of discussion threads on how to learn to program.

Try C#, Java, Python, etc. Plenty of info on those, they are easier to chew than C++, have available IDEs, etc, etc.

hey guys just searched the forums to see if there is anything and i didn't see anything. So i'm just wondeirng what Code is LFS programmed on? Is it programmed on C++? I'm thinks its programed on C++ but i just want to make sure cause i want to learn how to program a bit just for fun.

[azasmith14]

Notepad imo... :nod:

[kruuvi]

Notepad imo... :nod:
And you drove all those 20k km with rollerskates? Yeah...

[[nism0]M5]

a computer

well obviously!:thumb: lol

good sarky btw:razz:

[iam220]

Try C#, Java, Python, etc. Plenty of info on those, they are easier to chew than C++, have available IDEs, etc, etc.

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++.

[DarkTimes]

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++.
Python is multi-paradigm...

Also you could argue it's easier to learn OOP (which you will have to do at some point) if you get a handle on it early, rather than have to make the change from procedural programming at a later date.

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.

[iam220]

Python is multi-paradigm...

Also you could argue it's easier to learn OOP (which you will have to do at some point) if you get a handle on it early, rather than have to make the change from procedural programming at a later date.

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.

My apologies, I was wrong about python ...

but I stand by what I said about OOP, trying to teach someone OOP before procedural is like teaching someone the logarithm function before they know how to multiply. (perhaps a bit of an exaggeration , but you get the point).

I also completely disagree with your last statement. There is a right and wrong language when it comes to your first. I would pick something ancient, popular, procedural and not undergoing any development .. . start from the basics and move on up to the modern stuff.

[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.

[Shotglass]

Why is learning procedural programming easier than OO when starting out? You've just asserted that it is, with no explanation as to why.

well for one the only semi sensible example any textbook seems to be able to produce is a used car lot... which isnt doing oo any favours

my personal take on oo is that it usually doesnt make a whole lot of sense if youre working on a project alone and the whole point of oo only starts to appear when you try to glue the work of several coders together which with oo should be doable in a block diagram fashion as opposed to procedural which is bound to end up in a mess
maybe its just my lack of coding experience but i get the feeling that the only real advantage of oo is the self containedness of objects which is fairly pointless if you know exactly whats in them

[pb32000]

Almost all higher education institutes will teach OO straight away, for better or worse :shrug:

[Shotglass]

Almost all higher education institutes will teach OO straight away, for better or worse :shrug:

until just a few years ago most of the good universities (eg mit) taught functional programming (scheme) first

[pb32000]

until just a few years ago most of the good universities (eg mit) taught functional programming (scheme) first

Ahh ok, I'm just speaking from personal experience, so only in the past couple of years really.

[Shotglass]

apparently both caltech and berkley still use scheme and mit has switched to python although i dont know on which of the many paradigms python is based on they focus

[wien]

maybe its just my lack of coding experience but i get the feeling that the only real advantage of oo is the self containedness of objects which is fairly pointless if you know exactly whats in themThat's a big if though. I have no idea how a lot of the code I wrote years ago actually works nor how it handles its state/data. As time goes by you forget the details, even if you work alone, and it's important that you can once the project reaches a certain size. OO is just a means of abstraction. It's not the One True Way, but it's certainly handy in a lot of cases.

Now obviously you can group state together in structures and make functions that work on these in procedural programming as well, but it's my view that then you're doing OO anyway. Just with less desirable syntax.

OO to me is simply data aggregation; grouping related data together in self-contained objects. I can't even imagine how you'd program anything of reasonable size without it. I realise my definition is a lot wider than most though. I cannot stand the popular notion that "everything's an object", because it's plainly false. Pure OO languages like Java often invent silly classes for abstract concepts like "Math" which are solely used to house standalone functions like sin and cos. How do you create an instance of Math? "I'll have 2 pounds of Math please." It doesn't make any sense.

[AndroidXP]

That's why it's an abstract class containing static methods :tilt:

Tbh, I don't see what's bad about this. Sure you can't instantiate "Math", but it serves as a nice way to group common methods together. Would you rather import a certain package/namespace and suddenly have all those functions directly available?

[DarkTimes]

Would you rather import a certain package/namespace and suddenly have all those functions directly available?
Yes. :p

[wien]

Would you rather import a certain package/namespace and suddenly have all those functions directly available?Absolutely. Math is a namespace. Trying to shoehorn it into the OO paradigm by having only static member functions seems counter-intuitive to me.

[AndroidXP]

You're wrong, then :p

Because I say so :p


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).

[wien]

I can live with that. :D

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. Private functions can still go inside classes where it makes sense of course (or anonymous namespaces in C++), so you won't get clutter from implementation details if that's what you're afraid of. 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.

[w126]

Not having standalone functions in Java is not such a big problem. It is probably because Java classes (in compiled form) are also basic deployable and executable units. At least since version 1.5 you can "import static java.lang.Math.*" and then just use sin(x), cos(x) etc. in your code.

[Shotglass]

That's a big if though. I have no idea how a lot of the code I wrote years ago actually works nor how it handles its state/data.

fair point i guess

I cannot stand the popular notion that "everything's an object", because it's plainly false. Pure OO languages like Java often invent silly classes for abstract concepts like "Math" which are solely used to house standalone functions like sin and cos. How do you create an instance of Math? "I'll have 2 pounds of Math please." It doesn't make any sense.

thats one thing we completely aggree on

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.

solution: notepad :)

[AndroidXP]

So, decreasing the coding efficiency by about a factor of 10 you call a 'solution'? :scratchch ;)
(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.)
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 :shrug:

[Shotglass]

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

[IhmisQla]

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:

interface TrigonometryProvider {
public double sin(double a);
public double cos(double a);
...
}

class Math implements TrigonometryProvider, CalculusProvider, ... {
... loads of math stuff ...
}

:smileypul

[wien]

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.
Seems more like an argument for the sake of arguing to me now :shrug::) 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.

[wien]

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

[iam220]

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!

[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

[iam220]

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 ...

[Hollywood]

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.

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.


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.


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).

[Bob Smith]

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).