3 ms·
> Coding is getting much, much easier. I don't know about that one. If you want to build a compiler or a scripting engine, you will still be dealing with the o
by gizi 11y ago
> Coding is getting much, much easier.
I don't know about that one. If you want to build a compiler or a scripting engine, you will still be dealing with the one or the other variation of lex and yacc and then get bitten by the intricacies and gotchas of writing up a compilable LALR1 grammar. You should also have a reasonable command of C (or C++) but that is rather easy in comparison. Building a compiler is as hard now as in the 1970s when they first started using automated tools for that.
> Building an application that might have taken a team of 10 a year in the 1980s now takes a team of 2 just a few months.
Yes, if you are always building a variation on the same database application, it should indeed become easier after a while. That is the essence of a "framework". You are always building the same application, with just a few variations here or there. That will indeed give the wrong impression that building software is getting easier and easier. Building such frameworks, however, is not becoming easier, and we continuously have truly new applications to build, not just variations on the same one.
- onion2k 11y agoTo use a car analogy you're suggesting "the automotive industry still finds designing a car difficult because look at Formula 1 racing!", while ignoring everything that makes designing and building cars much easier/quicker/safer/cheaper. There'll always be edge cases where generalisations break down but looking at them doesn't give you any insight to the bigger picture.
- iofj 11y agoI think you're always going to see that. When a system is pioneered, it is very, very, very hard to get any kind of traction. To extend the car analogy. Karl Benz spent more than 3 years trying to find an engine configuration that worked and did not blow up. Then, again, he spent years to get an engine of the correct size to provide the correct amount of force for his horseless carriage, and things like transmission, gearshifters, ... Designing the first automobile, start to finish, took one man, going through 3 companies because they wouldn't let him, from 1871 to 1885, 14 years total. And keep in mind that the 1885 version was extremely unreliable, hard to control. It got out of control during a demonstration and crashed it into a wall 3 months after it's construction. It took until late 1888 for a "usable" model to get onto the market (and this is using a flexible definition of the word usable : his wife made 3 design changes on her first trip with the car, one because the brakes didn't work downhill, another to the ignition and something about the fuel line) But 2 things change for today : building a working car, is much easier. Anybody can do it in a week. Building a car that people might want to buy ... 2-3 years at least. Building a car with a new engine (the only way you're going to really improve performance), or any large difference (e.g. hybrid-electric) 6-10 years at least. Building a fundamentally different car like the tesla took barely less time than Karl Benz needed : 2000 (real work on Tzero started) to 2009 (working prototype presented) to late 2012 when the first model S rolled of the assembly line. This happens because the standards have gone up a lot. Yes writing software is easier. But writing software that qualifies as "good" has much higher standards, which makes things take longer. I would argue that these 2 are in competition. Some years the tools win, and you can write software faster. Other years people introduce the web and "standard" 5 middleware layers (javascript client-side, load balancing, web server, business logic server, database server) and it takes a lot longer. Other years people demand that a local bakery's webpage is "scalable" and it takes a LOT longer. If the car industry is a good example, the time and effort required to write software will effectively not go down by more than 20-30%, unless you compromise on quality.