social.stefan-muenz.de

Search

Items tagged with: softwaredevelopment

Quantum Inspired Algorithm Going Back To The Source


#softwaredevelopment #algorithm #quantum #wavefunctioncollapse #hackaday
posted by pod_feeder_v2
Quantum Inspired Algorithm Going Back To The Source
 

Quantum Inspired Algorithm Going Back To The Source


#softwaredevelopment #algorithm #quantum #wavefunctioncollapse #hackaday
posted by pod_feeder_v2
Quantum Inspired Algorithm Going Back To The Source
 

Beyond Printf(): Better Logging Practices for Faster Debugging


#hackadaycolumns #skills #softwaredevelopment #debugging #libpoco #logging #printf #hackaday
posted by pod_feeder_v2
Beyond Printf(): Better Logging Practices for Faster Debugging
 

Beyond Printf(): Better Logging Practices for Faster Debugging


#hackadaycolumns #skills #softwaredevelopment #debugging #libpoco #logging #printf #hackaday
posted by pod_feeder_v2
Beyond Printf(): Better Logging Practices for Faster Debugging
 

Short essays on programming languages


I saw a link to So You Think You Know
C?
by Oleksandr Kaleniuk on
Hacker News and was pleasantly surprised. I expected a few comments
about tricky parts of C, and found them, but there’s much more. The
subtitle of the free book is And Ten More Short Essays on Programming
Languages. Good reads.

This post gives a few of my reactions to the essays, my even shorter
essays on Kaleniuk’s short essays.

My C


The first essay is about undefined parts of C. That essay, along with
this primer on C
obfuscation

that I also found on Hacker News today, is enough to make anyone run
screaming away from the language. And yet, in practice I don’t run into
any of these pitfalls and find writing C kinda pleasant.

I have an atypical amount of freedom, and that colors my experience. I
don’t maintain code that someone else has written—I paid my dues doing
that years ago—and so I simply avoid using any features I don’t fully
understand. And I usually have my choice of languages, so I use C only
when there’s a good reason to use C.

I would expect that all these dark corners of C would be accidents
waiting to happen. Even if I don’t intentionally use undefined or
misleading features of the language, I could use them accidentally. And
yet in practice that doesn’t seem to happen. C, or at least my personal
subset of C, is safer in practice than in theory.

APL


The second essay is on APL. It seems that everyone who programs long
enough eventually explores APL. I downloaded Iverson’s ACM lecture
Notation as a Tool of
Thought

years ago and keep intending to read it. Maybe if things slow down I’ll
finally get around to it. Kaleniuk said something about APL I hadn’t
heard before:

[APL]didn’t originate as a computer language at all. It was proposed
as a better notation for tensor algebra by Harvard mathematician Kenneth
E. Iverson. It was meant to be written by hand on a blackboard to
transfer mathematical ideas from one person to another.

There’s one bit of notation that Iverson introduced that I use fairly
often, his indicator function notation described
here.
I used it a report for a client just recently where it greatly
simplified the write-up. Maybe there’s something else I should borrow
from Iverson.

Fortran


I last wrote Fortran during the Clinton administration and never thought
I’d see it again, and yet I expect to need to use it on a project later
this year. The language has modernized quite a bit since I last saw it,
and I expect it won’t be that bad to use.

Apparently Fortran programmers are part of the dark matter of
programmers
,
far more numerous than you’d expect based on visibility. Kaleniuk tells
the story of a NASA programming competition in which submissions had to
be written in Fortran. NASA cancelled the competition because they were
overwhelmed by submissions.

Syntax


In his last essay, Kaleniuk gives some ideas for what he would do if he
were to design a new language. His first point is that our syntax is
arbitrarily constrained. We still use the small collection of symbols
that were easy to input 50 years ago. As a result, symbols are highly
overloaded. Regular expressions are a prime example of this, where the
same character has to play multiple roles in various contexts.

