Hard Light Productions Forums
Off-Topic Discussion => Programming => Topic started by: Ghostavo on June 12, 2008, 06:52:43 am
-
Feel free to execute me for not including whatever backwater programming language you find your favorite. :P
-
The only programming language I used to know..........
BASIC.
-
php
-
Not my favourite, but you forget Haskell.
-
pascal...
-
I love the more esoteric languages, just because they force you to think differently.
Of these, Befunge (http://esolangs.org/wiki/Befunge) and its relatives are my favorite. Multidimensional programming is crazy. BeQunge (http://www.purplehatstands.com/bequnge/) is my editor of choice for these.
If you're interested in weird programming languages, check out the EsoLang (http://esolangs.org/wiki/Language_list) wiki.
-
Brain****?
-
Object Pascal
-
C++,
G codes and M codes for CNC (although I barely know the basics thanks to my summer job),
M-Code for Matlab...
-
Difficult to say, if I want to knock something together to do a job quickly and then get ignored as part of the main project, I'll use Java or the like, if I'm looking for something more 'permanent' I'd be more inclined to head for a compiled language.
-
you left out lua
im mostly c and c++, c++ being the one im most familiar with (aside from lua).
-
C++ and Java. I also know QBASIC, and a bit of Logo. And some Python, and Lua.
-
C/++ is pretty much all I know, other than that one semester of *shudder* Scheme.
-
http://xkcd.com/353/ (http://xkcd.com/353/)
http://xckd.com/413/ (http://xckd.com/413/)
-
Brain****?
Beat me to it...
I used to like Delphi, then switched to C++, now I'm liking C#. Not a big fan of perl, php, python, don't like non-compiled weakly typed languages.
-
It all depends on what you're doing. I don't think I'd ever use C-anything for a website.
-
It all depends on what you're doing. I don't think I'd ever use C-anything for a website.
Exactly, the right tools for the right job. For example, Visual Basic is good for small applications that can be used for moderately complex tasks where speed isn't vital, but the UI takes a while to set up, so it can be a pain in the arse to create very simple programs in, you can spend longer figuring out the Event Driven side of the program than actually performing the task you wanted.
-
My latest creations were in Tcl/Tk, Awk :)
C, C++ are too slow/laborious to develop for the little "projects" of mine.
-
Brain****?
Beat me to it...
I used to like Delphi, then switched to C++, now I'm liking C#. Not a big fan of perl, php, python, don't like non-compiled weakly typed languages.
How are you finding C#? I'm hearing a whole swathe of opposing opinions on it, some think that it is just as flexible as C++ and that the auto garbage system is a dream come true, others are claiming that the garbage collection means that it really should be classed as a 'C' language because it's considerably slower than it's counterparts.
-
:bump:
I know C++, and that's about it. Its covered in my module. I also know OpenGL, but it still comes under C++. I know a little AS3, and Java to boot. Plus, we had to learn Python, but I didn't really pay attention during class.
Oh, and next year, we have to learn DX, apparently. And a little birdy told me we have to learn cell programming and possibly C# and XNA.
-
:bump:
I know C++, and that's about it. Its covered in my module. I also know OpenGL, but it still comes under C++. I know a little AS3, and Java to boot. Plus, we had to learn Python, but I didn't really pay attention during class.
Oh, and next year, we have to learn DX, apparently. And a little birdy told me we have to learn cell programming and possibly C# and XNA.
Sounds pretty similar to the course I'm doing next year, multi-core programming, AI Heuristics and 3D Graphics programming. That's why I'm trying to get info on C#, I'm free to use any language I so use for next years project, and I have decided I want to use a C variant, but whilst C# would be 'easier' to use, I want to know how much of a system hit I'm going to take for game-style programming.
-
Iirc, we were told that C++ was the de facto game programming language, because it was a very powerful language, and you can easily use OOP with C++. I'm pretty sure you can do it with C# too, although apparently C++ is the base for most programming languages, so learning it will allow you to transition easier between languages.
-
That was the general impression I got as well, however, allegedly C# was designed with OO in mind from the top, and not enough people use Object Oriented programming in C++ anyway. Also, according to some sources, the garbage control of C# is actually superior to the manual requirements of C++, but then, others disagree.
I think C++ is the main game coding language because it was the only one that did the job for a while, I think C# is supposed to provide another option, but there's little information on it, and opinions seem to vary massively.
-
Imo, C# is still relatively new, so people are sticking with what they're familiar with, i.e C++. As time goes by, more C# games are released, it'll get more and more popular.
-
Generally I love C# compared to C++. I really like in C# include the auto-memory garbage collection, one less thing to need to be picky about. You still may need to implement the Dispose/Finalize methods, if your class uses objects that have Dispose implemented. FXCop will alert you of it.
I also like the conversions, especially to string, myNunber.ToString() The implementation of method overriding is a bit odd, the base method needs "virtual" and the child method needs "override".
Oh and probably my #1 reason, althought it's more Visual studio than language is "#region". The ability to collapse sections of code is great, so your not seeing code that's not relevant now.
-
I like Flash Action script :D
-
Pascal :D
-
Imo, C# is still relatively new, so people are sticking with what they're familiar with, i.e C++. As time goes by, more C# games are released, it'll get more and more popular.
C#'s popularity and relative young age is not the reason why game programmers are not adopting it. C# in practice uses a virtual machine like Java. The instructions generated when compiling a C# program are not directly processed by the processor. The performance will be always be less optimal than that of running native machine instructions. It's not so bad when developing normal applications but that's not so great for video games which are very performance oriented. Microsoft used to have Managed DirectX which uses C# but they ended up relegating that interface to XNA which is basically now used to make relatively simple Xbox Live Arcade games.
Plus, C# is a Microsoft technology. Game developers making games for the Nintendo DS, PS3, and Wii will never touch C#.
C and C++ isn't going anywhere when it comes to game development.
-
Aha! Thank you for that, that's pretty much the information I needed. I knew the .NET framework was heavily integrated into C# but reports varied as to whether the language was compiled or interpreted, this explains why.
I don't want to become too dependent on the good graces of Microsoft whilst coding, so that's pretty much decided the issue for me.
-
Wow. I didn't know that either. Okay. Its strictly C++ for me.
-
HEY! Where's Freepascal?
-
Actually there are cases where C# can be as fast as C++ and rare instances where it is actually faster than C++ (mostly with superior memory management).
-
Yeah but as you say they are rare. It's the same for Java for exactly the same reasons.
-
Go Basic ;D:yes:
-
My first programming language was BASIC, I made a golf game during the second semester of the class in high school. It was mostly to spite the teacher.
-
I use VB.net primarily - though, that's less about VB.net itself, and more about how much better VS is when using VB then C#. That and it's case insensitive, which frankly, all languages should be.
Do you guys think C++ will be able to maintain it's dominant position in gaming as the massively-multicore age dawns? C++ is unfriendly at it's best in a single thread, and multithreading has to make that even worse. With massively parallel hardware, I'm wondering if efficient hardware use isn't going to have to take a backseat to efficient development, the same way that C++ essentially killed off assembler. Seems like it's just about time for a new language which has parallelism as a focusing point from the ground floor.
-
...about how much better VS is when using VB then C#.
Not really no. C# and VB are far far better supported the C++, and the differences between VB intellisense and C# intellisense are far and few between.
That and it's case insensitive, which frankly, all languages should be.
No.
Do you guys think C++ will be able to maintain it's dominant position in gaming as the massively-multicore age dawns?
If you like playing games that don't suck, yes.
C++ is unfriendly at it's best in a single thread
If you have no idea what your doing, yeah.
and multithreading has to make that even worse.
Not really, no. Unless your doing things you shouldn't be doing. It only becomes a problem when you start modify the same memory locations from different threads, and you really shouldn't be doing that in the first place. Thats a problem even in C#, its just that in C#, it TELLS you that your being a complete dip**** instead of just blowing up.
With massively parallel hardware, I'm wondering if efficient hardware use isn't going to have to take a backseat to efficient development
Your saying it hasn't already? Do you know how many bull****-filled, horrifyingly inefficient, retarded Java games are out there? Do you know how unbelievably ****ing annoying working with XNA is? Efficient coding died YEARS ago, and its currently rotting in its grave as a bunch of retards with keyboards scream "OH HEY I CAN MAKE A GAME HAHHAHAHA" as they run across it. No, the only thing that matters nowadays is protecting idiot programmers from themselves so they don't blow up your computer. Everyone seems to dislike C++ because its a scary language and no one can understand how it works so they don't want to use it; they want to have 5 inches of fluffy padding on their walls before starting up their computer. Heck, *I* hated C++ because I couldn't understand it. Then, of course, I taught myself how to use it, and would now rather use it then any other language.
Seems like it's just about time for a new language which has parallelism as a focusing point from the ground floor.
We do not need more languages to argue about.
-
I have a feeling that Cell development could be done quite nicely with something like C#. Maybe a whole cell could even be dedicated to code management.
-
Case sensitivity is a tool of the devil.
Frankly, we'll never agree on the rest - languages are supposed to be tools meant for optimal ease of use and efficiency, not flaming crucibles to test some kind of programmer iron.
-
cell development?
-
The PS3's Cell processors.
-
Case sensitivity is a tool of the devil.
Frankly, we'll never agree on the rest - languages are supposed to be tools meant for optimal ease of use and efficiency, not flaming crucibles to test some kind of programmer iron.
Case sensitivity is awesome. As long as you don't name variables something like foOpIE, its quite useful in many regards, such as having things like FooClass fooclass = new FooClass(moreFoo); As long as you keep to capitalizing classes and keeping variables mostly lowercase, there's rarely any problems.
languages are supposed to be tools meant for optimal ease of use and efficiency
Programming language are supposed to do whatever they're supposed to do. If you want to make a program in 5 seconds that takes 5 days to figure out that its not connected to the internet, use visual basic. If you want to spend 5 hours coding a program that takes 5 seconds to figure out that its not connected to the internet, plus a slight chance of making your computer explode, use C++.
Graphics, by their very nature, require every last ounce of processing power a computer is capable of, and therefore, C++ will forever and always reign supreme in that area, unless of course an unmanaged language like D takes over. Can you make tetris using VB? Sure. Can you make Crysis using VB? Uh, no.
-
Yeah, without case sensitivity we wouldn't have much use for CamelCase.
-
Case-insenstive... icky about as bad as weakly typed languages.
-
FooClass fooclass?
Please dear god tell me you're kidding me.
If your class is of such limited use that a single instance makes sense, then why aren't you just making the thing a static class?
If it's NOT so limited that you're using a single instance, then give the instances a properly descriptive name.
Frankly, if graphics REALLY required every last ounce of processing power, you'd be programming in assembly. But you're not, are you? You've already decided that yes, it's acceptable to trade off processing power for ease of development. We're just quibbling about how much to trade.
-
Well if I'm thinking what blackhole is thinking, then if you make it static you can't do something like this:
FooClass fooClass = new FooClass (morefoo) ;
fooClass.FooAmount = amountofFoo ;
-
So why not just set morefoo in the type initializer, since there is only going to be one FooClass anyway?
Or name the variable something useful, like FooClassSingleton, or GlobalFooClass? At least then someone looking at you code can pretty much figure out from the variable name what the variable is for.
I mean, naming it FooClass only manages to tell us that it's a FooClass, which really isn't especially useful information, since presumably, if we're calling the variable by name, we have a pretty
good idea what it is. I'm failing to see how naming them the exact same thing except for a capitalization if providing any useful information to the poor bastard who's going to have to maintain the code.
-
There's more than one FooClass: fooClass and morefoo
Course who would name their class "FooClass"? ok don't answer that one :lol:
-
Frankly, if graphics REALLY required every last ounce of processing power, you'd be programming in assembly. But you're not, are you? You've already decided that yes, it's acceptable to trade off processing power for ease of development. We're just quibbling about how much to trade.
Oh I love this argument! It seems to be everyone's favorite "lets bash C++!" argument this year. Well, guess what, you can't do object-oriented programming in assembly. You can't do modular engines in assembly. You can, however, do all that in C++. In order to make a graphics engine, it is a requirement that the language you are programming in is capable of these kinds of things. Therefore, C++ is the lowest-level programming language you could feasibly program a graphics engine in while still getting it run as fast as possible. Saying I'm trading processing power off for ease of development is misleading, because to do the things you need to do with a graphics engine, you cannot do it in assembly, or C. I'm willing to trade nothing - I am building my graphics engine in the lowest possible programming language I can.
Another thing that everyone seems to conveniently forget is that to use DirectX, you've got to use C++. There is no way around that. You. Have. To. Use. C++. It doesn't matter if I wanted to code everything in assembly; you still have to use C++ to use DirectX, unless you want to forego the use of DirectX’s libraries, which is 1. stupid beyond all understandable belief and 2. a completely different argument altogether. Its the same for most of the advanced openGL functions as well.
I'm failing to see how naming them the exact same thing except for a capitalization if providing any useful information to the poor bastard who's going to have to maintain the code.
Classes are used to declare variables. That is where their scope-sharing stops. The use of FooClass fooClass = new FooClass(); is exactly 1 line of potentially confusing code. Throughout the entire rest of the function, fooClass is the only thing thats ever going to be used, and FooClass isn't going to be anywhere near it. If you think its so abhorrently difficult to maintain such code, please explain to me why such practices exist and are widespread throughout the entire programming industry?
Irrlicht does it.
Ogre does it.
Freespace 2 does it.
Every single program written at Microsoft does it.
Every single C++ and C# program I've ever downloaded does it.
Seriously, its everywhere. Saying its stupid is like telling the universe that stars are a bad idea.
-
Actually I don't think you need to use C++ to use Direct, you just need to have the translated interfaces. I remember seeing an old DirectX ported for Delphi quite some time ago.
-
And case insensitivity would be better because...?
-
How about difference between DataResult (property) and dataresult(value)? If I call Dataresult = somevalue, which one does it use?
-
Actually I don't think you need to use C++ to use Direct, you just need to have the translated interfaces. I remember seeing an old DirectX ported for Delphi quite some time ago.
Thats not what i was talking about. Yes, you can use translated interfaces, but there isn't one available for a non-object oriented language, because directX itself is object-oriented.
-
How about difference between DataResult (property) and dataresult(value)? If I call Dataresult = somevalue, which one does it use?
Neither of them, it would complain that the variable Dataresult wasn't declared.
-
How about difference between DataResult (property) and dataresult(value)? If I call Dataresult = somevalue, which one does it use?
Neither of them, it would complain that the variable Dataresult wasn't declared.
In case sensitive languages, yes.
-
So what was your point on that one?
Quoting Spicious...
And case insensitivity would be better because...?
-
From my own point of view, people shouldn't be naming variables and classes with the same name anyway, but in vast, multi-person projects, that is going to be extremely difficult to maintain. It's like the need to slap someone round the head when I see them using the Java 'This' command.
I actually like cased languages, it gives a lot more flexibility on variable names (and yet, for some reason, I have a habit of defining Booleans as all caps), and makes the language more 'readable' from a purely aesthetic position.
I've always defined variables thusly:
thisIsAVariable - therefore, the first letter is always a lower case, all further words lineated with Caps.
whereas:
ThisIsAClass - using this, it means I can tell whether the program is dealing with an array, an object or a field at a glance.
For example, you see a line of code the reads:
if CheckList(14) then XXXX
now, without casing, you might be looking at a value being passed to a test method, or the 15th object in a variable array, by using the naming convention, you know that what you are dealing with in this case is a Method, whereas checklist(14) is the 15th item in the array checklist.
-
Like telling the universe that stars are a bad idea. Or perhaps like telling Americans that Drunk Driving is a bad idea, based on how widespread it is. One of the reasons C++ is what it is, is because people resist change. A common bad idea is still a bad idea - I'm amazed you'd even try to argue something like that.
And yes, what appears to be an infinitesimal amount of power for usability is still a trade, whether you like it or not. Hell, you could even go in, write everything in C++, then go hand optimize the machine language you're putting out. But you're not going to do that either, are you? Because it's too goddamned much trouble for too little gain.
Flipside - Case insensitive isn't equal to case-less. The VB.net approach is very simple - define it in any form of capitalization you'd like, and when you use it again, no matter what the case you type in was, it's going to know which variable that is. And it's even going to nicely change whatever casing you type to match whatever you'd declare it to be. Since the advantages there are all wholly dependent on your team following the regulations of naming conventions, they can exist just as well in a case insensitive language.
And that's the plus side of well done case insensitivity. Declare once, in any casing you'd like, then just type and let the dev environment worry about capitalization. Are you guys seriously going to tell me you write entire blocks of code without any casing errors? Why sign up for more typos? What are you seriously gaining by having the ability to have a variable named Foo and a variable named foo?
Dataresult(property) and dataresult(value) are going to be determined by context. Ideally, what it should do is throw an error that you're writing ambigious code, because you are. Qualify it with the namespace if you're going to do that, or better yet, refuse to name the variable the same thing as a class.
-
One of the reasons C++ is what it is, is because people resist change. A common bad idea is still a bad idea - I'm amazed you'd even try to argue something like that.
So me resisting change is why I use C# 50% of the time, or is that just because I like to use the best language for the job? Have you completely forgotten that I used to program in Visual Basic? Case-insensitivity, in my experience, is a handicap. I like case-sensitive languages. When I moved to C#, suddenly everything was case-sensitive and I was like "Oh wow thats going to make everything so much harder - oh wait, this is awesome." This is not me saying "WE HAVE ALWAYS DONE IT THIS WAY AND WE ALWAYS WILL BECAUSE WE ARE DUMB TRADITIONALISTS," this is me saying that after having sampled both methods, I find that case-sensitivity is the one I prefer.
Because it's too goddamned much trouble for too little gain.
My listview control in my .net app takes up 11% of a quad-core CPU just by me holding the mouse down and scrolling up and down the list very fast. What the **** is that? Its not any of my code, because I have no code associated with that event (I've checked). I have no control over it. It just sucks up that CPU and flips me off. In C++, it wouldn't bump up the CPU by a single percentage point.
C++ is all about control. Its a heck of a lot easier to write really fast code that does exactly what you want and nothing more in a C++ app then in a managed application, where you get a crapload of overhead because of all the baggage that comes with it. You can, with a painful amount of work, get rid of some of that overhead, but 1. you still won't be as fast as C++ would be and 2. You could have programmed the whole thing in C++ by now!
My point is, in preformance critical applications, the amount of time you'll spend optimizing your managed code offsets whatever ease-of-production gains you get from using it.
-
My main problem with case insensivity would be the lack of uniform reserved words. Sure it's an aesthetic problem, but so is having 5 variables whose only difference is casing (although I would cry at the sight of it).
I assume most people would find case sensitive with case preventive to be the most natural.
-
From my own point of view, people shouldn't be naming variables and classes with the same name anyway, but in vast, multi-person projects, that is going to be extremely difficult to maintain. It's like the need to slap someone round the head when I see them using the Java 'This' command.
I actually like cased languages, it gives a lot more flexibility on variable names (and yet, for some reason, I have a habit of defining Booleans as all caps), and makes the language more 'readable' from a purely aesthetic position.
I've always defined variables thusly:
thisIsAVariable - therefore, the first letter is always a lower case, all further words lineated with Caps.
whereas:
ThisIsAClass - using this, it means I can tell whether the program is dealing with an array, an object or a field at a glance.
For example, you see a line of code the reads:
if CheckList(14) then XXXX
now, without casing, you might be looking at a value being passed to a test method, or the 15th object in a variable array, by using the naming convention, you know that what you are dealing with in this case is a Method, whereas checklist(14) is the 15th item in the array checklist.
Since C++ and java doesn't have properties, I'll agree with you. However, Delphi and C# do have properties and those can be used to "hide" the actual variable and allowing you to do design by contact on them. Also possibly giving them a more user friendly name. For your boolean idea, I usually have a private variable named something like "dirty" and a public read only property "IsDirty".
Btw, for arrays isn't it common standard to use [] for arrays (at least those languages i can remember)
Oh wait... you said variables and classes nevermind... I'll definetely agree with the "this" command, unless you absolutely need it, ala passing reference for self.
-
text
Right. So can we now say "Some people prefer case sensitivity for good reasons, some people prefer case insensitivity for good reasons" and call it a day?
Good. Now can you please look over what I actually said and point to where I said "Managed code is absolutely the way to go?"
Cause you know, I didn't. I didn't say Let's have a dot.net revolution, or lets start programming in java. And I certainly didn't say I was going to program Crysis in VB, or a terabyte database backend in Java.
At which point, we got to where we started from. And I still allege that C++ is unfriendly, and difficult to work in. That's why those other languages even exist - because in most situations, C++ is trading ease of creation for efficiency which isn't actually needed. Heck, you yourself go to C# at times. Which tells me that you understand that it is easier to do some things in other languages.
Now, may I humbly suggest, that maybe, just maybe, we can do a lot better then C++ in terms of creation efficiency even without managed code? And as programs grow ever more complicated, the amount of development time required for them is only going to increase, thus making development efficient is a pretty big priority, and maybe it's time to retire the old girl? She's what, 30, 40 years old now, and she was a bunch of extra additional to a language already designed for procedural programming?
Oh wait... you said variables and classes nevermind... I'll definetely agree with the "this" command, unless you absolutely need it, ala passing reference for self.
I never really use java, but there didn't seem to be anything inherently evil about this. What's so bad about it? Performance hit for referencing, or what?
-
I just hate people using things like, for example...
This House = New House();
As part of a method in a 'Street' class.
Meaning you now have a variable called House which is an instance of a class called House.
It's not 'wrong' it's just bloody irritating coding from my point of view, and can get very confusing on occasion.
-
Now, may I humbly suggest, that maybe, just maybe, we can do a lot better then C++ in terms of creation efficiency even without managed code? And as programs grow ever more complicated, the amount of development time required for them is only going to increase, thus making development efficient is a pretty big priority, and maybe it's time to retire the old girl? She's what, 30, 40 years old now, and she was a bunch of extra additional to a language already designed for procedural programming?
If D had a good IDE, I'd use it. Unfortunately, it doesn't. Its also not well-supported, which introduces heaps of problems. There's a really awesome game written in D using OpenGL somewhere called like... tube racer or something like that. TorusTrooper (http://wiki.debian.org/Games/TorusTrooper), thats what it was! The game is lightweight, unmanaged, and as totally kickass as C++, but sadly, D is young, and being 30 to 40 years old is more of an advantage to C++ then a disadvantage.
Also, C++ as a language works so well because it mimics how computers operate on a fundamental level. If we change how computers operate on a fundamental level, maybe then we'll need a new langauge for them. Until then, C++ still reigns supreme, and D is close behind, but D has issues of its own. Its these massive amounts of issues that keep new unmanaged languages from being developed. No huge company is going to put their money behind an unmanaged language, its all about managed stuff now, so its inevitable that C++ is probably going to still be here 30 to 40 years in the future. We still use roads, don't we?
COULD we do better than C++? Yeah, D is proof of that. Is that going to change anything? No, D is also proof of that. Everyone was like HOLY CRAP D IS AWESOME!
.... and then nothing happened.
I'm saying that next-gen games are always, always going to need the speed, power, and precise control that C++ offers, to such a degree that it will outweigh most advantages of managed code. Now, the higher-levels of games are moving to managed code for these precise reasons, things like scripting and whatnot, but at the end of the day, the game still needs to be coded primarily in C++, because thats the only way you can get peoples' jaws to drop at a conference room meeting.
I personally think this is just one of those things where no matter how much it sucks, its going to stay around until I'm so old I can't get out of my chair. However I also don't think that C++ is a bad language either, and I disagree that it is a horrifyingly mean and nasty language to program in. I think that it can be a b!tch to learn, but once you get the hang of it, its just another programming language. I transfer from C# to C++ every day with no problem.
Either way, I'm going to go play TorusTrooper and then use my handy dandy C++ skills to help improve Freespace 2.
-
@Flipside
I name my variables that way too; I got influenced by my lecturer, so I put either a small m or small g: mTexture/gTexture
-
Assembly language. Self modifying code for the win.
-
I find the "hard to learn" complaints about C++ kind of amusing, since my school's introductory programming classes taught C/++ as a matter of course. (And unless you're doing it in emacs at a Unix prompt, you're doing it wrong.) I never had any real trouble wrapping my mind around the mechanics of the language, and I'd never programmed a day in my life before that. Granted, I've never really used C++ for anything substantial (other than a bigass read-from/write-to/sort type of program), but at least I feel that I'd be able to do so were I to go paging back through my textbooks.
(Actually, the only other language I ever touched besides C/++ was Scheme. Dear lord, Scheme...)
-
You know, a little bit of looking and D really looks kind of interesting. Without a major backer, I can see why it has trouble, and it obviously needs a good dev environment. Is there anything for D even in the realm of visual studio?
-
http://dsource.org/projects/poseidon
Still needs quite a bit of configuration, but I think its pretty much as good as your going to get.
-
I've used
- C# which I found easy to pick up
- Visual Basic I thought was a joke of a program to use
- JAVA had way too many elements to reference
- JavaScript is fun and easy to learn
- PHP was ok but Perls got a lot more to offer
- ActionScript was a great language until it got updated to version 2 and 3 were it turned JAVA-like, which is why I dropped it
- Perl, a language I finally can appreciate because of its regex setup and that it can be used for a myriad of purposes other than web orientated.
I used to like Delphi, then switched to C++, now I'm liking C#. Not a big fan of perl, php, python, don't like non-compiled weakly typed languages.
Non-compiled languages are just as good as compiled languages, it just depends on what your using it for. C++ is a weakly typed language as well just like Perl.
http://www.ods.com.ua/win/eng/program/Perl5Unleashed/ch1.phtml#InterpretedLanguage1
Perl is interpreted. This can be either an advantage or disadvantage, depending on your needs. For example, Perl has a short development cycle compared to compiled languages, but it will never execute as fast as a compiled language. I discuss the disadvantages in the section called, "What Are the Negatives of Using Perl?," but there are some definite advantages.
One advantage of an interpreted language for tool or application development is that you can perform incremental, iterative development and testing without having to go through a create/compile/test/debug/fix cycle. By eliminating the compile portion of the cycle, interpreted languages can speed the development cycle drastically. It can also be helpful if you are evolving your application by implementing it with minimal capabilities and adding advanced capabilities later.
Because it is interpreted and relatively C-like, you can also use Perl as a prototyping language. This can be especially useful with complex or technically difficult projects such as network communication. You can use Perl's shortened development cycle to evaluate your design and then, once it is proven, rewrite the code in the language of your choice. By the way, C and C++ are good choices because Perl is a lot like C and supports much the same functionality.
I use VB.net primarily - though, that's less about VB.net itself, and more about how much better VS is when using VB then C#. That and it's case insensitive, which frankly, all languages should be.
Case sensitive exists so you can use variables names that don't conflict with existing names that may be used for methods, functions, etc
We do not need more languages to argue about.
Agreed :). There are already way too many...
-
Freakin basic rues,,,,, no sexp i see... but sexust dib;t you thinkk?....
-
Step away from the pint-glass with your hands up....
;)
-
Garghhhhh, you were wattchinn mee.
-
C++ is a weakly typed language as well just like Perl.
Only if you consider weakly typed to mean implicit conversions, otherwise C++ is strongly typed. A good example being this:
float a = 1/4; //Evaluates to 0 since 1 and 4 are integers, and the implicit conversion only occurs after they have been resolved
-
Me, QBASIC, Visual Basic by some extend (this was years ago), Assembly, C++, Scheme, and lastly MATLAB. Since my stuff is basically scientific computing, MATLAB is the choice of language here. In these cases you cannot beat massive amounts of libraries that are tested by lots of people, and the graphical output libraries stuff is way above what I could code with C++. The faster I get to test some hypothesis, the better.
If I absolutely wanted something to happen fast, (instead of slow and sure), then it is C++ time, but since I have never actually needed object oriented programming, I'm probably losing half of the benefits. I simply want a faster dot or cross product than MATLAB provides... or that there is no way to get rid of those four nested for-loops...
For graphics people, it is Assembly and C++. For electronical engineering, ditto. But I do understand the software level abstraction to get rid of POPs and PUSHs. And remove the chances of code becoming self-modifying and thus reduce risk of program gaining self-awareness (and thus starting nuclear war against all human race).
As an end chuckles, here is a list of undocumented assembly language mnemonics:
http://www.geocities.com/capecanaveral/lab/3550/assembly.htm
I personally like ARG, RPM, VDP, SCE, QVC, IDD and of course LNM (Launch Nuclear Missiles)
You will probably not find this stuff funny if you haven't written stuff with Assembler...
Mika