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

[Ron Frazier (ALE)]

Hi Alex,

Thanks for the reply.  I sense that you're a C programmer / fan; and that's totally fine.  If you ask 50 programmers how to do something, you'll get 85 answers.  So, we may never agree on some of these points.  Above all, I want my language to help me solve the application problems I'm trying to solve, not entrap me and bog me down while watching out for booby traps.  I think Go and Ruby are built using that philosophy.

I have a couple of more comments below.


Alex Carver <agcarver+ale at acarver.net> wrote:

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

Actually, in the 21st century, I believe the programmer should NEVER have to think about things like memory allocation ... EVER!  There's no reason for it unless you're doing something in assembly.  I never had to mess with it in Clipper.  Presumably, I wouldn't have to in Java, Go, or Ruby either.  You declare a variable, or perhaps instantiate it, memory get's allocated.  It goes out of scope, it get's deallocated.  It's needed again, it get's allocated again.  If it's a static program wide variable, it stays allocated as long as the program runs.  This type of low level resource allocation should only be attempted manually when it's impossible for automation to do it effectively.  It's more important for the programmer to figure out the logic that his program needs to have to work, not to figure out how to make the computer work.  We don't mess with that level of housekeeping in allocating sectors on the HDD any more.  I see no reason to do it with memory either.

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

I don't have any personal experience with PHP.  I did, actually, see the line you quoted.  However, I have to wonder if, with a stat like that, if I have to spend copious amounts of time worrying about whether I'm following all the conventions, whether or not the intrinsic structure of the language leads the programmer to commit more errors.  If so, I'd rather have a language that leads me to commit less errors.

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

Bottom line, if I have an I/O or system call that fails, and I haven't handled the exception, I want it to crash, or produce an error.  The last thing I want it to do is to keep running and then later produce some mysterious behavior that is nearly untraceable.  If nothing else, maybe my generic exception handler will say "error at line xyz, program terminated" and then the program dies.  If it happens during my testing.  I can fix it right there.  If it happens in the customer's hands, I'm sure I'll hear about it.  But, at least I have a chance to fix it and I know where to look.

It gets back to what I said at the top.  I want the language to be helping me solve my application problem, not necessitate that I'm continually worrying about falling into booby traps.

Sincerely,

Ron



--

Sent from my Android Acer A500 tablet with bluetooth keyboard and K-9 Mail.
Please excuse my potential brevity if I'm typing on the touch screen.

(PS - If you email me and don't get a quick response, you might want to
call on the phone.  I get about 300 emails per day from alternate energy
mailing lists and such.  I don't always see new email messages very quickly.)

Ron Frazier
770-205-9422 (O)   Leave a message.
linuxdude AT techstarship.com