Language:
switch to room list switch to menu My folders
Go to page: [1] 2 3 4 5 ... Last
↑↑↑ Old messages ↑↑↑            ↓↓↓ New messages ↓↓↓
[#] Tue Feb 07 2012 09:21:09 EST from dothebart @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]

http://nathanmarz.com/blog/suffering-oriented-programming.html

the problem is just, if nobody feels the pain.



[#] Wed Feb 08 2012 08:31:30 EST from fleeb @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]


I certainly follow this.

I try not to create something unless I see a certain need for it, unless I'm just farting around (which I do occasionally to learn something).

So, I don't implement features unless the feature really is needed. Saves a lot of time, and ensures the code is just.

[#] Fri Feb 10 2012 16:53:12 EST from skpacman @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]

 

Wed Feb 08 2012 08:31:30 AM EST from fleeb @ Uncensored

I try not to create something unless I see a certain need for it, unless I'm just farting around (which I do occasionally to learn something).

Which is the precise reason I decided to make my own ecommerce system for PHP-Fusion, instead of attempting to integrate someone else's, or paying a huge fee just to use one that's built for my purpose.

I figure, I have (most of) the skills to do it myself, and I'm tired of people charging big money for it, so why not piss everyone off by making my own (which I will distribute for free) and actually use my own on my other sites?

-- 
http://skpacman.hopto.org



[#] Sun Feb 12 2012 08:45:42 EST from IGnatius T Foobar @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]

Aren't there other true-open-source ecommerce systems out there already? Surely you aren't the first to do that?

[#] Mon Feb 13 2012 11:52:59 EST from skpacman @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]

 

Sun Feb 12 2012 08:45:42 AM EST from IGnatius T Foobar @ Uncensored
Aren't there other true-open-source ecommerce systems out there already? Surely you aren't the first to do that?

There are none that I could find that works specifically as an infusion for php-fusion 7.

I must have searched for at least 6 - 7 days to find one that worked.

I'm not the first to do it, which is the problem. The one that's available is severely out-dated and insecure. It would take me just as long to fix the old one as it would to build a better one. Any other ecommerce solutions for php-fusion are not free, nor open-source, and are sold through the author's website. I'm building one that is free, open-source, GNU/aGPL v3, etc.. standard infusion for php-fusion. Nobody has done one that works, is secure, is free, and complies to php-fusion's standards. until now... :)

-- 
http://skpacman.hopto.org



[#] Fri Feb 24 2012 08:06:56 EST from dothebart @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]

[#] Sat Mar 03 2012 17:21:59 EST from IGnatius T Foobar @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]

Umm ... yeah. Someone spent a lot of time and money on that, but why?

[#] Sat Mar 24 2012 22:26:59 EDT from IGnatius T Foobar @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]


Some of you are going to cringe at this, but ...

I've been meaning to teach myself Python, so I can figure out what all the fuss is about. It seems to be a perennial favorite among hackers who aren't into learning the language du jour and just want something good to stick with.

There is a small program I needed to write to perform a specific task (scan a VMware ESXi server's data stores and feed that data to Xymon -- something that VMware's own API's completely suck at, but that's another story). So I decided it would be a good opportunity to bang something out in Python.
The way to really get the feel for a language is to do an actual project in it.

I don't think it'll become my absolute favorite language, but that's probably because I've been coding in C for 25 years and I don't need to "evolve" for resume/CV enhancement because I'm not a professional developer. But it does seem like a quite nice language for those times when you want to bang something out quickly -- normally I'll write shell scripts for that.

So far I'm not sold on the whole "non C like syntax" thing. I like semicolons and curly braces. I do like its use of "duck typing" though. And what's quite nice is the wealth of functionality that is available through existing libraries, many of them already installed on a typical system.

Exception handling is pretty cool. Even in my little program I've already written pieces that are self-healing by simply catching any exception and returning an error to the function's caller.

I'd definitely choose Python for a project where "managed code environment
" was a requirement. I might even consider it as an extension language for Citadel someday.

[#] Sun Mar 25 2012 21:04:45 EDT from fleeb @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]


I had to use Python for the build system at my previous job (since the previous person who worked on the build system used that language). It isn't a terrible language at all, but sometimes it gets weird (mostly related to the way it handles inclusions... there's something that seemed mysterious about it to me that shouldn't have).

I haven't used Python in a long time, though.

[#] Mon Mar 26 2012 11:09:50 EDT from wizard of aahz @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]

Build monkeys and python...

[#] Mon Mar 26 2012 12:20:35 EDT from LoanShark @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]

Exception handling is pretty cool. Even in my little program I've
already written pieces that are self-healing by simply catching any
exception and returning an error to the function's caller.

This was tongue in cheek, right? ;)

[#] Mon Mar 26 2012 14:13:02 EDT from fleeb @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]


I'm still waiting on Ford's response.

[#] Mon Mar 26 2012 14:42:40 EDT from IGnatius T Foobar @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]

Yes it's 2012 and I'm exploring the world of exception handling for the first time. Remember the part where I said I'm not a professional developer? :)

"Something went wrong over there; you should check it out" is a big change from the world I normally play in, where the response is "We're going to crash now; you'd better hope your users are smart enough to send in decent bug reports so you can fix it in the next release"

[#] Tue Mar 27 2012 07:08:15 EDT from fleeb @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]


Exceptions yank control from the normal flow of a program, which on the one hand prevents everything from getting completely out of control, but on the other hand, make it hard to determine where the fault occured sometimes. It's very, very annoying to mysteriously have an exception get thrown somewhere that kills your program, yet not have a freaking clue who threw it, and perhaps a vague notion of why.

I suppose you can have the same problem without exceptions, but as a general rule, I prefer to pay attention to all values retrieved from the functions I call, and have code in place to react to them appropriately when something is out of place (e.g. the returned file pointer is not valid, so don't try to use it, react appropriately).

[#] Tue Mar 27 2012 14:37:41 EDT from LoanShark @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]


In C++-land it's a little different than on the Java Ranch and in the Python Pit: in C++, every exception doesn't print out the stack trace of the faulting line... unless I'm quite mistaken.

[#] Tue Mar 27 2012 15:46:23 EDT from Spell Binder @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]

TCL also dumps a stack trace for an uncaught exception. Though I can't generalize, since I've not done much programming in other scripting languages, it seems like exception handling is somewhat easier in an interpreted language like TCL, Perl, or Python, than it is in a compiled language like C or C++. I know that TCL, for example, gives the programmer the ability to create their own control structures, which can make exception handling very easy.
TCL Binder

[#] Tue Mar 27 2012 16:24:48 EDT from fleeb @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]


Well, that's true. In C++, the only stack you'll get is if you're in a debugger... otherwise, you'll need the luck of the gods to help you track down an exception.

[#] Wed Mar 28 2012 09:28:15 EDT from IGnatius T Foobar @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]

Python seems to *want* the programmer to use exceptions. For example, my program uses urllib2 to fetch data via HTTPS from a remote server. If that operation fails, it throws an exception. There is no return value to check.
If you want the program to not crash you have to catch the exception. That's just how it's done.

What I found convenient was that I could put the exception handler anywhere in the stack. I was able to tell the program, "if any of that stuff up there had a problem, take this action instead of that action." Since it's a garbage collected language, I also don't have to worry about freeing this buffer or that buffer depending on which failure mode occurred.

[#] Wed Mar 28 2012 12:32:53 EDT from Spell Binder @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]

Since I'm a computer engineer and not a computer scientist, I could be off on this idea, but it seems to me that exception handling is not too far off from event-oriented programming. Your program might encounter an exception or receive an event at pretty much any time. Either your code is set up to handle it, or it gets passed up to the next level.

One other thought I had about exceptions, especially for languages that don't automatically capture a stack trace, is to use correlators. I've seen these in some library APIs from time-to-time, but didn't really understand what they were until somewhat recently.

As I understand it, a correlator is nothing more than a unique identifier that gets passed into a stack chain from a higher-level caller. For example:

int corr = 13;
int rc = myFunc(arg1, arg2, corr);
int myFunc(int a, int b, int corr) {
int c;

c = a + b;
return someOtherFunc(c, a, b, corr);
}
int someOtherFunc(int a, int b, int c, int corr) {
if (c < 0) {
printf("In function someOtherFunc, correlator=%d: %d is less than zero.\n", corr, c);
return -1;
}
return a + b + c;
}

(Pardon any coding errors, I'm a little rusty with C)

The idea is to have a unique correlator for every high-level "operation" that occurs. That way, if a lower-level function encounters an exceptional condition, the correlator can be used to trace back to the original operation.

Of course, I think it's somewhat clumsy to have to pass a correlator value into every function call. I wonder if that's one reason I haven't seen them used more often.
Correlated Binder

[#] Wed Mar 28 2012 13:10:10 EDT from fleeb @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]


For my part, I program to avoid using exceptions most of the time, and prefer to pass error values instead. I do most of my programming in C++.

When I have to use something that forces me to catch exceptions, I catch them, and react accordingly.

I also try to do the whole RIIA thing (or whatever that acronym is) where you use constructors to create resources and destructors to remove them in a clean fashion, so an exception will automatically clean things up for you.

Still, Python will allow you to walk an exception stack, as I recall, so at least you can work out why your program stopped, and take action accordingly.

Go to page: [1] 2 3 4 5 ... Last