Wat is de meerwaarde van XS4ALL over KPN nu nog?

[Ruud Uphoff]

Produkt XS4ALL KPN
=====================================================
Internet 200/20 64,- 50,-
Interactieve TV van KPN 15,- 10,- TV Basis
Extra TV ontvanger 2,50 5,-
FRITZ!Box 0,0 7,49
Spotify Premium 0,0 9,99
Vast bellen 5,- 2,-
TV Pluspakket 0,0 0,0 Compleet korting
1 GB Mobiel internet 0,0 5,- *)
=====================================================
Totaal tot hier 86,50 89,48
KPN Entertainment korting 0,0 -5,0 **)
=====================================================
Slotsom 86,50 84,48

*) Bij KPN apart contract. (met hussel korting)
Ik heb een mobiel abo: Onbeperkt bellen, data en SMS. Daarvan mag je
maandelijks 50GB uitdelen aan huisgenoten. Delen naar Mobiel internet is
niet mogelijk bij XS4ALL, maar wel bij KPN. Ik heb dus meer performance,
voor twee euro minder.
**) Korting op het eerste entertainmentpakket. In dit geval Spotify.

Waarom dus nog bij dit pseudo XS4ALL blijven hangen? Er is hier een
heleboel zogenaamd gratis, maar dat betaal je dik in Internet en TV

--
Met vr. gr,
Ruud Uphoff

[Dirk T. Verbeek]

Op 13-05-2022 om 16:15 schreef Ruud Uphoff:

Tot nu toe steun je via xs4all ook nog Bits of Freedom.

[Peter X1]

Hmmmm

"Het merk XS4ALL houdt op te bestaan, zo wil KPN. Met die naam verdwijnt
ook een provider die opkwam voor vrijheid op internet."

Sowieso kun je beter rechtstreeks steunen. Mensen die lid zijn van een
commerciële club of flink geld vergokken onder het mom dat ze goede
doelen steunen,l draaien vooral zichzelf een rad voor ogen.

[Dirk T. Verbeek]

Op 13-05-2022 om 21:35 schreef Peter X1:

Zeker, het xs4all 'lidmaatschap' van Bits of Freedom zal vast wel met
een korting bedongen zijn.
Toch brengt het het onderwerp in een grotere kring onder de aandacht.

Een ander plusje van xs4all kan zijn dat je toegang tot de news server
dankzij het werk van Mike beter geanonimiseerd zal zijn, of datzelfde
systeem ook voor KNP klanten gebruikt wordt weet ik niet.

[Rob]

Dirk T. Verbeek <di...@example.com> wrote:
> Een ander plusje van xs4all kan zijn dat je toegang tot de news server
> dankzij het werk van Mike beter geanonimiseerd zal zijn, of datzelfde
> systeem ook voor KNP klanten gebruikt wordt weet ik niet.

Toegang geanonimiseerd? Ze weten van elke gebruiker toch precies
van welk abonnement die komt? En die proxy die met usernaam werkt
die is ook maar tijdelijk, straks kun je er alleen nog op basis van
IP adres in.

[Izak van Langevelde]

On 14/05/2022 10:55, Dirk T. Verbeek wrote:
> Een ander plusje van xs4all kan zijn dat je toegang tot de news server
> dankzij het werk van Mike beter geanonimiseerd zal zijn, of datzelfde
> systeem ook voor KNP klanten gebruikt wordt weet ik niet.

Alleen voor mensen met een kpn aansluiting, klanten met een pack kunnen
helemaal niet meer bij de news server, da's dan weer een dikke min...

--
Grinnikend door het leven...

[Dirk T. Verbeek]

Op 14-05-2022 om 10:58 schreef Rob:

KPN weet het, de provider van de server moet er eerst bij hun om vragen.

[Gerard Dou]

De 'meerwaarde' voor mij is behoud van een aantal @xs4all.nl emailadressen.
En gemakzucht :)

groet, Ger

[Dirk T. Verbeek]

Op 18-05-2022 om 11:27 schreef Gerard Dou:

> De 'meerwaarde' voor mij is behoud van een aantal @xs4all.nl emailadressen.
> En gemakzucht :)

Inderdaad heel belangrijk.

[richard lucassen]

On Wed, 18 May 2022 13:23:21 +0200

"Dirk T. Verbeek" <di...@example.com> wrote:

Daarom krijg je bij Freedom je eigen domein, dan ben je af van die
vendor lock-in.


--
richard lucassen
http://contact.xaq.nl/

[Richard Zuidhof]

Op vrijdag 13 mei 2022 om 16:15:51 UTC+2 schreef Ruud Uphoff:
> Produkt XS4ALL KPN

> FRITZ!Box 0,0 7,49

Ik merkte dat je 50% korting krijgt op de Fritzbox als je na de migratie overstapt van XS4ALL op KPN Hussel.
Best redelijk aangezien die 7,49 eigenlijk een combinatie van Fritzbox en extra helpdesk is.
--
Groet,

Richard

[A_Alias]

Op 18-5-2022 om 17:02 schreef Richard Zuidhof:

Tja freedom laat je een fritz kopen via hun voor 150 euro bij hun levert
het maar 2 euro per maand korting op om eigen modem te hebben.
(ben je dik 6jaar verder voordat je echt voordel heb)

maar naar KPN maatstaven heb je binnen 2 jaar je fritz bij hun al trug
betaald (elders kost een losse 7590 om en nabij 200)

wat zijn de voordelen van hussel ??

omdat de IPv6 het niet deed op mn 7360 heb ik nu een 7590.

en als ik een vrije modem keuze doe ... koop ik liever een 6890 die kan
een 4G Sim erin hebben met buiten antenne.
(heeft ook een WAN poort voor glas als dat er in de toekomst komt dat
zou er tien jaar terug al van komen maar kwam hiet nog niet verder als
fiber toe the curve)

want de oude 3G dongel van XS4all doet bar wijnig met een 5G/4G/2G Sim
van de KPN ... 0.17down/0.1up Mbit omdat hij via 2G verbint

[Ruud Uphoff]

On 18-05-22 11:27, Gerard Dou wrote:

>
> De 'meerwaarde' voor mij is behoud van een aantal @xs4all.nl emailadressen.
> En gemakzucht :)

Sja.. Arme kerel, als zovelen gegijzeld door een ISP.

Op https://joker.com neem je voor een prikkie een eigen domain.

[Ruud Uphoff]

Ja, en met die helpdesk heb ik ook al kennis gemaakt. "De wachttijd
bedraagt momenteel minder dan 1 minuut".

Zo overdreven hoeft nou ook weer niet. :-)

[Ruud Uphoff]

On 18-05-22 23:26, A_Alias wrote:

> en als ik een vrije modem keuze doe ... koop ik liever een 6890 die kan
> een 4G Sim erin hebben met buiten antenne.
> (heeft ook een WAN poort voor glas als dat er in de toekomst komt dat
> zou er tien jaar terug al van komen maar kwam hiet nog niet verder als
> fiber toe the curve)

Dat is een geweldig product, overigens in vergelijking met de andere
FRITZ-en knap duur. Maar ok, dan heb je ook wat.

[Rob]

Blijft wel een Fritzbox natuurlijk. Leuke router voor een gezinnetje
thuis, maar als je ook maar iets meer wilt met netwerken dan houdt
het al gauw op.

[A_Alias]

Op 19-5-2022 om 10:45 schreef Ruud Uphoff:

had je het zeker op een druk moment gedaan :)

mijn laatste telefoon werd direct beantwoord .. na dat je de keuze moest
maken of je al over was op kpn netwerk en ik de relatie code
(tegenwoordig klant NR) met * had weg gedrukt.

gelijk een medewerker aan de lijn .. ik schrok me rot ...nu all ....
krijg ik niet eens de tijd om eerst even koffie te zetten en in te
schenken ........

[Honderd 55]

Op donderdag 19 mei 2022 om 10:42:24 UTC+2 schreef Ruud Uphoff:

> On 18-05-22 11:27, Gerard Dou wrote:
>
> >
> > De 'meerwaarde' voor mij is behoud van een aantal @xs4all.nl emailadressen.
> > En gemakzucht :)

Tsja,
Ik stap ook maar over op een andere provider, vanwege die gemakzucht zet ik mijn abbo om in email only.
Alle meerwaarde die ik bij XS vond id nu weg, er is geen binding meer.

[Gerard Dou]

Zo zit ik ook nog steeds bij de postgiro

groet, Ger

[richard lucassen]

On Thu, 19 May 2022 20:51:05 +0200
Gerard Dou <gd...@xs4all.nl> wrote:

> Zo zit ik ook nog steeds bij de postgiro

Heb je al ponskaarten?

[-eggie-]

Op donderdag 19 mei 2022 om 21:00:14 UTC+2 schreef richard lucassen:

