There are legitimate questions if physical constants are constant everywhere in the universe, and also whether they are constant over time. Just because we conceive something "should" be a certain way doesn't make it true. The zero and negative numbers were also weird yet valid. How is the structure of mathematics different from fundamental constants, which we also cannot prove are invariant.
After first experiences with linux shell scripting, sed, awk, and C in 1990s, I found perl a welcome refuge. Way more featureful than DOS .bat files or BASIC! Its capabilities (perl + cpan) have always well exceeded my need for CS goodness. People do complain about the syntax, oddly, without mentioning the numerous ways perl was designed to make common tasks easy to do. The "use strict" pragma, and early adoption of testing culture are two examples where perl led the programming community. With the continued maturing of the language and ecosystem, I can only smile at the naysayers and wish them happiness whatever the language.
Mainstream science has poo-poohed for years any notion that Oriental medicine practices for facilitating lymph flow have any utility. Nice to hear they're back on the allopathic table.
It's big leap to assume that massage of peripheral lymph vessels (e.g. arms and legs) affect lymph draining in the brain. I'm always a bit perplexed when people's first reaction to new hard science is to assume that it supports more or less pseudoscience. Especially in a forum where hard evidence is the norm and encouraged. Just because some research shares a noun with pseudoscience doesn't mean that X supports Y.
This thought-provoking essay does not consider one crucial aspect of software: the cost of a user developing a facility with a given software product. Historically monopolistic software producers can force these costs to be borne because the user has no alternative to upgrading to the latest version of, for example, Windows, or gmail, or the latest version of the github GUI. A signficant portion of the open source / free software movement is software providing stable interfaces (including for the user) so that resources otherwise spent on compulsory retraining to use the latest version of something proprietary, can be invested in configuring existing resources to better suit the user's problem domain. For example, programs like mutt or vim, or my latest discovery, talon.
I don't think the division line runs on the open-source software front here. Windows has historically offered some of the most stable APIs, meanwhile there's plenty of examples of popular open-source software with a lot of breaking changes.
The comment you replied to said "significant portion of" and I believe it is clear which portion that refers to: the culture around c, linux, vim and bash, not things like nodejs, java and (semi-open-source) elasticsearch which are culturally separate.
I've never found a term I liked for this particular concept at the intersection of education & business so I made one up a while back:
A Knowledge Pool is the reservoir of shared knowledge that a group of people have about a particular subject, tool, method, etc. In product strategy, knowledge pools represent another kind of moat, and a form of leverage that can be used to grow or maintain market share.
Usage: Resources are better spent on other things besides draining the knowledge pool with yet another new interface to learn and spending time and money filling it up again with retraining.
The term is Institutional knowledge. "An organization's collective memory, encompassing the unique expertise, experiences, processes, and cultural insights built over time by its members, acting as a vital asset that guides operations, decision-making, and continuity, often residing in seasoned employees' tacit understanding but also in documented procedures and data. It includes deep technical skills..."
Institutional knowledge is scoped to members of an organization and covers things related specifically to the institution's operations. What I'm talking about is the knowledge of the general population, often as it relates to an institution's products.
For instance, tons of people know how to use Adobe products like Photoshop, by way of deliberate inaction on the part of Adobe around product piracy outside of workplaces. With this large knowledge pool entering into the workforce, users were able to convince workplaces to adopt Adobe products that they were already familiar with.
That wouldn't be institutional knowledge, but a pool of knowledge that institutions could take actions (or inaction, as the case above) to influence.
Good morning. An expanding plethora of buttons, tabs, menus requires geometrical memory that may have nothing directly to do with the function in question. The first GUIs were designed that functions be "discoverable," however the size of haystacks in which these discoverable functions hide has grown exponentially, adding cognitive overhead, and increasing the length of apprenticeship needed to master the application.
A slick-looking GUI is a kind of ad for the app. As author of an accessible, terminal-based DAW app, I contrast remembering an incantation like 'add-track' or 'list-buses' with hunting around. These incantations can have shorter abbreviations, such 'lb' for list buses, and 'help bus' or 'h bus' to be sufficiently discoverable, easier for both implementer and user. And then to have hotkeys to bump plugin parameters +/- 1/10/100 etc. Probably I'm pissing into the wind to think the majority of users will ever choose this -- and GUIs do provide amazing facilities for many purposes -- but we do have a huge array of choices on linux, including this plethora of music creation and production apps. That is a big success, IMO.
Nama is pretty good and for more traditional DAW workflows, greatly simplifies using ecasound at some cost. Would love to see ecasound start getting developed again.
Edit: was comparing nama to ecasound there, not the more common graphical DAWs.
This article gives a great background to Ruby's syntax origins in perl. Also, with a series of "What happened to perl?" articles appearing lately (maybe just one on HN) it gives a nice retrospective on both good parts and quirks of the language. That perl was eagerly adopted in many toolchains vital to linux distributions (such as Gnu autotools) and is a deep dependency through the IT world today is a testament to the strong fundamentals of the language beyond the oft-flamed syntax pecadilos.
To my thinking, the tides of perl bashing in articles and comments is a sign of the vitality of the language (all publicity is good publicity) especially with the continued development and renaissance of the language -- new language features such as in-core OO, mature tools such as the Perl Data Language -- along with cultural commitment to on-boarding and mentoring in the perl community.
The war on drugs and millions of non-violent offenders in prison does not exactly suggest to me the term "sacrosanct."
Every honest therapist looks at all components of a patient's life, and the patient, too, has a responsibility to identify what is helping and what is hurting them, or in which situations a trade-off is justified.
We will never be able to arrive at a complete and perfect answer for everyone because people happen to be individuals. However the medical profession (including therapy professions) lean heavily on generalizations to avoid the overhead of having to deal with a living, breathing individual with a history and family context, where possible.
Kurt Vonnegut wrote that an aspiring writer should take any writing job he or she can get. A hack job will at least keep the creative wheels turning. I think the same applies to software development jobs. Take one where you can learn something, hone your chops. Doesn't have to be your passion, because turning an abstract conception into working software is intrinsically satisfying to someone who appreciates that particular form of magic.
Do your own projects on the side and keep your antenna peeled for other opportunities more in line with your own life goals.
Yeah, it's a great idea. If nothing else, taking a job that is non-ideal will expose you to real people with real problem, even if the domain you all are working on is boring/sucky/whatever. Notice when people complain about stuff, try to see the patterns, ask probing questions what could have helped them, and eventually you'll discover patterns of problems that you could potentially solve by leaving and building your own thing.
reply