4 Programming Paradigms In 40 Minutes


One of the most important lessons I’ve learned is that programming languages are tools and not all tools are good for all jobs. Some tasks are easier to solve functionally. Some are clearly suited for OO. Others get simpler when you use constraint solving or pattern matching.

Let’s go on a whirlwind tour of 4 different programming languages emphasizing different programming techniques: OO, functional, logical, and procedural. You’ll leave this talk with a better understanding of which languages are best suited to which types of jobs and a list of resources for learning more.


RubyConf 2017


Aja Hammerly


The original video was published with the Creative Commons Attribution license (reuse allowed).


Original video source:

Nguồn: https://bus-rush.info/

Xem thêm bài viết khác: https://bus-rush.info/game/

43 thoughts on “4 Programming Paradigms In 40 Minutes

  1. In lisp, "car" stands for "contents of address register" and "cdr" stands for "contents of decrement register."

  2. It is a horrible idea to represent dollars and cents using what several computer languages refer to as a "float" because a float cannot accurately represent all the values between 0.00 and 0.99 in increments of 0.01.

  3. Always hated math and scripts in highschool. Total 360 degree turn, obsessed with this stuff now, a beautiful and powerful art.

  4. I think that what many people do not realize is that we think in the same way that LISP programming is done. It's actually IMPOSSIBLE to know that you are adding two numbers (in your head) without telling yourself that you're going to add two numbers. Therefore, the operator should come first. Even if someone grabs an arbitrary collection of numbers, and you tell them "okay, now add them", just by saying that have placed higher priority on the operator than you have on the operands.

  5. Not bad, but it doesn't help anyone to say "this doesn't look like OO does it?" and then not give any reasons why it wasn't suitable for the people in the audience that weren't so sure.

  6. Brilliant talk: I am going to use it to introduce law students to ideas about computation and programming languages.

  7. Computer languages are embarassigly bad….. all of them are so flawed. Your industry is a total mess. Single paradigm languages are the worst, that's for sure… at least O-O can use functions and procedures. With strong typing and overloadable global procedures and functions you can make O-O procedural or functional, with O-O .property and .method syntaxes too, so you can do: put(ob1, ob2)… ob1:=ob2…. ob1.put(ob2)… with operator overloading and all three styles you can make APIs with decent, highly readable code. If you stick to just one your code will read badly, like Chinese or German grammar, especially with O-O….. OO.Destroy!… I'd prefer to bin(OO), personally… and as to naming things, names should be as short as possible, even/espsecially at the most basic level… I don't do fields or properties, I do DATA OBJECTS with DATA CELLS and DATA OPS on LOTS OF (of lots of) DATA…… The Cell-Op-Lot Object/Class model… Property, Method, List/Table are so overly verbose…. every char removed while keeping or improving comprehendability is key…. This philosophy should be applied to all languages… But the main, general purpose language should have NO RESERVED WORDS, only symbols…. this leaves more room for well named objects, cells and ops. Each line should start with a object name or block type symbol followed by a block header and short block on the same line or tabbed, indented block on the next line… '?' = if/case, '!!' = ekse. * = for/while/loop, / = class definition, '.' = cell/op, + a few others… ? x1>x2 xHigh=x1 xLow=x2 || xHigh=x2 xLow=x1… but also functional: Bitmap1[20,20] = Bitmap2[10,10 40,40]… space or comma can be used for parameter lists… clauses as indexes: tallPerson = person [height>1800]…. pointer derefencing should be standarised with '.' prefix meaning pointer to, suffix meaning actual data, '..' suffix = cascading copy of data and subdata..

  8. So? Everything in C# is also an object. The same goes for Powershell, probably more programming languages as well.

  9. Polyglots are respected for a reason. They are very rare.

    Please never again confuse median & average with far outliers. I get too much of this crap when I talk to business executives, who barely speak English and wouldn't know structured algorithmic breakdowns with conjugating a verb in any language other than their own. If then.

  10. I'll never understand why people usually study a primary discipline with multiple languages. I mean, I get that each language is based on a more appropriate paradigm. But I think learning languages is a secondary thing, that you do based on your needs. You just have to understand in first place what means object oriented, functional, logic and procedural programming, not the languages themselves. That's why I teach Programming Paradigms in Python, which is "multi-paradigm" and easy to learn. Logic programming is the only paradigm we approach with other language, PROLOG.

  11. I like the idea of this talk. However, some of the examples given.. are not exactly tied to the paradigm under topic, but an implementation detail of a specific language.

  12. If you like exploring different languages, the two old ones i recommend for consideration are APL and SNOBOL.

    You might also look into Icon, which is an outgrowth of SNOBOL, applying its pattern-matching powers to a more standard "c" style syntax.

    Both are essentially procedural languages, but both have unique syntaxes.

    APL has its own character set, which is used to produce the most terse programming possible. The end notion is to reduce an entire program onto a single line. It is designed to be interactive (from an era when that was rare) and is strongly oriented towards mathematical operations. For example, you can perform a matrix inversion (where possible) using a SINGLE CHARACTER PRIMITIVE.

    SNOBOL is just slightly less exotic, with a unique sytax for statements:
    <label:> <subject> <pattern> <=> <object> <branch>

    That is up to 5 optional components to each language, with string processing the primary functional purpose.
    Label == duh. A unique label for the statement
    Subject == the target string/variable
    Pattern == a pattern to match the subject against, with an incredibly powerful set of primatives
    = is if you wish to do a replacement of matched text
    Object is what you want to replace the matched text with
    Branch == EACH statement can make a branch operation to a label, either an absolute branch, or, a conditional branch based on whether the action — either the pattern match or the replacement operation — succeeded or failed.

    You can define functions/procedures.

    If you know what a BNF grammar is, it is possible using snobol to directly implement any BNF grammar for that system almost without any coding.

    SNOBOL is also massively recursive. In general, most procedures are designed to perform operations in a highly recursive manner.

    My own class project for the course in this language (yes, ancient history in computer terns) was to symbolically differentiate an function containing standard math, trig, inverse trig, a^b, exponentials, and natural logs, and ANY level of nesting.

  13. My biggest takeaway is I need to avoid languages where the number of brackets required for the most basic thing exceeds the number of fingers I have 😅

  14. ok, kids

    this is good talk. But a bit misleading.

    It's not important how you write your functions/methods – smallest pieces of code. Important – how you combine them in bigger modules.

  15. It's all cool and shit with Prolog, until you have to build an enterprise app with it. It'll be like trying to edit a text document purely using regex. 😆

Leave a Reply

Your email address will not be published. Required fields are marked *