www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Re: What are AST Macros?

reply bearophile <bearophileHUGS lycos.com> writes:
Steven Schveighoffer:

 bearophile:

 String mixins are a hack, just a bit better than C preprocessor (because  
 they are scoped), they are not a replacement of clean macros.



 Interesting statement, can you back it up? :)  What can you do with a  
 macro that you can't do with a mixin?



In the meantime others have already given you some answers, I can add one
example. The Brainfuck language allows you to do every kind of thing, I have
seen even compilers written in it, but its usage is very unhandy, it's
bug-prone, requires lot of code to do even simple things, and it's very hard to
modify and debug programs written in it. What I meant is that string mixins in
theory allow you to do many things, but in practice you can't use them for
complex tasks, and you can't modify and fix the resulting code if you try to
use them for more complex tasks. They are not a long-term solution for a
language that seriously wants to improve over C and its preprocessor macros,
they are a hack.

In my opinion the std.bitmanip.bitfields souce code is already past the decency
limit for string mixins, and I hope they will be replaced by something better.

I don't agree with Andrei when he says that CLisp macros (and even more Scheme
macros that are hygienic too) are as hairy and unmantenable as code that uses
string mixins heavily.

In past I have asked for a gensym intrinsic in D, but it was not a serious
request, because I don't want to see string mixing used even more in D :-)

Bye,
bearophile
Jul 12 2010
next sibling parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Mon, 12 Jul 2010 16:22:28 -0400, bearophile <bearophileHUGS lycos.com>  
wrote:


 Steven Schveighoffer:

 bearophile:

 String mixins are a hack, just a bit better than C preprocessor  




 they are scoped), they are not a replacement of clean macros.



 Interesting statement, can you back it up? :)  What can you do with a
 macro that you can't do with a mixin?



 In the meantime others have already given you some answers, I can add  
 one example. The Brainfuck language allows you to do every kind of  
 thing, I have seen even compilers written in it, but its usage is very  
 unhandy, it's bug-prone, requires lot of code to do even simple things,  
 and it's very hard to modify and debug programs written in it. What I  
 meant is that string mixins in theory allow you to do many things, but  
 in practice you can't use them for complex tasks, and you can't modify  
 and fix the resulting code if you try to use them for more complex  
 tasks. They are not a long-term solution for a language that seriously  
 wants to improve over C and its preprocessor macros, they are a hack.



Brainfuck is basically a toy example of a language.  Nobody uses it for  
serious work.  Mixins are much better than a hack, the syntax of using  
them is just not polished.  They are easy to use/understand because a)  
people understand the language and b) people understand string  
manipulation.


 In my opinion the std.bitmanip.bitfields souce code is already past the  
 decency limit for string mixins, and I hope they will be replaced by  
 something better.



How would AST macros make std.bitmanip.bitfields easier to understand?  I  
have never seen it before, and I understood it after a couple minutes  
reading.  I bet the AST version would be actually harder to understand.

Most of the "ugliness" is the part that builds the accessors because it  
contains so much concatenation, but that is what I was proposing.  Having  
used php for the last year in my job, there is one thing I appreciate:  
with a language that is focused on string manipulation, it is so much  
better to be able to simply output variables inside strings rather than  
having to exit a quotation, and use a concatenation operator.  With the  
unused keyword macro, we can make string mixins much easier to  
write/understand without the need to add AST macros.

I'll give you another example -- javascript and HTML editing.  Most people  
would prefer to just use the innerHTML component of an element than have  
to use the DOM methods to create individual elements and add them as  
children, etc.


 I don't agree with Andrei when he says that CLisp macros (and even more  
 Scheme macros that are hygienic too) are as hairy and unmantenable as  
 code that uses string mixins heavily.



I don't have much experience with these languages except that in college  
while taking a scheme course, I wanted to create a bonfire out of all  
parentheses keys.

-Steve
Jul 12 2010
next sibling parent reply "Nick Sabalausky" <a a.a> writes:
"Steven Schveighoffer" <schveiguy yahoo.com> wrote in message 
news:op.vfq0aydoeav7ka localhost.localdomain...

 On Mon, 12 Jul 2010 16:22:28 -0400, bearophile <bearophileHUGS lycos.com> 
 wrote:


 Steven Schveighoffer:

 bearophile:

 String mixins are a hack, just a bit better than C preprocessor




 they are scoped), they are not a replacement of clean macros.



 Interesting statement, can you back it up? :)  What can you do with a
 macro that you can't do with a mixin?



 In the meantime others have already given you some answers, I can add 
 one example. The Brainfuck language allows you to do every kind of 
 thing, I have seen even compilers written in it, but its usage is very 
 unhandy, it's bug-prone, requires lot of code to do even simple things, 
 and it's very hard to modify and debug programs written in it. What I 
 meant is that string mixins in theory allow you to do many things, but 
 in practice you can't use them for complex tasks, and you can't modify 
 and fix the resulting code if you try to use them for more complex 
 tasks. They are not a long-term solution for a language that seriously 
 wants to improve over C and its preprocessor macros, they are a hack.



 Brainfuck is basically a toy example of a language.  Nobody uses it for 
 serious work.  Mixins are much better than a hack, the syntax of using 
 them is just not polished.  They are easy to use/understand because a) 
 people understand the language and b) people understand string 
 manipulation.



But when you're talking about the string being actual code, you're not 
always talking about typical string manipulation, sometimes you're talking 
about parsing which is only "string manipulation" superficially.


 I'll give you another example -- javascript and HTML editing.  Most people 
 would prefer to just use the innerHTML component of an element than have 
 to use the DOM methods to create individual elements and add them as 
 children, etc.



For writing, yes, but there's also reading: How many people do you know who 
would rather find the elements they want by parsing innerHTML instead of 
just dealing with the readily-available tree? None, I would hope, but the 
latter is essentially what we have to do for many of the more advanced 
things that string mixins *technically* replace AST macros for.
Jul 12 2010
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 07/12/2010 06:21 PM, Nick Sabalausky wrote:

 "Steven Schveighoffer"<schveiguy yahoo.com>  wrote in message
 news:op.vfq0aydoeav7ka localhost.localdomain...

 On Mon, 12 Jul 2010 16:22:28 -0400, bearophile<bearophileHUGS lycos.com>
 wrote:


 Steven Schveighoffer:

 bearophile:

 String mixins are a hack, just a bit better than C preprocessor




 they are scoped), they are not a replacement of clean macros.



 Interesting statement, can you back it up? :)  What can you do with a
 macro that you can't do with a mixin?



 In the meantime others have already given you some answers, I can add
 one example. The Brainfuck language allows you to do every kind of
 thing, I have seen even compilers written in it, but its usage is very
 unhandy, it's bug-prone, requires lot of code to do even simple things,
 and it's very hard to modify and debug programs written in it. What I
 meant is that string mixins in theory allow you to do many things, but
 in practice you can't use them for complex tasks, and you can't modify
 and fix the resulting code if you try to use them for more complex
 tasks. They are not a long-term solution for a language that seriously
 wants to improve over C and its preprocessor macros, they are a hack.



 Brainfuck is basically a toy example of a language.  Nobody uses it for
 serious work.  Mixins are much better than a hack, the syntax of using
 them is just not polished.  They are easy to use/understand because a)
 people understand the language and b) people understand string
 manipulation.



 But when you're talking about the string being actual code, you're not
 always talking about typical string manipulation, sometimes you're talking
 about parsing which is only "string manipulation" superficially.


 I'll give you another example -- javascript and HTML editing.  Most people
 would prefer to just use the innerHTML component of an element than have
 to use the DOM methods to create individual elements and add them as
 children, etc.



 For writing, yes, but there's also reading: How many people do you know who
 would rather find the elements they want by parsing innerHTML instead of
 just dealing with the readily-available tree? None, I would hope, but the
 latter is essentially what we have to do for many of the more advanced
 things that string mixins *technically* replace AST macros for.



