Your favorite programming language?

[Sniffy]

What's your favorite programming language?

[aspnetguy]

hmmmm let me think about it....ASP.Net with C#

[boen_robot]

My signature tells it... XSLT. But I also love all other XML based languages, as long as I can think of at least one use case for them (cause I also happen to know crappy (custom) XML based languages).

[justsomeguy]

I'm a fan of both PHP and C. If PHP could compile into a standalone desktop app, it would take over the world!

[reportingsjr]

Mines AJAX combined with PHP, that WILL rule the world! It makes for awesome web applications. No more loading to get new serverside data for me!! woohoo

[MartinAustin]

PHP is by far my favorite.<grumpy>At the moment, anything that has to do with standards and browser-compatibility can bite it. </grumpy>

[Skemcin]

Cold Fusion / Flex2XSLT

[Sniffy]

I prefer actionscript because it's simple to learn, and very visual.Although I do like php,html and css.

[aspnetguy]

I prefer actionscript because it's simple to learn, and very visual.Although I do like php,html and css.

I worked on a Flash app once...I found that actionscript was a lot like javascript.

[Sniffy]

I worked on a Flash app once...I found that actionscript was a lot like javascript.

Yeah, it is a lot like javascript. It's just it's mainly used to make games, and javascript is for browsers. The coding is quite alike, so that's why I know some of javascript and I only glanced through some of the tutorials.

[justsomeguy]

But, following in the footsteps of companies like Netscrape, Macromedia wasn't content to have a working language. So, they corrupted the object model for Actionscript and threw in a few things that make you go WTF pretty regularly. Actionscript is the only language I've seen where 1 doesn't equal 1. In certain circumstances of course.But the syntax is easy to learn, just as easy as Javascript or anything else. But the nature of the code being on a multi-frame movie, with different things being loaded at different times contains plenty of 'gotchas'. I spent the last two days rearranging a bunch of stuff because I was trying to get certain things to execute before other things, but still have various functions in the scope, it was a mess. But syntactically, it's very similar to Javascript.

[aspnetguy]

luckily for me I was just making a few add-ons to the program and hadn't had to develop the whole thing

[justsomeguy]

I generally enjoy working with it, but there should really be a dailyWTF site dedicated to Actionscript.

[aleksanteri]

NSIS/PHPIn NSIS, I like discovering new features (making installers, I test the functions to a notepad installer), MUI (which I just got working) and most of all, it's syntax is nice...instruction param param2 param3in nsis, macros also rock! Also a new version was released in july.In PHP, especially it's functions. MySQL support, etc etc. Yes, if PHP would standalone desktop application, my computer would be full of them! Assuming the complier is free of courde .Oh and XML:SVG too. I like making vector graphics.I actually once tried the Flash demo, and luckily I added one graphic to it! SVG is nicer (writeable!).

[pixelDepth]

I'm a fan of both PHP and C. If PHP could compile into a standalone desktop app, it would take over the world!

PHP-GTK :)I had a play with it a few months ago, just aren't enough resources. Hopefully with the recent release of v2, maybe there will be more websites dedicated to it.

[justsomeguy]

I played around with PHP-GTK a couple years ago, but even that is not standalone. It still requires PHP and its libraries to be available, whether they are distributed with the application or not. It's fun to play around with though.

[The Reverend]

I'm a big fan of PHP. I've been using it a lot the last several months and it's been able to do just about everything I've needed.

[wahlers]

I like COBOL...but that is a bit off topic on this forum.I am a professional COBOL application programmer.Most people do not know what COBOL is, or the fact that COBOL is the backbone of the financial world.I like the power, flexibility, speed, expandability and stability of COBOL...given its target...which is commercial automation!Since recently I am involved in presenting the information c.q. web pages (XHTML/XML, CSS/XSLT)...for which I am a total novice.Regards, Wim Ahlers.

[aspnetguy]

I like COBOL...but that is a bit off topic on this forum.I am a professional COBOL application programmer.Most people do not know what COBOL is, or the fact that COBOL is the backbone of the financial world.I like the power, flexibility, speed, expandability and stability of COBOL...given its target...which is commercial automation!Since recently I am involved in presenting the information c.q. web pages (XHTML/XML, CSS/XSLT)...for which I am a total novice.Regards, Wim Ahlers.

Code actually looks like s sentence too! I have had a cobol book sitting on my self for 2 years and I think I opened it twice...haven't had a need for it at all. No offense intended. What can you use COBOL that C or C++ couldn't do.

[wahlers]

Code actually looks like s sentence too! I have had a cobol book sitting on my self for 2 years and I think I opened it twice...haven't had a need for it at all. No offense intended. What can you use COBOL that C or C++ couldn't do.

