Simon Thompson

Simon Thompson

Academic at the University of Kent, where I am Professor in Logic and Computation in the School of Computing. You can find out more at my www.cs.kent.ac.uk/~sjt/

Location Canterbury, Kent, UK

Activity

  • Well, it's nice to see how far you can get with just pattern matching :-)

  • And just to confuse things, strings don't really exist in Erlang: they are "just" lists of ASCII codes …

  • What Brujo says is one of the strong customs of the Erlang community. So much so that I didn't realise that there was an import statement in Erlang for quite some time.

    It's interesting that the pragmatics of a language are as important as its syntax and semantics.

  • That's one reason it's really nice to teach!

  • Thanks for all the sharing in this step!

  • The story I know is that they tried a lot of languages, and found that none provided everything that they wanted. Hence a new language. The original interpreter was written in Prolog, so some of the syntax got carried over.

  • @AndrewMatthew fair enough. And I am guilty of using the maths here, but there's an interesting discussion to be had about how teachers' expectations feed into pupils' perceptions. If the former project that something is difficult, then that is picked up very clearly by the latter.

  • Hi Chaitanya. The whole function definition of `area` ends with a full stop, but the definition consists of two expressions: these are evaluated one after another, and the result of the function is the result of evaluating the last expression.

    In this case, in the first the name S is given to the formula on the right hand side, and then this S is used in...

  • @AndrewMatthew good points. I'm not completely sure about the math concepts, though. The idea of a function as a transformation of inputs (values) to outputs (values), rather than side-effects on storage, seems simpler conceptually, but maybe that's just showing my bias.

    And OK, I *do* use numbers for recursion, but as soon as lists are introduced then they...

  • It's interesting that type systems for Erlang are a hot topic again: facebook/whatsapp are looking at one, and Josef Svenningson has been developing a "gradual" type system for Erlang: gradualizer https://github.com/josefs/Gradualizer

  • Aha! Intriguing.

  • Yes, I think that was one of the few mistakes made in the design of Elixir.

  • Thanks for your additional comments here!

  • Simon Thompson made a comment

    Hi everyone - great to see you here, and I look forward to working with you on this MOOC.

    Do please use all the resources you find: each page has a _comments_ section, and I'd like to encourage you not only to ask questions, but also answer others questions too.

    We're joined by a number of experienced Erlangers from the Erlang Ecosystem Foundation who...

  • Doh! Sorry that I have been so slow in understanding this. I see that you have the set_trap_exit functionality exactly as it is because of the way that you allow your clients to have possession of multiple frequencies at any one time. I had really not envisaged this as a use case, and assumed that each client held at most one frequency at any time.

    So, to...

  • I wasn't sure that I understood the logic you have for dealing with trap_exit. In particular, what is behind the call set_trap_exit(NewFreqs) in the case that NewFreqs is not empty, but a successful de-allocation has taken place?

  • Did you think about getting the client to set trap_exit to true (for some parts of its execution)?

  • That's a fascinating question. I think that the answer is mainly that OTP got things broadly right, and that the sophistication of the implementation and design means that there's a big cost to re-developing something similar.

    The Erlang community is small and cohesive, but that's not been a bar to the development of different build tools, web frameworks...

  • Thanks for the comment about deallocate as call or cast. I partly chose the cast to make the contrast with call, but you're right that an acknowledgement would be a good thing, in general. On the other hand, it's certainly not necessary for the client to continue, so it's a matter of taste, I guess.

  • It's possible to include specs for the gen_server callbacks, and we should think about doing that.

  • Thanks, Victor!

  • We need to take on board that it's taking people more time … four weeks could work, and we'll definitely think about that. Thanks for the feedback!

  • Sure there are Erlang meet ups in Stockholm, and maybe Göteborg too?

  • Messages to non-existent processes are simply dropped … is that what you meant?

  • Once we start looking at distributed systems, then how systems recover becomes a lot more application-dependent. Francesco Cesarini's new book discusses this in the later chapters http://shop.oreilly.com/product/0636920024149.do

  • Inheritance is less straightforward. It's not hard to see Erlang as an object-based language, where objects are represented by processes and communication is via message passing; however there's no straightforward representation of inheritance without building an explicit model of it: rather ugly.

  • Manfred - that could indeed be a problem, but the asynchronous nature of Erlang message passing avoids a whole lot of potential scenarios for deadlock.

  • State can be persisted in a number of ways: by the arguments to a tail recursive function, by putting the state in a message to the process itself (a bit like "delay line" storage from the 1940s), or using an ETS table; some details about this are in the companion MOOC on functional programming in Erlang.

  • Hi Douglas - if you check out the documentation for the erlang module http://erlang.org/doc/man/erlang.html you'll see that link takes one argument, but monitor takes two, but also in that case, the relationship is made between the process in which monitor/2 is called and the second argument which is a Pid; the first is the atom process (distinguishing this...

  • I've also added some comments about this to the feedback video scheduled from the last step of week 2.

  • That's right.

  • Victor, that's exactly right. Concurrency is about *independence* of processes, rather than explicit parallelism. I should also have been clearer about steps …

  • Hi Florian - sorry to hear that. There are some pre-compiled Erlang versions at the Erlang Solutions website https://www.erlang-solutions.com/resources/download.html but perhaps not for your particular flavour of Linux.

  • Hi Jose - thanks for the question. The point is here that you have killed the existing process with reason kill, but the linked process will not receive a message with reason "kill" but with reason "killed", which is trappable.

  • We're still looking into the "extended video" problem …

  • Douglas - no, no monads in Miranda: the special flavour of Miranda was laziness + strong types, including user-defined types.

  • Thanks for the "heads up" on this … we'll look into it.

  • We talk about this in the next step. You're right that this is a potential problem: if you don't match on every kind of message then it's possible to miss some, and for these to accumulate in the mailbox.

    One way to avoid this is always to include a "catch all" clause in receive statements, but that may not be appropriate in all cases. Alternatively it's...

  • I'm using Visual Studio Code, which seems to work a treat (also for other languages).

  • What is meant here by "asynchronous" is that it's not necessary for message send and message receive to be synchronised. A message can be sent without the receiver actively participating at the time of sending. For this to work, messages have to held somewhere pending their being processed by the recipient: hence the mailbox. Given the example in Ed's posting...

  • The key Erlang construct here is the timeout of zero on a receive clause: this means that we can process all (and only) the messages already in the mailbox. We can just throw them away, or process them more actively.

  • Just to be clear about upgradingl: after upgrading you have indefinite access (bounded by the life of the course itself, I guess). The other thing to be aware of, is that "If you choose not to upgrade, you can still access the majority of the course for free, for the duration of the course plus two weeks – regardless of when you join”. This quote is from the...

  • Yes, indeed: well spotted Ed.

  • All good points; thanks! We'll talk some more about distribution in the last week of the course, but to jump ahead a little, it's right to say that Erlang “out of the box” supports distribution in a non-hostile environment. That being said, others have looked at ways of hardening systems, and there's a whole perspective on this in Cesarini and Vinoski's...

  • Good question! This can happen in practice, and it will slow down performance. In extreme cases it can lead to what gets called "grey failure". There's a nice discussion of this here, if you're interested: https://blog.acolyer.org/2017/06/15/gray-failure-the-achilles-heel-of-cloud-scale-systems/

  • You'll need to use Visual Studio Code - which is a code editor - rather than Visual Studio itself. It's confusing naming. Or did I misunderstand your message?

  • Douglas - that industrial/academic split might have been true 5 years ago, but Haskell is getting wider use industrially: not just in bigger enterprises e.g. banks but in startups and SMEs too.

  • Here's a way to create a local function: bind a function value to a variable, and then apply that variable, as here:

    foo(X) ->
    F= fun(Y) -> X+Y end,
    X+F(X).

  • Douglas - and one more thing: remember that there's a follow up Erlang MOOC on concurrency, too, starting in early August: do sign up for that! (You can really see the two 3 week courses as a single one, but with the chance to catch up in half way through). Info here: https://www.futurelearn.com/courses/concurrent-programming-erlang/

  • Hi Douglas … I think that the Haskell MOOC on FutureLearn will be running again in September 2017, so that's a chance to learn more. It's a 6 week one.

  • About local function definitions. You do it in Erlang like this:

    foo(X) ->
    F = fun(Y) -> X+Y end,
    X + F(X).

    and evaluation F(3) gives 9, for example.

  • Thinking about this again – and I do come to this question again and again – tail recursion tackles the problem by thinking about the process of getting to the answer “bottom up”, moving forward from the inputs, whereas the direct recursion approach looks at the result and tries to understand how that answer could be built from similar answers: so it's more of...

  • No, there's no difference between [El|List] and [El]++List since the complexity of Xs++Ys depends on the length of Xs. This comes to be a problem with expressions like ((…(([X1]++[X2])++[X3])++… )++[XN]) which can arise e.g. from a naive reverse with recursion clause

    rev([X|Xs]) -> rev(Xs) ++ {X].

    HTH, Simon

  • Thanks Léo - typically a case comes in handy when you don't want to make a function call just to switch depending on a value. I recall programming in Miranda which didn't have explicit cases, it it sometimes meant defining a function so that it could be called in the body of another function to make a switch. Problem with that is that it clutters up the name...

  • Thanks Stephen. All I would add is that we could modify the return type of maximum/1, so that it returns an {ok,N} when a maximum exists, and empty (or some other atom) otherwise. This passes the responsibility on to the caller to deal with the possibility of an error, and, of course, complicates the code that the caller has to write.

    In the general case...

  • Thanks for all the comments here … we'll certainly take these on board for the next run. In the meantime, just in case you missed the weekly email, there's a discussion of this in this video https://youtu.be/0J8DCxFoqOs too.

  • Apologies all - the first line in the section "Adding a supervisor" of the assignment should read: "Program a supervisor process that can be used to start the FREQUENCY SERVER, and restart it whenever it has terminated unexpectedly."

    It's now corrected in the assignment, so not a problem if you're coming to it for the first time.

  • Hi Deven - you're right about the Max Cut problem, but what I was asking here was to make the cuts straight lines. This makes it a lot (!) simpler.

  • We should add that early on. Thanks for the hint!

  • We'd like FutureLearn to add this. Definitely. It would come with supporting markdown in comments.

  • Using small letters isn't strictly an error. While X is a variable, x is an atom, and so a clause like f(x) -> 42; defines the function f to give the value 42 on the atom x (and says nothing about any other inputs). So, the warning is that you haven't covered all possible inputs.

  • Thanks for posting this!

  • Remember it's only a shell command, and not an Erlang function!

  • A succinct way of defining a side effect is that it's anything that happens when an expression is evaluated, in addition to returning a value. It could be IO, communication (in Erlang, message passing style), changes to the state of memory, changes to the state e.g. of a random variable, …

  • Thanks for posting this!

  • Simon Thompson made a comment

    Thanks everyone for your contributions here … it's interesting to see what a variety of background and experience people have, and also how many people are looking at Erlang because of Elixir. Nobody would have predicted the rise of Elixir five years ago, I think, but now it's an established – and still growing – technology. One of the exciting things of...

  • HI All. Thanks for the discussion about posting answers. We've been talking about this, and one thing to try would be to signal any post about a solution with SPOILER as the first line.

  • Simon Thompson made a comment

    Sorry to hear that there have been problems with the videos … we do hope that this is all sorted out now, and that things run smoothly from now. Looks like it is a problem with the video hosting company that Future Learn uses. Will keep you posted …

  • Nice video - very clear on the roles, but also humanises them: difficulty of keeping track of artists, but also very positive about how to ensure that communication is effective: ego-less management in action, I guess.

  • What really surprises me about this list is how clearly defined all these roles are. As an academic and computer scientist, I don't see such clearly defined roles either in universities or in the software development industry. What do others think about their industries and how they compare to the film industry?

  • This is much more useful than the last video, and great to have this as a download to; thanks.

  • Sorry to say I didn't find this at all useful. Some sort of organisation chart, diagram or just a written list, would be much more useful than this spoken list …

  • Altman's Nashville … I guessed 100, and 110 listed on IMDb, but I guess that doesn't include 100s of extras. I wonder whether if it were made now – it's hard to think of this as being made over 40 years ago – the numbers would be higher?

  • Hi Mara, Jon Bourne posted this really useful link in reply to me asking the same question. http://www.hollywoodreporter.com/news/budget-breakdowns-what-a-typical-827862

    Sorry Jon, don't know how to link to your reply directly.

  • Thanks very much … that's really interesting.

  • Thanks. One thing I hope we'll learn is where the money goes on a typical film, though I guess that no file may be typical :-)

  • How easy is it to find out how the cost of (say) £20,000,000 for a mid-budget film is actually spent. Is this sort of data available?

  • The Ice Storm was a wonderful film, and Sense and Sensibility: a common humanity, but such different stories.

  • Lighting is intriguing for me, both as an amateur photographer, and being filmed myself for another MOOC … in both cases, getting the light right can mean having to manipulate it by reflection or active lighting. It's counter-intuitive, as our visual perception means that we accommodate so much more than a photographic film or digital sensor.

  • Interesting to see behind the curtain … though it would be a shame to have the mystique completely removed. I'm only here to find out more, it's not part of my job/career at all.

  • Simon Thompson made a comment

    Film is something special to me: in a world where we graze lots of media, film in a cinema still demands, and I hope deserves, 100% attention. It's always intriguing to see "behind the curtain" a little, and to find out more about production.

  • Two films that managed to mix light and dark in a way that seemed natural and to mirror how the world is. I might have expected Mustang to be all dark, and Florence Foster Jenkins to be all fluff, but both had their balance. It's always great to be surprised.

  • I'm very pessimistic about the outcome. I fear that we're going to get Brexit, based on fear about immigration and disenchantment with politics in many parts of Britain. We'll see a retreat from the world, and particularly from our neighbours in Europe, and it will do nothing to solve the underlying political problems. I hope I am wrong … but I fear not.