Thread: C or python or perl?

Originally Posted by Poincare

Will i be laughed at if I use one the interpreted langs?

Maybe by your grandparents and a few stragglers living in caves, etc.

One thing that I have done before and that I believe many other people do, altho I don't know the term for it, is work some functionality (such as an algorithm) out in perl, since the amount of coding is orders of magnitude less, and then implement it in C -- so I focus on high level concerns, and then the lower level nitty gritty optimization. Both perl and python are written in C (I think python leans on C++ more for extensions, maybe that is why perl is faster ), and I will say that at least with perl it is surprising the extent to which you can "see the relationship" even when the syntax is quite different, altho perl does often explicitly and directly rely on the same semantics as the underlying C functions. I haven't used python for much except "gimp-fu", so I don't know as much about it.

I use both C and perl on a daily basis and cannot claim to have done anything in one language that I cannot do in the other, and I don't feel I'm "better" in one or the other either, this is just the reality of what they are I suppose.

If your problem is seg faults, which are usually about memory management, and error reporting, which is generally better with interpreted languages, then go for it. While perl has much larger available set of libraries/modules, like second to nothing, and maybe better on-line resources, I would say python is less idiosyncratic, much easier to learn, more normative OO and with a very rapidly growing user base, so it might be better for you. They will both do want you want, anyway; perl has been used to do high performance 3D graphics and is widely used in scientific research, such as bioinformatics; I imagine the same is true of python.

Scripting languages rock, don't let anyone tell you otherwise.

You can try C++ too. It's fast (as fast as C) and has functionality / ease to match python/perl.

Originally Posted by Elysia

You can try C++ too ... ease to match python/perl.

Not in everything. Good luck with quick, dirty string processing

> I've been trying to write a math engine in C. Well, i've had a really really really hard time parsing all the inputs and stuff
How are you parsing things? You could always use a lexer like flex.

Python. Python is my dirty lover, and it's been good to me.

It's possible switching to C++ might help you in this case, if it helps you with memory management. I believe the majority of the coders using languages purely for math algorithms use C though, and Python for quick testing. I remember a lot of complaints about Python's core global interpreter lock. So computing an algorithm in parallel is blocked (threads are useless) - think there's a workaround.

Originally Posted by Sebastiani

Patently untrue. I've written many parsers and other various string-processing routines in C++ without any headaches whatsoever. Not only can it be just as easy as with an interpreted language, it can be much more so (thanks to operator-overloading, among other things), and also much more powerful and flexible (thanks to templates, your code works with arbitrary types (char, float, a custom type, etc), and parses not just "flat" char* strings, but any kind of object that can be iterated (lists, vectors, files)). Try getting *that* to work with perl or python!

I dunno bro, Python's string parsing is so much more convenient and readable. In the long-run it doesn't matter, but scripting languages are masters of the short-run.

someString[5:10]

Originally Posted by Dae

Python. Python is my dirty lover, and it's been good to me.

It's possible switching to C++ might help you in this case, if it helps you with memory management. I believe the majority of the coders using languages purely for math algorithms use C though, and Python for quick testing. I remember a lot of complaints about Python's core global interpreter lock. So computing an algorithm in parallel is blocked (threads are useless) - think there's a workaround.



I dunno bro, Python's string parsing is so much more convenient and readable. In the long-run it doesn't matter, but scripting languages are masters of the short-run.

someString[5:10]

Hmm, let's see:

Code:

/*
    Read a phone number in the format (XXX) XXX-XXXX
*/
template < typename Iterator, typename Result >
bool read_phone_number
( 
	Iterator begin, 
	Iterator end, 
	Result& area_code, 
	Result& exchange, 
	Result& extension 
)
{
	using namespace 
		xtd::parser;
	static syntax< >
		ws = skip( token_range( " \n\t" ) ),
		lp = ws + '(' + ws, 
		rp = ws + ')' + ws, 
		dash = ws + '-' + ws,
		digit = terminal_range( '0', '9' ),	
		digits_3 = ws + ( digit * 3 ) + ws, 
		digits_4 = ws + ( digit * 4 ) + ws;
	return
	(
		lp + ( digits_3 >> store( area_code ) ) + rp 
		+ ( digits_3 >> store( exchange ) ) + dash 
		+ ( digits_4 >> store( extension ) )
	).parse_all( begin, end );
}

template < typename Container, typename Result >
inline bool read_phone_number
( 
    Container const& data, 
    Result& area_code, 
    Result& exchange, 
    Result& extension 
)
{
    return read_phone_number( data.begin( ), data.end( ), area_code, exchange, extension );
}

That's a very simple example, of course, but extending it to accept more formats would be trivial. And note that the parser doesn't skip whitespace by default, but that could be easily built into a library, if desired.

Here's a sample test program:

Code:

