www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Lisp vs. C++ (not off-topic)

reply Josh Stern <josh_usenet phadd.net> writes:
This old blog doesn't mention D, but I think it is good and really
relevant anyway:

http://userpages.umbc.edu/~bcorfm1/C++-vs-Lisp.html

IMO, it points to a set of issues that relate to how D (and its libraries)
have the potential to allow developers to be a lot more productive than
they are with C++.   Particularly relevant D features related to
the points mentioned there include but are not limited to  GC, mixins,
regex, and elimination of header/instantiation separation.   The point
about the productivity benefits of creating interfaces that return the
most interesting value (maybe alongside the interface that allows the
greatest efficiency when optimizing) is a good one to remember in practice.
Oct 10 2006
next sibling parent reply Makaan <saadjuuk haigara.com> writes:
I think the number of lines is over rated. This is a very simple example and
doesn't really compare anything useful. Lisp may have fewer lines but the number
of parenthesis counter balances this.

It really needs to compare something more complicated like a telephone PBX
exchange. Lisp has a number of advantages including built in lists and this is a
list problem.  It doesn't compare anything except the implementation of lists of
data and should focus on something much more complex with larger variables like
a
3d game engine.
Oct 10 2006
parent Josh Stern <josh_usenet phadd.net> writes:
On Tue, 10 Oct 2006 20:01:10 +0000, Makaan wrote:


 I think the number of lines is over rated.


I guess it depends on who is rating and how they do it.  The most obvious
problem with line counting is that it doesn't insure an apples-to-apples
comparison unless there is some way to hold quality relatively
constant.   Using small explicit tasks is one way to try to achieve the
latter.


This is a very simple example and
 doesn't really compare anything useful. Lisp may have fewer lines but
 the number of parenthesis counter balances this.


What they actually measured in the referenced study was the amount of time
the coding took to complete the task.  If problems with LISP syntax still
hurt productivity of experienced developers then that would have already
been factored into the comparison.  

Looking at lines of code wasn't the base measure of productivity - it
was rather the blog author's attempt to try and explain the amount of time
it took. But my understanding parallels his in the sense that studies
which have looked at larger projects still found number of lines of code
required to be about the best predictor of the amount of time required for
a given type of project - i.e. you can't compare app coding to real-time
embedded coding, but you can you can compare across similar tasks, and
some say lines of similar quality across similar task is a way to look at
the effect of the programming language on productivity. That doesn't mean
it's a great predictor -  but it seems as good as anything else people
have come up with.


 It really needs to compare something more complicated like a
telephone
 PBX exchange. Lisp has a number of advantages including built in lists
 and this is a list problem.  It doesn't compare anything except the
 implementation of lists of data and should focus on something much more
 complex with larger variables like a 3d game engine.


At least the author of the blog was taking library data structures like
lists and hashmaps for granted, so that wasn't the issue per se, though he
finds fault with the existing interfaces from a productivity point of
view.
Oct 10 2006
prev sibling next sibling parent reply Walter Bright <newshound digitalmars.com> writes:
Josh Stern wrote:

 This old blog doesn't mention D, but I think it is good and really
 relevant anyway:
 
 http://userpages.umbc.edu/~bcorfm1/C++-vs-Lisp.html
 
 IMO, it points to a set of issues that relate to how D (and its libraries)
 have the potential to allow developers to be a lot more productive than
 they are with C++.   Particularly relevant D features related to
 the points mentioned there include but are not limited to  GC, mixins,
 regex, and elimination of header/instantiation separation.   The point
 about the productivity benefits of creating interfaces that return the
 most interesting value (maybe alongside the interface that allows the
 greatest efficiency when optimizing) is a good one to remember in practice.



It is a very interesting article for anyone wanting to carefully look at 
language differences. Anyone care to try a D version following the 
original challenge?

    http://www.flownet.com/ron/papers/lisp-java/
Oct 10 2006
next sibling parent Lionello Lunesu <lio lunesu.remove.com> writes:
Walter Bright wrote:

 Josh Stern wrote:

 This old blog doesn't mention D, but I think it is good and really
 relevant anyway:

 http://userpages.umbc.edu/~bcorfm1/C++-vs-Lisp.html

 IMO, it points to a set of issues that relate to how D (and its 
 libraries)
 have the potential to allow developers to be a lot more productive than
 they are with C++.   Particularly relevant D features related to
 the points mentioned there include but are not limited to  GC, mixins,
 regex, and elimination of header/instantiation separation.   The point
 about the productivity benefits of creating interfaces that return the
 most interesting value (maybe alongside the interface that allows the
 greatest efficiency when optimizing) is a good one to remember in 
 practice.


 
 
 It is a very interesting article for anyone wanting to carefully look at 
 language differences. Anyone care to try a D version following the 
 original challenge?
 
    http://www.flownet.com/ron/papers/lisp-java/



It was sooo easy in D! I got it done in 1 hour 15 minutes.. But, my 
results differ from theirs and I can't figure out why.

For example, my prog comes up with "3-/0--69-4: 3 echt", which seems 
correct ("echt" is in the dictionary and is coded as "0694"), but their 
output.txt has nothing for the phone number "3-/0--69-4" ???

L.
Oct 11 2006
prev sibling next sibling parent reply Lionello Lunesu <lio lunesu.remove.com> writes:
I give up. I can't figure out why those phone numbers are missing from 
their output.

I've attached what I have so far. It's pretty nice, readable, and uses 
quite a few of D goodies ;)

L.
Oct 11 2006
next sibling parent reply AndBre <nospam nowhere.null> writes:
On Wed, 11 Oct 2006 13:45:29 +0300, Lionello Lunesu wrote:


 I give up. I can't figure out why those phone numbers are missing from
 their output.
 
 I've attached what I have so far. It's pretty nice, readable, and uses
 quite a few of D goodies ;)
 
 L.
It was sooo easy in D! I got it done in 1 hour 15 minutes.. But, my 
results differ from theirs and I can't figure out why.

