mybrid

I have another question, is profit a motive for HN? It does not appear to be. Before HN there was slashdot.org, whicj is still around. Slashdot lost the thread I think because of revenue concerns and change of ownership. If this place is truly 100% a finacial loss then it does seem to validate yet again that news for profit is a bad idea because the news is soon compromised in the name of more viewership to drive ad revenue. If Reddit went 100% loss then I'm sure better moderation decisions would be available to them, likewise for Twitter and Facebook.

Well met. Just curious if one has approached this site from a usability perspective? For example, one formality in usability studies is that of personnas. The name "Hacker"suggests a preconcieved personna? Who is this hacker? My usability and marketing spidey senses tell me hacker embodies on one hand a elite group of programmers and on the other hand a lawless band of brigands? Have you ever conducted studies on how just the name Hacker alone gates this community? Who shies away from this place and who doesn't? I highly recommend courses by NNG for usability. The word hacker certainly has stigmas associated with it. The last study I read from NNG concluded that while many gains have been made in usabilty in the last decade, their findings were that IA, information architecture, lags significantly. IA is about word choices. If I saw an application menu with the word Hacker as a selection I would definitely flag that for review? Also I enjoy the site and Happy New Year!

Thanks, you gave more information than is being publicly disseminated. I'd like to see CDC publications on the long term bounds cited. Random people on the Internet is not compelling. Also, mRNA vaccines have been ongoing for years. We need better communication on why now other than we're really smart, now, and the gov. spent billions. If that is all it took we'd have cured cancer long ago.

The only problem is from a communication with the public is that as many people has physically possible will be vaccinated. How is this "emergency" approval any different then a general approval if the end result of the same?

" but given the circumstances, the risks posed by vaccination for the general public are outweighed by the benefits. "

That's the problem, we don't. We don't know what the risk is long term, it is unknown. It is illogical to say that an completely unknown risk has any logical comparison.

How do they classify something like this as safe for the long term if long term experiments are not conducted? Is there any substitute for time trials for drugs other than these new vaccines? These are the questions my relatives are asking me and my answers are I don't know, I don't. The scientific community needs to do a better job of communication. Why are we confident that a trial of only three months is sufficient when the only efficacy test for long term effects is long term trials?

DRY is just a another way of saying the best practice of don't reinvent the wheel. The difference being reinventing the wheel is applied to third party packages and DRY to you own code. The friction from blindly applying both is the same, dependency. This is especially apparent in JavaScript where literally thousands of dependent libraries can be pulled in and any two version incompatiblies can break the build. Pulling in any dependency usually means pulling in orders of magnitude more lines of code then will be used. The inert code relative to one's use can be subject to version incompatiblies and security patches no different than any other code. It can also be subject to build differences such as numpy and pandas being non-native Python and native Python libraries exist for many limited use cases. Of course none of this is an endorsement of cut/copy/paste development. However, it is an indictment of cut/copy/paste enforcement of DRY and the more general don't reinvent the wheel.

Firefox on Android still only has 10 Add ons. Ten. It just seems to me Mozilla is deliberately killing Firefox off.

But hey, the NASDAQ and DOW are setting historical records. Nothing to see here, move along.

The crux of the problem is that for much of the US population any porn is unethical and immoral. Since the advent of the Internet the % of population declaring no religious affiliation has jumped by 25%. Once the US hits near 50% non-religious population then the fights are really going to begin about social norms. The struggle is much larger than just porn norms, but all norms.

The law of unintended consequences applies. By not not processing porn payments the credit card companies force porn companies to generate revenue via advertising that works best if they give the content away for free. My surprise here is that Pornhub was able to process payments via Mastercard and Visa as I was under the impression that all porn was rejected by them already. https://www.vice.com/en/article/kb7ak9/the-secret-censorship...

