Unsplash

Larry Tesler – copy/paste-ophavsmanden, er død

Larry Tesler, der var ophavsmand bag funktionerne “klip”, “kopier”, “indsæt”, “søg og erstat”, er død, 74 år gammel.

Larrys død blev blandt andet markeret af Xerox, hvor Larry arbejdede i en periode i 70erne, inden han blev headhuntet af Steve Jobs til Apple – hvor han arbejdede i 17 år.

Der har været mange forskellige implementationer af cut/copy-paste, lige fra IBM / Microsoft’s tidligere Shift+Del, Ctrl+Insert, Shift+Insert , til Apples stadig brugte Cmd+x/c/v over til den nok mest brugte Ctrl+x/c/v – alle grundlag for store tidsbesparelser, minimering af fejl og ikke mindst forum tråde.





Gå til bund
Gravatar

#1 larsp 21. feb. 2020 09:31

One of Mr Tesler's firmest beliefs was that computer systems should stop using "modes", which were common in software design at the time.

Yup. Tag den, vi!
Stop using Google all the time: https://justsearchportal.com - Without distractions - Respecting privacy
Gravatar

#2 DStruct 21. feb. 2020 09:33

One of Mr Tesler's firmest beliefs was that computer systems should stop using "modes", which were common in software design at the time.

Yup. Tag den, vi!
Buy land. They've stopped making it
Gravatar

#3 fastwrite_1 21. feb. 2020 20:52

Ærgreligt at man ikke kan kopiere sit liv fra omkring 30'erne og indsætte det igen når man nærmer sig de 80, så man igen er 30.

Hans mission var at gøre det nemmere at bruge computer - ret vildt at en funktion han indførte dengang stadig bliver brugt... brugt... brugt...
Gravatar

#4 brostenen 22. feb. 2020 10:16

Well... Ingen lever evigt.
Min blog: http://to9xct.blogspot.com

001100 010010 011110 100001 101101 110011

Glad og tilfreds Linux desktop bruger.
Gravatar

#5 dugfrisk 22. feb. 2020 16:02

lego keyboard.
Dewayne "Lee" Johnson
Queensland cotton farms

Gravatar

#6 larsp 23. feb. 2020 10:09

#2 det var vist copy paste ;)
Stop using Google all the time: https://justsearchportal.com - Without distractions - Respecting privacy
Gravatar

#7 nwinther 27. feb. 2020 14:56

Copy/Paste er vel en af de største effektiviseringer i verdenshistorien?

Den koster INTET og den forbedrer effektivitet og produktivitet (potentielt) eksponentiel.
Gravatar

#8 Daldorph 28. feb. 2020 10:24

"alle grundlag for store tidsbesparelser, minimering af fejl" men også grundlag for mange fejl. Det er i hvert fald sådan jeg oplever det i forbindelse med systemudvikling.
Gravatar

#9 larsp 28. feb. 2020 10:42

Det er en skam at copy-append ikke er slået an og er mere udbredt. Jeg brugte engang en tekst-editor med den funktion. Hvis man vælger copy-append (Ctrl+Shift+C var det vist) erstatter den markerede tekst ikke clipboard, men bliver lagt til. Ekstremt brugbart.
Stop using Google all the time: https://justsearchportal.com - Without distractions - Respecting privacy
Gravatar

#10 arne_v 28. feb. 2020 17:43

#9

I jEdit er det CTRL+E CTRL+A.

The greater danger for most of us lies not in setting our aim too high and falling short; but in setting our aim too low, and achieving our mark.
Gravatar

#11 arne_v 28. feb. 2020 17:48

#8


public int getA() {
return a;
}
public void setA(int a) {
this.a = a;
}


copy paste


public int getA() {
return a;
}
public void setA(int a) {
this.a = a;
}
public int getA() {
return a;
}
public void setA(int a) {
this.a = a;
}


en hurtig redigering mens man snakker med konen i telefonen og forsøger at følge med i diskussionen i den anden ende af rummet


public int getA() {
return a;
}
public void setA(int a) {
this.a = a;
}
public int getB() {
return b;
}
public void setB(int b) {
this.a = b;
}


og man laver naturligvis ikke unit test af så banal kode som getter og setter

