Re: [tlug] Making programming easier... or something like that

[Attila Kinali <attila@example.com>]

Moin,

Thanks for this long reply!

On Fri, 19 Oct 2012 16:06:01 +0900
Curt Sampson <cjs@example.com> wrote:

> The heart of programming is, when it comes down to it, simply
> manipulation of symbols according to strict rules of a logic that
> you (or someone else) has made up. In other words, mathematics. This
> discipline is in turn used (or, more frequently, misused, or not
> infrequently hardly used at all) when practicing software engineering,
> which is what most people in "the industry" do.

I have to disagree here. Programming, at least for me, has very little
to do with mathematics. Yes, it is about symbol manipulation. Yes, there
are strict rules. But the same applies on building a car out of Lego bricks.
You manipulate symbols (the bricks) according to strict rules (you can
only plug the ontop of each other and on right angles). Yet, you probably
agree with me, that building cars out of Lego has nothing to do with
mathematics, but on the other hand is very similar to writing software
(and also doing electronic design). Rather than comparing it to mathematics
i would express it as a form of problem solving. Given a big, intractable
problem, how do you go on to solve it? Do you tackle it all at once?
Split it up in little pieces and solve them seperately? Do you try to
integrate the pieces as soon as you solved them or rather at the end
when you have all pieces? Unfortunately, my knowledge in problem solving
is rather limited and so far i have not found a good introductory textbook
on this (i'm sure there is, there must be! psychologist have studied
this for decades). The best i've found until today is a chapter from [1].

For me the question is, how could one make the solving of this specific
problem of programming simpler, so that a broader range of people could
do it. 


> If you want to look at how people learn about programming and deal with
> it as mental work when they're being or have been taught well, chasing
> down the various uses of Racket[1], such as Bootstrap[2] and Matthias
> Felleisen's TeachScheme![3] may be of help. Racket (previously DrScheme)
> is a langauge that seems particularly associated with serious research
> into the pedagogy of computing science.

I looked at this, but somehow it didnt seem very apealing. One thing might
me my slight dislike of Scheme's representation (honestly, how can a
language where everything is build from paranthesis be used for teaching
average students?). There is hardly any syntactic structure that helps
the human mind to get an anchor what it is dealing with. It also needs quite
a bit of abilitiy in abstraction, which is something not everyone is capable
of (why?). On the other hand, Scheme is very very simple. It's the PIC16C84
of the programming languages (an 8bit processor that had only 30 opcodes but
was able to run a webserver).

I will definitly have a look at this.


 
> 
> If you're interested in what really gets practiced, The Daily WTF[4]
> is as good a source as any of examples of how many (probably most)
> developers don't really have a mental process, or possibly a brain at
> all.

I know it and often read it for recration at work :-)

> That's not particularly helpful for improving one's skills, of course.
> For that sort of thing, whether you're working seriously on making
> software or just playing around, I can recommend nothing more highly
> than learning functional programming. Functional programming researchers
> and language designers are, in general, far more concerned than anybody
> else with the logical coherence and power of their languages, and that
> comes out in making the languages both easier to learn and use and
> more powerful than more popular languages,

May i ask what your educational background is?
It sounds to me as you have a university degree in computer science
with a heavy foundation in mathematics, or you swichted from a mathematics
major to computer science.

Logical coherence and and power of expression are two parts of making a
programming language (probably the two most important), but in my experience
they mean very little to Joe Average. Even in the academics, where people
tend to handle abstractions well, i always get the feeling that the way
of looking at the world is very different if you are a liberal arts major.


> even if you exclude the
> messes such as Perl and Ruby that were thrown together on an ad-hoc
> basis. (It should be noted that many people damaged by extensive
> exposure to ill-designed languages will vehemently dispute the "easier
> to learn" portion of this statement, but these are people so far gone
> that they don't even realise that the statement "f(); g();" includes a
> flow-of-control structure, much less have any ability to recognise what
> it is.)

Hmm.. I'm surprised at that. Perl was my third or forth language i learned,
when i was still new to computers (had one for a year or two).
I has pretty quickly become my tool language of choice for virtually eveything.
I've written a lot of stuff, from simple data munging stuff (read some
text files, create some data out of thin air and produce some meaningless
statistics form it) over a parser for a context free language (a subset
of VHDL) purely in regular expression to a whole circuit optimization
system based on an evolutionary algorithm.

I find perl pretty easy to learn, safe for the basic notation (which
i think is a horrible mess of special characters). What makes
it for me very interesting is that it allows to use various forms
of statetments to express the same thing. And you can chose the one
that seems to fit the best in the current context. Just like i would
do in a natural language.
 
> As to specific references, I can only throw out a few random ones.
> 
> One of the classic texts in the area is _Structure and Interpretation of
> Computer Programs_[5] (usually referred to as just "SICP"). 

I have this, though i never finished reading it.

> However, one
> thing you miss out on with that is the interesting and extremely helpful
> stuff a good type system (such as that of ML and related langauges) can
> give you. For that, Haskell may be the best route to go, using something
> such as Graham Hutton's _Programming in Haskell_[6] or Paul Hudak's
> _The Haskell School of Expression_[7] (though I would certainly do the
> former before the latter). 

Long long ago, i got recomended to learn haskell (actually here on
this mailinglist). But somehow haskell has a quality like python that
makes it difficult to enter my brain. I cannot say what it is.
Every time i try to read "Real World Haskell" something keeps telling
me that what i read is not the right thing. Interestingly, much after
my first and second try to learn haskell, i bought the book "Programming
Erlang" out of a whim, read and finished it within a month. There are
a lot of interesting concepts in erlang, but i know that haskell goes way
beyond that. Having read about earling made understanding haskell easier.
But still there is something that keeps me away from it.



> On 2012-10-18 19:01 -0400 (Thu), jep200404@example.com wrote:
> 
> >    http://www.nand2tetris.org/
> 
> This is the first time I've come across this, but it looks absolutely
> brilliant. It addresses at least part of a massive problem that I and my
> other not-so-young friends have noted and discussed amongst ourselves
> from time to time.
> 
> That said, I don't think it directly addresses your problem, since it's
> not so much about how one thinks about programming per se, but simply
> understanding what's really going on under the hood. That's somewhat
> esoteric knowledge you will probably need from time to time if you're a
> professional programmer, but is only used occasionally, as opposed to
> something like knowledge of algorithms, and many people can get by just
> fine without knowing it at all.

I have to disagree here. I know very little about algorithms, very little
about design patterns and stuff like this (i only had very basic formal
teaching in programming). But i still see myself as a half way decent 
programmer. Yes, this might be pure hybris, but i'm quite sure that you
don't need to know much about algorithms to write good code. This of course
leads to the question, what does one need to know to write good code?


> I've ordered a copy of the book, though, and if anybody happens to be
> interested in putting together a group to basically do the course, I'd
> be in for that. I've been thinking for some time I wanted to start
> spending some time at Tokyo Hackerspace building up my own CPU from
> TTL 7400 NAND gates, but I reckon I might be able to live without the
> frustration of debugging timing issues and whatnot in actual physical
> components.

I have somewhere in my archives an article (or series, dont remember)
on building a 4bit CPU out of TTL gates, but it is in german. If you
want i can try to dig it out.


				Attila Kinali 


[1] Cognitive Psychology and its Implications, by J.R. Anderson


-- 
There is no secret ingredient
         -- Po, Kung Fu Panda