5 ms·

It's not. Installing a C++ tool chain two decades ago is much harder than any current environment.

umanwizard 9y ago
"Learning programming" doesn't mean "learning C++". A lot of people learned on some BASIC that came pre-installed on whatever device they bought.
- sirmarksalot 9y ago
  And you're typing this comment from a full-featured Javascript IDE.
rconti 9y ago
For decades, "development tools" was a (relatively) standard bit of kit on any Linux distro; in fact, you needed it to compile basic software you needed to run on the machine. These days, every environment/framework has a different distribution method/model involving running random shell scripts or learning git or whatever. For example, on OS X (I imagine this is harder on Windows, possibly easier on Linux) Python: To install REAL Python on OS X: * Install GCC * To install GCC you need XCode * To install Homebrew, use Ruby to curl to a random shell script on github. * Export a path * Use brew to install python3 * Brew installs pip for you (and then?) React Native: * Assuming you have Node installed (yeah, sure, why not!): * npm install * create-react-native-app * npm start * Then download Expo client on iOS or android phone and scan a QR code...
- Too 9y ago
  I thought it would be easy on windows but was baffled how bad the instructions on the python website are. The getting started guide still caters for windows xp and choosing py2 vs py3 is still considered a good decision for beginners. 1. browse to python.org 2. get confused whether to choose python 2.7 or 3.6 3. get confused wheter to choose gzipped sourced tarbal, XZ zipped source tarbal, embeddable zip file x86-64, embeddable executable installer x86-64, embeddable web installer x86-64, and then repeat all those options for x86. T___T 4. open installable, press next a few times. Last time i did this there were some confusing options to select there also, like wheter to use %APPDATA%, add to PATH or not. On linux: sudo apt install python3
groovy2shoes 9y ago
Really? I remember it being rather easy circa 2003. On Windows, you could download an installer for Dev-C++ or the Borland compiler, install it like any other program, and you were done. On virtually every other platform, you didn't have to do anything at all: the system came with a C++ toolchain ready to go. I'd say it's still just as easy to get going with those sorts of tools now, and the same goes for many other languages, like Java and C# for example. That said, I think the question of whether it was easier to start programming then versus now has a more nuanced answer. The kinds of programs people are likely going to want to write—like mobile apps, web apps, and games—are a lot more complex these days than their equivalents were back then. On the other hand, there are boatloads of free tooling and information readily-available to help people through it. On the third hand, there could perhaps be issues of information overload if you go looking without a guide. So, getting started is one thing, and I can't say for sure whether it's harder now versus then. Of course, that's a slightly different question than whether it was easier to learn programming then versus now. This question is easy for me to answer: of course not, learning it now is just as easy[1] as it's ever been! [1]: Or hard, if you're of the glass-half-empty persuasion ;)
- user5994461 9y ago
  You had to install Visual Studio then the Windows SDK then probably other libraries. Then spend an afternoon to set environment variables and project settings until it can compile anything. Dev C++ and code blocks had a an easier start, although they were bugged to death and only used for hello world projects. Borland is paid software. There was a free edition was very challenging to obtain. That certainly contributed to the death of the company. If we talk about two decades strictly. There was no internet so you couldn't find any tutorial or help page. Books were selling for $50 each and you couldn't Ctrl+F them. On Linux a newbie can "gcc -o helloworld.c" to compile his first C file. Then there is a massive gap until he will be able to compile multiple files with make, auto tools, manage external libraries and package anything to run on another computer. Now it's 2018 and Linux still doesn't have a C++ debugger.