Hvorfor f..... virker det ikke????

:-)

The greater danger for most of us lies not in setting our aim too high and falling short; but in setting our aim too low, and achieving our mark.
Gravatar

#12 larsp 1. mar. 2020 18:56

arne_v (11) skrev:
og man laver naturligvis ikke unit test af så banal kode som getter og setter

Hvorfor f..... virker det ikke????

Obviously: :)

public void setB(int b) {
this.a = b;
}

Og godt eksempel på typisk Java bloat med tre kilometer getter og setter der ikke gør noget som helst andet end at risikere at introducere bugs :)

Husk også at designe programmet med klassehierakier for selv de mindst tænkelige koncepter så man sikrer sig at programmet eksploderer i hundredevis af små filer, hvorved den stakkel der skal læse koden ikke har nogen jordisk chance for at overskue hvad der foregår.

Har Java mon ikke også en af de længste minimale Hello World implementationer blandt populære sprog?

Nej, jeg har aldrig været Java fan...
Stop using Google all the time: https://justsearchportal.com - Without distractions - Respecting privacy
Gravatar

#13 CBM 1. mar. 2020 19:00

Cut, copy, paste

https://fricomputer.dk https://retrohardwareheaven.blogspot.com/ #ComeToTheDuckSide www.duckduckgo.com, AMD + ASUS = kvalitet! #BringBackTheKeyboard #JackOn SailfishOS rocks! Stop using Google search.. use https://justsearchportal.com/ instead (includes DuckDuckGo)
Gravatar

#14 Daldorph 2. mar. 2020 11:39

#11 lige præcis... bortset fra at jeg meget sjældent skriver getter og setter i Java :-)
Gravatar

#15 arne_v 2. mar. 2020 16:06

larsp (12) skrev:

Og godt eksempel på typisk Java bloat med tre kilometer getter og setter der ikke gør noget som helst andet end at risikere at introducere bugs :)


De fleste mener vel at det er god OO at indkapsle data adgang.

Nogle sprog (mest midaldrende) bl.a. Java kræver at man skriver to metoder.

Andre sprog (mest nyere) har en nemmere syntaks for det.

Generelt er Java udviklere ikke så glade for at skrive de metoder manuelt, så de vælger en af alternativerne:
* lade IDE autogenerere dem
* lade Lombok autogenerere dem på oversættelsestidspunkt

The greater danger for most of us lies not in setting our aim too high and falling short; but in setting our aim too low, and achieving our mark.
Gravatar

#16 arne_v 2. mar. 2020 16:08

larsp (12) skrev:

Har Java mon ikke også en af de længste minimale Hello World implementationer blandt populære sprog?


Afhænger nok lidt af hvad man kalder minimal og populær. Og af ens formatering.

Men umiddelbart virker det ikke sådan.

Java 5 linier:


public class Dav {
public static void main(String[] args) {
System.out.println("Dav verden");
}
}


C# 9 linier:


using System;

public class Dav
{
public static void Main(string[] args)
{
Console.WriteLine("Dav verden");
}
}


C 7 linier:


#include <stdio.h>

int main()
{
printf("Dav verden\n");
return 0;
}


C++ 9 linier:


#include <iostream>

using namespace std;

int main()
{
cout << "Dav verden" << endl;
return 0;
}


Python 1 linie:


print("Dav verden")


PHP 3 linier:


<?php
echo 'Dav verden';
?>



The greater danger for most of us lies not in setting our aim too high and falling short; but in setting our aim too low, and achieving our mark.
Gravatar

#17 dub 2. mar. 2020 17:21

#16
Brainfuck 1 linje:


++++++++[>++++[>++>+++>+++>+<<<<-]>+>+>->>+[<]<-] Hello World

Cheerleader for videnskab.
Gravatar

#18 arne_v 2. mar. 2020 19:43

#17

Omskriv venligst til at udskrive det samme som mine eksempler.

:-)
The greater danger for most of us lies not in setting our aim too high and falling short; but in setting our aim too low, and achieving our mark.
Gravatar

#19 dub 2. mar. 2020 19:45

#18 Vi ses om 3 år :-)
Cheerleader for videnskab.
Gravatar

