This is the revised transcript of my talk at the OWLTEH Conference 2018 at the Coventry University.

In the beginning there was the LMS

Learning Management Systems appeared on the market around the beginning of 2000.

Since then they have been the foundation of the modern education sector, ranging from the basic functionalities of activity tracking, grades and analytics for the students (and in some cases the parents) to complex environments for remote education or even experimental pedagogies (e.g. FARE that provides hospitalized students means to access the physical class and labs).

In the last five years commercial LMS reduced the pace of their progress, while providing better accessibility and decentralization.

The core of their principle hasn't changed. In this talk I am going to highlight their problems and outline a vision for a different approach that is supported by modern technologies.

The problem of traditional LMS

The design of a Learning Management System is based mainly around closed structures, such as very strict roles management and access management.

In a scenario where a professor might want to bring a domain expert during classes and online, a traditional LMS doesn't provide any kind of facilities for things such a role (in terms of login rights, rights towards other users, moderation capabilities).

There are many corner cases that lack a general method that allows users to expand the features of an LMS, especially when an institution lacks the technical means to bring development to such platforms.

Moreover, traditional LMS are highly gerarchic and foster an epistemology of "possession": learners are defined by the content that they "possess", the course they subscribed to, the material they downloaded. The educator is forced to be an authoritative source of knowledge that needs to direct the activity of the learners by having students pull the knowledge through an online portal. The flow is unidirectional and content centric.

In my experience instructors produce delivery-centered pedagogies because LMS lacks the flexibility to be adapted to learners, especially when they are used by a variety of instructors (e.g.: all of the professors of a UNI). While this model better reflects the traditional classroom I would argue that modern users are not used to this kind of dynamics in modern online communities.

You can learn more about the friction in the usage of traditional LMS in the following papers:

• Rubin, Fernandes, Avgerinou, & Moore, 2010

• Naveh, Tubin, & Pliskin, 2010

• Parry, 2009; Sanchez-Franco, 2010

• Beebe et al., 2010

Hacking Education with Digital Pedagogies

What happens when education gets "hacked" and transitions in the digital world? This is what we envision within the realms of the EduHack project:

• "Content to consume" becomes "content to consume to produce content": learners become knowledge builders because producing intellectual outputs is the logical continuation to learning.

• The environment goes from content centric to learner centric: teachers must be comfortable with the fluidity of such new roles.

• The distribution of information goes from knowledge-push to knowledge-pull: learners actively seek out educational material and gets rewarded.

In the academia the closest study in this direction has been: eLearning 2 0 and new literacies are social practices lagging behind, W.-Y. Lim et al.

What do we gain with OSNs

In the Web 2.0 landscape and in particular for younger generations, Online Social Networks (OSNs) have strong potential for building and mantaining strong connections and create an informal learning environment that collects and puts into actions the ideas that I have described. I wont rehash widely known statistics, but it must be said that nowadays OSNs, in particular Facebook, Youtube and Twitter have a high rate of penetration towards students of upper secondary and post secondary education. For younger students OSNs are their primary means of communication while dominating their usage of the internet overall.

• Using Social Networks Technology to Enhance Learning in Higher Education: a Case Study using Facebook.

• Web-Based Learning Platforms integratins Social Networking for Design Educations at High Schols in China.

• Using online social networking for teaching and learning: Facebook use at the University of Cape Town.

Case studies: Facebook as an alternative LMS

Different case studies analyzed the possible uses of Facebook as a social LMS. The following is a list of the positive and negative results of such studies grouped by User Experience Design (UX), Behavior of the users and Quantitative Participation.

UX

Advantages:

1. Photos and discussions are presented better than traditional LMS.

2. User's walls, private messages and comments are considered just communication tools.

3. Users reported that the technologies used for sharing class related material was familiar.

4. Educators reported that Facebook was useful to answer questions in bulk.

5. Educators reported that given the capabilities above, they saved a lot of time that otherwise would have been spent dealing with class related communications and questions.

Disadvantages:

1. Users where skeptical in writing long essays.

2. Friction when used as a formal learning platform.

3. Private platforms have issues related to accessibilities and language. Communication was done in english even if that wasn't the case before;

4. Facebook doesn't support a wiki system.

5. There are no tools for group management.

6. There are no tools for sending bulk messages and group notifications.

7. No capabilities for deletion and archival of material.

8. No support for common multimedia (such as powerpoint slides or pdf).

9. Maximum characters limit for posts.

Behavior of the users

Advantages:

1. Users reached to older students and befriended them.

2. Users reported that they felt less pressure online.

3. Educators found that boldlier students asked more questions because of absense of face to face shyness.

