General Programming Q&A thread! Ask any questions about programming, answer the questions of other users, or post suggestions for future threads.

Don't forget to format your code using the triple backticks or tildes:

Here is my schema:

```sql
CREATE TABLE article_to_warehouse (
  article_id   INTEGER
, warehouse_id INTEGER
)
;
```

How do I add a `UNIQUE` constraint?

I'm interested in C or Go, but i'm open to ideas.

I have plenty of sh scripts i created to integrate my tools and system, so i have some experience and i don't want a scripting language like python.

My first plan is to learn the basics of the language and rewrite some of those scripts.

I think my first pick will be a script that uses ffmpeg to convert my flac files to mp3 or opus. I use sndconv -opus/-mp3 and it checks if there are flac files in the folder (i only have full albums), converts and puts in a folder named "$artist - $album".

My long term goal is to make a cli/tui music player like cmus.

UPDATE: i'm having plenty of success with Go right now. I just wrote a basic version of my music conversion script. It's just converting a music i pass as argument to mp3, but i'll keep working on it and adding functionality just to dip my toes in Go. It seems like a good language and i'm having fun!

Thanks for all the answers!

General Programming Q&A thread! Ask any questions about programming, answer the questions of other users, or post suggestions for future threads.

Don't forget to format your code using the triple backticks or tildes:

Here is my schema:

```sql
CREATE TABLE article_to_warehouse (
  article_id   INTEGER
, warehouse_id INTEGER
)
;
```

How do I add a `UNIQUE` constraint?

General Programming Q&A thread! Ask any questions about programming, answer the questions of other users, or post suggestions for future threads.

Don't forget to format your code using the triple backticks or tildes:

Here is my schema:

```sql
CREATE TABLE article_to_warehouse (
  article_id   INTEGER
, warehouse_id INTEGER
)
;
```

How do I add a `UNIQUE` constraint?

There's no doubt computer science is indeed a science, but what about programming itself? Does it fulfill the basic requirements that make something a science? I'm not an academic, just trying to start a conversation.

In many ways, programming is like Math: a means to an end. And Math is a science. Like math, programming has several fields with vastly different ideas of what constitutes programming. Because it is applied logic, programming is also provable and disprovable. There are many disputing hypothesis and, even though absolute truth is a distant dream, it is certain that some sentences are truer than others. Again, like Math, Programming has many practical applications, such as finances and engineering.

Some people consider Math a propaedeutics: not a science in itself, but a discipline that provides fundamentals to actual sciences such as chemistry and physics. The same reasoning could be applied to programming, as nothing more than a tool for computer science. I personally think there's something unique about programming and it's problem-solving methods that can be considered a field of its own.

What you guys and girls think?

An experiment I've been thinking about lately: a (recurring?) Q&A thread! Ask any questions about programming, answer other users' questions, or post suggestions for future threads.

Don't forget to format your code using the triple backticks or tildes:

Here is my schema:

```sql
CREATE TABLE article_to_warehouse (
  article_id   INTEGER
, warehouse_id INTEGER
)
;
```

How do I add a `UNIQUE` constraint?

Meta questions:

• Should I turn this into a recurring thread?
• If yes, should it be a weekly or a monthly thing?
• Should DBA and SysAdmin questions be allowed or should someone else make a separate recurring thread for these?

Hi everyone! It's been a long time since last programming challenge ^list, and here's a nice one I've encountered.

If you search for something like 7km to AU, you'll get your answer. But how is it done? I don't think they hardcoded all 23 units of distance and every conversion factor between them.

If you were programming a conversion system - how would you do it?

First of all, you have input in format that you can specify, for example something like this:

meter kilometer 1000
mile kilometer 1.609344
second minute 60
...

Then you should be able answer queries. For example 7 mile meter should convert 7 miles to meters, which is 11265.41.

Can you design an algorithm that will convert any unit into any other unit?

Edit: Some conversion rates I extracted from wikipedia:

