Forgot your password?
typodupeerror

Comment: Re:Looking at the wrong part of the problem (Score 1) 391

by Half-pint HAL (#46646867) Attached to: Toward Better Programming

The original author is looking at the part of the problem that gets the most attention, but not at the part that causes the most problems. He's looking at programming languages and their expressive problems. Those are real, but they're not why large programs break. Large programs usually break for non-local reasons. Typically, Part A was connected to Part B in some way such that an assumption made by part B was not satisfied by part A.

I believe the author ascribes most non-local problems to "incidental complexity". Incidental complexity introduces bugs, which in turn make code less predictable, which causes non-local problems. Furthermore, Grainger focuses on carrying out non-destructive data transforms, à la functional programming, which alone should wipe out a large percentage of non-local problems, as you shouldn't find yourself having to chase down any erroneous value-change bugs.

In fact, Grainger's whole point is about the attitude that you express being typical -- we focus on the fixing the problems created by the imperative programming paradigm within the imperative programming paradigm, rather than simply replacing the imperative paradigm with something more appropriate.

This essay is basically what all our CS lecturers have been saying for the last 40 years....

Comment: Re:After Decades of Wondering What's Wrong (Score 1) 391

by Half-pint HAL (#46646847) Attached to: Toward Better Programming

he chose two rather bad examples. His math formula is as likely to look like gobbledygook to a non-math person as the program is.

Ah, but the thing is that the back-end that allows the formula to be shown in a mathematical notation is an abstracting backend. In current programming, the formula has a machine representation that maps to a single visual representation. Once we start storing abstract forms, we can let the IDE present it according to the user's wishes and knowledge.

Comment: Re:We Choose Framentation Over Consolidation. (Score 1) 391

by Half-pint HAL (#46646823) Attached to: Toward Better Programming

These days, I see a lot of code that CANNOT be read without using an "IDE".

... and herein lies one of computing's biggest paradoxes. We are obsessed with plaintext as being the only suitable format for code because it is "human readable", yet almost every coder on a project of any scale uses an ID with autocompletion etc. The IDE would be much easier to use if it was freed from the constraints of plain text -- rather than linear code ordering, we could order instead by dependencies, and display on screen left-to-right ordered by call when viewing the logic. Away from plaintext, we could start using standard mathematical notation for mathematical problems (see also TFA). We could eliminate most typo bugs by simply not allowing an undefined keyword or label to be used. And we could implement spreadsheet/database-style table displays for the setting of nested arrays of data, rather than faffing around with bracket-matching and erroneous commas.

We need computing to be more closely bound to the IDE.

Comment: Re:80%? A lofty goal indeed. (Score 1) 391

by Half-pint HAL (#46636999) Attached to: Toward Better Programming
I was always a pretty competent coder, but I hardly ever code these days. I'm perfectly happy thinking in logical terms -- my problem is keeping the logic in my head while I spend several days coding around the logic. When I'm fighting with syntax, eccentricities in library execution etc, I have to not only think about the problem logic, but also the language logic, the library logic, etc etc etc. This is what Grainger calls "incidental complexity" -- everything other than the problem at hand. It distracts from solving the actual problem, and it places a massive unnecessary cognitive load on the coder. It becomes frustrating and limiting, and you sometimes find at the end of the day that you haven't coded exactly what you intended to, because you were so distracted. But all that incidental complexity means that it's very difficult to unpick your code and rewrite it to what you wanted. Incidental complexity is very bad both for the experienced and inexperienced coder.

Comment: Re:Not as bigger deal as it sounds if you RTFA (Score 1) 243

by Half-pint HAL (#46628295) Attached to: Dropbox's New Policy of Scanning Files For DMCA Issues
You've never been involved in any commercial film production then: it's a long, arduous process. Or code development: it's also a long, arduous process. Perhaps in these cases it's the toolchain that's at fault, but at present, suffer you will. But there's nothing that you can do to stop your fingers hurting if you want to learn the guitar to a really high level.

Comment: Re:Not as bigger deal as it sounds if you RTFA (Score 0) 243

by Half-pint HAL (#46620581) Attached to: Dropbox's New Policy of Scanning Files For DMCA Issues

The only legal way to run this sort of service and not be liable for it's misuse is to design it in such a way that you cannot see what is being stored at all.

YANAL. The DMCA states that companies must take reasonable steps to prevent reuploading. Designing a system with the express purpose of not being able to prevent uploading would be thoroughly illegal.

Comment: Re:Not as bigger deal as it sounds if you RTFA (Score 1) 243

by Half-pint HAL (#46620557) Attached to: Dropbox's New Policy of Scanning Files For DMCA Issues

First of all, learning and understanding what it is to be human shows that we are creatures who literally NEED to create and share.

On the other hand, it could be argued by the same token that internet sharing and lolcatz-esque memes are actually a drug that latches onto that need, corrupting it and distracting us from the act of creation by giving us a false sense of achievement through constant sharing. If we take pride in posting other people's creations, we cheat ourselves of the urge to create something unique ourselves.

After all, why should I suffer hours of preparation to put something on the net and get a few dozen views, when for a few minutes work I can copy someone else's file and get a million views?

Comment: Re:Separation of Concerns (Score 1) 391

by Half-pint HAL (#46619049) Attached to: Toward Better Programming

Variable scope is a strange concept to get used to at first. It seems cluttered if you're used to explicitly defining your variables, then having those variables only available in that function. Having variables available to scopes nested in your scope is very flexible and lends itself to writing some beautiful code.

Yes, scoping is very powerful, and almost all languages use it for very good reason. The point is that in JavaScript the easiest scope to use is the effective global one (yes, it's a property of the "window" object, but as far as the programmer's concerned, "window" is "main"). The easiest thing to use should always be the safest -- the programmer should always have to make an active choice to do something the more dangerous way.

Comment: Re:Separation of Concerns (Score 1) 391

by Half-pint HAL (#46609457) Attached to: Toward Better Programming

"Environment variables" must exist, whether as a passed object (which my university lecturers favoured) or as bog-standard global variables. But as soon as environment variables are available, lazy programmers will use them as global variables. Attempting to engineer mechanisms to prevent this happening is a complete waste of time, and only makes programming more complicated. You can't just make the "wrong way" harder -- you've just got to make the right way a little easier than the wrong way. Grainger's Aurora seems to follow that principle quite well -- whereas functional programming tried to force you not to update values (destroying data) unnecessarily by making it practically impossible to do so, Grainger simply makes non-destructive data processing one step easier than destructive data processing: the only destructive action is an explicit update with the result of a non-destructive process.

The default "lazy" state is therefore the right one, so the appropriate behaviour is rewarded. Doing unnecessary destructive changes takes the programmer longer and makes the code less clear, so will naturally be avoided. But crucially, programmers are still able to do whatever they want, when they want.

Comment: Re:Do electric cars actually produce CO2? (Score 2) 330

Hydro destroys river ecosystems. For an extreme example of the effects of damming on waterways, look at France. It's a mass of hydroelectric plants and drinking water reservoirs, and its major rivers have almost all been canalised, with a network of locks and sluices to reduce winter flow to ensure that the water level is high enough for navigation during the summer months. Fish stocks in the French rivers are dangerously low, with the Atlantic Salmon now all but unknown to French anglers.

All human activity has an impact, and there is no such thing as "clean" electricity.

Comment: Re: co2? (Score 1) 330

Clouds are not made of water vapour, but of water. Liquid water droplets suspended in mid-air. Water vapour is a gas, and is indeed a greenhouse gas. Greenhouse gases allow certain infrared wavelengths through, but block others: specifically they allow the light of the sun in, but reflected/radiated heat from the Earth is kept in.

"Card readers? We don't need no stinking card readers." -- Peter da Silva (at the National Academy of Sciencies, 1965, in a particularly vivid fantasy)

Working...