Stability! readability! transportability!Try to read, run and/or modify a system written in C++ of 15 years ago!How easy is it?...in reality!Actually...it is reverse! C and C++ can do more than COBOL! Thus COBOL can do less!That is because COBOL is good in just one thing: Core financial applications!There hardly is any screen logic (read:presentation logic) in COBOL!And if there is, it usually is vendor dependent (read: non-standard).Displaying any result from a COBOL program is the responsibility of a program good at displaying information.COBOL was never intended to control the spaceship, games, video, sound and the like...It does not pretend to be anything else than it is: a stable, reliable, maintainable business oriented software solution.N.b. COBOL stands for: = Common Business Oriented Language.See, among others: http://looselycoupled.com/glossary/COBOLn.b. since the latest standard COBOL is, like many other languages, a hybrid language.Thus a combination of procedural and object-oriented code constructs.And, like any hybrid language, it can either be procedural only, object-oriented only or a mixture. (not discussing here which paradigm or combinations of paradigms is wise to use in specific situations).Throughout the years I noticed the strange phenomenon of COBOL being criticized by people who have actually never coded in COBOL or even never coded for large commercial multinationals in any programming language.Regards, Wim Ahlers.

[justsomeguy]

COBOL was never intended to control the spaceship, games, video, sound and the like...

Well no kidding, because when it was created 47 years ago those things didn't exist yet. That's the one thing that would stop me from learning something like COBOL or FORTRAN. The "do one thing, do it well" mantra works well for things when resources are limited, but with all the processing power and memory that we have 47 years later, there are now several languages that can do everything COBOL or FORTRAN can, and also do the presentation, and the logic, and the disk interaction, and garbage collection, and everything else. There is no longer a need for a program that only does presentation (or that only does business logic) when you can just use a language that will do whatever you need it to. As far as readability, maintainability, and transportability goes (and several other -bilities), those things are only as good as the programmer writing the code. If the programmer understands those concepts well and makes an effort to include high degrees of each, then the application will reflect that. But I, for one, don't have a lot of problems reading something like PHP that comes from anyone, because I understand the language to begin with.

[aspnetguy]

Try to read, run and/or modify a system written in C++ of 15 years ago!

I agree, but that is because 15 years ago there wasn't the push for re-usable code and nobody cared about the poor guy that would have to maintain it once the original programmer left.Thinks have changed and programmers seem to have discovered a little thing called // or /**/If a program is written well and you know the language it is usually not too difficult to read.

[justsomeguy]

I agree, but that is because 15 years ago there wasn't the push for re-usable code and nobody cared about the poor guy that would have to maintain it once the original programmer left.Thinks have changed and programmers seem to have discovered a little thing called // or /**/If a program is written well and you know the language it is usually not too difficult to read.

You know, that's a good point. Can we get some examples of COBOL written in 1959 please?Here's an example of a program in COBOL that unpacks a comma-separated string into fields, and checks the length of each field:

	  $ SET SOURCEFORMAT"FREE"IDENTIFICATION DIVISION.PROGRAM-ID.  UnstringFileEg.AUTHOR.  Michael Coughlan.* Example showing the unpacking of comma separated records* and the size validation of the unpacked fields.* In this example we have only implemented unpacking* an InsertSupplier record.ENVIRONMENT DIVISION.INPUT-OUTPUT SECTION.FILE-CONTROL.	SELECT VarLengthRecFile ASSIGN TO "VarLen.DAT"		ORGANIZATION IS LINE SEQUENTIAL.DATA DIVISION.FILE SECTION.FD VarLengthRecFile.01 VarLenRec.   88  EndOfFile		   VALUE HIGH-VALUES.   02  TypeCode			PIC XX.	   88 DeleteSupplier   VALUE "1,".	   88 DeleteVideo	  VALUE "2,".	   88 InsertVideo	  VALUE "3,".	   88 InsertSupplier   VALUE "4,".	   88 ValidTypeCode	VALUE "1,", "2,", "3,","4,".   02  RemainingRec		PIC X(78).WORKING-STORAGE SECTION.01 InsertSupplierRec.   02 TransType			PIC 9.   02 TransDate			PIC X(8).   02 Supplier-Code		PIC XX.   02 Supplier-Name		PIC X(20).   02 Supplier-Address	 PIC X(50).* These counts allow us to detect if there are too many chars* in a particular field.  For instance the date field should be* 8 characters in size.01 InsertSupplierCounts.   02 DateCount			PIC 99.	  88 ValidDate		 VALUE 8.   02 SuppCodeCount		PIC 99.	  88 ValidSuppCode	 VALUE 1 THRU 2.   02 SuppNameCount		PIC 99.	  88 ValidSuppName	 VALUE 1 THRU 20.   02 SuppAdrCount		 PIC 99.	  88 ValidSuppAdr	  VALUE 1 THRU 50.01 StringEnd			   PIC 99.PROCEDURE DIVISION.Begin.   OPEN INPUT VarLengthRecFile   READ VarLengthRecFile	  AT END SET EndOfFile TO TRUE   END-READ   PERFORM UNTIL EndOfFile	  MOVE ZEROS TO InsertSupplierCounts*	 First find the actual length of the record	  PERFORM VARYING StringEnd FROM 78 BY -1			  UNTIL RemainingRec(StringEnd:1) NOT = SPACE	  END-PERFORM	  IF InsertSupplier		 UNSTRING RemainingRec(1:StringEnd) DELIMITED BY ","			 INTO TransDate		COUNT IN DateCount				  Supplier-Code	COUNT IN SuppCodeCount				  Supplier-Name	COUNT IN SuppNameCount				  Supplier-Address COUNT IN SuppAdrCount		 END-UNSTRING		 PERFORM CheckForErrors		ELSE		  IF NOT ValidTypeCode			 DISPLAY SPACE			 DISPLAY "Record = " VarLenRec(1:70)			 DISPLAY "Type code is not valid"		  END-IF	  END-IF	  READ VarLengthRecFile		 AT END SET EndOfFile TO TRUE	  END-READ   END-PERFORM   CLOSE VarLengthRecFile   STOP RUN.CheckForErrors.   DISPLAY SPACE   DISPLAY "Record = " VarLenRec(1:70)   IF NOT ValidDate	 DISPLAY "Date Size Error"		END-IF   IF NOT ValidSuppCode DISPLAY "Supplier Code Error"	END-IF   IF NOT ValidSuppName DISPLAY "Supplier name Error"	END-IF   IF NOT ValidSuppAdr  DISPLAY "Supplier address Error" END-IF.