But bitfields and other similar code generating samples don't parse - 
they generate.

Andrei
Jul 12 2010
parent reply "Nick Sabalausky" <a a.a> writes:
"Andrei Alexandrescu" <SeeWebsiteForEmail erdani.org> wrote in message 
news:i1ge6c$c9s$1 digitalmars.com...

 On 07/12/2010 06:21 PM, Nick Sabalausky wrote:

 "Steven Schveighoffer"<schveiguy yahoo.com>  wrote in message

 Brainfuck is basically a toy example of a language.  Nobody uses it for
 serious work.  Mixins are much better than a hack, the syntax of using
 them is just not polished.  They are easy to use/understand because a)
 people understand the language and b) people understand string
 manipulation.



 But when you're talking about the string being actual code, you're not
 always talking about typical string manipulation, sometimes you're 
 talking
 about parsing which is only "string manipulation" superficially.


 I'll give you another example -- javascript and HTML editing.  Most 
 people
 would prefer to just use the innerHTML component of an element than have
 to use the DOM methods to create individual elements and add them as
 children, etc.



 For writing, yes, but there's also reading: How many people do you know 
 who
 would rather find the elements they want by parsing innerHTML instead of
 just dealing with the readily-available tree? None, I would hope, but the
 latter is essentially what we have to do for many of the more advanced
 things that string mixins *technically* replace AST macros for.



 But bitfields and other similar code generating samples don't parse - they 
 generate.



I already agreed to that part ("For writing, yes..."). But there are other 
uses that *do* parse, and others that do both. The point is NOT that string 
mixins are *always* unsatisfactory as a replacement for AST macros. The 
point is that *there are perfectly legitimate use-cases* where string mixins 
are unsatisfactory as a replacement for AST macros. I think you've already 
agreed to this in other posts.
Jul 12 2010
parent reply Rainer Deyke <rainerd eldwood.com> writes:
On 7/12/2010 19:41, Nick Sabalausky wrote:

 I already agreed to that part ("For writing, yes..."). But there are other 
 uses that *do* parse, and others that do both. The point is NOT that string 
 mixins are *always* unsatisfactory as a replacement for AST macros. The 
 point is that *there are perfectly legitimate use-cases* where string mixins 
 are unsatisfactory as a replacement for AST macros. I think you've already 
 agreed to this in other posts.



The great strength of string mixins is that you can use them to add the
AST macros to D.  The great weakness of string mixins is that doing so
requires a full (and extendable) CTFE D parser, and that no such parser
is provided by Phobos.

It would be interesting to try the "extendable CTFE D parser" route
instead of the "AST macros as built-in primitive" route.  For example,
you could use it to add new lexical tokens to D, something that would be
impossible with AST macros.


-- 
Rainer Deyke - rainerd eldwood.com
Jul 12 2010
parent reply "Nick Sabalausky" <a a.a> writes:
"Rainer Deyke" <rainerd eldwood.com> wrote in message 
news:i1gs16$1oj3$1 digitalmars.com...

 On 7/12/2010 19:41, Nick Sabalausky wrote:

 I already agreed to that part ("For writing, yes..."). But there are 
 other
 uses that *do* parse, and others that do both. The point is NOT that 
 string
 mixins are *always* unsatisfactory as a replacement for AST macros. The
 point is that *there are perfectly legitimate use-cases* where string 
 mixins
 are unsatisfactory as a replacement for AST macros. I think you've 
 already
 agreed to this in other posts.



 The great strength of string mixins is that you can use them to add the
 AST macros to D.  The great weakness of string mixins is that doing so
 requires a full (and extendable) CTFE D parser, and that no such parser
 is provided by Phobos.



Seems to me that would lead to unnecessary decreases in compilation 
performance. Such as superfluous re-parsing. And depending how exactly DMD 
does CTFE, a CTFE D parser could be slower than just simply having DMD do 
the parsing directly.
Jul 13 2010
parent reply Rainer Deyke <rainerd eldwood.com> writes:
On 7/13/2010 01:03, Nick Sabalausky wrote:

 "Rainer Deyke" <rainerd eldwood.com> wrote in message 
 news:i1gs16$1oj3$1 digitalmars.com...

 The great strength of string mixins is that you can use them to add the
 AST macros to D.  The great weakness of string mixins is that doing so
 requires a full (and extendable) CTFE D parser, and that no such parser
 is provided by Phobos.



 Seems to me that would lead to unnecessary decreases in compilation 
 performance. Such as superfluous re-parsing. And depending how exactly DMD 
 does CTFE, a CTFE D parser could be slower than just simply having DMD do 
 the parsing directly.



True. I tend to ignore compile-time costs.  The performance of computers
is increasing exponentially.  The length of the average computer program
is more or less stable.  Therefore this particular problem will
eventually solve itself.

Of course, this is just my perspective as a developer who uses a
compiler maybe twenty times a day.  If I was writing my own compiler
which was going to be used thousands of times a day by thousands of
different developers, I'd have a different attitude.


-- 
Rainer Deyke - rainerd eldwood.com
Jul 13 2010
next sibling parent "Nick Sabalausky" <a a.a> writes:
"Rainer Deyke" <rainerd eldwood.com> wrote in message 
news:i1h52o$2kb7$1 digitalmars.com...

 On 7/13/2010 01:03, Nick Sabalausky wrote:

 "Rainer Deyke" <rainerd eldwood.com> wrote in message
 news:i1gs16$1oj3$1 digitalmars.com...

 The great strength of string mixins is that you can use them to add the
 AST macros to D.  The great weakness of string mixins is that doing so
 requires a full (and extendable) CTFE D parser, and that no such parser
 is provided by Phobos.



 Seems to me that would lead to unnecessary decreases in compilation
 performance. Such as superfluous re-parsing. And depending how exactly 
 DMD
 does CTFE, a CTFE D parser could be slower than just simply having DMD do
 the parsing directly.



 True. I tend to ignore compile-time costs.  The performance of computers
 is increasing exponentially.  The length of the average computer program
 is more or less stable.  Therefore this particular problem will
 eventually solve itself.



The people behind C++ probably thought the same thing ;)


 Of course, this is just my perspective as a developer who uses a
 compiler maybe twenty times a day.  If I was writing my own compiler
 which was going to be used thousands of times a day by thousands of
 different developers, I'd have a different attitude.
Jul 13 2010
prev sibling parent reply Don <nospam nospam.com> writes:
Rainer Deyke wrote:

 On 7/13/2010 01:03, Nick Sabalausky wrote:

 "Rainer Deyke" <rainerd eldwood.com> wrote in message 
 news:i1gs16$1oj3$1 digitalmars.com...

 The great strength of string mixins is that you can use them to add the
 AST macros to D.  The great weakness of string mixins is that doing so
 requires a full (and extendable) CTFE D parser, and that no such parser
 is provided by Phobos.



 performance. Such as superfluous re-parsing. And depending how exactly DMD 
 does CTFE, a CTFE D parser could be slower than just simply having DMD do 
 the parsing directly.



 True. I tend to ignore compile-time costs.  The performance of computers
 is increasing exponentially.  The length of the average computer program
 is more or less stable.  Therefore this particular problem will
 eventually solve itself.
 
 Of course, this is just my perspective as a developer who uses a
 compiler maybe twenty times a day.  If I was writing my own compiler
 which was going to be used thousands of times a day by thousands of
 different developers, I'd have a different attitude.
 
 



CTFE isn't intrinsically slow. The reason it's so slow in DMD right now 
is that the treatment of CTFE variables is done in an absurdly 
inefficient way.
Jul 13 2010
next sibling parent reply bearophile <bearophileHUGS lycos.com> writes:
Don:

 CTFE isn't intrinsically slow. The reason it's so slow in DMD right now 
 is that the treatment of CTFE variables is done in an absurdly 
 inefficient way.



