Programmers as an investment

The Rise of Developeronomics or the value of software talent.

Literate Programming versus Unix shell (?)

See More shell, less egg for a great example of two completely different approaches to a programming problem.

11 programming trends to watch

Here.
Specially number 3, No code is an island
"There's a dark side to these tightly integrated stacks of code: the walled garden."
Number 8, Traditional education fades from relevance

coding isn’t fun if all you can do is call things out of a library (Knuth)

"Today, I mostly paste libraries together" in Whatever happened to programming?

Is this the problem with today programming? Or are the libraries too dull? dumb? Low-level? Insuficient abstraction?

Think of the very different concept of Unix small programs put together, one after the other, to "treat" data. See next post,Literate Programming versus Unix shell (?)

Forget “Enterprise-Class Software”

"The term “Enterprise Software” is poisonous because it implies a scalability ceiling for a solution serving a few 10,000 people that used to be ambitious, but that’s no longer the case. It’s also no longer the hardest class of software solutions – not at all."
Read here, Enterprise Software is much much simpler than, example, multi-players games. Think of scale and availability.

Types, classes of Mathematical abstractions?

Back from types and classes to the more abstract mathematical entitie:Where do types come from?

Answers in  Translating math into code: Examples in Java, Python, Haskell and Racket.

For more details look at Chris Okasaki's Purely Functional Data Structures book.

The futility of developer productivity metrics

..."A highly effective, productive developer workforce is often the result of high-quality, effective management. Unfortunately, nobody has developed a metric for that yet. Coincidence?"

Lasagna code

Good Lispian rant at the complexities of object oriented and other languages as compared to Lisp, Scheme or Algol.

Babbage and Ada

Trying to build the Analytical Engine. But the most important idea is that Ada was the first to understand the universality of computers. And their limits.

Father of Lisp and AI John McCarthy has died

Stanford University has confirmed that John McCarthy, the inventor of the LISP programming language and one of the pioneers of artificial intelligence (AI), has died at the age of 84.

Among developers, McCarthy may be best known as the inventor of Lisp, which he devised in 1958 while at MIT and published in the seminal work "Recursive Functions of Symbolic Expressions and Their Computation by Machine, Part I.”

Computer science is booming

Navigate the Booming Computer Science Market

Databases: Linq is the way? or is it Memory?

Perhaps not NoSQL, but SQL through Linq? The World According to LINQ

Finally someone rediscovers Memory!

 

Programming Isn't Fun Any More

Original text at Neophilic.

To be found here.

"We spent years working on software reusability. We have now succeeded, and have to pay for that. Be careful of what you wish for...  The good news is that programming will become easier for people with good memories but not so great analytical capabilities."

The idea is clear: programming used to be about designing algorithms. Now it is more about learning and using frameworks or APIs. Where has the intelligence gone?

See discussions at Codeproject, and Reddit.  See below, Frameworks.

Frameworks?

Are frameworks making developers dumb?

Also, Libraries vs Frameworks

How Computational Complexity Will Revolutionize Philosophy

The theory of computation has had a profound influence on philosophical thinking. But computational complexity theory is about to have an even bigger effect, argues one computer scientist.

Enterprise Software Sucks but it Doesn’t Have To

Very good ideas from Jesus Rodriguez blog. Helps a lot to understand why Enterprise Software sucks. Also that this sad situation is mainly limited to Enterprise Software. And that there are alternatives.

The Age of the Algorithm

... UT Dallas researcher who speculates that as algorithms increasingly become the differentiator in software, algorithm developer jobs and algorithm engineering degrees may not be far behind.

Some thoughts on programming, buliding solid systems, functional programming, abstraction

Gerald Jay Sussman paper, Building Robust Systems: "The digital computer is a break-through of this kind, because it is a universal machine that can simulate any other information-processing machine."

Lisp: A language for stratified design, Harold Abelson and Gerald Jay Sussman, AIM-986: "Lisp encourages one to attack a new problem by implementing new languages tailored to that problem".

PicoLisp, A Radical Approach to Application Development, Alexandre Burger, radical.pdf:

   - Deal with constant application change
   - Develop through an iterative process
   - Have a fully functional systema at each iteration
   - Lightweight and fast language
   - Compiled Lisp is not Lisp
   - Lisp is fast because it is a tree of executable nodes
   - On top of PicoLisp Burger built an application server which includes a Database and a Lisp based markup language
   - Information kept in one place
   - Abstracted library of functions

Check Pico-Lisp here.

Good ideas from the past

Buried Treasures by Glenn Vanderburg

The Art of Computer Programming