For example, my prog comes up with "3-/0--69-4: 3 echt", which seems 
correct ("echt" is in the dictionary and is coded as "0694"), but their
output.txt has nothing for the phone number "3-/0--69-4" ???
 L.


I just looked in the dictionary and "etch" isn't there. Maybe you are
searching for "etch" and find "Sketch", "Ketchup"? If this is the case you
can just look for the word preceeded by \n. Hope this helps.
Can you repost your code I cannot see your attachment.
AndBre
Oct 11 2006
parent AndBre <nospam nowhere.null> writes:
 I just looked in the dictionary and "etch" isn't there. Maybe you are
 searching for "etch" and find "Sketch", "Ketchup"? If this is the case you
 can just look for the word preceeded by \n. Hope this helps.
 Can you repost your code I cannot see your attachment.
 AndBre


Sorry I mispelled the word, you are right, it is in the dictionary.
AndBre
Oct 11 2006
prev sibling next sibling parent reply Walter Bright <newshound digitalmars.com> writes:
How does the speed stack up with the C++ version?
Oct 12 2006
parent Lionello Lunesu <lio lunesu.remove.com> writes:
Walter Bright wrote:

 
 How does the speed stack up with the C++ version?


My version in D seems more straightforward than either C++ version on 
that site, so they can't really be compared. I'd have to port my D 
version to C++, but I don't know enough STL and am reluctant to learn it.

Doing the task in D was just incredible easy and straightforward. And 
the result runs faster than that C++ version, which is not really saying 
much about D, knowing the excess string conversions in the C++ version.

L.
Oct 13 2006
prev sibling parent reply Lionello Lunesu <lio lunesu.remove.com> writes:
While trying to understand the c++ implementation, I found out what the 
problem was. The c++ version does not allow a digit at position k if 
there's a word in the dictionary that matches the digits at k..n, even 
if that word cannot actually be used in the encoding because of a 
mismatch anywhere after n.

For example 30694, there IS a word matching "306", "sei" and therefor, 
the result "3-/0--69-4: 3 echt" is not considered..

L.
Oct 13 2006
parent reply Don Clugston <dac nospam.com.au> writes:
Lionello Lunesu wrote:

 While trying to understand the c++ implementation, I found out what the 
 problem was. The c++ version does not allow a digit at position k if 
 there's a word in the dictionary that matches the digits at k..n, even 
 if that word cannot actually be used in the encoding because of a 
 mismatch anywhere after n.
 
 For example 30694, there IS a word matching "306", "sei" and therefor, 
 the result "3-/0--69-4: 3 echt" is not considered..
 
 L.


So the C++ version wasn't merely more complicated and slower than D, it 
was also wrong??
Oct 13 2006
parent reply "Lionello Lunesu" <lionello lunesu.remove.com> writes:
"Don Clugston" <dac nospam.com.au> wrote in message 
news:egoc9c$lfm$1 digitaldaemon.com...

 Lionello Lunesu wrote:

 While trying to understand the c++ implementation, I found out what the 
 problem was. The c++ version does not allow a digit at position k if 
 there's a word in the dictionary that matches the digits at k..n, even if 
 that word cannot actually be used in the encoding because of a mismatch 
 anywhere after n.

 For example 30694, there IS a word matching "306", "sei" and therefor, 
 the result "3-/0--69-4: 3 echt" is not considered..

 L.


 So the C++ version wasn't merely more complicated and slower than D, it 
 was also wrong??


I would say: yes :)

But, I don't really know what's right and what's wrong, since the 
description could be interpreted either way. I'd say the way the C++ version 
is doing it makes no sense logically.. The fact that there's a word "sei" in 
the dictionary should not prevent a good result "3 echt" from being 
considered.

L.
Oct 13 2006
parent reply Walter Bright <newshound digitalmars.com> writes:
Lionello Lunesu wrote:

 But, I don't really know what's right and what's wrong, since the 
 description could be interpreted either way. I'd say the way the C++ version 
 is doing it makes no sense logically.. The fact that there's a word "sei" in 
 the dictionary should not prevent a good result "3 echt" from being 
 considered.


Could you put together a web page with the results? Or just text, I can 
turn it into a web page.
Oct 13 2006
next sibling parent Lionello Lunesu <lio lunesu.remove.com> writes:
Walter Bright wrote:

 Lionello Lunesu wrote:

 But, I don't really know what's right and what's wrong, since the 
 description could be interpreted either way. I'd say the way the C++ 
 version is doing it makes no sense logically.. The fact that there's a 
 word "sei" in the dictionary should not prevent a good result "3 echt" 
 from being considered.


 
 Could you put together a web page with the results? Or just text, I can 
 turn it into a web page.


Sure thing!
Oct 15 2006
prev sibling parent reply "Lionello Lunesu" <lionello lunesu.remove.com> writes:
 Could you put together a web page with the results? Or just text, I can
 turn it into a web page.


Here it is!

Feel free to check my english and fix it :)

L. 


begin 666 lisp-java-d.zip

M;+5:;7/;N!'^WIG^AXW;N4 ]F;3D=\M6)V?G6E]SN6OB-FT33X<2(8EGBF )
MTHZ;YGY[GUWP!:3DV&VG\EB42&"QV'UV]P& TV<7/YQ?_?7'E[3,5S']^*=O
M7EV>T]:V[[_;/??]BZL+^OW5]Z]HS]L9TE46)";*(YT$L>^_?+WURU\07EO+
M/$]/?/_N[LZ[V_5TMO"OWO L;\^/M3;*"_-P:_++7YSRO8GM=+I405A^EN]Y
ME,=J\BHR*=T:C[X+; //\^CBMW3JVV=.8Y/?QXKR^U2=;>7J8^[/C-F:T%2'
M]_2)9CK6V0E-XV!V,Z8IWA>9+I+PA.Z64:[&]-F*FKIMB^9^T=S/51"/B8?8
M#M5,9P'/_H02G33-HZ;Y(E,JJ1^DF<(C=_Q?*7F-:15DBPB"1COIQ\X;--99


