www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - I am considering D

reply waldemar nxp.com writes:
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.
Nov 05 2005
next sibling parent reply "Walter Bright" <newshound digitalmars.com> writes:
<waldemar nxp.com> wrote in message news:dkjoa6$2m30$1 digitaldaemon.com...

 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.


I'm not exactly sure what you're asking for. C++ compatibility?
Nov 06 2005
parent reply clayasaurus <clayasaurus gmail.com> writes:
Walter Bright wrote:

 <waldemar nxp.com> wrote in message news:dkjoa6$2m30$1 digitaldaemon.com...
 

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.


 
 
 I'm not exactly sure what you're asking for. C++ compatibility?
 
 


I think he wants a low level language that has builtin support for 
calling python code, or can be easily embedded into python.
Nov 07 2005
parent reply waldemar nxp.com writes:
Right, I do not need C++ compatibility.

Python is deceptively attractive until one runs into performance problems which
invariably leads to a painful drift toward C/C++.  BTW, I have looked at Boo.
Looks great on paper but how fast is it?

D is still in play in my project becaue it is fast.  If I gravitate away from
Python toward D, that's a better alternative for me than C.  Even if it works
one way only.  Unfortunately, there is no direct path to D, it can only be done
(maybe) with a C wrapper around D.  What a hassle.  I do not know very many
program managers putting up with it.

So there is my case.

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, kills the never ending fights over the "coding standards", and removes
the necessity to match the parentheses all the time. The second one is an
extremely handy vehicle for handling small sets of data as well as for dealing
with mutliple input/output parameters.  The third one properly decouples
formatting from i/o which should have been done long long time ago.

In article <436F87A5.4030802 gmail.com>, clayasaurus says...

Walter Bright wrote:

 <waldemar nxp.com> wrote in message news:dkjoa6$2m30$1 digitaldaemon.com...
 

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.


 
 
 I'm not exactly sure what you're asking for. C++ compatibility?
 
 


I think he wants a low level language that has builtin support for 
calling python code, or can be easily embedded into python.
Nov 11 2005
next sibling parent reply Agent Orange <no spam.com> writes:
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....


waldemar nxp.com wrote:

 Right, I do not need C++ compatibility.
 
 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, kills the never ending fights over the "coding standards", and removes
 the necessity to match the parentheses all the time. The second one is an
 extremely handy vehicle for handling small sets of data as well as for dealing
 with mutliple input/output parameters.  The third one properly decouples
 formatting from i/o which should have been done long long time ago.
 
 In article <436F87A5.4030802 gmail.com>, clayasaurus says...
 

Walter Bright wrote:


<waldemar nxp.com> wrote in message news:dkjoa6$2m30$1 digitaldaemon.com...



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.



I'm not exactly sure what you're asking for. C++ compatibility?


I think he wants a low level language that has builtin support for 
calling python code, or can be easily embedded into python.
Nov 12 2005
next sibling parent "Ameer Armaly" <ameer_armaly hotmail.com> writes:
"Agent Orange" <no spam.com> wrote in message 
news:dl4fsj$2h1p$1 digitaldaemon.com...

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


Yeah really- try working with indentation as a blind guy like myself; the 
primary reason I've never used it :).

 waldemar nxp.com wrote:

 Right, I do not need C++ compatibility.

 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, kills the never ending fights over the "coding standards", and 
 removes
 the necessity to match the parentheses all the time. The second one is an
 extremely handy vehicle for handling small sets of data as well as for 
 dealing
 with mutliple input/output parameters.  The third one properly decouples
 formatting from i/o which should have been done long long time ago.

 In article <436F87A5.4030802 gmail.com>, clayasaurus says...


Walter Bright wrote:


<waldemar nxp.com> wrote in message 
news:dkjoa6$2m30$1 digitaldaemon.com...



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.



I'm not exactly sure what you're asking for. C++ compatibility?


I think he wants a low level language that has builtin support for 
calling python code, or can be easily embedded into python.
Nov 12 2005
prev sibling parent reply Ivan Senji <ivan.senji_REMOVE_ _THIS__gmail.com> writes:
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.
Nov 12 2005
parent waldemar nxp.com writes:
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.
Nov 13 2005
prev sibling next sibling parent reply Hasan Aljudy <hasan.aljudy gmail.com> writes:
waldemar nxp.com wrote:

 Right, I do not need C++ compatibility.
 
 Python is deceptively attractive until one runs into performance problems which
 invariably leads to a painful drift toward C/C++.  BTW, I have looked at Boo.
 Looks great on paper but how fast is it?
 
 D is still in play in my project becaue it is fast.  If I gravitate away from
 Python toward D, that's a better alternative for me than C.  Even if it works
 one way only.  Unfortunately, there is no direct path to D, it can only be done
 (maybe) with a C wrapper around D.  What a hassle.  I do not know very many
 program managers putting up with it.
 
 So there is my case.
 
 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, kills the never ending fights over the "coding standards", and removes
 the necessity to match the parentheses all the time. The second one is an
 extremely handy vehicle for handling small sets of data as well as for dealing
 with mutliple input/output parameters.  The third one properly decouples
 formatting from i/o which should have been done long long time ago.
 
 In article <436F87A5.4030802 gmail.com>, clayasaurus says...
 

Walter Bright wrote:


<waldemar nxp.com> wrote in message news:dkjoa6$2m30$1 digitaldaemon.com...



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.



I'm not exactly sure what you're asking for. C++ compatibility?


I think he wants a low level language that has builtin support for 
calling python code, or can be easily embedded into python.


 
 
 



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!!
Nov 12 2005
parent reply Matthias Becker <Matthias_member pathlink.com> writes:
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.
Nov 12 2005
parent reply Nils Hensel <nils.hensel web.de> writes:
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
Nov 13 2005
parent reply Hasan Aljudy <hasan.aljudy gmail.com> writes:
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.
Nov 16 2005
next sibling parent Hasan Aljudy <hasan.aljudy gmail.com> writes:
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.
Nov 16 2005
prev sibling parent reply Nils Hensel <nils.hensel web.de> writes:
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
Nov 16 2005
parent reply Hasan Aljudy <Hasan_member pathlink.com> writes:
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++.
Nov 16 2005
parent Nils Hensel <nils.hensel web.de> writes:
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
Nov 16 2005
prev sibling parent Nils Hensel <nils.hensel web.de> writes:
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
Nov 13 2005
prev sibling next sibling parent "Lionello Lunesu" <lio remove.lunesu.com> writes:
 Ideally, it would be "low level Python".


Have a look at Boo.
http://boo.codehaus.org/

L.
Nov 07 2005
prev sibling parent reply clayasaurus <clayasaurus gmail.com> writes:
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.
Nov 12 2005
parent waldemar nxp.com writes:
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
Nov 13 2005