leovonl

That's quite an achievement, and I'm even more impressed he was able to do so in the textile industry that suffered so much in the mid-nineties in the region.

Context: I'm from the Itajaí Valley (where Brusque is located), which has a strong textile industry - one of the main drivers of the local economy. It used to be much stronger until the disastrous Collor government caused a number of them to go bankrupt or severely reduce their production due to some serious mismanagement of the Brazilian economy.

Edit: His original employment contract can be found here (in Portuguese, a bit difficult to read): https://www.brusquememoria.com.br/acervo-imagem/2057

It makes zero sense to look at nationwide average for Brazil to draw any conclusions without looking at per-state or per-region data.

Northern region has places with 60+ homicide rate, southern region has places with 3-4 homicide rate.

Take a look at this article: https://pt.m.wikipedia.org/wiki/Lista_de_unidades_federativa...

And this map with some of the highest/lowest homicide rates: http://55ca7cd0-f8ac-0132-1185-705681baa5c1.s3-website-sa-ea...

Both in Portuguese but I think it's not hard to make sense of the numbers (rate is 1/100k, map colours describe increase/decrease in violence, bottom lines show current top/bottom rates in cities with 100k+ residents).

Nothing new on this, experienced programmers know the performance implications of data structures (ie, lists are generally bad regardless of the language/paradigm) and most complains about language itself can be read as "I'm not used to this way of writing code". Which is fine, but it is an opinion not exactly a fact or a piece of knowledge.

OCaml itself is not a new language and they are probably not going to break compatibility to fix minor syntactic issues now - even the new ppx system was introduced in a way to not interfere with the current syntax. TBH I find it a very minor annoyance compared to all other more things the language has to offer.

Generally, a big improvement in ability to focus, and a sustained mental clarity throughout the day.

Entering in ketosis was also an watershed moment, like an epiphany, with a sudden feeling of increased awareness. But it's hard to describe precisely, and I guess YMMV.

His reading is simplistic, but so is the article: there is no mention about different metabolic states, for instance.

The brain depends on a very small quantity of glucose to function - it arguably is more efficient with ketone bodies, for instance [1] - so covering not only glycolysis seems like an incomplete research.

[1] https://blogs.scientificamerican.com/mind-guest-blog/the-fat...

The study doesn't mention this anywhere, but one can assume it considers only a state of glycolysis. This makes the the title/conclusion a bit misleading.

In case of ketosis [1], the brain mainly relies on ketone bodies for fuel.. I'm curious about how one's brain would perform in such state - judging by personal experience, the results would be very different.

[1] https://en.wikipedia.org/wiki/Ketosis

I would say it is not only valid but a very interesting method to deal with 0-day exploits and automatic scanners.

I have a number of services running at home, all outside the standard ports - sip is on 5099 (remote gateway is on 5088), SSH on 5225, etc - and the difference in the number of attempts to log into my box (and make international calls..) is huge - actually, I did not have a single attempt to put a call through my asterisk box since I changed the ports outside the default range.

Of course, it's not the only security measure, but I'd argue it can be as important and as effective as any other.

Social welfare is not socialism.

Having grown up in Brazil, where computers and parts are expensive - and in a time where the country was recovering from a galloping inflation and a failed attempt from the government to cut it back by freezing everyone's saving accounts - I can very strongly relate to this.

In fact, I think most brazilians of my generation which share same taste for building things are used to prototyping things with "a lot of duct tape" and reusing parts by disassembling unused/old toys, small machines/appliances, etc, and reusing what they can to make something new.

About the "gambiarra" term, it has a lot of connotations associated (some bad), but it also carries an idea of "subverting the original intent of the designer" or "subverting the intended usage of the parts/pieces". Which is why it fits perfectly in the idea of "hacking" for repurposing and recycling.

> And I can actually not remember a single time when this was actually useful [..]

This tells a lot about what is wrong with software development and why industry is constantly plagued with security issues, misbehaving systems, buggy behaviour on edge-cases, etc.

There was a thread on HN some time ago about software engineering, and I remember mentioning that if "software engineering" was really to be taken seriously, we'd be using theorem proving to guarantee software is correct.

The best analogy is the bricklayer vs structural engineer: you can build something simple very quickly without really putting too much thought about soundness, but once you go past a few floors the risks are too big to be ignored - which is why we have the latter.

It usually boils down to cost - some people like to spread the idea that formal methods are sorcery or are limited in scope, specially people outside of computer science that have no strong background on mathematical methods, which sometimes do a disservice to the efforts of researchers and the ones that had exposure to the theoretical foundations of CS.

In any case, I don't want to go on a huge rant here - so if you don't know, it doesn't hurt to spend some time reading about modern tools and applications for this, maybe even playing with available tools, and.. who knows, maybe learn something new.

Sorry, but I strongly disagree.

I can think of two very strong reasons to prefer awk over perl:

* busybox implements awk, so its (usually) available even on embedded platforms

* awk syntax is way clearer than perl, anyone that has a few experience in C + shell can figure out what is being done with some googling

