mybrid

A practical definition of Turing complete is any language that can exercise the full capabilities of the computer.

Given any two languages can do so then they are in fact, interchangeable.

"That's because no one even knows how to start doing "science" in this direction."

No true, there is an entire field of usability science. It is all still limited to experimental learnings as opposed to theoretical deterministic knowns.

Currently usability testing is only be applied to end users. There is no reason task analysis and the Jakob Neilson's 10 heuristic rules of basic usability cannot be applied to software itself. I apply the science of usability to written software.

Functional programming is inscrutable by most. Berkeley uses LISP as a flunk out class to weed out freshman.

I find it odd that given in the physical world people require different shoe sizes for different feet that in the intellectual world people believe one size fits all, or that there is ultimately a single style of code that is comprehensible. Do you really believe our brains are all the same?

The functional programming crowd will always play a minor roll in human programming and not because as you suggest, you are all superior.

But rather it has to do with how brains differ. In fact I think the very real, emotional, visceral reaction people have to functional programming is key. People who love it, love it. Everyone else is completely demotivated by it. Lost in sets of parenthesis as the say. There is little middle ground. The very emotional reaction people have speaks volumes about how the brain views programming.

Spoken language changes every day because people use words differently due to brains being different. This vexes those who are compulsive about adhering to fixed definitions and grammar rules because of some imagined ideal. The same is playing out in software. We will always be creating new languages and tweaking them and there are there will be those who believe in an imaginary ideal of what readable code is.

Ultimately I think software writing needs to mature to where written language has matured: editors. Code review has some semblance as does paired programming. But editing is far more involved. Editors can reject entire writings.

So why do we need editors in the first place? Because in order to have happy consistency a set of rules is not enough. I comes down to style: a word here, a name change there. It may not seem like much but in fact it is.

Given a language is Turing complete, meaning it can exercise the full capability of the CPU and computer, then the choice of language and style is about the human condition, a condition which is as varied as the people in it.

If one cannot write code that ones finds usable then one needs to keep searching in earnest for a better style. However, once you have a style you can appreciate your own code from years ago then it is a matter of arbitrary standards when interacting with others. You have to draw the line somewhere but lets not pretend for a second that a single writing style is ideal for everyone, or even most. Its arbitrary because without any standards you have an unmanageable chaos.

Coding software needs to catch up with usability testing of presenting software. The dynamics are equivalent. In usability theory there is no one practice for all domains. In fact, usability theory completely embraces marketing where branding is important, i.e. distinctness is highly valuable. I suggest then that usability studies be companion to software written to the same extant as software presentation. Naming is just one aspect of usability. Information architecture, or grouping of names, is one of the most important roles in usability. In his report this year Jakob Nielson did a comparison study across ten years. Usability of software has increased in every category save one: information architecture. Grouping names into menus for tasks is really, really hard. The current trend of mega-menus is no help from experience. Doing usability studies and task analysis on the code would be a huge boon to usability of the application. It would raise overall usability awareness and its value.

Sorry, this was course work for a graduate class.

In the 1990s I did research on the efficacy claims of object oriented programming versus procedural programming. This article bares a striking resemblance in the claims. Case study after case study showed that object oriented code had less bugs due to compilers catching bugs, etc. However, almost every study was similar to this report: it was a re-write from procedural to object-oriented. There exists strong evidence to suggest that throwing away ones first prototype produces the same results as to benefits comparing object-oriented versus procedural programming. The conclusion of my research was the same as others: unless one is comparing the same project written from scratch without any sharing of design or code then these studies claims are correlation, not causation.

callback, n: 1. a function passed as a parameter. asynchronous programming, n: 1. code written to manage interrupts, often called signals.

This article is exemplary of why any educated and trained developer will not go anywhere near the Javascript community.

No processes. No hangouts. No index service started without asking. Chrome on Windows is a pig. Back when I was using it then nonstop then 25% of CPU usage was pegged to Chrome. I gave up trying to manage Chrome and switched to Firefox.

Recently Firefox said they were moving away from threads to processes. I think that's a mistake. Killing Chrome was a pain at times because when it does hang all the child processes had to be killed independently. It was possible to restart Chrome with orphaned processes. What a mess.

