In article <b370f0$a7r$1@digitaldaemon.com>, Mark Evans says...
>
>The author deliberates between C, C++, Java, OCaml, Scheme, Lisp.  Maybe I should have put the subject as "Re: OCaml" but that was getting tired.  -M.
>
>http://www.paulgraham.com/vanlfsp.html
>
>'Writing Java code, though not particulary painful in the sense that C is painful (core dumps etc.), puts me to sleep. Writing Ocaml ... is exciting. My motivation to tackle the project has tripled overnight.... Why are "languages designed for smart people" (LFSPs) so much more fun to program in than "languages designed for the masses" (LFMs)?'

Yes, languages for smart people are more fun.  However, nearly all software that sell well, and even most open-source code, is eventually worked on by the other kind of people.  This is why GNU recommends staying away from C++, and contributing code in plain old C.

The real trick is making the language as powerful as possbile, while keeping the compiler lean, and keeping those other kinds of people from shooting themselves in the foot.

Bill

P.S.  I happen to specialize in keeping programmers' feet healthy.

A must read from Paul Graham.  I could not have offered a better rationale for first-class functions, though the principle stated is general, and so deserves its own thread.

The design goals of D put certain constraints on the full development of this idea, but the ceiling is a lot higher than anyone involved with D really understands.  Vault's decision to use first-class functions is one evidence of that fact.  -M.


http://www.paulgraham.com/power.html http://www.paulgraham.com/fix.html

"It seems to me that succinctness is what programming languages are for. Computers would be just as happy to be told what to do directly in machine language. I think that the main reason we take the trouble to develop high-level languages is to get leverage, so that we can say (and more importantly, think) in 10 lines of a high-level language what would require 1000 lines of machine language. In other words, the main point of high-level languages to make source code smaller."

"The main value of the succinctness test is as a guide in designing languages. The most useful comparison between languages is between two potential variants of the same language. What can I do in the language to make programs shorter?"

"Aiming for succinctness seems a good way to find new ideas. If you can do something that makes many different programs shorter, it is probably not a coincidence: you have probably discovered a useful new abstraction."

"...programs written in more powerful languages tend to have fewer bugs."

Hi, Mark.

Great links!  The second one is the funniest computer language related page I ever read.

>http://www.paulgraham.com/power.html http://www.paulgraham.com/fix.html

I agree for the need of powerful constructs.  The smoke test for a language's power that I use is a simple reusable directed graph package.

Every popular efficiently compiled language I've tried it in has failed to elegantly support it!

We've talked a about it on this newsgroup, and haven't come up with a clean solution in D.

In C and C++, I write the same stupid isomorphic functions over and over and over...  Want to break loops in a directed graph in a single linear traversal? I've written it dozens of times.  How about finding a max weighted path from primary inputs to outputs (representing circuit delay)?  It hurts every time I write it.  The types change, but never the algorithms.

Bill

I feel like that burned out hacker he talks about.

I need a new language in a bad way.  C++ is getting really really old.  I find myself fighting the language more than focusing on the original problem.  Hell most of my problems are caused directly by the implementation language and the crystal structure that C++ programs naturally solidify into as they grow.

I grow bored with the problem by the time I get halfway through implementing its solution, or a deadline comes along and it has to be put on hold until I forget about it, or until the feature gets dropped due to lack of time.

Maybe it's just me.  But I really am not all that excited about programming anymore.  A new language that gave me lots of expressive power while simultaneously freeing me from the mundane worries of memory management and cleanup and type checking and syntactical nitpicking would be a godsend.

Maybe I should check out OCaml more.  I looked at it but it seems, how shall I put it, a little inelegant.  I don't have much time for learning languages anymore.  It's hard to decide which one to pursue.

Sean

"Mark Evans" <Mark_member@pathlink.com> wrote in message news:b370f0$a7r$1@digitaldaemon.com...
> The author deliberates between C, C++, Java, OCaml, Scheme, Lisp.  Maybe I should have put the subject as "Re: OCaml" but that was getting
ired.  -M.
>
> http://www.paulgraham.com/vanlfsp.html
>
> 'Writing Java code, though not particulary painful in the sense that C is painful (core dumps etc.), puts me to sleep. Writing Ocaml ... is
exciting. My
> motivation to tackle the project has tripled overnight.... Why are
"languages
> designed for smart people" (LFSPs) so much more fun to program in than
> "languages designed for the masses" (LFMs)?'

Sean L. Palmer wrote:
> I feel like that burned out hacker he talks about.
> 
> I need a new language in a bad way.  C++ is getting really really old.  I
> find myself fighting the language more than focusing on the original
> problem.  Hell most of my problems are caused directly by the implementation
> language and the crystal structure that C++ programs naturally solidify into
> as they grow.

Man, I'm with you there...  I've gotten so frustrated, I've even written my own language to solve the issues I've been fighting forever.  I have the authority to make our company use it... but even if it doubles our productivity, that would probably be stupid.  D is remarkably close to what I have been working on, and I think it has a real chance of success.

If it could just support directed graphs well, I'd be happy.

Bill

"Bill Cox" <bill@viasic.com> wrote in message news:3E57BCC7.6050301@viasic.com...
> If it could just support directed graphs well, I'd be happy.

Could you elaborate, please? (I apologize if you have before.)

"Mark Evans" <Mark_member@pathlink.com> wrote in message news:b37347$cdr$1@digitaldaemon.com...
> http://www.paulgraham.com/fix.html

D: C++ is too complicated

"Mark Evans" <Mark_member@pathlink.com> wrote in message news:b37347$cdr$1@digitaldaemon.com...
> http://www.paulgraham.com/power.html

