meuk

Same here. Generating LaTeX statically is a pain in the ass.

I think that generally speaking, women tend to be more social, and, biologically speaking, have a higher desirability (it is low-effort for men to produce offspring, but high-effort for women).

This is also why it's useful to hire new people once in a while and pay attention to what they think. A new, junior hire will note many of the same things as an expensive consultany. With the difference that people actually listen to the observations of the consultant , while they expect the junior dev to get used to things.

So you're basically judging the book by its cover? You don't care about the content at all?

That only makes sense if you're hiring a frontend developer. Many people who are excellent programmers hate frontend development, and will happily use a theme or clone a repo if they can avoid frontend work that way.

Yup, it doesn't feel exactly fair too. There's a voice inside of me that says: "It takes me almost a year to save that amount of money, and these people get it for free because they couldn't resist to spend money they didn't have?". But let's just accept that the world is not fair, and it will never be.

I still feel great for the people who were in serious financial trouble and are not anymore. Let's just hope they see it as an incentive to never be in that situation again.

Hm, I'm not a fan of Cmake. I like how simple and clean Make is. In my experience it works more often than Cmake, and if not, I can usually debug it. Cmake seems like an overengineered beast to me. But I probably haven't 'grokked' it yet.

> I gather you understand the topic, but I'm still left wondering: who is this for, and what will they do with it?

'Understand' is a big word. I've played around with Idris (which is a Haskell-like programming language that supports Homotopy type theory as well). I have a grasp of the underlying mathematics but don't really understand the stuff deeply.

Yes, I went on a bit of a rant and totally ignored your (totally reasonable) question. Theorem proving and proof checking are quite niche, both within computer science and mathematics. In computer science, the idea is that you can formally prove the correctness of computer programs to avoid software failures and have very robust programs. In mathematics, the ideal is to have

  1. A universal language for proofs
  2. A database of computer-verified results
  3. Easy verification of new results

It's a mighty interesting topic, and unfortunately, I've also found it quite difficult to get more than a shallow understanding of it.

Yup. You're 80. You spend your money on a modem, because some marketing guy tells you that's all you need to send e-mails. Then there's this thing in your room, you still have no idea how to send an e-mail, so you call tech support. Then suddenly you are the idiot, and get ridiculed.

Reminds me a lot of how narrow-minded a lot of people are in tech. Everyone who knows a bit more than you is a wizard and everyone who knows a bit less is a moron.

The premise of an axiomatized system is that you can "mechanically" check proofs. So you can also invert the question and ask "Why the hell do we still prove things by hand?".

The answer to that is that there are no good tools and no universally accepted common notation that is amendable to automatic proof checking yet. Those are problems that projects like this want to solve.

I applaud the effort really; it's hard work, and people tend to ask more critical questions ("What is it good for?" "Theorem proving is for academics only") than for any other type of program.

I'm not sure what exactly the defining quality of 'balance' is that nature does not have. In other words, I miss the point of the article.