npm is terrible. Why? because the color and formatting outputs all kinds of escape characters. Guess what happens when Jenkins or other build systems try to render spinning ascii characters? What happens if color and spinning punctuation is allowed then developers who use configuration files for things like npm promote them to build with color escape character output enabled. It creates a mess of configuration files keeping separate build and development just for escape character configuration. My advice is no color and no escape characters if your CLI will ever be part of a build chain or is intended to output to logs. All it takes is for one usage to a log that doesn't have '--no-color' and the binary characters will trip up diff and other tools that only work on text.

Ouch! My eyes! What is up with the Mark Up web site? They seriously need to hire the Norman Nielson Group to give them usability feedback.

Given 'pwd -P' may very well print out a different but equally usable path then it brings to my mind the need for two separate commands: rwd "relative working directory" (no sym link resolution) awd "absolute working directory" (sym link resolution)

Also, "pwd -A" where A means ABSOLUTE is easier to remember than "-P" for physical. I never hear anyone talk about physical directories. When people are talking about resolving sym links they talk about absolute versus relative paths. Seems like a good historical research topic to understand why the canonical usage is "physical" that no one uses versus relative/absolute paths that are actually used.

Opinion is not fact. Given this is Scientific American should we expect something, say, more scientific?

Let's put this under the heading, "One Size Does Not Fit All".

The underlying assumption of this opinion is that there is only one model to teach too.

In the modern era we really need to take into account our differences.

In this case, functional versus procedural programming.

1. Write this in a Lisp as functional.

2. Present the functional form as human readable as the given procedural.

3. Conduct a study and gather the data.

4. Present the findings.

My experience has taught me that there is subset of the human population who think more naturally in functional programming.

But if one model is insufficient? then why would two be?

What languages are yet to be invented to meet the needs of the millions of daily programmers?

It is time for experimental science to be conducted given the millions of people involved.

The path has already been laid out with Usability research that is entirely experimental.

It is time to do the hard science on usability of claims of functional and procedural programming languages.

It is time to put to rest opinion and one size fits all.

"Semantic is a development framework that helps create beautiful, responsive layouts using human-friendly HTML."

Claims made without evidence can be dismissed without evidence.

I'm not singling out Semantic UI here except to say that usability studies validate beautiful, responsive layouts using human-friendly HTML.

Has anybody done a usability study to confirm any such claims?

Again, not singling out Semantic UI except to point out an opportunity. Semantic UI could be the first to quantify this by providing usability study support rather than just putting it our there.

https://www.nngroup.com/

This kind of question is meaningless in my opinion without the workload being defined. For example, is this for transaction processing like for banking or web programming of social networking like with Facebook?

One also needs to consider the entire landscape. For example, the LAMP stack is mature community with out-of-the-box, ready-to-ship web sites. There exists lots of support and tools. Software stacks like Django for Python typically have community involvement for a particular database. If one is using an ORM like SQLAlchemy, what is SQLAlchemy best used with?

Here are just some of the things that should be qualified when asking database choice:. 1. Transaction support. 2. Scale out support. 3. NoSQL and other data store integration. 4. Cloud support if deploying in a cloud. Really depends on your cloud vendor. 5. Location, location, location. Is this an internal application on your company LAN, or a social networking application to be installed around the world? Replication in MySQL quite useful. 6. SQLite? Why did you exclude SQLite? I'm assuming because the person posting this question already knows something about the workload that defeats SQLite? What is that workload? Testing against SQLite is trivial, just create an in memory database. 7. ETL support. Are bulk updates due to ETL processing of files and such common place? Bulk updates happen better when indexes are not attached, etc. 8. Reporting support. 9. Denomalized versus normalized support. It is common place in web applications with data distributed applications around the world to shard a database table, completely denormalized.

The point is that designing a database schema is heavily dependent on the expected workload. The choice of SQLite, PostesSQL , MySQL, SQL server, Oracle or what have you depends heavily on the workload. It is nonsensical to ask what the right tool for the job is without knowing the job.

Follow the money. The notion that databases have failed the web was put to Mike Stonebraker of Ingres fame at a seminar I attended back in the late 1990s. The actual question was this: "Why aren't database vendors building object oriented databases for the web?"

