What is “modern” programming? | Hacker News Reader

What is “modern” programming?

lemire.me

71 pointsmatt_d76 comments

Modern programming is more than just the tool chain and package management. To me modern programming is more the wider adoption of concepts borrowed from languages like Haskell: like pattern matching and safer null checks (like Maybe or Option types). It also includes easy to use coroutines or a good concurrency story. Programming with new languages comes with more compile time checking and linting, less chances to make simple stupid typo-like errors that take hours to debug. The formatting and package management are all part of this of course.

I don't really hear people call vim or emacs old fashioned too much anymore. There are a lot of new vim and neovim and spacemacs users out there.

The social aspects of coding are very nice too. It's so great to be able to search GitHub for code to see how other people solved a similar problem to one I might be having.

> Programming with new languages comes with more compile time checking and linting, less chances to make simple stupid typo-like errors that take hours to debug.

Most of the "old languages" did not have this problem. This was a product of the 90s when people built a bunch of stuff really fast without stopping to think about whether what they were building was really a good idea.

So, it's a couple of decades later, but that part of the 90s spirit is still in full force today, but there are many many more programmers. The logical conclusion is that the garbage dump being built today is way worse than the garbage dump built in the past, and that should scare you if you think typo debugging was bad.

These kids can't see the forest for the trees.

All the software is getting slower and more incomprehensible, and they think it's getting better.

P.S: Voting on HN does nothing to change anyone's mind. If you don't reply, you're basically just saying "nuh uh!".

Yeah, the fact that you are getting downvoted is proof that the average HN voter does not understand software.

The microcomputer kinda reset the clock on software development, as there was little co-mingling of mainframe people and microcomp people.

And i can't help feel we had a similar reset with the iPhone intro, again because of a split between desktop people and mobile people.

If I understand your first sentence, I think it says there are "old languages" that are relatively devoid of footguns. If so, which languages?

I believe the standard example is Modula 2. Somewhat newer, but Ada is pretty great.

Just about any old language, including C post-ANSI. The main relatively-heavily-used offenders are Lisp and shell scripts of various kinds. (And I think "oops, you made a typo, you don't find out until you try to run it and happen to ht that branch of code, oops that did not happen for three months, who knows what other bombs are sitting there waiting" is one of the primary factors in Lisp not gaining wider adoption.)

I mean, C is less compile-time-checky than Pascal, but it is tremendously better than JavaScript in that regard. So is FORTRAN, etc, etc.

Using a Lisp compiler helps a bit.

  * (defun foo (alpha)
      (flet ((beta (bar)
               (+ alph bar)))
        (bet (beta 1 2))))

The Lisp compiler, here SBCL with its REPL, detects in this function above:

  * wrong number of arguments
  * undefined function
  * undefined variable
  * unused variable