awk is also powerful enough to separate output to different files, accumulate inputs, etc. And if you need anything more complex, there are tons of other languages to choose from then (including perl).

It's an excuse that is commonly given - but easily avoidable if you care enough about the ones that pay your salary by buying processors from your company.

And not only that, but they did much more than the average Joe and essentially pin-pointed the issue for them. So yeah, inexcusable it is.

Computer Science is a science field, therefore computer scientists usually see themselves as something more than an engineer - you don't want to apply the same knowledge over and over to make something exactly as the known knowledge tells you to do, you want to try new things and experiment with new ideas. That's the general mentality of the degree by itself.

Real "software engineering" would have to be done with Agda, Coq, or similarly tools - theorem provers that guarantee your solution is sound. It is done that way for software that absolutely cannot fail (eg, aerospatial). Unfortunately, engineers are usually too far away from this kind of knowledge - and sometimes even doubt this is possible or doable, even if you direct them to the research (!).

By the way, software engineering disciplines are usually depressive OO garbage, frameworks and all that non-sense that comes with excessive Java usage, and frankly never teach anything about reliability or even proving programs correct - which should have been their primary goal.

This classification of "paradigms" is a bit off.

First, declarative programming is a generic name which includes a broad range of paradigms - from functional to logic programming. Logic programming is something that deserves a special mention and discussion, because there are a number of interesting and unique concepts that deserve a more in-depth explanation.

Second, "dependent types" is better understood as a feature of a language (or better yet, of a type system) than a paradigm by itself.

Some of the other "paradigms" also seem more like characteristics of languages, and not really something that structures the way solutions are expressed/understood.

I suggest adding a "in US or UK" to the title.

Nothing wrong, I'd love to use taxis. But I have a few conditions:

* I want to call a driver and know if the ride was accepted, if the car is coming, how much time it will​ take for it to arrive, all in realtime... and specially, I want feedback if the ride is cancelled;

* Not to be called names if the ride was too short;

* Be able to rate the driver and know that anything I complained about would be taken seriously;

* Pay a fair amount for a decent service.

There are a number of taxi companies that are already doing apps and such. I think this is great. I have no such options where I live, therefore... Uber.

You article about hiring a C++ developer made me chuckle on the interviewees' answers; apart from the "virus" one I've also heard all the others - and had the same thoughts. You'd think that one would prepare a bit more before being interviewed, but I guess that's more common that I expected.

By the way, I really liked your interview questions; very straightfoward and to the point.

Something I usually ask when interviewing is the difference from C and C++ - specially if the résumé lists "C/C++" instead of separating both - as many people view C++ as a "C with classes".. which is not a fifth of what modern C++ really is.

It's amusing to read all these calls for a more democratic EU, specially when comparisons with the USA are made.

EU membership is voluntary, you can leave if you want. What would happen if an USA state decided to leave? Check the history books.

Truly democratic nations respect self-determination principles. In this sense, USA is closer to the authoritarianism of Spain than to democracies like Canada or the UK itself.

How can one compare UK and US and say the later has better social mobility? Ever heard of NHS (1) or council housing? Have you compared tuition fees on both countries?

While I mostly understand the different atmosphere on both places, and even agree with some of the points, I have to say the author had to be pretty immersed in a very particular bubble to have come to this conclusion - which does not seem to fit reality as all.

(1) Yes, NHS has its problems, but US simply does not have anything like it.

"When we've initially started [..], dominant was Go 1.3, which had mechanisms to detect memory blocks allocated inside used libraries and all such blocks were to be freed by GC. Go 1.6 significantly improved its memory management, however as part of those improvements memory allocated by external libraries was no longer garbage collected by the runtime."

This looks like a serious API break.

To be fair, the whole idea of the runtime automagically managing external memory gives me shivers, and this looks like moving in the right direction - I just think it was not very wise to go with that initial decision in the first place.

Latency and speed are two very different things. For good audio quality, the first is way more important than the later.

Also, lossy codecs usually drop a good chunk of information in favour of compression, working with larger packets for better efficiency and adding even more latency. In that sense, G.711 or higher-quality PCM is the best if you want lowest latency possible.

I've worked for some time with telecom to know that each time you add a complex codec (G.72x) you may end up doing a few conversions on the way: in most gateways, if audio comes in as codec X, it gets converted to PCM internally and then re-converted to codec X again before going to the other end. Adding bypass logic adds little benefit as you have to scale the system for worst case scenario (all channels performing the costlier compression), so bypass only complicates your code.

So those "X ms of algorithmic latency" for complex codecs may end up being multiplied a few times: throw in echo cancelling, jitter buffers, etc and you get a call where you end up interrupting each other all the time due to audio delay.

My experience with endorsements tells they can be not only deceiving, but also a trap.

There's this guy which I used to work with that was not very good in the job and used to distract others at work very often, not being really productive most of the time - but he was generally nice to everyone, so nobody really disliked him.

He ended up leaving the company, and was hired by another company which we had business with. After some time, his new employer called our boss to tell he left, taking with him all the code of the project he was and starting a company by himself with this code.