Are those arrays managed like immutable arrays in a functional language? :-)
To implement mutable arrays with an immutable data structure you need a GC
designed for it (like the Haskell one) and a different underlying
implementation, like a finger tree, that avoids most of the copying and
allocations :-)

Bye,
bearophile
Jul 13 2010
parent Don <nospam nospam.com> writes:
bearophile wrote:

 Don:

 CTFE isn't intrinsically slow. The reason it's so slow in DMD right now 
 is that the treatment of CTFE variables is done in an absurdly 
 inefficient way.



 Are those arrays managed like immutable arrays in a functional language? :-)



*Everything* is done with copy-on-write. It's not an appropriate way to 
implement mutable variables in an interpreter.


 To implement mutable arrays with an immutable data structure you need a GC
designed for it (like the Haskell one) and a different underlying
implementation, like a finger tree, that avoids most of the copying and
allocations :-)



Yes, and even that would never work very well for a D interpreter.
Jul 13 2010
prev sibling parent reply "Nick Sabalausky" <a a.a> writes:
"Don" <nospam nospam.com> wrote in message 
news:i1h6br$2ngl$1 digitalmars.com...

 Rainer Deyke wrote:

 On 7/13/2010 01:03, Nick Sabalausky wrote:

 "Rainer Deyke" <rainerd eldwood.com> wrote in message 
 news:i1gs16$1oj3$1 digitalmars.com...

 The great strength of string mixins is that you can use them to add the
 AST macros to D.  The great weakness of string mixins is that doing so
 requires a full (and extendable) CTFE D parser, and that no such parser
 is provided by Phobos.



 performance. Such as superfluous re-parsing. And depending how exactly 
 DMD does CTFE, a CTFE D parser could be slower than just simply having 
 DMD do the parsing directly.



 True. I tend to ignore compile-time costs.  The performance of computers
 is increasing exponentially.  The length of the average computer program
 is more or less stable.  Therefore this particular problem will
 eventually solve itself.

 Of course, this is just my perspective as a developer who uses a
 compiler maybe twenty times a day.  If I was writing my own compiler
 which was going to be used thousands of times a day by thousands of
 different developers, I'd have a different attitude.



 CTFE isn't intrinsically slow. The reason it's so slow in DMD right now is 
 that the treatment of CTFE variables is done in an absurdly inefficient 
 way.



Doesn't it at least have some intrinsic overhead? The best way I can think 
of to do it (in fact, the way Nemerle does it, and I really wish D did too) 
is to actually fully compile the CTFE then dynamiclly link it in and run it 
natively (erm, well, Nemerle is .NET, not native, but you get the idea). 
Even that would seem to have a little bit of overhead compared to just 
running code that's already built-in to the compiler (it has to compile a 
chunk of code, and then link it, both of which take more time than just 
calling an internal function). And if you're not doing it that way then 
you're interpreting, which inherently adds some fetch/dispatch processing.

Yea, certainly it could be made to be fairly fast, and the overhead doesn't 
*have* to be big enough to be noticable. But why not just do it the *really* 
fast way right from the start? Especially in a language like D that's 
supposed to have an emphasis on short compile times.
Jul 13 2010
parent reply "Nick Sabalausky" <a a.a> writes:
"Nick Sabalausky" <a a.a> wrote in message 
news:i1i8o8$1kb1$1 digitalmars.com...

 "Don" <nospam nospam.com> wrote in message 
 news:i1h6br$2ngl$1 digitalmars.com...

 Rainer Deyke wrote:

 On 7/13/2010 01:03, Nick Sabalausky wrote:

 "Rainer Deyke" <rainerd eldwood.com> wrote in message 
 news:i1gs16$1oj3$1 digitalmars.com...

 The great strength of string mixins is that you can use them to add 
 the
 AST macros to D.  The great weakness of string mixins is that doing so
 requires a full (and extendable) CTFE D parser, and that no such 
 parser
 is provided by Phobos.



 performance. Such as superfluous re-parsing. And depending how exactly 
 DMD does CTFE, a CTFE D parser could be slower than just simply having 
 DMD do the parsing directly.



 True. I tend to ignore compile-time costs.  The performance of computers
 is increasing exponentially.  The length of the average computer program
 is more or less stable.  Therefore this particular problem will
 eventually solve itself.

 Of course, this is just my perspective as a developer who uses a
 compiler maybe twenty times a day.  If I was writing my own compiler
 which was going to be used thousands of times a day by thousands of
 different developers, I'd have a different attitude.



 CTFE isn't intrinsically slow. The reason it's so slow in DMD right now 
 is that the treatment of CTFE variables is done in an absurdly 
 inefficient way.



 Doesn't it at least have some intrinsic overhead? The best way I can think 
 of to do it (in fact, the way Nemerle does it, and I really wish D did 
 too) is to actually fully compile the CTFE then dynamiclly link it in and 
 run it natively (erm, well, Nemerle is .NET, not native, but you get the 
 idea). Even that would seem to have a little bit of overhead compared to 
 just running code that's already built-in to the compiler (it has to 
 compile a chunk of code, and then link it, both of which take more time 
 than just calling an internal function). And if you're not doing it that 
 way then you're interpreting, which inherently adds some fetch/dispatch 
 processing.

 Yea, certainly it could be made to be fairly fast, and the overhead 
 doesn't *have* to be big enough to be noticable. But why not just do it 
 the *really* fast way right from the start? Especially in a language like 
 D that's supposed to have an emphasis on short compile times.



Plus, there's the whole duplication of code: D parser in C++, plus a D 
parser in D CTFE.
Jul 13 2010
parent reply Johan Granberg <lijat.meREM OVEgmail.com> writes:
Nick Sabalausky wrote:

 Plus, there's the whole duplication of code: D parser in C++, plus a D
 parser in D CTFE.



On the other hand this would give us an D parser in D that might help in
making D self hosting.
Jul 14 2010
next sibling parent Clemens <eriatarka84 gmail.com> writes:
Johan Granberg Wrote:


 Nick Sabalausky wrote:

 Plus, there's the whole duplication of code: D parser in C++, plus a D
 parser in D CTFE.



 On the other hand this would give us an D parser in D that might help in
 making D self hosting.
 



http://code.google.com/p/dil/

"Dil is a hand-crafted compiler implementation for the D programming language
written in D 1.0 using the Tango standard library. The lexer and the parser are
fully implemented."

http://www.dsource.org/projects/ddmd

"DDMD is a direct port of official Digital Mars D compiler to the D Programming
Language."

Both of these are not fully functional compilers, but lexing and parsing seems
to be reasonably complete in both of them.
Jul 14 2010
prev sibling parent reply Justin Johansson <no spam.com> writes:
Johan Granberg wrote:

 Nick Sabalausky wrote:

 Plus, there's the whole duplication of code: D parser in C++, plus a D
 parser in D CTFE.



 On the other hand this would give us an D parser in D that might help in
 making D self hosting.



Not a chance -- pigs will fly before that and before that that, some
pigs will wear a show of lipstick.
Jul 14 2010
parent Johan Granberg <lijat.meREM OVEgmail.com> writes:
Justin Johansson wrote:


 Johan Granberg wrote:

 Nick Sabalausky wrote:

 Plus, there's the whole duplication of code: D parser in C++, plus a D
 parser in D CTFE.



 On the other hand this would give us an D parser in D that might help in
 making D self hosting.



 Not a chance -- pigs will fly before that and before that that, some
 pigs will wear a show of lipstick.