4. Students help each other in answering questions

5. Six people from prior classes idependently requested to join the group

6. Constant and more accurate feedback for teachers

7. Constant communication for teachers

8. They got to know classmates better

9. In heavily moderated OSNs, few users find disappropriate contents.

10. In a comparison Facebook's discussion were more numerous than Moodle's discussions even when people were not allowed to be friends

Disadvantages:

1. Addiction

2. Students reported difficulties to get used to the new online persona.

3. Miscommunication: many prefer face to face interaction to express views. This maybe because they are used to it in traditional classrooms.

4. Some people say that they don't feel safe on FB (this is even more common when interviewing master students).

5. Some students worry that their personal life could be discovered and misjudged by tutors.

6. Students avoided to befriend educators and lecturers in order to hide their private lives.

7. During the research period, no student befriended the interviewed lecturers.

8. Students did not accept friend requests from lecturers.

Quantitative Participation

Advantages:

1. Overall the students are more responsive to issues and questions raised in classes.

2. There is a higher number of ongoing discussions in any period.

3. Users log to Facebook for class related activities also during vacations (while the university LMS was almost not used).

4. Very active participation: more than 90% of the students used Facebook outside of classes for study related activities.

5. Improved discussion outside of classes.

6. Students post class related material.

7. Creation of many User Generated Content.

There are no relevant reported challenges regarding participation and usage patterns.

Where do we go from here?

I want to highlight some other threats that an OSN such as Facebook poses to the Open Web.

• The issue of privacy: forcing students to use a service that mines and sells their data is unethical.

• Identity pollution: the open web is based on the principle of pseudoanonimity, users should be capable of build a prism of different online identity for different communities and environments.

• Studies report Facebook as more appropriate for younger students, but younger people have higher rates of addiction to OSNs as well.

• Addicted OSNs users have a lower GPA.

• 20% of college students reported being stalked on OSNs.

While the reported results about learners and educators participation in the usage of OSNs as LMS is astounding, forcing students to signup and give away their sensible data to private services is debatable and could be considered unethical.

The EduHack model

We need to develop a new LMS that is respectful of the Open Web standards without providing any friction to the users.

For this reasons, as part of the EduHack Project, we are developing the EduHack Knowledge Sharing Platform.

The EduHack Knowledge Sharing Platform was born around the assumption that many of the advantages in terms of user engagement and group dynamics

provided by OSNs could be replicated by adopting their widely known design patterns and mimicing closely the UX.

At the core of the platform there are the founding principles of the Open Web.

For this reason no data is collected of mined. Users are provided with an account that could be separated from their different online persona.

A platform for collaborative learning

The EduHack Knowledge Sharing Platform is divided into two parts.

The personal area is user centric and provides a window into the activities of the user in the form of multimedia blogposts.

The user can create and manage different roles for external editors to his private area. By default no other user is allowed to post a "story" in his personal area, but other users can be added as team members and can manage group works in different blogs.

Learners are expected to elaborate and remix what they learned (e.g. from online classes or MOOCs).

The public area is modelled after the UX of Reddit and it is divided into diffent sections (e.g.: mathematics, IT, discrete phisics, etc...), each providing a wiki.

Learners can subscribe to different sections or different users and be notified of new content or interactions.

Every user is allowed to post a link, an essay or any other widely adopted multimedia artifact to any section. Every user can positively vote and comment every post made. Comments can be positively voted as well.

Comments and content can be ordered by a custom algorithm (Wilson score interval) or chronologically.

Educators have a custom flair, can create new sections and moderate them. Moderation consists in changing links, removing posts or comments. Vote cannot be altered.

Conclusions

The EduHack Knowledge Sharing Platform is an ongoing effort to evolve LMS and augment them with social features and modern group dynamics.

The UX is modeled after a widely used social network without sacrificing consolidated approaches from traditional LMS.

We want to provide with this model an ethically sound framework for user centric, knowledge-pull pedagogies.

References

• Using online social networking for Teaching and learning: Facebook use at the University of Cape Town, Tanja E Bosch.

• The myths about e-learning in higher education, James Kariuki Njenga and Louis Cyril Henry Fourie

• Group Formation in eLearning-enabled Social Networks, Steffen Brauer and Thomas C. Schmidt

• eLearning 2.0 and new literacies: are social laggin behind, Wei-Ying Lim, Hyo-Jeong So and Seng-Chee Tan

• Using the Facebook group as a learning management system: An exploratory study, Qiyun Wang, Huay Lit Woo, Choon Lang Quek, Yuqin Yang and Mei Liu

