Low code

Being a professional software developer today is not about writing a programming language, and writing code is not the most crucial part of the job. Software development is mostly about the stack, the platforms, data sources, databases, network layers, APIs and security mechanisms and procedures that you use to build client-server software solutions.

Programming is a craft

Good answers to a Quora question: Are Google software engineers really doing anything extraordinary day-to-day than simply coding/fixing some quite trivial software stuff?

One of them deserves to be read. By a Google engineer:

"The joke at Google is, “Other engineers are working on things that are going to change the world, but I’m just sitting here moving protocol buffers around.”

Then you open up the Deep Mind code and take a look at it, and it’s just method after method that’s full of code that’s just moving protocol buffers around.

It turns out that the most extraordinary code is really ordinary if you look at it closely enough. Not just at Google. Look at the code that Richard Stallmann wrote for GNU bash, like the glob processor. Was that extraordinary? Absolutely. It’s also just awful, tedious code, frustrating to write and boring to read.

It goes the other way, too. I’m working on a project that I’m finding really exciting and interesting, and anyone I describe it to quickly changes the subject and walks away so that they won’t be bored into insensibility. But I’m close enough to it that I’m finding it fascinating. There are so many ways for it to go wrong! And I have to find and fix them all!"

Backus had it right!

Can Programming Be Liberated from the Von Neumann Style?

Tikhon Jelvis has it right! 

And some more findings and opinionn on functional programming. Including discovery of the possibility compile-time garbage collection (to be studied):


https://www.quora.com/Why-does-functional-programming-have-such-a-high-status-in-academic-circles

https://en.wikipedia.org/wiki/ML_(programming_language)

http://lambda-the-ultimate.org/node/2047
https://softwareengineering.stackexchange.com/questions/339666/managed-code-could-gc-be-taken-care-of-during-compile-time
https://link.springer.com/chapter/10.1007/978-1-4471-3810-5_14
https://www.researchgate.net/publication/227295133_Compile-time_garbage_collection_for_lazy_functional_languages
https://lirias.kuleuven.be/bitstream/123456789/131304/1/Mazur.pdf

FP x OOP

Is functional programming more effective than object-oriented programming?

It is all here. Just read the posts

What do you dislike about the current state of programming?

John Backus insight

"Programming ... is now the province of those who prefer to work with thick compendia of details rather than wrestle with new ideas".
Backus seminal paper: Can Programming Be Liberated from the von Neumann Style? A Functional Style and Its Algebra of Programs.
Ideas still valid today. And that was written before object oriented programming!

Good programmers

advices

Was IT better before the 90s?

Good paper, personal experience of the author. Shows that IT in the 90s was almost a secret - so IT people were not professionals - and IT now is super-open - so again IT people are not professionals.

See preceding post.

Conclusion: IT people, developers and operation people must turn into serious professionals. This is a long road ahead.

SICP or Programming by poking

Brilliant explanation by Sussman onwhy he stoped delivering his famous SICP course at MIT. Clear view on difference of software development 20 years ago (analysis-by-synthesis) and software today (poking gigantic libraries).

I do thing that today there is space for programming large systems bottom-up, using abstraction.

MicroServices and Containers

New - and efficient - way of developing software?  New modularization possibilities?  To check.

Symbolic Analysis & Symbol-Driven Engineering

Authors introduce a framework to connect the core areas of computer science.

It would be interesting to apply this framework, semantics, to administrative IT. As the algorithms are relatively simple, we eventually could prove programs correctness.

See also Semantics.

Mathematics and Programming

Three examples, with monads  and other constructs, showing that mathematical concepts, and functional programming, are the way to clear and error-free programs. Difficult perhaps. But worthy.

The Curse of the Excluded Middle

 Monads and Programming

Functors, Applicatives, And Monads In Pictures

No Methodologies

Why don’t software development methodologies work?

An experienced programmer - a "typical" programmer -, one who have used all methodologies and "techniques du jour" shows clearly that methodology is not the key to producing good software. 

The text strongly suggests that the key to good software is... the programmer. As a craftsman. Which puts the last nail in the coffin of so-called Software Engineering. 

Simple: Software is not engineering. It is related to Art, Craft and Mathematics.See Knuth The Art of Computer Programming.

" I’ve lived through waterfall/BDUF (big design up front), structured programming, top-down, bottom-up, modular design, components, agile, Scrum, extreme, TDD, OOP, rapid prototyping, RAD, and probably others I’ve forgotten about. I’m not convinced any of these things work."

"My own experience, validated by Cockburn’s thesis and Frederick Brooks in No Silver Bullet, is that software development projects succeed when the key people on the team share a common vision, what Brooks calls “conceptual integrity.” This doesn’t arise from any particular methodology, and can happen in the absence of anything resembling a process. I know the feeling working on a team where everyone clicks and things just get done. What I don’t understand is why I had that feeling a lot more in the bad old days of BDUF and business analysts than I do now."

"I think programmers should pay much more attention to listening to and working with their peers than to rituals and tools, and that we should be skeptical of too much process or methodologies that promise to magically make everyone more productive"

Programming 2014

15 hot programming trends -- and 15 going cold

To me programming is more than an important practical art. It is also a gigantic undertaking in the foundations of knowledge.

Grace Hopper

Alan Kay interview

"One could actually argue—as I sometimes do—that the success of commercial personal computing and operating systems has actually led to a considerable retrogression in many, many respects.