A good read. The major cases where D significantly increases the succintness of programs:

1) garbage collection - all that memory management code is gone. It's amazing how this cleans up and simplifies code.

2) class objects referenced by handles only - gone are the need for and complicated semantics of copy constructors and assignment overloads.

3) array management - the whole scheme of slicing, concatenation, and automatic memory management of arrays is a big shrinker of programs.

4) templates - I believe (though not yet born out by experience) that D's practice of grouping a bunch of related declarations under one template is a big shrinker for template programming.

Hi, Walter.

Walter wrote:
> "Bill Cox" <bill@viasic.com> wrote in message
> news:3E57BCC7.6050301@viasic.com...
> 
>>If it could just support directed graphs well, I'd be happy.
> 
> 
> Could you elaborate, please? (I apologize if you have before.)

Sure.  It's somewhat complicated.  I wish I could sumarize the problems in one or two lines, but I can't.

Just to jump ahead, I think a good solution can be found in Sather. Their "reuse" construct looks easy to implement (of course, templates looked easy too...).  Ken Carpenter's suggested "framwork" idea seems to also work well.

If you look at the non-reusable pseudo-code I posted for the Pizza Contest, I think you'll find it both readable, and likely to lead to an efficient implementation (Ok, I haven't compiled it yet... you'll probably find that I've got glaring errors).  I think when you see the reusable versions people hopefully will write for the contest, you'll see that they are either very complex, or not very efficient.  With a "reuse" construct, I think you could directly reuse the simple and otherwise non-reusable version.

First, let's look at why the pseudo code I suggested is not reusable in D.  This is simple.  Inheriting from Node, Edge, and Graph is the only way to reuse this code, since it wasn't defined as an interface or template.  If Netlist were to inherit from Graph, it would inherit a linked list of nodes, but what I asked for was two doubly linked lists, one of Instances, and one of Nets.  Similar problems occur with the other classes.  We also run into the problem of having to do lots casts to derived classes if we ever want to traverse the derived objects.

Let's try that again, but this time with templates.  Graph, Node, and Edge could all be rewritten to be template classes, and the container classes could be provided by the user.  But all that does is let us define various kinds of directed graphs.  It doesn't allow me to directly embed graph functionality in my netlist.  The two doubly linked lists in Netlist are not easily going to get defined by using the Graph template class.  You'd have to do something goofy like inherit from two versons of the Graph template at the same time.  It's all down-hill from there.

Ken Carpenter suggested making Graph, Node, and Edge template classes that inherit from template parameters.  This may actually lead to the winning implementation, but I think it's going to be pretty convoluted.  Frankly, if a programmer didn't shoot himself in the foot with such code, I'd buy a gun and shoot it for him.

How about using interfaces?  This actually works, but has some issues. Now we have to define a large interface that mimics every method and attribute used in the pseudo code.  It could be dozens of methods. Every one of them has to be defined by the user.  Worse, every time I add a graph related atribute or method to the Graph interface, every user has to upgrade his code, even if he doesn't need the new graph functionallity.  There are all kinds of attributes that would eventually be needed.  For example, we have a level attribute in our simple code for the contest.  There are other problems.  The foreach(Graph, node) functionality would have to be done with some sort of virtual iterator.  When writing the foreach loop in the Graph code, you can't just instantiate the iterator on the stack as you would in C++, because you don't know it's size.  That's determined by the user's choice of contaner class, which is hidden behind the interface.  You have to use something like Java Enumeration interfaces, which leads to pretty slow code.  The darned iterators are going to wind up on the heap!  Finally, there's the potential overhead of lots of virtual function calls since everything is done through an interface.  However, if the D compiler were to do global optimizations across modules, it might succeed in binding most of them statically.

It seems to me that writing a good reusable graph module in D is hard. I think it should make for an interesting contest, if I can get any competitors interested.  If someone could show me how to do a really good one that D specifically enables, I think I'd ask my company to start using D, since we currently have to rewrite basic code like this every day in C.

I haven't used the Sather "reuse" constructs before, so I don't know what hidden pitfalls are there.  However, it seems to mimic what I do today in C: copy the functions and class attributes from one module and paste them into my new module, and then rename things to make it all work.  It's very similar to the "framwork" stuff Ken Carpenter was talking about, which also seems like it would do the trick.

I sure hope I'm wrong about all this, and someone just shows me how to reuse code...  It would definately be worth the 30 bucks for pizza.

Bill

Bill Cox <bill@viasic.com> wrote in news:3E57E58F.4080108@viasic.com:

> Hi, Walter.
> 
> Walter wrote:
>> "Bill Cox" <bill@viasic.com> wrote in message news:3E57BCC7.6050301@viasic.com...
>> 
>>>If it could just support directed graphs well, I'd be happy.
>> 
>> 
>> Could you elaborate, please? (I apologize if you have before.)
> 
> Sure.  It's somewhat complicated.  I wish I could sumarize the problems in one or two lines, but I can't.
> 
> Just to jump ahead, I think a good solution can be found in Sather. Their "reuse" construct looks easy to implement (of course, templates looked easy too...).  Ken Carpenter's suggested "framwork" idea seems to also work well.

Actually it was me but to give credit where credit is due I got the the framework idea from an article by Tim Sweeney.

http://www.gamespy.com/legacy/articles/devweek_b.shtm

A notable quote is...
<quote>
While object-oriented languages handled pure objects well, they modeled
complex relationships between objects poorly. Frameworks and collections
turn out not to be truly modular or extensible because the languages
can't represent families of objects. </quote>