I can still wish :)
Jul 14 2010
prev sibling next sibling parent reply pillsy <pillsbury gmail.com> writes:
== Quote from Steven Schveighoffer (schveiguy yahoo.com)'s article:


 On Mon, 12 Jul 2010 16:22:28 -0400, bearophile <bearophileHUGS lycos.com>
 wrote:




 In my opinion the std.bitmanip.bitfields souce code is already past the
 decency limit for string mixins, and I hope they will be replaced by
 something better.



 have never seen it before, and I understood it after a couple minutes
 reading.  I bet the AST version would be actually harder to understand.



That's not such a great example. The problems will start piling up when you
have more complicated arguments.
Say you want your macro to look like it has an argument list with two entries,
called like

     foo(x, y)

which acts like a string mixin, and receives "x, y" as the argument string.
Then you split at the comma, and
you're fine. You go on with your day, and the next thing you know someone is
complaining that your foo macro
doesn't work because it chokes on

    foo(bar(a, b), c)

and

    foo("d, e", f)

By the time you deal with all the possibilities, you'll have written most of a
parser. That parser has gotta parse
the text into *something*, and it'll probably be a tree.

There's no reason you can't use library functions to parse strings containing D
code into that tree; indeed,
having access to such functions in the standard library would be useful in all
sorts of ways. RIght now D is only
a couple steps away from where it would need to be in order to allow people to
build a really useful macro
system in libraries.

Cheers,
Pillsy
[...]
Jul 12 2010
parent "Nick Sabalausky" <a a.a> writes:
"Steven Schveighoffer" <schveiguy yahoo.com> wrote in message 
news:op.vfr7dti0eav7ka localhost.localdomain...

 Pulling apart an  expression and reassmbling it can solve some problems, 
 but the majority of  the reason to need macros is to generate code, not to 
 read it and rewrite  it.



I can't help wondering if that is largely just because we're accustomed to 
not being able to do the "pull apart" without significant effort. I think we 
need to look at some of the use-cases in languages like Nemerle that have 
that sort of thing.
Jul 13 2010
prev sibling next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 07/13/2010 10:48 AM, retard wrote:

 Mon, 12 Jul 2010 16:53:12 -0400, Steven Schveighoffer wrote:


 Brainfuck is basically a toy example of a language.  Nobody uses it for
 serious work.




 Having used php for the last year in my job, there is one thing I
 appreciate: with a language that is focused on string manipulation, it
 is so much better to be able to simply output variables inside strings
 rather than having to exit a quotation, and use a concatenation
 operator.



 Php is basically a toy example of a language.  Nobody uses it for serious
 work.



Facebook.

Andrei
Jul 13 2010
next sibling parent Ellery Newcomer <ellery-newcomer utulsa.edu> writes:
On 07/13/2010 11:09 AM, Andrei Alexandrescu wrote:

 On 07/13/2010 10:48 AM, retard wrote:

 Php is basically a toy example of a language. Nobody uses it for serious
 work.



 Facebook.

 Andrei



Wait, which side are you arguing for?
Jul 13 2010
prev sibling parent reply "Nick Sabalausky" <a a.a> writes:
"Andrei Alexandrescu" <SeeWebsiteForEmail erdani.org> wrote in message 
news:i1i332$19jl$2 digitalmars.com...

 On 07/13/2010 10:48 AM, retard wrote:

 Mon, 12 Jul 2010 16:53:12 -0400, Steven Schveighoffer wrote:


 Brainfuck is basically a toy example of a language.  Nobody uses it for
 serious work.




 Having used php for the last year in my job, there is one thing I
 appreciate: with a language that is focused on string manipulation, it
 is so much better to be able to simply output variables inside strings
 rather than having to exit a quotation, and use a concatenation
 operator.



 Php is basically a toy example of a language.  Nobody uses it for serious
 work.



 Facebook.



Nothing personal, but I wouldn't consider any of those social networking 
sites to be remotely "serious". They're like the web-app equivilent of PHP - 
useless garbage. And just because they're popular doesn't mean they're not 
useless garbage - just look at any fad. They're the modern pet rock, and I 
hope they die out just as quick. (Again, nothing personal.)
Jul 13 2010
next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 07/13/2010 01:00 PM, Nick Sabalausky wrote:

 "Andrei Alexandrescu"<SeeWebsiteForEmail erdani.org>  wrote in message
 news:i1i332$19jl$2 digitalmars.com...

 On 07/13/2010 10:48 AM, retard wrote:

 Mon, 12 Jul 2010 16:53:12 -0400, Steven Schveighoffer wrote:


 Brainfuck is basically a toy example of a language.  Nobody uses it for
 serious work.




 Having used php for the last year in my job, there is one thing I
 appreciate: with a language that is focused on string manipulation, it
 is so much better to be able to simply output variables inside strings
 rather than having to exit a quotation, and use a concatenation
 operator.



 Php is basically a toy example of a language.  Nobody uses it for serious
 work.



 Facebook.



 Nothing personal, but I wouldn't consider any of those social networking
 sites to be remotely "serious".



Me neither until I started working for them. Facebook is one of the most 
difficult companies to get hired at as a programmer, and as a direct 
consequence has amassed a lot of talented folks working on hard, 
interesting problems.

Andrei
Jul 13 2010
next sibling parent "Nick Sabalausky" <a a.a> writes:
"Andrei Alexandrescu" <SeeWebsiteForEmail erdani.org> wrote in message 
news:i1ibci$1omk$1 digitalmars.com...

 On 07/13/2010 01:00 PM, Nick Sabalausky wrote:

 Nothing personal, but I wouldn't consider any of those social networking
 sites to be remotely "serious".



 Me neither until I started working for them. Facebook is one of the most 
 difficult companies to get hired at as a programmer,



Just out of pure curiosity, what sorts of criterea do they use?


 and as a direct consequence has amassed a lot of talented folks working on 
 hard, interesting problems.
Jul 13 2010
prev sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 07/14/2010 12:07 PM, retard wrote:

 Tue, 13 Jul 2010 13:30:43 -0500, Andrei Alexandrescu wrote:


 On 07/13/2010 01:00 PM, Nick Sabalausky wrote:

 "Andrei Alexandrescu"<SeeWebsiteForEmail erdani.org>   wrote in message
 news:i1i332$19jl$2 digitalmars.com...

 On 07/13/2010 10:48 AM, retard wrote:

 Mon, 12 Jul 2010 16:53:12 -0400, Steven Schveighoffer wrote:


 Brainfuck is basically a toy example of a language.  Nobody uses it
 for serious work.




 Having used php for the last year in my job, there is one thing I
 appreciate: with a language that is focused on string manipulation,
 it is so much better to be able to simply output variables inside
 strings rather than having to exit a quotation, and use a
 concatenation operator.



 Php is basically a toy example of a language.  Nobody uses it for
 serious work.



 Facebook.



 networking sites to be remotely "serious".



 Me neither until I started working for them. Facebook is one of the most
 difficult companies to get hired at as a programmer, and as a direct
 consequence has amassed a lot of talented folks working on hard,
 interesting problems.



 Such as email scams.

 http://a.imageshack.us/img823/3307/serioususe.jpg

 I see a pattern here. Why should I trust You or Your Employer?



Not sure I understand. The monthly bitter quip?

Andrei
Jul 14 2010
prev sibling parent Bruno Medeiros <brunodomedeiros+spam com.gmail> writes:
On 13/07/2010 19:00, Nick Sabalausky wrote:

 "Andrei Alexandrescu"<SeeWebsiteForEmail erdani.org>  wrote in message
 news:i1i332$19jl$2 digitalmars.com...

 On 07/13/2010 10:48 AM, retard wrote:

 Facebook.



 Nothing personal, but I wouldn't consider any of those social networking
 sites to be remotely "serious". They're like the web-app equivilent of PHP -
 useless garbage. And just because they're popular doesn't mean they're not
 useless garbage - just look at any fad. They're the modern pet rock, and I
 hope they die out just as quick. (Again, nothing personal.)



