Computer Science from the Bottom Up (2013)

Theory is useless without implementation and implementation is nothing without an understanding of theory. Implementation and theory are in lockstep but by learning theory you will not necessarily know how to implement, or even really understand, the topics you have memorized. On the other hand it is necessitated by the concept of implementation that you on one hand understand the tools you are using to solve this problem and on the other have reached a point where you see why the tool is used.

You can sit a person in front of a whiteboard all you want. Brainwash them about arrays, maps, matricies, trees and graphs and they have a high likely hood of coming out knowing nothing but verbatum what you have told them. Conversly you cannot sit a person in front of a computer, guide them through the exercises that I described, and expect the same as the student who once sat in front of the whiteboard.

Trees grow from seeds and the best way to plant these seeds are not with an expo marker but, in my opinion, by bringing the student to a crossroads where they need to discover a concept on their own. This is a common tactic in game design: allow the player to discover new rules after you've taught them the basic foundation.

After they understand the basic foundation of how they will be interacting with the machine I think that, with the guidance of the correct assignements in the notebook codesegment phase of the program, the student will be able to create these different routines and ideas on their own.

Some such examples I will provide below:

   - Make some way that will allow you to find a number between two possitions in memory
   - Make a wrapper for this routine that will operate from a starting possition and an offset of the size
   - Make a way to find the distance between two points on an X, Y plane
   - Find a way to apply the same transformation in every item between two points in memory
   - Find a way to implement a way of storing data about an X, Y plane. For instance where a dot is on a section of graph paper
   - Make a subroutine that will allow you to store potentially infinite items in a collection. There are many ways to approch this but the three main ones are to: use a section of memory that is preallocated and reallocated when it is filled, make some way to daisy chain items of the list together possibly by wrapping them in in more data that will serve to aid your program, do the same as the daisy chain but allow the chain to coninue in more then one direction. Hint: this will probably need an init_, add_, remove_, free_ 

This would take a long time but under the correct stimulating guidance the student will be able to seek out why they need these tools. These tasks should be presented after they've completed a project that someone in our position knows that the optimal way of solving the problem was not choosen and a more abstract and simple solution exists. These situations will present themselves often. I've possitioned myself to make these suggestions to my peers at my university who are having a very difficult time passing the classes we are in together. The people who need to see why AND how.

I'll look at their work and say "how about try using X method of solving the problem and show me what you come up with" and when they come up with a solution I say "now try and make it a library. Remove it from your current solution and allow yourself to use it for further work on other projects".

This changes the way they think about programing.

UVic has a helpful graph of their course requirements now: https://www.csc.uvic.ca/Program_Information/Undergraduate_St...

from https://www.csc.uvic.ca/Program_Information/Undergraduate_St...

For course details http://web.uvic.ca/calendar2016-09/CDs/CSC/CTs.html

http://web.uvic.ca/calendar2016-09/CDs/SENG/CTs.html

An algorithm that is infinitly complex and takes infinite time is of no practical use in every day computation. Maybe in theory, in textbooks, in labcoats, but not in industry.

I don't know where an uncomputable algorithm would be useful.

I do know that you cannot possibly start a student out on a plane of the purely theoretical as they cannot see the value of what they are learning, they cannot understand the implications of the material, and frankly they won't remember it if they don't need it. To their minds, they don't need it if they haven't used it. It can be JFM (Just Fking Magic) to them if they haven't seen a case where it has improved their own algorithms. They will also not really understand how it works with no implementation. It is impractical to say the least.

Theoretical computation is a higher level topic then real computation topic. In the same sense that you start math with addition, subtraction, multiplication, and division you should start out computer science with implementation.

I don't think this is a fair comparison to what the GP is saying. You can pick up pretty much any book on programming for the C-style and more then 90% of the information will transfer over. Classes may be omitted in some, reqired in others. The same may apply to types. But after they see a compiler warning you're likely to google it and figure out what's wrong very easily.

On the other hand most people, who are quite professional in our field I might add, don't even know the names of the most used LISP derivatives. Many also don't even realize they have one built into their browser that is perfectly adequate for satisfying the desires to explore functional programming and general computation principles.

This isn't a statement of malice or even a bad question from the GP. It is confusing and we only have ourselves to blame for this (ourselves being the world of people who want FP to become more mainstream in the SE world).

Look at the stark differences in these two websites:

   - http://racket-lang.org/
   - https://www.rust-lang.org/

What we need is this (with much less crap):

   - https://www.python.org/

And what we don't need is this (with all of this text and few examples of what you CAN do):

   - http://julialang.org/

Granted these are for different markets but the point still stands. If you want adoption by the general software development communities we must make a good case as to why this move should be made. Historically this required a few factors

   1. A better alternative to at least 1 problem *
   2. A simple unified way of introducing people to the change
   3. Simple support for the rollover. Or at least simple enough as to not overpower the benifits presented by switching over.

* = Something that has already been done by the FP community.

You have to understand that peeople call it like they see it and when they see Lots of Insane and Silly Parrens they see LISP and no name change will disaccosiate Scheme, Racket, and LISP in the eyes of the average programmer. I've been using functional languages for a good part of my life as a programmer and I feel they ARE the same. The ideas are common even if their presentation isn't.

The only LISP-Like languages that have sucessfully hid from the tarnished name of LISP are JavaScript and Python and they've managed to develop their own bad raps for themselves in the eyes of some programmers.

No progress will be made by barrating people. Prucussive maintence works on tools and gear, not peers.

In some contexts this optimizations make no sense. In others you'd be laughed out of the office for suggesting that you should use a linked list. You'd be shitcanned before you got back to your office.

In the same sense if you're in a python shop doing web development and you say "EVERYONE we need to STOP using python and write ALL of our HTTP code in C! We'll be able to optimize the hell out of it and probably save 10K of memory per request! That's HUGE!" you would also in tern be shitcanned before you finished the sentence.

If you take that same exact mentality and bring it to a company that builds realtime systems that do DSP and maybe even handle some user interaction in an embeded form facter and you say "EVERYONE! I've found that if we replace our current memory allocator with a circular buffer and pre-allocate everything in an SRAM we can get power-off tolerance AND allow ourselves to make use of all of our memory while not even needing to WASTE the cyles on freeing our memory! We'll save on the oders of 1ms over 50actions! That's a HUGE boon for our batter life!" you'd walk out the head of the office. Saving 500ns, 100 bytes, or even improving something on that scale no matter what it is in contect is huge.

The problem boils down to one thing. For the embeded systems people saving 1MS may be on the oder of 20% of their runtime. For the python shop saving 10K of memory is probably on the oder of sub-00.001% of their memory usage.

It is all about context.

(Disclaimer: I have changed from LL to arrays in some applications because it made a measurable improvement to the speeds of my systems.)