deckard1 9y ago
How so? Two decades ago was... 1998. You pop in Visual Studio 6.0 click a few buttons and it's done. On Linux we had gcc/g++, which came preinstalled in every distro. Even if you factor in setting up Makefiles and autoconf and friends, those are nowhere near the complexity of configuring webpack for a SPA, let alone installing everything you need for a functioning stack. We're talking days, weeks, and even months of tedious fighting to get everything setup. You have to worry about setting up web servers, HTTPS, CORS, what type of backend API to use, what ports your various microservices live on, what HTTP framework to use, which babel settings to use. I spend way more time these days on architecture and overhead issues than feature work. It's not even ballpark close. C/C++ I set the Makefile up once for the architectures I need and I'm done. In C++ in 1998 you were also never in danger of having to upgrade a major component in the middle of development. I've had to upgrade node, React, webpack, and others all within the same year. The shrinkwrap supply chain vanished and so did the costs of pushing out new releases. New releases, I might add, that have a shit ton of bugs (never, ever, ever touch a X.0 npm package, jesus christ do not do it)
- fragmede 9y ago
  > Even if you factor in setting up Makefiles and autoconf and friends, those are nowhere near the complexity of configuring webpack for a SPA, let alone installing everything you need for a functioning stack. We're talking days, weeks, and even months of tedious fighting to get everything setup. That's an overly rosy view of the past. Makefiles are inscrutable for a newbie. We're talking hours just to figure out tabs versus spaces for indentation. Google launched in 1998 so that was barely Googleable, there was no Stack Overflow (remember expertsexchange.com?). Older C compilers utterly failed at useful error messages on trivial errors like missing semicolons, or closing strings or braces, and 1998 was before Boost, so good luck getting STL Vectors working. These days languages have hashes/dicts available as a built in data structure. If you were lucky in 1998, you had a C string library and no one had to call ::malloc (or worse, ::realloc). There have always been major component upgrades if you choose to get distracted. Circa 1998... remember that whole mess with 2.2 vs 2.4 Linux kernel? How about upgrading Debian versions was and that fun with incompatible versions of libc? i386 vs x86_64? STL? How about rewriting to use Boost (version 1 came out in '99)? Getting Boost to build in the first place was at least a multi day adventure. As a newbie, setting something up on a modern stack is actually pretty easy - because that's no longer something to setup by hand. Clone the tutorial repo, grab their docker container or `npm install`, and you're up and running.
bsder 9y ago
Add a decade and your statement is correct. Getting a C++ toolchain in 1998 was pretty easy. You were either Windows and lived with whatever Microsoft abomination they shipped or you were on a Unix and you installed gcc and vi/emacs. Truly smart people installed CVS. In 1988 on the other hand, you sometimes had to figure out how to bootstrap gcc--possibly from the broken garbage compiler the manufacturer shipped and sometimes from nothing at all.

"Learning programming" doesn't mean "learning C++". A lot of people learned on some BASIC that came pre-installed on whatever device they bought.

sirmarksalot 9y ago
And you're typing this comment from a full-featured Javascript IDE.

rconti 9y ago

For decades, "development tools" was a (relatively) standard bit of kit on any Linux distro; in fact, you needed it to compile basic software you needed to run on the machine. These days, every environment/framework has a different distribution method/model involving running random shell scripts or learning git or whatever. For example, on OS X (I imagine this is harder on Windows, possibly easier on Linux) Python: To install REAL Python on OS X: * Install GCC * To install GCC you need XCode * To install Homebrew, use Ruby to curl to a random shell script on github. * Export a path * Use brew to install python3 * Brew installs pip for you (and then?) React Native: * Assuming you have Node installed (yeah, sure, why not!): * npm install * create-react-native-app * npm start * Then download Expo client on iOS or android phone and scan a QR code...

Too 9y ago
I thought it would be easy on windows but was baffled how bad the instructions on the python website are. The getting started guide still caters for windows xp and choosing py2 vs py3 is still considered a good decision for beginners. 1. browse to python.org 2. get confused whether to choose python 2.7 or 3.6 3. get confused wheter to choose gzipped sourced tarbal, XZ zipped source tarbal, embeddable zip file x86-64, embeddable executable installer x86-64, embeddable web installer x86-64, and then repeat all those options for x86. T___T 4. open installable, press next a few times. Last time i did this there were some confusing options to select there also, like wheter to use %APPDATA%, add to PATH or not. On linux: sudo apt install python3

groovy2shoes 9y ago

