I'm not sure if you seen this thread...

http://www.digitalmars.com/drn-bin/wwwnews?digitalmars.D/29232

~ Clay

waldemar@nxp.com wrote:
> For what it's worth, here is one guy's opinion and need.
> 
> I am considering D, becuase I am looking for a low level language complementing
> Python. I use Python becuase it is the most productive language I have ever
> seen. Incidentally, Python cites many of the same reasons for its creation as D
> does. I think that is a good sign.  
> 
> D is clearly going into the direction that I am looking for.  But it is still a
> long way from what it would need to be to bet a major project on.  That may be
> OK, Python lingered for 15 years or so before reaching the threshold of
> acceptability.  C needed more than a decade as well.
> 
> I appreciate D's compatibility with C, but my number one wish is that maybe one
> day somebody well versed in compiler design can offer compatibility in the "up"
> direction as well. Swig and company is a one way street I need something a lot
> more integrated than that.   Ideally, it would be "low level Python".   I do not
> design compilers but I have a clue and I am aware of the difficulties.  The next
> best thing would be a low level language that can be easily embedded.  But there
> is nothing remotely adequate for that purpose.  Not even D.  But maybe it could
> become one sometime. 
> 
> Waldemar
> 
> Nice language, still.
> 
> 

Matthias Becker schrieb:
>>Sorry, just had to drop my two cents here:
>>Python is as good as pascal!! i.e. it sucks for anything larger than 50 lines of code.
>>Maintainance with it is just hell!!
> 
> 
> I can't confirm that.
> 
> 
I second that. Personally I believe Python to be the most maintainable Language around. Rereading Python Code one hasn't touched for a long time is far easier than that of any C-Style language.
If we'd be speaking of PERL though, I'd agree and go as far down as 5 lines.

Regards,
Nils

waldemar@nxp.com schrieb:
> PS.: Three things D might want to borrow from Python: indents, tuples, and the %
> formatting operator. The first one eliminates the need to type those unnecessary
> braces,
Well if you're interested,
I wrote a precompiler/meta-language I dubbed PYSIC (combining the best of Python and Basic hence the name) that lets you write Code for C-Style languages (C(++), D, Java etc.) by using a Python-like syntax with BASIC variable declaration inbetween. I don't have a complete documentation for it yet since it was intended for personal use only, but I could send you the fully commented Python script the program consists of.
It certainly sweetens my life by letting me concentrate on content instead of form but that just might be me.

Regards,
Nils

That's pretty good.  Thanks.

Maybe it's just a matter of writing a proper d module for python.  David's little test project, though, seems like a one person experiment. Maybe it can grow to a more widely recognized effort.  But that's very very interesting.


In article <dl51un$2v3u$1@digitaldaemon.com>, clayasaurus says...
>
>I'm not sure if you seen this thread...
>
>http://www.digitalmars.com/drn-bin/wwwnews?digitalmars.D/29232
>
>~ Clay
>

Oooh that was a silly suggestion, wasn't it?  (indents)

However the other two are legit.

Tuples.  Should not be that hard.  Seems like anonymous structures are almost it.  However, syntactic support throughout the language is what makes them so sweet.

% formatting operator.  This one's even easier probably.  Just a call to sprintf with a garbage collected buffer.  A few special cases, maybe.  Again, it's the consistent syntax that makes it so great.


In article <dl4qbh$2pha$1@digitaldaemon.com>, Ivan Senji says...
>
>Agent Orange wrote:
>> I think I would rather gouge outmy eyeballs with a rusty spoon than use a language that actually enforced indentations as grammar. python is cute but ive even had to debug 'misindented' code - it was one of the dumbest things ive ever seen....
>> 
>
>You couldn't have said it better.

Nils Hensel wrote:
> Matthias Becker schrieb:
> 
>>> Sorry, just had to drop my two cents here:
>>> Python is as good as pascal!! i.e. it sucks for anything larger than 50 lines of code.
>>> Maintainance with it is just hell!!
>>
>>
>>
>> I can't confirm that.
>>
>>
> I second that. Personally I believe Python to be the most maintainable Language around. Rereading Python Code one hasn't touched for a long time is far easier than that of any C-Style language.
> If we'd be speaking of PERL though, I'd agree and go as far down as 5 lines.
> 
> Regards,
> Nils

Well, let's just say that my prof is making us program assignments in python! and I didn't really like it.
I'll admit that I wrote a 250 lines-of-code program which would probably take 1000 lines in D, but that's mainly because I would use so many braces { } where each one takes up one extra line!

As for maintainability, I just felt that it's not very easy to track down what is happening, since there aren't really any types, and I'm not always sure what a certain variable is used to represent. Plus it encourages what I consider to be bad habits, such as using the built-in list to represent vectors, instead of writing a vector class; it's bad because things get messy when you have a list of "vectors" or a list of a list of "vectors", etc, i.e. when things get a bit complicated.

My feeling stays that it's not really good for any medium program. I said above "no more than 50 lines of code", well, that's very true for pascal, but for python, maybe the limit is a 1000 lines or something. I just don't find it feasable!

.
.
.

Or maybe I'm just in denile.

ouch, sorry, double post, don't know why it happened :/