• Using Social Networking Technology to Enhance Learning in Higher Education: A Case Study Using Facebook, Peter Ractham and Daniel Firpo

• Students’ and teachers’ use of Facebook, Khe Foon Hew

• The future of e-learning: a shift to knowledge networking and social software, Mohamed Amine Chatti and Matthias Jarke

• Using Facebook as course management software: a case study, Elizabeth M. LaRue

• Electronic Social Media in Teaching: Usages, Benefits, and Barriers as Viewed by Sudanese Faculty Members, Ahmed Yousif Abdelraheem and Abdelrahman Mohammed Ahmed

• The Use of Social Networking in Education: Challenges and Opportunities: Ashraf Jalal Yousef Zaidieh

• Findings on Facebook in higher education: A comparison of college faculty and student uses and perceptions of social networking sites, M.D. Roblyer, Michelle McDaniel, Marsena Webb, James Herman and James Vince Witty e,4

• Online social networks: Why do students use facebook? Christy M.K. Cheung, Pui-Yee Chiu and Matthew K.O. Lee

• e-Learning: The student experience, Jennifer Gilbert, Susan Morton and Jennifer Rowley

Questo articolo è stato originalmente scritto per il blog di r/italyinformatica.

Negli ultimi anni abbiamo assistito all'ascesa di un gran numero di linguaggi di programmazione, in particolare Go (2009), Rust (2010), Kotlin (2011), Elixir (2011), Crystal (2014), Pony (2014).

Questa esplosione di nuovi linguaggi è dovuta, fra le molte motivazioni, alla necessità di adottare paradigmi di programmazione non immediatamente recenti come cittadini di primo tipo.

Rispetto ai più maturi C, C++ o Java, Python o Ruby questi linguaggi offrono "out of the box" supporto per:

• una visione moderna delle concorrenze (le goroutines di Go o il modello ad attori di Pony ed Elixir)
• Memory safeness, in particolare:
  • assenza di NULL (Pony, Rust, Kotlin)
  • gestione automatica della memoria, il cosiddetto [Garbage Collector](https://en.wikipedia.org/wiki/Garbage_collection_(computer_science) (o Reference Counting per Rust)
  • assenza di puntatori
  • assenza di deadlocks
• Supporto ad HTTP nella standard library
• Management delle dipendenze (ad eccezione di Kotlin)
• Namespaces

Chiaramente nessuno di questi linguaggi è oggettivamente superiore agli altri, sono tutti turing completi e la scelta del programmatore ricade su motivazioni del tutto personali (stile, programmazione ad oggetti, familiarità con altri linguaggi).

Un pò di contesto

Ho scritto la mie prime due righe di codice nel 2013 per il corso di Computer Science del Politecnico di Torino.

Per mia fortuna, al Politecnico le cose si muovono ancora lentamente e ci hanno fatto usare C per tutta la durata della triennale. Si è aggiunto un corso di principi della programmazione ad oggetti al terzo anno, in Java.

Personalmente ho imparato durante l'estate di quel primo anno le basi di C++ e Python poco dopo.

Sono stati con i miei primi progetti che ho capito che non si può avere un buon linguaggio senza un buon tooling ed una community vivace e soprattutto tanta, tanta documentazione. Per questo, per molto tempo C è stata la mia prima scelta, dato che il mio target è sempre Linux.

Gli obbiettivi prima del linguaggio

Questo post vuole essere una raccolta più o meno organizzata delle motivazioni per cui mi sono dovuto muovere oltre la frontiera di C nel mio ultimo progetto, ovvero un backend per la raccolta e presentazione di pubblicazione di ricerca e materiale didattico per più di 80 centri di ricerca.

Per il Centro Nexa del Politecnico di Torino mi sono ritrovato per la prima volta responsabile del codice che dovevo scrivere e dell'uso che se ne sarebbe fatto.

Ho dovuto tenere in considerazione, oltre chiaramente alla funzionalità della piattaforma, in ordine di priorità:

1. Sicurezza
2. Performance e scalabilità
3. Separazione dal frontend
4. Facilità di deploy in un server che non controllo

Fortunatamente non mi è stata imposta nessuna limitazione sulla scelta del linguaggio, altrimenti Python sarebbe stato la scelta più adeguata se avessi dovuto tener conto anche di altri programmatori.

Benvenuto D

La mia scelta è caduta su D.

Voglio provare ad affrontare ad uno ad uno i motivi di questa scelta magari inusuale.

Sicurezza

Nessuno vuole davvero vantarsi di usare un backend scritto in C/C++. Il buffer overflow può essere considerato il bug più comune e ci sono situazioni in cui non appaiono affatto in maniera ovvia.

Inoltre per un applicativo distribuito il Garbage Collector è la scelta più performante, specialmente se coordinato fra le varie istanze.

D offre questo di design, e benchè il suo GC sia frutto di numerose discussioni, offre in maniera del tutto innovativa, robustezza e sicurezza.

In particolare, D presenta:

• Array che sono slices (o ranges) ma non puntatori (e neanche oggetti)
• Bound checking durante la fase di compilazione.
• Inizializzazione automatica delle variabili.
• Safe Casting (chiaramente come eredità di C++).
• Restricted pointers: si può passare una funzione per referenza dichiarandola ref, ma solo quando passata come parametro o di ritorno. Inoltre non c'è nessuna pointer arithmetic.
• RAII, ovvero l'acquisizione delle risorse equivale alla loro assegnazione e Scopes: le variabili hanno una lifetime limitata allo scope di dichiarazione. Nessun dangling pointer come in C.
• Strutture immutabili: come nelle specifiche di molti linguaggi funzionali, si può dichiarare una variabile come immutable e quindi può essere facilmente condivisa fra threads.
• @safe, @trusted: le specifiche del linguaggio permettono di annotare delle funzioni come sicure o affidabili affinchè il compilatore controlli che non gestiscano puntatori (ad esempio interfacciandosi con C) ed utilizzino il subset "sicuro" del linguaggio (maggiori dettagli in seguito).
• funzioni pure: le funzioni inoltre possono essere dichiarate pure, prive di effetti collaterali e sempre rientranti. Questo permette di evitare deadlocks e un controllo totale sul risultato delle funzioni.

Performance

Ci sono moltissime soluzioni per scrivere un applicativo che si interfaccia con il web, ma hanno tutte la loro origine nel famoso C10K problem.

Nel mio caso ho deciso di utilizzare un approccio asincrono con coroutines (anche detti threads leggeri).

Benchè D abbia supporto nativo alle coroutines, ho deciso di appoggiarmi al framework più comune per web dev in D: vibe.d.

Ogni volta che Vibe accetta una richiesta dall'esterno ed esegue una funzione bloccante (che interrompe l'esecuzione del programma fino al ritorno della funzione), questa viene messa in una pool di azioni da eseguire e Vibe controlla periodicamente che almeno una di queste sia pronta a ritornare un risultato e continuare con l'esecuzione di questa.

