HN user
https://www.functionalgeekery.com/episode-37-eric-smith/
You should try skimming to the end, where there are two pages of references. Not to mention the fact that Cardelli is a prominent figure in the study of programming languages.
And I think you'll find that Gilad Bracha is a more informed critic of reliance on static type checking.
That conclusion made me laugh. In the early to mid 90s, I was working on 3D interactive software. The video drivers and chips had advanced so much in one year that all of the lovingly handcrafted assembly I had written over that time was useless. I thought to myself, "what an unstable industry to build a career in". I also made comparisons to accounting, medicine, and law, thinking perhaps I had made a wrong choice.
Turns out that adapting to rapid change is a critical aspect to this career choice. It is also a problem for businesses, which you start to grapple with as you move up the chain of command. The mistake is wistfully hoping that things would slow down enough for you rest on your hard-won knowledge, as in other fields. There is no competitive advantage in aging technology.
Although the OP seems to be asking for "engineering" not "programming" books, I'm going to second this. Benjamin Pierce's "Types and Programming Languages" will help you get down to what programming is really about. If you are not familiar with lambda calculus and its notation, it may be rough going at first. But lambda calculus is VERY simple, and Pierce takes you through it. The book progresses methodically to the concepts found in most common programming languages.
This is one of the few truly language agnostic books on programming. SICP is close, but it is limited in relevance at times due to the limitations of a particular language (Scheme).
As a long-time advocate of functional programming, I was once asked after a talk what is the "best" FP language to learn. Since I'm known as a Haskell/Scala/ML person, I surprised much of the audience by answering that I thought F# was the best entry point. What I did not say, however, was that I think that Windows is a challenging environment for anyone who is used to Linux/Mac -- and this includes the "open source" world in general. I think that Microsoft is a leader in language design, but their platform relevance was slipping for many years. I believe it may be on the upswing (with Xamarin etc). I would encourage you to stick with F# as you will be further along in not only understanding FP, but other modern programming languages, including ones that haven't been invented yet.
He keeps warning not to write thousands of lines before talking to customers (as you often hear from biased survivors). But it sounds like they didn't find PM fit by talking to customers. Rather they identified -- perhaps out of desperation and exhaustion -- 0.1% of the code they had written that they thought might be useful and threw it out there. The takeaway really seems to be write as much code as you can, if one-tenth of one percent is going to be the golden nugget. Also, I suspect that they were able to use that other code and the processes around it to capitalize on their good fortune.
Speaking from personal experience ... At the time of signing you can see the upside (the offer), but you can't know the downside, which can be quite significant. It's a poor trade-off. Avoid these unless you get some kind of severance for the period of the agreement. Mere employment as "consideration" is a bad deal.
Kay mentions The Dream Machine, which in my opinion is one of the better books on some of the early work in computing systems. Heartily recommend it.
"Je n’avais pas besoin de cette hypothèse-là." -- Pierre-Simon Laplace
Here is an essay I wrote following my son's first technical talk, weeks after his seventh birthday. It references what I believe works in teaching children to program.
https://medium.com/@eric2.71828/your-journey-is-important-sh...
Not at all high-brow, but I revisit the in-the-trenches case study of "Scaling Pinterest" on Infoq from time to time because I find their fighting through the pain inspirational for my own scaling troubles.
Absolutely! Every time programming education comes up, someone brings up Scratch. It's advocacy is -- possibly detrimentally -- overused. It may be appropriate in some cases, but it is not a universal tool for introducing people to programming. There is certainly something inauthentic about using blocks. They may not be appropriate for people with motor-control issues. And the reliance on imperative constructs (assignment-based statements) as being essential for understanding computation is arguably wrong and possibly hurtful.
I only have a sample of 1 (my six-year-old son, turning seven today), but he is perfectly capable of typing, understanding function definition and composition, data structures, and working with reactive I/O. He's not some super-genius. He's a regular kid who likes to swim, ride his bike, play Pokemon, and watch Netflix. But he can also make things by "real" programming. I'm sure other kids could as well.
I was delighted to see most of the answers here encourage you to continue from where you are in your interests. Only one comment mentioned abandoning your love and going to where everyone else is. Bad idea. You will find that if you keep pulling on the threads that interest you, worlds will continue to open up. And there is definitely work in those worlds.
Age is definitely not a factor. The speed with which you are able to learn definitely is. Good luck. I think this is awesome.
The headline and the body are posing two different questions. Regarding books that impacted my career in software. The top three are:
1) K&R C
2) Zen of Graphics Programming
3) C++ Programming Language, 2E
I wouldn't recommend any of these to a young version of myself today.
I teach my 6yo son using Pyret and Racket simultaneously. Pyret is, hands down, the best teaching language today, but hasn't been in use as long as Racket, so there aren't as many resources.
https://docs.racket-lang.org/drracket/
http://www.ccs.neu.edu/home/matthias/HtDP2e/
Someone below mentions Khan Academy. It's approach is similar and stays on the straight-and-narrow in its use of Javascript:
I would suggest that the need for Englishy variable names is due to a weakness in programming languages and possibly the programming model itself. Why should a set of legitimate values for a computation benefit from how you refer to that set? Can that variable take on undesired values? Do you rely on that name and its comprehensibility to distinguish good from bad values? I sometimes find it hard to believe we still program this way.
Sure. The original 1931 paper is 20-something pages long:
http://www.w-k-essler.de/pdfs/goedel.pdf
Here's an English translation (with a lengthy introduction)
http://jacqkrol.x10.mx/assets/articles/godel-1931.pdf
Even without trying to follow the proof proper, the sub-sections of the second part are interesting on their own, particularly Gödel numbering and primitive recursive functions. Here is another translation that covers just this part:
http://www.research.ibm.com/people/h/hirzel/papers/canon00-g...
It's true that if you know nothing about formal logic, history of metamathematics, and decidability, then it's going to be particularly hard going, but there are a lot of accessible resources for each of those topics and the paper is well structured (meaning you can concentrate on the pieces).
The encoding that Gödel used for formulas should be fascinating for anyone familiar with Turing work on decidability as well as how computers work generally. Primitive recursive functions don't handle computation generally, but seem to be a first step in understanding what it means. Anyone familiar with Alonzo Church, lambda calculus, functional programming, McCarthy's first paper on Lisp would probably be interested in this bit.
Of course, Gödel's result on formal systems shattered the idea of an axiomatic basis for mathematics, but I personally think its greater long-term impact is helping to usher in computation. It's worth recognizing both.
Although it's nice to see Gödel show up in the popular press, I didn't get what the point of this was. His Incompleteness paper is not that impenetrable. Sometimes it does pay to at least look at primary sources in addition to listening to others' efforts to summarize or dissect. I don't think the author of this article made much of an effort to understand what or who she was writing about. Sad, really, given Gödel's importance in understanding the beginnings of a science of computation (easily one of the most significant achievements in human history), where there is already too much myth-making and mischaracterizations.
Never reassign a variable with a different value.
I recently gave an intro to coding to young Girl Scouts using Pyret (http://www.pyret.org). The screencast is here:
I had to wing it because the ages turned out to be younger than I expected. I've taught my 6yo son using Racket and Pyret so I had the basic approach already. Although I shot over their heads in spots, overall the girls seemed to be really engaged, as were their parents. For my money, Pyret is THE language for an intro to programming, almost regardless of age.
Elizabeth Warren makes similar observations in presentation at UC Berkeley in 2007
http://www.uctv.tv/shows/The-Coming-Collapse-of-the-Middle-C...
"And, thanks to Konrad Zuse, computers and computer networks are what we have."
Holy smokes, what an inaccurate statement. Arguably one of the obstacles to progress in technology is due the persistence of the fundamental computer design that has been employed since "Baby" ran its first program just before lunch on June 21, 1948, including an approach to fast random memory accesses. This approach was novel, based on CRTs used in radar. Most everything else -- design-wise -- was from the Moore School Lectures of 1946. And the really inspirational part of those was from the work on the ENIAC.
The missing piece that needs to be more generally appreciated is how the early work on practical, general-purpose computers was quietly done in England while the Americans were squabbling over who was first.
Just to weigh in here, since I also taught both of my kids to read at an early age. I also taught them arithmetic early.
The biggest win is confidence about learning. This was particularly meaningful when they got into more "competitive" environments, by which I mean first grade where kids are expected to perform in front of their peers. When I tell my kids that just because they have trouble with something in school, that doesn't mean they aren't good at learning or at the subjects, they believe me because they have succeeded at both reading and math outside of that setting.
I believe kids are capable of a lot more than they are supported on. The trick, in my view, is to constantly know where that boundary is.
Both reading and math have notions of basic mechanical skills and meaning. My kids weren't great at the meaning part until they were over 6. But they both excelled at the mechanics part early. As an example, early on they learned to add by counting up. But later I was able to replace this with "tricks" (aka "math thinking"). A example is adding 9 to a number. Adding by counting is tedious and prone to mistakes. But if you've learned to add 10, then it is always one less. Similarly, since addition commutes, instead of 2 + 8, change it around to 8+2, which is easier and quicker. Both of my kids have embraced this approach to math of learning the shortcuts, which is actually where they get to experience the patterns and relationships that make math fun and interesting. When I showed them how the digits in multiples of 9 always add to 9, they were astounded. And then I showed them how the digits in multiples of 8 add up to a descending, and repeating "countdown" pattern. Wow. My daughter (who just turned 8) knows a bunch of these insights into the behavior of numbers and operations on them, and confidently says "I'm good at math" despite obviously struggling in other areas (gym, music, art) relative to her peers.
My son reads Junie B. Jones quietly to himself and bursts out laughing. He has discovered the meaning part. And when my daughter got a book about feelings, she finally discovered the power and relevance of reading.
Incidentally, my kids spend about 40 minutes on reading and math in the evening. They get roughly 2 1/2 hours to do other things between school and dinner. There isn't an opportunity cost.
Real World OCaml https://realworldocaml.org
The Functional Approach to Programming (Cousineau)
Since I appreciate seeing someone else's schedule, figured I would post ours. I have 6 and 8yo. and we live quite close to school.
10.5 - sleep
0.75 - morning routine (teeth, dress, find lost things)
7 - school
0.5 - transit
2.75 - free time
0.5 - dinner
0.5 - evening routine (pjs,teeth, don't take bath every day)
0.5 - workbooks & parent tutoring or school homework
0.5 - independent reading of chapter books
0.5 - stories read to them
Because we personally tutor our kids, I'm sure we will resent an increased homework burden as they get older, especially as we are able to tutor to a relatively high level for most subjects. Unfortunately the school does not coordinate with us on the learning objectives, so we more or less rely on Common Core standards to know what's expected.
Wow. I think you missed the point there. He is extolling the virtues of Racket and Dr. Racket. I agree with him, and I think it needs a lot more evangelizing.
My son is 6 tomorrow and is also using Dr. Racket to learn programming. I post on twitter and Facebook about it. I'm proud of my son. But more than that, I'm amazed at Racket as an environment for learning and teaching programming.
No. The author is the originator of FRP and has had a clear definition of it for almost two decades that included a written denotational semantics and modeling of continuous time. FRP has been confusingly redefined by a string of people in the last few years. They could've chosen other labels.
Example usage: https://www.youtube.com/watch?v=Cozw088w44Q
Thanks for pointing this out. I was interested to see they credit Paul Hudak's "Haskell School of Expression" for inspiration. I will have to take a fresh look at that given my newfound appreciation of HTDP (due to stumbling across Norman Ramsey's assessment of it). Also need to look deeper into Hudak's FRP now that I think about it.
How to Design Programs 2E
http://www.ccs.neu.edu/home/matthias/HtDP2e/
This book is much more than the intro to programming that it appears to be. It is a foundational approach for producing robust programs, regardless of your implementation language or level of experience.