▲ 71 points
back
76 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.
>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".
>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!
Sometimes it takes a long time for good ideas to percolate from academia/research to the day-to-day practice of the craft.
> 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.
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?
if(foo = bar) { ... }
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!".
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.
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.)
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.
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.
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.
But—only in very metaphorical ways is a program a text file.
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.
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.
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?)
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?
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.
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 :-)
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
[3] https://github.com/prettier/prettier/issues/2444
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.
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.
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.
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.