Larry Tesler – copy/paste-ophavsmanden, er død
-
af
_tweak
mboost-dp1
Unsplash
Æ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...
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...
#8
copy paste
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
og man laver naturligvis ikke unit test af så banal kode som getter og setter
Hvorfor f..... virker det ikke????
:-)
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????
:-)
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...
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
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';
?>
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);
}
}
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)
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.
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.
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.
- Forside
- ⟨
- Forum
- ⟨
- Nyheder
Gå til bund