Inoltre, benchè questo meccanismo funzioni interamente su un solo thread, è elementare coordinare una thread pool che distribuisa il carico fra i vari core che eseguono migliaia di threads leggeri concorrentemente.

Contratti e Tests

Non amo scrivere commenti sui programmi. Penso sia assolutamente necessario commentare il codice di librerie ma al di fuori di queste il codice (buon codice) dovrebbe essere autoesplicativo.

Inoltre, nelle mie recenti esperienze, il comportamento del programma era chiaro a partire dai tests.

In D questo concetto viene portato agli estremi applicando il "Design by Contract programming.

Un contratto è la divisione di una funzione in:

• Precondizione, ovvero le condizioni che devono essersi verificate prima della chiamata della funzione;
• Postcondizione, ovvero le condizioni che devono essere rispettate all'uscita della funzione (solitamente applicate al risultato);
• Invarianti, ovvero le specifiche di una struttura dati che devono rimanere verificate in ogni funzione;
• Corpo della funzione

Un esempio:

struct Clock {

    short time;

    invariant {

    assert (time > 0);

    }

}

short addReturnTime(Clock c, short n) 

    in {
        n > 0;

    }

    body {

        return c->time + t;

    }

    out (result){

        result > c->time;

    }

unittest {

    auto clock = Clock(60);

    assert (addReturnTime(clock, 10) == 70);

}

Come si nota dall'esempio il supporto ai tests è built-in nel linguaggio e distanti solo una flag in fase di compilazione.

Un approccio moderno alle concorrenze

Il modello primitivo delle concorrenze in Posix è discutibilmente datato e prono ad errori per il programmatore.

D di default evita la condivisione di dati fra Threads. Fra le varie motivazioni c'è il fatto che questo rifletta più realisticamente l'hardware, ma sicuramente l'obbiettivo finale è la riduzione di bug.

Non voglio dilungarmi nei dettagli di ogni singolo approccio, ma per completezza D offre out of the box i seguenti modelli:

• Message passing e attori, ovvero tutti i dati che vogliono essere condivisi fra thread sono incapsulati in RPC;
• Green threads, come nel mio caso;
• Multi processing, ovvero man 3 fork
• TaskPools, ovvero future e promises di Python e Javascript;
• SIMD vectorization

