Click through to read some of the highlights.
Click through to read some of the highlights.
What is your take on functional programming and related technologies (i.e. lambdas and streams)? Is it our salvation? Is it merely another useful design pattern? Or is it a technological dead-end?
Python creator Guido van Rossum has said most programmers aren't used to functional languages, and when he answered Slashdot reader questions in 2013 said the only functional language he knew much about was Haskell, and "any language less popular than Haskell surely has very little practical value." He even added "I also don't think that the current crop of functional languages is ready for mainstream."
Leave your own opinions in the comments. Do you like functional programming?
The researchers then checked for the code in GitHub repositories, and concluded that "there is a substantial, if not causal, link between insecure tutorials and web application vulnerabilities." Their paper is titled "Leveraging Flawed Tutorials for Seeding Large-Scale Web Vulnerability Discovery."
I'm guessing Slashdot's readers have their own opinions about this, so share your educational experiences in the comments. What was your first programming language?
- "C# programmers start and stop their day earlier, and tend to use the language less in the evenings. This might be because C# is often used at finance and enterprise software companies, which often start earlier and have rigid schedules."
- "C programmers start the day a bit later, keep using the language in the evening, and stay up the longest. This suggests C may be particularly popular among hobbyist programmers who code during their free time (or perhaps among summer school students doing homework)."
And they've also calculated the technologies used most between 9 to 5 (which "include many Microsoft technologies, such as SQL Server, Excel, VBA, and Internet Explorer, as well as technologies like SVN and Oracle that are frequently used at enterprise software companies.") Meanwhile, the technologies most often used outside the 9-5 workday "include web frameworks like Firebase, Meteor, and Express, as well as graphics libraries like OpenGL and Unity. The functional language Haskell is the tag most visited outside of the workday; only half of its visits happen between 9 and 5."
We (the developers) don't want to release "fixes" that users haven't accepted, but the code changes often include changes at all levels of the stack (database, DOAs, Business Rules, Webservices and multiple front-ends). Multiple code changes could be occurring in the same areas of code by different developers at the same time, making merges of branches very complex and error prone. Many fingers are in the same pie. Our team size, structure and locations prevent having a single gatekeeper for code check-ins... What tools and procedures do you use to prevent un-approved fixes from being deployed to production as part of the larger code change sets?
Fixes are included in a test build for users to test and accept -- but what if they never do? Leave your best answers in the comments. How woud you stop un-approved code changes from being deployed?
But one reverend told NBC that VR worlds could be dangerous because they "may take people from community and from the incarnational aspects of Christian life... [W]e always run a very serious risk that the medium overtakes the message... What we must do is guard against the use of technology through market logic where people become brands and all things spiritual become commoditized."
Survey responses were scored according to the SPANE-B metric, a standard tool used in psychology to assess "affect," defined as total negative feelings subtracted from total positive feelings. It ranges from -24 to 24. The mean score found in the developer happiness survey was 9.05. Slightly happy. The minimum was -16, while the maximum was 24. So, even in the worst cases, employees weren't totally miserable, whereas in the best cases employees weren't miserable at all.
The paper -- titled "On the Unhappiness of Software Developers" -- found that the top cause of unhappiness was being stuck while solving a problem, followed by "time pressure," bad code quality/coding practices, and "under-performing colleague."
And since happiness has been linked to productivity, the researchers write that "Our results, which are available as open data, can act as guidelines for practitioners in management positions and developers in general for fostering happiness on the job...unhappiness is present, caused by various factors and some of them could easily be prevented."
Andy writes that he also likes Elixir, talks about Agile, reveals how he survived his most challenging project, and says the biggest advancement in programming has been the open source movement. ("Imagine trying to study chemistry, but the first half of the elements were patent-protected by a major pharma company and you couldn't use them...") And he also answered an interesting follow-up question on Twitter: "Do you feel validated in an age of Node and GitHub? Some of your best chapters (scripting and source control) are SOP now!"
Andy's reply? "We've made some great progress, for sure. But there's much to be done still. E.g., You can't ship process."
Raymond cautions that "No hacker is only one of these" -- though apparently most of the hackers he knows appear to be two of them, "an indication that we are, even if imperfectly, zeroing in on real traits." But the blog post ends by asking "What archetypes, if any, are we missing?"
It'll be interesting to see if Slashdot readers if they recognize themselves in any of the archetypes. But the blog post also answers the inevitable question. What archetype is Eric S. Raymond?
"Mostly Architect with a side of Algorithmicist and a touch of Jack-of-All-Trades."