A tool that suggests optimized logic for a piece of code/module/function
in [General Programming]
|
Prev: Best way to learn ... need some help
Next: A tool that suggests optimized logic for a piece of code/module/function
From: Nick Keighley on 15 Jan 2010 04:20 On 13 Jan, 16:43, dj3va...(a)csclub.uwaterloo.ca.invalid wrote: > In article <4b4def88$0$22938$e4fe5...(a)news.xs4all.nl>, > [Jongware] <so...(a)no.spam.net> wrote: > >Walter Banks wrote: > >> Defining goals at a much higher level than C opens the possibilities > >> for automating algorithmic choices at the function level. > > >Aha -- wouldn't the logical end point be a programming language where > >you type "word processor", save it as source, compile, and have a word > >processor? > > Why bother to compile it? Just have it interpret on-the-fly. > That way you could even run it in interactive mode, and it's > sufficiently high-level that even non-programmers could usefully use > it. > > Unix people call this a "shell". I'm guessing you're trying to be funny/ironic. But in case you aren't, Unix has dozens of stranglely incompatible Command Line Interfaces that Unix people call "shells". None of them are word processors. -- Campaign Against Unix Bigotry
From: dj3vande on 15 Jan 2010 11:43 In article <5de738e1-b64c-470c-a097-4020a2397cf0(a)j5g2000yqm.googlegroups.com>, Nick Keighley <nick_keighley_nospam(a)hotmail.com> wrote: >On 13 Jan, 16:43, dj3va...(a)csclub.uwaterloo.ca.invalid wrote: >> In article <4b4def88$0$22938$e4fe5...(a)news.xs4all.nl>, >> [Jongware] <so...(a)no.spam.net> wrote: >> >Aha -- wouldn't the logical end point be a programming language where >> >you type "word processor", save it as source, compile, and have a word >> >processor? >> >> Why bother to compile it? Just have it interpret on-the-fly. >> That way you could even run it in interactive mode, and it's >> sufficiently high-level that even non-programmers could usefully use >> it. >> >> Unix people call this a "shell". > >I'm guessing you're trying to be funny/ironic. But in case you aren't, >Unix has dozens of stranglely incompatible Command Line Interfaces >that Unix people call "shells". None of them are word processors. Right. But all of them have the property that I can get a word processor by typing the name of a word processor that's installed on the system. My point was that the "primitives" provided by a shell (the programs installed on the system) give a pretty good approximation to [Jongware]'s suggestion of "type 'word processor' and get a word processor". dave -- Dave Vandervies dj3vande at eskimo dot com I only have to be quoted in a sig 5000 more times before I catch up with Richard Heathfield. --Nick Keighley in comp.lang.c
From: -jg on 15 Jan 2010 15:19 On Jan 16, 8:28 am, Jon Kirwan <j...(a)infinitefactors.org> wrote: > > Walter, they don't even do _that_ task well enough. > > Since this topic appears to suggest the idea of having a > compiler do something I consider almost crazy-minded at this > point in time..... Yes, the best reply to the original overall question, is a Pencil !!. However, there are some details, aside from the 'find a new algorithm'(?!) request that tools could be expected to offer. Taking this: [" It will be even more helpful if that tool also provides the cycle counts, cache usage, cache misses and lines of code also. "] Lines of code should already be there, in a listing output, and also in a debugger. Likewise, on a chip/ICE with HW breakpoints and sys timers, you could expect a good system to be able to give time-of-flight on running code, if you really need that. The OP sees to expect all this in an EDITOR, which is miss-directed, but it is possible in a full tool chain. -jg
From: Andy on 15 Jan 2010 17:32 On Jan 14, 9:57 am, David Brown <da...(a)westcontrol.removethisbit.com> wrote: > I don't agree here (perhaps as a compiler writer you are thinking of > "implementation" in terms of generated target code - then I'd agree). > Kids use Logo to learn about programming concepts, and how to get the > computer to do what you want it to do. They learn to write things like: > > TO SQUARE :size > REPEAT 4 [ FD :size RT 90 ] > END > > This is entirely about writing an imperative implementation of how you > want the system to draw a square. > > Compare this to a sample program in a real functional programming > language, Haskell: > > factorial 0 = 1 > factorial n = n * factorial(n - 1) > > Here you tell the system what you want - you give a mathematical > description of the results. You don't care how it gets them - maybe it > uses recursion, maybe it uses iteration, maybe it builds up a cache of > calculated values as it goes along. > The LOGO interpreter/compiler is just as free to implement alternative solutions to drawing a square as the Haskell compiler is of altering the described recursive implementation of a factorial. Whether the compiler is smart enough to do so has nothing to do with the language being "procedural" or "functional". Andy
From: Jasen Betts on 16 Jan 2010 03:28
On 2010-01-15, Nick Keighley <nick_keighley_nospam(a)hotmail.com> wrote: > I'm guessing you're trying to be funny/ironic. But in case you aren't, > Unix has dozens of stranglely incompatible Command Line Interfaces > that Unix people call "shells". None of them are word processors. emacs comes close. :) --- news://freenews.netfront.net/ - complaints: news(a)netfront.net --- |