8 ms·

What is “modern” programming?

71 points by matt_d 9y ago

agumonkey 9y ago
TP7 is 800KB top: IDE, compiler and other utils. That thing has floating windows AND ascii shaded windows. How ridiculous.
- jackmott 9y ago
  a lot of things have been downhill since turbo pascal and turbo c++!
- pjc50 9y ago
  Just checked my copy of TurboC++, which is a single 867kB EXE (how does that work on a 640k system?)
  - agumonkey 9y ago
    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.
  - to3m 9y ago
    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 9y ago
      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:9ptZPcsR69QJ:https://groups.google.com/d/topic/comp.std.c%252B%252B/tFGw0zfKfdY+&cd=1&hl=en&ct=clnk&gl=us https://webcache.googleusercontent.com/search?q=cache:9ptZPc...
deleted 9y ago
[deleted]
mevile 9y ago
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 9y ago
  > 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 9y ago
    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 9y ago
      Yeah, the fact that you are getting downvoted is proof that the average HN voter does not understand software.
Vektorweg 9y ago
This article is not about programming, but software development in regards of tooling.
- dasmoth 9y ago
  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 9y ago
    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.)
frou_dh 9y ago
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 9y ago
  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 9y ago
    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 9y ago
      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.
marenkay 9y ago
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 9y ago
  "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 9y ago
    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 9y ago
      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?
dkarapetyan 9y ago
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 9y ago
  Steam’s ok, itch.io is great. Do you vendor in your appp’s prerequisites?
  - dkarapetyan 9y ago
    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.
swerner 9y ago
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 9y ago
  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 9y ago
    But—only in very metaphorical ways is a program a text file.
    - enriquto 9y ago
      How is that metaphorical at all? In all current languages, you write programs precisely by writing text files.
      - coldtea 9y ago
        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...
        enriquto 9y ago
        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.
mnm1 9y ago
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 9y ago
http://www.dsprobotics.com/applications.html http://www.dsprobotics.com/applications.html https://www.native-instruments.com/en/products/komplete/synths/reaktor-6/ https://www.native-instruments.com/en/products/komplete/synt... http://rawkes.com/articles/an-introduction-to-noflo-and-flow-based-programming 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.
- pjc50 9y ago
  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 9y ago
    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.
- ktRolster 9y ago
  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.
- Confusion 9y ago
  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.
rf15 9y ago
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.
astrobe_ 9y ago
"modern" is a useful concept. Like fashion, it has to be something different every year.
- collyw 9y ago
  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.
ktRolster 9y ago
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.
k__ 9y ago
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 9y ago
  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 9y ago
    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 9y ago
      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?
flavio81 9y ago
'70s modern programming: mostly imperative, unstructured '80s " " : mostly structured '90s " " : mostly OOP '00s " " : OOP, garbage collected '10s " " : dynamic scripting languages 2017: multi-paradigm
skybrian 9y ago
Nit: Go's standard format command doesn't care about line length. Officially, there's no hard limit on line length.
TheAceOfHearts 9y ago
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
zentlim 9y ago
Yep. I can no longer picture writing code without git. "If you mock people who program using the Atom text editor, Visual Studio or Emacs, you are not being social." - Let's not forget vim and vi.
NumberSix 9y ago
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 9y ago
  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.
brightsize 9y ago
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?

71 points by matt_d 9y ago

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

jackmott 9y ago
a lot of things have been downhill since turbo pascal and turbo c++!
pjc50 9y ago
Just checked my copy of TurboC++, which is a single 867kB EXE (how does that work on a 640k system?)
- agumonkey 9y ago
  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.
- to3m 9y ago
  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 9y ago
    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:9ptZPcsR69QJ:https://groups.google.com/d/topic/comp.std.c%252B%252B/tFGw0zfKfdY+&cd=1&hl=en&ct=clnk&gl=us https://webcache.googleusercontent.com/search?q=cache:9ptZPc...

deleted 9y ago

[deleted]

mevile 9y ago

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 9y ago
> 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 9y ago
  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 9y ago
    Yeah, the fact that you are getting downvoted is proof that the average HN voter does not understand software.

Vektorweg 9y ago

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

dasmoth 9y ago
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 9y ago
  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.)

frou_dh 9y ago

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 9y ago
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 9y ago
  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 9y ago
    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.

marenkay 9y ago

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 9y ago
"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 9y ago
  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 9y ago
    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?

dkarapetyan 9y ago

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 9y ago
Steam’s ok, itch.io is great. Do you vendor in your appp’s prerequisites?
- dkarapetyan 9y ago
  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.

swerner 9y ago

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 9y ago
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 9y ago
  But—only in very metaphorical ways is a program a text file.
  - enriquto 9y ago
    How is that metaphorical at all? In all current languages, you write programs precisely by writing text files.
    - coldtea 9y ago
      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...
      - enriquto 9y ago
        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.

mnm1 9y ago

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 9y ago

http://www.dsprobotics.com/applications.html http://www.dsprobotics.com/applications.html https://www.native-instruments.com/en/products/komplete/synths/reaktor-6/ https://www.native-instruments.com/en/products/komplete/synt... http://rawkes.com/articles/an-introduction-to-noflo-and-flow-based-programming 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.

pjc50 9y ago
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 9y ago
  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.
ktRolster 9y ago
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.
Confusion 9y ago
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.

rf15 9y ago

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.

astrobe_ 9y ago

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

collyw 9y ago
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.

ktRolster 9y ago

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.

k__ 9y ago

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 9y ago
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 9y ago
  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 9y ago
    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?

flavio81 9y ago

'70s modern programming: mostly imperative, unstructured '80s " " : mostly structured '90s " " : mostly OOP '00s " " : OOP, garbage collected '10s " " : dynamic scripting languages 2017: multi-paradigm

skybrian 9y ago

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

TheAceOfHearts 9y ago

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

zentlim 9y ago

Yep. I can no longer picture writing code without git. "If you mock people who program using the Atom text editor, Visual Studio or Emacs, you are not being social." - Let's not forget vim and vi.

NumberSix 9y ago

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 9y ago
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.

brightsize 9y ago

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?