I should point out that for something like PHP, the explode function or strtok function will do this for you, minus the size validation.

[aspnetguy]

wow all that instead of

$arr = explode($delimitedString);for($i=0;$i<sizeof($arr);$i++){   //check the length}

I see no advantage to using it at all.

[wahlers]

You can always find an instruction in any language that is better than any other language.Thus, it is a bit pointless to compare instruction sets and find exactly that instruction that is better than the solution in any other program.I can easily find instructions in COBOL that are hard to code in, for instance, java.But, as said before, a futile and pointless discussion.About comments (/* bla, bla, bla .... */):Comments are both a blessing and a curse!The curse comes when years pass by and no maintainer or programmer feels responsible for modifying the comments after making a change (or addition, or removal) of some program code.Usually the comments are not to be trusted and often more hinder than help the poor programmer.But that is just my experience...About programming itself:Regardless the language used (you name it: Eiffel, java, whatever...) you can mess up using any logical/programming structure...independent of the programming language used.That is why I never use this as an argument.About the one size fits all solution:I am all for it!...except for the fact that I have never found a solution satisfying all requirements and, at the same time, being easy to use!Don't get me wrong...I do realize that some complex systems do require complex solutions.But many systems I know don't need to be as complex as they are.Not withstanding that some people prefer complex systems because they make a career out of it to deliberately keep a system complex to secure their livelihood!...but that is just my observation...It is not good enough that the aces and gurus understand the system!The system must be understand by the mediocre majority. Because, sofar, reality has proved that most if not all systems are maintained by the mediocre majority.And yes, it does happen that a fantastic superb blitz system is maintained by some half God.But even half Gods can have fatal traffic accidents.It is very unwise to let your critical system depend on half Gods! In this respect mediocre is a good thing!Also...It is my experience that a good commercial system is divided into domains of separate responsibilities (both technically as well as seperation of businnes responsibilities).Technically: Presentation, data storage and data manipulation all have there own domains.Which is a good thing!And we already have a separate system for data access (a relational database system in 99.9% of the cases).With COBOL I merely concentrate on the contents of the data and not on how this data is displayed.Which is a good thing! It is good because in a multinational system crossing borders and time zones presentation is different anyway. Not to mention that in many commercial transactions presentation is not even needed (or a minor issue), merely because large volumes of money is shifted backward and forward from one account to the other by means of high volume transactions of which (eventually) a simple summary list is produced.Boring indeed! But this is what the world runs on...boring commercial transactions instead of a true color, high fidelity flash presentations.Not to say that there are, of course, a lot of people who make lots of money creating true color, high fidelity flash presentations, games and the like...but this is a totally different domain!But that is not the point. The point is:What, for instance, if you want to switch from a relational database to an object database?It would not be wise to have an SQL statement in either your presentation or data manipulation logic!As every programmer/analyst knows such a system is highly unstable and susceptible to the famous ripple effect.Having said all this, there is no such thing as 'the perfect' system...at least, I have never seen one.Anyway...I digress...I knew up front that me mentioning COBOL as a favorite language would provoke some reaction...as it always does whenever COBOL is mentioned!By the way...'old' is not synonymous for bad! If this were true than Bach, Beethoven en Mozart would also be 'bad'!Regards, Wim.