Object oriented databases store binary objects as opposed to object-relational databases Mike pioneered with Postgres. The plan was for CORBA, common object request broker architecture, to shuffle versioned objects around the web and object oriented databases would store binary code objects.

Mike's answer? "Because the money is in transaction processing. Banks pay millions of dollars for transaciton systems. Transactions are the meat-and-potatoes of database sales."

In some sense database companies are wise for ignoring the web. Web companies are now hell bent on "move fast and break things." A transaction database is the antithesis of move fast and break. Transactions move deliberately with consistency. Durability says I can unplug my database at any time and bring it back up. This is the opposite mind set of move fast and break things.

Here in the valley whole QA departments are being disbanded in favor of LEAN and move fast and break things. All of this is antithetical to the database world of transaction processing.

At they say: you get what you pay for. What the enterprise companies are paying for is exactly what is being delivered. Open Source fits the every changing, move fast and break things of the web world.

To whit, you might see database vendors move into the web space some day if in fact companies are willing to pay millions of dollars for them.

Thanks! for the paper reference!

This article reminds me of a couple of things.

1. Wasn't Feynman the one who was promoting replacing classical mechanics with relativity for freshman physics? How has that turned out?

2. Fuzzy logic makes a similar argument. Bart Kowasaki down in San Diego I believed proved mathematically that fuzzy logic equates Calculus and Nyquist equations. I'm probably not getting that quite right. But, Fuzzy Logic was called the "cocaine of math" and yet the Japanese have done quite well in using fuzzy math in software and manufacturing. The arguments put forth here about why every developer should learn category theory smack of the same arguments that have been made about Fuzzy logic and why fuzzy math should be taught in elementary school. I personally like and use fuzzy logic for programming but wide spread adoption of fuzzy logic never took hold. From what I've read of Category Theory, Fuzzy Logic seems to have a better argument as a programming shift because Fuzzy is a lot less abstract. Just start with a bunch of if statements that approximate the math.

I think the scope of this trolling concern needs to be expanded to include the latest science on confirmation bias and cognitive dissonance.

The fake news of Hillary running a child prostitution ring out of a pizza parlor is an example of where people are creating protected spaces for confirmation bias online. Such a story is ludicrous. After Trump won the alt-right created a coded language where common words are substituted for slurs. It is human nature for birds of a feather to flock together and part of this includes creating a negative environment to weed out all but the most dedicated. This human behavior can be found at executive levels at Fortune 500 companies where cussing and swearing not allowed at the employee level represent barriers for people, most notably women, who don't appreciate the troll, obnoxious behavior. It is well known that climbing the corporate ladder requires an ever increasing capacity to put up with caustic trolling behavior.

As an Ancient Developer I see the problem with Javascript as not being the language, but the ecosystem.

1. Async programming. Async programming is hands down the aspect of programming that college students do the worst on. As a TA at Berkeley I can say it was one of the hardest aspects of programming for students to do well in and yet Javascript starts with an total async model.

2. No testing. Some of this has to do with Javascript starting life as web browser only. Some of this has to do with writing test code for async programming. How does one write async test code? Very, very carefully.

3. Not invented here. Javascript is not a young language. It has been around more than 10 years and yet Javascript has the same chaotic ecosystem as a first year language. That's a permanent mind set, or ecosystem.

The natural conclusion of this kind of ecosystem is to eventually suggest developers just run in kernel mode and bypass user space altogether. Asynchronous code such as database pooling is hard to get correct. This why an app server has financial value: pay for the hard stuff. And, get this, the hard stuff can be abstracted away.. Same with distributed clustering. Because these kinds of difficult async services can be black box abstracted then we have a kernel, an OS and user space. Javascript challenges that notion, and all the experience and the history of why we have kernels to begin with. Javascript is asking developers to in effect become kernel developers, without doing testing , and with in ever changing 'not invented here' chaotic code base.

Does not bode well. Has nothing to do with language though.

Well met! Reading all the rigor applied to new ideas in this article brought a tear to my eye. If only such rigor, even just a smidgen, were applied to internal projects within corporations...