Lisp compilers have only been made available as late as 1962, so that might explain why Lisp has no wider adoption...

  ; in: DEFUN FOO                                                                                                                                                 
  ;     (BETA 1 2)                                                                                                                                                
  ;                                                                                                                                                               
  ; caught WARNING:                                                                                                                                               
  ;   function called with two arguments, but wants exactly one                                                                                                   
  ;   See also:                                                                                                                                                   
  ;     The ANSI Standard, Section 3.2.2.3                                                                                                                        

  ;     (SB-INT:NAMED-LAMBDA FOO                                                                                                                                  
  ;         (ALPHA)                                                                                                                                               
  ;       (BLOCK FOO                                                                                                                                              
  ;         (FLET ((BETA #                                                                                                                                        
  ;                  #))                                                                                                                                          
  ;           (BET (BETA 1 2)))))                                                                                                                                 
  ;                                                                                                                                                               
  ; caught STYLE-WARNING:                                                                                                                                         
  ;   The variable ALPHA is defined but never used.                                                                                                               
  ; in: DEFUN FOO                                                                                                                                                 
  ;     (+ ALPH BAR)                                                                                                                                              
  ;                                                                                                                                                               
  ; caught WARNING:                                                                                                                                               
  ;   undefined variable: ALPH                                                                                                                                    

  ;     (BET (BETA 1 2))                                                                                                                                          
  ;                                                                                                                                                               
  ; caught STYLE-WARNING:                                                                                                                                         
  ;   undefined function: BET                                                                                                                                     
  ;                                                                                                                                                               
  ; compilation unit finished                                                                                                                                     
  ;   Undefined function:                                                                                                                                         
  ;     BET                                                                                                                                                       

  ;   Undefined variable:                                                                                                                                         
  ;     ALPH                                                                                                                                                      
  ;   caught 2 WARNING conditions                                                                                                                                 
  ;   caught 2 STYLE-WARNING conditions                                                                                                                           

  FOO

Most of your comments would be vastly improved by omitting the reams of repl output.

True, so true. The SBCL compiler is almost human; Once, it insulted me with something like: "You have assigned a value to an index out of bounds. Congratulations!!"

Keep on preaching, Rainer, and may the other programmers see the light.

if(foo = bar) { ... }

>To me modern programming is more the wider adoption of concepts borrowed from languages like Haskell: like pattern matching and safer null checks (like Maybe or Option types). It also includes easy to use coroutines or a good concurrency story. Programming with new languages comes with more compile time checking and linting, less chances to make simple stupid typo-like errors that take hours to debug.

How old are these concepts? When I read this, it reads more like, "things I was unfamiliar with before, but I've heard of recently".

Sometimes it takes a long time for good ideas to percolate from academia/research to the day-to-day practice of the craft.

>How old are these concepts? When I read this, it reads more like, "things I was unfamiliar with before, but I've heard of recently".

Well, the age of a concept doesn't matter much.

What makes it old or modern is not the history of its invention or early years, but when it's popularized.

One thing that came up often in my PL theory classes: "cutting edge" features of popular programming languages lag cutting edge features of research languages by about 30 years.

The interesting consequence is: if you want to look for The Next Big Thing in programming languages, just go back 20 years!

This is much more about tools and processes than modern programming.

There is no such thing as modern programming since the fundamental principles of what is considered "good" programming are largely unchanged for the past 40 years.

Been an engineer for 25 years now, and so far I have not seen any fundamental changes in programming itself. This blog post also is a testament to that, as it just talks about things surrounding programming and mixes that with a few principles.

"Been an engineer for 25 years now, and so far I have not seen any fundamental changes in programming itself."

It's pretty surprising and to me a little disappointing how much programming has stayed the same. There is just much more tooling.

Which in the end is actually a nice thing because that means the guiding principles were right.

Tooling is just driven by one of the primary attributes an engineer should have: an abundance of lazyness that strives to find solutions for the long run.

Just the mainstream programming not changing that much does not mean that the guiding principles were right, it just means that the original ideas of computers and programming worked well enough to sustain themselves and win and maintain the place of mainstream way of automating things with computers.

Once conventions are set and basic computer systems (platforms) get built, building anything new will most probably be done in the same paradigm, even if there is a better way of doing things.

Consider the C language, which was very successful and today is a mainstream language via which we develop and control vast majority of computer systems. Programming in C today is, I think, very similar to programming in C when it was introduced. Would you say, considering the experience of those decades, that we use C because the principles of C were right? Or did we just get stuck with it because it was good enough in 70's and now it's too hard to detach ourselves from it?

I think you are mixing up things here. I am talking about principles on how to solve tasks in programming, you are talking about differences in programming languages.

But the thing is: what is right in programming was the same in C 40 years ago and is exactly still the same if you use Erlang. And it is also the reason why many old programs still work because previous generations applied the basic principles much more diligent than we do (because there is the next NodeJS around the corer, etc. smirking)

We are still writing instructions into text files and executing them sequentially. Threading is still difficult to get right. There are still no good tools for understanding a codebase.

Honestly I thought by now we would be interacting on a much higher and richer level with the machine.

Honestly I thought by now we would be interacting on a much higher and richer level with the machine

Smalltalk took some steps in this direction, and saw a degree of commercial use in the 90s. For the matter, fire up a REPL from your favourite LISP and you'll have a more interactive experience than most mainstream languages offer.

There are still attempts to move in this direction. "Notebook" interfaces which are kind-of popular with data scientists in some fields. Swift playgrounds.

I think what's prevented interactive environments gaining more traction is pretty much the same thing that's driving a lot of the trends in the linked article: what is being optimised is fine-grained collaboration and discipline within teams at the expense of flair and individuality. The modernist developer is getting unit tests to pass, not playing in an interactive interface.

I hold the opinion that formatting should not be a part of source code, I should rather be held in a separate style sheet. Source code should then contain only logic. Tha way I can set my editor to tabs, my coworker can set it to spaces and none of that ends up in the source code - the source just says that there's a block of blank space and the Style sheet tells the editor/IDE how to present it.

In a similar way, things like braces placement (or no braces like in Python) or capitalisation can be kept out of source code and in a style sheet.

(That way, I'll never have to dig through white space and formatting changes in git logs any more to find actual changes to the code.)

For some reason, I find this idea extremely disturbing; almost dystopian. To me, the sentence "a program is a text file" is one of the first axioms of computer technology.

But—only in very metaphorical ways is a program a text file.

How is that metaphorical at all? In all current languages, you write programs precisely by writing text files.

For one, in that a running program is not a text file -- it has been parsed into an AST, processed in various pipelines, and converted into several forms before it even hits a register...

On the other hand, you can compile the same program with different optimization options, and even on different architectures, and we say that it is always the same program, but the binary objects may be wildly different. Thus, the program is the text file, not the binary object.

I can add blank lines, change variable names, add comments, and yet through all these changes, it is the same program. By your logic, then, none of them can be the "real" program, just as none of the different binaries could be the "real" program.

I think that it is better to think of all of these as representations of the same abstract program. The Sieve of Eratosthenes can be implemented in different languages, binary or assembler, high-level or low-level, English or code, but they are all representations of the same abstract program.

Strictly speaking though, the text itself isn't a program, it's the input to a program (a compiler) that produces an actual program. On the other hand, this definition seems a little pedantic and you could even argue that the binary produced by the compiler isn't a program either, that a program consists entirely of its behavior.

Generally, this is not correct - compiling is not the only way to "translate" a program into an executable form: there are direct interpreters for many programming languages.

I never said compiling was the only way, just that "translation" (as you put it) is in fact necessary.

In all current _serious_ languages, maybe, but also Piet exists: http://www.dangermouse.net/esoteric/piet.html

I think it's fair to say that all programs are written artifacts as opposed to visual ones. The few visually oriented programming languages haven't really taken off.

However, it doesn't necessarily have to be the plainest of plain text. Even today, it is ridiculously popular for people to use syntax-highlighting, which adds color to everything they do. It might not get stored to the disk, but it shows that the experience of writing/reading code goes far beyond the purely textual.

Other things to consider: Code-block folding; call-graph and type-hierarchy visualizations; GUI tools for files that are half-generated and half-written; the way that diff tools turn text differences into a visual experience...

In other words, while storing your creative output in a simple and consistent way is good, the craft of programming has organically added many visual interactions to match the strengths and weaknesses of our human brains. It's not unreasonable to expect more of that, even if the core remains a written conversation with an idiot savant computer.

Agreed. Source code being "denormalized" as plaintext brings practicality, yet also problems like structure-indentation mismatch, or having merge conflicts over a trivial rename.

Writing a non-plaintext editor is a huge UI/UX problem, however...

Huh? On the contrary, it's very easy.

Smalltalk environments used to it, Lisp machines could do it, etc.

Even the combination (programmer edits code as text, but in fact just manipulates a structure, which on the programming environment has all the cool properties of live code --knowledge of structure, easy refactoring, etc-- but at the end is again saved as text and works with all tools like Git etc) is trivial to make.

Okay, allow me to clarify. A structure editor that has an all-around experience superior to plaintext editing, to the extent that such an editor can gain critical mass/mainstream adoption, remains an unsolved problem.

I can't really see a reason why source files should only be logic. For a long time we've operated on the principle that they ought to be readable too, because humans write them. So there are comments, formatting, and styles of programming to make what you're doing readable to others, like choice of variable names. Decide on a "stylesheet" to use with the people with whom you're working with, and try to stick to it.

In a way tabs are an invitation to style them how you want.

Code formatting mostly is a solved issue.

Configure a tool like clang-format/uncrustify, and make it run automatically by your test scripts.

We've been doing this at work for years, and I'm still amazed at the results: nobody cares about the coding style anymore, and the code is perfectly homogenous (and the logs/diffs are 99% clean from formatting concerns).

One thing about "modern" software development that I find striking is that the process seems to have largely jettisoned user testing. That is, testing performed by humans, usually by teams of testers. Maybe that's still a thing and I just don't see it, but I also don't see nearly as many job ads for testers as I used to, and those seem to be exclusively at BigCorps. Back in the day (let's call that pre-2000 as an estimate), in the places I worked we'd never dream of releasing something to the public that the test team had not beat the crap out of in their own sweet way, and even the smallest of companies had at least one full-time tester on board. I realize that automated testing has become extremely popular but I've always been skeptical that it could replace user testing in effectiveness and have viewed the two approaches as complimentary. This doesn't seem to be the majority view now, I get the feeling that the "modern" opinion is "if the test can't be automated, fuck it, it's not worth doing" ... essentially the coders won, the testers have finally been vanquished! How about at your company?

Seems to me that official language-integrated package managers are a hallmark of contemporary programming.

They are kinda sorta realising the dream of pervasive code reuse. In a low-friction buffet style.

This is definitely a modern thing but I think it's a bad thing, or at least a move in the wrong direction.

Language-specific package managers tie you into a single language. It's hard to use multiple languages in a project, even when that would make sense, or to migrate to a new language.

You end up needing a separate layer on top of the language's package system. Big projects like Unity have their own package managers and build systems.

I think it would be much better to have a generic package system that can be used for everything, and a generic build system that can be used for everything.

Admittedly, existing generic package managers and build systems aren't very good! So maybe this is a bad idea and it's just too hard, or maybe there's some key insight or advance we're missing.

I think Google's build system Bazel is along the right lines. Unashamedly aiming for 100% correctness, so it's really reliable and therefore usable for all build tasks.

It's interesting that you mention Bazel. Do any of Google's large public projects use it? Android has Repo, Chromium has depot_tools, and Fuchsia has jiri.

Fuchsia has its own IDL [0], which is used to generate bindings for C, C++, Dart, Go, and Rust.

It's not perfect, but I'd say Webpack [1] is worth mentioning. You define loaders and it crawls your dependency graph. When you reference assets in code they get built, copied to the output folder, and all references updated.

[0] https://fuchsia.googlesource.com/fidl/

[1] https://webpack.js.org

Google uses Bazel (or Blaze, which it's based on) for almost all their proprietary code, at least.

Their big open source projects, Android and Chrome and now Fuchsia, seem to have very different coding cultures from the rest of Google. I've used both repo and depot_tools a bit and both are pretty bad -- very thin and leaky abstractions on top of the source control system.

All programming languages should force upon the users a unique code format.

I'm fine with this, as long as it's my code format style.

TP7 is 800KB top: IDE, compiler and other utils. That thing has floating windows AND ascii shaded windows. How ridiculous.

a lot of things have been downhill since turbo pascal and turbo c++!

Just checked my copy of TurboC++, which is a single 867kB EXE (how does that work on a 640k system?)

Can't say. Was TCpp released that long ago ? I ran TP7 on a 586class machine, and it was probably designed for 486 ones. Also I think TP7 was split in a few runnables, and the largest one was around 600KB .. could fit all in memory in theory.

Overlays? - https://en.wikipedia.org/wiki/Overlay_(programming)

I used to use Turbo C++ 3.0 (I think it was? - this was 1993) and overlays was one of the touted features, though I never used it.

I recalled the acronym "VROOM" being associated with Borland's tools of this era, with the "OM" part meaning "Overlay Manager/Management"; a bit of searching yielded[1]:

  What is the VROOM in the Borland Turbo C++ ?
  9/14/94 3:53 PM

  Hi!
  I very need information about usage VROOM
  in the Borland Turbo C++ or Borland C++.
  Thanks. Alex.

  VROOM is their overlay manager.  That is, 
  it allows you to write programs which execute 
  in a conventional DOS memory (aka 640K) which
  is smaller than the size of the compiled program.
  For example, on a machine with 550K available 
  conventional DOS memory, you can run a program
  1Mb large.
  [...]

[1] https://webcache.googleusercontent.com/search?q=cache:9ptZPc...

Maybe we are getting better at programming but we still suck at delivering computing artifacts to end users. Who here has tried to ship a Ruby or Python application to desktop or even server users? Was the experience "modern"? We might as well be shipping punch cards.

Steam’s ok, itch.io is great. Do you vendor in your appp’s prerequisites?

You have to vendor. There is no other way. Or you pay the cost of vendoring at deploy time by having to pull in all the third party dependencies anyway. Whenever I rely on the end user or the platform to fill in the blanks I always regret it.

I disagree with a number of points in the article, but a particularly questionable claim, which is common in recent years, is that version control is new/modern:

Version control. Twenty years ago, it made sense to write your code on your desktop and send the new code (as patches) by email. But this only makes sense when the pace of collaboration is slow. Today, this would be insane. Anything less than Git is backward. Note that even Microsoft builds Windows using Git today.

Version control has been in widespread use for over forty (40) years. SCCS (Source Code Control System) was released in 1972 -- forty-five, yes forty-five (45) years ago. https://en.wikipedia.org/wiki/Source_Code_Control_System

The widely (and still) used Revision Control System (RCS) was released in 1982 -- 35 years ago. https://en.wikipedia.org/wiki/Revision_Control_System

Concurrent Versions System (CVS) was released in 1990 as a networked extension to RCS -- twenty-seven (27) years ago. https://en.wikipedia.org/wiki/Concurrent_Versions_System

The Subversion version control system was released in 2000, seventeen (17) years ago and was in widespread use years before Git. https://en.wikipedia.org/wiki/Apache_Subversion

There are, of course, many other version control systems dating back decades in many cases: Perforce, Mercurial, Visual SourceSafe, and others.

Version control has been in widespread use at many companies and organizations at least since the 1980s and has been in widespread use in many open source projects specifically for decades. Many open source or free software projects used CVS or SVN or other version control systems before Git or still do.

There is nothing new or modern about version control. It has been standard practice in software development for over thirty years.

I was going to comment on this as well. Even in the mid-90s the companies I worked for used PVCS.

https://en.wikipedia.org/wiki/PVCS

Not long thereafter Visual SourceSafe got traction in my workplaces. Then along came CVS.

This article is not about programming, but software development in regards of tooling.

In particular, software development by medium-to-large teams engaging in fairly fine-grained collaboration.

I can see why the students he mentions are not necessarily buying this stuff.

You have to know this stuff to be a useful programmer, though. (Or at least, it's very tough to be useful if you don't.)

This is the first time I see this package description format. The leading de-indented dots make me nervous.

That being said, I agree with the idea that things have changed a lot and tooling has become a lot better.

'70s modern programming: mostly imperative, unstructured

'80s " " : mostly structured

'90s " " : mostly OOP

'00s " " : OOP, garbage collected

'10s " " : dynamic scripting languages

2017: multi-paradigm

What I saw was a mix of waterfall and iterative processes.

The package managers on language level changed much.

Also I have the feeling that MVC, MVVM, MVP etc. is over and it's Components all the way.

Wait, you use components without a model layer?

Just because the people who invented flux didn't know the word "model" doesn't mean it's a new pattern :-)

React without flux/redux/whatever and state distributed though the component tree instead is a thing. It's not the right solution for every problem, anything like, but with a bit of thought about where it makes sense to keep the state, it can work pretty well and components which know how to fetch their own data can sometimes be easier to reuse in other contexts than, e.g., components from a full-on redux application.

See also, Relay (or om.next) with "co-located queries" for a declarative take on this.

I'm not sure how you'd write an application without a data model? If you take a look at the first figure here:

http://heim.ifi.uio.no/~trygver/themes/mvc/mvc-index.html

it's hard to see how react/flux isn't just dealing with the controller/view bit - perhaps in a better way - but it's still a bridge between the users mental model and the computers data model? And it's likely that the data model is at least somewhat complex, if it involves some kind of MVCC/ACID/transactions and/or data normalization?

Nit: Go's standard format command doesn't care about line length. Officially, there's no hard limit on line length.

"modern" is a useful concept. Like fashion, it has to be something different every year.

One of the most annoying things about our industry. I would prefer to get to know a few technologies really well rather than keep chasing the latest new hotness. Unfortunately that is seen as stagnating.

I agree with many points raised here.

Provide CLI tooling and you can build integrations with any editor! A while back Microsoft published Language Server Protocol [0]. I'm sure there must've been previous attempts achieve this, but I'm not aware of any that were widely successful. Meanwhile LSP seems to be gradually growing [1]. Having a common interface seems like such a sensible idea too! With that said, I think the software community has largely standardized on Unix. Is it unreasonable to expect OSs to implement a Unix-compatibility layer? Given that Windows is working towards that goal, is there any other major holdout?

Code formatters make tons of sense. It lets you shift the responsibility over to the computer. I think it should also be possible to have an editor visually format code in your own preferred style, while saving the output in the project's preferred style; although I haven't seen this implemented by any editor yet. In the web community, Prettier [2] has been growing increasingly popular. It currently supports JS, CSS, and GraphQL in many of their flavors (e.g. JSX, Flow, TypeScript, etc.); and there's ongoing discussion about supporting others like Markdown [3], and probably others which I haven't seen.

Dependency management is one of the big pain-points of dealing with older languages. I want to be able to pull in APIs that correctly solve my problem without sacrificing cross-platform support. Sometimes I want to load multiple versions of a library. Setting up a working build environment shouldn't require multiple hours or days of work. As an example, I've wasted multiple days over the last few months trying to build android for either my Pixel or Nexus 5X, using Ubuntu, and I haven't been successful. I can't count the number of times I've lost interest in projects because I couldn't get it to build after spending countless hours, sometimes days, trying to setup a working environment. I have my fair share of criticisms of the web development community, but at least it's never a problem getting one of their projects to build.

Testing is important! I think this is something that Swift is doing well. They have a list of projects [4] which they automatically test against the development branch in order to understand the compatibility impact of their changes. With their latest set of breaking changes they also provided tools to help gradually migrate to the latest version [5]. I'll note I haven't worked on a serious production-ready Swift environment, so I don't know how effectively these tools work for a serious real-world projects.

Version control is a must, but I'd also suggest trying out more tools, rather than limiting yourself to git. I've used git professionally, and I can work with it without breaking anything. But plenty of its commands are needlessly confusing and quirky, and it's too easy to shoot yourself in the foot. Relevant XKCD [5]. I've had cases where I shot myself in the foot and Time Machine's file history was the only thing that saved me. Fossil [6] is a really nifty alternative, written by the creator of SQLite. It's much friendlier, and it includes an issue tracker and wiki! I've been happily using it for some of my personal projects. It's not the right tool for every problem, but it never hurts to try out something new.

[0] https://github.com/Microsoft/language-server-protocol

[1] http://langserver.org

[2] https://prettier.io

[3] https://github.com/prettier/prettier/issues/2444

[4] https://swift.org/source-compatibility/

[5] https://xkcd.com/1597/

[6] http://fossil-scm.org

I agree that package managers and a standard code format are useful. The rest of the things he mentions are a matter of preference. The tone and attitude of the author are simply insufferable. I'd hate for someone so opinionated about unimportant shit to be on my team, I can tell you that much from experience.

http://www.dsprobotics.com/applications.html

https://www.native-instruments.com/en/products/komplete/synt...

http://rawkes.com/articles/an-introduction-to-noflo-and-flow...

Please. Stop. Typing.

How much of your coding is spent on syntax, structure, and scope - jobs that the computer often does much better than you? What benefit is there in typing out the same loops and so on over and over and making people read your code in order to figure out what the structure should look like?

The reason people drew flowcharts by hand and then typed out programs was because the computers couldn't interpret complex diagrammatic programming in real time back in the 70s. This has changed, but people are still typing and think that color-coding and autocomplete are pretty snazzy features in a modern IDE.

How much of your coding is spent on syntax, structure, and scope

I agree with you on syntax, but a computer definitely does not do structure better than me.

Typing with autocomplete and syntax advice is much faster than manipulating diagrams. And you can diff the text with your existing source control tools.

This is why AutoCad has a command line.

A great example of only considering your own needs and not those who will be maintaining the code alter. Yes, typing is fast and easy, but it's also locking everyone into a dead development path. That's why so many people in the creative industries have moved on from it.

Generic graphical programming, in things equivalent to your examples, has so far sucked. Anyone who has ever been forced to do it for more than a trivial amount of time, creating more than trivial programs, has experienced that.

I understand the 'non-textual programming' evangelism as wishing for something 'better than textual programming', but it's like people wondering whether there isn't something better than math to describe Nature. Unless you come up with something, there isn't and you can't claim there is or has to be. Some small parts can be described by diagrams and words perfectly. For the most part: math or bust.

Reply on news.ycombinator.com