You are here: SE » ThesesHome » XArbeitNeurofriction1

Traces of accomodating Neurofriction / Spuren des Umgangs mit Neurofriction (Bachelor- oder Masterarbeit)

((This page is incomplete!))

(This page is in English because of potential international collaboration. The thesis can be written in English or German as you prefer.)


Background

Systematic vs. opportunistic approach to APIs

When learning an API for a given purpose, some people will first acquire the necessary API knowledge (systematic approach), while others prefer to use guesses, examples, and experiments (opportunistic approach) [MenSteSch19].

Neurodiversity and Neurofriction

In this context, a Neurodiversity hypothesis might state
  • ND1: some of these behavioral preferences are not mere habits (that could be changed), but result from fixed neurological dispositions and
  • ND2: there are many more such neurological differences that result in peculiar needs, strengths, and preferences [MorBegWie15].

Given Neurodiversity, a hypothesis we will call Neurofriction [Dagstuhl22231] states
  • NF1: most of today's languages, frameworks, libraries, and tools were designed by people prefering the systematic approach, reflect that preference in their design, and thereby put neurodiversely different programmers at a disadvantage. Therefore:
  • NF2: we should learn how such languages, frameworks, libraries, and tools could cater for more diverse audiences and then start doing so.

The Perl/Python Neurofriction conjecture

The programming language Perl appears to be an exception from NF1. The designer of Perl, Larry Wall, is a linguist by background and has often stated flexibility of expression and style to be a design goal. In his 11th "State of the Onion" keynote, he has has even formulated explicitly what is essentially ND1 (in section "passive data, global consistency / active data, local consistency").
"There is more than one way to do it." (TIMTOWTDI) is the inofficial slogan (and even a sort of war cry at times) in the Perl community.
In the early days of dynamic web pages, Perl was the most popular platform for building them. Its popularity has since gone down a lot, but there is still a large and vital Perl community and a huge respository of libraries, CPAN.

Python, on the other hand, another highly popular dynamically typed language, which has a lot in common with Perl in terms of language capabilities, appears to be kind of the opposite: The near-official credo of the Python community, the Zen of Python (PEP 20) states (among other things):
"There should be one -- and preferably only one -- obvious way to do it.".

We conjecture that the Perl platform and community, by contrasting it with Python's, is a good spot for studying what NF2 might look like.

Research idea

  • Pick a number of topics for which there are libraries of similar functionality in Perl and in Python.
  • For each pair of such libraries,
    • study the structure of the API and API documentation and
    • compare the nature of questions asked about them (e.g. in Q&AS forums such as StackOverflow)
    • as well as the nature of the corresponding answers.

If the Perl/Python conjecture is correct, we would expect to see more diverse perspectives and approaches addressed by the Perl community compared to how the Python community acts on similar issues.

The research method by which to make such a comparison systematic and credible is Grounded Theory Methodology (GTM).

Procedural steps

  • Learn and try out the basics of GTM by means of units 4 and 5 of the course Empirical methods in software engineering (this will take about 1 day of highly concentrated work).
  • Pick at least three (better five) pairs of non-trivial libraries where the Perl instance and the Python instance have similar scope (or one includes the other's scope) but not-too-similar APIs for filling that scope. Possible starting points may be the Python standard library, popular libraries on PyPI or CPAN, or popular Perl-related or Python-related tags on StackOverflow.
    • Warning: Instead of APIs, you could also pick frameworks, but the ensuing analysis is likely to become too difficult in that case.
  • Conceptualize these API dissimilarities: The nature of alternative approaches taken, the nature of additional approaches provided beyond the first. Orient your Theoretical Sensitivity towards differences related to NF2.
  • Analyze the API documentation in light of the NF2 hints provided by [MenSteSch19].
  • Look for Q&A pertaining to these (parts of these) APIs. Possible points of attention (directions for Theoretical Sensitivity):
    • Does the asker appear to prefer systematic approach or opportunistic approach? Which indicators suggest that?
    • What (and which) fraction of her problem has the asker already solved?
    • What is the nature of the remainder?
    • Is code provided? How complete (runnable)? How well stripped down?
    • Does the asker appear to be confused by alternative or additional approaches? Or helped by them?
    • Do responses point to documentation? Explain a solution themselves? Provide additional examples? Provide alternative approaches different from the asker's?

Quality criteria

Literature

[Dagstuhl22231] Report on the Dagstuhl seminar 22231 on "Theories of Programming", 2022.

[MenSteSch19] Meng, Steinhardt, Schubert: How Developers Use API Documentation: An Observation Study, Communication Design Quarterly 7(2), 2019.

[MorBegWie15] Morris, Begel, Wiedermann: [[https://doi.org/10.1145/2700648.2809841][Understanding the Challenges Faced by Neurodiverse Software Engineering Employees: Towards a More Inclusive and Productive Technical Workforce], 17th International ACM SIGACCESS Conference on Computers & Accessibility, 2015.