1. 17

This is a curious legal thing, but it isn’t tech related at all. Maybe a better fit over at HN or Reddit.

1. 2

The “About” page suggests that what is on- and off-topic is determined by which tags exist (unfortunately? maybe incorrectly? or maybe I’m just misunderstanding). Perhaps this tag should be changed to say “tech law” if the community doesn’t want to see arbitrary interesting legal articles.

1. 2

I believe that it is understood that all of those tags function in the context of technology. Otherwise we’d expect to see (further) abuse of the culture, art, law, and other tags.

Lobsters is just as much about what isn’t here as it is what is here.

1. 5

Obviously boiling lobsters is cruel and brutal, but so is eating them. There is no “compassionate” way to eat something. If you are bothered by boiling them, take the logic a step further and don’t eat them either.

1. 8

So you think that there’s no moral difference between “quick and painless”, “slow and horrible”, and “clumsy bludgeoning”? Sounds like a pretty extreme position to me.

http://futurama.wikia.com/wiki/Suicide_booth

1. 9

I think this is a useful attempt to elucidate a somewhat confusing position on dz’s part, but that reducing a choice like this to the apparent fundamental principles rarely advances a conversation. People weigh far more things than they are even aware of, and are often not able to explain their real reasons. That’s especially true with a concern like animal suffering which is difficult to think about without having an urge to dismiss it out-of-hand to avoid having to imagine horrifying implications in detail.

Personally, I think that both killing animals and causing them to suffer are wrong. Unfortunately, they’re on the list of wrong things that all humans are complicit in to some extent, although certainly we can individually adjust the degree to which we are, through our lifestyle choices. Political slogans are simplistic because they must be, but it’s important to remember the nuance when actually talking through something controversial like this.

I see the point of a device to kill lobsters faster. But let’s not name anything on the site after it. I expect that this thread has already gotten more political, and with less relevance to the site’s core mission, than many lobste.rs users are comfortable with.

1. 3

Yes I agree not to name anything on this site after it. It would be uncool and uncrustaceanly.

1. 2

Thank you. I very much agree that there’s a lot of subtlety to these kinds of issues, and that they are worth considerate discussion in depth, but that this is probably not the right venue.

I’m still learning how to write comments that are simultaneously relevant, provocative, and concise without being glib or mean… or encouraging others to. It’s hard! Sometimes it might be impossible. I think it’s still worth practicing.

1. 2

but that this is probably not the right venue

I dunno about everyone else but I find this sentiment common and deeply disappointing.

Programmers, like it or not, must learn to tackle ethical questions. We’ve automated jobs away, built software to cheat on emission standards, designed UIs with the intent to deceive users — and any attempt to discuss these issues where programmers dwell is invariably shut down with claims of “improper venue!”

How can we expect to advance our profession if we keep proclaiming that our spaces are strictly for tech chat only?

1. 7

I agree! But let’s spend those limited resources discussing ethical questions that relate to systems we, as programmers, might be asked to build someday. I can promise you that it’s possible to make an entire career simply out of thinking about those questions, and still barely scratch the surface.

2. 3

I didn’t say that. One would prefer “quick and painless” but the immoral act isn’t the suffering, it’s the killing.

1. 5

If the immoral act isn’t the suffering then you shouldn’t eat plants, either.

1. 2

While I don’t share @dz’s moral position, I don’t see this as a gotcha! that shows it is inconsistent.

2. 2

This is a really interesting position - Is there some underlying principle on which this belief rests? Or does it just feel self-evident? For you, is there any amount of crustacean suffering that’s worth more than one crustacean death?

1. 1

So as long as I don’t kill you I can make you suffer as much as I want and it wouldn’t be immoral. I certainly see the appeal of the philosophy.

1. 1

edited: see below

1. 1

What if both things are immoral?

1. 5

There are certainly a large segment of people who think that killing and causing suffering are immoral, however this is the first time I’d ever seen that killing was immoral but suffering was not. Given that humans probably would go extinct without killing anything (plants included) usually people make the caveat “Killing is okay as long as you’re killing the beings that suffer the least”. Some go the whole fruits and nuts route, causing no harm at all, but I don’t think this is large scale sustainable. Plants only is a decent argument, but you’re still totally killing, so if suffering isn’t a moral criteria you might as well go eat whatever because I mean you’ve gotta kill you might as well kill the thing that reduces your suffering and I would have to kill like 400,000 clovers to equal one cow because biodensity.

Something tells me this isn’t the philosophy DZ has and I’m going to take a generous interpretation that they really meant that reducing suffering doesn’t mean there is NO suffering. The animal was still ripped from its habitat, deprived of a normal life, separated from any family it might have had, etc. I’m going to also suspect that DZ also feels that killing is unilaterally wrong, which is I think not a bad moral basis to aspire to. I think there is some wisdom in having that goal.

