Notes On Lisp Characteristics Of Lisp Evaluating Functional: Fill & Download for Free

The nature of Lisp is that you have functions (which are first-class object), macros, symbolic bindings to values and functions, lists, which can contain functions, values, and other lists, and I think most importantly, metacircular evaluation. These are embodied in functions like eval and apply (you’ll learn about those eventually). A dominant characteristic is that there is a subtle difference between code and data. This is commonly called “homoiconicity.” It’s a sophisticated way of saying that functions and data are made up of the same stuff. It’s just a matter of how they are interpreted from moment to moment.What this means is that everything you use in the language is made up of the above elements—everything. In traditional procedural languages, you have reserved words, or commands, and then you have data. Commands and data are made of different stuff, and you have no means of adding to, or altering the command set. In Lisp, they’re made out of the same stuff. So, it’s possible to change everything in it (depending on how much leeway the dialect’s implementation allows). This is what gives many beginners to Lisp headaches (I went through this as well), because if you’ve been programming in procedural languages for years, this just doesn’t make any sense. How can data be code?!…When you’re first learning it, you don’t have to worry about what I just said. That can come later. Once you realize what I just said means, though, it opens up a new way of seeing what programming can be: You can kind of write your own ticket. You can write your own language, with its own semantics.One way of getting over that hump of understanding what I said about code and data, I found, was to realize Surprise! You’re soaking in it. This is a blog post I wrote, introducing the subject, referring to in-depth sources.One thing I’ll note is the big difference between Common Lisp (CL) and other Lisp dialects is that it’s not strictly a functional language. It’s entirely possible to program in CL in a very similar fashion to how you would in a procedural language. Probably the most familiar analogy would be JavaScript. You can program in a functional style in CL, but the language doesn’t force you into it.

The term functional programming language isn’t well defined, in the sense that people mean different things by it.The smallest set of languages that would be considered functional are languages that are purely functional, in the sense that expression evaluation does not have side effects. The most popular of these is Haskell, but Clean is another; both of these are descendants of Miranda, which is a trademark of Research Software Ltd. Dependently typed languages such as Idris, Agda, and Coq’s term language are also purely functional. There are many other research languages and theorem provers that are very pure and possibly functional.Another criterion for functional programming languages is whether the language supports higher-order functions, that is, taking functions as arguments and returning them. Almost every modern language supports this, so in this weaker sense, almost every modern language is functional. There are impure languages that are traditionally considered functional, such as Common LISP, Scheme, Racket, Clojure, Standard ML, OCaml, F#, and Scala. But I would argue there is no real meaningful sense in which, say, LISP and Scheme are functional but Perl and JavaScript are not. And is it really correct to say that F# and Scala are functional, but C# and modern Java, which are just as higher-order, are not? These are differences of degree, not kind. By similar criteria, we probably have to consider Swift, Rust, and C++11 and later to be functional programming languages.Now, as a scientist and a programming language semanticist, this is somewhat unsatisfying to me. We may not be able to define what it means to be a functional programming language, but there are a bunch of language features that we associate with what we call functional. So maybe we can classify languages more finely based on which of a set of “functionalish” features they support. In addition to purity, discussed above, and higher-orderness, there are details of how well higher-orderness is supported. For example, is there a function type you can use for specifying the type of a functional argument, or do you need to define a specific interface in each case? Is there good support for both upward and downward funargs? Does the language have lambda or some form of anonymous function? And there are other features characteristic of functional programming. For example, correct, space-safe compilation of tail-calls (procedure calls in return position) is essential for using recursive functions to model loops and state machines. Or what about algebraic datatypes and pattern matching? There’s a place where Java 8 still falls short as compared to Scala. One final aspect I consider is how “expression-oriented” a language is, in terms of what forms are allowed to be expressions. I made a table to help you compare:Please note that many cells in this table are judgment calls; I could write a footnote for nearly every one. So if you are wondering what I mean by a particular M, just ask.

