>> [MUSIC] So, let's conclude our course motivation by discussing why I chose to
use the three languages I did in presenting the material for this course.
>> here, I'll distinguish ML, which sometimes is used as a more general term
for SML, OCaml, and F# >> from standard ML or SML which is
what we're actually using. And I'll point out, first of all, that SML, Racket, and
Ruby provide a very useful combination for us. So, I have a two dimensional grid
here where you can see that some languages
>> are more dynamically typed, and others are more statically typed.
>> We'll study the differences between those a lot in this course.
>> You could also say that some languages promote more of a functional
style, while others promote more of an object-oriented style.
>> There are other rows one could add to this chart,
>> not all languages are >> functional or object oriented.
>> But it's useful to us for this course that Racket, Ruby, and SML
correspond to three of the four positions.
>> I don't think we have time for a fourth language.
>> And many people, before coming to a course like this, have already seen the
fourth segment if they've programmed in Java or C#,
>> or used the object oriented features in Scala or what not.
>> that's not true if you programmed in Python,
>> which is dynamically typed. >> But nonetheless, three out of four
positions helped show that functional versus object oriented
>> is an orthogonal issue from dynamically versus statically typed.
>> So, that's why I picked these three as a package.
>> Why did I pick each one individually? Well, for any of the ML
like languages, including SML, I really like that it has polymorphic type, so we
can use the type system to understand how code can be reusable when we see quote a
types. >> It has pattern matching which I
think is a wonderful way to >> think about how to decompose your
data. >> And I really like the module system,
which we will study in order to see how you can use abstract types to enforce and
variance the clients of your library cannot violate.
>> For Racket, I want a language with dynamic typing.
>> I like to do a short segment on macros and Racket has a very good macro
system that makes a lot of sense. >> I like that it has minimalist syntax
by using more parenthesis. everything has a very regular, very easy to understand
syntax, even if many people don't tend to like it.
>> And it has eval >> which is a particular concept we can
talk about, and relate it to some other concepts.
>> I really like Racket as a language, >> and so that's why I picked it.
>> And finally, Ruby. >> it's an object oriented language.
>> It uses classes, but it does not have types.
>> So that's a good contrast with a lot of other object oriented
>> programming languages. >> It's very object-oriented.
>> All the data in Ruby is an object, not just most of it, which I like. And
some small features that, that I find useful to teach.
>> And, and I'll try to include the particular topic of mix-ins which you can
accomplish with Ruby's modules. >> So, there's a lot of other small
reasons. >> Well, that gives you a sense that I
didn't just pick these because I liked them or I thought they were fun or I
liked their syntax or something like that.
>> I do wish I could complement these three languages with Haskell and with
Prolog, because I think they are qualitatively different from the three we
will use and, and we simply just don't have Have time.
>> Haskell's approach to laziness, a topic we will study briefly with Racket
is what really sets it apart. >> As well as its pure functional
nature that it's really separates out even more than ML, the ability to mutate
things in to a separate part of the language.
>> And it does that, and does other things as well, with the wonderful
features of type classes and monads, which I just don't have time to get into.
>> And then, Prolog is really a very different paradigm. It's logic
programming where it has built into the language semantics the idea of searching
for a solution. >> And it's a very different
perspective on how to think about computation.
>> So, for most of the rest of this segment, why don't I explain reasonable
options as alternatives to ML, Racket and Ruby, and a little bit of why I didn't
pick them. >> like everything in this section this
is optional, but some of you may be curious in these reasons.
>> So, instead of SML, we could have easily used a similar language a more
functional language, maybe OCaml, F#, Haskell, Scala all of which are more
modern, a little more convenient to modernize and more tool support.
>> And I did pick SML for, for some good reasons, some really good reasons
and some more accidental ones. >> so, the, probably the closest
choice, the thing I would have been next to pick would have been OCaml.
>> it has all the things we need but I would need to have port all of my course
materials and I probably introduce a lot of bugs when I did that. And there are a
few small things that I do use in the class where SML is a little more elegant.
In particular in SML but not in OCaml, those constructors from our data type
bindings are actually functions. They can be passed around just like any
other function. >> And I find that SML's approach to
signature matching, when we study the module system, let's me point out a few
elegant things that don't, don't work quite as well as in OCaml.
>> OCaml is a wonderful language, as is F#.
>> F# is really a dialect of OCaml that runs on Microsoft's .net platform.
>> I steer away from it a bit because it is a sophisticated and complicated
language, and you need an implementation of net.
>> to run it. >> And so that's a little more
difficult, although, not impossible on non Windows platforms.
And, compared to OCaml, there's even a few more small things that don't work as
well. >> in particular, the fact that you
cannot take a polymorphic function and export it in a signature as a
non-polymorphic function. >> These are minor things, you could
absolutely do the course in F#. But you know, it's enough to cause me to pick,
stick with SML. >> Haskell, I would be less likely to
pick. >> Haskell's a wonderful language. But
the way I teach semantics and the way the way I want you to think about evaluation
rules does not work well with the lazy semantics in Haskell.
>> And Haskell things don't evaluate in the order that they do in ML
>> and in most other programming languages.
>> And I find that much harder to teach with.
>> Other people do start with Haskell, even in a first programming course.
>> And I have nothing bad to say about those courses.
>> But it, I >> find it too difficult to present a
crisp and accurate view of computation in the presence of laziness.
>> Okay. So, SML is a less modern language than
these others, that's not to say you couldn't build a real system with it
today. We've been writing programs with it.
>> but I find it's still a fine foundation for teaching functional
programming. And after you've learned it, you will
have much, much less trouble picking up another one of these languages they
really are quite similar in many ways. >> So, a little more quickly instead of
Racket, we could have used Scheme or Lisp or Clojure that are, that share a lot of
similarities. >> for me, Racket is a modern language,
it's continuing to evolve, which is both a blessing and a curse.
>> it's a bit more of a moving target, but it improves in, in many ways these
variance and in the ways it doesn't, it doesn't really matter for us.
>> I particularly like it's module system, It's support for structs, which
are a lot like, eh, records and other languages,
>> and its contract system. >> Although, we won't really get into
the contract system, it's nice to have a language where you can go on and learn
more on your own for that sort of thing. >> It has a large user base.
>> it's probably best known for its role in computer science education, but
that is not all that it is used for. >> And it comes with the Doctor Racket
IDE which makes it easier for teaching because the development environment was
always designed to be useful >> for teaching.
>> At the bottom of the slide, it turns out in Racket, you could design your own
language very easily. It's a very cool feature of the Doctor Racket system and
the Racket infrastructure. >> and it's tempting to do that for
anyone's class, and then come with a language that's exactly like you want.
so, a slight variant of Racket. But, I decided it would be better to use the,
the, the more common language that other people also use.
it's a good design, it's already been used by other people.
>> and even if there a few rough edges for us it seemed better to stick with a
language >> as already defined.
>> And finally, Ruby. >> Ruby is known as a scripting
language, so why not use Python or Pearl or JavaScript.
>> They are also dynamically typed. >> Most of those languages, like Python
and JavaScript do also have many of the object-oriented features.
>> But they're not as fully object oriented as Ruby.
>> And Ruby it's really a more complete commitment to object-oriented
programming, in ways that, that we will see.
>> Ruby also has full closures, which Python does not.
>> Python doesn't provide the full power of closures as we have seen
>> or will see in ML. >> and JavaScript is a very
object-oriented language but it does not have classes. It has prototype based
inheritance, a topic we won't get to in this class.
>> And I don't necessarily have a preference for one over the other, but
I'm happier starting with a dynamically typed class-based object-oriented
language because I feel it makes an easier contrast with statically-typed
class-based object-oriented languages like Java and C# and Scala.
>> So, the other language that actually shares everything with Ruby that I've
said so far is actually Smalltalk. >> And I used to actually use
Smalltalk. >> it's a much older language language.
>> People find the syntax very strange, which of course doesn't bother me in the
slightest because it's just syntax. >> Couple things I like less Is that,
it is just less common. >> Fewer people know about it.
>> There's less modern tools for it, and Smalltalk implementations have
traditionally merged the language with the environment.
>> And what I find to be a somewhat strange way and a way to make it harder
for me to tease out the actual language constructs.
>> People who like Smalltalk consider that a feature.
>> I find it a little more confusing, >> okay?
>> So, there's your background. >> just to finish up very briefly let
me remind you, I think I said this at the beginning of the course, the way we use
these languages in this course can make them seem silly.
>> We write small little functions, we test individual concepts at a time.
>> I'm fully aware that real programming languages need lots of
things. >> You want tools like testing
frameworks and bug tracking systems and project managers.
>> You want libraries for things like file I/O and accessing the network.
>> You want constructs for floating-point and string operations, and
multi-threading, >> okay? Many of the elegant languages
have that and more. >> Racket and Ruby actually have all of
these things. >> but we just don't use them in that
way in a course on programming languages. >> And so, you know, there are other
languages, like Java, that we could also use in this sort of silly way
>> in order to teach language constructs.
>> I've just tried to explain in this segment how I think ML, Rachet, and Ruby
better serve our purposes. >> And so, finally, let's finish up
motivation with, after this course, will you ever use any of these languages
again? it's quite likely you will. >> I encourage you to.
>> You might use similar enough languages that it's almost like you're
using these languages. >> But you might not.
>> You might spend the rest of your career programming in C++.
>> And that's because of real-world concerns,
>> right? You need the libraries that you need.
>> You need to use the languages that your boss wants you to use.
>> You need be hi, able to hire people under your team that have the background
and the skills that you need. >> There may be an industry standard.
>> You may need to communicate your ideas to people who have not taken this
class, and so on. >> I get all that.
>> you know, a, a course like this, by design, the thing that separates a course
from sort of industry practice and the real world is that we don't have to deal
with all of those questions, we can focus just on the programming languages.
>> This is a course on programming languages not the more general issues of
software engineering and software development.
>> And that affords us the opportunity, the benefit, to push those reasonable
questions off to the side. And, it's really about taking a more long
term view, right? Technology leaders, and I hope many of you are technology
leaders, get to affect answers like what is the industry standard? What sort of
people should I be hiring? How should we educate software developers? And so, we
shouldn't feel overly constrained by how the world necessarily works today.
>> We should plan for the future. >> We should see the underlying
elegance. >> We should see the universal
features. And I like to use ML, Racket, and Ruby to do that.