... en mijn Rijkspostspaarbank hier ter plaatse verhuist binnenkort naar een splinternieuw kantoor met een dubbel aantal loketten .....;-)

[-eggie-]

Op vrijdag 20 mei 2022 om 07:16:27 UTC+2 schreef -eggie-:

Alle gekheid op een stokje, ik denk dat de meerwaarde van de 'nieuwe' XS4ALL nagenoeg nul zal zijn. Ga na mijn omzetting, deze wacht ik rustig af, alles maar eens plussen en minnen en zien of ik blijf of niet. Gr. -eggie-

[richard lucassen]

On Thu, 19 May 2022 22:21:26 -0700 (PDT)
-eggie- <egbert.m...@gmail.com> wrote:

> Alle gekheid op een stokje, ik denk dat de meerwaarde van de 'nieuwe'
> XS4ALL nagenoeg nul zal zijn. Ga na mijn omzetting, deze wacht ik
> rustig af, alles maar eens plussen en minnen en zien of ik blijf of
> niet. Gr. -eggie-

Ik was al vroeg weg, men liegt en draait, vertelt de halve waarheid en
daar hou ik niet van. Dan maar wat duurder. En dan ben ik nog iemand
die echt alleen maar een lijn nodig heeft. Xs4all is compleet
weggevaagd want het gaat alleen maar om geld en nergens anders over.
Zoals gebruikelijk helaas. Dus als je gaat plussen en minnen, begin eens
bij min honderd.

[Joe]

On Thu, 19 May 2022 21:00:12 +0200, richard lucassen <mailin...@lucassen.org> wrote:

>On Thu, 19 May 2022 20:51:05 +0200
>Gerard Dou <gd...@xs4all.nl> wrote:
>
>> Zo zit ik ook nog steeds bij de postgiro
>
>Heb je al ponskaarten?

Ik nog wel ;-) Om later nog eens mee te pronken. Weet je nog wel oudje?

[Joe]

Tja, hier: glasvezel komt er met een paar weken aan, oranje buis is al gespot.

Tweak heeft een aanbod 410/jaar voor 1Gb en vast IP op aanvraag... Heb al een eigen domein voor mail en Eweka voor usenet. Ga dan
alleen Spotify missen maar de vraag is of dat erg is.

Verschil in geld en snelheid is nogal fors. Maar, misschien komt er een goed aanbod van kpn4all....

[-eggie-]

Op vrijdag 20 mei 2022 om 07:52:01 UTC+2 schreef richard lucassen:

Laat mij eerlijkheidshalve gewoon op '0' beginnen en zien waar ik uit kom.
-eggie-

[richard lucassen]

On Sat, 21 May 2022 00:55:04 -0700 (PDT)

-eggie- <egbert.m...@gmail.com> wrote:

> Op vrijdag 20 mei 2022 om 07:52:01 UTC+2 schreef richard lucassen:
> > On Thu, 19 May 2022 22:21:26 -0700 (PDT)
> > -eggie- <egbert.m...@gmail.com> wrote:
> >
> > > Alle gekheid op een stokje, ik denk dat de meerwaarde van de
> > > 'nieuwe' XS4ALL nagenoeg nul zal zijn. Ga na mijn omzetting, deze
> > > wacht ik rustig af, alles maar eens plussen en minnen en zien of
> > > ik blijf of niet. Gr. -eggie-
> > Ik was al vroeg weg, men liegt en draait, vertelt de halve waarheid
> > en daar hou ik niet van. Dan maar wat duurder. En dan ben ik nog
> > iemand die echt alleen maar een lijn nodig heeft. Xs4all is
> > compleet weggevaagd want het gaat alleen maar om geld en nergens
> > anders over. Zoals gebruikelijk helaas. Dus als je gaat plussen en
> > minnen, begin eens bij min honderd.
> > --
> > richard lucassen
> > http://contact.xaq.nl/
>
> Laat mij eerlijkheidshalve gewoon op '0' beginnen en zien waar ik uit
> kom. -eggie-

Eerlijkheid, betrokkenheid, bevlogenheid, vrijheid van communicatie en
het werken met een niet op winst gestoelde organisatie laten zich niet
noteren in een cel van een spreadsheet.

[Roger]

On 2022/05/20 07:51, richard lucassen wrote:
> On Thu, 19 May 2022 22:21:26 -0700 (PDT)
> -eggie- <egbert.m...@gmail.com> wrote:
>
>> Alle gekheid op een stokje, ik denk dat de meerwaarde van de 'nieuwe'
>> XS4ALL nagenoeg nul zal zijn. Ga na mijn omzetting, deze wacht ik
>> rustig af, alles maar eens plussen en minnen en zien of ik blijf of
>> niet. Gr. -eggie-
>
> Ik was al vroeg weg, men liegt en draait, vertelt de halve waarheid en
> daar hou ik niet van. Dan maar wat duurder. En dan ben ik nog iemand
> die echt alleen maar een lijn nodig heeft. Xs4all is compleet
> weggevaagd want het gaat alleen maar om geld en nergens anders over.

Dat geldt voor heel veel klanten ook. Mensen die bewust bereid zijn wat
meer te betalen voor kwaliteit, kun je met een loepje zoeken.

Groeten,
-Roger

[Erik]

En schrapkaarten? Ponsband met complete programma's er op? :)

Groet,
Erik

[Rob]

Schrapkaarten en ponsbanden zijn hier bij verhuizingen en opruimacties
allemaal weg gemikt. Maar ik had ze wel, ooit.

[Izak van Langevelde]

Stenen plaquettes met 10 instructies erop?

[richard lucassen]

On Mon, 23 May 2022 15:48:06 +0200
Izak van Langevelde <eeza...@studiomestenmist.nl> wrote:

> > En schrapkaarten? Ponsband met complete programma's er op? :)
>
> Stenen plaquettes met 10 instructies erop?

Die zijn ook al ge-update:

https://tmp.xaq.nl/Steve-Jobs-arrives-in-heaven.jpg

:-)

[Roger]

Ponsband? A trip down memory lane!

Ik heb rond 1980 een ponsband gebruikt om een programma (ca. 20kB) over te zetten
tussen twee computers in verschillende delen van het land. Even een van de computers
meenemen in de trein was niet handig (te lomp en te zwaar).

Van de computers was alleen de CPU hetzelfde (een Z80). Maar het OS was anders, de
5 1/4" floppy disks waren niet compatibel (de een hard sectored, de andere soft) en
de USB-stick moest nog worden uitgevonden. We hadden wel modems, maar geen compatibele
programma's om de data door te piepen. Door een speling van het lot hadden we wel
allebei een papertape reader/puncher tot onze beschikking!

Ik had drie kopieën meegekregen. De eerste twee scheurden bij het inlezen. Met de
derde lukte het. Pfff...

Groeten,
-Roger

[Rob]

Roger <nosuc...@example.com> wrote:
> Ik had drie kopieën meegekregen. De eerste twee scheurden bij het inlezen. Met de
> derde lukte het. Pfff...

Scheurende papertape? Dat heb ik nog nooit meegemaakt...
Wellicht inferieur papier (niet dat harde "geoliede" papier), of onhandigheid
bij het gebruik? (invoer raakt in de knoop en wordt zo de reader in
getrokken)

Ik had een schoenedoos met allemaal papertape, dmv een speciaal programma
was er op de leader de programmanaam geponst zodanig dat je dit kunt lezen.
(en 5x7 dot matrix)

Maar die is inmiddels dus onder het motto "wat moet je er nog mee" weg
gegooid...

[Roger]

On 2022/05/24 10:45, Rob wrote:
> Roger <nosuc...@example.com> wrote:
>> Ik had drie kopieën meegekregen. De eerste twee scheurden bij het inlezen. Met de
>> derde lukte het. Pfff...
>
> Scheurende papertape? Dat heb ik nog nooit meegemaakt...
> Wellicht inferieur papier (niet dat harde "geoliede" papier), of onhandigheid
> bij het gebruik?

Een combinatie van beide...

Groeten,
-Roger

[Joe]

Hmm, schrapkaarten misschien nog in oud schoolspul, dat was de manier om op de HEAO basic te leren. Een week later de uitslag.
Ponsband alleen maar bij telex gebruikt, nooit in de computersfeer.

[Rob]

Of ECOL.
Het voordeel van die manier van leren programmeren was dat je heel goed
leerde kijken naar het programma om minder het risico te lopen dat je
de boel terug kreeg met een simpele foutmelding (in de syntax van het
programma of tijdens de uitvoering ervan).
Daardoor leerde je bepaalde fouten direct te zien waar de latere "IDE"
generatie naar ging zoeken met een debugger of door talloze kleine
aanpassingen en dan maar weer COMPILE en RUN proberen.

[Izak van Langevelde]

