[ale] semi [OT] making learning ruby programming fun?

Alex Carver agcarver+ale at acarver.net
Mon Mar 25 16:56:52 EDT 2013


On 3/25/2013 07:39, Ron Frazier (ALE) wrote:
>
> According to the link posted above, the top 10 languages, and some of the reasons I've rejected some of them, are as follows.  No offense is intended to anyone that programs in these languages.
>
> 01) Java - security problems
>
> 02) C - not modern garbage collected

I would argue that it's YOUR job as the programmer to collect your own 
garbage.  My landlord doesn't take the trash out for the other tennants, 
why should they take my trash out?

Cleaning up after a program because of something out of the ordinary 
(unexpected crash, kill -9, whatever) is different than just failing to 
deallocate the RAM that you allocated during program execution.

> 03) Objective C - Apple centric primarily
>
> 04) C++ - not modern garbage collected
>
> 05) C# - MS centric primarily
>
> ------------
>
> 06) PHP - security problems
> per
> http://en.wikipedia.org/wiki/Php
> "About 30% of all vulnerabilities listed on the National Vulnerability Database are linked to PHP."

You skipped the next line:

"These vulnerabilities are caused mostly by not following best practice 
programming rules: technical security flaws of the language itself or of 
its core libraries are not frequent (23 in 2008, about 1% of the total)."

PHP, like many other languages (except Java) isn't inherently 
vulnerable.  Instead it's how the programmer wrote the code.  I would 
put good money down that the most widely used "vulnerability" in PHP is 
an SQL injection attack because someone forgot to sanitize user input. 
You can't blame the code because there's a bunch of built-in sanitizing 
routines plus ways to roll your own if you don't like theirs (I've done 
both).  I could easily argue that C (practically the core of all 
programming short of assembly, FORTRAN and COBOL) is also vulnerable 
because I can do something stupid like free(raw_user_input) that the 
compiler might willingly let me do and blow up the machine (there's also 
the fork() bomb that will blow the machine up, too.)


The few times that a core PHP module was vulnerable to something saw a 
fix come pretty quickly or at least a way to avoid the issue.

> 10) Perl - does not have safe I/O and system calls
> per
> http://en.wikipedia.org/wiki/Comparison_of_programming_languages

Not failsafe just like C which means that if you fail to test a return 
value from a function that failed then it blows up.  Hmm, sounds like 
PEBKAC/PICNIC to me.  Goes along with garbage collection, it's the 
programmer's job to make sure that errors are handled.  Critical 
unforeseen errors (RAM stick chokes and wipes a block of memory) is up 
to the kernel but anything else is your responsibility.  I/O path didn't 
open because of a typo?  Your responsibility.  Database connection 
didn't open because the user's password is wrong?  Your responsibility.




More information about the Ale mailing list