I always saw the tradeoff more in terms of developer time: Python is faster to write but pretty much always slower to run (unless you're doing a lot of IO or mainly writing wrapper functions around compute-intensive compiled code).

I don't think a lot of people would actually use asymptotically slower algorithms when using a different language.

I'm not saying you're wrong. I'm just saying the mistake is understandable, and that you can correct someone in a polite way. Probably everyone has used terminology the wrong way, and I don't think overreacting helps your case in any way.

(I don't understand your remarks about ethnicity. As far as I know 'douchebag' is not a racial slur.)

Whoah, this covers a lot. I was expecting some linear algebra, calculus, and discrete math, but there's actually some stuff in there I don't know after doing a masters in math.

> Where are these people coming from? We were perfectly clear when we invented the term "open source" that we meant "free software", to the point of adapting the Debian Free Software Guidelines into the explicit and detailed Open Source Definition, and we've been using the term consistently for over 20 years.

Well, language is open, and confusing terminology will cause misunderstandings. Besides, there is not one definition of open source, and the most common definition has 10 criteria. You're not exactly doing anyone a service by calling someone who is not aware of all this background and understandably uses a rational interpretation of "open source" a roach. In fact, you come across as a douchebag.

(Now, I agree that intentionally abusing the term is reprehensible, but that does not seem to be the case here)

Yup, she makes great examples without sacrificing accuracy.

This visualization is also very useful when trying to understand Bayes' theorem.

> A typewriter is an excellent tool because, even though it’s slow in a relative sense, every aspect of the machine itself operates as quickly as the user can move.

For some reason, coffee machines with a built-in reservoir for coffee beans annoy me a lot more than the ones with a filter. For one with a filter, I know I have to put some coffee in it and fill the reservoir. I can determine the strength of the brew by this as well. The ones with built-in reservoirs should be able to give you a cup of coffee, but it is incredibly annoying when you have to suddenly refill the reservoir.

While the total work you do is less, the machine is unpredictable. It feels like the machine now controls you, instead of the other way around.

A lot of people are unaware of how insanely fast computers are. If you can do a computational task in a year, a computer should be able to do it well within a second.

At a previous employer, we had a test that took about 45 minutes, which most people just accepted as a fact of life. Unfortunately, we had to use this test a lot. After I optimized it (in my own time, because the team lead didn't think it had priority), it took 5 freaking seconds. Probably still far from optimal, but way more manageable.

One of the reasons I always get annoyed when I work in windows: Programs take forever, I need the mouse for everything, and god, the installation times.

I recently started working at a company where we use Linux workstations. I work on a machine where I don't have sudo rights. Yesterday I asked a co-worker if he could install a package for me. From the time of me asking and the time that the package was installed on all the workstations, there was about 10 seconds. Nice.

The minispartan FPGA devboard has HDMI in- and output and is decently priced. On the other hand, I don't think it is fast enough to process full hd (only hd, so 1280x720).

See http://hamsterworks.co.nz/mediawiki/index.php/FPGA_Projects for many examples (also using different boards).

Edit: Just realized that storing a single frame needs quite some memory. This is something you need to keep in mind. If you use the DDR RAM on the board you'll probably be find, but this is not trivial (even using the tools designed to do this).

That sounds super familiar. One time my team lead moved a meeting one day back for a week, even though I mentioned that the meeting was important every day. When we finally had the meeting, she was mentioned that I took care of it too late. In these situations I tend to be too much 'yes and amen', and I should push back some more.

> Or is it on their best interest to keep it broken?

It seems similar to a strategy they use more often, famously known as embrace, extend, and extinguish [1]:

  1. Use some standard/specification

  2. Accumulate lots of users with questionable strategies

  3. Extend/break/deviate from the specification

  4. Devs update software to cope with the undocumented Microsoft(c) behavior

  5. There is no point in following the specification or standard anymore, since it won't work in practice anyway. Microsoft effectively dictates what devs do.

[1]: https://en.wikipedia.org/wiki/Embrace,_extend,_and_extinguis...

I can't help but think that you can only do a very shallow treatment of everything in this list in a CS program. It seems like the author basically put down his own CS program as a requirements list. The style the author uses reinforces this thought, since the sections are very shallow and very closely match what I would expect from someone who did an introductory course on every subject in the list. And I'll be damned if the 11(!) programming languages "every CS major should know" aren't exactly the programming languages that the author happens to know. It would be a surprising achievement to even know just C and C++.

This post may be influenced a little by the irritation that after seven years of study and two years of work experience (and many time spent on this stuff as a hobby in my free time), I still don't match nearly 50% of the 'requirements' in this list. But hey, these lists should be taken with a lot of salt. It's pretty fun to make one and reflect on all the things you've learned. In my list, there would be more numerical analysis and less languages.

I don't understand the problem, and the article doesn't really help. If I understand correctly, universities pay a fee to Elsevier to access papers. They also submit their published papers to Elsevier. And (this is where I'm not sure anymore) they have to pay a fee to make their work freely accessible?

Then why don't they just pay for the subscription, but don't submit anything? Or upload a freely accessible pre-print version like many people do?

Congratulations on the win! Can you recommend any papers, blog(post)s, or books for the interested layman? (I am currently scanning though the facebook post, which is great, but personally I am looking for something more technical).

If that's your job, then you should, but not every programmer. At least make the title of your post "every web programmer" or "every programmer using AWS". It makes the post a lot less clickbaity.

You might consider the HiFive board. It's around 50 dollar, a more appropriate price for something to play around with.

The constraint is not on the number of neighbors directly. If there is just one node (say, A) with 4 neighbors (say B1, B2, B3, B4), we can color A red and B1, B2, B3, B4 blue. It only becomes a problem when all nodes are interconnected (i.e. the graph is complete). So, the result does imply that graphs which are not colorable with 4 colors are not planar. In particular, the complete graph (where all nodes of the graph are connected) with 4 nodes is not planar.

If you squint your eyes, the balls look red, blue, and green, but that's to be expected if there are colored bars over them. And if you don't squint your eyes, the "balls" look about the same color... So what's the illusion?

These 'every programmer should know' things should stop -- surely a web developer isn't supposed to know latency figures (or 114 pages about the details of RAM, see [1]). Likewise, most programmers don't care about AWS costs.

[1] https://people.freebsd.org/~lstewart/articles/cpumemory.pdf