lol...

-- 
Bruno Medeiros - Software Engineer
Jul 19 2010
prev sibling next sibling parent reply "Nick Sabalausky" <a a.a> writes:
"Steven Schveighoffer" <schveiguy yahoo.com> wrote in message 
news:op.vfsn2hvweav7ka localhost.localdomain...

 Just for fun, how would you define a serious language?

 1. Major major websites use it (facebook is one example, there are many 
 more).
 2. There are lots of books about it.
 3. people make serious money doing it, not just play money.
 4. major IDEs support it (I use netbeans, and probably would be lost 
 without it).
 5. The documentation is complete and well written.
 6. It supports interfaces to many major technologies (many databases, 
 apache, pdf, etc.)



For me, there'd be two criteria (in no order):

1. Useful
2. Doesn't suck

:)
Jul 13 2010
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 07/13/2010 02:00 PM, Nick Sabalausky wrote:

 "Steven Schveighoffer"<schveiguy yahoo.com>  wrote in message
 news:op.vfsn2hvweav7ka localhost.localdomain...

 Just for fun, how would you define a serious language?

 1. Major major websites use it (facebook is one example, there are many
 more).
 2. There are lots of books about it.
 3. people make serious money doing it, not just play money.
 4. major IDEs support it (I use netbeans, and probably would be lost
 without it).
 5. The documentation is complete and well written.
 6. It supports interfaces to many major technologies (many databases,
 apache, pdf, etc.)



 For me, there'd be two criteria (in no order):

 1. Useful
 2. Doesn't suck

 :)



That leaves only D on the table :o).

Andrei
Jul 13 2010
parent "Nick Sabalausky" <a a.a> writes:
"Andrei Alexandrescu" <SeeWebsiteForEmail erdani.org> wrote in message 
news:i1ihke$253j$6 digitalmars.com...

 On 07/13/2010 02:00 PM, Nick Sabalausky wrote:

 "Steven Schveighoffer"<schveiguy yahoo.com>  wrote in message
 news:op.vfsn2hvweav7ka localhost.localdomain...

 Just for fun, how would you define a serious language?

 1. Major major websites use it (facebook is one example, there are many
 more).
 2. There are lots of books about it.
 3. people make serious money doing it, not just play money.
 4. major IDEs support it (I use netbeans, and probably would be lost
 without it).
 5. The documentation is complete and well written.
 6. It supports interfaces to many major technologies (many databases,
 apache, pdf, etc.)



 For me, there'd be two criteria (in no order):

 1. Useful
 2. Doesn't suck

 :)



 That leaves only D on the table :o).



Yup :)

Well, and Nemerle if you're doing something that doesn't need systems 
capabilities.
Jul 13 2010
prev sibling parent Justin Johansson <no spam.com> writes:
retard wrote:

 Mon, 12 Jul 2010 16:53:12 -0400, Steven Schveighoffer wrote:
 

 Brainfuck is basically a toy example of a language.  Nobody uses it for
 serious work.  




 Having used php for the last year in my job, there is one thing I
 appreciate: with a language that is focused on string manipulation, it
 is so much better to be able to simply output variables inside strings
 rather than having to exit a quotation, and use a concatenation
 operator.



 Php is basically a toy example of a language.  Nobody uses it for serious 
 work. You just think your work is serious, but it isn't. Php shows what 
 the world would look like if it was created by an "intelligent designer".



Yep, Php is totally LIC (lacking intellectual content).

However, as sad as the state of affairs is, to say that nobody
uses it for serious work is plain wrong.

Magento ECommerce Platform
http://www.magentocommerce.com/

The Magento platform gets mega downloads and has tonnes and
tonnes of plugins developed by heaps and stacks of developers.


 I don't have much experience with these languages except that in college
 while taking a scheme course, I wanted to create a bonfire out of all
 parentheses keys.



 Sounds really mature. "I have no experience with D, it's just some shitty 
 language with lots of semicolons - yea, lots of semicolons is all I 
 remember and that after finding Python I've never looked back - Python is 
 the most native high-performance language I know". You've probably missed 
 99% of the power of Lisp by only focusing on parenthesis.



Many have heard the sad story of Viaweb, the online store application
developed by Paul Graham and Robert Morris and written in LISP

(Read all about the LISP secret weapon here)
http://www.paulgraham.com/avg.html

My understanding is that upon Yahoo acquiring Viaweb from Graham and
Morris for $megabucks, they canned LISP and rewrote the entire codebase
in some infidel PL.
Jul 13 2010
prev sibling next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 07/12/2010 03:22 PM, bearophile wrote:

 Steven Schveighoffer:

 bearophile:

 String mixins are a hack, just a bit better than C preprocessor
 (because they are scoped), they are not a replacement of clean
 macros.



 Interesting statement, can you back it up? :)  What can you do with
 a macro that you can't do with a mixin?



 In the meantime others have already given you some answers, I can add
 one example. The Brainfuck language allows you to do every kind of
 thing, I have seen even compilers written in it, but its usage is
 very unhandy, it's bug-prone, requires lot of code to do even simple
 things, and it's very hard to modify and debug programs written in
 it. What I meant is that string mixins in theory allow you to do many
 things, but in practice you can't use them for complex tasks, and you
 can't modify and fix the resulting code if you try to use them for
 more complex tasks. They are not a long-term solution for a language
 that seriously wants to improve over C and its preprocessor macros,
 they are a hack.

 In my opinion the std.bitmanip.bitfields souce code is already past
 the decency limit for string mixins, and I hope they will be replaced
 by something better.



Clearly a more structured approach would be better. On the other hand 
bitfields is literally the first code-generating tool I ever wrote, so I 
expect better idiomatic code will come about after the community's 
experience increases.


 I don't agree with Andrei when he says that CLisp macros (and even
 more Scheme macros that are hygienic too) are as hairy and
 unmantenable as code that uses string mixins heavily.



I said:

=======
Though I sympathise with all of the above, I should add that I have 
looked at languages that feature AST macros (Lisp, Scheme, Dylan) and 
such macros are difficult to create and read as well. We're not looking 
at day and night improvement there.
=======

and you claim, quite unequivocally, that I said:

=======
CLisp macros (and even more Scheme macros that are hygienic too) are as 
hairy and unmaintainable as code that uses string mixins heavily.
=======

I mean WTF?

Back on topic: http://www.apl.jhu.edu/~hall/Lisp-Notes/Macros.html. 
Compare the simple macro in the beginning and the correct macro at the end.


Andrei
Jul 12 2010
next sibling parent "Nick Sabalausky" <a a.a> writes:
"Andrei Alexandrescu" <SeeWebsiteForEmail erdani.org> wrote in message 
news:i1g5aq$2vkj$1 digitalmars.com...

 Back on topic: http://www.apl.jhu.edu/~hall/Lisp-Notes/Macros.html. 
 Compare the simple macro in the beginning and the correct macro at the 
 end.



I can't read ordinary lisp, but Nemerle's macros seem pretty damn easy to 
me:

http://nemerle.org/Macros_tutorial

And note that deconstructing the tree typically makes use of Nemerle's 
excellent pattern-matching:

http://nemerle.org/Grok_Variants_and_matching#Matching

I've long been of the opinion that Nemerle's CTFE, macros and pattern 
matching make D's counterparts look terrible in comparison (too bad Nemerle 
doesn't do low-level).
Jul 12 2010
prev sibling parent bearophile <bearophileHUGS lycos.com> writes:
Andrei Alexandrescu:

 Back on topic: http://www.apl.jhu.edu/~hall/Lisp-Notes/Macros.html. 
 Compare the simple macro in the beginning and the correct macro at the end.



