7 ms·

Couldn't agree more. I think we should redesign programming so that it is primarily a method of communicating between humans. If that becomes the focus, we can

by Glench 6y ago

Couldn't agree more. I think we should redesign programming so that it is primarily a method of communicating between humans. If that becomes the focus, we can use the best methods we have of communicating words, graphics, and interactivity to explain complex systems. One of my own projects in this area is a prototype where I made the best possible explanation of a JavaScript library I could: https://glench.github.io/fuzzyset.js/ui/ https://glench.github.io/fuzzyset.js/ui/

abacadaba 6y ago
ah perfect i was just about to implement cosine similarity in js :)
elviejo 6y ago
I also agree... and Gerald Sussman also agree with: "programs should be done for humans to understand, and incidentally for computers to execute." and also Knuth agreed, and that is why he invented literate programming. But why literate programming isn't more popular is beyond me.
- amelius 6y ago
  > "programs should be done for humans to understand, and incidentally for computers to execute." And shareholders to make money.
- brlewis 6y ago
  > why literate programming isn't more popular is beyond me I saw this topic brought up in a video I was watching yesterday https://youtu.be/SzA2YODtgK4?t=1519 https://youtu.be/SzA2YODtgK4?t=1519 There are 2 reasons: 1. Programmers and code review tools are not very good at making sure comments and documentation are updated when code is. 2. People see literate programming as primarily for documentation-focused or teaching purposes. The statistics in the article we're commenting on suggest that more software systems should be documentation/teaching focused, since the "learning the system" phase is where most of the time goes.
  - imtringued 6y ago
    I will admit that I am in group 2. I always saw it as something exclusively used for teaching. I have a project that I basically abandoned because of a lack of free time and there is little hope that my friend will understand the code base without my help. If literate programming can help with that project I'll be sold on it.
  - vanderZwan 6y ago
    > 2. People see literate programming as primarily for documentation-focused or teaching purposes. I agree. Specifically, it's for teaching my future forgetful self what the hell this bit of code is supposed to do. Especially if waterbed theory appears to apply and it's inherently a juggling act of interlocked complex systems.
- JoeAltmaier 6y ago
  Does that help you understand the code in front of you? Because the root issue is understanding the whole system, not individual codes.
- bmitc 6y ago
  Do you have a reference for where Sussman said or wrote that? I just want to know where it is so I can refer to it.
  - asdftemp 6y ago
    https://mitpress.mit.edu/sites/default/files/sicp/full-text/sicp/book/node3.html https://mitpress.mit.edu/sites/default/files/sicp/full-text/...
- tudorgirba 6y ago
  >But why literate programming isn't more popular is beyond me. One issue with literate programming is that it advertised a single narrative for code. Only code is data, and there are always many narratives about data. This change might look cosmetic, but it is actually fundamental. In Glamorous Toolkit, beside having multiple views, we also embedded an interactive notebook right in the development environment and through it we tell interactive stories about the inside the system.
eliot_miranda 6y ago
That programs should be for communicating between humans is one of the core design tenets of Smalltalk. For example, just look at the number syntax. No cryptic conventions for non-decimal bases; simply write BASErNUMBER, eg 11rA9, 36rZ. Humanism pervades the entire system. Read the introduction and first chapter of Smalltalk-80: the Language and its Implementation (available online). It’s no accident the the Glamorous Toolkit has been implemented in Smalltalk; it is part of the flow of Smalltalk culture. Instead of slumming of trying to make JavaScript, a truly awful language for humans with the most contradictory base library I know of, faults beautifully demonstrated in several presentations, try using an open source Smalltalk, Squeak, Pharo and indeed GT itself.
- Glench 6y ago
  Hey! You should look at my thing! The techniques in it have nothing to do with JavaScript and could easily be done in a smalltalk or any language :)
kitd 6y ago
I think we should redesign programming so that it is primarily a method of communicating between humans. Agreed. I think it was Fred Brooks who argued that the number of bugs in a system correlates with the number of lines of communication between the coders of the system. And that number grows exponentially as you add coders. Fixing the communication has the most immediate impact on bug count.
- auggierose 6y ago
  English is pretty good for communication between humans. Obviously, your method of communication needs to adapt to the subject at hand. Talking about a website design certainly seems substantially different enough than talking about web assembly concurrency semantics to warrant different modifications of English.