I agree with Kaleniuk in principle that we should be able to expand our
vocabulary of symbols, and yet in practice this hasn’t worked out well.
It’s possible now, for example, to use λ than lambda in source code,
but I never do that.

I suspect the reason we stick to the old symbols is that we’re stuck at
a local maximum: small changes are not improvements. A former client had
a Haskell codebase that used one non-ASCII character, a Greek or Russian
letter if I remember correctly. The character was used fairly often and
it did made the code slightly easier to read. But it wreaked havoc with
the tool chain and eventually they removed it.

Maybe a wholehearted commitment using more symbols would be worth it; it
would take no more effort to allow 100 non-ASCII characters than to
allow one. For that matter, source code doesn’t even need to be limited
to text files, ASCII or Unicode. But efforts along those lines have
failed too. It may be another local maximum problem. A radical departure
from the status quo might be worthwhile, but there’s not a way to get
there incrementally. And radical departures nearly always fail because
they violate Gall’s law: A complex system that works is invariably found
to have evolved from a simple system that worked.

Related posts

Bild/Foto{width="1"
height="1"}

http://feedproxy.google.com/~r/TheEndeavour/~3/f4HSSsYLlnk/
#johndcook #Softwaredevelopment #Programming
Short essays on programming languages

John D. Cook: Short essays on programming languages

 

Short essays on programming languages


I saw a link to So You Think You Know
C?
by Oleksandr Kaleniuk on
Hacker News and was pleasantly surprised. I expected a few comments
about tricky parts of C, and found them, but there’s much more. The
subtitle of the free book is And Ten More Short Essays on Programming
Languages. Good reads.

This post gives a few of my reactions to the essays, my even shorter
essays on Kaleniuk’s short essays.

My C


The first essay is about undefined parts of C. That essay, along with
this primer on C
obfuscation

that I also found on Hacker News today, is enough to make anyone run
screaming away from the language. And yet, in practice I don’t run into
any of these pitfalls and find writing C kinda pleasant.

I have an atypical amount of freedom, and that colors my experience. I
don’t maintain code that someone else has written—I paid my dues doing
that years ago—and so I simply avoid using any features I don’t fully
understand. And I usually have my choice of languages, so I use C only
when there’s a good reason to use C.

I would expect that all these dark corners of C would be accidents
waiting to happen. Even if I don’t intentionally use undefined or
misleading features of the language, I could use them accidentally. And
yet in practice that doesn’t seem to happen. C, or at least my personal
subset of C, is safer in practice than in theory.

APL


The second essay is on APL. It seems that everyone who programs long
enough eventually explores APL. I downloaded Iverson’s ACM lecture
Notation as a Tool of
Thought

years ago and keep intending to read it. Maybe if things slow down I’ll
finally get around to it. Kaleniuk said something about APL I hadn’t
heard before:

[APL]didn’t originate as a computer language at all. It was proposed
as a better notation for tensor algebra by Harvard mathematician Kenneth
E. Iverson. It was meant to be written by hand on a blackboard to
transfer mathematical ideas from one person to another.

There’s one bit of notation that Iverson introduced that I use fairly
often, his indicator function notation described
here.
I used it a report for a client just recently where it greatly
simplified the write-up. Maybe there’s something else I should borrow
from Iverson.

Fortran


I last wrote Fortran during the Clinton administration and never thought
I’d see it again, and yet I expect to need to use it on a project later
this year. The language has modernized quite a bit since I last saw it,
and I expect it won’t be that bad to use.

Apparently Fortran programmers are part of the dark matter of
programmers
,
far more numerous than you’d expect based on visibility. Kaleniuk tells
the story of a NASA programming competition in which submissions had to
be written in Fortran. NASA cancelled the competition because they were
overwhelmed by submissions.

Syntax


In his last essay, Kaleniuk gives some ideas for what he would do if he
were to design a new language. His first point is that our syntax is
arbitrarily constrained. We still use the small collection of symbols
that were easy to input 50 years ago. As a result, symbols are highly
overloaded. Regular expressions are a prime example of this, where the
same character has to play multiple roles in various contexts.