CLisp macros are messy, they can be not easy to read and understand, and worse
of all they can fragment the community because every large program that defines
many complex macros essentially defines a new variety of CLisp. This makes it
hard to read, modify and reuse for other purposes CLisp code written by other
people (but allows the creation of domain-specific code, that can reduce
program size and make it simpler). Python has refused macros mostly because of
this risk of fragmentation. A significant part of the success of Python comes
from the ecosystem of tons of little modules that you can download and use in
your code with usually only little effort. A large usage of macros can kill
this.

On the other hand I believe that D string mixins, if used to replace some of
the purposes of CLisp macros, are worse than CLisp macros.

Scheme (and maybe Clojure too) macros are more hygienic so they remove some of
the problems shown in that Macros.html page, this means that a good Square
macro written in Scheme looks better and is simpler than that CLips one (on the
other hand Scheme macros can be a little less powerful, I am not expert enough
to give you examples).

Bye,
bearophile
Jul 12 2010
prev sibling next sibling parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Mon, 12 Jul 2010 19:21:08 -0400, Nick Sabalausky <a a.a> wrote:


 "Steven Schveighoffer" <schveiguy yahoo.com> wrote in message
 news:op.vfq0aydoeav7ka localhost.localdomain...

 On Mon, 12 Jul 2010 16:22:28 -0400, bearophile  
 <bearophileHUGS lycos.com>
 wrote:


 Steven Schveighoffer:

 bearophile:

 String mixins are a hack, just a bit better than C preprocessor




 they are scoped), they are not a replacement of clean macros.



 Interesting statement, can you back it up? :)  What can you do with a
 macro that you can't do with a mixin?



 In the meantime others have already given you some answers, I can add
 one example. The Brainfuck language allows you to do every kind of
 thing, I have seen even compilers written in it, but its usage is very
 unhandy, it's bug-prone, requires lot of code to do even simple things,
 and it's very hard to modify and debug programs written in it. What I
 meant is that string mixins in theory allow you to do many things, but
 in practice you can't use them for complex tasks, and you can't modify
 and fix the resulting code if you try to use them for more complex
 tasks. They are not a long-term solution for a language that seriously
 wants to improve over C and its preprocessor macros, they are a hack.



 Brainfuck is basically a toy example of a language.  Nobody uses it for
 serious work.  Mixins are much better than a hack, the syntax of using
 them is just not polished.  They are easy to use/understand because a)
 people understand the language and b) people understand string
 manipulation.



 But when you're talking about the string being actual code, you're not
 always talking about typical string manipulation, sometimes you're  
 talking
 about parsing which is only "string manipulation" superficially.



Not in most cases.  For extremes, I think perhaps there could be a niche  
for that, but it can be had via string mixins and CTFE (as long as CTFE is  
robust enough).  Having a compiler written in D wouldn't hurt either ;)


 I'll give you another example -- javascript and HTML editing.  Most  
 people
 would prefer to just use the innerHTML component of an element than have
 to use the DOM methods to create individual elements and add them as
 children, etc.



 For writing, yes, but there's also reading: How many people do you know  
 who
 would rather find the elements they want by parsing innerHTML instead of
 just dealing with the readily-available tree? None, I would hope, but the
 latter is essentially what we have to do for many of the more advanced
 things that string mixins *technically* replace AST macros for.



But you can't manipulate D code "on the fly" as you can HTML.   
Essentially, you are *always* writing code when using string manipulation  
to do mixins, because the compiler hasn't parsed it yet.

Essentially, there is no requirement that the input that you are about to  
manipulate must be valid D code, only the output should be.  That isn't to  
say it can't be valid D code, but in most cases, wouldn't you rather have  
simpler input?

-Steve
Jul 13 2010
prev sibling next sibling parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Mon, 12 Jul 2010 20:00:12 -0400, pillsy <pillsbury gmail.com> wrote:


 == Quote from Steven Schveighoffer (schveiguy yahoo.com)'s article:


 On Mon, 12 Jul 2010 16:22:28 -0400, bearophile  
 <bearophileHUGS lycos.com>
 wrote:




 In my opinion the std.bitmanip.bitfields souce code is already past  




 decency limit for string mixins, and I hope they will be replaced by
 something better.



 I
 have never seen it before, and I understood it after a couple minutes
 reading.  I bet the AST version would be actually harder to understand.



 That's not such a great example. The problems will start piling up when  
 you have more complicated arguments.
 Say you want your macro to look like it has an argument list with two  
 entries, called like

      foo(x, y)

 which acts like a string mixin, and receives "x, y" as the argument  
 string. Then you split at the comma, and
 you're fine.



This isn't exactly what I meant to do with macros.  What I wanted was for  
the commas to separate the expressions, and pass those expressions via  
stringification.  It isn't a fully fleshed out idea, but here is what I  
was thinking:

macro foo(arg1, arg2) mixin("$arg1 + $arg2;") // $ inside string  
references parameter, just a possibility

foo(x, y); // translates to mixin("x + y;");

These are just ideas, perhaps there are issues with them, but I think we  
can come up with reasonable rules that allow a lot of flexibility, and at  
the same time, allow mixins to be masked as normal expressions, resulting  
in greater usability in generic code, and much more beautiful code.


 You go on with your day, and the next thing you know someone is  
 complaining that your foo macro
 doesn't work because it chokes on

     foo(bar(a, b), c)

 and

     foo("d, e", f)

 By the time you deal with all the possibilities, you'll have written  
 most of a parser. That parser has gotta parse
 the text into *something*, and it'll probably be a tree.



Or, you say "foo isn't meant to deal with that input" :)

I don't see people complaining that bitfields doesn't accept such various  
strings as arguments...


 There's no reason you can't use library functions to parse strings  
 containing D code into that tree; indeed,
 having access to such functions in the standard library would be useful  
 in all sorts of ways. RIght now D is only
 a couple steps away from where it would need to be in order to allow  
 people to build a really useful macro
 system in libraries.



I think a full parser would not hurt, but most of the time, you just want  
to use the expressions in generating some code.  Pulling apart an  
expression and reassmbling it can solve some problems, but the majority of  
the reason to need macros is to generate code, not to read it and rewrite  
it.

-Steve
Jul 13 2010
prev sibling next sibling parent reply retard <re tard.com.invalid> writes:
Mon, 12 Jul 2010 16:53:12 -0400, Steven Schveighoffer wrote:


 Brainfuck is basically a toy example of a language.  Nobody uses it for
 serious work.  




 Having used php for the last year in my job, there is one thing I
 appreciate: with a language that is focused on string manipulation, it
 is so much better to be able to simply output variables inside strings
 rather than having to exit a quotation, and use a concatenation
 operator.



Php is basically a toy example of a language.  Nobody uses it for serious 
work. You just think your work is serious, but it isn't. Php shows what 
the world would look like if it was created by an "intelligent designer".


 I don't have much experience with these languages except that in college
 while taking a scheme course, I wanted to create a bonfire out of all
 parentheses keys.



Sounds really mature. "I have no experience with D, it's just some shitty 
language with lots of semicolons - yea, lots of semicolons is all I 
remember and that after finding Python I've never looked back - Python is 
the most native high-performance language I know". You've probably missed 
99% of the power of Lisp by only focusing on parenthesis.
Jul 13 2010
parent reply "Nick Sabalausky" <a a.a> writes:
"retard" <re tard.com.invalid> wrote in message 
news:i1i1se$ord$1 digitalmars.com...

 Php is basically a toy example of a language.  Nobody uses it for serious
 work. You just think your work is serious, but it isn't. Php shows what
 the world would look like if it was created by an "intelligent designer".



I want to have that enlarged, framed and mounted on my wall.

("That's what she said!" Ha h..umm...no...sorry...)