On 24/05/2022 15:26, Rob wrote:
> Joe <no...@nowhere.whereo> wrote:
>> On Mon, 23 May 2022 14:39:26 +0200, Erik <non...@invalid.nl> wrote:
>>
>>> On 20-05-2022 15:47, Joe wrote:
>>>> On Thu, 19 May 2022 21:00:12 +0200, richard lucassen <mailin...@lucassen.org> wrote:
>>>>
>>>>> On Thu, 19 May 2022 20:51:05 +0200
>>>>> Gerard Dou <gd...@xs4all.nl> wrote:
>>>>>
>>>>>> Zo zit ik ook nog steeds bij de postgiro
>>>>>
>>>>> Heb je al ponskaarten?
>>>>
>>>> Ik nog wel ;-) Om later nog eens mee te pronken. Weet je nog wel oudje?
>>>
>>> En schrapkaarten? Ponsband met complete programma's er op? :)
>>>
>>> Groet,
>>> Erik
>>
>> Hmm, schrapkaarten misschien nog in oud schoolspul, dat was de manier om op de HEAO basic te leren. Een week later de uitslag.
>
> Of ECOL.
> Het voordeel van die manier van leren programmeren was dat je heel goed
> leerde kijken naar het programma om minder het risico te lopen dat je
> de boel terug kreeg met een simpele foutmelding (in de syntax van het
> programma of tijdens de uitvoering ervan).

Ik heb 'ns in Pascal geprogrammeerd zonder Pascal compiler, die was om
een of andere organisatorische reden niet geïnstalleerd. Toen die
compiler er wel kwam, had ik zoveel tijd besteed aan nalezen en -denken
dat het ding praktisch meteen werkte...

[Erik]

Hardcore Algol voor op de Burroughs! ;)

Groet,
Erik

[Joe]

Later Volmac, dat lwas meer militaire training - zeker voor de eigen werknemers. Ook daar was de computer veel verder weg dan de
taal. Als het op papier niet naar coaches wens was hoefde je al niet verder.

[Jan van den Broek]

2022-05-25, Joe <no...@nowhere.whereo> schrieb:
> On Tue, 24 May 2022 15:26:30 +0200, Rob <nom...@example.com> wrote:

[Schnipp]

>>Het voordeel van die manier van leren programmeren was dat je heel goed
>>leerde kijken naar het programma om minder het risico te lopen dat je
>>de boel terug kreeg met een simpele foutmelding (in de syntax van het
>>programma of tijdens de uitvoering ervan).
>>Daardoor leerde je bepaalde fouten direct te zien waar de latere "IDE"
>>generatie naar ging zoeken met een debugger of door talloze kleine
>>aanpassingen en dan maar weer COMPILE en RUN proberen.
>
> Later Volmac, dat lwas meer militaire training - zeker voor de eigen werknemers. Ook daar was de computer veel verder weg dan de
> taal. Als het op papier niet naar coaches wens was hoefde je al niet verder.

k kan mij een bedrijf heugen (ca 2005, RPG, AS/400) waar de teamleider
codereviews niet op de souce, maar op de gegenereerde machinetaal deed.
--
Jan v/d Broek
balg...@dds.nl

[Izak van Langevelde]

Laat me raden, het bestaat niet meer?

[Jan van den Broek]

2022-05-25, Izak van Langevelde <eeza...@studiomestenmist.nl> schrieb:
> On 25/05/2022 09:47, Jan van den Broek wrote:

[Schnipp]

>> k kan mij een bedrijf heugen (ca 2005, RPG, AS/400) waar de teamleider
>> codereviews niet op de souce, maar op de gegenereerde machinetaal deed.
>
> Laat me raden, het bestaat niet meer?

Een kleine maand terug nog wel, waarschijnlijk nu ook nog, maar zo vaak
rijd ik er niet langs.

[Joe]

Machinetaal (assembler) was leuk man! Zelf modificerende code enzo. Daar is geen enkel bedrijf aan onderdoor gegaan. Ook niet aan
RPG of AS/400 (later IBM iSeries) hoewel het natuurlijk speelgoed is tov een zSeries.

[Izak van Langevelde]

On 26/05/2022 16:46, Joe wrote:
> Machinetaal (assembler) was leuk man! Zelf modificerende code enzo. Daar is geen enkel bedrijf aan onderdoor gegaan.

Vandaar dat het niet meer gebruikt wordt?

[Joe]

On Thu, 26 May 2022 17:40:28 +0200, Izak van Langevelde <eeza...@studiomestenmist.nl> wrote:

>On 26/05/2022 16:46, Joe wrote:
>> Machinetaal (assembler) was leuk man! Zelf modificerende code enzo. Daar is geen enkel bedrijf aan onderdoor gegaan.
>
>Vandaar dat het niet meer gebruikt wordt?

O? Wel zeker wordt het nog gebruikt. Maar niet meer door gewone programmeurs. Je moet dan meer denken aan systeem software op
diep niveau of microcode.

[Izak van Langevelde]

Voor mij voor het laatst op een microcontroller...

[Rob]

Izak van Langevelde <eeza...@studiomestenmist.nl> wrote:

> On 26/05/2022 16:46, Joe wrote:
>> Machinetaal (assembler) was leuk man! Zelf modificerende code enzo. Daar is geen enkel bedrijf aan onderdoor gegaan.
>
> Vandaar dat het niet meer gebruikt wordt?

Het ideaal is dat de programmeur er niks van hoeft te snappen wat ie doet.
Want dan is ie goedkoop op te leiden en goedkoop in te zetten.

Toen ik nog op school zat leerden we de architectuur van de computer,
de bijbehorende assembler taal, en wat bijvoorbeeld een compiler deed
om van een "hogere programmeertaal" machinetaal te maken (evt via assembler).

Tegenwoordig leert men dat niet meer, althans meestal niet. Men leert
zich te richten op het op te lossen probleem in plaats van op de
werking van de computer. Ik denk dat de meeste "programmeurs" geen
idee hebben hoe een CPU werkt.

Daardoor zie je ook dat hogere programmeertalen die nog heel veel
van de machine laten zien en vereisen dat je snapt hoe de machine
werkt, bijvoorbeeld "C", het onderspit delven. De programmeur snapt
helemaal niet waar ie mee bezig is en "doet maar wat", om te kijken
of het toevallig werkt, en daarmee bouwt ie allerlei fouten in het
programma die later een veiligheidsprobleem zijn of crashes veroorzaken.

Als je in assembler kunt programmeren kun je ook een C programma schrijven
wat niet op grenscondities crasht. Maar mensen kunnen geen C meer
schrijven want "dat is een gevaarlijke taal die niks checkt" en zelf
de checks waar nodig inbouwen dat kunnen ze niet meer.

Daarom verschuift alles naar talen die helemaal niets meer laten zien
van wat de computer precies doet, en verschuift de denkwereld van
programmeurs van het bedenken van effectieve algorithmes naar het
aaneenschakelen van eerder gemaakte blokken, zelfs als die niet goed
passen. Je krijgt dat software die goedkoper te ontwikkelen is, en
als je geluk hebt ook doet wat je wilt, maar die wel tot 1000 keer meer
"machine power" vereist om hetzelfde te doen.

Dit wordt dan verdedigd met "maar computers zijn nu goedkoop", echter
de wachttijd die onvermijdelijk toch veel langer wordt die is niet
goedkoop.

Bedenk je maar eens hoeveel miljoenen manuren er al verloren zijn
gegaan door het wachten op Windows Update. De acties die dat ding
uitvoert zijn tamelijk triviaal en kunnen op een machine met snelle
"disk" (SSD) binnen een paar seconden uitgevoerd worden, maar toch
zit je maar te wachten en is de CPU al die tijd 100% belast.
Schakel uw computer niet uit!

Gewoon omdat het niet efficient geprogrammeerd is, en dat de makers
cq verkopers niks kan schelen. Danwel ze zover vervreemd zijn van
efficient programmeren dat het niet eens in ze opkomt er eens naar te
kijken waarom het toch zo lang duurt allemaal.

[Izak van Langevelde]

On 26/05/2022 19:44, Rob wrote:
> Izak van Langevelde <eeza...@studiomestenmist.nl> wrote:
>> On 26/05/2022 16:46, Joe wrote:
>>> Machinetaal (assembler) was leuk man! Zelf modificerende code enzo. Daar is geen enkel bedrijf aan onderdoor gegaan.
>>
>> Vandaar dat het niet meer gebruikt wordt?
>
> Het ideaal is dat de programmeur er niks van hoeft te snappen wat ie doet.
> Want dan is ie goedkoop op te leiden en goedkoop in te zetten.

Kort en goed, computers worden gebruikt om geld te verdienen, en niet om
goede producten of diensten te leveren...

[A. Dumas]