Best of success!

Testing cost money.

I find it very unusual to talk with developers who regularly modify their testing practice based on time and money.

The most expensive is to do it all: unit testing, integration testing, component testing, system testing, end-to-end testing, stochastic testing, performance testing.

The art of testing in no small part comes down to the art of money. How much bang-for-the buck does any testing provide given limited resources? I answer that question.

Understand the workload.

Take the workload difference between in house versus public usage.

If one releases software into the public domain then one has no reasonable expectation as to the kinds of data driving your code. For this kind of general purpose, heavily reused software then code coverage with, unit testing and mocking makes the most sense is my experience.

However, one can also write code for a very specific, limited usage. In those cases I find regression testing with regression data works best. They are not paying me to find bugs to satisfy code coverage.

I find understanding the workload is a significant factor in determining the kinds of testing I use.

I found the art of testing is more tied to the reality on the ground as opposed to the testing methodology.

1. Do you have a a QA department doing manual or even automated testing? 2. Do you have performance testing? 3. Is the code base large or small? 4. Transactions versus analytics? 5. Social media? Some code doesn't need testing. Facebook doesn't test their code.

Each new project requires a flexibility to understand the reality of time and resources available for testing, the type of application and performance considerations. If one works at a bank or on transactional software then testing needs to verify exactness. If you are working on analytical software then what's another anomaly between friends, errors in your errors, who cares. If you are working on social media then just pump and dump like NodeJS.

That is the art of testing to me. A mind set of one size fits all with respect to the of value unit testing, integration testing, regression testing or manual testing is the opposite of art: it's ideology.

Engineers are aholes. How the negativity manifests itself is different between genders but the fact remains, Engineers are aholes. Nonstop, 24/7. As a software contractor I interview more than most I can tell interview horror stories that will peel paint. Has little to do with my gender though. Key man is common problem in the valley. Some person makes themselves a key man in the company and then reign down holy hell on everyone around them. This scenario plays out every day in Silicon Valley. The point is the problem is much larger than just how women are treated, but how people are treated. If you can't take the heat get out of the kitchen is the mind set. Its a dog-eat-dog world and I'm wearing Milkbone shorts, as they comedian quipped. Root cause is not gender specific. Root cause is mean people in general. Mean people are going to be mean people, independent of gender. It doesn't help that Bill Gates, Steve Balmer, Bill Joy, Scott McNealy, Larry Elison, Steve Jobs are pretty much mean people role model CEOs people understand being mean as necessary. It would be interesting to redo this study and swap being mean for gender as the bias. I have no data but I suspect that being mean is a far bigger factor than gender bias. At a minimum being mean plays a large role and if addressing part of the root cause is not part of the solution then all of the bias related solutions are sure to fall short.

History tells a different story. When the income tax was first implemented it was not long ere any income over one million dollars was 100% taxed. During Eisenhower's two-terms in the 1950s the top tax bracket was 75%. It is interesting to consider that when the modern conservative wants to return to the American prosperity of the 1950s if, like you, conservatives would be willing to return to Eiesenhower's tax brackets and tax production.

A better historical argument can be made that America should have never switched from a dividends approach to the stock market during the late 1970s. Our current system rewards quarterly gains for long term losses and this has lead to the various bubbles. I can easily argue we should return to Eisehower tax brackets and also a dividends approach to stock market gains and in doing so history is on my side.

"-Not-invented-here syndrome"

The counter to this is dependency hell. I oft times see developers pulling in large, new and compiled dependencies into Python projects for a single pieced of functionality just to avoid being accused of "not-invented-here".

It is worth noting that when something goes viral we still don't know why. Facebook represents the ultimate in viral success. Given we do not understand why things go viral then it stands to reason that the underlying software methodology is not causation. This means that the fickle finger of fate could easily be visited upon Facebook the same as with MySpace and Facebook will be in no control. This is independent of the any software methodology they use.

Claims made without evidence can be dismissed without evidence.