Hasan Aljudy wrote:
> Nils Hensel wrote:
> 
>> Matthias Becker schrieb:
>>
>>>> Sorry, just had to drop my two cents here:
>>>> Python is as good as pascal!! i.e. it sucks for anything larger than 50 lines of code.
>>>> Maintainance with it is just hell!!
>>>
>>>
>>>
>>>
>>> I can't confirm that.
>>>
>>>
>> I second that. Personally I believe Python to be the most maintainable Language around. Rereading Python Code one hasn't touched for a long time is far easier than that of any C-Style language.
>> If we'd be speaking of PERL though, I'd agree and go as far down as 5 lines.
>>
>> Regards,
>> Nils
> 
> 
> Well, let's just say that my prof is making us program assignments in python! and I didn't really like it.
> I'll admit that I wrote a 250 lines-of-code program which would probably take 1000 lines in D, but that's mainly because I would use so many braces { } where each one takes up one extra line!
> 
> As for maintainability, I just felt that it's not very easy to track down what is happening, since there aren't really any types, and I'm not always sure what a certain variable is used to represent. Plus it encourages what I consider to be bad habits, such as using the built-in list to represent vectors, instead of writing a vector class; it's bad because things get messy when you have a list of "vectors" or a list of a list of "vectors", etc, i.e. when things get a bit complicated.
> 
> My feeling stays that it's not really good for any medium program. I said above "no more than 50 lines of code", well, that's very true for pascal, but for python, maybe the limit is a 1000 lines or something. I just don't find it feasable!
> 
> .
> .
> .
> 
> Or maybe I'm just in denile.

Hasan Aljudy schrieb:
> Well, let's just say that my prof is making us program assignments in python! and I didn't really like it.
> I'll admit that I wrote a 250 lines-of-code program which would probably take 1000 lines in D, but that's mainly because I would use so many braces { } where each one takes up one extra line!
That might be a greater advantage than you think it is. Less code usually means less bugs.


> As for maintainability, I just felt that it's not very easy to track down what is happening, since there aren't really any types, and I'm not always sure what a certain variable is used to represent.
That's not quite true (I'm talking about the facts now, not your feelings :). Just because Python is dynamically typed doesn't mean the variables don't have a type. The type is declared on assignment and does not change unless you reassign to the variables name. Basically all variables in Python are references not BASIC-like variants. There is no implicit type conversion and you can test for the variables type at runtime.
I believe you refer to function interfaces in which you don't specify the type of the parameters. I think that this is a huge advantage for it let's you implement polymorphic code with ease without having to declare dozens of alternative interfaces or templates. But I can see that this might threaten less confident programmers.


> Plus it encourages what I consider to be bad habits, such as using the built-in list to represent vectors, instead of writing a vector class; it's bad because things get messy when you have a list of "vectors" or a list of a list of "vectors", etc, i.e. when things get a bit complicated.
Again I don't believe this to be a problem. Complicated data structures are always complicated, in any language. Using the built-in list (that behind the scenes actually is not a list but a dynamic array. See link below, topic 6.16) is a good decision. You can be sure that this is a tested and optimized piece of software that is also very powerful. Also you may derive from it if you need specialized behaviour.
Besides, what would you want to build your vector class on, if not the built-in list? Write your own C(++) module and hope your implementation is better?

http://mail.python.org/pipermail/python-announce-list/1999-July/000107.html
Python Language FAQ - Section 6


> My feeling stays that it's not really good for any medium program. I said above "no more than 50 lines of code", well, that's very true for pascal, but for python, maybe the limit is a 1000 lines or something. I just don't find it feasable!
My experience is that it is the best programming language for any project that is not runtime- or distributable-size-critical. The latter being the bigger problem since you can quite easily extend python programs by C(++) modules. But still that doesn't mean that you have to like it.


> Or maybe I'm just in denile.
No, you're just arguing emotionally. But if you are not too appalled by Python already than I consider you give it a fair second thought for it stands very well in comparison.

Regards,
Nils

In article <dlevet$k7v$1@digitaldaemon.com>, Nils Hensel says...
>
>Hasan Aljudy schrieb:
>> Plus it encourages what I consider to be bad habits, such as using the built-in list to represent vectors, instead of writing a vector class; it's bad because things get messy when you have a list of "vectors" or a list of a list of "vectors", etc, i.e. when things get a bit complicated.
>Again I don't believe this to be a problem. Complicated data structures
>are always complicated, in any language. Using the built-in list (that
>behind the scenes actually is not a list but a dynamic array. See link
>below, topic 6.16) is a good decision. You can be sure that this is a
>tested and optimized piece of software that is also very powerful. Also
>you may derive from it if you need specialized behaviour.
>Besides, what would you want to build your vector class on, if not the
>built-in list? Write your own C(++) module and hope your implementation
>is better?

Sorry, I meant a Math vector, as in a point (x,y), not an array.

What I'm talking about is using "primitive" (kind of) structures to represent data, which kind of goes against what I've been tought in the OOP course. You know, this might not be much of a problem for a 250 lines program, but I suspect that it'll get more complicated as the project size grows.

Plus, I'm comparing to D, not C++.

Hasan Aljudy schrieb:
> Sorry, I meant a Math vector, as in a point (x,y), not an array.
Oops, my bad!

> What I'm talking about is using "primitive" (kind of) structures to represent
> data, which kind of goes against what I've been tought in the OOP course.
> You know, this might not be much of a problem for a 250 lines program, but I
> suspect that it'll get more complicated as the project size grows.
I see. I agree that this is a stupid idea as long as a vector is more than a mere representation of two (or more) connected values. If it's an object with methods to be performed on, it definitely belongs in its own class.
But I don't think Python encourages you to use stupid techniques. Nothing stops you from writing your own vector class. I mean in what way does D stop you from representing vectors as double[2]?
Poor  design is IMHO not so much a matter of language (PERL propably being an exception) but more of the general ability of telling shit from shoe polish ;-)

> Plus, I'm comparing to D, not C++.
Yes, I noticed. I just mentioned C(++) because Python's API is written in C hence it is the usual choice for extension modules. But you may as well use D.


Regards,
Nils