The use of container technology also helps. My code is developed into a Docker container and on passing all tests gets added to a repository of Docker images. That image is deployed to any post development environment and we can absolutely guarantee that the app will behave identically in all environments.
For me having consistent environments has revolutionised what we do.
You wrote, ‘Visual Studio is not modern, this is what a modern dev environment should do,’ and then listed a ton of things that VS does pretty well within its target stack. Granted, I only use VS for full-stack enterprise-level asp.net, but I just figured I’d point out that it supports:
– auto formatting
– node and other flavors of build tools
– unit testing
– nuget in asp.net at least, which means fewer ‘hard dependencies’
– continuous integration
– containerization (or will soon)
That said, I generally step out of the full IDE and recommend VS Code, Atom etc when it comes to working outside of the asp.net stack (and soon even for asp.net core) and using Git, ci, and Docker.
My only point is that all the editors have their pros, and you can use them all in an antiquated fashion, but I don’t agree with blaming VS for that, and in fact I think recent iterations of VS have really kept up with a modern dev environment for its stack. (stepping into 2010 for some projects though… Ugh).
But I agree in that we should be educating new devs on the proper build pipeline regardless of the stack and editor they use, because ftp ugh.
You wrote, ‘Visual Studio is not modern, this is what a modern dev environment should do,’
That’s not what I wrote.
What I am saying is that if you go back 20, 30 years ago… there were things that looked like modern-day Visual Studio. The graphical interface is very much old school. So, using Visual Studio in 2017 does not make you “modern”.
Regarding Microsoft in general, they are definitively embracing best practices and helping to move the field in the right direction.
There are several other features worth notting for modern IDE’s like InteliJ:
– refactoring, extracting methods, subclasses, crateing interfaces from implementations and vice versa…
– hinting – not only syntax highlighting but performance tips ets, predicted compilation and runtime errors
– database connections, persistance, ER diagrams to/from entities and classes
– automatic code generaion: test cases, surrounding, wrapping with loops/try-catch and so on
Modern programming is less programming. It’s building your app at a higher abstraction level using visual languages and low code tools where you can focus on the core of what you want to build and not in all the boiler plate around it, therefore delivering much faster.
> So what happens when you work with smart students who never learned about modern programming?
> They look at a command like go get and they only see the skin (a command line).
> They think it is backward. Where are the flashy graphics?
My experience is that most students (here I mean post-secondary students) are well-accustomed to the command line, and are (initially) tied very little to IDEs, or at least understand very well how to use their favored IDE to develop against most projects. Indeed, though my entire post-secondary education IDEs were basically invisible. The religions of recent students seem to be more about languages, licenses and development philosophies than specific IDE choies.
In the real world, including “students” who self-learn and perhaps students of schools that actually include IDEs in the curriculum (which?), I think you really want to do two things: make your code portably compilable with the standard platform capabilities, and at least ensure it isn’t hostile to IDE use. On unix-like platforms that generally means a make, autotools or cmake build (or at least something that boils down to the same thing) and at least fixing bug reports from IDE users that don’t otherwise compromise the software.
On Windows platforms, it’s a bit tougher because of the large gulf in functionality between approximately POSIX-compliant software and Windows, but you can get pretty close with MinGW and cmake, or even cmake alone (depending on the source).
John Smithsays:
The problem with all these general advice about programming is that you never show what you have accomplished. Point to a successful software project where your methods were employed so we can have some verifiable proof that you are actually a productive programmer and not an ivory tower professor with no experience in the real world. Have you ever worked in a real company?
Tell us about your real world experience, we are dying to be amazed.
Gene Arthursays:
Started programming in 1980, with extended basic on a Ti99, with 16k of memory, 13K USABLE FOR PROGRAM., Moved up to a Osborne, with64k memory, and an about 4 inch green screen built in, Z80 cpu. 8080/z80 assembly, basic, forth, and yuck, Cobal.. verbose, Fortran.. Then Compaq Deskpro, 640k mem, 20meg hardrive, TI LISP, ICON,C, TURBO PASCAL, FORTH. I still use Unicon-lang and Icon. Many boxes later, Added: C,PHP, Prolog, … then around 2002, Haskell. That has been the most mind expanding/busting, ever since, along with still using Icon/Unicon for scripting, and utilities. Not a fan of object oriented langs. Elixir is one that I will be Trying in earnest soon. That could be I think a super addition, love what I’ve seen so far.. was put off with the Erlang syntax, but elixir has put a clean face on the great erlang run-time. Cheers, gene
jldsays:
“Modern programming” is very easy:
You just need to be politically correct in your programming and voila! you’re modern 😀
Alexander Smithsays:
One key aspect around go is that it’s spec is about 1/6 of the size of Java. This makes training and ramping up significantly faster and cheaper.
Also modern programming is much more functional/ immutable/ stream – closure based than it used to be ( leads to more reliable concurrent code).
To me powerful ide’s are often a sticking plaster for a language/framework’s deficiencies.
Hicham Assoudisays:
Very nice post Prof. Daniel. In my opinion “Modern Programming” is a paradigm shift that goes hand in hand with “Modern Applications” e.g. Mobile and cloud based applications. In fact, for some legacy applications (e.g. packaged application), which already have their own dev/deployment processes a and frameworks, its hard to introduce and sell the modern programming approach to the project decision makers.
Cheers
20 years ago we used offline API documentation describing function parameters. Today we google complete, ready to use code fragments for all common tasks.
I think that this is closely related to “programming is social”. We used to program in closed silos, with reference books and limited teams. This is no longer true.
A key commonality of all the aspects that are described as “modern programming” is that they are relatively recent (not over 20 years old) as “best practice”. I would put “Learning on the job” (or Just in Time) as the key attribute for a modern programmer.
I have been at it for 30 years, and I learn something new at least every year. In the last 10 I added git, jenkins, docker, snap, vscode on linux, boost::test, agile (scrum), Raspberry Pi, Arduino, Python and many others to my arsenal, and I look forward (with some trepidation) to the next (r)evolution.
lavita-rica.comsays:
What majority of supposed graduates of whatever programming related education you care to cite are basically ignorant of the importance and qualities of a stack?
'No Bugs' Haresays:
IMNSHO, modern programming is exactly the same as “old” programming. Exactly like 20 years ago (when I started my architectural career as a co-architect of a stock exchange) programming is all about getting things done.
Everything else is just a tool in a toolbox to achieve that task. Moreover – whatever-fans-of-specific-technology-will-tell-you – most of the modern tools may be a blessing or a curse depending on specifics. Examples are numerous, including but not limited to: (a) automated deployment button being devastating if it gets to wrong hands; (b) over-reliance on IDE debugger which becomes a detriment for a wide class of debugging problems (people spend too much time trying to follow the code, when logging shows the problem much better); (c) over-reliance on IDE class browsers – which leads to crappy source file organization and reduces code readability (and to make things worse – it supports a misunderstanding that design is about classes, while way too often class is way too small unit for thinking about the code); (d) over-reliance on automated testing (especially on automated _unit_ testing) leads to false sense of security – and unit testing is known to be of extremely little value at least in real-world interactive systems (=”if you want to avoid regressions, code review – in addition to automated testing – is a MUST”). And so on, and so forth.
Looking at the very same thing from a bit different perspective – we can say exactly as 30 years ago, the real art of programming has nothing with the book by Knuth (it is a really good book, but it is about science, not art); rather – the real art of programming is all about finding what out of all those shiny-things-in-the-toolbox is applicable to your specific project, and what is not.
H. Sahyounsays:
Prof,
Your Student.
In modernisation let talk cloud, git, etc. There is the question of security issues.
Second, 5 gl or 6 gl languages or ide make no smart effort to build your own tool but you’ll be dependable on others.
The use of container technology also helps. My code is developed into a Docker container and on passing all tests gets added to a repository of Docker images. That image is deployed to any post development environment and we can absolutely guarantee that the app will behave identically in all environments.
For me having consistent environments has revolutionised what we do.
Right, so my list is not meant to be exhaustive. There are many “modern” things in programming… that came out in the last decade.
Ever had to code in Smalltalk? I suggest you try Pharo : you’ll be blown away!!
You wrote, ‘Visual Studio is not modern, this is what a modern dev environment should do,’ and then listed a ton of things that VS does pretty well within its target stack. Granted, I only use VS for full-stack enterprise-level asp.net, but I just figured I’d point out that it supports:
– auto formatting
– node and other flavors of build tools
– unit testing
– nuget in asp.net at least, which means fewer ‘hard dependencies’
– continuous integration
– containerization (or will soon)
That said, I generally step out of the full IDE and recommend VS Code, Atom etc when it comes to working outside of the asp.net stack (and soon even for asp.net core) and using Git, ci, and Docker.
My only point is that all the editors have their pros, and you can use them all in an antiquated fashion, but I don’t agree with blaming VS for that, and in fact I think recent iterations of VS have really kept up with a modern dev environment for its stack. (stepping into 2010 for some projects though… Ugh).
But I agree in that we should be educating new devs on the proper build pipeline regardless of the stack and editor they use, because ftp ugh.
You wrote, ‘Visual Studio is not modern, this is what a modern dev environment should do,’
That’s not what I wrote.
What I am saying is that if you go back 20, 30 years ago… there were things that looked like modern-day Visual Studio. The graphical interface is very much old school. So, using Visual Studio in 2017 does not make you “modern”.
Regarding Microsoft in general, they are definitively embracing best practices and helping to move the field in the right direction.
There are several other features worth notting for modern IDE’s like InteliJ:
– refactoring, extracting methods, subclasses, crateing interfaces from implementations and vice versa…
– hinting – not only syntax highlighting but performance tips ets, predicted compilation and runtime errors
– database connections, persistance, ER diagrams to/from entities and classes
– automatic code generaion: test cases, surrounding, wrapping with loops/try-catch and so on
Modern programming is less programming. It’s building your app at a higher abstraction level using visual languages and low code tools where you can focus on the core of what you want to build and not in all the boiler plate around it, therefore delivering much faster.
https://www.outsystems.com/low-code-platforms/
To be fair, this part seems unusual to me:
> So what happens when you work with smart students who never learned about modern programming?
> They look at a command like go get and they only see the skin (a command line).
> They think it is backward. Where are the flashy graphics?
My experience is that most students (here I mean post-secondary students) are well-accustomed to the command line, and are (initially) tied very little to IDEs, or at least understand very well how to use their favored IDE to develop against most projects. Indeed, though my entire post-secondary education IDEs were basically invisible. The religions of recent students seem to be more about languages, licenses and development philosophies than specific IDE choies.
In the real world, including “students” who self-learn and perhaps students of schools that actually include IDEs in the curriculum (which?), I think you really want to do two things: make your code portably compilable with the standard platform capabilities, and at least ensure it isn’t hostile to IDE use. On unix-like platforms that generally means a make, autotools or cmake build (or at least something that boils down to the same thing) and at least fixing bug reports from IDE users that don’t otherwise compromise the software.
On Windows platforms, it’s a bit tougher because of the large gulf in functionality between approximately POSIX-compliant software and Windows, but you can get pretty close with MinGW and cmake, or even cmake alone (depending on the source).
The problem with all these general advice about programming is that you never show what you have accomplished. Point to a successful software project where your methods were employed so we can have some verifiable proof that you are actually a productive programmer and not an ivory tower professor with no experience in the real world. Have you ever worked in a real company?
Kind regards,
John Smith
I make it easy to find out about me.
Tell us about your real world experience, we are dying to be amazed.
Started programming in 1980, with extended basic on a Ti99, with 16k of memory, 13K USABLE FOR PROGRAM., Moved up to a Osborne, with64k memory, and an about 4 inch green screen built in, Z80 cpu. 8080/z80 assembly, basic, forth, and yuck, Cobal.. verbose, Fortran.. Then Compaq Deskpro, 640k mem, 20meg hardrive, TI LISP, ICON,C, TURBO PASCAL, FORTH. I still use Unicon-lang and Icon. Many boxes later, Added: C,PHP, Prolog, … then around 2002, Haskell. That has been the most mind expanding/busting, ever since, along with still using Icon/Unicon for scripting, and utilities. Not a fan of object oriented langs. Elixir is one that I will be Trying in earnest soon. That could be I think a super addition, love what I’ve seen so far.. was put off with the Erlang syntax, but elixir has put a clean face on the great erlang run-time. Cheers, gene
“Modern programming” is very easy:
You just need to be politically correct in your programming and voila! you’re modern 😀
One key aspect around go is that it’s spec is about 1/6 of the size of Java. This makes training and ramping up significantly faster and cheaper.
Also modern programming is much more functional/ immutable/ stream – closure based than it used to be ( leads to more reliable concurrent code).
To me powerful ide’s are often a sticking plaster for a language/framework’s deficiencies.
Very nice post Prof. Daniel. In my opinion “Modern Programming” is a paradigm shift that goes hand in hand with “Modern Applications” e.g. Mobile and cloud based applications. In fact, for some legacy applications (e.g. packaged application), which already have their own dev/deployment processes a and frameworks, its hard to introduce and sell the modern programming approach to the project decision makers.
Cheers
How about adding stackoverflow.com to the list?
20 years ago we used offline API documentation describing function parameters. Today we google complete, ready to use code fragments for all common tasks.
How about adding stackoverflow.com to the list?
I think that this is closely related to “programming is social”. We used to program in closed silos, with reference books and limited teams. This is no longer true.
A key commonality of all the aspects that are described as “modern programming” is that they are relatively recent (not over 20 years old) as “best practice”. I would put “Learning on the job” (or Just in Time) as the key attribute for a modern programmer.
I have been at it for 30 years, and I learn something new at least every year. In the last 10 I added git, jenkins, docker, snap, vscode on linux, boost::test, agile (scrum), Raspberry Pi, Arduino, Python and many others to my arsenal, and I look forward (with some trepidation) to the next (r)evolution.
What majority of supposed graduates of whatever programming related education you care to cite are basically ignorant of the importance and qualities of a stack?
IMNSHO, modern programming is exactly the same as “old” programming. Exactly like 20 years ago (when I started my architectural career as a co-architect of a stock exchange) programming is all about getting things done.
Everything else is just a tool in a toolbox to achieve that task. Moreover – whatever-fans-of-specific-technology-will-tell-you – most of the modern tools may be a blessing or a curse depending on specifics. Examples are numerous, including but not limited to: (a) automated deployment button being devastating if it gets to wrong hands; (b) over-reliance on IDE debugger which becomes a detriment for a wide class of debugging problems (people spend too much time trying to follow the code, when logging shows the problem much better); (c) over-reliance on IDE class browsers – which leads to crappy source file organization and reduces code readability (and to make things worse – it supports a misunderstanding that design is about classes, while way too often class is way too small unit for thinking about the code); (d) over-reliance on automated testing (especially on automated _unit_ testing) leads to false sense of security – and unit testing is known to be of extremely little value at least in real-world interactive systems (=”if you want to avoid regressions, code review – in addition to automated testing – is a MUST”). And so on, and so forth.
Looking at the very same thing from a bit different perspective – we can say exactly as 30 years ago, the real art of programming has nothing with the book by Knuth (it is a really good book, but it is about science, not art); rather – the real art of programming is all about finding what out of all those shiny-things-in-the-toolbox is applicable to your specific project, and what is not.
Prof,
Your Student.
In modernisation let talk cloud, git, etc. There is the question of security issues.
Second, 5 gl or 6 gl languages or ide make no smart effort to build your own tool but you’ll be dependable on others.
An opinion from you master’s degree student.
Kind regards
H. Sahyoun
hi Professor Daniel,
can I ask your permission to translate this blog post to Chinese and publish in my blog with reference and citation?
thanks!
Junjia
Yes, you can translate and repost the content.