Live data from Hacker News

How to Design Programs (2014)

htdp.org

121–130 of 141 posts

Re: How to Design Programs (2014)

#121
post #115

Earlier quoted context omitted.

Yes, I agree, that is a caricature. More seriously, I think leaning on this language-specific feature in a book that's supposedly teaching "general programming 101," or whatever, is in bad taste. As it says: > One reason that the distinction between process and procedure may be confusing is that most implementations of common languages (including Ada, Pascal, and C) are designed in such a way that the interpretation…

SICP point is that you can implement a for loop with tail recursion easily but not viceversa.

I don't think that's the point, as conversion in both directions is near trivial. It is a straightforward mechanical process, it may not always be easy or simple but it's more likely tedious than hard or complex.

More importantly, in the listed languages (excepting a handful of compiler optimization options) the semantics of procedure calls are different than Scheme's semantics for procedure calls. So if you, in C, convert a for loop into a tail recursive procedure you have changed the behavior of the program, not just its appearance (and same in reverse). In Scheme or another language with tail call elimination, then this conversion ought not actually change the behavior of your program (done in either direction). This also has the effect of removing the loop constructs as a necessity of the language. You can describe an efficient iterative process in Scheme with tail recursion, but you cannot describe it (in a general sense, same caveat for some optimization options) with tail recursion in the listed procedural languages and must use a special syntax element (their loop constructs) to achieve the same program semantics.

Re: How to Design Programs (2014)

#122
post #115

Earlier quoted context omitted.

SICP point is that you can implement a for loop with tail recursion easily but not viceversa.

I don't think that's the point, as conversion in both directions is near trivial. It is a straightforward mechanical process, it may not always be easy or simple but it's more likely tedious than hard or complex. More importantly, in the listed languages (excepting a handful of compiler optimization options) the semantics of procedure calls are different than Scheme's semantics for procedure calls. So if you, in C, c…

Transforming a program with tail calls to one without require to move all mutually recursive tail function to a common trampoline or something similar. Rewriting a single or a few tail functions into a loop/switch is easy, but it "impossible" to do for library API without global transformations.

(I could be wrong, I am not an expert in this, my basis are that an open set of function with a call in tail position can be used to describe arbitrary state machines (with the state being the arguments of the tail call and the rules the code of each function) that is open to new functions being added from anywhere. If you want to transform this in an iterative state machine all your functions need to be "registered" and "called" by the state machine.)

Re: How to Design Programs (2014)

#123
post #54

Earlier quoted context omitted.

I think these are the 2 courses OP is talking about: https://www.edx.org/course/how-to-code-simple-data https://www.edx.org/course/how-to-code-complex-data

I believe op is talking about the entire sequence where after those 2 you learn java and typescript. I also took the entire sequence the java one was really good at explaining aliasing problems, how to figure out an existing codebase by yourself, and all taught by UBC profs. The two intro courses that use htdp are not nearly as rigorous as the book, you never get to see anything difficult enough to warrant using the…

The two courses of your parent comment are 2 out of 6 courses of this program [1]. It mentions Java and Typescript. It seems like all 6 can be taken for free if you click the individual links. Is this what you took?

[1] https://www.edx.org/micromasters/ubcx-software-development/

That indeed is the course the top comment is talking about.

The instructor Gregor Kiczales has a youtube channel named 'Systematic Program Design' [2]. His 5 minutes intro video [3] is really good IMO - one can send it to ones relatives or friends who ask you what the heck you are doing in your job.

[2] https://www.youtube.com/channel/UC7dEjIUwSxSNcW4PqNRQW8w

[3] https://www.youtube.com/watch?v=dJbpHukiQ7I

Re: How to Design Programs (2014)

#124
post #54

Earlier quoted context omitted.

I think these are the 2 courses OP is talking about: https://www.edx.org/course/how-to-code-simple-data https://www.edx.org/course/how-to-code-complex-data

Are the 2 courses sufficient on their own? or do I need to read the book as well?

Those 2 are part of 6 courses. See my comment above:

https://news.ycombinator.com/item?id=26515981

Re: How to Design Programs (2014)

#126
post #64

Earlier quoted context omitted.

There was this question about books on software engineering. https://news.ycombinator.com/item?id=26488944 I saw it was at least a couple of years since HtDP was discussed on HN. I appreciate its flat footed approach and systematic method. To me, these are hallmarks of professional engineering practice. There's no attempt to make the problems more interesting by adding complexity or affectations. YMMV.

Can you explain "flat footed approach"?

You know how Ali floated like a butterfly?

Not that.

You know how Tyson early in his career just walked straight forward and punched?

Like that.

Re: How to Design Programs (2014)

#127

Kathi Fisler gave a great talk at the latest racketcon about research done based on the HtDP curriculum. I thought it was interesting to see the sorts of problems that fit well with the basic structure templates given in htdp and the kinds of problems that were a bad fit. https://www.youtube.com/watch?v=MnrRUdbOW1M

Thank you for the link.

Re: How to Design Programs (2014)

#128

Earlier quoted context omitted.

I believe op is talking about the entire sequence where after those 2 you learn java and typescript. I also took the entire sequence the java one was really good at explaining aliasing problems, how to figure out an existing codebase by yourself, and all taught by UBC profs. The two intro courses that use htdp are not nearly as rigorous as the book, you never get to see anything difficult enough to warrant using the…

The two courses of your parent comment are 2 out of 6 courses of this program [1]. It mentions Java and Typescript. It seems like all 6 can be taken for free if you click the individual links. Is this what you took? [1] https://www.edx.org/micromasters/ubcx-software-development/ That indeed is the course the top comment is talking about. The instructor Gregor Kiczales has a youtube channel named 'Systematic Program D…

Yep well 5.5 courses I took as the last one is a big project and I already was doing one so skipped it. The java courses are good in teaching how to properly make an abstract object iirc, was many years ago I took them. Probably the best intro to programming sequence you can find though maybe not enough assignments

Re: How to Design Programs (2014)

#129

Earlier quoted context omitted.

Hello, this might be a bit personal but I am a fellow lawyer having practiced law for 3 years. How did you take the plunge after six years of doing law? Were there any external circumstances? How did you get over worrying about finding a job, losing status etc.? I dream of getting into legal tech and combine my passion for computers with my hard earned law knowledge at some point. But it's just a dream at this stage…

If you can get a law degree, you can definitely learn comp sci. Lots of people with no experience think it's magic, but it really isn't that hard to learn. This book and the teachings that use it were a great way to get started when I took the course. It built a solid foundation for everything else to come when I took the course at neu.

Actually I always had an interest for computers and I already have a lot of CS knowledge (minus maths). That's why I hang around on HN :).

I was always obsessed with computers since childhhood, I somehow got into law school and faked my way from there.

My problem is taking the plunge to do something else other than law. I try to live day by day and focus on other things besides computers.

Re: How to Design Programs (2014)

#130
post #64

Earlier quoted context omitted.

Can you explain "flat footed approach"?

You know how Ali floated like a butterfly? Not that. You know how Tyson early in his career just walked straight forward and punched? Like that.

I knew the former but not the latter. Got it now.
Post reply on HN