I think it is domain dependent -- for example, it is very helpful to have a 
debugger of some kind for a parser, but less so for a projection language like 
Nile. On the other hand, debuggers for making both of these systems are very 
helpful. Etoys doesn't have a debugger because the important state is mostly 
visible in the form of graphical objects. OTOH, having a capturing tracer (a la 
EXDAMS) could be nice for both reviewing and understanding complex interactions 
and also dealing with "unrepeatable events"

The topic of going from an idea for a useful POL to an actually mission usable 
POL is prime thesis territory.



> From: Loup Vaillant <l...@loup-vaillant.fr>
>To: fonc@vpri.org 
>Sent: Wednesday, February 29, 2012 5:43 AM
>Subject: Re: [fonc] Error trying to compile COLA
>Yes, I'm aware of that limitation.  I have the feeling however that
>IDEs and debuggers are overrated.  Sure, when dealing with a complex
>program in a complex language (say, tens of thousands of lines in C++),
>then sure, IDEs and debuggers are a must.  But I'm not sure their
>absence outweigh the simplicity potentially achieved with POLs. (I
>mean, I really don't know.  It could even be domain-dependent.)
>I agree however that having both (POLs + tools) would be much better,
>and is definitely worth pursuing.  I'll think about it.
>Alan Kay wrote:
>> With regard to your last point -- making POLs -- I don't think we are
>> there yet. It is most definitely a lot easier to make really powerful
>> POLs fairly quickly than it used to be, but we still don't have a nice
>> methodology and tools to automatically supply the IDE, debuggers, etc.
>> that need to be there for industrial-strength use.
>> Cheers,
>> Alan
>>     *From:* Loup Vaillant <l...@loup-vaillant.fr>
>>     *To:* fonc@vpri.org
>>     *Sent:* Wednesday, February 29, 2012 1:27 AM
>>     *Subject:* Re: [fonc] Error trying to compile COLA
>>     Alan Kay wrote:
>>      > Hi Loup
>>      >
>>      > Very good question -- and tell your Boss he should support you!
>>     Cool, thank you for your support.
>>      > […] One general argument is
>>      > that "non-machine-code" languages are POLs of a weak sort, but
>>     are more
>>      > effective than writing machine code for most problems. (This was
>>     quite
>>      > controversial 50 years ago -- and lots of bosses forbade using any
>>      > higher level language.)
>>     I didn't thought about this historical perspective. I'll keep that in
>>     mind, thanks.
>>      > Companies (and programmers within) are rarely rewarded for saving
>>     costs
>>      > over the real lifetime of a piece of software […]
>>     I think my company is. We make custom software, and most of the time
>>     also get to maintain it. Of course, we charge for both. So, when we
>>     manage to keep the maintenance cheap (less bugs, simpler code…), we win.
>>     However, we barely acknowledge it: much code I see is a technical debt
>>     waiting to be paid, because the original implementer wasn't given the
>>     time to do even a simple cleanup.
>>      > An argument that resonates with some bosses is the "debuggable
>>      > requirements/specifications -> ship the prototype and improve it"
>>     whose
>>      > benefits show up early on.
>>     But of course. I should have thought about it, thanks.
>>      > […] one of the most important POLs to be worked on are
>>      > the ones that are for making POLs quickly.
>>     This why I am totally thrilled by Ometa and Maru. I use them to point
>>     out that programming languages can be much cheaper to implement than
>>     most think they are. It is difficult however to get past the idea that
>>     implementing a language (even a small, specialized one) is by default a
>>     huge undertaking.
>>     Cheers,
>>     Loup.
>>     _______________________________________________
>>     fonc mailing list
>>    fonc@vpri.org <mailto:fonc@vpri.org>
>>     http://vpri.org/mailman/listinfo/fonc
>> _______________________________________________
>> fonc mailing list
>> fonc@vpri.org
>> http://vpri.org/mailman/listinfo/fonc
>fonc mailing list
fonc mailing list

Reply via email to