
What is “modern” programming? - matt_d
http://lemire.me/blog/2017/07/15/what-is-modern-programming/
======
mevile
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.

~~~
jblow
> 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.

~~~
microcolonel
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!".

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

------
marenkay
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.

~~~
maxxxxx
"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.

~~~
marenkay
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.

~~~
effie
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?

~~~
marenkay
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_ )

------
swerner
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.)

~~~
enriquto
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.

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

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

~~~
fasquoika
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.

~~~
Koshkin
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.

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

------
brightsize
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?

------
frou_dh
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.

~~~
iainmerrick
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.

~~~
TheAceOfHearts
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/](https://fuchsia.googlesource.com/fidl/)

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

~~~
iainmerrick
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.

------
ktRolster
_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.

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

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

~~~
to3m
Overlays? -
[https://en.wikipedia.org/wiki/Overlay_(programming)](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.

~~~
cagey
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...](https://webcache.googleusercontent.com/search?q=cache:9ptZPcsR69QJ:https://groups.google.com/d/topic/comp.std.c%252B%252B/tFGw0zfKfdY+&cd=1&hl=en&ct=clnk&gl=us)

------
dkarapetyan
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.

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

~~~
dkarapetyan
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.

------
NumberSix
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](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](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](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](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.

~~~
brightsize
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](https://en.wikipedia.org/wiki/PVCS)

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

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

~~~
dasmoth
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.

~~~
iainmerrick
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.)

------
rf15
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.

------
flavio81
'70s modern programming: mostly imperative, unstructured

'80s " " : mostly structured

'90s " " : mostly OOP

'00s " " : OOP, garbage collected

'10s " " : dynamic scripting languages

2017: multi-paradigm

------
k__
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.

~~~
skrebbel
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 :-)

~~~
dasmoth
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.

~~~
e12e
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](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?

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

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

~~~
collyw
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.

------
TheAceOfHearts
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](https://github.com/Microsoft/language-server-protocol)

[1] [http://langserver.org](http://langserver.org)

[2] [https://prettier.io](https://prettier.io)

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

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

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

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

------
mnm1
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.

------
anigbrowl
[http://www.dsprobotics.com/applications.html](http://www.dsprobotics.com/applications.html)

[https://www.native-
instruments.com/en/products/komplete/synt...](https://www.native-
instruments.com/en/products/komplete/synths/reaktor-6/)

[http://rawkes.com/articles/an-introduction-to-noflo-and-
flow...](http://rawkes.com/articles/an-introduction-to-noflo-and-flow-based-
programming)

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.

~~~
pjc50
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.

~~~
anigbrowl
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.