... In the last 25 years or so, we actually got something like a pop culture, similar to what happened when television came on the scene and some of its inventors thought it would be a way of getting Shakespeare to the masses. But they forgot that you have to be more sophisticated and have more perspective to understand Shakespeare. What television was able to do was to capture people as they were.
So I think the lack of a real computer science today, and the lack of real software engineering today, is partly due to this pop culture."

"Most software today is very much like an Egyptian pyramid with millions of bricks piled on top of each other, with no structural integrity, but just done by brute force and thousands of slaves."

"that was the big revelation to me when I was in graduate school—when I finally understood that the half page of code on the bottom of page 13 of the Lisp 1.5 manual was Lisp in itself. These were “Maxwell’s Equations of Software!” This is the whole world of programming in a few lines that I can put my hand over."

" I think the style languages [Lisp, APL, SmallTalk] appeal to people who have a certain mathematical laziness to them. Laziness actually pays off later on, because if you wind up spending a little extra time seeing that “oh, yes, this language is going to allow me to do this really, really nicely, and in a more general way than I could do it over here,” usually that comes back to help you when you’ve had a new idea a year down the road. The agglutinative languages, on the other hand, tend to produce agglutinations and they are very, very difficult to untangle when you’ve had that new idea."

"Even if you’re designing for professional programmers, in the end your programming language is basically a user-interface design. You will get much better results regardless of what you’re trying to do if you think of it as a user-interface design."

"Corporate buyers often buy in terms of feature sets. But at PARC our idea was, since you never step in the same river twice, the number-one thing you want to make the user interface be is a learning environment—something that’s explorable in various ways, something that is going to change over the lifetime of the user using this environment. New things are going to come on, and what does it mean for those new things to happen?"

And many many great and strong ideas and concepts in this Alan Kay interview

HTML, CSS, Javascript not real programming?

So, when I hear people say HTML and CSS (and even JavaScript) aren’t real programming, I think of Mainframe computers, and the Walkman, and The Encyclopedia Brittanica. All better. All gone.

Javascript?

Perhaps the next universal language? Looks possible. Some advantages: simple, used both on client and server side, quick learning.

More on first programming language

William Cusing post in the ResearchGate discussion on which programming language to use in a first programming course. Very interessting:

Racket is a variant of Scheme that focuses on teaching.
http://htdp.org/
http://docs.racket-lang.org/drracket/htdp-langs.html

The Structure and Interpretation of Computer Programs (SICP) is also a classic textbook in computer science (which also teaches Scheme). 

Teaching someone a language is a serious amount of responsibility. It amounts to teaching how to think. Teaching a low-level machine language will 'straightjacket' that individual into low-level thinking. That could be called inflicting brain damage (eminent computer scientists do say so -- such as Dijkstra), instead of teaching.

It is rare, and only will get rarer as compilers/interpreters/virtual-machines improve, that programmers are needed to produce fast programs nowadays. Optimizing before profiling is the root of project failure. Learning how to think at a higher level, profile, and optimize by hand only when truly necessary is the way to approach the present, and moreso the future.

For example, let's consider a typical domain where C is held to be the "best" language: numerical algorithms. Say Fast Fourier Transform. Please Read:http://en.wikipedia.org/wiki/FFTW 
http://www.fftw.org/faq/section2.html#languages

In particular note that the Fastest Fourier Transform is implemented in a combination of ML and OCaml. They wrote their own mini-compiler in those languages, that spits out C code better than anyone else's hand-written C code. They pulled that off because ML and OCaml allow them to easily write their own compiler customized to compiling Fast Fourier Transforms. 

In 'principle' they could have written C code to manipulate C code; but in reality such a project would have failed. Likewise, in 'principle' we could implement an OS in assembly: but the result would be horribly poor in features, if it worked at all. From such considerations it should become clear: the path to the future is higher level languages. C is the new assembly (and has been for some time). Learn it only for the purpose of compiling to it (or because you have a burning desire to implement device drivers for the rest of your life), and learn it only after learning one of the many superior higher level languages out there. 

It is important to learn a higher level language first (ML, OCaml, Python, Ruby, Scala, Clojure, Scheme, Racket, Common LISP, ...) so that you do (less) harm to your ability to think clearly and concisely. Of these languages, Scheme has probably the best support for teaching, and one of the purest approaches; it may not be the language you use on a daily basis for the rest of your life, but it is an ideal language to have learned first.

 
An my answer, below:
I think there is a prejudice against low-level languages. If you think about it, Assembly or machine-level language is not "low level". It is very detailed, indeed. But a few syntactic sugar + expression parsing can take care of the register-to-memory and memory-to-register operations. There are languages, like old PL360, which do that. You can write complete expressions and the languages translates them to machine-language.

So, the point is not being low level. Also not of being a machine language. We had high level machine language like Algol for the Burroughs machine, or LISP for the Symbolic Machines.

The point is that learning machine language we do learn a Universal Machine model. The Von Neumann model. This experience is enlightning. The student understands that data and program have the same representation, are stored in the same memory. The student catches what a compiler has to do to translate his "high level program".

Lisp, Scheme or Racket, as mentioned in William Cushing post, and used in SICP, teach yet another different Universal Machine model, the lambda calculus.

With the Universal Machine concepts understood, the student can then go to "standard" programming languages like C, Java, etc...

5 pioneering paths for software development's new frontier

Beware of the complexity in the development environment. Question: how to keep it simple? And efficient.