Really? I remember it being rather easy circa 2003. On Windows, you could download an installer for Dev-C++ or the Borland compiler, install it like any other program, and you were done. On virtually every other platform, you didn't have to do anything at all: the system came with a C++ toolchain ready to go. I'd say it's still just as easy to get going with those sorts of tools now, and the same goes for many other languages, like Java and C# for example. That said, I think the question of whether it was easier to start programming then versus now has a more nuanced answer. The kinds of programs people are likely going to want to write—like mobile apps, web apps, and games—are a lot more complex these days than their equivalents were back then. On the other hand, there are boatloads of free tooling and information readily-available to help people through it. On the third hand, there could perhaps be issues of information overload if you go looking without a guide. So, getting started is one thing, and I can't say for sure whether it's harder now versus then. Of course, that's a slightly different question than whether it was easier to learn programming then versus now. This question is easy for me to answer: of course not, learning it now is just as easy[1] as it's ever been! [1]: Or hard, if you're of the glass-half-empty persuasion ;)

user5994461 9y ago
You had to install Visual Studio then the Windows SDK then probably other libraries. Then spend an afternoon to set environment variables and project settings until it can compile anything. Dev C++ and code blocks had a an easier start, although they were bugged to death and only used for hello world projects. Borland is paid software. There was a free edition was very challenging to obtain. That certainly contributed to the death of the company. If we talk about two decades strictly. There was no internet so you couldn't find any tutorial or help page. Books were selling for $50 each and you couldn't Ctrl+F them. On Linux a newbie can "gcc -o helloworld.c" to compile his first C file. Then there is a massive gap until he will be able to compile multiple files with make, auto tools, manage external libraries and package anything to run on another computer. Now it's 2018 and Linux still doesn't have a C++ debugger.

deckard1 9y ago

How so? Two decades ago was... 1998. You pop in Visual Studio 6.0 click a few buttons and it's done. On Linux we had gcc/g++, which came preinstalled in every distro. Even if you factor in setting up Makefiles and autoconf and friends, those are nowhere near the complexity of configuring webpack for a SPA, let alone installing everything you need for a functioning stack. We're talking days, weeks, and even months of tedious fighting to get everything setup. You have to worry about setting up web servers, HTTPS, CORS, what type of backend API to use, what ports your various microservices live on, what HTTP framework to use, which babel settings to use. I spend way more time these days on architecture and overhead issues than feature work. It's not even ballpark close. C/C++ I set the Makefile up once for the architectures I need and I'm done. In C++ in 1998 you were also never in danger of having to upgrade a major component in the middle of development. I've had to upgrade node, React, webpack, and others all within the same year. The shrinkwrap supply chain vanished and so did the costs of pushing out new releases. New releases, I might add, that have a shit ton of bugs (never, ever, ever touch a X.0 npm package, jesus christ do not do it)

fragmede 9y ago
> Even if you factor in setting up Makefiles and autoconf and friends, those are nowhere near the complexity of configuring webpack for a SPA, let alone installing everything you need for a functioning stack. We're talking days, weeks, and even months of tedious fighting to get everything setup. That's an overly rosy view of the past. Makefiles are inscrutable for a newbie. We're talking hours just to figure out tabs versus spaces for indentation. Google launched in 1998 so that was barely Googleable, there was no Stack Overflow (remember expertsexchange.com?). Older C compilers utterly failed at useful error messages on trivial errors like missing semicolons, or closing strings or braces, and 1998 was before Boost, so good luck getting STL Vectors working. These days languages have hashes/dicts available as a built in data structure. If you were lucky in 1998, you had a C string library and no one had to call ::malloc (or worse, ::realloc). There have always been major component upgrades if you choose to get distracted. Circa 1998... remember that whole mess with 2.2 vs 2.4 Linux kernel? How about upgrading Debian versions was and that fun with incompatible versions of libc? i386 vs x86_64? STL? How about rewriting to use Boost (version 1 came out in '99)? Getting Boost to build in the first place was at least a multi day adventure. As a newbie, setting something up on a modern stack is actually pretty easy - because that's no longer something to setup by hand. Clone the tutorial repo, grab their docker container or `npm install`, and you're up and running.

bsder 9y ago

Add a decade and your statement is correct. Getting a C++ toolchain in 1998 was pretty easy. You were either Windows and lived with whatever Microsoft abomination they shipped or you were on a Unix and you installed gcc and vi/emacs. Truly smart people installed CVS. In 1988 on the other hand, you sometimes had to figure out how to bootstrap gcc--possibly from the broken garbage compiler the manufacturer shipped and sometimes from nothing at all.