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.
Cheers,
Alan
>________________________________
> 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.
>
>Loup.
>
>
>
>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@vpri.org
>http://vpri.org/mailman/listinfo/fonc
>
>
>
_______________________________________________
fonc mailing list
fonc@vpri.org
http://vpri.org/mailman/listinfo/fonc
