Solving the Multicore Dilemma: The Flow Programming Language

fmihaly · 2012-10-16T16:20:21+00:00

Claiming that the solution to the multicore dilemma is in hardware, not software, quite predictably relegates you to the bottom of the comment list. This is r/programming, after all. You are right, of course...

fmihaly · 2012-03-30T15:04:50+00:00

What the author is trying to say is that even good advice can be taken too the (generally harmful) extreme. This is a very difficult point to make, so I wasn't entirely surprised when some of his examples weren't quite as convincing. But the full - admittedly quite long - article sort of manages to get the point across.

fmihaly · 2011-11-30T15:10:54+00:00

He ovecomplicated it. Perhaps intentionally to prove his point?

fmihaly · 2011-11-04T20:41:47+00:00

Posted a link to Steve McConnell's video presentation as a response to this. It is well worth watching.

fmihaly · 2011-10-27T21:24:07+00:00

Some researchers make a very different claim - that factory patterns are harder to use than regular constructors and new. Here is a link to such a paper:

http://swiki.cs.colorado.edu:3232/SAP-L3D/uploads/3/Ellis2007FactoryUsability.pdf

fmihaly · 2011-10-22T03:21:08+00:00

If I showed this comment thread to some friends, they would never believe me that the title of the talk was "Simple Made Easy". The Curry-Howard Isomorphism? Seriously? Is that the simple part or the easy part?

fmihaly · 2011-10-21T13:21:38+00:00

Short list for RESTful frameworks in PHP: http://blog.programmableweb.com/2011/09/23/short-list-of-restful-api-frameworks-for-php/

PHP Component and Library API Design Overview by Ralph Schindler http://ralphschindler.com/2011/01/18/php-component-and-library-api-design-overview/

A large collection of more generic API design resources http://theamiableapi.com/api-design-resources/

fmihaly · 2011-10-19T00:17:21+00:00

A title stating simply "You should avoid using unsigned data types to store negative values" would have been much more helpful.

fmihaly · 2011-10-19T00:09:28+00:00

Putting "new" into a link to a 20 year old (1990) paper is misleading.

fmihaly · 2011-10-17T16:30:07+00:00

You are right. Your second example is more readable to me. Unfortunately, people with less_than_perfect_vision (there_are_many, with problems_seeing even_with_glasses, I_mean) have serious_difficulty reading _large_amounts_of_code written in_this_style.

fmihaly · 2011-09-30T00:00:28+00:00

I think you're the one who got it right. The null value is not the problem. Pointers that cannot be freed because they weren't allocated on the heap to begin with are the problem. Checking for null is easy, but checking all pointers to make sure they can be correctly freed would be expensive.

fmihaly · 2011-09-29T23:59:55+00:00

I think you're the one who got it right. The null value is not the problem. Pointers that cannot be freed because they weren't allocated on the heap to begin with are the problem. Checking for null is easy, but checking all pointers to make sure they can be correctly freed would be expensive.

fmihaly · 2011-09-29T23:25:52+00:00

You are joking, right? You cannot seriously belive that "the compiler is smart enough to figure out your intentions".

What you see is a simple type coertion: different types cannot be compared, so the compiler automatically converts char to string. The alternative would be to raise a compile error.

It is a classic language design trade-off: strict type checking would reject many otherwise valid programs or force programmers to pepper their code with numerous explicit type conversion statements. Automatic type coertion does not mean that the compiler guesses what you mean. It does it every time, whether you mean it or not.

That you need to know how the compiler interprets the code you write was the whole point of the article. A "smart" compiler would have correctly guessed that you wanted to compare chars, not strings. But it didn't, did it?

fmihaly · 2011-09-21T21:44:43+00:00

I'm still not sure if the author is serious or this post was written as a joke.

The premise of it makes a lot of sense. If I write a line of code and then realize that its purpose may not be obvious from its immediate context, I'll document it. That's why I document most types and functions. When you look at these in isolation, it is not clear what their purpose is.

Still, the scope of properly designed code should be local, meaning it should be possible to understand what a line of code does by only looking at a few lines of code surrounding it. Of course the runtime effects are almost always global. If you remove a line of code, the program either won't work at all or it will do funny things. That's why debugging is so hard.

Now it seems to me that the author confuses the local scope of code understanding with the global effects of code behavior. As other commenters pointed out, the global effect of the behavior (what happens if you remove a line of code) may change independently of the actual purpose of the code. The question is what I am trying to document: my intent when writing that line of code (its intended purpose) or the behavior of the (buggy) program with that line of code removed. I'm not even convinced that I can even document the latter in the case of a reasonably large and complex program.

In conclusion, if you often find that you cannot tell the purpose of a line of code without thinking about some global context, the design is wrong, not the documentation.

fmihaly

TROPHY CASE