Rob <nom...@example.com> wrote:
> Toen ik nog op school zat leerden we de architectuur van de computer,
> de bijbehorende assembler taal, en wat bijvoorbeeld een compiler deed
> om van een "hogere programmeertaal" machinetaal te maken (evt via assembler).
>
> Tegenwoordig leert men dat niet meer, althans meestal niet. Men leert
> zich te richten op het op te lossen probleem in plaats van op de
> werking van de computer. Ik denk dat de meeste "programmeurs" geen
> idee hebben hoe een CPU werkt.
>
> Daardoor zie je ook dat hogere programmeertalen die nog heel veel
> van de machine laten zien en vereisen dat je snapt hoe de machine
> werkt, bijvoorbeeld "C", het onderspit delven.

Bij elektrotechniek (electrical engineering) leren ze dat allemaal nog wel,
ook hbo, specifiek de embedded richting.

[Flibsy]

Izak van Langevelde <eeza...@studiomestenmist.nl> wrote:

> On 26/05/2022 16:46, Joe wrote:
>> Machinetaal (assembler) was leuk man! Zelf modificerende code enzo.
>> Daar is geen enkel bedrijf aan onderdoor gegaan.
>
> Vandaar dat het niet meer gebruikt wordt?
>

Ik deed graag zelfmodificerende recursieve coding. Dat waren nog eens
tijden!

--
Flibsy

[Daniel Dent]

Op 26-5-2022 om 19:44 schreef Rob:

>
> Tegenwoordig leert men dat niet meer, althans meestal niet. Men leert
> zich te richten op het op te lossen probleem in plaats van op de
> werking van de computer. Ik denk dat de meeste "programmeurs" geen
> idee hebben hoe een CPU werkt.
>

Ik vraag mij wel eens af hoeveel energiecentrales wereldwijd gesloten
zouden kunnen worden als alle software geschreven zou zijn door
"old-school"-programmeurs (uit de tijd dat opslag-, geheugen-, en
rekencapaciteit van computers enorm begrenst was, en de volledige
wiskundige trukendoos opengetrokken moest worden om iets werkend te
krijgen), in plaats van door de vele
"knip&plak/trial&error"-programmeurs van tegenwoordig. ;-)

[Rob]

Ok dat is in ieder geval een geruststelling... ik vreesde dat dit
ondertussen niet meer het geval zou zijn.

Tegenwoordig heb je wel Youtube kanalen waar dit soort onderwerpen
uitgebreid behandeld wordt, bijvoorbeeld detail beschrijvingen van
wat er gebeurt in een 6502 of Z80 of het bouwen van een computer
op basis van minimale logische bouwstenen (o.a. de breadboard computer
van Ben Eater).

[Izak van Langevelde]

Het vakgebied informatica was dertig jaar geleden al zo breed dat het
ondoenlijk was in drie jaar tijd een allround vakman op te leiden. Met
alle aandacht voor modieuze zijstraten als cybersecurity, onzin als
blockchain en niewigheden als machine learning is de spoeling wel erg
dun geworden...

[Izak van Langevelde]

Je bedoelt dat software geschreven zou worden door mensen die niet meer
bestaan?

[Daniel Dent]

Op 26-5-2022 om 22:28 schreef Izak van Langevelde:

Haha, ja feitelijk wel, maar het is gewoon frustrerend om te beseffen
dat software veel beknopter en slimmer geschreven zou kunnen zijn, en
daardoor veel energiezuiniger zou kunnen werken.
Ik heb tenminste bij vrijwel ieder apparaat het idee dat er per
klokcyclus miljoenen nullen en enen omklappen zonder dat dat nodig is,
en dat er zelfs heel veel omklappen zonder dat iemand ter wereld nog
weet waarom dat gebeurt... ;-)


Een paar jaar geleden bepleitte iemand (ik geloof Neelie Smit-Kroes) dat
kinderen op basisscholen al moesten beginnen met "coderen", terwijl ik
meteen dacht: Nee, nee, nee... Dan moeten ze later zoveel afleren,
willen ze ooit nog fatsoenlijke code kunnen produceren.
Programmeren zonder wiskundig onderlegd te zijn, zou verboden moeten
worden... ;-)

[Rob van der Putten]

Hoi

On 26/05/2022 22:08, Daniel Dent wrote:

Is It More Energy-Efficient to Program in Rust?
https://developers.slashdot.org/story/22/02/20/0143226/is-it-more-energy-efficient-to-program-in-rust
Zie ook tabel in;
https://aws.amazon.com/blogs/opensource/sustainability-with-rust/
Wie C doet kan zich dus sustainable (groen) programmer noemen. Zijn
'oude' talen toch nog 'hip'.


Vr.Gr,
Rob
--
Google search is unreliable
http://www.sput.nl/internet/google.html

[Joe]

En daardoor wordt het verdienpotentieel weer kleiner. Goed programmeren levert geld op, zowel in houdbaarheid van programmatuur als
in verminderde onderhoudskosten. Efficientie (lagere hardware/cloud investeringen) neemt ongemerkt ook toe.

[Joe]

Die breedte is nog verder toegenomen.
Bedrijven willen nu alles wat sexy is, ongeacht of het voor hen nuttig is en bijdraagt aan de bottomline.
Jongeren en studenten gaan al voor een opleiding aan de gang met wat sexy is, brouwen van alles en verwachten hun kunstje later te
gelde te maken.

Gevolg: bedrijven moeten wel en personeel wil niet anders. Concepten worden niet meer begrepen, zeldzame uitzonderingen
daargelaten. Falende projecten zijn aan de orde van de dag. Zowel bij overheid als in het bedrijfsleven want "managers" weten al
helemaal niet meer waar ze van zijn en voor zouden moeten staan....

[Rob]

Izak van Langevelde <eeza...@studiomestenmist.nl> wrote:

Ok maar ik neem aan dat je bij "informatica" praat over een universitaire
studie en die zijn (of waren) meestal niet gericht op het opleiden van
een vakman.

Het gaat juist meer om het verkrijgen van inzichten in hoe de zaken
echt werken dan om het "werken met specifieke ontwikkelomgevingen".

Zelf heb ik wel een praktische opleiding (HTS electrotechniek met
specialisatie technische computerkunde) gedaan en in die tijd was er
nog een grote varieteit in zowel theorie als praktijk. Er was ook
nog niet heel veel standaardisatie in de wereld dus ook geen neiging
om "alleen Microsoft oplossingen te behandelen" oid. Microsoft was
toen alleen bekend van de BASIC-in-ROM die je in de eerste microcomputers
vond, maar die hadden we op school helemaal niet, dat had je hooguit
thuis.

In het algemeen was er een grotere afstand tussen bedenken van een
programma en uitproberen of het werkte, en dat leek inefficient maar
het had zeker ook voordelen.

[Joe]

+1

[Miquel van Smoorenburg]

In article <slrnt8vf46...@xs9.xs4all.nl>,

Rob <nom...@example.com> wrote:
>Daardoor zie je ook dat hogere programmeertalen die nog heel veel
>van de machine laten zien en vereisen dat je snapt hoe de machine
>werkt, bijvoorbeeld "C", het onderspit delven. De programmeur snapt
>helemaal niet waar ie mee bezig is en "doet maar wat", om te kijken
>of het toevallig werkt, en daarmee bouwt ie allerlei fouten in het
>programma die later een veiligheidsprobleem zijn of crashes veroorzaken.
>
>Als je in assembler kunt programmeren kun je ook een C programma schrijven
>wat niet op grenscondities crasht. Maar mensen kunnen geen C meer
>schrijven want "dat is een gevaarlijke taal die niks checkt" en zelf
>de checks waar nodig inbouwen dat kunnen ze niet meer.

Er is bijna niemand die volledig 100% secure C kan schrijven.
Ik niet in ieder geval. Ja, 10 regels, of 20, maar in een
project van tienduizenden regels? Vergeet het maar. Hoeft ook
niet aan jou te liggen, iemand anders kan in een ander deel
een aanpassing hebben gemaakt wat bepaalde assumpties ongeldig
maakt en omdat C niet heel strict is merk je dat pas op momenten die
meestal niet erg goed uitkomen.

https://www.zdnet.com/article/microsoft-70-percent-of-all-security-bugs-are-memory-safety-issues/
^^^^^^^^^^^^^ weet je wat dit kost ...

>Daarom verschuift alles naar talen die helemaal niets meer laten zien
>van wat de computer precies doet, en verschuift de denkwereld van
>programmeurs van het bedenken van effectieve algorithmes naar het
>aaneenschakelen van eerder gemaakte blokken, zelfs als die niet goed
>passen. Je krijgt dat software die goedkoper te ontwikkelen is, en
>als je geluk hebt ook doet wat je wilt, maar die wel tot 1000 keer meer
>"machine power" vereist om hetzelfde te doen.

Java of C# zijn niet 1000x langzamer (misschien 2x, of 3x) en zijn
wel memory safe. Of safe_r_ in ieder geval (je kan soms de fout ingaan
met race condities in threaded code).