I agree with Kaleniuk in principle that we should be able to expand our
vocabulary of symbols, and yet in practice this hasn’t worked out well.
It’s possible now, for example, to use λ than lambda in source code,
but I never do that.

I suspect the reason we stick to the old symbols is that we’re stuck at
a local maximum: small changes are not improvements. A former client had
a Haskell codebase that used one non-ASCII character, a Greek or Russian
letter if I remember correctly. The character was used fairly often and
it did made the code slightly easier to read. But it wreaked havoc with
the tool chain and eventually they removed it.

Maybe a wholehearted commitment using more symbols would be worth it; it
would take no more effort to allow 100 non-ASCII characters than to
allow one. For that matter, source code doesn’t even need to be limited
to text files, ASCII or Unicode. But efforts along those lines have
failed too. It may be another local maximum problem. A radical departure
from the status quo might be worthwhile, but there’s not a way to get
there incrementally. And radical departures nearly always fail because
they violate Gall’s law: A complex system that works is invariably found
to have evolved from a simple system that worked.

Related posts

Bild/Foto{width="1"
height="1"}

http://feedproxy.google.com/~r/TheEndeavour/~3/f4HSSsYLlnk/
#johndcook #Softwaredevelopment #Programming
Short essays on programming languages

John D. Cook: Short essays on programming languages

 
Hey all, quick question: Are there any really good insightful videos/lectures/articles on open source business models out there? I've been dwelling over the statement that the service/support-based model is not sustainable for a few weeks and all the expert opinions I heard so far just resolve to shifting away from open source licensing in some form or another. Example: https://www.invidio.us/watch?v=T_UM5PYk9NA
#opensource #freesoftware #softwaredevelopment #foss
 

Unix Tell All Book From Kernighan Hits the Shelves


#news #softwaredevelopment #softwarehacks #belllabs #book #briankernighan #unix #hackaday
posted by pod_feeder_v2
Unix Tell All Book From Kernighan Hits the Shelves
 

Unix Tell All Book From Kernighan Hits the Shelves


#news #softwaredevelopment #softwarehacks #belllabs #book #briankernighan #unix #hackaday
posted by pod_feeder_v2
Unix Tell All Book From Kernighan Hits the Shelves
 

Computational survivalist


Some programmers and systems engineers try to do everything they can
with basic command line tools on the grounds that someday they may be in
an environment where that’s all they have. I think of this as a sort of
computational survivalism.

I’m not much of a computational survivalist, but I’ve come to appreciate
such a perspective. It’s an efficiency/robustness trade-off, and in
general I’ve come to appreciate the robustness side of such trade-offs
more over time. It especially makes sense for consultants who find
themselves working on someone else’s computer with no ability to install
software. I’m rarely in that position, but that’s kinda where I am on
one project.

Example


I’m working on a project where all my work has to be done on the
client’s laptop, and the laptop is locked down for security. I can’t
install anything. I can request to have software installed, but it takes
a long time to get approval. It’s a Windows box, and I requested a set
of ports of basic Unix
utilities
at the beginning of
the project, not knowing what I might need them for. That has turned out
to be a fortunate choice on several occasions.

For example, today I needed to count how many times certain characters
appear in a large text file. My first instinct was to write a Python
script, but I don’t have Python. My next idea was to use grep -c, but
that would count the number of lines containing a given character, not
the number of occurrences of the character per se.

I did a quick search and found a Stack Overflow
question
“How can I use the UNIX shell to count the number of times a letter
appears in a text file?” On the nose! The top answer said to use
grep -o and pipe it to wc -l.

The -o option tells grep to output the regex matches, one per line.
So counting the number of lines with wc -l gives the number of
matches.

Computational minimalism