#20 arne_v 2. mar. 2020 19:46

larsp (12) skrev:

Husk også at designe programmet med klassehierakier for selv de mindst tænkelige koncepter så man sikrer sig at programmet eksploderer i hundredevis af små filer, hvorved den stakkel der skal læse koden ikke har nogen jordisk chance for at overskue hvad der foregår.


Det er normalt at skrive Java kode med en klasse per fil.

Og det giver mange filer. Eneste andet sprog jeg kan komme i tanke om med en tilsvarende praksis er PHP med auto loader.

Men det er værd at bemærke at det kun er et krav at top level klasser med public visibility skal have sin egen fil.

Det her er helt validt:


package february;

public class Demo {
public static class A {
private int v;
public A(int v) {
this.v = v;
}
@Override
public String toString() {
return String.format("A(%d)", v);
}
}
public static class B {
private int v;
public B(int v) {
this.v = v;
}
@Override
public String toString() {
return String.format("B(%d)", v);
}
}
public static void main(String[] args) {
System.out.println(new A(1));
System.out.println(new B(2));
System.out.println(new C(3));
System.out.println(new D(4));
}
}

class C {
private int v;
public C(int v) {
this.v = v;
}
@Override
public String toString() {
return String.format("C(%d)", v);
}
}

class D {
private int v;
public D(int v) {
this.v = v;
}
@Override
public String toString() {
return String.format("D(%d)", v);
}
}


The greater danger for most of us lies not in setting our aim too high and falling short; but in setting our aim too low, and achieving our mark.
Gravatar

#21 arne_v 2. mar. 2020 19:56

arne_v (20) skrev:

Men det er værd at bemærke at det kun er et krav at top level klasser med public visibility skal have sin egen fil.


Og skal man være helt korrekt, så er ovenstående kun et krav hvis Java kildekoden er gemt i filer.

Java sprogets specifikation nævner eksplicit muligheden af at gemme kildekoden i en database og at reglen naturligvis ikke gælder der.

(sektion 7.2 og 7.6)


The greater danger for most of us lies not in setting our aim too high and falling short; but in setting our aim too low, and achieving our mark.
Gravatar

#22 nwinther 3. mar. 2020 07:35

Daldorph (8) skrev:
"alle grundlag for store tidsbesparelser, minimering af fejl" men også grundlag for mange fejl. Det er i hvert fald sådan jeg oplever det i forbindelse med systemudvikling.


Ja, alle fejl nedarves også, medmindre man er opmærksom.
Men for at det ikke er en fordel, skal du lave mere forkert, end rigtigt.

Og hvis dét er tilfældet, nytter det ikke at undlade at bruge Copy/Paste.
Gravatar

#23 arne_v 3. mar. 2020 19:28

nwinther (22) skrev:
Daldorph (8) skrev:
"alle grundlag for store tidsbesparelser, minimering af fejl" men også grundlag for mange fejl. Det er i hvert fald sådan jeg oplever det i forbindelse med systemudvikling.


Ja, alle fejl nedarves også, medmindre man er opmærksom.
Men for at det ikke er en fordel, skal du lave mere forkert, end rigtigt.

Og hvis dét er tilfældet, nytter det ikke at undlade at bruge Copy/Paste.


Det argument forstår jeg ikke.

Hvis vi siger:

N1 = arbejde på at taste fremfor copy paste
N2 = arbejde ved at finde fejl i copy paste
P = andel af copy paste der er forkert
S = besparelse

så må det gælde at:

S = N1 - P*N2

S < 0
=>
N1 - P*N2 < 0
=>
N1/N2 < P

Hvis N1/N2 er 0.5 så skal man lave mere forkert end halvdelen for at gå i negativ.

Men realistisk set er N2 vel langbt større end N1 så en N1/N2 i 0.005-0.05 er vel mere sandsynligt.


The greater danger for most of us lies not in setting our aim too high and falling short; but in setting our aim too low, and achieving our mark.
Gå til top

Opret dig som bruger i dag

Det er gratis, og du binder dig ikke til noget.

Når du er oprettet som bruger, får du adgang til en lang række af sidens andre muligheder, såsom at udforme siden efter eget ønske og deltage i diskussionerne.

Opret Bruger Login