Matt Barton, The Fine Art of Computer Programming, Free Software and the Future of Literate Programming:

“When software became merchandise, the opportunity vanished of teaching software development as a craft and as artistry” (Richard P. Gabriel and Ron Goldman)

Barton mentions Pope, essayist and poet, as a model. Code should be read like poetry. "It is perhaps time to elect a new Pope. To my mind, there is only one man of sufficient merit and tenacity to warrant such an honor: Donald E. Knuth. I nominate Knuth because of the development of what he terms literate programming, ..."

"The truth, according to Knuth, is that programming is “both a science and an art, and that the two aspects nicely complement each other”

From Literate Programming, Patrick TJ McPhee: "The second important idea is the view of program writing as a special type of literary work with its stress on the readers, as opposite to the stress on computers many programmers have."

Stan Kelly-Bootle, Ode or Code: "Dijkstra’s oft-quoted advice was, “Besides a mathematical inclination, an exceptionally good mastery of one’s native tongue is the most vital asset of a competent programmer.”" (Stan being an excellent example of brilliant mastery of English language)

Principles of Problem Solving

Peter Wegner Principles of Problem Solving:

Remarkable paper, with views on applied Universal Machines:

"Theoretical computer science (TCS) asserted in the 1960s that Turing machines (TMs)—introduced by Turing [4] to help show the limitations of mathematical problem solving—provide a complete model of computer problem solving by negating Turing's claim that TMs could solve only functional, algorithmic problems. The TCS view ignored Turing's assertion [4] that TMs have limited power and that choice machines, which extend TMs to interactive computation, represent a distinct form of computing not modeled by TMs."

"...we edited a book on interactive computing [1], with 18 articles by prominent researchers, including Milner, Broy, Vardi, and Van Leeuwen, describing their contributions to and opinions about interactive computing as a new paradigm of computing for the 21st century."

"Fundamental models of computer science evolved from the Greek modes of mathematical thought of Pythagoras and Euclid to the interactive 20th century models of computational problem solving of Gödel, Turing, and Milner. It is not surprising that changes in computing technology can determine changes in mathematical and political thinking. Computation emphasizes open processes involving interaction among machines and users, rather than the closed transformation of an input to an output."

The algorithmic revolution---the fourth service transformation

Services science 

The algorithmic revolution---the fourth service transformation

John Zysman

Communications of the ACM
Vol. 49 No. 7, Page 48
10.1145/1139922.113994

We are in the midst of the fourth services transformation. The core story is the application of rule-based IT tools to service activities; it is not about the growth in the quantity or the value of the activities we label as services. The application of IT has the potential to transform the services component of the economy, altering how activities are conducted, and value is created. Services were once seen as a sinkhole of the economy, immune to significant technological or organizationally driven productivity increases. Now the IT-enabled reorganization of services, and business processes more generally, has become a source of dynamism in the economy.

There are four interconnected service stories that must be separated and clarified. The first is an accounting error, or perhaps better, a matter of financial engineering. Activities outsourced from manufacturing are relabeled as services. The GM window washer is a manufacturing employee; but when contracted by GM he becomes a service employee. The same window is washed, perhaps by the same window washer. Initially, at least, we should assume the activities stay the same, just conducted by different organizations.

The second story is that services become a larger part of the economy with the evolution of consumer and business purchases. Services have become a larger portion of both the consumer market-basket and of what businesses use to produce and distribute their goods and services.

The third service story is about the transformation in and changing role of women in the work force and, with that, the conversion of unpaid domestic work—washing floors, watching babies, and delivering groceries—into commercial services bought and sold in the market. It is a form of household outsourcing.

The fourth service story is the digital or algorithmic transformation. Service activities themselves are changed when they can be converted into formalizable, codifiable, computable processes with clearly defined rules for their execution. This is an algorithmic service transformation facilitated by IT tools. Much of the service innovation then is around the adoption and effective implementation of IT tools. Certainly business processes from finance and accounting through to customer support and CRM are altered when they can be treated as matters of information and data management. Routine and manual functions are automated, and fundamental reorganization of activities is enabled. Likewise, sensors and sensor-based networks change many personal services. Then, as service activities are conducted by and with IT tools, the worker skills required change as well. And of course, as information moves, many activities that were previously tightly linked to particular places can be moved.

Just as important, this algorithmic transformation blurs the line even further between product and service. For example, it is conventional to observe that products such as media products are simply encapsulated information. Conversion into digital format facilitates their online delivery to computers, cell phones, iPods, and the like. Slowly the particular product, the purchase of a CD, blurs into a service, a subscription to download music. IBM has transformed from a company selling a product in which service support provided competitive advantage into a service company embedding products in its offerings. The services that ride on the product platform become the differentiated asset that creates value for the firm.