SaltyBackendGuy 6y ago
Just wanna say thanks for this library (fuzzyset). It's great and was easy to implement / test against.
- Glench 6y ago
  Glad you like it!

by Glench 6y ago

abacadaba 6y ago

ah perfect i was just about to implement cosine similarity in js :)

elviejo 6y ago

I also agree... and Gerald Sussman also agree with: "programs should be done for humans to understand, and incidentally for computers to execute." and also Knuth agreed, and that is why he invented literate programming. But why literate programming isn't more popular is beyond me.

amelius 6y ago
> "programs should be done for humans to understand, and incidentally for computers to execute." And shareholders to make money.
brlewis 6y ago
> why literate programming isn't more popular is beyond me I saw this topic brought up in a video I was watching yesterday https://youtu.be/SzA2YODtgK4?t=1519 https://youtu.be/SzA2YODtgK4?t=1519 There are 2 reasons: 1. Programmers and code review tools are not very good at making sure comments and documentation are updated when code is. 2. People see literate programming as primarily for documentation-focused or teaching purposes. The statistics in the article we're commenting on suggest that more software systems should be documentation/teaching focused, since the "learning the system" phase is where most of the time goes.
- imtringued 6y ago
  I will admit that I am in group 2. I always saw it as something exclusively used for teaching. I have a project that I basically abandoned because of a lack of free time and there is little hope that my friend will understand the code base without my help. If literate programming can help with that project I'll be sold on it.
- vanderZwan 6y ago
  > 2. People see literate programming as primarily for documentation-focused or teaching purposes. I agree. Specifically, it's for teaching my future forgetful self what the hell this bit of code is supposed to do. Especially if waterbed theory appears to apply and it's inherently a juggling act of interlocked complex systems.
JoeAltmaier 6y ago
Does that help you understand the code in front of you? Because the root issue is understanding the whole system, not individual codes.
bmitc 6y ago
Do you have a reference for where Sussman said or wrote that? I just want to know where it is so I can refer to it.
- asdftemp 6y ago
  https://mitpress.mit.edu/sites/default/files/sicp/full-text/sicp/book/node3.html https://mitpress.mit.edu/sites/default/files/sicp/full-text/...
tudorgirba 6y ago
>But why literate programming isn't more popular is beyond me. One issue with literate programming is that it advertised a single narrative for code. Only code is data, and there are always many narratives about data. This change might look cosmetic, but it is actually fundamental. In Glamorous Toolkit, beside having multiple views, we also embedded an interactive notebook right in the development environment and through it we tell interactive stories about the inside the system.

eliot_miranda 6y ago

That programs should be for communicating between humans is one of the core design tenets of Smalltalk. For example, just look at the number syntax. No cryptic conventions for non-decimal bases; simply write BASErNUMBER, eg 11rA9, 36rZ. Humanism pervades the entire system. Read the introduction and first chapter of Smalltalk-80: the Language and its Implementation (available online). It’s no accident the the Glamorous Toolkit has been implemented in Smalltalk; it is part of the flow of Smalltalk culture. Instead of slumming of trying to make JavaScript, a truly awful language for humans with the most contradictory base library I know of, faults beautifully demonstrated in several presentations, try using an open source Smalltalk, Squeak, Pharo and indeed GT itself.

Glench 6y ago
Hey! You should look at my thing! The techniques in it have nothing to do with JavaScript and could easily be done in a smalltalk or any language :)

kitd 6y ago

I think we should redesign programming so that it is primarily a method of communicating between humans. Agreed. I think it was Fred Brooks who argued that the number of bugs in a system correlates with the number of lines of communication between the coders of the system. And that number grows exponentially as you add coders. Fixing the communication has the most immediate impact on bug count.

auggierose 6y ago
English is pretty good for communication between humans. Obviously, your method of communication needs to adapt to the subject at hand. Talking about a website design certainly seems substantially different enough than talking about web assembly concurrency semantics to warrant different modifications of English.

SaltyBackendGuy 6y ago

Just wanna say thanks for this library (fuzzyset). It's great and was easy to implement / test against.

Glench 6y ago
Glad you like it!