Teaching Programming
in [Python]
|
From: Stefan Behnel on 4 May 2010 11:52 Ed Keith, 04.05.2010 17:43: > The PITA is having to keep track of the indentation of each embedded > chunk and summing it for each level of indentation. This requires a fair > amount of bookkeeping that would not otherwise be necessary. > > The original prototype simply replaced each embedded chunk with the text > from the chunk definition, all indenting information was lost. It worked > for most languages, but not Python. > > In testing the program I used two languages, Python and J. Well, then both of the language generators have benefited from your effort because the generated complete code is properly indented and therefore much more readable during debugging. I'd say it was worth it. Stefan
From: superpollo on 4 May 2010 11:55 superpollo ha scritto: > Stefan Behnel ha scritto: >> superpollo, 04.05.2010 14:46: >>> my template system wants >>> the input to generate the code to stay on a single line ( don't ask >>> :-( ) >> >> I hope you don't mind if I still ask. What are you generating and for >> what templating system? > > ok, since you asked for it, prepare yourself for a bit of a horror story > ;-) > > i will answer in my next post ok here it is. i am not a programmer or it-guy in the first place; my job is as a high school teacher in a field only remotely connected with computers (math and physics). since i have some kind of computer literacy (as opposed to most of my colleagues), some years ago i was kindly asked to try and solve a "simple" particular problem, that is to write a program that generates math exercises (q+a) from an example taken from the textbook. for instance, this: %%TITLE:Sample worksheet %% %%SCHEMA:\lim_{x \to <A>} %%SCHEMA:\frac %%SCHEMA:{x^3-<A-B>x^2-<AB>x} %%SCHEMA:{x^3-<A>x^2+<C>x-<AC>}\\ %% %%ANS:FRAC %%ANSNUM:<A^2+AB> %%ANSDEN:<A^2+C> %% %%AMIN:1 %%AINC:1 %%AMAX:2 %%BMIN:3 %%BINC:1 %%BMAX:4 %%CMIN:2 %%CINC:1 %%CMAX:3 should generate this latex source document: \documentclass[a4paper,10pt,twocolumn,fleqn]{article} \title{Sample worksheet} \pagestyle{empty} \usepackage[italian]{babel} \usepackage{amsmath} \usepackage{amssymb} \usepackage{cancel} \usepackage{mathrsfs} \usepackage[dvips]{graphicx} \usepackage{eurosym} \usepackage{pstricks} \usepackage{pst-eucl} \usepackage{pst-poly} \usepackage{pst-plot} \frenchspacing \begin{document} \section*{\center{\framebox{Sample worksheet}}} \noindent \begin{enumerate} \item \begin{multline*} \lim_{x \to 1} \frac {x^3+3x^2-4x} {x^3-x^2+2x-2}\\ \end{multline*} \item \begin{multline*} \lim_{x \to 2} \frac {x^3+x^2-6x} {x^3-2x^2+2x-4}\\ \end{multline*} \item \begin{multline*} \lim_{x \to 2} \frac {x^3+2x^2-8x} {x^3-2x^2+2x-4}\\ \end{multline*} \item \begin{multline*} \lim_{x \to 1} \frac {x^3+2x^2-3x} {x^3-x^2+2x-2}\\ \end{multline*} \item \begin{multline*} \lim_{x \to 1} \frac {x^3+2x^2-3x} {x^3-x^2+3x-3}\\ \end{multline*} \item \begin{multline*} \lim_{x \to 1} \frac {x^3+3x^2-4x} {x^3-x^2+3x-3}\\ \end{multline*} \item \begin{multline*} \lim_{x \to 2} \frac {x^3+x^2-6x} {x^3-2x^2+3x-6}\\ \end{multline*} \item \begin{multline*} \lim_{x \to 2} \frac {x^3+2x^2-8x} {x^3-2x^2+3x-6}\\ \end{multline*} \end{enumerate} \subsection*{\center{Answers}} \begin{enumerate} \item \begin{displaymath} \frac{5}{3} \end{displaymath} \item \begin{displaymath} \frac{5}{3} \end{displaymath} \item \begin{displaymath} 2 \end{displaymath} \item \begin{displaymath} \frac{4}{3} \end{displaymath} \item \begin{displaymath} 1 \end{displaymath} \item \begin{displaymath} \frac{5}{4} \end{displaymath} \item \begin{displaymath} \frac{10}{7} \end{displaymath} \item \begin{displaymath} \frac{12}{7} \end{displaymath} \end{enumerate} \end{document} which in turn can be used to generate the following pdf file: http://www.datafilehost.com/download-cc88a19e.html fine huh? now, for the horror part. when i began putting down some code i thought that maybe it would take a couple of evenings to put up a working prototype, and i was w-r-o-n-g: 1) as i said i am not a professional 2) i decided to use bash shell as a core language for the parser/generator ( *sigh* ) 3) feautiritis soon crept in if some of you knows a bit about math and especially algebra, you will understand that some of the biggest problems in generating standard math notation in to cope with the various layers of traditions and innuendos: for example i could generate the string "2x" which is fine; but what about "1x" or "-1x" or "0x"? and what about plus signs at the start of an expression (normally omitted)? when does a subexpression start? etc .... there are plenty of icompatible rules and as much as exceptions ... as you can see i had many problems to solve and i am not trained to cope with such issues from a programmatic standpoint. another thing is that for some features i intended to include i found convenient to use python (since it's the language i feel i am more at ease with), so i had to cope with template lines like this: %%SCHEMA:<PYCODE1:import math ; print int(math.sqrt($A**2-2.*$A*$B))> or even worse: %%ANSFRCEMBPYC:<PYCODE3:print "\\\\mathrm{p.~st.~}" , $C , "~\\\\longmapsto~" , $C**2*(3*$A+3*$B+$C) , "~\\\\mathrm{(max~loc.)}">\\ to make a long story short: the whole program is now 4775 lines of bash code, written by an unqualified amateur under time pressure; sometimes i have to hand-modify it to get certain outputs as i expect them to be; this in turn breaks other subsystems. i am ashamed to post the code, and it is a true design nightmare. also it is offtopic (being bash). *but* it was and it is a wonderful experience to learn to program, to acknowledge weaknesses end strongnesses of various approaches, to better understand the structure of math notation, problem solving end teaching techniques. it is still work in progress though, and i hope i will never see the day i have to refurbish it. i hope -- instead -- that the next time i try to attack the task i will have a better knowledge thanks to errors committed, to avoid many of the pitfalls i stumbled upon. for now, it works. *whew* i hope i was not boring, and i sincerely hope that some of you could see the depth of the problem i tried to solve (perhaps usuccesfully), end give me some professional advice as what to do for the next incarnation of my awful program. any concrete suggestion will be *very* appreciated. thank to all bye
From: Terry Reedy on 4 May 2010 12:06 On 5/3/2010 7:46 PM, cjw wrote: > Nobody likes indentation at first, Speak for yourself, please. For two decades before I met Python, I indented code nicely whenever it was allowed. That option was one of the great advancements of Fortran77 over FortranIV. Coming from C, I was immediately glad to be done with those darn braces. tjr
From: D'Arcy J.M. Cain on 4 May 2010 12:07 On Tue, 4 May 2010 17:00:11 +0200 Andre Engels <andreengels(a)gmail.com> wrote: > Although I have little or no experience with this, I still dare to say > that I don't agree. The difference is that in C you do not _need_ to > know where in the braces-defined hierarchy you are. You just embed or > change a piece of code at the right location. In Python however you > _do_ need to know how far your code is to be indented. Well, I'm afraid your lack of experience shows. Experienced C coders will tell you that one of the most annoying things is counting braces to make sure that you have the right number in the right places. In fact, they add indentation so that they can use the visual layout to check the brace layout. Braces are the added step. -- D'Arcy J.M. Cain <darcy(a)druid.net> | Democracy is three wolves http://www.druid.net/darcy/ | and a sheep voting on +1 416 425 1212 (DoD#0082) (eNTP) | what's for dinner.
From: Chris Rebert on 4 May 2010 12:11
On Tue, May 4, 2010 at 8:49 AM, D'Arcy J.M. Cain <darcy(a)druid.net> wrote: > On Wed, 5 May 2010 00:35:18 +1000 > James Mills <prologic(a)shortcircuit.net.au> wrote: >> In my experience of non-indentation sensitive languages >> such as C-class (curly braces) it's just as hard to keep track >> of opening and closing braces. > > Harder. Â That was the big "Aha!" for me with Python. Â My first > programming language was Fortran in 1969 so when I saw indentation as > syntax I also recoiled in horror for about 0.5 seconds. The amount of mental scaring that Fortran has caused regarding indentation is astounding. Maybe the PSF should run re-education camps for Fortran programmers... :P > However, I > immediately realized that from now on I could be sure that if it looked > right then it was right. > > Â Â for (x = 0; x++; x < 10); > Â Â Â Â printf("Current number is %d\n", x); > > Or... > > Â Â for (x = 0; x++; x < 10); > Â Â { > Â Â Â Â printf("Current number is %d\n", x); > Â Â } > > Oops. Â Looks right but isn't. Â Try to make that mistake in Python. Technically, that pitfall /could/ be eliminated if curly-braces languages simply always required the curly-braces for bodies and stopped special-casing the null body case, in which case both your examples would be syntax errors. Removing the special-casing of single-line bodies too would remove a further class of errors. However, I've yet to encounter a language that takes such an approach. Quite a pity. Cheers, Chris -- I've thought a lot about this. http://blog.rebertia.com/2010/01/24/of-braces-and-semicolons/ |