hzhou

People need understand that floating point comparison at floating precision is undefined, so it is not a bug. The proper floating number representation should track its precision. Since that is more complicated and potentially performance affecting, so until then the programmer should manage the precision tracking on their own (similar to memory allocations), that is, one should do:

  if ( f_a < f_b-f_eps)
  if ( f_a > f_b+f_eps)
  if (fabs(f_a-f_b)<f_eps)

If you don't do this, then you are on your own. Sometimes it is fine, but sometimes it may give you grief, just like the dangers of other undefined behaviors.

PS: I also have a problem that people think "undefined behavior" is undefined because certain standards say so. Undefined behavior is due to lack of agreement of common sense or it defies common sense. For example, divide by zero, there is no common sense doing so, and define its behavior does not change anything. Signed integer overflow, there is no common sense agreement for that behavi

hzhou

There is no question that we need types in a programming language. The problem is, there is a mismatch between sematic types and the actual data types. The actual data types are from bottom up: either it is a white horse or it is a black horse, and if there is a horse type, a white horse is not a horse. On the other hand, our semantic types are top-down. First we are only concerned whether it is a horse, only when the situation requires, we differentiate it into white horse or black horse. This mis-match between bottom-up and top-down creates a significant programming friction.

What do we do?

First, I think we should meet in the middle. Let's all work at a default type. For example, integers, let's by default all work with int -- be it 32bit or 64bit, let's assume (for now) it is always of sufficent size and efficiency.

Next, we need the meta programming system the ability to trace the variables and allow certain variable to be upgradable to a more specific types. The meta system has to understand the hier

hzhou

In the world of complex reality, context simplifies it.

On the other hand, generalization complicates it.

Meta-subcode, another name for patterns replaces generalization to provide persistent simplification across contexts.

Characters of meta-subcode include: incompleteness, ambiguity, and lack of specific meaning. It is only defined under limited contexts. Application to an new context always requires due-deligence of checking its applicability.

hzhou

By any measure, we are in a very early stage of computing. At this very early stage, programming language is a thing on its own. It is not unusual that computer scientists trying to design the perfect language for the next 100 years. It is often to find people get into flame wars arguing about which or what is the best language. It is a typical topic to hear people want to learn specific language as a 1-year, 5-year or career goals.

But langugage is not an end. Language is a mean. I think at some point, we are going to realize that this is obvious.

As a mean, it is silly to pursue without putting it into the contexts of the ends. The ends change, from person to person, from time to time, so it is silly to believe there is perfect language.

hzhou

Perl's motto is, "There is more than one way to do it."

Python's motto is, "There should be one — and preferably only one — obvious way to do it."

Perl's way has a few requirement: you need understand your problem; you need understand your tools; you need understand that your problem is often unique and the (best) solution depends on many factors including the nature to the problem, the mechanisms of your tools, as well as your experience. Perl's way is how we solve our every day problems -- not by following templates -- by applying common sense.

Now let's say you don't really understand your problem, or more often, you don't really understand your tools. Then typically you would be forced to read manual and follow the instructions. And often, you want to fit your problem into the model that the manual of your tool describes. In this situation, you certainly would wish there is only one (obvious) way to do it.

In the early days, programmers are intrinsicly hackers, problem solvers and far in between. The

hzhou

Libraries (such as libpcre and libreadline) are just like products such as microwaves and toast ovens. And as typical consumer products, they are supposed to be simple, and they are:

#include <pcre.h>
pcre* re;
re = pcre_compile(pattern, 0, &err_msg, &err, NULL);
int offsets[30];
pcre_exec(re,	NULL,	s, n, 0, 0, offsets, 30);

#include <readline/readline.h>

s = readline("> ");

hzhou

C has undefined behavior and this used to be a non-issue. For example, divide by zero, integer overflow, etc. which you are supposed to avoid by common sense. By common sense, we never intended to divide by zero or overflow an integer, so whether they are defined behavior or not, we program the same. In the cases that we do end up dividing by zero or overflowing integer, they are simply bugs in the program. Bugs are part of programmer's life, no big deal. Note here that even these behaviors are defined, they are still bugs or errors.

Now there is another class of undefined behavior called dead code ellimination. Certain code do not have effects running them, so logic applies that why not elliminate them?

The problem here is that dead code often do have an intention. For example, certain dead code is there as a simple test and intende to trigger crash when unexpected condition occurs. Certain dead code are there as a redudancy and intend to trigger error when parts of code become inconsistent. Yes, there are

hzhou

When we choose a more complex data structure, everywhere along the chain that need access that data will need complex handling. On the other hand, when we simplify the data structure, not only we simplify at the creation time, we simplify the handling throughout lifetime, and we also simplify the destruction of that data. Consider many data structure are created only to be destroyed, that latter simplification could be significant. Of course, if we knew that, we would try to bypass the creation in the first hand, except these exceptions will also increase the complexity. With simpler data structure, we have more capacity for such additional complexity.

hzhou

It is wrong that we are solving a given, fixed grammar problem. And the problem with that is because a given, fixed grammar is the wrong problem.

hzhou

It depends on the viewpoint of what is programming. If you treat programming as a mathematical problem, then you want to attack it the Rust's way. If you want to treat programming a practical problem, then Go's approach makes a lot of sense. For practical problems, the right answer is not known and it is not even certain that there is a right answer, so it is not about correctness; it is more about attitude and philosophy. Go is pretty clear on its philosophy.

permalinkembedsaveeditdisable inbox repliesdeletereply

[–]CanIComeToYourParty 1 point 35 minutes ago

If you don't treat programming as a mathematical problem, I wouldn't want to work with you on any codebase that's any more complex than 10KLOC.

permalinkembedsaveparentreportgive goldreplied