• s

    srini

    3 years ago
    personal computing or personal programming vs professional programming seems like a neat dichotomy (still a spectrum in reality though)
    s
    1 replies
    Copy to Clipboard
  • shalabh

    shalabh

    3 years ago
    The interesting aspect here is how sharing happens. What are the artifacts you produce, how are they published, located, acquired, integrated etc? In a shared-first approach this is built-in to the system. Like a persistent world multiplayer game, you create stuff in a shared virtual word that easily visible to others, and available for reuse and remixing. In an individual-first, this not a big concern because existing sharing methods may be deemed sufficient and are outside the system itself (copy files around, push to git etc.) I think the single shared world idea affects fundamental design decisions around composition methods. For instance, copying code files that need to be compiled into libraries does not seem the same as linking to a web page. The web is halfway there. It's a shared world where any published page has a URL and can be linked to. However the links are unstable and only jump links are available (no other forms of composition) and local development is outside the system. Projects like Unison and the Object Network are attempting to get there, it seems. Both have the notion of a 'global id' to locate an element. Fluid is similar too, I think? An earlier related idea from Joe Armstrong (Why do we need modules at all?) is
    I am thinking more and more that if would be nice to have *all* functions in
    a key_value database with unique names.
    shalabh
    Brian Hempel
    +5
    15 replies
    Copy to Clipboard
  • d

    Doug Moen

    3 years ago
    Types of collaboration: 1. Publish your code. Other people (who you may not know) can discover your code, reuse it, remix it. Centralized version: github public repository. Decentralized version: IPFS, plus a discovery mechanism. 2. Share your code with members of your team (but don't share it outside your team). Centralized: github private repository. Less centralized: Run your own git server, with authentication and a user account for each team member. Decentralized: Each team member has their own git repository, shares patches with other team members. 3. Real time collaboration. Several people editing the same code base at the same time. Centralized: The true version of the code exists on a central server. Decentralized: Each person has their own copy of the code, and a peer to peer protocol keeps them in sync. 4. Collaborative live coding. Several people editing the same code base while the program is running. Or, in a video/music performance, outputs of one live coding session are taken as inputs to another live coding session, in real time.
    d
    Kartik Agaram
    +3
    16 replies
    Copy to Clipboard
  • Duncan Cragg

    Duncan Cragg

    3 years ago
    For EUP, the "Programmer" circle needs to be rewritten and the "Programming Language" box moved directly on top of it. Back in the 80s I called that a "Domain and Target Independent Language".
    Duncan Cragg
    Brian Hempel
    +1
    3 replies
    Copy to Clipboard
  • ogadaki

    ogadaki

    3 years ago
    @Konrad Hinsen says:
    End users would thus be seen as life-long learners who advance at their own rhythm, possibly never going all the way to professional.
    I totally agree with that. And maybe it is not easy to set the frontier on this scale "end-user <-> professionnal". I guess sometime some end-user progrmmers can be more efficient than professionnal ones. Example: I guess I can be considered as a professionnal programmer, but I am sure that there are plenty of end-user programmers that master Excel a lot more than me (side note for me: I guess I have to dig into Excel programming a bit more, for my general culture... 🙂 ).
    ogadaki
    Konrad Hinsen
    +1
    14 replies
    Copy to Clipboard
  • Kartik Agaram

    Kartik Agaram

    3 years ago
    I don't think "professional" is some sort of goal to strive for. The existence of professional programmers today is a sign of how immature our software/society is. The ultimate goal of EUP is to replace this priesthood. Along the way we definitely have to make choices about the sequence in which a new stack and methodology eats the universe of use cases.
    Kartik Agaram
    Ilari Kajaste
    +3
    10 replies
    Copy to Clipboard
  • jonathoda

    jonathoda

    3 years ago
    jonathoda
    Duncan Cragg
    +3
    6 replies
    Copy to Clipboard
  • s

    srini

    3 years ago
  • crabl

    crabl

    2 years ago
    there's a lot of research and activity going on around programming environments for users who have never been exposed to software development before (Scratch, Logo, etc.) but are there any good environments out there for people who are motivated enough to start building software on their own to solve problems (people who, given the time, would absolutely put in the effort to learn a programming language, but who haven't invested the time yet)? i'm thinking about those users who are "just dangerous enough" with a computer to know that they can use it as a higher-level tool than just a word processor or internet browser. i'm thinking of something like a scripting language (applescript?) or environment (ios shortcuts/automator, i guess excel can be included here too). is this niche under-served? are the tools not powerful enough? not easy enough to understand? riddled with incidental complexity? is the resulting software not easy enough to share?
    crabl
    Ilari Kajaste
    +4
    12 replies
    Copy to Clipboard
  • Duncan Cragg

    Duncan Cragg

    2 years ago
    Interesting list of end-user groups to aim our products at: https://www.inkandswitch.com/archive/rdlab-concept-sketch.pdf - bioinformaticians - architects - financial analysts - archeology / GIS - industrial design / CAD - data scientists - web designers I know that @jonathoda is considering scientists as his target userbase.
    Duncan Cragg
    1 replies
    Copy to Clipboard