int main( void )
{
    string
        input_as_string = "( 800 )555 - 1212";
    list< int >
        input_as_list_of_ints( input_as_string.begin( ), input_as_string.end( ) );
    vector< double >
        numbers_as_doubles( 3 );
    vector< int >
        numbers_as_ints( 3 );
    assert
    ( 
        read_phone_number
        ( 
            input_as_string, 
            numbers_as_doubles[ 0 ], 
            numbers_as_doubles[ 1 ], 
            numbers_as_doubles[ 2 ] 
        )
    );    
    assert
    ( 
        read_phone_number
        ( 
            input_as_list_of_ints, 
            numbers_as_ints[ 0 ], 
            numbers_as_ints[ 1 ], 
            numbers_as_ints[ 2 ] 
        )
    );            
    copy
    ( 
        numbers_as_doubles.begin( ), 
        numbers_as_doubles.end( ), 
        ostream_iterator< double >( cout, "\n" ) 
    );
    copy
    ( 
        numbers_as_ints.begin( ), 
        numbers_as_ints.end( ), 
        ostream_iterator< int >( cout, "\n" ) 
    );
    return 0;
}

Now it may seem silly to pass the input as a list< int > or place the result into a double, but my point is that it is incredibly flexible, and AFAIK would quite complicated to work out with a scripting language (correct me if I'm wrong though).

Besides all of this, the parsing is done roughly as fast as had you done it "by hand" (maybe 5% slower, max).

Anyway, so my whole point is that C++ is more than adequate for this sort of thing (although you may need to do a fair bit of coding, initially). Not that I think there's anything wrong with using a scripting language, either - I'm just defending C++ position as a contender.

EDIT:
OK, well the assertion failed. Wrong grammer. Fixed.

Originally Posted by Elysia

has functionality / ease to match python/perl.

Good luck with everything from the first character on. That is way way WAY out to lunch...do you know what a sigil is? Etc. These things are worlds apart by design and necessity. The more complex the demo you propose, the further apart the byte counts for the source will become. I promise. At around 2-300 lines, with the perl version less than 50, this difference starts to seem extremely significant.

Vis. math parsing, I wrote this a while ago for something (in C), you can take a look; the first two do roman numerals, the third one does normal expressions like (2+2)*7, with commentary:

http://www.intergate.com/~halfcountp...P/parsing.html

Originally Posted by Sebastiani

I wasn't quoting you, actually. But if I may:



So which is it?

Anyway, my main argument was simply that C++ is equally as useful (and indeed "the right tool for the job"). How exactly does that make "no sense to begin with"? As I said, I was merely defending the language, really. I don't mind people promoting scripting languages - they are, obviously, also quite useful (I use them almost every day) - but when I hear claims to the effect that they leave languages such as C++ "in the dust"...that's just nonsense, pure and simple.

The reason it makes no sense, Sebastiani, is because C/C++ maybe be quick and easy for you, but the topic is the OP (original poster) not you. He's just learning the language, and keeps running into seg faults. Do you honestly thing he won't save a serious amount of time using a scripting language, versus learning the intricacies of C/C++? You know C++ so well your syntax emulates the C++ standard library (like a lot of people here). That code you wrote up may be easy for you but the OP would have to learn a lot more subjects and syntax to use it, let alone create it himself (it takes a certain experience, without googling everything - and I mean everything - and possibly asking questions), compared to a scripting language. I've never even used xtd. Even I'd have to learn that library. On the other hand I've used the exact same perl-style regular expressions in Perl, PHP, JavaScript, Python, and C++ (but ran into difficulties with string literals and learning the boost::regex library).

It's almost like your recommendation is learn C++ for 5 years, then you will be able to produce code using C++ as efficiently as you would in Python. I will say if someone knew C++ as well as you, they shouldn't use Python (unless maybe web based). Fact. I know C++ less than you do, and I still won't use Python for most projects. I'm willing to put in the time to learn it. I recommend learning both though, as they both teach you a lot about computer science (C++ more-so, and Python quicker - ie Java argument - Java 2x faster than C++, Python 2x faster than C++ - for newbies).

True, sorry I don't mean to bicker but since you mention it...

Originally Posted by Sebastiani

How many newcomers to C++ do you think actually understand the internals of the the STL? And yet, they use these powerful tools every day.

It's not whether they understand the internals of the STL, STD, Boost, or whatever. It's whether they can use them, right off the bat, as fast and easy as any scripting language. The answer is no.

Yes, the libraries are a benefit. I'm able to find most of what I need within Boost, but it's certainly not as easy when you're first getting started.

Originally Posted by Sebastiani

You could even design a C++ library that is just as "user-friendly" and de-fanged as any scripting language, dynamic-type system, and all.

In some most cases yes, but you've seen boost::lambda. It does a lot to bridge that gap, but without the compiler (or some compiler feature), it's not as simple as scripting languages. Normally you merely wrap any code in brackets instant lambda or inline functor. Without reading docs on _1 _2, bind, ref, constant, var, for_each, if_ this, else_ that, or other. Hence C++0x lambdas, which should be convenient when they work entirely. Boost::tuple is syntactically not as simple and easy to use as Python. There's dozens of examples. These libraries are inhibited by the compiler (the standard).

For example I doubt you'll see something in C++ like boost::any without casting

There's reasons, I know. It's not all that hard, I know. The OP is having troubles with C, so I don't see how recommending an extension of C is even on topic ("C or python or perl"). Given his position, Python would be a whole heck of a lot faster and easier than C (or C++). The whole scripting languages vs C/C++ topic is in RELATION to the OP, not you, or me.

Originally Posted by Sebastiani

When it get's right down to it, *either* (or even both) can be used to get the job done.

Yup, and the original topic was the difficulty of the chosen language (and if using a scripting language would be embarrassing). Not which one can get the job done - that's just obvious.