M6D1Y$&.:QIOIE1_Z039;1K?*^,XC_\*/DE!]]! 86XY&U<L5<T&)NC-LR?34
M#R8
M9 L]J +WI5"9619->>8!W*KAC]6*O\V601RK9*%8)5 CR.DN,*0S*(XHB>\)
MXX<P'?JU99N\`%CQ`)B<+6GWB,X'!(5 Z5!<58^C, /?`$N!N;&SO,L`8[K%


M$S;R  30>9$E,(8N<I[C%,:A6:R"C.ZB)(&^&M9IIMR6S :X6T+]4C+\&*I;
M%>MTI1+(BU9*> %<2JP[TZ$:0'*^E.EFG E">!"-N'-;.B 03%FO$2UUD9FR

M[*[ASF%[.MZ:L]^QED9#JHB&50WC9D"7$*N+Q3+')P OXI 6B&2*,%'*LWM:
MW1L5SSUZ$=N&=/E\M89(-GH#HK(/]5CK90!I4V1.FL,(PQVZAR,-3'37=T?'
M>'<RNGB[+1V)%W;7:8JY%TF4W[/^8H75/9F;*(X-Q]K3T]76Y((V) ,G].&\
M11'8R%^WYJ68/=$YH01RV$(]'MU&4[1*8\5NE'IB?:<39 M,(WQ0RWFL[Q*5
MBX:93OPT2!&./D?1-L>3OS&,RE3$ND\Q*,,VE[%M%KWD`-(W!)>CK$+L8C(4


M!0:U0APR( 81#R
M_Z4TZQIC&IAH)H5#LJRF$#A>1N;$0 -/$ 19:*S9`U3(F1 R&& >Q6 6'$)M
M752 )!HK3"=CVV4V;2!?Z SE/-4VB4D(4"^.;I18V'8P7.11BI;(QOUQ1W!A
MK%\C`SZ3IO RL%I*<TH*]E>E:6*1SU1*-!5CIDB^N4RJ4[ZT,1'0RLY!U2VC
M!*FKG+O.;*UU!_+H?*EF-U9YI 7(PL KZ_98Z8PK> X_F UID.6N E U05K/



MQQ46!O!P6$AK41PPX#AXK.=K)6QW7B32]5$;\>N-8C(2V20U1WR!` $'?<2-
MS*\*U4IH1Z;?$GKJMYP+0%X4694^X</"9O*Z"ETB<&V=$=AQU<YU6I*!, K 
M14#D
MI"=;:1S6MBPKXG-F;%#MN25V):N5'(6IU'/O,*$F[0FWKM+M*F#VUXWJY6AR
M#JHG>1MKGU$G_99,P2E0=,^4" 1E %R5X5F(RAOK_Z4V.Y;(/^:;%SMN"UE0
ML!O_J]&B)"WRAP:J'];KJ&3P1%I4V:%D[;59U >1-!R(82^$:"/G9^6 NKHQ
M(".HY>0J^PP\X?(9^-XSZEVMN;Z2A12$NA$M$D[GO%!AE?K=?)ZI2; *:3LK
M$JK-LVWU1]M,M;$`"HM%KR0GQCY P!PB9J72^^TT0':P*Q[-!2*1%2>6I2C7
M,V: G#ID6IURQF4JT1YG<V>"' (/\P(>HIOF6=_3:.+[=%X.-[U'V$!Z'(-H
M%" TA2VL<3"SZTY!=3%%D :(5XA5! <G'"OFBBTOY7B)>!,.OD+QF4<\$TY;
M4=ZL9JO8;$FXS)NNR %('.52? XZP6%$6#KC8=5I.L$`10S:/)U4AAG;V8D\


MJT%ES"".`B-#VL=E>1UW'MJ[]6,I*N-:`Y_>XG9J9$EI61Q+0X*NR9=EY9)*
M>^<_O.O;&91W^)*^ULD%=^T1FR)QAA6:3'TH_,F"L;R=J7Q<;3I-RNK*W7KX

M!]LL[.T>6CMV):(:S0%T0%;H2>/'QT67[<+>Z'BT5QJH% Z3S&4^O6=KVO9F
M_=;<NAU I_YZ=L1=.A/#O-_QO.AZ
MOR,*73/A*M(='W^+_Q-6`I[\+(""[TIZ*&T^U1WMVD <W$',:3'9"DPXWP)U



M2A<UW5=I%:O/3IE:'NZ^,QSM[NT?'!X=;^B^.W+R82UA__! =V?O^/A >'BT
M/SPZ8 F'!Z/1[O&ZA(.]=0V>TO\_G.__MWEG_D_I,GY:7D10LN<#BP))D]/[
M7(+Z_76?X=7?F')J=+R?7=,SB8GG]%Q"9&/PN^W'#P3^8_%NN0%SMSHDZM6^

MS\Z:637QR#U
M_8'^A.LK^H%^Q/5W]'OZ6YE;'LA+3U.0'M)0892?**%_X I^2A]QQ9J9[G'%
ML GO`:WP/J.(;G&=T T5N,:D*<5U04OZYU,TK.+X48UV()5HB'^^CLKKKKWN

MJN7HIMQHJ+=YO(8K-?$E3=[;S]=\&P)&TEP8T8:X<_*W1"#HNNCN4CJQ56>%
M)J;MDQ-D]5#O'2M+X-(U1QY_],(B'==1+ 98,4,,^=3*\L;ZB4_?1DEHI#H%
MS<+#U(6$M]F3TD1.4-F^O7(OOMD]EZJ:5LQ]$QUTB(UC3OH[Z_&.9U8YL]J\

MWN\(=MQ*O6!,9:LU\N4&3..I0"A%M2M9Q5=[?#X_[<[(M523W>L.I6WF?,(K
M).%,5 U*PC;NSL!J[[+D_&PXIORK.!^?M>TUIJ^_SC>Q2]ZBD:XMV-238TZ9

M959DF9*-8V?V0OF[H=3A-.MBR^TL/M>&4KPYG49JAH5;P/$49'DIUV*_7KXU
MKXV6: -U-&Y%6.6DW/-^?3UPS27=6RGG8;F]`*#YS2-.*U\E,PB&]+.E-3:Y
M_4Q0K=WI\YK#ZH7'QKF6DEMZC!OKRJZX;)H9M>879[G37<A=97* =Z-4BN)5

M+12J&_240P.C$B/;-HGL&$K3&OE; TTBI\67SOV,4JORD$>.$7 CS'MP\5FE
MWZ^"53J6-WI6#X_0L4,VNG.ZV\']:I73\:P5NSD2AT^(Q,HQK<"K2UC%#C/A

M.$X "3KJ: *A:N] K=MD?0=A;04 S3J$I&<W!,N3"MF$CQ+>(:CW$MWS9-XJ
M=W=B_A-6XQ[=K8NP9RKFI*&$Y<F3T]2MR^L$1N3_O:27I7,_;0RK9V[3, S6
M.84U'Q2.XVY9%P_))IS,[\O[<.Z\93MX4]9(P6#X]P[\(P;[ Y,B,\R=:\_T


M/TTGG2WY`>E9[M'P",ELM+-ST.ST0V7[B[U3O_QQY+\!4$L!`A0`% ```` `

;+FAT;6Q02P4&``````$``0`^````N X`````
`
end
Oct 19 2006
next sibling parent Walter Bright <newshound digitalmars.com> writes:
Lionello Lunesu wrote:

 Could you put together a web page with the results? Or just text, I can
 turn it into a web page.


 
 Here it is!
 
 Feel free to check my english and fix it :)


Cool!
Oct 19 2006
prev sibling parent reply Walter Bright <newshound digitalmars.com> writes:
I've taken the liberty of:

1) Converting it to use Ddoc and the macros used to create the Digital 
Mars site.
2) Added a link to this thread.
3) Took out the bit about compiling html, as I need to fix Ddoc so that 
works!
4) Hosting it.

If you object to any of this, or have any corrections, please let me 
know and I'll take care of it!

http://www.digitalmars.com/d/lisp-java-d.html

If it meets with your approval, I'll add it to the 'Comparisons' links.

Thanks!
Oct 19 2006
parent reply "Lionello Lunesu" <lionello lunesu.remove.com> writes:
"Walter Bright" <newshound digitalmars.com> wrote in message 
news:eh9fib$ve9$1 digitaldaemon.com...

 I've taken the liberty of:

 1) Converting it to use Ddoc and the macros used to create the Digital 
 Mars site.
 2) Added a link to this thread.
 3) Took out the bit about compiling html, as I need to fix Ddoc so that 
 works!
 4) Hosting it.

 If you object to any of this, or have any corrections, please let me know 
 and I'll take care of it!

 http://www.digitalmars.com/d/lisp-java-d.html

 If it meets with your approval, I'll add it to the 'Comparisons' links.


Of couse, I'd be honoured! :)


 Thanks!


No, thank you! ; )

L.

PS. I don't like the way the longer lines of code exceed the code-box. I had 
the same thing and fixed it using 'margin' instead of 'width' in the style 
sheet. Might work?
Oct 19 2006
next sibling parent reply Walter Bright <newshound digitalmars.com> writes:
Lionello Lunesu wrote:

 Of couse, I'd be honoured! :)


Ok!


 PS. I don't like the way the longer lines of code exceed the code-box. I had 
 the same thing and fixed it using 'margin' instead of 'width' in the style 
 sheet. Might work? 


I think it looks fine.
Oct 19 2006
parent reply "Chris Miller" <chris dprogramming.com> writes:
On Fri, 20 Oct 2006 02:47:40 -0400, Walter Bright  
<newshound digitalmars.com> wrote:


 Lionello Lunesu wrote:

 Of couse, I'd be honoured! :)


 Ok!


 PS. I don't like the way the longer lines of code exceed the code-box.  
 I had the same thing and fixed it using 'margin' instead of 'width' in  
 the style sheet. Might work?


 I think it looks fine.


Looks pretty bad to me,  
http://img148.imageshack.us/img148/5238/t4h8t4g3ev7.png
Oct 19 2006
next sibling parent reply Walter Bright <newshound digitalmars.com> writes:
Chris Miller wrote:

 On Fri, 20 Oct 2006 02:47:40 -0400, Walter Bright 
 <newshound digitalmars.com> wrote:
 

 Lionello Lunesu wrote:

 Of couse, I'd be honoured! :)


 Ok!


 PS. I don't like the way the longer lines of code exceed the 
 code-box. I had the same thing and fixed it using 'margin' instead of 
 'width' in the style sheet. Might work?


 I think it looks fine.


 
 Looks pretty bad to me, 
 http://img148.imageshack.us/img148/5238/t4h8t4g3ev7.png


Yowsa! I guess that's the problem with style sheets. They aren't 
portable. (It looks fine in Explorer, what are you using?)
Oct 20 2006
next sibling parent reply "Chris Miller" <chris dprogramming.com> writes:
On Fri, 20 Oct 2006 03:12:44 -0400, Walter Bright  
<newshound digitalmars.com> wrote:


 Chris Miller wrote:

 On Fri, 20 Oct 2006 02:47:40 -0400, Walter Bright  
 <newshound digitalmars.com> wrote:


 Lionello Lunesu wrote:

 Of couse, I'd be honoured! :)


 Ok!


 PS. I don't like the way the longer lines of code exceed the  
 code-box. I had the same thing and fixed it using 'margin' instead of  
 'width' in the style sheet. Might work?


 I think it looks fine.


  Looks pretty bad to me,  
 http://img148.imageshack.us/img148/5238/t4h8t4g3ev7.png


 Yowsa! I guess that's the problem with style sheets. They aren't  
 portable. (It looks fine in Explorer, what are you using?)


Opera.
Oct 20 2006
parent reply Walter Bright <newshound digitalmars.com> writes:
Chris Miller wrote:

(It looks fine in Explorer, what are you using?)


 Opera.


I tried it in Mozilla, it looks different from both IE and Opera.
Oct 20 2006
parent reply Kyle Furlong <kylefurlong gmail.com> writes:
Walter Bright wrote:

 Chris Miller wrote:

 (It looks fine in Explorer, what are you using?)


 Opera.


 
 I tried it in Mozilla, it looks different from both IE and Opera.


You, sir, must not be a web programmer. :-D
Oct 20 2006
parent Walter Bright <newshound digitalmars.com> writes:
Kyle Furlong wrote:

 Walter Bright wrote:

 Chris Miller wrote:

 (It looks fine in Explorer, what are you using?)


 Opera.


 I tried it in Mozilla, it looks different from both IE and Opera.


 
 You, sir, must not be a web programmer. :-D


Uh-oh, he's on to me!
Oct 20 2006
prev sibling next sibling parent reply "Unknown W. Brackets" <unknown simplemachines.org> writes:
Actually, they are portable... but what you're doing is technically 
incorrect.  I had thought it was intentional.

You set a width for the box, and so the standards-compliant browsers 
listen to you and do as you say.  You don't set overflow, so it's 
defaulted to visible.  Thus what you see in the screenshot.

Internet Explorer is completely ignoring the standards (what the CSS 
property "width" is supposed to do) and treating it as a minimum width.

Normally, you'd set min-width instead to get the effect that Internet 
Explorer is giving you... but IE does not support min-width.  Hence 
probably why Internet Explorer behaves this way.

A lot of people use something like this for that:

min-width: 600px;
width: expression("600px"); /* This line only understood by IE. */

However, Internet Explorer 7 (coming out _very_ soon, final already 
available for download) will comply with the standards (when the 
document has a proper DOCTYPE, which yours does) and thus the above will 
break it.

I would suggest that it wouldn't be too bad to simply have:

min-width: 600px;

Because, this will mean that Internet Explorer 6 and below will simply 
show the box at whatever width, including smaller than 600px... but 
every other browser will work as you wish.

-[Unknown]



 Chris Miller wrote:

 On Fri, 20 Oct 2006 02:47:40 -0400, Walter Bright 
 <newshound digitalmars.com> wrote:


 Lionello Lunesu wrote:

 Of couse, I'd be honoured! :)


 Ok!


 PS. I don't like the way the longer lines of code exceed the 
 code-box. I had the same thing and fixed it using 'margin' instead 
 of 'width' in the style sheet. Might work?


 I think it looks fine.


 Looks pretty bad to me, 
 http://img148.imageshack.us/img148/5238/t4h8t4g3ev7.png


 
 Yowsa! I guess that's the problem with style sheets. They aren't 
 portable. (It looks fine in Explorer, what are you using?)
Oct 20 2006
next sibling parent Walter Bright <newshound digitalmars.com> writes:
Unknown W. Brackets wrote:

 I would suggest that it wouldn't be too bad to simply have:
 
 min-width: 600px;
 
 Because, this will mean that Internet Explorer 6 and below will simply 
 show the box at whatever width, including smaller than 600px... but 
 every other browser will work as you wish.


I shall apply the fix. Thanks!
Oct 20 2006
prev sibling parent reply "Lionello Lunesu" <lionello lunesu.remove.com> writes:
"Unknown W. Brackets" <unknown simplemachines.org> wrote in message 
news:ehanlp$22jc$1 digitaldaemon.com...

 Actually, they are portable... but what you're doing is technically 
 incorrect.  I had thought it was intentional.

 You set a width for the box, and so the standards-compliant browsers 
 listen to you and do as you say.  You don't set overflow, so it's 
 defaulted to visible.  Thus what you see in the screenshot.

 Internet Explorer is completely ignoring the standards (what the CSS 
 property "width" is supposed to do) and treating it as a minimum width.

 Normally, you'd set min-width instead to get the effect that Internet 
 Explorer is giving you... but IE does not support min-width.  Hence 
 probably why Internet Explorer behaves this way.

 A lot of people use something like this for that:

 min-width: 600px;
 width: expression("600px"); /* This line only understood by IE. */

 However, Internet Explorer 7 (coming out _very_ soon, final already 
 available for download) will comply with the standards (when the document 
 has a proper DOCTYPE, which yours does) and thus the above will break it.

 I would suggest that it wouldn't be too bad to simply have:

 min-width: 600px;

 Because, this will mean that Internet Explorer 6 and below will simply 
 show the box at whatever width, including smaller than 600px... but every 
 other browser will work as you wish.


Wouldn't the same effect be achieved by setting "margin" instead of 
"(min-)width"?

L.
Oct 20 2006
parent reply "Unknown W. Brackets" <unknown simplemachines.org> writes:
I'm afraid not.  Margin controls the amount of spacing outside the box, 
against other boxes or the outside edge of the browser.

Thus, if you want the box to be at least 600px wide on a 800px, 1024px, 
or 1600px screen (not even beginning to talk about un-maximized browser 
windows!)... you cannot use a fixed margin to achieve this.  Using a 
percentage wouldn't be too bad, but would cause their to be much 
scrollable space on the right.

Unless you mean something else, and I'm misunderstanding you?

You could, in theory, use some trickery to achieve the affect using 
margins or other properties and nesting many elements (or use a table), 
but it would likely result in brittle, unmaintainable HTML/CSS which 
does no one much good.

-[Unknown]



 "Unknown W. Brackets" <unknown simplemachines.org> wrote in message 
 news:ehanlp$22jc$1 digitaldaemon.com...

 Actually, they are portable... but what you're doing is technically 
 incorrect.  I had thought it was intentional.

 You set a width for the box, and so the standards-compliant browsers 
 listen to you and do as you say.  You don't set overflow, so it's 
 defaulted to visible.  Thus what you see in the screenshot.

 Internet Explorer is completely ignoring the standards (what the CSS 
 property "width" is supposed to do) and treating it as a minimum width.

 Normally, you'd set min-width instead to get the effect that Internet 
 Explorer is giving you... but IE does not support min-width.  Hence 
 probably why Internet Explorer behaves this way.

 A lot of people use something like this for that:

 min-width: 600px;
 width: expression("600px"); /* This line only understood by IE. */

 However, Internet Explorer 7 (coming out _very_ soon, final already 
 available for download) will comply with the standards (when the document 
 has a proper DOCTYPE, which yours does) and thus the above will break it.

 I would suggest that it wouldn't be too bad to simply have:

 min-width: 600px;

 Because, this will mean that Internet Explorer 6 and below will simply 
 show the box at whatever width, including smaller than 600px... but every 
 other browser will work as you wish.


 
 Wouldn't the same effect be achieved by setting "margin" instead of 
 "(min-)width"?
 
 L.
Oct 20 2006
parent reply "Lionello Lunesu" <lionello lunesu.remove.com> writes:
"Unknown W. Brackets" <unknown simplemachines.org> wrote in message 
news:ehcbui$ip8$1 digitaldaemon.com...

 I'm afraid not.  Margin controls the amount of spacing outside the box, 
 against other boxes or the outside edge of the browser.

 Thus, if you want the box to be at least 600px wide on a 800px, 1024px, or 
 1600px screen (not even beginning to talk about un-maximized browser 
 windows!)... you cannot use a fixed margin to achieve this.  Using a 
 percentage wouldn't be too bad, but would cause their to be much 
 scrollable space on the right.

 Unless you mean something else, and I'm misunderstanding you?


Well, why would anyone (Walter in this case) want to use "width"? Probably 
to prevent the code-box from touching the edges of the page. The problem 
with "width" was that it can make the box too small for its contents. That's 
why I suggested using "margin" instead. It prevents the box from touching 
the edges but never smaller than the longest line inside the box.. But that 
was of course before I knew "min-width" existed :)

L.
Oct 20 2006
parent Walter Bright <newshound digitalmars.com> writes:
Lionello Lunesu wrote:

 Well, why would anyone (Walter in this case) want to use "width"? Probably 
 to prevent the code-box from touching the edges of the page. The problem 
 with "width" was that it can make the box too small for its contents. That's 
 why I suggested using "margin" instead. It prevents the box from touching 
 the edges but never smaller than the longest line inside the box.. But that 
 was of course before I knew "min-width" existed :)


I used the "width" so that multiple code boxes lined up neatly. It just 
looked better.
Oct 21 2006
prev sibling parent reply Bill Baxter <wbaxter gmail.com> writes:
Walter Bright wrote:

 Chris Miller wrote:
 

 Looks pretty bad to me, 
 http://img148.imageshack.us/img148/5238/t4h8t4g3ev7.png


 
 
 Yowsa! I guess that's the problem with style sheets. They aren't 
 portable. (It looks fine in Explorer, what are you using?)


The same overflow problem exists in many of the D languages pages, too.
   e.g. http://www.digitalmars.com/d/template.html

If I switch to a small enough default font it looks ok, though.
(I use FireFox.)

--bb
Oct 20 2006
parent Walter Bright <newshound digitalmars.com> writes:
Bill Baxter wrote:

 Walter Bright wrote:

 Chris Miller wrote:


 Looks pretty bad to me, 
 http://img148.imageshack.us/img148/5238/t4h8t4g3ev7.png



 Yowsa! I guess that's the problem with style sheets. They aren't 
 portable. (It looks fine in Explorer, what are you using?)


 
 The same overflow problem exists in many of the D languages pages, too.
   e.g. http://www.digitalmars.com/d/template.html


I wouldn't be surprised at all at that, since they all use the same 
style sheet, and all are generated with Ddoc macros.
Oct 20 2006
prev sibling parent Lionello Lunesu <lio lunesu.remove.com> writes:
Chris Miller wrote:

 Looks pretty bad to me, 
 http://img148.imageshack.us/img148/5238/t4h8t4g3ev7.png


That's how it looks in FireFox as well.

L.
Oct 20 2006
prev sibling parent reply Walter Bright <newshound digitalmars.com> writes:
I sent Brandon Corfman a link to your article, and here's his reply 
(posted with his permission):


 Thanks for sharing that article. It's a good discussion, although I'll 
certainly need
 more time to study the results in detail.
 
 Here's another link to results in some other languages:
 http://www.nsl.com/papers/phone.htm
 
 Since I can't enter the discussion, one thing I wanted to point out is that I
posted my
 original C++ code verbatim as soon as I was finished. So although there are
better ways
 to use the STL (as has been endlessly pointed out to me by other C++
advocates), the
 point wasn't to tweak the original program to make it more concise, as that
would
 simply have eaten up more time. The point was to solve the program as quickly
as I could
 and then measure the LOC afterwards.
 
 I'm really impressed with the way Lionello wrote the code without looking at
the other
 versions first. I've had plenty of others tell me that they translated
existing programs
 into their pet language or wrote their own after studying the solutions. Most
of them also
 won't tell how long it took them either ... especially the C++ guys ... heh.
 
 Brandon
Oct 20 2006
parent Brad Anderson <brad dsource.org> writes:
Walter Bright wrote:

 I sent Brandon Corfman a link to your article, and here's his reply
 (posted with his permission):
 

 Thanks for sharing that article. It's a good discussion, although
 I'll  certainly need
 more time to study the results in detail.

 Here's another link to results in some other languages:
 http://www.nsl.com/papers/phone.htm

 Since I can't enter the discussion, one thing I wanted to point out is
 that I posted my
 original C++ code verbatim as soon as I was finished. So although
 there are better ways
 to use the STL (as has been endlessly pointed out to me by other C++
 advocates), the
 point wasn't to tweak the original program to make it more concise, as
 that would
 simply have eaten up more time. The point was to solve the program as
 quickly as I could
 and then measure the LOC afterwards.

 I'm really impressed with the way Lionello wrote the code without
 looking at the other
 versions first. I've had plenty of others tell me that they translated
 existing programs
 into their pet language or wrote their own after studying the
 solutions. Most of them also
 won't tell how long it took them either ... especially the C++ guys
 ... heh.

 Brandon 


 


To rephrase Brandon's response:  D pwnz!!!
Oct 20 2006
prev sibling parent reply Dave <Dave_member pathlink.com> writes:
Walter Bright wrote:

 Josh Stern wrote:

 This old blog doesn't mention D, but I think it is good and really
 relevant anyway:

 http://userpages.umbc.edu/~bcorfm1/C++-vs-Lisp.html




I see the dictionary and input files at the link below, but can't find the
mappings.txt file used in 
the C++ version... Am I just missing it?

Thanks.


 IMO, it points to a set of issues that relate to how D (and its 
 libraries)
 have the potential to allow developers to be a lot more productive than
 they are with C++.   Particularly relevant D features related to
 the points mentioned there include but are not limited to  GC, mixins,
 regex, and elimination of header/instantiation separation.   The point
 about the productivity benefits of creating interfaces that return the
 most interesting value (maybe alongside the interface that allows the
 greatest efficiency when optimizing) is a good one to remember in 
 practice.


 
 
 It is a very interesting article for anyone wanting to carefully look at 
 language differences. Anyone care to try a D version following the 
 original challenge?
 
    http://www.flownet.com/ron/papers/lisp-java/
Oct 11 2006
parent "Lionello Lunesu" <lionello lunesu.remove.com> writes:
"Dave" <Dave_member pathlink.com> wrote in message 
news:egk0jk$2d59$1 digitaldaemon.com...

 Walter Bright wrote:

 Josh Stern wrote:

 This old blog doesn't mention D, but I think it is good and really
 relevant anyway:

 http://userpages.umbc.edu/~bcorfm1/C++-vs-Lisp.html




 I see the dictionary and input files at the link below, but can't find the 
 mappings.txt file used in the C++ version... Am I just missing it?


Ah, I could have posted that file, sorry.. Don't have it here, but it's just 
a txt file with "e 0\nE 0\n"... etc. I made it myself using the table from 
the original task description.

L.
Oct 13 2006
prev sibling parent reply Sean Kelly <sean f4.ca> writes:
It's an interesting analysis, but I think some of the points of 
comparison aren't as strong has the writer implies.  For example, he 
begins by saying that his initial C++ attempt is shorter than average 
and suggests that this is because his is the only C++ attempt to use the 
STL.  Later he goes on to make a direct comparison of some of his code 
and some of Peter Norvig's code (in the Style section) and concludes 
that because Norvig's code is shorter and doesn't modify the sequence in 
place, functional programming is better.  He's forgotten his original 
statement regarding his code vs. the other C++ entrants however, and 
perhaps doesn't have enough experience with the STL to know that:

     words.reverse();
     cout << num << ":";
     for (list<string>::const_iterator i = words.begin();
          i != words.end(); ++i)
         cout << *i << " ";
     cout << "\n";

can be rewritten as:

     std::cout << num << ':';
     std::reverse_copy( words.begin(),
                        words.end(),
                        std::ostream_iterator<std::string>( std::cout,
                                                            " " ) );
     std::cout << '\n';

This rewrite addresses his concern about reversing the list in place to 
print it out (it doesn't modify the original sequence), and partially 
addresses the comment about having to print out the list manually.  It 
also reduces his LOC count by two and is almost as expressive as the 
Lisp version.  A further reading of his code shows that he doesn't use 
the algorithm library at all, which is IMO one of the greatest strengths 
of C++.

That said, I do agree with the general thrust of the article.  While 
tricks like the above are possible in C++, they tend to require a good 
degree of knowledge or experience to be aware of.  By comparison, I 
think Lisp naturally lends itself to the type of code in Norvig's 
example.  The Lisp code is also more succinct and more clear than even 
an algorithm-aware rewrite of the C++ version, though I believe the gap 
would be narrower than the original comparison suggests.

I believe that D has a definite opportunity to do better than C++ in 
code clarity and ease of programming, but I'm not sure the library is 
sufficient quiet yet.  The C++ algorithm/iterator model is extremely 
powerful and D's foreach and delegates aren't enough by themselves.  For 
example, writing the code snippet above in D would be much more like the 
original C++ version than my rewrite.  For D to be great, I think it 
will need an standard algorithm-oriented library that exploits D's 
unique language features.  DTL seemed a likely candidate, but 
development on it stalled ages ago.  But perhaps it contains ideas worth 
pursuing.  I'll admit it's been so long that I've forgotten a lot of the 
details of how it works.


Sean
Oct 11 2006
next sibling parent reply Walter Bright <newshound digitalmars.com> writes:
Sean Kelly wrote:

 I believe that D has a definite opportunity to do better than C++ in 
 code clarity and ease of programming, but I'm not sure the library is 
 sufficient quiet yet.  The C++ algorithm/iterator model is extremely 
 powerful and D's foreach and delegates aren't enough by themselves.  For 
 example, writing the code snippet above in D would be much more like the 
 original C++ version than my rewrite.  For D to be great, I think it 
 will need an standard algorithm-oriented library that exploits D's 
 unique language features.  DTL seemed a likely candidate, but 
 development on it stalled ages ago.  But perhaps it contains ideas worth 
 pursuing.  I'll admit it's been so long that I've forgotten a lot of the 
 details of how it works.


D just needs a foreach_reverse statement.
Oct 11 2006
next sibling parent Derek Parnell <derek psyc.ward> writes:
On Wed, 11 Oct 2006 10:55:35 -0700, Walter Bright wrote:
 

 D just needs a foreach_reverse statement.


Ain't that the truth!

-- 
Derek Parnell
Melbourne, Australia
"Down with mediocrity!"
Oct 12 2006
prev sibling parent reply clayasaurus <clayasaurus gmail.com> writes:
Walter Bright wrote:

 Sean Kelly wrote:

 I believe that D has a definite opportunity to do better than C++ in 
 code clarity and ease of programming, but I'm not sure the library is 
 sufficient quiet yet.  The C++ algorithm/iterator model is extremely 
 powerful and D's foreach and delegates aren't enough by themselves.  
 For example, writing the code snippet above in D would be much more 
 like the original C++ version than my rewrite.  For D to be great, I 
 think it will need an standard algorithm-oriented library that 
 exploits D's unique language features.  DTL seemed a likely candidate, 
 but development on it stalled ages ago.  But perhaps it contains ideas 
 worth pursuing.  I'll admit it's been so long that I've forgotten a 
 lot of the details of how it works.


 
 D just needs a foreach_reverse statement.


old thread on the subject: 
http://www.digitalmars.com/d/archives/digitalmars/D/17320.html
Oct 12 2006
next sibling parent James Dunne <james.jdunne gmail.com> writes:
clayasaurus wrote:

 Walter Bright wrote:

 Sean Kelly wrote:

 I believe that D has a definite opportunity to do better than C++ in 
 code clarity and ease of programming, but I'm not sure the library is 
 sufficient quiet yet.  The C++ algorithm/iterator model is extremely 
 powerful and D's foreach and delegates aren't enough by themselves.  
 For example, writing the code snippet above in D would be much more 
 like the original C++ version than my rewrite.  For D to be great, I 
 think it will need an standard algorithm-oriented library that 
 exploits D's unique language features.  DTL seemed a likely 
 candidate, but development on it stalled ages ago.  But perhaps it 
 contains ideas worth pursuing.  I'll admit it's been so long that 
 I've forgotten a lot of the details of how it works.


 D just needs a foreach_reverse statement.


 
 old thread on the subject: 
 http://www.digitalmars.com/d/archives/digitalmars/D/17320.html


Thanks Clay.  I was about to post an "I told you so..." post, but you 
saved us all from that fate.

Wait...

-- 
-----BEGIN GEEK CODE BLOCK-----
Version: 3.1
GCS/MU/S d-pu s:+ a-->? C++++$ UL+++ P--- L+++ !E W-- N++ o? K? w--- O 
M--  V? PS PE Y+ PGP- t+ 5 X+ !R tv-->!tv b- DI++(+) D++ G e++>e 
h>--->++ r+++ y+++
------END GEEK CODE BLOCK------

James Dunne
Oct 16 2006
prev sibling parent Walter Bright <newshound digitalmars.com> writes:
clayasaurus wrote:

 Walter Bright wrote:

 Sean Kelly wrote:

 I believe that D has a definite opportunity to do better than C++ in 
 code clarity and ease of programming, but I'm not sure the library is 
 sufficient quiet yet.  The C++ algorithm/iterator model is extremely 
 powerful and D's foreach and delegates aren't enough by themselves.  
 For example, writing the code snippet above in D would be much more 
 like the original C++ version than my rewrite.  For D to be great, I 
 think it will need an standard algorithm-oriented library that 
 exploits D's unique language features.  DTL seemed a likely 
 candidate, but development on it stalled ages ago.  But perhaps it 
 contains ideas worth pursuing.  I'll admit it's been so long that 
 I've forgotten a lot of the details of how it works.


 D just needs a foreach_reverse statement.


 
 old thread on the subject: 
 http://www.digitalmars.com/d/archives/digitalmars/D/17320.html


I know, lots of good ideas in that thread. I was hoping to find a way to 
do it using existing language facilities, but the results are just too 
hackish.
Oct 16 2006
prev sibling parent reply Sean Kelly <sean f4.ca> writes:
Oh, a quick comment on loops, since the article mentions those as well. 
  Here is the Lisp code:

     (loop for word in (gethash n *dict*) do


His C++ version:
     for (HashMap::iterator i = gDict.equal_range(n).begin();
          i != gDict.equal_range(n).end(); i++)

In D, if the words were stored in a sorted array, I would write:

     foreach( word; dict[lowerBound(n) .. upperBound(n)] )


And if they were in an AA (char[][][int] dict):

     foreach( word; dict[n] )

Note that this expects the lookup for n to succeed or the current AA 
code will throw an exception.  A more robust version:

     char[][]* list = n in dict;
     if( list ) foreach( word; *list )

seems unnecessarily wordy and somewhat unreadable.  It would be nice if 
AAs had some lookup method that returned a default value on failure 
instead of requiring the pointer check above.


Sean
Oct 11 2006
parent Lionello Lunesu <lio lunesu.remove.com> writes:
Sean Kelly wrote:

 Oh, a quick comment on loops, since the article mentions those as well. 
  Here is the Lisp code:
 
     (loop for word in (gethash n *dict*) do
 
 
 His C++ version:
     for (HashMap::iterator i = gDict.equal_range(n).begin();
          i != gDict.equal_range(n).end(); i++)
 
 In D, if the words were stored in a sorted array, I would write:
 
     foreach( word; dict[lowerBound(n) .. upperBound(n)] )
 
 
 And if they were in an AA (char[][][int] dict):
 
     foreach( word; dict[n] )
 
 Note that this expects the lookup for n to succeed or the current AA 
 code will throw an exception.  A more robust version:
 
     char[][]* list = n in dict;
     if( list ) foreach( word; *list )
 
 seems unnecessarily wordy and somewhat unreadable.  It would be nice if 
 AAs had some lookup method that returned a default value on failure 
 instead of requiring the pointer check above.


Perhaps foreach could always check for 'null' if you pass it a pointer 
to an array.

L.
Oct 12 2006