Also, I like the implementation of profiles in Firefox much better. I have a different profile for work, home and various side jobs. Very nice.

Chrome developers are crap developers and they hide behind processes because they don't have the chops to do threads. I hate to see Firefox move in that direction. Maybe Firefox needs to since Firefox is adopting Chrome extensions. But I refuse to use Chrome because it has crappy performance and usability. Hopefully Firefox doesn't move in the same direction.

Another way of saying this is it is not science.

Usability needs to be applied to more than just the end user experience: but the entire SDLC experience.

I'm a software generalist. Fortune did a study once that where the discovered the average person has three different careers. My first was in sales, before the age of 28. Second was in manufacturing logistics working in a warehouse and MRP. Third is software. Someone else suggested blogging. My sales experience has been a great leg up over the typical programmer in human relations. 1. Figure out how to sell yourself because your competition doesn't. 2. Consult. I've owned my consulting company since I graduated from college. Having a different "job" every year actually is a good thing when one is project consulting. 3. Be prepared to interview. I interview like crazy. 4. Network with agents and agencies. Find the agency that knows how to place.

When I first started consulting I relied heavily on agents and agencies. Agencies are a challenge and it takes time to find the a relationship that knows how to put you in front of clients.

Usability matters.

Functional versus procedural programming is first and foremost a usability problem for developers. The two are interchangeable as far as being Turing complete.

I just spent a week at a Jakolb Nielson's education course on usability. I asked the executive vice-president at the company if they had branched into software development itself, sadly the answer is still no.

Functional programming for the majority of developers is not usable. The article mentions they are are targeting DSL, domain specific languages. Which is fine. For example, Haskell has seems to have found a boutique community in async, MQ world. But, from a usability perspective one is severely limiting ones pool of developers choosing a functional language.

It is fascinating from a human nature perspective that people who think in functional programming are brains are wired differently from the procedural programmer. There is very visceral reaction when either camp is asked to program in the manner they find least usable.

Ultimately I think compilers will get to a development stage where independent of functional programming or procedural programming approaches the same optimized code gets implemented under the hood.

Postgres was originally written in LISP. Ultimately Stonebraker had to make the call that if Postgres was going to get adopted widely, LISP had to go and it was rewritten in C/C++ before being open sourced. As a point of research you all might want to look into the Postgres experience.

UC Berkeley's approach to teaching computer science I believe is the correct approach.

1. In CS150 one has to build a hardware computer. 2. In another class one has to build an OS. 3. In another class one has to build a Database. 4. In another class one has to build a Network.

Education is key. Understanding the TLB inside the CPU gives one an appreciation for context switching between the only 2 users the CPU has hardwired into it: kernel and user.

Being a sysadmin is insufficient experience as education. Every developer should know how to build a hardware computer from the ground up.

Computer science at Berkeley doesn't have a "Java" class. The language one programs in changes depending on the Professor and topic. That way one doesn't get too attached to a language.

Most developers do not understand the hardware implementation of a thread, or now-a-days a docker. As a result both get used wildly incorrectly.

Threads are useful blocking on IO to keep the CPU from starving. However, switching threads simply to swap CPU bound jobs is inefficient. Just adding a thread doesn't guarantee equal service to users just like adding processes does not.

Developers are using dockers today who have no clue why they are doing so...it's just that everyone is doing it and they do not want to appear stupid.

Experience as a sysadmin is no substitution for education.

Wisdom is the product of knowledge and knowledge is often times the product of foolish mistakes.

A butterfly flaps its wings in Africa and changes the weather in California.

Unknowns is the one word answer to your question.

You have your known knowns, your known unknowns and your unknown unknowns.

We have to make decisions every day with known unknowns and unknown unknowns. Philosophy is a body of knowledge that is in built up on trial-and-error over time. Those first trials start for us when history first started. We've been building on them ever since. We still know next to nothing about consciousness. Philosophy today primarily deals with consciousness. Once we've modeled the conscious brain and can completely control and predict human nature then there truly will be no need for philosophy.