When I first read "Nobody uses it for serious work." I was about to hit 
Reply and object, but the next sentence hit the nail right on the head. 
*I've* used PHP plenty of times simply because I had to, but when you get 
down to it, none of that (and really no web app in general IMO) *really* 
qualifies as serious work. We may get paid to make it, but it's all just 
pointless dinky shit (and most of it's made by amateurs anyway).
Jul 13 2010
parent Justin Johansson <no spam.com> writes:
Nick Sabalausky wrote:

 "retard" <re tard.com.invalid> wrote in message 
 news:i1i1se$ord$1 digitalmars.com...

 Php is basically a toy example of a language.  Nobody uses it for serious
 work. You just think your work is serious, but it isn't. Php shows what
 the world would look like if it was created by an "intelligent designer".



 I want to have that enlarged, framed and mounted on my wall.
 
 ("That's what she said!" Ha h..umm...no...sorry...)
 
 When I first read "Nobody uses it for serious work." I was about to hit 
 Reply and object, but the next sentence hit the nail right on the head. 
 *I've* used PHP plenty of times simply because I had to, but when you get 
 down to it, none of that (and really no web app in general IMO) *really* 
 qualifies as serious work. We may get paid to make it, but it's all just 
 pointless dinky shit (and most of it's made by amateurs anyway).



I know what you mean.  While I did reply and sort of object by citing
the Magento ecommerce platform as a Php thing that is widely used,
I noted that it (Php) is a sad reality.  As for retard's paragraph
above, taken in toto with all it's subtlety, this is absolutely
brilliant writing. :-)

If retard were to write a book, I would be sure to buy a copy.
I think there must be quite a bit of mutual respect between retard
and Andrei.  Andrei is a brilliant writer also.

Cheers
Justin Johansson
Jul 13 2010
prev sibling next sibling parent retard <re tard.com.invalid> writes:
Tue, 13 Jul 2010 04:58:04 -0400, bearophile wrote:


 Don:

 CTFE isn't intrinsically slow. The reason it's so slow in DMD right now
 is that the treatment of CTFE variables is done in an absurdly
 inefficient way.



 Are those arrays managed like immutable arrays in a functional language?
 :-) To implement mutable arrays with an immutable data structure you
 need a GC designed for it (like the Haskell one) and a different
 underlying implementation, like a finger tree, that avoids most of the
 copying and allocations :-)



Why so many smileys?
Jul 13 2010
prev sibling next sibling parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Tue, 13 Jul 2010 11:48:30 -0400, retard <re tard.com.invalid> wrote:


 Mon, 12 Jul 2010 16:53:12 -0400, Steven Schveighoffer wrote:


 Brainfuck is basically a toy example of a language.  Nobody uses it for
 serious work.




 Having used php for the last year in my job, there is one thing I
 appreciate: with a language that is focused on string manipulation, it
 is so much better to be able to simply output variables inside strings
 rather than having to exit a quotation, and use a concatenation
 operator.



 Php is basically a toy example of a language.  Nobody uses it for serious
 work. You just think your work is serious, but it isn't. Php shows what
 the world would look like if it was created by an "intelligent designer".



No, it's you who are not serious ;)

php sucks as a language, but its what I have to work with.  There are some  
good parts to it.


 I don't have much experience with these languages except that in college
 while taking a scheme course, I wanted to create a bonfire out of all
 parentheses keys.



 Sounds really mature. "I have no experience with D, it's just some shitty
 language with lots of semicolons - yea, lots of semicolons is all I
 remember and that after finding Python I've never looked back - Python is
 the most native high-performance language I know". You've probably missed
 99% of the power of Lisp by only focusing on parenthesis.



So go join the lisp newsgroup and give out online high fives.  I'll just  
stay right here, thanks :)

-Steve
Jul 13 2010
prev sibling next sibling parent retard <re tard.com.invalid> writes:
Tue, 13 Jul 2010 11:09:07 -0500, Andrei Alexandrescu wrote:


 On 07/13/2010 10:48 AM, retard wrote:

 Mon, 12 Jul 2010 16:53:12 -0400, Steven Schveighoffer wrote:


 Brainfuck is basically a toy example of a language.  Nobody uses it
 for serious work.




 Having used php for the last year in my job, there is one thing I
 appreciate: with a language that is focused on string manipulation, it
 is so much better to be able to simply output variables inside strings
 rather than having to exit a quotation, and use a concatenation
 operator.



 Php is basically a toy example of a language.  Nobody uses it for
 serious work.



 Facebook.



If they paid you as much in the academia, you'd probably enjoy your life 
more writing D or C++. I guess this is also an ethical issue, I despise 
guys like Zuckerberg who don't respect people's privacy and spy on their 
personal data. He probably pays well if you're a famous world class C++ 
book author, but I'd find my position a bit uneasy.
Jul 13 2010
prev sibling next sibling parent retard <re tard.com.invalid> writes:
Tue, 13 Jul 2010 13:09:08 -0400, Steven Schveighoffer wrote:


 On Tue, 13 Jul 2010 11:48:30 -0400, retard <re tard.com.invalid> wrote:
 

 Mon, 12 Jul 2010 16:53:12 -0400, Steven Schveighoffer wrote:


 Brainfuck is basically a toy example of a language.  Nobody uses it
 for serious work.




 Having used php for the last year in my job, there is one thing I
 appreciate: with a language that is focused on string manipulation, it
 is so much better to be able to simply output variables inside strings
 rather than having to exit a quotation, and use a concatenation
 operator.



 Php is basically a toy example of a language.  Nobody uses it for
 serious work. You just think your work is serious, but it isn't. Php
 shows what the world would look like if it was created by an
 "intelligent designer".



 No, it's you who are not serious ;)
 
 php sucks as a language, but its what I have to work with.  There are
 some good parts to it.



There are no good parts in PHP, but you're right that it is used in the 
real world.


 

 I don't have much experience with these languages except that in
 college while taking a scheme course, I wanted to create a bonfire out
 of all parentheses keys.



 Sounds really mature. "I have no experience with D, it's just some
 shitty language with lots of semicolons - yea, lots of semicolons is
 all I remember and that after finding Python I've never looked back -
 Python is the most native high-performance language I know". You've
 probably missed 99% of the power of Lisp by only focusing on
 parenthesis.



 So go join the lisp newsgroup and give out online high fives.  I'll just
 stay right here, thanks :)



It doesn't matter what language you use. The concepts are the same 
regardless of the syntax. If I liked the parenthesis hell, I'd probably 
use Lisp. But it's still not a good argument to bring up every time Lisp 
is being discussed. You're dismissing all intelligent discussion by 
ranting about the syntax. Almost everyone here agrees that Lisp has too 
little syntax, so that point doesn't bring any new value.
Jul 13 2010
prev sibling next sibling parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Tue, 13 Jul 2010 13:20:03 -0400, retard <re tard.com.invalid> wrote:


 It doesn't matter what language you use. The concepts are the same
 regardless of the syntax. If I liked the parenthesis hell, I'd probably
 use Lisp. But it's still not a good argument to bring up every time Lisp
 is being discussed. You're dismissing all intelligent discussion by
 ranting about the syntax. Almost everyone here agrees that Lisp has too
 little syntax, so that point doesn't bring any new value.



Maybe you misunderstood my original statement.  Scheme may introduce some  
nice paradigms, and be well designed, but I just couldn't get past the  
parentheses.  Therefore, I have little experience in scheme, even though I  
used it.  That's all I was saying.

My professor would write some scheme example on the board, and then write  
a bunch of closing parentheses as he was saying "cdr, cons, etc." so I was  
absolutely thoroughly lost most of the time :)  I'm surprised I even  
passed that class.  We had to write a scheme interpreter in scheme, it was  
probably way too advanced for my brain at the time.