Als je echt safe wilt moet je Rust gebruiken. Dat is ook gewoon
net zo snel als C of C++.

Mike.

[Rob]

Miquel van Smoorenburg <mik...@xs4all.nederland.invalid> wrote:
>>Daarom verschuift alles naar talen die helemaal niets meer laten zien
>>van wat de computer precies doet, en verschuift de denkwereld van
>>programmeurs van het bedenken van effectieve algorithmes naar het
>>aaneenschakelen van eerder gemaakte blokken, zelfs als die niet goed
>>passen. Je krijgt dat software die goedkoper te ontwikkelen is, en
>>als je geluk hebt ook doet wat je wilt, maar die wel tot 1000 keer meer
>>"machine power" vereist om hetzelfde te doen.
>
> Java of C# zijn niet 1000x langzamer (misschien 2x, of 3x) en zijn
> wel memory safe. Of safe_r_ in ieder geval (je kan soms de fout ingaan
> met race condities in threaded code).

Ik heb het niet over het vergelijken van een simpele constructie in
beide talen, bijvoorbeeld "hoe lang duurt een loop van 1000 keer",
maar over de performance van het totale resultaat.
En dan gaat het ook niet alleen over snelheid, maar ook over geheugen
gebruik, hoe constant dat geheugengebruik is over langere runtimes, etc.

Die factor 1000 haal ik uit een project wat ik zelf een keer van Java
naar C heb omgezet en waar ik die factor gemakkelijk haalde in geheugen
gebruik, en in CPU gebruik ging het ook wel aardig die kant op.

Dan moet je uiteraard niet alleen het algorithme 1:1 overzetten van
Java naar C nee. Dan moet je het probleem opnieuw bekijken en omzetten
van de denkwereld van een Java programmeur naar die van iemand die
de onderliggende mechanismen snapt en weet waar je op moet letten.

Ja, dat kan heel goed betekenen dat je een vaste buffer alloceert
en daar je databytes stuk voor stuk in plaatst, gaandeweg goed checkend
dat je niet over het eind gaat, maar dat is dan heel wat effcienter
dan een of ander dynamische-lengte string waar je steeds een karakter
aanplakt met een + of . operator en dan terugzet in dezelfde variabele.
Lijkt voor de moderne programmeur hetzelfde, maar onderwater wordt
die dan keer op keer gecopieerd naar een steeds grotere buffer,
en het dynamisch geheugenmanagement dat daarbij gebruikt wordt leidt
tot expansie van de hoeveelheid geheugen, "garbage collects", enz.
Terwijl dat in de specifieke applicatie totaal onnodig is. En tegen
de tijd dat je 4096 byte bericht compleet is heb je wel duizenden
keren dezelfde data onnodig gecopieerd.

Let op dit is maar een voorbeeld, het is niet de bedoeling om een
welles-nietes discussie over dit specifieke voorbeeld te gaan houden.

[Jan van den Broek]

2022-05-27, Joe <no...@nowhere.whereo> schrieb:

[Schnipp]

> Die breedte is nog verder toegenomen.
> Bedrijven willen nu alles wat sexy is, ongeacht of het voor hen nuttig is en bijdraagt aan de bottomline.
> Jongeren en studenten gaan al voor een opleiding aan de gang met wat sexy is, brouwen van alles en verwachten hun kunstje later te
> gelde te maken.

Ik denk dat dertig,, veertig jaar terug precies hetzelfde was.

[Schnipp]

[Paul Slootman]

Miquel van Smoorenburg <mik...@xs4all.nederland.invalid> wrote:
>

>Java of C# zijn niet 1000x langzamer (misschien 2x, of 3x) en zijn
>wel memory safe. Of safe_r_ in ieder geval (je kan soms de fout ingaan
>met race condities in threaded code).

Je hebt voor Java wel 1000x zoveel memory nodig... en dan nog gaat ie op
een gegeven moment druk zijn met garbage collection.

/me is geen java fan. Het kan vast wel goed, maar dat ben ik eigenlijk
nog niet tegengekomen

>Als je echt safe wilt moet je Rust gebruiken. Dat is ook gewoon
>net zo snel als C of C++.

En Go?


Paul (houdt het wel op C, of perl als ik lui ben)

[Izak van Langevelde]

On 26/05/2022 22:53, Daniel Dent wrote:
> Een paar jaar geleden bepleitte iemand (ik geloof Neelie Smit-Kroes) dat
> kinderen op basisscholen al moesten beginnen met "coderen", terwijl ik
> meteen dacht: Nee, nee, nee... Dan moeten ze later zoveel afleren,
> willen ze ooit nog fatsoenlijke code kunnen produceren.

Ik kan me nog wel herinneren dat men destijds bij Inleiding Programmeren
het liefst leerlingen had die nog nooit geprogrammeerd hadden...

> Programmeren zonder wiskundig onderlegd te zijn, zou verboden moeten
> worden... ;-)

Daar ben ik het niet mee eens. Ik heb destijds veel wiskunde te
verstouwen gekregen, en nooit gebruikt, afgezien van wat
brugklas-wiskunde. De enige reden dat ik veel wiskunde voor mijn kiezen
kreeg, was dat de docenten hun kennis te gelde moesten maken.

[Izak van Langevelde]

On 27/05/2022 10:45, Miquel van Smoorenburg wrote:
> In article <slrnt8vf46...@xs9.xs4all.nl>,
> Rob <nom...@example.com> wrote:
>> Daardoor zie je ook dat hogere programmeertalen die nog heel veel
>> van de machine laten zien en vereisen dat je snapt hoe de machine
>> werkt, bijvoorbeeld "C", het onderspit delven. De programmeur snapt
>> helemaal niet waar ie mee bezig is en "doet maar wat", om te kijken
>> of het toevallig werkt, en daarmee bouwt ie allerlei fouten in het
>> programma die later een veiligheidsprobleem zijn of crashes veroorzaken.
>>
>> Als je in assembler kunt programmeren kun je ook een C programma schrijven
>> wat niet op grenscondities crasht. Maar mensen kunnen geen C meer
>> schrijven want "dat is een gevaarlijke taal die niks checkt" en zelf
>> de checks waar nodig inbouwen dat kunnen ze niet meer.
>
> Er is bijna niemand die volledig 100% secure C kan schrijven.
> Ik niet in ieder geval. Ja, 10 regels, of 20, maar in een
> project van tienduizenden regels? Vergeet het maar. Hoeft ook
> niet aan jou te liggen, iemand anders kan in een ander deel
> een aanpassing hebben gemaakt wat bepaalde assumpties ongeldig
> maakt en omdat C niet heel strict is merk je dat pas op momenten die
> meestal niet erg goed uitkomen.

Vandaar dat alle kritieke code in een applicatie-server geduwd is. De
meeste ontwikkelaars maken handig gebruik van een database die aan het
internet hangt, aan de hand van voorbeeldjes. Vaak gaat dat goed, maar
lang niet altijd...

[Izak van Langevelde]

Slecht programmeren vraagt meer mensen, en daar wordt gruwelijk veel aan
verdiend, door allerlei detacheringsclubjes, intermediairs en
bemiddelaars...

[Izak van Langevelde]

On 27/05/2022 10:33, Rob wrote:
> Izak van Langevelde <eeza...@studiomestenmist.nl> wrote:
>> On 26/05/2022 21:42, A. Dumas wrote:
>>> Rob <nom...@example.com> wrote:
>>>> Toen ik nog op school zat leerden we de architectuur van de computer,
>>>> de bijbehorende assembler taal, en wat bijvoorbeeld een compiler deed
>>>> om van een "hogere programmeertaal" machinetaal te maken (evt via assembler).
>>>>
>>>> Tegenwoordig leert men dat niet meer, althans meestal niet. Men leert
>>>> zich te richten op het op te lossen probleem in plaats van op de
>>>> werking van de computer. Ik denk dat de meeste "programmeurs" geen
>>>> idee hebben hoe een CPU werkt.
>>>>
>>>> Daardoor zie je ook dat hogere programmeertalen die nog heel veel
>>>> van de machine laten zien en vereisen dat je snapt hoe de machine
>>>> werkt, bijvoorbeeld "C", het onderspit delven.
>>>
>>> Bij elektrotechniek (electrical engineering) leren ze dat allemaal nog wel,
>>> ook hbo, specifiek de embedded richting.
>>
>> Het vakgebied informatica was dertig jaar geleden al zo breed dat het
>> ondoenlijk was in drie jaar tijd een allround vakman op te leiden. Met
>> alle aandacht voor modieuze zijstraten als cybersecurity, onzin als
>> blockchain en niewigheden als machine learning is de spoeling wel erg
>> dun geworden...
>
> Ok maar ik neem aan dat je bij "informatica" praat over een universitaire
> studie en die zijn (of waren) meestal niet gericht op het opleiden van
> een vakman.