Computational minimalism is a variation on computational survivalism.
Computational minimalists limit themselves to a small set of tools,
maybe the same set of tools as computational survivalist, but for
different reasons.

I’m more sympathetic to minimalism than survivalism. You can be more
productive by learning to use a small set of tools well than by hacking
away with a large set of tools you hardly know how to use. I use a lot
of different applications, but not as many as I once used.

Related posts

Bild/Foto{width="1"
height="1"}

http://feedproxy.google.com/~r/TheEndeavour/~3/FlB6bwZIEcA/
#johndcook #Softwaredevelopment #Programming #Unix
Computational survivalist

John D. Cook: Computational survivalism

 

Computational survivalist


Some programmers and systems engineers try to do everything they can
with basic command line tools on the grounds that someday they may be in
an environment where that’s all they have. I think of this as a sort of
computational survivalism.

I’m not much of a computational survivalist, but I’ve come to appreciate
such a perspective. It’s an efficiency/robustness trade-off, and in
general I’ve come to appreciate the robustness side of such trade-offs
more over time. It especially makes sense for consultants who find
themselves working on someone else’s computer with no ability to install
software. I’m rarely in that position, but that’s kinda where I am on
one project.

Example


I’m working on a project where all my work has to be done on the
client’s laptop, and the laptop is locked down for security. I can’t
install anything. I can request to have software installed, but it takes
a long time to get approval. It’s a Windows box, and I requested a set
of ports of basic Unix
utilities
at the beginning of
the project, not knowing what I might need them for. That has turned out
to be a fortunate choice on several occasions.

For example, today I needed to count how many times certain characters
appear in a large text file. My first instinct was to write a Python
script, but I don’t have Python. My next idea was to use grep -c, but
that would count the number of lines containing a given character, not
the number of occurrences of the character per se.

I did a quick search and found a Stack Overflow
question
“How can I use the UNIX shell to count the number of times a letter
appears in a text file?” On the nose! The top answer said to use
grep -o and pipe it to wc -l.

The -o option tells grep to output the regex matches, one per line.
So counting the number of lines with wc -l gives the number of
matches.

Computational minimalism


Computational minimalism is a variation on computational survivalism.
Computational minimalists limit themselves to a small set of tools,
maybe the same set of tools as computational survivalist, but for
different reasons.

I’m more sympathetic to minimalism than survivalism. You can be more
productive by learning to use a small set of tools well than by hacking
away with a large set of tools you hardly know how to use. I use a lot
of different applications, but not as many as I once used.

Related posts

Bild/Foto{width="1"
height="1"}

http://feedproxy.google.com/~r/TheEndeavour/~3/FlB6bwZIEcA/
#johndcook #Softwaredevelopment #Programming #Unix
Computational survivalist

John D. Cook: Computational survivalism

 

TinyGo Brings Go To Arduino


#arduinohacks #arm #softwaredevelopment #bbcmicrobit #go #golang #tinygo #hackaday
posted by pod_feeder_v2
TinyGo Brings Go To Arduino
 

TinyGo Brings Go To Arduino


#arduinohacks #arm #softwaredevelopment #bbcmicrobit #go #golang #tinygo #hackaday
posted by pod_feeder_v2
TinyGo Brings Go To Arduino
 
 
Dear hivemind with strong feelings about open source software,

Which Linux Distro would I choose for work (software dev) nowadays?

- stable, not too heavy on maintenance
- fairly recent software
- I know arch and debian-like systems

#Linux #Debian #Arch #SoftwareDevelopment
 
I have deleted
The commented out code
That was in
The legacy codebase

And which
You were probably saving
For god knows what

Why did you do this
We have
Version history

Cole Townsend
#SoftwareDevelopment #Programming #RevisionControl
 
I have deleted
The commented out code
That was in
The legacy codebase

And which
You were probably saving
For god knows what

Why did you do this
We have
Version history

Cole Townsend
#SoftwareDevelopment #Programming #RevisionControl
 
Later posts Earlier posts