-Steve
Jul 13 2010
prev sibling next sibling parent retard <re tard.com.invalid> writes:
Tue, 13 Jul 2010 13:30:19 -0400, Steven Schveighoffer wrote:


 On Tue, 13 Jul 2010 13:20:03 -0400, retard <re tard.com.invalid> wrote:
 

 It doesn't matter what language you use. The concepts are the same
 regardless of the syntax. If I liked the parenthesis hell, I'd probably
 use Lisp. But it's still not a good argument to bring up every time
 Lisp is being discussed. You're dismissing all intelligent discussion
 by ranting about the syntax. Almost everyone here agrees that Lisp has
 too little syntax, so that point doesn't bring any new value.



 Maybe you misunderstood my original statement.  Scheme may introduce
 some nice paradigms, and be well designed, but I just couldn't get past
 the parentheses.  Therefore, I have little experience in scheme, even
 though I used it.  That's all I was saying.
 
 My professor would write some scheme example on the board, and then
 write a bunch of closing parentheses as he was saying "cdr, cons, etc."
 so I was absolutely thoroughly lost most of the time :)  I'm surprised I
 even passed that class.  We had to write a scheme interpreter in scheme,
 it was probably way too advanced for my brain at the time.



Ok. There are some code visualization tools for Lisp/Scheme with color 
encoded blocks and indentation instead of parentheses. You could also 
rewrite 'car' and 'cdr' as 'head' and 'tail'.
Jul 13 2010
prev sibling next sibling parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Tue, 13 Jul 2010 14:08:15 -0400, Nick Sabalausky <a a.a> wrote:


 "retard" <re tard.com.invalid> wrote in message
 news:i1i1se$ord$1 digitalmars.com...

 Php is basically a toy example of a language.  Nobody uses it for  
 serious
 work. You just think your work is serious, but it isn't. Php shows what
 the world would look like if it was created by an "intelligent  
 designer".



 I want to have that enlarged, framed and mounted on my wall.

 ("That's what she said!" Ha h..umm...no...sorry...)

 When I first read "Nobody uses it for serious work." I was about to hit
 Reply and object, but the next sentence hit the nail right on the head.
 *I've* used PHP plenty of times simply because I had to, but when you get
 down to it, none of that (and really no web app in general IMO) *really*
 qualifies as serious work. We may get paid to make it, but it's all just
 pointless dinky shit (and most of it's made by amateurs anyway).



Just for fun, how would you define a serious language?

1. Major major websites use it (facebook is one example, there are many  
more).
2. There are lots of books about it.
3. people make serious money doing it, not just play money.
4. major IDEs support it (I use netbeans, and probably would be lost  
without it).
5. The documentation is complete and well written.
6. It supports interfaces to many major technologies (many databases,  
apache, pdf, etc.)

I'd agree that php has some serious drawbacks, I can't tell you how many  
times I miss static typing when working on a daily basis (try forgetting  
to use $this when writing an object).  But it's just another language, one  
that works, and is well defined.  I'd also agree that there are lots of  
non-serious developers using it, which means the quality of any one piece  
of code has a better chance of being crappy than a piece of C++ code, but  
I've seen a lot of crappy C++ code too.

-Steve
Jul 13 2010
prev sibling next sibling parent Jonathan M Davis <jmdavisprog gmail.com> writes:
On Tuesday, July 13, 2010 12:00:45 Nick Sabalausky wrote:

 "Steven Schveighoffer" <schveiguy yahoo.com> wrote in message
 news:op.vfsn2hvweav7ka localhost.localdomain...
 

 Just for fun, how would you define a serious language?
 
 1. Major major websites use it (facebook is one example, there are many
 more).
 2. There are lots of books about it.
 3. people make serious money doing it, not just play money.
 4. major IDEs support it (I use netbeans, and probably would be lost
 without it).
 5. The documentation is complete and well written.
 6. It supports interfaces to many major technologies (many databases,
 apache, pdf, etc.)



 For me, there'd be two criteria (in no order):
 
 1. Useful
 2. Doesn't suck
 
 :)



Arguably, _every_ computer language sucks - if nothing else because the 
designers of each and every language had to make decisions with pros and cons, 
and they aren't omniscient, so they're bound to have made mistakes of some 
variety in the language design. The real questions are how well the language 
does what you're trying to do and how close it operates to how you think.

Depending on what you're doing, any particular language could be fantastic or
it 
could be horrible. And there are always drawbacks of some kind no matter _what_ 
you do. So, really, they all suck. It's more a question of which sucks the
least 
than which doesn't suck.

Personally, I find that D is the closest to what I'm looking for in a language, 
and I think that it's the best language out there. But it's by no means
perfect, 
and it never will be no matter how much Walter, Andrei, et al work on it. Every 
language has problems and that's not going to change. If nothing else, there
are 
just too many places in computing where there are tradeoffs.

- Jonathan M Davis
Jul 13 2010
prev sibling next sibling parent retard <re tard.com.invalid> writes:
Wed, 14 Jul 2010 07:45:18 +0930, Justin Johansson wrote:


 Nick Sabalausky wrote:

 "retard" <re tard.com.invalid> wrote in message
 news:i1i1se$ord$1 digitalmars.com...

 Php is basically a toy example of a language.  Nobody uses it for
 serious work. You just think your work is serious, but it isn't. Php
 shows what the world would look like if it was created by an
 "intelligent designer".



 
 ("That's what she said!" Ha h..umm...no...sorry...)
 
 When I first read "Nobody uses it for serious work." I was about to hit
 Reply and object, but the next sentence hit the nail right on the head.
 *I've* used PHP plenty of times simply because I had to, but when you
 get down to it, none of that (and really no web app in general IMO)
 *really* qualifies as serious work. We may get paid to make it, but
 it's all just pointless dinky shit (and most of it's made by amateurs
 anyway).



 I know what you mean.  While I did reply and sort of object by citing
 the Magento ecommerce platform as a Php thing that is widely used, I
 noted that it (Php) is a sad reality.  As for retard's paragraph above,
 taken in toto with all it's subtlety, this is absolutely brilliant
 writing. :-)
 
 If retard were to write a book, I would be sure to buy a copy. I think
 there must be quite a bit of mutual respect between retard and Andrei. 
 Andrei is a brilliant writer also.



Of course I admire him as person, but you're ranking my pseudonym a lot 
higher than necessary.

Lately I've completely lossed interest in programming and focused on 
managing techies. I kept learning new and new languages and concepts, but 
eventually was left empty handed. The problem is, many language suck and 
you not only need good technology but also people with adeguate skills. 
The situation looks much brighter (at least to me) when you can focus on 
higher level concepts and forget programming language constructs. Of 
course it's still interesting to read new papers about PLs. LtU is a 
great site.
Jul 13 2010
prev sibling parent retard <re tard.com.invalid> writes:
Tue, 13 Jul 2010 13:30:43 -0500, Andrei Alexandrescu wrote:


 On 07/13/2010 01:00 PM, Nick Sabalausky wrote:

 "Andrei Alexandrescu"<SeeWebsiteForEmail erdani.org>  wrote in message
 news:i1i332$19jl$2 digitalmars.com...

 On 07/13/2010 10:48 AM, retard wrote:

 Mon, 12 Jul 2010 16:53:12 -0400, Steven Schveighoffer wrote:


 Brainfuck is basically a toy example of a language.  Nobody uses it
 for serious work.




 Having used php for the last year in my job, there is one thing I
 appreciate: with a language that is focused on string manipulation,
 it is so much better to be able to simply output variables inside
 strings rather than having to exit a quotation, and use a
 concatenation operator.



 Php is basically a toy example of a language.  Nobody uses it for
 serious work.



 Facebook.



 networking sites to be remotely "serious".



 Me neither until I started working for them. Facebook is one of the most
 difficult companies to get hired at as a programmer, and as a direct
 consequence has amassed a lot of talented folks working on hard,
 interesting problems.



Such as email scams.

http://a.imageshack.us/img823/3307/serioususe.jpg

I see a pattern here. Why should I trust You or Your Employer?
Jul 14 2010