Zeker wel, al is dat niet altijd een ontwikkelaar, maar steeds vaker een
manager, onderzoeker of docent...

[Daniel Dent]

Op 27-5-2022 om 11:24 schreef Izak van Langevelde:

>
>> Programmeren zonder wiskundig onderlegd te zijn, zou verboden moeten
>> worden... ;-)
>
> Daar ben ik het niet mee eens. Ik heb destijds veel wiskunde te
> verstouwen gekregen, en nooit gebruikt, afgezien van wat
> brugklas-wiskunde. De enige reden dat ik veel wiskunde voor mijn kiezen
> kreeg, was dat de docenten hun kennis te gelde moesten maken.
>

Dan denk ik dat ik zou gaan huilen als ik jouw code zou zien die
bijvoorbeeld een praktische oplossing zou bieden voor een variatie op
het handelsreizigersprobleem.
Dat is te programmeren zonder hogere wiskunde, maar dan levert de
computer de oplossing pas na uren/dagen/weken/maanden/jaren fulltime
rekenen. Terwijl een wiskundig model van dat probleem het snel oplost
(zolang het aantal adressen niet enorm uit de hand loopt).

Ander voorbeeld:
Op de universiteit kreeg ik les van een docent die nog door Edsger
Dijkstra was opgeleid. Die gaf een ogenschijnlijk simpele opdracht (30
jaar geleden inmiddels, dus ik kan die opdracht niet meer reproduceren).
Hier had ik in eerste instantie ~50 regels code (het essentiële
rekenwerk van het programmaatje) voor nodig om dat op te lossen (weinig
wiskundig aangepakt). Na de opmerking, met glimmende oogjes
uitgesproken, "Dat kan korter!", en wat aanwijzingen, kreeg ik het terug
naar ongeveer 20 regels (meer wiskundig aangepakt). Opnieuw volgde een
beoordeling met een olijke glimlach "Dat kan korter!". Nog een
aanwijzing hielp me naar 15 regels, maar toen dacht ik wel de limiet
bereikt te hebben.
Even later presenteerde hij de optimale oplossing: 1 regel code, die een
geniale opeenstapeling van wiskundige trucjes bevatte, en die in
uitvoering slechts een fractie van de rekentijd nodig had, ten opzichte
van mijn oplossing.

Toen werd ik ineens heel blij dat ik Technische Bedrijfskunde studeerde,
en informatica slechts een deel van mijn opleiding vormde, in plaats van
de hoofdmoot... ;-)

Handelsreizigersprobleem:
https://nl.wikipedia.org/wiki/Handelsreizigersprobleem
Op te lossen met de wiskundige techniek van "lineair programmeren":
https://nl.wikipedia.org/wiki/Lineair_programmeren
Edsger Dijkstra:
https://nl.wikipedia.org/wiki/Edsger_Dijkstra
Simula (waar we toen in programmeerden):
https://en.wikipedia.org/wiki/Simula

[Izak van Langevelde]

On 27/05/2022 12:59, Daniel Dent wrote:
> Op 27-5-2022 om 11:24 schreef Izak van Langevelde:
>
>>
>>> Programmeren zonder wiskundig onderlegd te zijn, zou verboden moeten
>>> worden... ;-)
>>
>> Daar ben ik het niet mee eens. Ik heb destijds veel wiskunde te
>> verstouwen gekregen, en nooit gebruikt, afgezien van wat
>> brugklas-wiskunde. De enige reden dat ik veel wiskunde voor mijn
>> kiezen kreeg, was dat de docenten hun kennis te gelde moesten maken.
>>
>
>
> Dan denk ik dat ik zou gaan huilen als ik jouw code zou zien die
> bijvoorbeeld een praktische oplossing zou bieden voor een variatie op
> het handelsreizigersprobleem.
> Dat is te programmeren zonder hogere wiskunde, maar dan levert de
> computer de oplossing pas na uren/dagen/weken/maanden/jaren fulltime
> rekenen. Terwijl een wiskundig model van dat probleem het snel oplost
> (zolang het aantal adressen niet enorm uit de hand loopt).

Dat heeft niets met hogere wiskunde te maken, daarvoor zijn standaard
algorithmen bekend...

> Ander voorbeeld:
> Op de universiteit kreeg ik les van een docent die nog door Edsger
> Dijkstra was opgeleid. Die gaf een ogenschijnlijk simpele opdracht (30
> jaar geleden inmiddels, dus ik kan die opdracht niet meer reproduceren).
> Hier had ik in eerste instantie ~50 regels code (het essentiële
> rekenwerk van het programmaatje) voor nodig om dat op te lossen (weinig
> wiskundig aangepakt). Na de opmerking, met glimmende oogjes
> uitgesproken, "Dat kan korter!", en wat aanwijzingen, kreeg ik het terug
> naar ongeveer 20 regels (meer wiskundig aangepakt). Opnieuw volgde een
> beoordeling met een olijke glimlach "Dat kan korter!". Nog een
> aanwijzing hielp me naar 15 regels, maar toen dacht ik wel de limiet
> bereikt te hebben.
> Even later presenteerde hij de optimale oplossing: 1 regel code, die een
> geniale opeenstapeling van wiskundige trucjes bevatte, en die in
> uitvoering slechts een fractie van de rekentijd nodig had, ten opzichte
> van mijn oplossing.

Een leuk verhaal, maar ik geloof niet in geniale oplossingen die door 1%
van de ontwikkelaars begrepen kunnen worden, en die een snelheidswinst
boeken die op moderne hardware van slechts academische betekenis is. De
pupillen van Dijkstra hielden zich bezig met speelgoedvoorbeelden, en
sommigen doen dat nog steeds. Zeg eens eerlijk, hoeveel tijd heeft het
gekost de man op te leiden, en hoeveel tijd heeft 'ie zelf aan deze
oplossing besteed?

Ik herinner me een medestudent die apetrots was dat hij in een
onleesbare pagina, zonder commentaar of bruikbaar wit Lisp voor elkaar
kreeg waar ik 10 pagina's voor nodig had, met commentaar, leesbare
layout, en begrijpelijke namen voor functies. Hij kreeg een 5, ik had een 9.

[robert]

Daniel Dent <daan082...@xs4all.nl>:

> Even later presenteerde hij de optimale oplossing: 1 regel code, die een
> geniale opeenstapeling van wiskundige trucjes bevatte, en die in
> uitvoering slechts een fractie van de rekentijd nodig had, ten opzichte
> van mijn oplossing.

En sindsdien schrijf jij je code alleen nog maar in ondoorgrondelijke
oneliners? ;)

--
robert

[Daniel Dent]

Op 27-5-2022 om 13:13 schreef Izak van Langevelde:

>
> Een leuk verhaal, maar ik geloof niet in geniale oplossingen die door 1%
> van de ontwikkelaars begrepen kunnen worden, en die een snelheidswinst
> boeken die op moderne hardware van slechts academische betekenis is. De
> pupillen van Dijkstra hielden zich bezig met speelgoedvoorbeelden, en
> sommigen doen dat nog steeds. Zeg eens eerlijk, hoeveel tijd heeft het
> gekost de man op te leiden, en hoeveel tijd heeft 'ie zelf aan deze
> oplossing besteed?

Hij schudde dergelijke oplossingen wel uit zijn mouw. Maar hij was
ongetwijfeld meer een academicus dan een man van de praktijk.

>
> Ik herinner me een medestudent die apetrots was dat hij in een
> onleesbare pagina, zonder commentaar of bruikbaar wit Lisp voor elkaar
> kreeg waar ik 10 pagina's voor nodig had, met commentaar, leesbare
> layout, en begrijpelijke namen voor functies. Hij kreeg een 5, ik had
> een 9.
>

Terecht dat jij die 9 kreeg, en hij die 5, maar dat gaat in essentie wel
over iets anders. Immers, eenmaal gecompileerd werkte jullie code
misschien wel identiek.

[Jan van den Broek]

2022-05-27, Daniel Dent <daan082...@xs4all.nl> schrieb:
> Op 27-5-2022 om 11:24 schreef Izak van Langevelde:
>
>>
>>> Programmeren zonder wiskundig onderlegd te zijn, zou verboden moeten
>>> worden... ;-)
>>
>> Daar ben ik het niet mee eens. Ik heb destijds veel wiskunde te
>> verstouwen gekregen, en nooit gebruikt, afgezien van wat
>> brugklas-wiskunde. De enige reden dat ik veel wiskunde voor mijn kiezen
>> kreeg, was dat de docenten hun kennis te gelde moesten maken.
>>
>
>
> Dan denk ik dat ik zou gaan huilen als ik jouw code zou zien die
> bijvoorbeeld een praktische oplossing zou bieden voor een variatie op
> het handelsreizigersprobleem.