ångström
0.1nm
astronomical unit
149597870700m
attometre
0.000000000000000001m
barleycorn
8.4m
bohr
0.00846
cable length (imperial)
185.3184m
cable length
185.2m
cable length (US)
219.456m
chain (Gunters)
20.11684m
cubit
0.5m
ell
1.143m
fathom
1.8288m
femtometre
0.00000000000001m
fermi
0.00000000000001m
finger
0.022225m
finger (cloth)
0.1143m
foot (Benoit)
0.304799735m
foot (Cape) (H)
0.314858m
foot (Clarke's) (H)
0.3047972654m
foot (Indian) (H)
0.304799514m
foot,metric
0.31622776602m
foot,metric (long)
0.3m
foot,metric (short)
0.30m
foot (International)
0.3048m
foot (Sear's) (H)
0.30479947m
foot (US Survey)
0.304800610
french
0.0003m
furlong
201.168m
hand
0.1016m
inch
0.0254m
league
4828m
light-day
25902068371200m
light-hour
107925284880m
light-minute
17987547480
light-second
299792458m
light-year
31557600light-second
line
0.002116m
link (Gunter's)
0.2011684m
link (Ramsden's; Engineer's)
0.3048m
metre
1m
m
1metre
km
1000m
mickey
0.000127
micrometre
0.000001
mil; thou
0.0000254
mil
10km
mile (geographical)
6082foot (International)
quarter
0.2286m
rod
5.0292m
rope
6.096m
shaku
0.303 0303m
span (H)
0.2286m
stick (H)
0.0508m
toise
1.949 0363m
twip
1.76310
yard
0.9144m

Video Link

I decided to post this as a text topic since IMO the video description is really important to understanding this performance:

Aug. 29, 2019 | Colin Marshall -- Dan Tepfer has transformed the acoustic piano entirely with his new project, Natural Machines. Watch the keys and you'll see this Disklavier — a player piano — plucking notes on its own. But it's not a prerecorded script.

Here's how it works: Tepfer plays a note, and a computer program he authored reads those notes and tells the piano what to play in response. Tepfer can load different algorithms into the program that determine the pattern of playback, like one that returns the same note, only an octave higher. Another will play the inverted note based on the center of the piano keys. These rules create interesting restrictions that Tepfer says make room for thoughtful improvisation. In his words, he's not writing these songs, so much as writing the way they work. To better communicate what's happening between him and the piano, Tepfer converted these audio-impulse data into visualizations on the screen behind him, displaying in real time the notes he plays followed by the piano's feedback. We dive even deeper into this project in a recent Jazz Night in America video piece.

Perhaps the trickiest part here, unlike a human-to-human duo, is that the computer plays along with 100 percent accuracy based solely on Tepfer's moves. He compares it to dancing with a robot that never misses a beat. Tepfer has to play in kind to keep the train on the tracks, but if he falls out of step, so does the computer. On the other hand, Tepfer has unlocked a new frontier of music available to acoustic piano players: He's essentially given himself more limbs to play the piano at once, and at times we see more than 10 keys pressed at a time or a sequence of notes played at seemingly superhuman speeds. It's a central idea to what innovative technology enables for us — that which is impossible for us to achieve on our own.

edit: Nice related video from Jazz Night in America with Dan explaining some of how it works:
https://www.youtube.com/watch?v=0L6tzG3FkcU

Some of you have read the Typesetting Markdown blog series (https://dave.autonoma.ca/blog/). The plan was to finish the last two parts with Annotated Text (basically markup for Markdown) and Figure Drawing (MetaPost); however, people have asked for a post on Markdown to EPUB, others have asked for high-quality PDF theme templates using ConTeXt, and some have requested rendering Markdown into HTML.

Within the realm of Markdown, digital documentation, typesetting with ConTeXt, R, externalized interpolated strings, and bash scripting, what would interest you for the next post in the series?

(Please flip through the blog series to see the topics that have been covered.)

It'd my understanding that C has stuck around in the UNIX world for so long, nearly half a century, mostly due to the inertia of legacy code.

If you could snap your fingers and magically port/fork the entire stack of open source codebases to the language of your choice, which would you pick and why?

For those who haven't seen my essay-length posts in the past, I occasionally like to delve into explaining different programming concepts, particularly with regards to making your code easier to manage. Sometimes this has to do with how you structure you code and projects, and at others it has to do with how you think about the problems you're solving. I've been in the mood to write up on yet another programming subject, but nothing in particular has stood out to me lately during the course of my work.

With that in mind, I figured I would take a different approach and see if anyone here had some specific requests for content they would like to see. Requests from all levels of experience are welcome!

(And for those who are itching to do a write-up on any of the requests that appear here, feel free to call dibs!)

Edit

For those who want to take a dive into my previous submissions, you can now find them in the new wiki entry created by @cfabbro or directly via the programming.code_quality_tips tag here.

Preface

It's not uncommon for a written piece of code to be both brief and functionality correct, yet difficult to reason about. This is especially true of recursive algorithms, which can require some amount of simulating the algorithm mentally (or on a whiteboard) on smaller problems to try to understand the underlying logic. The more you have to perform these manual simulations, the more difficult it becomes to track what exactly is going on at any stage of computation. It's also not uncommon that these algorithms can be made easier to reason about with relatively small changes, particularly in the way you conceptualize the solution to the problem. Our goal will be to take a brief tour into what these changes might look like and why they are effective at reducing our mental overhead.

Background

We will consider the case of the subset sum problem, which is essentially a special case of the knapsack problem where you have a finite number of each item and each item's value is equal to its weight. In short, the problem is summarized as one of the following:

• Given a set of numbers, is there a subset whose sum is exactly equal to some target value?

• Given a set of numbers, what is the subset whose sum is the closest to some target value without exceeding it?

For example, given the set of numbers {1, 3, 3, 5} and a target value of 9, the answer for both of those questions is {1, 3, 5} because the sum of those numbers is 9. For a target value of 10, however, the first question has no solution because no combination of numbers in the set {1, 3, 3, 5} produces a total of 10, but the second question produces a solution of {1, 3, 5} because 9 is the closest value to 10 that those numbers can produce without going over.

A Greedy Example

We'll stick to the much simpler case of finding an exact match to our target value so we don't have to track what the highest value found so far is. To make things even simpler, we'll consider the case where all numbers are positive, non-zero integers. This problem can be solved with some naive recursion--simply try all combinations until either a solution is found or all combinations have been exhausted. While more efficient solutions exist, naive recursion is the easiest to conceptualize.

An initial assessment of the problem seems simple enough. Our solution is defined as the set of array elements whose total is equal to our target value. To achieve this, we loop through each of the elements in the array, try combinations with all of the remaining elements, and keep track of what the current total is so we can compare it to our target. If we find an exact match, we return an array containing the matching elements, otherwise we return nothing. This gives us something like the following:

function subsetSum($target_sum, $values, $total = 0) {
    // Base case: a total exceeding our target sum is a failure.
    if($total > $target_sum) {
        return null;
    }

    // Base case: a total matching our target sum means we've found a match.
    if($total == $target_sum) {
        return array();
    }

    foreach($values as $index=>$value) {
        // Recursive case: try combining the current array element with the remaining elements.
        $result = subsetSum($target_sum, array_slice($values, $index + 1), $total + $value);

        if(!is_null($result)) {
            return array_merge(array($value), $result);
        }
    }

    return null;
}

Your Scope is Leaking

This solution works. It's functionally correct and will produce a valid result every single time. From a purely functional perspective, nothing is wrong with it at all; however, it's not easy to follow what's going on despite how short the code is. If we look closely, we can tell that there are a few major problems:

• It's not obvious at first glance whether or not the programmer is expected to provide the third argument. While a default value is provided, it's not clear if this value is only a default that should be overridden or if the value should be left untouched. This ambiguity means relying on documentation to explain the intention of the third argument, which may still be ignored by an inattentive developer.

• The base case where a failure occurs, i.e. when the accumulated total exceeds the target sum, occurs one stack frame further into the recursion than when the total has been incremented. This forces us to consider not only the current iteration of recursion, but one additional iteration deeper in order to track the flow of execution. Ideally an iteration of recursion should be conceptually isolated from any other, limiting our mental scope to only the current iteration.

• We're propagating an accumulating total that starts from 0 and increments toward our target value, forcing us to to track two different values simultaneously. Ideally we would only track one value if possible. If we can manage that, then the ambiguity of the third argument will be eliminated along with the argument itself.

Overall, the amount of code that the programmer needs to look at and the amount of branching they need to follow manually is excessive. The function is only 22 lines long, including whitespace and comments, and yet the amount of effort it takes to ensure you're understanding the flow of execution correctly is pretty significant. This is a pretty good indicator that we probably did something wrong. Something so simple and short shouldn't take so much effort to understand.

Patching the Leak

Now that we've assessed the problems, we can see that our original solution isn't going to cut it. We have a couple of ways we could approach fixing our function: we can either attempt to translate the abstract problems into tangible solutions or we can modify the way we've conceptualized the solution. With that in mind, let's take a second crack at this problem by trying the latter.

We've tried taking a look at this problem from a top-down perspective: "given a target value, are there any elements that produce a sum exactly equal to it?" Clearly this perspective failed us. Instead, let's try flipping the equation: "given an array element, can it be summed with others to produce the target value?"

This fundamentally changes the way we can think about the problem. Previously we were hung up on the idea of keeping track of the current total sum of the elements we've encountered so far, but that approach is incompatible with the way we're thinking of this problem now. Rather than incrementing a total, we now find ourselves having to do something entirely different: if we want to know if a given array element is part of the solution, we need to first subtract the element from the problem and find out if the smaller problem has a solution. That is, to find if the element 3 is part of the solution for the target sum of 8, then we're really asking if 3 + solutionFor(5) is valid.

The new solution therefore involves looping over our array elements just as before, but this time we check if there is a solution for the target sum minus the current array element:

function subsetSum($target_sum, $values) {
    // Base case: the solution to the target sum of 0 is the empty set.
    if($target_sum === 0) {
        return array();
    }

    foreach($values as $index=>$value) {
        // Base case: any element larger than our target sum cannot be part of the solution.
        if($value > $target_sum) {
            continue;
        }

        // Recursive case: do the remaining elements create a solution for the sub-problem?
        $result = subsetSum($target_sum - $value, array_slice($values, $index + 1));

        if(!is_null($result)) {
            return array_merge(array($value), $result);
        }
    }

    return null;
}

A Brief Review

With the changes now in place, let's compare our two functions and, more importantly, compare our new function to the problems we assessed with the original. A few brief points:

• Both functions are the same exact length, being only 22 lines long with the same number of comments and an identical amount of whitespace.

• Both functions touch the same number of elements and produce the same output given the same input. Apart from a change in execution order of a base case, functionality is nearly identical.

• The new function no longer requires thinking about the scope of next iteration of recursion to determine whether or not an array element is included in the result set. The base case for exceeding the target sum now occurs prior to recursion, keeping the scope of the value comparison nearest where those values are defined.

• The new function no longer uses a third accumulator argument, reducing the number of values to be tracked and removing the issue of ambiguity with whether or not to include the third argument in top-level calls.

• The new function is now defined in terms of finding the solutions to increasingly smaller target sums, making it easier to determine functional correctness.

Considering all of the above, we can confidently state that the second function is easier to follow, easier to verify functional correctness for, and less confusing for anyone who needs to use it. Although the two functions are nearly identical, the second version is clearly and objectively better than the original. This is because despite both being functionally correct, the first function does a poor job at accurately defining the problem it's solving while the second function is clear and accurate in its definition.

Correct code isn't necessarily accurate code. Anyone can write code that works, but writing code that accurately defines a problem can mean the difference between understanding what you're looking at, and being completely bewildered at how, or even why, your code works in the first place.

Final Thoughts

Accurately defining a problem in code isn't easy. Sometimes you'll get it right, but more often than not you'll get it wrong on the first go, and it's only after you've had some distance from you original solution that you realize that you should've done things differently. Despite that, understanding the difference between functional correctness and accuracy gives you the opportunity to watch for obvious inaccuracies and keep them to a minimum.

In the end, even functionally correct, inaccurate code is worth more than no code at all. No amount of theory is a replacement for practical experience. The only way to get better is to mess up, assess why you messed up, and make things just a little bit better the next time around. Theory just makes that a little easier.

On lobste.rs I found link to an article from Vidar Holen, the author of shellcheck. He made a fork bomb that is really interesting. Here's the bomb:

DO NOT RUN THIS.

eval $(echo "I<RA('1E<W3t`rYWdl&r()(Y29j&r{,3Rl7Ig}&r{,T31wo});r`26<F]F;==" | uudecode)

This may look pretty obvious, but it's harder than you think. I fell for it. ^twice. Can you find out how this bomb works?

Warning: executing the bomb will slow down your computer and will force you to restart.
You can limit impact of the fork bomb by setting FUNCNEST.

export FUNCNEST=3

Have fun!