Andrei Alexandrescu, uno dei due creatori del linguaggio, dedica un intero capitolo alle concorrenze che potete leggere liberamente qui.

Assenza di dogmatismi

Non potrei mai pensare di scrivere un linguaggio di programmazione senza mettere al secondo posto la semplicità.

Ma chiaramente ancora prima di discutere di semplicità la dobbiamo definire.

Go e Python sono due linguaggi semplici. Lo sono per la ridotta sintassi (Go in particolare) e perchè attraverso il loro dogmatismo costringono il programmatore ad adottare dei paradigmi di programmazione scelti dai designer di quel linguaggio. E` il motivo per cui in python non abbiamo delle vere lambda e per cui Go non ha le eccezioni.

In D il programmatore ha libertà piena di scelta. Oltre ad un paradigma di programmazione si può ridefinire la sintassi e evitare il Garbage Collector. Si può in ultimo disattivare tutte le feature del linguaggio che sono @safe e adottare uno stile molto più vicino al C/C++, con tanto di inline asm.

Dove iniziare

Non posso non concludere un post propagandistico senza indirizzare i più interessati alle prime risorse per imparare D.

Personalmente consiglio il libro di Andrei che offre in particolare moltissimi dettagli sulle motivazioni del design di D. Non ho ancora letto un libro che affrontasse così chiaramente il design di linguaggi di programmazione e i vari compromessi fra performance, semplicità e complessità del compilatore.

Inoltre il sito della community offre due intro per chi proviene da C e C++, oltre al classi tour.

Inoltre la libreria standard, Phobos, è talmente chiara che solitamente mi trovo a mio agio a consultare direttamente il codice piuttosto che la documentazione online.

It is also common ground, however, that the First Amendment does not guarantee the right to communicate one's views at all times and places or in any manner that may be desired.

Tempo fa rimasi colpito nel leggere questo orientamento della corte degli Stati Uniti dal quale ho tratto la precedente citazione.

La libertà di espressione è un diritto molto potente che ha storicamente molteplici interpretazioni. Benchè ingenuamente potrebbe essere inteso come la possibilità di manifestare qualsiasi idea, ci sono delle situazioni in cui si deve intendere come il diritto di un individuo minoritario nel poter esprimersi liberamente e senza ritorsioni.

Con questa premessa posso inquadrare più facilmente il motivo per cui ritengo che il ban del 2015 da parte degli amministratori di Reddit nei confronti di /r/FatPeopleHate e altri subreddit di minor dimensioni non sia stata un'azione ipocrita rispetto agli ideali della piattaforma.

Angela Nagle ci ricorda che quegli spazi online senza leader roccaforte di ideali minoritari di sinistra, hanno permesso di esprimere non un'idea, ma qualsiasi idea, anche di estrema destra. Diventa quindi inevitabile che una piattaforma delle dimensioni di Reddit, che nello specifico raccoglie una moltitudine di argomenti e discussioni grazie ai quali è stata ritenuta un bastione della eterogeneità, prima o poi debba adottare una linea di moderazione più definita.

Il recente ban invece non riguarda la libertà di espressione, e mi colpisce personalmente, nonostante io non abbia mai visitato alcuno dei subreddit recentementi banditi e le mie uniche transazioni si siano limitate agli utenti di r/MechanicalKeyboards.

Sono approdato a Reddit inizialmente a causa del mio hobby per le tastiere meccaniche. Da lì mi sono mosso verso r/italy e altri subreddit di indirizzo informatico. Ho interessi di nicchia e Reddit mi permetteva di riunirmi con persone dall'altra parte del globo che mi fornivano informazioni che non avrei potuto ottenere altrimenti.

Ora questo rimane valido solo per le persone i quali interessi sono allineati con quelle comunità che riflettono una buona immagine per Reddit e gli investitori. Benchè i miei subreddit di riferimento non siano stati banditi, riconosco che nel recente ban ci sono degli intenti politici o misteriosamente economici.

Con questo post dico addio a Reddit. Da spazio di discussione a spazio di intolleranza e divisione politica, dove delle comunità che non rientrano nei canoni di buona reputazione per delle agenzie pubblicitarie devono essere eliminate.

Non voglio che ogni mia parola sia pesata oltre i valori della comunità a cui sottoscrivo, non voglio fare esercizi di autocensura nei post che scrivo.

Aderivo a delle regole ben definite e delle quali gli amministratori si assumevano la responsabilità. Con il ban di marzo 2018 il sito che conoscevo ha cambiato faccia ed il post di un utente anonimo sarà l'ultimo post che downvoterò.