Ik programmeer een aantal jaar ambtshalve, maar ik heb nooit het
handelsreizigersprobleem hoeven oplossen. Of je moet daarmee bedoelen
dat handelsreizigers zaken verkopen zonder te overleggen over de
haalbaarheid.

(Wat is het verschil tussen en verkoper en een trolleybus? Een
trolleybus stopt als hij de draad kwijt is.)

[Schnipp]
--
Jan v/d Broek
balg...@dds.nl

[Daniel Dent]

Op 27-5-2022 om 13:41 schreef robert:

Dat is toch het mooie van wiskunde leren?
Als je bezig bent met hoofdstuk 4 in het leerboek, dan lijkt wat er in
hoofdstuk 6 staat ondoorgrondelijk. Ben je eenmaal in hoofdstuk 8
aangeland, dan lijkt dat wat in hoofdstuk 6 stond ineens ontzettend
simpel... ;-)

[Izak van Langevelde]

On 27/05/2022 13:47, Daniel Dent wrote:
> Op 27-5-2022 om 13:13 schreef Izak van Langevelde:
>

>> Ik herinner me een medestudent die apetrots was dat hij in een
>> onleesbare pagina, zonder commentaar of bruikbaar wit Lisp voor elkaar
>> kreeg waar ik 10 pagina's voor nodig had, met commentaar, leesbare
>> layout, en begrijpelijke namen voor functies. Hij kreeg een 5, ik had
>> een 9.
>>
>
> Terecht dat jij die 9 kreeg, en hij die 5, maar dat gaat in essentie wel
> over iets anders. Immers, eenmaal gecompileerd werkte jullie code
> misschien wel identiek.

Mogelijk, even afgezien van het feit dat Lisp niet gecompileerd werd,
maar geïnterpreteerd. Maar goed, Lisp werd nou niet echt gebruikt
vanwege de oorverdovende performance...

[Izak van Langevelde]

On 27/05/2022 13:48, Jan van den Broek wrote:
> 2022-05-27, Daniel Dent <daan082...@xs4all.nl> schrieb:
>> Op 27-5-2022 om 11:24 schreef Izak van Langevelde:
>>
>>>
>>>> Programmeren zonder wiskundig onderlegd te zijn, zou verboden moeten
>>>> worden... ;-)
>>>
>>> Daar ben ik het niet mee eens. Ik heb destijds veel wiskunde te
>>> verstouwen gekregen, en nooit gebruikt, afgezien van wat
>>> brugklas-wiskunde. De enige reden dat ik veel wiskunde voor mijn kiezen
>>> kreeg, was dat de docenten hun kennis te gelde moesten maken.
>>>
>>
>>
>> Dan denk ik dat ik zou gaan huilen als ik jouw code zou zien die
>> bijvoorbeeld een praktische oplossing zou bieden voor een variatie op
>> het handelsreizigersprobleem.
>
> Ik programmeer een aantal jaar ambtshalve, maar ik heb nooit het
> handelsreizigersprobleem hoeven oplossen. Of je moet daarmee bedoelen
> dat handelsreizigers zaken verkopen zonder te overleggen over de
> haalbaarheid.

Klopt. In de pak 'm beet 20 jaar dat ik software heb ontwikkeld, heb ik
mij geloof ik drie keer gebogen over performance, waarbij het in twee
gevallen ging om slecht gedocumenteerde query optimalisatie, waardoor
een query weken dreigde te draaien, in plaats van een halve dag, en een
enkel geval waarin ik een bloksignaal in realtime moest decoderen, en
waar ik in assembly heb lopen zoeken of het nog een klokcyclusje sneller
kon.

Zonder nou in te hakken op de jeugd van tegenwoordig, de meeste
praktijkproblemen gaan niet veel verder dan 1+1=2 (en dan in euro's).
Hooguit gaat het om performance, eigenlijk nooit over complexiteit.

[Izak van Langevelde]

On 27/05/2022 14:01, Daniel Dent wrote:
> Op 27-5-2022 om 13:41 schreef robert:
>> Daniel Dent <daan082...@xs4all.nl>:
>>> Even later presenteerde hij de optimale oplossing: 1 regel code, die een
>>> geniale opeenstapeling van wiskundige trucjes bevatte, en die in
>>> uitvoering slechts een fractie van de rekentijd nodig had, ten opzichte
>>> van mijn oplossing.
>>
>> En sindsdien schrijf jij je code alleen nog maar in ondoorgrondelijke
>> oneliners? ;)
>>
>
> Dat is toch het mooie van wiskunde leren?

Dat heeft niets met wiskunde te maken, en alles met slecht programmeren.

[Rob]

Ja precies, maar wat moet een manager met kennis over processor- en
computer architectuur, microcode, bottlenecks in geheugen- en massa
opslag toegang, enz? Kennis daarover hindert hem alleen maar bij het
enthousiast aanhoren van de verkopers van moderne technologie.
"volgens mij ligt het niet zo simpel als meneer de verkopert denkt".

[Rob]

Paul Slootman <paul+...@wurtel.net> wrote:
> Miquel van Smoorenburg <mik...@xs4all.nederland.invalid> wrote:
>>
>>Java of C# zijn niet 1000x langzamer (misschien 2x, of 3x) en zijn
>>wel memory safe. Of safe_r_ in ieder geval (je kan soms de fout ingaan
>>met race condities in threaded code).
>
> Je hebt voor Java wel 1000x zoveel memory nodig... en dan nog gaat ie op
> een gegeven moment druk zijn met garbage collection.
>
> /me is geen java fan. Het kan vast wel goed, maar dat ben ik eigenlijk
> nog niet tegengekomen

Ja precies. Dat is het probleem met Java: als je kritiek hebt op
slecht en langzaam werkende Java programma's dan zal de Java fan altijd
opmerken dat dit niet aan Java ligt en dat het wel goed KAN.

Alleen kom je de combinatie van "slecht en langzaam werkende programma's"
en "Java" wel HEEL erg vaak tegen, dat kan geen toeval zijn.

[Izak van Langevelde]

Er is weinig mis met Java, maar zoals alle gereedschappen kun je het
niet blindelings voor alles gebruiken...

[robert]

Rob <nom...@example.com>:

> Paul Slootman <paul+...@wurtel.net> wrote:
>>
>> /me is geen java fan. Het kan vast wel goed, maar dat ben ik eigenlijk
>> nog niet tegengekomen
>
> Ja precies. Dat is het probleem met Java: als je kritiek hebt op
> slecht en langzaam werkende Java programma's dan zal de Java fan altijd
> opmerken dat dit niet aan Java ligt en dat het wel goed KAN.

Java is traag, C is een veiligheidsrisico, Perl is onleesbaar, PHP is
al helemaal niet serieus te nemen. Er is de afgelopen 30 jaar weinig
veranderd.

--
robert

[Izak van Langevelde]

Een computer blijft mensenwerk...

[Rob]

Izak van Langevelde <eeza...@studiomestenmist.nl> wrote:

Je hebt duidelijk niet begrepen waar ik op doel.

[Izak van Langevelde]

Da's dan wederzijds...

[robert]

Rob <nom...@example.com>:

Waar dóel je eigenlijk precies op? Dat Java traag is? Dat Javaprogrammeurs
allemaal prutsers zijn? Met een paar miljard apparaten in de wereld die
Java (of een JVM) draaien zal het kennelijk de rest van de mensheid een
zorg zijn.

--
robert

[Roger]

On 2022/05/27 18:19, robert wrote:
> Rob <nom...@example.com>:
>> Paul Slootman <paul+...@wurtel.net> wrote:
>>>
>>> /me is geen java fan. Het kan vast wel goed, maar dat ben ik eigenlijk
>>> nog niet tegengekomen
>>
>> Ja precies. Dat is het probleem met Java: als je kritiek hebt op
>> slecht en langzaam werkende Java programma's dan zal de Java fan altijd
>> opmerken dat dit niet aan Java ligt en dat het wel goed KAN.
>
> Java is traag,

Geen ervaring mee.

> C is een veiligheidsrisico,

Het risico is de onbekwame programmeur die niet weet hoe je veilig programmeert
in C. Het vergt ook een discipline die veel programmeurs niet hebben.

C++ is wat beter, zeker als je bv. new/delete afzweert (en altijd RAII gebruikt)
en ook STL types gebruikt i.p.v. low level C types. De prijs is uiteraard flink
wat extra overhead in memory en performance (t.o.v. C).

Onder Windows is C# met .NET voor mij de eerste keus. Bij het ontwerp van C# heeft
Microsoft zich heel goed gerealiseerd wat er mis is met C en C++.

> Perl is onleesbaar,

Je kunt in Perl heel goed prima leesbare programma's schrijven, maar het is helaas
o zo gemakkelijk om onleesbare brij te produceren. Vooral Perl goeroes bezondigen
zich hieraan ('kijk eens hoe goed ik ben').

> PHP is al helemaal niet serieus te nemen.