The drama is that tools and technologies based on algorithmic decomposition of service processes may have the power to revolutionize business models the way manufacturing was revolutionized in the industrial revolution. The digitally implemented service processes and activities will displace people when it is embedded in automated processes, but often complement the effective use of human insight, intelligence, and knowledge in the choice, development, application, and effective use, of these tools will remain central. The crucial issue in this era will be how underlying knowledge and insight is developed and applied.

 

John Zysman (zysman@berkeley.edu) is co-director of BRIE and a professor of political science at UC Berkeley.

---

©2006 ACM  0001-0782/06/0700  $5.00
Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. To copy otherwise, to republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee.

The Digital Library is published by the Association for Computing Machinery. Copyright © 2006 ACM, Inc.

The Web is the Computer

What Is Web 2.0, Design Patterns and Business Models for the Next Generation of Software: seminal O'Reilly paper. Some ideas:

The Web as a platform

The Web is the Computer

Harnessing Collective Intelligence

Data is the Next Intel Inside

End of the Software Release Cycle

Lightweight Programming Models

Software above the levels of a Single Device

Rich User Experiences

Software Engineering: An Idea Whose Time Has Come and Gone?

DeMarco Reflects on 40 Years of Software Engineering Evolution:  "On the 40th anniversary of NATO's "Conference on Software Engineering," where the discipline of software engineering was first proposed, Tom DeMarco paused to reflect on the discipline's evolution, including his role in influencing its initial direction toward metrics. The author of the much-quoted "You can’t control what you can’t measure" now wonders whether this orientation has distracted us from the real point of computing: "The more important goal is transformation, creating software that changes the world or that transforms a company or how it does business." His conclusion, under the title "Software Engineering: An Idea Whose Time Has Come and Gone?" [pdf] appeared in the July/August edition of IEEE Software magazine."

See also: The Profession of IT is software engineering engineering in CACM, vol.52, no.3

Chuck Connell, Software Engineering is not equal do Computer Science: "Software engineering will never be a rigorous discipline with proven results, because it involves human activity. "

The trouble with Enterprise Software

Cynthia reviews the problems with Enterprise software: The proliferation of complexity, the cost of implementation. She also thinks that re-usable software is a myth when complexity is high (is it?). Original article at MIT Sloan Management Review. Copy here. Critic review here and here. An also here, on SOA to fix ERP.

Developers get better with age

A simple conclusion, based on interesting statistics.

And... We're entering the decade of the developer. 

And more, on the subject of experience, of difference between the expert and the master, and yes, the master is the one who makes programs simple.

On the subject of design, the wise advice of Paul Graham.

Jürgen Schmidhuber

Artificial Intelligence researcher at http://www.idsia.ch/.

Interesting ideas: complexity, Kolmogorov algorithms, Gödel machine.  Worth having a look at.

(dica / suggestion of Orsoni.  Thanks!)

Avoid starting with OOP

Don't Distract New Programmers with OOP.

"The shift from procedural to OO brings with it a shift from thinking about problems and solutions to thinking about architecture... At some point, yes, you'll need to discuss how to create objects in Python, but resist for as long as you can."

Learning curve, abstraction

Our first hypothesis stating that internalization leads to more planning and better performance is supported. Internalization resulted in longer thinking times before starting to work on the problem and to more time between moves. It indicates that when information has to be internalized, more contemplation is provoked and users ponder longer before acting… Internalization subjects solved the problems with fewer superfluous moves, thus with greater economy… Our results suggest that internalization provokes more “thinking before acting” than externalization.… not at any measure, externalization resulted in better performance. Once more we found positive effects of internalization on problem-solving behavior: it led to more plan-based behavior, smarter solution paths and better declarative knowledge. Externalization led to a more display-based approach resulting in less economic solutions and shallower thinking.

This shows clearly the power of concepts and abstraction over "the simple and easy way to..."

The Framework Myth

If ever there was an irresistible programmer’s platitude, it is that code-reuse is invariably a good thing. Unfortunately, even the best of advice can be taken to a ludicrous extreme, the construction of generic frameworks within organisations.  Mike Mooney gives a warning, based on painful experiences.

Clearly shows, trough both practice and reflection, that attempt to build framework will impact negatively software development. So, back to the simple programming model, don't try to invent shortcuts. Either you are not good enough or the framework built will not be good enough for the job.

The world runs on bad software