Warning: this is a brain dump. Expect substandard eloquence and suboptimal composition.*** NOT FINISHED ***I will first explain the motivation for, and cover the skillsets I believe comprise a good programmer/developer/engineer/whatever you want to call it. Then I'll get into the actual plan.In my mind getting good at any domain is broken down into two broad skillsets:Soft skills: motivation and enjoyment of the craft is the most important - first and foremost you have to 'hack' your mind to like something new that you didn't like before. You also need to understand of the culture of the domain - these are the 'meta level' characteristics, what makes a practitioner of the craft or member of the domain instantly recognizable to another practitioner/member as "legit." <-- very subtle psychology here. Use the terms and buzzwords but do not misappropriate over overuse them.Hard skills: the actual skills; what people are usually thinking about when they think about the topic.Soft skillsThe way to get motivation and enjoyment out of software development is by going to meetups and conferences, hearing speakers talk. Not when you are an expert but from DAY ONE. It doesn't matter if you don't understand what they are talking about - the point is you've got a famous person on stage to look up to for inspiration. It conditions your mind because you see the social proof that this person has (people go 'omg you so awesome!' naturally makes you want to climb the ladder and be like them). Meetups are good because you can meet other newbies and do 'confessionals' and also meet mentors that you can ask the hard questions, advice from. You also get to learn by osmosis things like mannerisms, colloquialisms, memes, etc.Whenever you learn something in a factual domain (where some solutions/answers are more 'right' than others), always fact check multiple sources. Like everything in life, on the journey to proficiency you will be mislead many times, receive false information or bad advice many times. Most of these times the person giving you false information isn't malicious, they themselves just don't know! Don't assume someone knows something just because they know more then you.That includes this Quora answer.Hard skillsThis is in order of what I feel is important, but it's really iffy. For example the only reason I put software architecture and databases et al. beneath team software development is b/c one could get into a team as a junior developer and learn more about architecture, databases, CS, and sysadmin later.1. baseline programming ability2. web/application programming3. team software development4. software architecture5. databases / datastores6. computer science7. system administration / DevOpsI'm going to be didactic when possible, but am not not going to use explanatory language since if you don't know what any of this means anyway looking it up is a great place to start!Throughout the two years, you will glance back at this document every so often and see what you now understand / still do not understand.Baseline Programming Ability- concepts: the sort that you'd find at places like http://learnpythonthehardway.org/ http://ruby.learncodethehardway.org/book/- debugging: you need to learn how to debug programs and figure out what goes wrong. This means using a debugger in your environment/language or printing out statements to check your logic. You should know what a stack trace is and how that can help you know where to start looking.- libraries: all programming languages come with what's usually called a "standard library," which is code provided to accomplish commonly useful tasks not in the language specification itself. For example, networking libraries for a language such as php to communicate over the web. Then there will be programmer written libraries which you will heavily leverage in order to speed up your development - no one wants to reinvent the wheel and there're plenty of wheels out there for you to find and use. Different languages have different terms and centralized repositories for them, for example Ruby has 'gems' and Pythons has 'eggs.' Perl has a repository called "CPAN"- *should ideally* know at least two different 'subtypes' of languages. They can be both imperative, C-like syntax languages, but you should know say (for example) ruby and objective-C, or python and C++, or php and java, ruby and java: one high level scripting language and one 'closer to the metal' language that can be used for systems programming / native application development. You don't have to, but it helps because most software interviews will have a question in Java or C, reasoning that it's "just one of those things you ought to know."- reading code:Ideally you should also know a functional language (doesn't have to be hardcore LISP/Scheme/Haskell, can be Clojure or something multi-paradigm like Scala, and recognize that languages like javascript have functional elements). But not necessary at all. <-- you will, however, become a better programmer the more languages you learn because the different languages were created to solve different problems, and so they THINK about the problems differently. More ways of thinking about problem solving is always better.web programming / application programming- html/css:- javascript:- "single page applications":- if you want to do iPhone/Android development, you can go there. Be aware though that a lot of work is being done on mobile websites and it's unclear if native applications will be popular say five years in the future, so if you are just starting out it's more fruitful to put your energy into web development.- dynamic web sites: client/server- REST and working with APIs:- how does the entire internet actually work, end to end? You actually don't NEED to know this but by asking this simple question it will lead you down the road of web servers, DNS, load balancing, CDNs, firewalls, etc. all sorts of topics.(side note) Web Performance:- "Scaling" a website: there's a reason why I put the 'scaling' in parentheses.- caching layers: on each step of a web request there is caching, from client --> CDN --> HTTP caching layer --> web server --> data --> database/operating system. HTTP headers encode information instructing these caches what to do and how to act.- frontend performance:- backend performance:- benchmarking vs. profiling:At this point in the skill tree, you may be able to get an entry level position, or an internship/unpaid position depending on your network/job seeking abilities.team software development- software versioning: ex. "2.3.1" denotes <major>.<minor>.<patch>. Major releases are backwards incompatible (ex. Rails 2.x vs. Rails 3.x), Minor releases are features additions (ex. Rails 3.0 vs. Rails 3.1), Patch releases are bug fixes (ex. Rails 3.0.1 vs. Rails 3.0.7)- feature prioritization- communication skills- version control- deployment/configuration management- documentation- software testing- continuous integration- there are also lots of topics here like "how to hire/interview" "how to improve a developer" and "how to fire someone" but those are more management topics I suppose, though they do need special treatment when it comes to programmersSoftware architecture- design patterns:- refactoring:- clean coding:- error handling, exception handling strategies: Ideally you have logic to handle EVERY possible scenario in a program, but in practice this is hard and too tedious. Also, some errors that occur simply cannot progress the program further. This is an exception. Also, program control flow can be made simpler with the concept of exceptions. Remember this adage: "throw exceptions down low, catch them up high" <-- this'll make sense to you at some point.Databases/Datastores- there should be a minimum amount of knowledge about databases. You should know what SQL is and what makes good and bad SQL queries. At the very least that this concept exists. Recognize if you are using something like Ruby On Rails or Django which uses an object relational mapper, that they have limitations and performance issues in certain cases. The documentation for an ORM should talk about this.- You should know how to model data. Meaning, if someone tells you "I need an app with customers and orders and they have wish lists and I want to keep track of the suppliers" etc, you should be able to design a data model to do it (otherwise how would you build the application?)- You should ideally know about pure DB level performance: the differences between Postgres and Mysql, the tuning parameters, how their storage engines work. At the very least recognize that the database is a program itself that can run optimally or suboptimally. Know that all databases (even nosql data stores such as MongoDB) have a "slow query log" that will tell you what is not working well, and you can look things up from there.- Concurrent access to databases. If two people try to write a value to a database at the same time within a transaction, what happens? All databases have a set of features to accomplish something called MVCC (Multiversion Concurrency Control). DIfferent databases do this differently. There is also a concept called ACID (Atomicity Consistency Integrity Durability) that describes attributes that a program should possess in order to be called a database, and MVCC is a flexible notion: there are always tradeoffs and in a single database instance (as opposed to a distributed database, which I will address later) the tradeoffs are often between speed and concurrency. These levels of tradeoffs are divided into tiers, called "isolation levels" (serializable, read uncommitted, read committed, repeatable read). Know that different databases may ship with different default isolation levels (mysql vs. postgres for instance).- datastores are things like Redis, Memcache, MongoDB, CouchDB. They do not adhere to the aforementioned ACID properties and so are not databases in the traditional, purest sense, and do not use SQL for querying them. But they can store information and are useful for a variety of reasons. You don't need to know too much about them but should be aware of their existence and what they do (read: the wikipedia article).- If you've read this far, you should also be aware that there is something called "NoSQL hype." You should be aware that there exists "SQL vs. NoSQL" debates and research being done into the topic of what technologies will meet the data storage requirements of the modern and future web. The summary is this, though: evaluate solutions, benchmark them, and use the right tool for the job.- For most developers it's not super relevant to know distributed datastores like Cassandra/Riak/HBase, but you should know concepts like map/reduce. These datastores are of interest and chances are most companies at some point in scale will use one of those technologies for data analysis. This also starts to get into a separate topic all together (distributed systems and how to architect them).Note on Distributed databases/datastores: know that in a distributed system's state there is something called CAP theorem (Consistency, Availability, Partition tolerance). The rule is that you can choose only two out of the three as properties of your distributed system, BUT this is a gray area due to a couple different business use cases: if a datastore is distributed it must choose whether to have every node "know the same stuff," or every node be accessible- 1. "eventual consistency": if I don't care too much about everything being correct, I can have writes/updates to my system state propagate. An example is Amazon's inventory. Amazon doesn't NEED to have accurate inventory counts, because if everybody buys a book and it's not available they can just reverse the transaction and send an email to the customer: "sorry we're actually out of stock"- 2. Quorum sensing. Paxos algorithm, read about it. If the state of a system needs to be absolute, when I read a value the Nodes need to vote on what the correct answer is. Good example is reading a stock price in high frequency trading. If I am buying a stock, I NEED to know what the price is at this very moment, because I may be acting on changes in fractions of a cent.Systems Administration / DevOpsA long time ago computers were mysterious and people with special skills were hired to work with them. They were/are called systems administrators (or sysadmins for short). Today, a lot of sysadmin stuff has evolved in conjunction with software development such that a sysadmin is more of a developer who is writing programs to manage the systems/infrastructure. Hence you will come across the term "developer operations"(DevOps) and the title "operations engineer"- This is kind of a moving target since the advent of cloud computing platforms like Amazon AWS and Rackspace have been changing the game, and more recently full on "hands off sysadmin" like Heroku are making it so developers don't need to know anything about the servers their programs run on- you will need a minimum level of linux knowledge, however, if you are developing on a mac or even PC. Commands like "ls" "tail" "mv" "cp" etc. you need to know the concept of a "path" - these are the directories your computer will search through when you type in a command, and this is critical because you are not the only person executing commands on your computer, other programs are as well. Be aware in *nix machines there is something called a "bash profile" or "shell profile" that gives settings and configuration to each user account- there will come a time when you need to compile a program in order to use it. Remember this: configure, make, make install. This is the general sequence of commands used to install a program, which may vary. Source code you download will typically have a README file to tell you how to install it.- web servers typically run on linux, and if you run your own you should be aware of concepts like cron jobs, chroot jails, programs automatically started when the server boots (init.d), daemons, logging, file permissions, PIDs, how to monitor running programs and what to do when they crash (ps -aux to see running programs, note the PID and google 'how to kill program linux').- these also include additional commands used on servers to assess and modify their state, like "vi" "top" "iostat" "vmstat" and others.- a lot of the commands you type into the shell can also be automated with shell scripting, or a scripting language like tcl/expect. These scripts, which can do things like backup a database, can be automatically scheduled as one of the aforementioned 'cron jobs', which reside in a 'cron tab'- also be aware that *nix has slight differences across the different branches and environments. Things like commands and file structure will be slightly different. Especially if you have a Mac you will notice that many commands and file structure is different between your Mac and a linux machine. This is because unix has a family tree, I've attached a picture of something like what this looks like (to my knowledge - it's probably horribly inaccurate but the point is that your Mac sits on a different part of the family tree than linux):Computer Science- Algorithms: you should know about the nature of algorithmic complexity (Big-O notation) although this should be pretty intuitive if you think about how your code runs and how to make it fast or slow. Know what makes slow code and fast code. You should also know a bit about graph algorithms because they are applicable to a variety of real life problems (For example how does Google Maps' directions feature work? How does flight search on Orbitz work?)- Operating Systems is important b/c it plays heavily into how database internals work and how to optimize their performance. You should know how multithreading and processes work and what happens on multicore machines, a bit about Linux architecture (like the concept of "everything is a file", IPC/domain sockets, PIDs, etc.).- Compilers, and by extension how interpreters (languages like Ruby, PHP, Python) work are of interest to you on multiple levels. For instance, the performance of dynamically typed languages like Ruby and Javascript are highly influenced by the internal architecture of the interpreter, and these internal attributes manifest themselves in speed optimizations when programming.- AI/machine learning: good for nerd cred, it's reasonably useful to be familiar with the basics b/c things like using euclidean distance and bayesian filtering for basic recommendation engines, as well as random statistics related topics are pretty applicable to a broad range of consumer products.Realize though that business is about people, not machines, and I'd take learning more sales/marketing/PR skills over this stuff any day. This is a moot point though, because if you've truly hacked your mind into liking this stuff and get inspiration from peers, social pressure to be "legit," you'll probably come across this stuff at some point. You may not get far if your math skills are limited (some linear algebra comes into play like for non negative matrix factorization and support vector machines, and if you get into data analysis (even metrics for things like response times and throughput) there's statistics involved. Also you will care about matrix math for certain algorithms like Google's Page Rank), but again - you'll come across what you come across. Learn what interests you and then some.The Two Year PlanSo now we're finally to an actual step by step plan over the course of two years to get you good at programming. Well... there is none. There are actionable items of course but this is all there is: build shit, and also make shit with other people. Perhaps I've fooled you this whole time into thinking there'd be an actual guide at the end.But I haven't. The truth is that life just doesn't work like that. Life isn't a linear path from A to B to C....???.... to Z. It's a zigzag ride full of twists and turns that everyone blazes their own particular way.The important thing is that now you know what you need to learn, and I've told you what to know and how to go get it.So that's it. The only reason why this was called a two-year plan is because this was my own journey up until the writing of this answer.The rest is up to you.I leave it entirely in your hands.