Hier kan ik het alleen maar mee eens zijn. PHP gebruik ik alleen als het niet
anders kan.

> Er is de afgelopen 30 jaar weinig veranderd.

Wat vooral niet is veranderd de laatste 30 jaar zijn de programmeurs... (en niet
te vergeten hun managers)

Groeten,
-Roger

[Paul Slootman]

robert <US3N37+{x.g}@gmail.com> wrote:
>
>Waar dóel je eigenlijk precies op? Dat Java traag is? Dat Javaprogrammeurs
>allemaal prutsers zijn? Met een paar miljard apparaten in de wereld die
>Java (of een JVM) draaien zal het kennelijk de rest van de mensheid een
>zorg zijn.

In het begin werd java aangeprezen als "compile once, run everywhere".
In de praktijk moet je vaak tot in de laatste cijfers precies de juiste
versie java 1.6.0.75 hebben want 1.6.0.93 werkt het niet meer.

Laat staan dat een tijdje switch fabrikanten dachten dat het een goed
idee was om de web interface in java te schrijven. Ik heb daar nog een
virtualbox image van win xp voor zodat ik die nog kan bedienen, want met
een moderne browser (als je edge zo ver gekregen heeft dat java embedded
loopt) werkt het weer niet omdat weer de versie van java niet overweg
kan met die oude code.

Gelukkig wordt dat steeds meer gewoon html 5 (ook voor ILO's om de
console op afstand over te nemen).


Paul

[Mark Huizer]

The wise Daniel Dent enlightened me with:

>
> Toen werd ik ineens heel blij dat ik Technische Bedrijfskunde studeerde,
> en informatica slechts een deel van mijn opleiding vormde, in plaats van
> de hoofdmoot... ;-)
>

Als iemand die wel Informatica deed, durf ik de bewering aan dat je
wellicht wat doorslaat.

Er zijn stukken waar programmeren betekent dat je theoretisch aan de
slag kan, en op basis van logica, wiskunde etc optimalisaties kan
bereiken. Maar dat is niet 100% van wat ontwikkelen inhoudt.

Dingen die ongetwijfeld niet 100% efficient zijn, zijn zaken als
libraries, frameworks etc. Ook voor vele algoritmische zaken. Er zijn
meer dan genoeg voorbeelden waar je beter een goed gecontroleerde
library kan gebruiken die misschien 10% efficienter zou kunnen, maar
veel betrouwbaarder is qua resultaat dan "het wiel telkens opnieuw
uitvinden". Die balans zoeken is ook een belangrijke vaardigheid.

Gebruikersinterfaces, database ontwerpen,
softwareontwikkelingsprocessen, allemaal onderdelen waar jouw
handelsreizigersprobleem totaal niet aan de orde zijn.

Mark

[Paul Slootman]

Roger <nosuc...@example.com> wrote:
>
>> Perl is onleesbaar,
>
>Je kunt in Perl heel goed prima leesbare programma's schrijven, maar het is helaas
>o zo gemakkelijk om onleesbare brij te produceren. Vooral Perl goeroes bezondigen
>zich hieraan ('kijk eens hoe goed ik ben').

Ik doe altijd m'n best om het zo leesbaar mogelijk te houden en zonodig
commentaar erbij te zetten, al was het alleen maar voor mijzelf zodat ik
een 5 jaar jongere mijzelf nog steeds snap :-)


Paul

[Rob]

Ik denk dat het gebruiken (en vooral aanleren) van bepaalde gereedschappen
een soort van programmeur creeert die voornamelijk ondermaatse kwaliteit
levert. Java trekt dat kennelijk aan, want als Java in de buurt is dan
is bagger nooit ver weg.

[A. Dumas]

Roger <nosuc...@example.com> wrote:
> On 2022/05/27 18:19, robert wrote:
>> PHP is al helemaal niet serieus te nemen.
>
> Hier kan ik het alleen maar mee eens zijn. PHP gebruik ik alleen als het niet
> anders kan.

Meh. Ja, er is ontzettend veel stupide troep, mede omdat php het intrinsiek
mogelijk maakt, maar de reputatieschade komt denk ik vooral doordat het zo
ontzettend veel gebruikt is, door een onvolwassen booming business, en
omdat het online is en elke fout misbruikt kan worden.

Ik heb zelf een paar jaar bij een php-webshop gewerkt als backend
programmeur, en MIJN php code was altijd super goed!! ;) Maar serieus, als
je goed programmeren geleerd hebt dan kun je ook met php goeie dingen
maken.

[robert]

Roger <nosuc...@example.com>:

En, wat ik eigenlijk bedoelde te zeggen, de mensen (meestal personen die
niet programmeren voor hun dagelijks werk) die zeiken over programmeertaal X.

--
robert

[Daniel Dent]

Op 27-5-2022 om 20:37 schreef Mark Huizer:

Dat is zeker waar. Ik heb wel de indruk dat het nu iets teveel naar de
andere kant is doorgeslagen. Denk aan het Log4j debacle. Dat kwam in
veel gevallen toch neer op gemakzucht.

En voor software die op bijvoorbeeld 10, 100 of 1000 systemen actief is,
heeft efficiëntie-optimalisatie natuurlijk weinig zin. Maar zijn
intussen heel veel apps (om in modieuze termen te spreken), die op
miljoenen apparaten actief zijn. Als je die slechts 10% efficiënter zou
kunnen maken, dan sla je al wel een deuk in een pakje boter... ;-)

De reden dat ik mij in deze thread begon te mengen was de
energietransitie waar we als planeetbewoners voor staan, en die een stuk
makkelijker wordt als we energie weten te besparen. De invloed die
efficiëntere software zou kunnen hebben, blijft onderbelicht, en ik vind
dat ontwikkelaars daar toch echt een bijdrage te leveren hebben.

[Joe]

On Fri, 27 May 2022 18:40:59 -0000 (UTC), Paul Slootman <paul+...@wurtel.net> wrote:

>Ik doe altijd m'n best om het zo leesbaar mogelijk te houden en zonodig
>commentaar erbij te zetten, al was het alleen maar voor mijzelf zodat ik
>een 5 jaar jongere mijzelf nog steeds snap :-)
>
>
>Paul

Je bent nu beslist de uitzondering op de regel.

[Joe]

On Fri, 27 May 2022 19:51:46 -0000 (UTC), A. Dumas <alex...@dumas.fr.invalid> wrote:
>
>Ik heb zelf een paar jaar bij een php-webshop gewerkt als backend
>programmeur, en MIJN php code was altijd super goed!! ;) Maar serieus, als
>je goed programmeren geleerd hebt dan kun je ook met php goeie dingen
>maken.

De kern van het probleem: Een programmeur die (ook) analyst is snapt wat ie moet maken kan dat vaak onafhankelijk van de
voorgeschotelde taal. Zelfs in een slechte taal (welke dan ook) zijn goede dingen te maken, net als dat je in een goede taal
vreselijke constructies kunt produceren.

Het begint bij het ontleden van het probleem dat je op gaat lossen. Dat kunstje wordt nauwelijks meer geleerd en met steeds meer
code-snippets die een stukje kunstje doen en die je overal vandaan kunt toveren wordt het niet persee beter.

[Joe]

On Fri, 27 May 2022 14:21:24 +0200, Izak van Langevelde <eeza...@studiomestenmist.nl> wrote:

>
>Klopt. In de pak 'm beet 20 jaar dat ik software heb ontwikkeld, heb ik
>mij geloof ik drie keer gebogen over performance, waarbij het in twee
>gevallen ging om slecht gedocumenteerde query optimalisatie, waardoor
>een query weken dreigde te draaien, in plaats van een halve dag, en een
>enkel geval waarin ik een bloksignaal in realtime moest decoderen, en
>waar ik in assembly heb lopen zoeken of het nog een klokcyclusje sneller
>kon.
>
>Zonder nou in te hakken op de jeugd van tegenwoordig, de meeste
>praktijkproblemen gaan niet veel verder dan 1+1=2 (en dan in euro's).
>Hooguit gaat het om performance, eigenlijk nooit over complexiteit.

Performance = geld. Snellere verwerking op dezelfde hardware maakt ruimte voor nieuwe oplossingen.

Vwb de praktijkproblemen: eens. Maar dat komt omdat de echte problemen te complex lijken voor de simpele zielen die zich
tegenwoordig met bedrijfsoplossingen bezig houden.

[Flibsy]

Ik denk het niet, want ik deed hetzelfde. Wel met de nadruk op 'zonodig'.

En Paul en ik zijn de norm.

--
Flibsy

[Izak van Langevelde]

Die dikkerd uit Cheers?

[Flibsy]

Izak van Langevelde <eeza...@studiomestenmist.nl> wrote:

De norm zonder kapitaal. Oh, dat maakt het niet helderderderder. Dan maar
niet gevat: Neen.

--
Flibsy