This may seem bad already, but it was not the end: a few years later, the guy comes back asking me for recommendations on LinkedIn - when I checked his profile, I found he got a lot of code from the first company as well - where we used to work together - and put on his Github, with copyright headers stating he was the author. In fact, he did that with code I personally wrote.

Of course, I didn't endorse him - but if I go to his LinkedIn page today, there are tons of recommendations by ex-colleagues, including recommendations for things that he barely worked with.

And this is just one example. Most co-workers I have or had that were really good in what they do have zero to a few recommendations, and usually in very specific stuff that don't every start to cover their knowledge.

So, my advice is: if you use LinkedIn recommendations to anything serious, you are doing something wrong.

SOS was meant to be easily recognizable and trivial to generate:

    ... --- ... --- ... --- ... (and so on)

Indeed, in the later case, exceptions are really an unnecessary cost.

In fact, another argument which could be made against the use of exceptions is that the abstraction per se is not a really good mechanism for abstracting error handling. Explicitly handling errors - including try!() à la Rust and/or monadic composition of functions - usually leads to a better error coverage, as safety is enforced by the type system itself.

Usually anything that deals with theory of computation, formal languages, formal methods, compilers, graph theory, functional programming, logic programming.

I assume numerical analysis, probability and even assembly are subjects most people from engineering would already have some familiarity with.

More specific subjects include relational algebra (for relational databases) and AI concepts like neural nets.

I sometimes find it hard to discuss some subjects with some of my co-workers that don't have some degree directly related to computer science.

For instance, it's very common for electrical engineers to work on software development and they tend to have a good grasp of how things work in the lower level, but when you start moving up in the abstraction ladder, the discussion starts to become harder. Compilers, types, and generally anything that is more related to math or "formalization" is not within their standard knowledge.

It could be argued the same could be said about some with CS degrees as well - category theory, what? - but that usually is a sign of a lacking education. A good electrical engineer does not need to know about context-free grammars, same cannot be said about a good computer scientist.

This is usually a problem when discussing solutions: "How are we going to solve problem X?" tends to be approached by a computer scientist from the POV of algorithms and the concepts involved (for instance, CAP for distributed systems, and how to deal with conflict resolution, etc) and then search for tools that match the criteria. OTOH, most of the time people that don't have the understanding of this area would want to choose a tool that best fits the problem by its description, without thinking about the underlying algorithm and the implications or trade-offs.

I also had some issues when discussing languages and paradigms - it's hard to evaluate the available options when you can't see the concepts and understand what they provide you with. Most engineers don't have the slightest idea of what is logic programming, though it is essential to a good number of fields in science and industry.

Either way, I don't think anyone should be forced to have a degree to be able to work with software, only reservation I have is when people say it doesn't make any difference, as "programming is easy, anyone can do it and understand anything without formal education". Sure, surgery is also easy... the hard part is to keep the patient alive.

This seems to be a simple RTFM issue to me: POSIX specifies that gmtime() uses UTC and localtime() uses current timezone. Using gmtime() would implement the desired behaviour without any need to hardcode environment variables.

First hand 5-year experience with embedded and C++ here.

I used to work with a big C++ codebase which implemented ISDN/R2/SIP stacks (and a few more protocols), running inside an embedded ARM. Now I mostly work with a C codebase that does similar things.

I can say with good confidence that most of what was written on the article about compiler flags, etc, can be regarded as premature optimization - ie, you just need to start from this point if you know your environment is really constrained and exceptions are too much of a cost - which is usually not the case in modern embedded ARM systems.

About the advantages, I completely agree with the safety issue. Reuse is also much easier - using generic programming concepts to better encapsulate your abstractions, including functions acting on different types (templates), you can rely on sizeof and/or properties of the types themselves to specialize the proper behaviour. All without having a single virtual/dynamic dispatch. And modern C++ is making this much easier to use.

TBH I never used a single virtual in any of my code, though we used to have that in a few places in the whole stack away from the performance-sensitive code paths.

Comparing to C, there's a lot of repeated patterns in the code I work nowadays, and it's a bit frustrating as I can't really abstract them sometimes, and there's some repetition of similar algorithms in different places. You can start doing callbacks, some ugly acrobatics with macros, and some other alternatives, but the code then becomes unreadable, a minefield, or both.

Funny how the "proper" first example still has a lot of things to be addressed, like the fact that it has a magic number (7) coming from nowhere, which is duplicated a few times as well.

It would be way less error-prone to calculate the number of elements using sizeof, for instance. This would also make the function independent of the type (a template could be used), thus reusable in another contexts.

In 2004, I wrote the first article about a well-known but not very popular brazilian singer in the portuguese Wikipedia. I spent the whole weekend on it, citing references, finding dates, listing albums, etc.

A few years ago I went back to find the article much bigger... but it was utter crap. The text was nowhere near unbiased, barely touched facts and seemed more like a bedtime story about flying saucers than a wikipedia article per se. There was more content indeed, but most data was obscured by something that didn't looked at all like an encyclopedia article.