Being said, don’t make perfect the enemy of the good. If someone is going to kill and eat me, I should hope they don’t boil me alive. I would be a lot more upset about being tortured to death than I would about just being killed.

1. 3

Yes, this is the correct interpration, and I see how my post could be read differently.

3. 3

Something tells me if you were in the position of being boiled alive vs a painless death you would have more of an opinion on the matter.

1. 5

Several people here are recommending CMake as an alternative. I’ve only interacted with CMake at a fairly surface level, but found it pretty unwieldy and overcomplicated (failed the “simple things should be simple” test). Does it have merits that I wasn’t seeing?

1. 3

CMake can generate output both for Unix and for Windows systems. That’s one (good) reason lots of C++ libraries use CMake.

1. 2

CMake is pretty nice and has nice documentation. You can also pick stuff up from reading other people’s CMakeLists. For simple projects the CMake file can be pretty compact.

1. 3

I actually found the CMake documentation to be quite terrible for new users. The up-to-date documentation factually describes what the different functions do, but has very little examples of how to actually write real-world CMake scripts. There are a few official tutorials that try to do this, but they are made for ancient versions like CMake 2.6. So in order to learn how to use CMake, you are stuck reading through tons of other peoples scripts to try to deduce some common best practices.

While modern CMake is not terrible, you often have to restrict yourself to some ancient version (2.8.6 I believe is common) in order to support certain versions of CentOS/RHEL/Ubuntu LTS (and there were some big changes in CMake around 2.8.12/3.0).

Also, having string as the only data type has led to some absurd corner cases.

1. 2

I’m kinda confused - the graphs at the beginning seem to show the opposite of what the author is claiming. For a given number of executions, the shorthand (in blue) seems to take more time, not less. What am I missing?

1. 4

Looks like the axes are flipped. The x-axis is actually time taken, and the y-axis is the number of executions. The labels are wrong, too: notice how it says the “number of executions” is 0.000001.

1. 3

I was going to say something about the poor match between UB and automobile engineering, but will restrain myself.

1. 3

I stared at this for a while before realizing you meant Undefined Behavior.

1. 8

This is the third or fourth post from the last few days from yegor256; All of them have been right on the line between hilariously and terrifyingly bad advice. One of them (“How much do you cost?” I think it was called) lingered in the top spot on the home page because there were so many rebuttals in the comments. This list is not a recipe for a good career or a good life.

1. 17

The idea that the go language designers and implementors are nondogmatic is an interesting assertion to make, but it’d be better if there were a citation or an example. Certainly there are, famously, many more counterexamples, so it would be great to understand why the author has this belief. Is it from experience? Or is it from an ardent wish that it be true?

1. 9

I am a huge fan of Go, bet businesses on it, have had great successes with it, that said…

… why the author has this belief. Is it from experience?

I have no doubt that this is the truth. I believe the core team is very willing to discuss things at length, non-dogmatically with those they consider peers (language designers, researchers). But how they dealt with the community in both tone and substance was another thing all together – they set the dogmatic “no questions” (less charitably, “we are right”) tone absolutely, and the community followed.

Or is it from an ardent wish that it be true?

Or I suspect, a hope for the future. Which is fine, if your community has issues, try to change them and the change has to start from people with voices with enough reach, rsc is one of those voices.

1. 9

The go team are a bit similar to how openbsd works. If its clear you dont know what you are talking about, you will be redirected to go-nuts.

Tbh i think they are incredibly patient with lots of bad and unresearched suggestions. Good suggestiona get a great deal of consideration

2. 6

rsc is just one of the Go designers/implementers, and is probably somewhat less opinionated than, say, Rob Pike.

My guess is rsc is reposting this as much as a reminder to himself as to others. Go is probably more famous for what it expressly leaves out than what it leaves in, and so remembering to say why something was left out is pretty hard versus just saying “because that’s not Go.”

1. [Comment removed by author]

1. 4

I was surprised to come here to see a lot of objection to the Lisper’s suggestion that language designers tend to be open to talking about tradeoffs because they had to consider them during the design process. I read the point of the piece as the conclusion, asking the community to be fair and complete in talking about pluses and minuses:

But we need help from everyone. Remember that none of the decisions in Go are infallible; they’re just our best attempts at the time we made them, not wisdom received on stone tablets. If someone asks why Go does X instead of Y, please try to present the engineering reasons fairly, including for Y, and avoid argument solely by appeal to authority. It’s too easy to fall into the “well that’s just not how it’s done here” trap. And now that I know about and watch for that trap, I see it in nearly every technical community, although some more than others.

2. 5

The idea that the go language designers and implementors are nondogmatic is an interesting assertion to make

I don’t think he’s actually making that assertion - he’s saying that the conversations language designers (of different languages) have amongst each other don’t appeal to dogma. Citations, then, could really only come from specific recorded conversations amongst only language designers.