...But, a lot of people are doing amazing things and making insane amounts of money from bad software.

Why Can't Developers Estimate Time?

Some thoughts on estimating projects time, and the very important sentende: We can't estimate the time for any individual task in software development because the nature of the work is creating new knowledge.

Not Dead Yet: The Rise and Fall and Rise of Java

Java is not dead yet, but new and diverse languages are rising. Good market study with statistics.

Como gerenciar programadores

Finalmente alguém diz, de forma direta, como gerenciar programadores (geeks para ele).  A chave é respeito.  Respeito pela competência técnica.  E reconhecimento da contribuição deles, que é de conseguir fazer as pessoas trabalhar melhor.  Enfim, são profissionais que colocam a profissão acima das políticas da empresa.

The unspoken truth about managing geeks

Object-oriented programming, where is it now?

Good thinking on OO from a programmer with practical experience: Programming like it's 1995

Software: arte? ofício? engenharia?

Uma pista para se entender porque software é tão mal feito está neste Dan North rejects the Manifesto for Software Craftsmanship. Ele considera que o que interessa é que o problema esteja resolvido, que o software funcione, não importa como foi feito! Compara fazer software com o trabalho de um encanador: não importa a solução dada contanto que a torneira forneça água.

É porisso que se faz tanto software ruim. E encanamentos também, aliás.

trade (ofício):
...
4. any occupation pursued as a business or livelihood.
5. some line of skilled manual or mechanical work; craft: the trade of a carpenter; printer's trade.
...

craft (arte, ofício):
...
Definition of CRAFT
1. skill in planning, making, or executing : dexterity
2. an occupation or trade requiring manual dexterity or artistic skill <the carpenter's craft> <the craft of writing plays> <crafts such as pottery, carpentry, and sewing>

Will continuous delivery transform the production of software?

To monitor.  This looks like software development by continuous improvement plus strong interaction with users. Isn't what we see in the Web? (Google, Amazon, ...)

Omega

Linguagem - e conceito - a acompanhar.  Ver trabalhos de Tim Sheard.

Um novo conceito de tipo?  Linguagem funcional mais tipos ricos?

Ver Languages of the Future, Tim Sheard (guardado em Library)

Software Engineering is the #1 Job in the United States in 2011

Java World, January 9
In its annual review of career opportunities, CareerCast recently ranked Software Engineering as the #1 job in the United States for 2010. This continues a recent trend, in which the software engineering, software development and programming professions have received high rankings in various career surveys. In the previous year's rankings, for example, Software Engineering was ranked as the #2 job. The article explores possible reasons why Software Engineering is enjoying new popularity and responds to reader comments about the specific roles and responsibilities of Software Engineering.
There are several reasons why Software Engineering moved to the #1 spot for 2011. The study identified the software engineering job market as widening in both scope and diversity, thanks primarily to cloud computing and mobile device development. The greater number and variety of positions leads to greater potential for an industry and reduces the competitiveness factor in finding new jobs. At the same time, the stress factor for Software Engineering careers declined, enabling an improved work-life balance.
The article and its methodology attracted a number of comments and vocal reader feedback. For example, readers debated the finer points of how a software engineer is different from a programmer or coder. They also debated the relative value of the various components of what makes a "good job" or "good career." Overall, software engineering is a solid choice of career when looking at the ratio of reward to effort. There are few careers with such a high level of compensation for a bachelor's degree, which is the typical educational level of software engineers though some have more and some have less formal secondary education.
(from ACM CareerNews, January 18, 2011)
 

Fact and folklore in software engineering

Laurent Bossavit questiona e critica as várias análises e teorias sobre produtividade do programador. O assunto aparece no tópico So what is known about programmer productivity? Resposta: muito pouco. Quando se tem medidas que variam de 1 a 20, pode-se dizer que não se sabe nada e que não há métricas úteis. Temos um campo de estudo pouquíssimo científico, baseado em folklore e  "ouvi dizer". Que tal reconhecer que programar não é um tipo de trabalho cuja produtividade se mede? É mais próximo de trabalho criativo, de arte, de produção de ciência, de produção de matemática.

Também  em francês aqui.

Lisp. Maxwell's equations for computation indeed

David Nolens' Posterous blog, Lazy Evaluation vs. Macros. He really appreciates Lisp:

"The key insight of Lisp is that a programmer or a community of programmers should have have the whole of computation at their finger tips." Which goes in the direction I recommend: programmability.

"So the real question moving forward isn't "Is Lisp too powerful?", rather, "Are our mainstream programming languages and paradigms too damn weak?"."