There is this slightly disappointing panel with Bjarne Stroustrup, Rob Pike, Niko Matsakis (of Rust), and Andrei Alexandrescu (of C++ and D), whose most dogmatic participant seems (to me) to be Rob Pike, but if you’re hoping for an in-person flame war, it’s not there.

1. 3

Replied something like this to dwc, but I’m surprised the focus here ended up on the Lisper saying that language designers are comfortable talking about tradeoffs because they had to wrestle with them while designing.

Seems like a nice enough anecdote and my reaction wouldn’t be to demand citations proving anyone’s thoughtfulness. But more fundamentally, the story was just a stop on the way to asking users to “[r]emember that none of the decisions in Go are infallible” and “present the engineering reasons fairly.” Hard for me to find that objectionable.

1. 10
1. prioritize projects in void
2. break a project into milestones in void
3. plan milestone in pomodoro-sized chunks in void
4. write basic protobuf files for milestone
5. write mockable messenging system (and clock, disk, io…) that plugs into either sockets/real version or a test harness that will use quickcheck to induce partitions, swizzle messages, fill disks and advance clocks rapidly in fake time
6. write correctness properties of system
7. write e2e test for milestone
8. write unit test for component
9. write component while quickcheck is blasting away, catching tons of assumptions as I go
10. when I hit pomodoro boundaries, distract myself as much as possible, prefer physical activity, let subconscious GC the problems I was thinking about a little bit.
11. load test with loghisto and opentsdb (logarithmically bucketed histograms ftw)
12. dstat, flamegraph for guiding optimization

(my projects tend to be performance-minded reliable distributed systems)

tools:

• void information organizer for the terminal
• tmux + vim
• rust / erlang / python
• opentsdb
1. 6

Wow, I’m really glad I read through this discussion section - I was recently going through a new year planning exercise and wishing I had something basically identical to void.

It’s also really instructive to read about distributed system programming specifically - I’ve recently been doing stuff at work that would benefit from a lot of this structure. Thanks for writing it up!

1. 12

I’ve written a TUI minesweeper game and a cellular automaton library, both basically scratch projects, around 200 lines. Nothing serious yet.

However, after using it for these, I think I will prefer it in the future for anything where I would have otherwise used C or C++, and where it’s possible to use Rust. I really like lots of things about it, but the most important ones for me apart from safety are:

• Traits and generics, which provide, for me, the biggest benefits of using statically typed languages. Whenever I use dynamically typed languages the thing I miss the most is the ability to specify interfaces.
• Pattern matching and good error handling mechanisms, without exceptions. This gives you a really nice sense that you’ve fully understood all possible situations at each call site when you compile your code.
• Expression-orientedness. This is mostly a personal aesthetic preference.
• Modern ecosystem features; primarily dependency management. The benefits of this are pretty obvious at this point, I think, if you’ve ever used Ruby, Node, or Pip, and compared the experience to C and C++.
• No GC - this at least gives me hope that I’ll be able to use it as a C replacement in almost every arena.

Unfortunately, since Rust isn’t yet available on most embedded platforms, I don’t see any obvious near-term major projects, so I’ll keep building toys instead. My next one may be a Rust client library for ROS.

Things that would make my life easier if they were in Rust:

• More target platforms. I want to write my home automation stuff in Rust and right now that isn’t possible.
• Better compilation times. They’re working on this but it’s still not great.
• Type-level integers. This is one of the very few remaining C++ features that would make a big difference for me if ported to Rust.
• A REPL. There used to be one, but it fell behind the current nightly build and has never caught up. This is necessary for things like Jupyter notebooks or good web playgrounds. If Rust had this I might be able to give up Python for almost everything.
1. 2

A cellular automation library? Could you elaborate on that?

1. 3

Sure - it’s basically just a trait describing what a cellular automaton’s API needs to look like, and some boilerplate for stepping through time. I also started on an easy way to visualize 1D and 2D CAs, but didn’t finish it. Next steps (apart from the visualization library) might be a function to back-drive reversible CAs, or generate rules from given state transitions.

1. 2

Ah, cellular automaton. I read automation and I was hoping you were working with cellular radios. I need some help getting started with those. Still a cool project! :D

1. 8

I took honors linear algebra in college, used linear algebra for differential equations, signals, machine learning, and robotics, used it for work, used it in my free time.

I did not understand it until I watched this series.

Video lectures can be so much more than a blackboard/whiteboard facsimile, and I hope to the gods that 3blue1brown makes more in-depth lecture series like this one, and I hope even more that other educators take this series as an example of what’s possible.

1. 12

Pages with lots of mathematical expressions tend to take a long time to be rendered with MathJAX; KaTeX is a similar tool that’s much faster: https://khan.github.io/KaTeX/