10 ms·

We’re approaching the limits of computer power – we need new programmers

sumanthvepa 7y ago
The renewed interest in C++ and other compiled languages is an indication of the need to get more efficient. Programmer skill will become more important in the future. But they won't be today's skills. I expect that programming in the future will be more about getting the AI to do what you want rather than writing code directly.
- thechao 7y ago
  I’m already an AI you can pay to get a computer to do what you “want”; the problem is ‘what you want’ is so poorly specified, there’s no way to turn it into an actionable set of steps!
  - meztez 7y ago
    This comment has to be the most insightful I have ever read. It is true on so many levels and captures perfectly the mentality that some senior decision makers have about AI.
  - archi42 7y ago
    Other dev: "I wish I could just tell an AI to do $implementation for me", me: "You know what our boss just did?". ;-)
- papermachete 7y ago
  Agreed. Hopefuly a fusion between prolog and haskell comes by - a modern declarative language to end all languages. Let it decide what's best for cache locality and profile your performance. Let it choose the best data structures based on your constraints - compile time and maybe runtime.
  - WhyNott 7y ago
    FYI, a fusion between prolog and haskell already exists: its called mercury. Its a statically compiled language with decent performance characteristics (at least, in its category).
    - tluyben2 7y ago
      Mercury was pretty good last I tried and a very interesting language at that; I like Prolog and did quite a lot of work in it in the 90s (mostly research). I like how clean it looks (that's from Prolog) and the performance is great due to the fact that you give quite a lot of info to the compiler when you are programming (see for instance [0]). It has many backends it compiles to (Java, .NET, Erlang, native; not sure how well they are all maintained). It is a shame that not more people are working on the language and that not more people use it; I think there was not enough hype surrounding it. I gave up as it could not produce native code for ARM, a platform I always need for everything I do (for many years already), so to take a language seriously as something to dive in, it needs to have ARM support. Not sure what the state of that is now; this is many years ago. [0] https://www.mercurylang.org/information/doc-latest/mercury_ref/Determinism-categories.html https://www.mercurylang.org/information/doc-latest/mercury_r...
      - pdimitar 7y ago
        As a general comment and talking about myself exclusively, it's a new kind of fatigue that I would call "oh look, another programming language". There are quite a few very interesting and solid languages out there. One example for something that's not nearly well enough utilised or used widely is OCaml -- although in its case the lack of true multicore CPU support definitely cripples interest. But the language has an amazing type system that catches a _TON_ of errors (maybe even more than Rust's compiler, not entirely sure). And its compiler is just lightning-fast, fastest I've ever seen in fact. And it is multi-paradigm language (OOP and functional, and a lot of interesting typing constructs on top, half of which I don't even understand). Etc. Not advocating for OCaml by the way (I work with Elixir and am looking to get better at Rust lately). It's just an example demonstrating that, again, there are a good amount of very solid languages and runtimes out there but we the programmers are so busy either (a) belonging to tribes or (b) being so damn busy we can't look beyond the tech we do our daily job with -- and then a lot of excellent tech gets left in the dust. :( Mercury might be one of these tech pieces. And it's definitely not the only one.
- crazypython 7y ago
  It seems to me that if we can merge https://github.com/Syniurge/Calypso https://github.com/Syniurge/Calypso into LDC, we can get a language that is easier to understand and compiles faster than C++, Dlang.
- Forge36 7y ago
  Using the data we what have would already be a big gain. I think that's AI's biggest contribution. I've seen a lot of time and complexity go into improving functionality beat by someone who wrote code to track what actions were taken, and adjust based on frequency of use. The first option is needed if you have no data and cannot gather the data, the second is great because it can adjust itself over time. This is where I see the SRE (site reliability engineers) role. The developers making changes are put into a position where they measure the cost impact of a decision. It's these feedback loops, and the practices they instill, that I believe we need. New programmers can help break the mold, but without good feedback they'll fall into the same traps.
- falcolas 7y ago
  Identifying the right characteristics in data, and creating properly tagged corpuses of data that correspond with the right characteristics is no less work than writing code. Not to mention manually written algorithms are, in many cases, more accurate than ML heuristics (for a terrible yet relevant example in the finance industry, identifying the correct sum of a set of numbers).
- sly010 7y ago
  Why not both?
- jobseeker990 7y ago
  What about Rust or D? OR even Go-lang?
- quotemstr 7y ago
  I don't think the new interest in compiled language reflects anything other than ongoing cyclical changes in fashion. Neither "compiled" nor "interpreted" language families (the terms are vague and the same language can fall in both categories) has a slam dunk performance advantage over the other. > I expect that programming in the future will be more about getting the AI to do what you want rather than writing code directly. This is the clear endgame. The question is how long it takes to get there.
  - throwaway17_17 7y ago
    It’s a small semantic nitpick, but I think that you have to qualify the domain of conversation in stating: ‘neither “compiled” or “interpreted” language families ... has a slam dunk performance advantage over the other.’ If this is universally qualified, where are the scientific HPC simulations written in python, AAA video games written in Haskell, and fin tech trading apps written in Lisp? I am not stating that there are no places where compiled vs interpreted can never produce acceptable results, it’s just more nuanced than a forall type proposition. Addendum: I am aware C# could sort of be ‘interpreted’ and Unity is C#, so there is at least some evidence in the game category, but I’d quibble over the best-in-class C#/Unity game being considered 100% C#.
    - sudosysgen 7y ago
      Unity is also quite far from being known for the best performance.
- cmdshiftf4 7y ago
  >The renewed interest in C++ and other compiled languages is an indication of the need to get more efficient. I kind of disagree with this based on intuition alone. Most developers, professional developers, are using web tech (JS stack in particular - Node and hyped front-end frameworks). Yet we"re seeing "interest" in compiled languages such as Rust, despite almost nobody using it professionally and almost nobody doing much with it outside of simple proof of concepts. To me it points toward a developing sense of insecurity in modern professional developers that simply being a JS dev isn't really programming/development and they've to "prove" themselves with lower level tech. Something that indicates that, for me, is in StackOverflow's 2019 survey [0] the most used tech was JS and that which surrounds it, followed by Python and other easy-to-get-going-well-supported tech. Yet the "Most Loved" was Rust. I could be wrong, and I'm open to being, but I intuitively I don't believe the interest in performant technologies is in the face of the sheer bloat we've seen, particularly from the web-front. >Programmer skill will become more important in the future. My prediction on this, not so AI specific, is that developing and deploying web-tech will continue to become easier and easier, meaning it'll take less people to do it. Sure, work may arise from developing countries/economies to supplant a drop in demand for it in the developed world, but maybe not. Combined with a potential bubble burst in tech, I think those relying on web dev for a living could be in trouble in the coming decade. I don't foresee much in terms of companies trying to optimize operational costs by instructing their devs to write their code more efficiently with memory/performance in mind to reduce operating costs, and thus spur a push toward jumping on compiled languages. If anything, cloud computing will continue to get cheaper and cheaper as the big 3 continue to try and absorb as much marketshare as possible. [0] https://insights.stackoverflow.com/survey/2019#overview https://insights.stackoverflow.com/survey/2019#overview
  - steveklabnik 7y ago
    Rust is used for far more than proofs of concept, and is deployed at some of the largest tech companies in some of their key products.
    - cmdshiftf4 7y ago
      Not disagreeing with that. Although, in re-reading the above, I have made a grave mistake above, contrasting most used with most loved. SO's "most loved" is measured by "of those professional using this language, how many responded that they love using it", so in the case of Rust it's 83.5% of the 3% using it professionally. In retrospect I think my point would be better made by pointing at the difference between the technologies being used professionally and the technologies "most wanted", where Go and Rust are in the top 20% of wanted but the bottom 40% for Go and bottom 20% for Rust. I'll leave the original intact for posterity but what's cited is done so erroneously.
- c-cube 7y ago
  I'm hopeful about Crystal filling this niche in the future.
Forge36 7y ago
What the future holds is hard to grasp, the piece shared with me yesterday was "we'll spend the next decade removing features, at no loss to functionality" One of the biggest pieces of bloat I've seen is doing the same thing in multiple places, and the new feature not being an improvement over the old workflow in 90% of cases, the efficiency gained 10% was lost in the other 90%
- wool_gather 7y ago
  > the piece shared with me yesterday was "we'll spend the next decade removing features... Sounds like an interesting read; do you mind sharing a link (or submitting it to HN)?
rini17 7y ago
What will be probably most interesting to watch: the collision between hardware constraints and ever-increasing complexity of standards like Unicode and HTTP.
Zigurd 7y ago
If you look at the volume of software that needs to be produced, and at the trend to include software in more products, and at the entrepreneurial imperative that risk capital is the most expensive resource, it looks very unlikely that handcrafted machine instructions will play a greater role in the future. Cloud computing and SaaS have extended the deadline for coming up with an answer to "What comes after Moore's Law." But it is much more likely to not be based on every coder learning what us olds learned 40 years ago. Instead, optimization is more likely to get automated. Even what we call "architecture" will become automated. People don't scale well, and the problem is larger than un-automated people can solve.
- thedevelopnik 7y ago
  I don’t think that handcrafted machine instructions are what is necessary. Even switching from languages like Ruby or JS (Node) to languages like Go or Elixir yields tremendous efficiency improvements. Beyond that, developers being conscientious of what they send over the wire, and being just a bit critical of what the framework or ORM produces also can yield substantial gains. I say this as a “DevOps” guy who is responsible for budget at a mid-size startup, where we’re hitting scale where this becomes important. We save about 8 production cores per service that we convert from Rails to Go. Devs lose some convenience, yes, but they’re still happy with the language, and they’re far from writing hyper-optimized, close to the metal code.
  - deleted 7y ago
    [deleted]
  - pdimitar 7y ago
    You mentioned it yourself early in your comment but IMO going from Rails to Go is a bit weird. Rails to Phoenix (Elixir) is much easier and productive for many devs, it turned out. Elixir itself is almost completely staying-out-of-your-way language as well -- meaning that if your request takes 10ms to do everything it needs then it's almost guaranteed that 9.95ms of those 10 are spent in the DB and receiving the request and sending the response; Elixir almost doesn't take CPU resources. I worked with a lot of languages, Go/JS/Ruby/PHP/Elixir included. Elixir so far has hit the best balance between programmer productivity and DevOps happiness. (Although I can't deny that the single binary outputs of Go and Rust are definitely the ideal pieces to maintain from a sysadmin's perspective.)
uncle_j 7y ago
Every few years something like this gets written. I remember similar things being written in 2004-2005 before the Core 2 line of processors came out. There is still improvements being made to the current tech or new takes on the current tech that aren't incorporated yet in the current bunch of consumer processors. Also I happen to think that what makes a computer fast is the removal of bottlenecks in the hardware. You can take quite an old machine (I have a Core 2 Quad machine under my desk) slap in an SSD and suddenly it doesn't feel much slower than my Ryzen 3 machine.
- markrages 7y ago
  I first heard this when I was in school in the mid nineties.
- gameswithgo 7y ago
  except now it has actually been true for years. clock rates aren't increasing. advances in performance have been only from things that are tricky for developers to efficiently leverage (cache, simd, more cores). We need developers who understand these new low level details as much now as we needed that kind of developer in the past.
  - uncle_j 7y ago
    > except now it has actually been true for years Sure it is true. It isn't a tech journo writing a quick piece to get some clicks. I am quite cynical these days. There hasn't been any competition in the Desktop CPU space for years until 2019. Also clock rates haven't increased since the mid-2000s (there were 5ghz P4 chips). Clock rates being an indication of speed stopped being a thing back then when I could buy a "slower" clocked Athlon XP chip that was comparable to a P4 with a faster clock. Also more stuff is getting offloaded from the CPU to custom chips (usually the GPU). > We need developers who understand these new low level details as much now as we needed that kind of developer in the past. I suspect that there will get better compiler and languages. I work with .NET stuff and the performance increase from a rewrite to .NET core is ridiculous.
    - 7y ago
ledauphin 7y ago
I just don't buy this. I cut my teeth as a HPC programmer working with C and writing no-lock algorithms. There will always be a need for that, but realistically the vast majority of software being developed is simply not performance-critical. It's designed to work at human speed. Advances in language, compiler, and runtime implementations will continue to keep up with any growth in the need for performant applications for the foreseeable future, despite the looming collapse of Moore's Law.
- falcolas 7y ago
  Even if the software only needs to respond at a certain speed, scale will quickly make you either pay through the nose for better hardware or optimize the software so that it can respond in a small fraction of the original speed. The trick, as always, is finding balance between paying for hardware and paying developers.
  - tluyben2 7y ago
    But that is the case now too and in my experience it swung to paying through the nose for hardware in general; as more or less a sidetrack I take on projects where I optimise (mostly online) systems. Example; a few weeks ago a startup asked me to check out their setup as they were spending almost 30k$/mo on AWS. I spent a few days optimising and now they are down to less than 10k$. With some more work it will be a few 1000$; there is still so much wrong. But that is less low hanging fruit so it will be a lot more expensive. Still well worth it imho. People really bought into the ‘people are more expensive than hardware’ as an excuse to get screwed like this. For $5k in human cost, these guys (and their investors) now save 200k/year in hosting. And this is not an isolated story; I am working on another one at this very moment. Programmers have become so incredibly sloppy with the ‘autoscaling’ and ‘serverless’ cloud ‘revolution’.
    - ledauphin 7y ago
      You're quite right that there's plenty to optimize. It's not that there isn't money in optimizing. It's that there's often not _enough_ money in optimizing to rise to the level of the top N priorities for a business.
tomrod 7y ago
This is a topic that really interests me, but I couldn't read the article -- either a paywall, ad-wall, or some other reader-hostile blocker incongruent with the foundation of the Internet prevents usability. Ah well. I'll join the conversation regardless. For all the programmers out there -- _how do we do this?_. I came into programming through Matlab and Python in Economics and Data Science. I don't have formal training in software engineering. I know some C, some Fortran, and have a journeryman's understanding of how my tools interact with the hardware they run on. Where can I learn how to be extremely efficient and treat my operating environment always as resource constrained? Am I correct in seeing the rise of point-and-click cloud configuration hell-sites like AWS are masking the problem by distributing inefficiently? (sorry if unrelated, spent hours debugging Amazon Glue code last night and struck me as related). In other words -- how can we tell what is the path forward?
- bordercases 7y ago
  The fundamental tradeoff is between control and abstraction. Better control typically means going closer to machine/operational semantics, better abstraction typically means going to denotational semantics. Compilers are what mediate between these two domains, but tend to become more bloated as they have to accommodate both more diverse hardware and more numerous languages. This helps the working programmer ignore the problem of writing good code but only for so long. It only delays the inevitable as the returns from clever compilation can't go on forever, and in fact these returns become more volatile as hardware architectures become more complex (typically through more cores or extra caches, incurring synchronization costs). Thus for maximum performance through binaries one would have to practice tweaking compiler settings which just creates another layer of abstraction and defeats the point of having this step automated for you. Programmer training in particular needs to become both more comprehensive and more specialized. More comprehensive means knowing how each layer of abstraction gets built up from the most common machines (like x86). More specialized means filtering out a lot of people who were trained-for-the-tool and facilitating more cross collaboration between those that can program in a domain but not program for performance. This might mean better methodologies for prototyping across domains or experimentation with organizational structures to complement such methodologies. Functional algebraic programming as a paradigm still seems somewhat underrated to me as a way of cross-cutting conceptual boundaries and getting programmers refocused on how their code is interpreted from the point of denotation. But it comes at great risk from continuing the trend towards more redundant abstraction which is responsible for bloatware. At that point it seems that knowing how these problems are solved without classes types and libraries, or at least how classes types and libraries resolve the complexities of just doing it using the native capabilities of the operating environment (and recursing down to the point of maximal control), might be a big improvement, as it means reversing the greater-abstraction trend. Under these discretions languages like OCaml and Rust seem to make the cut. A lot of good ideas from these languages seem to seep into the design of others. But the white whale is browser programming/web programming, as the browser has become the de facto endpoint for universal application deployment. WASM may or may not fix this. But then we just get to compilers again. This talk did the most for developing my point of view here: https://www.youtube.com/watch?v=443UNeGrFoM https://www.youtube.com/watch?v=443UNeGrFoM Choice quotes include "If you're going to program, really program, and learn to implement everything yourself" and "At first you want ease, but in the end, all you'll want is control." Or just take up another field. We probably need more farmers and doctors than programmers now.
pjc50 7y ago
The major problem areas are those where it's economically "best" to do the computationally inefficient thing. The obvious example is the quick-to-build MVP, but many of the bigger problems come from platform conflicts. Because we have at least five different actively uncooperating operating system platforms, it's hard to build portable native apps - so people build electron apps instead. We also use the web browser as a competitive battleground; due to coordination problems only one programming language and UI model is possible, although another is creeping in via webassembly. Then there's the ongoing War On Native Apps. Every platform holder would love to take the 30% cut of the profits and veto which applications can run on the platform. We're left with Windows (non-app-store) and sort of MacOS (although watch out for notarisation turning into a veto in the future). And sadly this has very real benefits in malware prevention. Systems which run arbitrary code get exploited. Beyond that there's cryptocurrency, where finding a less-efficient algorithm is a design goal to maximise the energy wasted, in order to impose a global rate limit on "minting" virtual tokens.
- bordercases 7y ago
  Now this is horror.
- contingencies 7y ago
  Don't forget the benefits of portability and the need to hire people as factors contributing to the use of higher level, generally less efficient languages: a few days back I read a description of C as a "hard to find skill these days".
  - zozbot234 7y ago
    There are plenty of people with real skills in C working in embedded. It might even be easier to find C than C++ developers.
    - mikehollinger 7y ago
      I challenge you to find a C “boot camp.” In fact doesn’t this point to a gap in the marketplace? Where are my “IOT ALL THE THINGS / 5G / Edge” bootcamps? Where are the “leetcode” challenges that talk about proper sampling rates for an 8-bit A/D converter, or implementing a closed loop PID in a 16-bit architecture? I suspect that that’s what the Grandparent comment is commenting on — there’s so much talking about the former and so little talking about the latter - even if every computer engineer graduating from a ABET-certified institution is these skills.
qwerty456127 7y ago
Why do we need more computer power? I haven't upgraded my laptop since 2009 (well, I've replaced its HDD with an SSD 2 years ago and it made a huge difference) and I'm okay. Some people insist on photorealistic 3D graphics in the games they play, I agree that's cool but wouldn't say that's anything close to important.
- jryb 7y ago
  It’s critical for a lot of scientific and industrial applications. Too many things just can’t be done without a supercomputer.
  - btrettel 7y ago
    I disagree. I did my masters' on computational fluid dynamics (CFD) and I'd say that a large fraction of supercomputer use (in fluid dynamics at least) is wasted. Mostly because people take naive approaches and end up computing the wrong thing, set up their simulation poorly, reinvent the wheel, use HPC on something that can be computed by hand, etc. If they read more of the literature they'd have a more solid grasp on things and use the software much more efficiently when they do use it. My philosophy at the moment is to use HPC only when I've exhausted other possibilities. I think many people jump to HPC prematurely. The simpler approaches are so much cheaper that I think it's usually worthwhile. I'm skeptical of the argument that it's cheaper to use HPC than it is to use more efficient methods in this case, because the more efficient methods are often something like a few days spent reading to find the right equation or existing experimental data vs. at least that much setting up a simulation and longer to run it. Edit: Bill Rider has a bunch of blog posts that make similar points: https://wjrider.wordpress.com/2016/06/27/we-have-already-lost-to-the-chinese-in-supercomputing-good-thing-it-doesnt-matter/ https://wjrider.wordpress.com/2016/06/27/we-have-already-los... https://wjrider.wordpress.com/2015/12/25/the-unfortunate-myth-of-the-hero-calculation/ https://wjrider.wordpress.com/2015/12/25/the-unfortunate-myt... https://wjrider.wordpress.com/2016/05/04/hpc-is-just-a-tool-modeling-simulation-is-what-is-important/ https://wjrider.wordpress.com/2016/05/04/hpc-is-just-a-tool-... https://wjrider.wordpress.com/2016/11/17/a-single-massive-calculation-isnt-science-its-a-tech-demo/ https://wjrider.wordpress.com/2016/11/17/a-single-massive-ca... https://wjrider.wordpress.com/2014/02/28/why-algorithms-and-modeling-beat-moores-law/ https://wjrider.wordpress.com/2014/02/28/why-algorithms-and-...
jingfire 7y ago
I like the statement saying that software is only limited by human imagination. Meanwhile it is also the case that better hardware brings more possibilities to what we can do.
The_rationalist 7y ago
Are there any progress/path to progress for making competitive 3D cpus/asics? I understand that 3D has thermal issues but couldn't this be prevented by increasing (dead) dark silicon and maybe water cooling inside the 3D chip? Not directly comparable but brains are state of the art of computing and are tri-dimensionals.
matt2000 7y ago
It seems like there might be a pretty straight up tradeoff between difficulty of developing software and quantity of software produced. So the more we attempt to optimize at a lower level, the more time it takes to develop, and the less software someone can make and maintain. So, given that - would you rather lose 30-40% of the apps you use and like, but the rest are faster? Or keep using everything you have now? There are exceptions to this, as with everything, but it's not as easy as this article makes it sound, i.e. "Just make faster stuff dummy!" There's always a cost.
- zozbot234 7y ago
  That's just not true. In fact, we're losing 30%-40% of the software we use and like every single day simply because people write utter crap and then pointlessly rewrite it over and over. If we placed more focus on having sane development practices and good computer assists for developers, we'd ultimately find it easier to develop software and maintain it over time, such that there'd be little or no need to throw stuff away altogether.
- Falkon1313 7y ago
  We have cheap ubiquitous personal computers that can display streaming high definition video, with audio streams and subtitles, on a virtual screen inside a virtual reality - while multitasking and running other programs in the background. The hardware's plenty good enough for daily use. The problem is that software practices have gotten so bad that a simple text messenger or email client uses at least as many resources as that program that's streaming HD video within a virtual reality, just to send or receive a few bytes of text now and then. I'd be ok with losing 30-40% of the overbloated apps, because then they could be replaced with apps that don't need 2GB of dependencies to left-pad a string. We've really gone overboard on the "code reuse is great" and "don't reinvent the wheel" to the point that every program tries to include as much as possible of all code ever written and every wheel ever designed.
- pdimitar 7y ago
  > would you rather lose 30-40% of the apps you use and like, but the rest are faster? Or keep using everything you have now? Dude, I agree to lose at least 80% of them, most are useless and with bad UX on top of that. Even worse: they are distracting. At some point hiring the programmers to pour software by the kilogram becomes a visible problem -- when the businessmen wake up to the fact that the amortised cost of a job sloppily done (say, over the course of the next 2 years) is much higher than investing 20-30% more upfront. That's what the article is arguing for, IMO.
n_ary 7y ago
The article read to me like one of those posted every 6-8 months with random thoughts someone had in one morning reminiscing old days with oranges compared to sports cars and complete disregard that, as time marches on, things change, people(customers/users) want more, convenience is prioritized. I'll also reminiscence a bit: back in 2000s, my 266MHz, 64MB, 4.1GB HDD PC would let me install a 2GB full feature third person adventure game(Legacy of Kain: Soul Reaver, for exampler) worth nearly double digit hours of play, currently it takes 2x of disk space to install a basic platformer giving 1-2h of fun. Every new game lags to hell on a new PC because I have opted for 1 year old GFX card. I can view a PDF nicely with SumatrPDF yet Adobe Acrobat Reader takes 3-digit MB to offer same feature & 5x more time to start. I could use IRC in 2000s while Slack takes all of my RAM available. A website back in days would be few kB, I mean people here frequently compare HN with Jira or how funny it is that Netflix has to spend engineering effort to improve time-to-first-render on it's landing page which is static! Those are facts, not so good: Soul Reaver vs Assassin's Creed is bad idea, because people didn't mind if grass was just flat texture or hero looked like walking cubes. SumatraPDF can open a PDF but Adobe Reader gives me annotation, form filling, signing etc. NFS2 was just racing, NFS:Heat players demand customizing exhaust gas color. Netflix home page loads more images combined than "back in days" and must adapt to big or small screens so it looks great everywhere. Jira lets me drag-n-drop a ticket while it took x3 time to update same ticket back in days in several form refreshes. HN is the simplest CRUD, it just lets me vote and post basic text, heck it delegated search to algolia(a different service)! The features Slack offers will require 5-7 extra different services if I were to use IRC. But those kinds of reality don't get posts up-voted, so instead they are always like ranting about why Whatsapp needs more resources than the SMS app when both lets me send text to someone else? Anyways, things change over time, in 2000s, my PC would lag if I opened MSWord & had windows Media player playing some HD videos or a game would crash if I tabbed out of it to check something. But now I have 20+ tabs open that live update stock tickers and have texts infested with hundreds of advert monitoring things while a tiny window plays current news in corner while am typing away happily in IntelliJ IDE, and have a ML model training in background. Now I can also record a HD version of my gameplay and tab out too. I think, in future complex development will take place in the cloud, we'll probably have high speed internet everywhere and online IDE or similar so everything happens in cloud. Similarly how 4GB HDD costed a fortune in 2000s but same price gets me a x100 capacity now, cloud resources will improve while prices will go down. :)
nickpinkston 7y ago
We're mostly fighting Murphy's Law, not Moore's law. As said below, most problems are so far from being compute/$ or otherwise technically limited and far more about organizational / political issues putting vast inefficiencies into these systems and priorities that fund their creation.
- wpietri 7y ago
  Definitely. Honestly, I'd be excited if hardware stopped progressing. Ever-better hardware and ever-shifting platforms cover up a multitude of organizational sins. There's much less incentive to write good code given the rate at which code gets thrown out, and given what people are willing to spend on their AWS bills before asking if something could perhaps be improved.
  - pdimitar 7y ago
    Yep, agreed. But to be fair, hardware will stop progressing pretty soon IMO. PCIe 4.0 backbone is quite strong and a lot of companies, when buying workstations or servers based on it, won't move on from it for quite a while. Or so I hope.
- fuzzfactor 7y ago
  From the article: >In a lecture in 1997, Nathan Myhrvold, who was once Bill Gates’s chief technology officer, set out his Four Laws of Software. 1: software is like a gas – it expands to fill its container. 2: software grows until it is limited by Moore’s law. 3: software growth makes Moore’s law possible – people buy new hardware because the software requires it. And, finally, 4: software is only limited by human ambition and expectation. Codified anti-recycling.
JustSomeNobody 7y ago
Right now, most organizations (and developers) are focused on developer speed/productivity. As compute resources plateau, some developers will be required to focus on compute efficiency and speed. There will always be a limit to how fast you want your CRUD web app to run vs how much you want to spend on developers, though.
- pdimitar 7y ago
  You are correct on the outset. I am simply observing the pendulum being on the one extreme end for a long time now though -- businesses always optimise for minimum time to deliver a new product and then pay very hefty consulting fees to fix the mess that could have been easily avoided in the first place (by making the project's development time 20% longer) -- which I am willing to bet my balls would not have been fatal for the business, in like 90% of the cases. For things to go well and optimally, the pendulum should never be on the extremes. Sure, you guys are in a hurry. OK. But I must protect my name and your interests and must do a good job as well. Don't make me emulate a bunch of clueless Indians, please. Just go hire them. Businessmen aren't very good at compromises when it comes to techies. I am still coming to terms with that fact and to this day I cannot explain its origins and reasoning well.
LargoLasskhyfv 7y ago
Stock photo shows voltage regulator circuitry beneath cpu, most likely SMD capacitors. I wonder if the author thinks these are the parts he is writing about?
- userbinator 7y ago
  Those are the decoupling capacitors under the CPU socket. A very odd choice of photograph for this article, but perhaps an ironic hint that we need programmers who also know more about the hardware...
- mtreis86 7y ago
  At the least the editor does, as that photo is captioned, "Only so many transistors can fit on a silicon chip."
champtar 7y ago
One of the best 2h practical course that I had was just write the fastest square matrix multiplication. You could use any language, any algorithm, just no libraries. The target was a 32 core CPU server (this was ~10 years ago). At 5000x5000 all the Java and Python attempts were running out of memory. In C, We tried some openmp, some optimized algorithm, but in the end the best trick was to flip one of the matrix so that memory could be always prefetched. Out of curiosity another student tried GNU Scientific Library, it turned out to be ~100 times faster. My take away was find the right tool for the job! A fun read on cloud scale vs optimized code is this recent article comparing ClickHouse and ScyllaDB (https://www.altinity.com/blog/2020/1/1/clickhouse-cost-efficiency-in-action-analyzing-500-billion-rows-on-an-intel-nuc https://www.altinity.com/blog/2020/1/1/clickhouse-cost-effic...)
- jonas21 7y ago
  Yeah, I wouldn't be surprised if the majority of code performing large matrix multiplications these days was written in Python and executed on GPUs by libraries like Tensorflow and PyTorch. With the right abstractions, programmers can be "lazy" and still get great performance.
  - srg0 7y ago
    Matrix multiplication is usually done by a platform-specific BLAS library (BLAS is an API, there are multiple implementations, e.g. Intel MKL, OpenBLAS, cuBLAS). There are some other linear algebra APIs/libraries, but this is what's used the most. Most of the numerical code that cares about performance for linear algebra uses this API and links an appropriate implementation.
  - otabdeveloper2 7y ago
    The 'written in Python' you speak of is actually Fortran under the hood.
- agumonkey 7y ago
  reminds me of the dude who managed to parse TB with awk instead of whatever spark like product was trendy
kraig911 7y ago
How many years was it where bridges were made only out of wood? I feel engineers before us had the foresight to see the possibilities but lacked the tools and understanding. I fear only when people realized the economy needed to support large mammals crossing a bridge at one time did they really engineer bridges to support that weight. I think the same metaphor could be said for computing.
- pdimitar 7y ago
  Yeah, most people only get creative only when they absolutely must, and not one minute earlier.
peterwwillis 7y ago
Does the sad realization occur to anyone else that if all software was open instead of proprietary, we probably would already have the most optimized, most efficient, most advanced software? Instead, most of it's proprietary, so we've been re-inventing the wheel for decades. I remember how well and how fast software worked 20 years ago. Today I have to reboot my telephone to make a call.
- noisem4ker 7y ago
  I think there's so much more code already than people are capable and willing to work on. Exposing my business' code to the world would only add to the pile. Open source as we know it is the perfect playground for trying out new technologies, just for the sake of it or for building resumes. This is exactly "reinventing the wheel" as you say it. Last, I'm not sure of the link between open source and software quality.
- mkl 7y ago
  This doesn't make sense to me. There's lots of open source software that's widely used, but most of it is not the "most optimized, most efficient, most advanced". I think you are looking at the past with rose-tinted glasses. The software I remember from 20 years ago was generally slow, clunky, unstable, and often didn't work very well.
xvilka 7y ago
Finally, a time for Electron and JVM to go away.
deleted 7y ago
[deleted]
jlj 7y ago
Functional programming is something to watch and learn. It can help take advantage of multi-core single machines and distributed computing alike because it is thread safe due to using immutable variables and the mathematics behind pure functions. Compared to OOP, no locking, concurrency, or race conditions to worry about if used correctly.
- Ericson2314 7y ago
  Functional program helps immensely, but I don't think you are describing it quite right. You cannot to distributed systems without concurrency. Even if you don't have low level synchronization failures, you still need to watch out for determinism. Fortunately we have the math for that (usually order theory). I make this point as someone whose job is Haskell. Too many people expect awesome magic sauce and basically write the same old imperative stuff in functional programming languages: not in the small but in the large. There's still plenty of benefit of using a good language for that, but you won't get zomg auto-parallelism.
  - jlj 7y ago
    Meant that it enables concurrency and parallelism without having to worry so much about the mechanics of it, which helps take advantage of multiple cores as described in the article. Immutable data structures and pure functions avoid data corruption when two or more threads are working on the same data. OOP requires a lot of code to get the same result, true? I'm new to FP myself and it seems like if done wisely it simplifies multi thread, parallel processing quite a bit.
    - Ericson2314 7y ago
      I would check out https://github.com/reflex-frp/reflex https://github.com/reflex-frp/reflex which is truly a godsend for concurrency but actually uses loads of mutation internally. Haskell helps loads here but the mechanisms are a lot more complex and nuanced than the circa 2000 ideology you were saying.
  - pdimitar 7y ago
Ericson2314 7y ago
We are having worse and worse latency, though not bad throughput, but the real issue is complexity. We just keep on pilling more crap on top of the old crap. I'm lucky at work we write lots of stuff to avoid the tell/mound, but hello! where is the rest of the industry on this? [You can use our stuff if you like, it is all public. Let's rebuild together.]
pier25 7y ago
There’s also the environmental factor nobody takes into account. Less CPU cycles means less emissions. When a piece of software is used by millions or even billions it must be significant.
- xaedes 7y ago
  There is actually a paper about this topic: "Energy Efficiency across Programming Languages"
  - pier25 7y ago
    Thanks I'll check it out!
thewebcount 7y ago
I don't think this article is seeing the whole picture. The author talks about how programmers used to have to cram a program into 16KB of RAM (or ROM) and it had to be efficient. But that came at a huge cost. Reading 6502 Assembly with variables that could only have up to 6 characters for their names, and were all global was a huge pain in the ass! We have great optimization tools freely available these days, and when necessary they are used. We also have great standard libraries with most languages that make it fairly easy to choose the right types of containers and other data structures. (You can still screw it up if you want, though.) As soon as it becomes economically necessary to write more efficient code, we will be tasked with that. I work on professional software and we do a hell of a lot of optimization. Some of it is hard, but a lot of it could be done by regular programmers if they were taught how to use the tools.
mjpuser 7y ago
We also have a mantra against optimization until you know that you need to. It seems too cost and time prohibitive to put these things on the programmer to maintain, and that we need to develop tools to help optimize our code. Maybe the next generation of optimization techniques will be runtime instead of compile time. We already have dbs with optimizers, so maybe there will be programming languages with optimizers?
rs23296008n1 7y ago
Usually poorly performant code needs optimisation through a change of approach or mindset. It is the way we are thinking about the problem that is lowering performance. Not necessarily the hardware itself. I've seen locking brought forward as a critical limit. Long discussions about new hardware and adding nodes and all sorts of expenditure required. We need a larger kubernetes. More GPUs! I've also been in the situation where we switched to a plain redis queue (LPOP, RPUSH) scheme and gotten 10x the improvement just by lowering message overhead. A lot of the very complex solutions require so much processing power overhead simply because they involve wading through gigabytes. Better alternative solutions involve less gigabytes. Same hardware, different mindset. Not even talking about assembly language or other forms of optimisation being required. Just different philosophy and different methodology. Perhaps we need programmers with the mental flexibility to run experiments and be open to alternatives. (Spoiler: we've already got plenty of these people.)
- pdimitar 7y ago
  We have a good number of them indeed but nobody wants to pay them to fix most of the IT area. Ironic, right.
  - rs23296008n1 7y ago
    Or we can't get them past the HR hiring policies that eliminate all candidates. Been through that myself. I even got multiple tech leads to sit the testing and watched them fail. They were already on the team yet would not be able to get on the team. Absurd but true. Contracting is such a strange world. I've drifted so far into it I've lost the ability to see how salary based people even get work. All I can do is keep the door open for as many people as possible. Sometimes I need to actually assert the door into existence. This was something I didn't know was possible until recently.
    - pdimitar 7y ago
      Can you tell me more? Sounds quite humorous. And quite usual...
tus88 7y ago
Wtf would the Guardian know.
hyko 7y ago
No we’re not – no we don't.
lousken 7y ago
Yea, it's really annoying when IS vendor said their solution needs 16GBs of RAM for every computer when it's just all basic stuff like dashboards, graphs, tables etc. Even modern PC games still don't require this amount.
stebann 7y ago
When I read articles similar to this one, I can't avoid asking myself how can universities take a more integrated approach to disciplines related to software engineering and computer science. I know that we can't learn all the stuff that's going around, but some standard organization should be put on the table. I felt it many times while studying this lack of "low level" preparedness.
m0zg 7y ago
You don't need "new" programmers. Just dust off some "old" programmers who are now merely 40-50 years old. There's plenty of life still in us, and we can tell a pointer from a hole in the ground.
- axilmar 7y ago
  We are too expensive for them, it seems.
Priem19 7y ago
“The only consequence of the powerful hardware I see,” wrote one, “is that programmers write more and more bloated software on it. They become lazier, because the hardware is fast they do not try to learn algorithms nor to optimize their code… this is crazy!” This is remarkably accurate for games as well. Insurgency: Sandstorm for example. I was full of hope when I learned it was being developed in Unreal Engine which supports large scale combat much better than Insurgency's source engine. Unfortunately when it came out if performed much worse than its predecessor. Working with these engines has become so easy you don't really have to 'think' anymore and can just keep throwing stuff in.
a_ranom_dev 7y ago
Title should be changed to needing old programmers, as many comments have hit upon.
luord 7y ago
There were several good points both for and against the article in this comment section. I was pleasantly surprised, usually the threads caused by posts like this turn into "static typing vs dynamic typing" or "functional vs object oriented" flamewars. As for my own opinion: yes, optimization is key, but we gotta remember not to make it premature. Take advantage of the fast hardware to actually create something; once we know that the something is viable, let's refactor and optimize.
- pdimitar 7y ago
  Literally every experienced programmer would like to do this. But when you get to that last stage the shot-callers are like "nah, it's fine" and you never get to the optimisation. I've seen many products die simply because customers get frustrated with laggy or buggy experience and leave. By the time the businessmen wake up, it's usually too late.
  - codeisawesome 7y ago
    Which means that Business Analysts need to save the world by proving to the shot-callers things similar to what Amazon found (a few ms of lag in the site load caused $$$ of revenue loss). The ever improving Observability stack combined with strong analytics on the client-side can make this possible. Perhaps regulation around Climate Effects (or carbon taxes on inefficient software) might also bring about an industry-wide change of attitudes (and incentives).
    - pdimitar 7y ago
      Trouble is, most businessesmen I worked with would give you a blank stare if you tell them they need a business analyst.

The renewed interest in C++ and other compiled languages is an indication of the need to get more efficient. Programmer skill will become more important in the future. But they won't be today's skills. I expect that programming in the future will be more about getting the AI to do what you want rather than writing code directly.

thechao 7y ago
I’m already an AI you can pay to get a computer to do what you “want”; the problem is ‘what you want’ is so poorly specified, there’s no way to turn it into an actionable set of steps!
- meztez 7y ago
  This comment has to be the most insightful I have ever read. It is true on so many levels and captures perfectly the mentality that some senior decision makers have about AI.
- archi42 7y ago
  Other dev: "I wish I could just tell an AI to do $implementation for me", me: "You know what our boss just did?". ;-)
papermachete 7y ago
Agreed. Hopefuly a fusion between prolog and haskell comes by - a modern declarative language to end all languages. Let it decide what's best for cache locality and profile your performance. Let it choose the best data structures based on your constraints - compile time and maybe runtime.
- WhyNott 7y ago
  FYI, a fusion between prolog and haskell already exists: its called mercury. Its a statically compiled language with decent performance characteristics (at least, in its category).
  - tluyben2 7y ago
    Mercury was pretty good last I tried and a very interesting language at that; I like Prolog and did quite a lot of work in it in the 90s (mostly research). I like how clean it looks (that's from Prolog) and the performance is great due to the fact that you give quite a lot of info to the compiler when you are programming (see for instance [0]). It has many backends it compiles to (Java, .NET, Erlang, native; not sure how well they are all maintained). It is a shame that not more people are working on the language and that not more people use it; I think there was not enough hype surrounding it. I gave up as it could not produce native code for ARM, a platform I always need for everything I do (for many years already), so to take a language seriously as something to dive in, it needs to have ARM support. Not sure what the state of that is now; this is many years ago. [0] https://www.mercurylang.org/information/doc-latest/mercury_ref/Determinism-categories.html https://www.mercurylang.org/information/doc-latest/mercury_r...
    - pdimitar 7y ago
      As a general comment and talking about myself exclusively, it's a new kind of fatigue that I would call "oh look, another programming language". There are quite a few very interesting and solid languages out there. One example for something that's not nearly well enough utilised or used widely is OCaml -- although in its case the lack of true multicore CPU support definitely cripples interest. But the language has an amazing type system that catches a _TON_ of errors (maybe even more than Rust's compiler, not entirely sure). And its compiler is just lightning-fast, fastest I've ever seen in fact. And it is multi-paradigm language (OOP and functional, and a lot of interesting typing constructs on top, half of which I don't even understand). Etc. Not advocating for OCaml by the way (I work with Elixir and am looking to get better at Rust lately). It's just an example demonstrating that, again, there are a good amount of very solid languages and runtimes out there but we the programmers are so busy either (a) belonging to tribes or (b) being so damn busy we can't look beyond the tech we do our daily job with -- and then a lot of excellent tech gets left in the dust. :( Mercury might be one of these tech pieces. And it's definitely not the only one.
crazypython 7y ago
It seems to me that if we can merge https://github.com/Syniurge/Calypso https://github.com/Syniurge/Calypso into LDC, we can get a language that is easier to understand and compiles faster than C++, Dlang.
Forge36 7y ago
Using the data we what have would already be a big gain. I think that's AI's biggest contribution. I've seen a lot of time and complexity go into improving functionality beat by someone who wrote code to track what actions were taken, and adjust based on frequency of use. The first option is needed if you have no data and cannot gather the data, the second is great because it can adjust itself over time. This is where I see the SRE (site reliability engineers) role. The developers making changes are put into a position where they measure the cost impact of a decision. It's these feedback loops, and the practices they instill, that I believe we need. New programmers can help break the mold, but without good feedback they'll fall into the same traps.
falcolas 7y ago
Identifying the right characteristics in data, and creating properly tagged corpuses of data that correspond with the right characteristics is no less work than writing code. Not to mention manually written algorithms are, in many cases, more accurate than ML heuristics (for a terrible yet relevant example in the finance industry, identifying the correct sum of a set of numbers).
sly010 7y ago
Why not both?
jobseeker990 7y ago
What about Rust or D? OR even Go-lang?
quotemstr 7y ago
I don't think the new interest in compiled language reflects anything other than ongoing cyclical changes in fashion. Neither "compiled" nor "interpreted" language families (the terms are vague and the same language can fall in both categories) has a slam dunk performance advantage over the other. > I expect that programming in the future will be more about getting the AI to do what you want rather than writing code directly. This is the clear endgame. The question is how long it takes to get there.
- throwaway17_17 7y ago
  It’s a small semantic nitpick, but I think that you have to qualify the domain of conversation in stating: ‘neither “compiled” or “interpreted” language families ... has a slam dunk performance advantage over the other.’ If this is universally qualified, where are the scientific HPC simulations written in python, AAA video games written in Haskell, and fin tech trading apps written in Lisp? I am not stating that there are no places where compiled vs interpreted can never produce acceptable results, it’s just more nuanced than a forall type proposition. Addendum: I am aware C# could sort of be ‘interpreted’ and Unity is C#, so there is at least some evidence in the game category, but I’d quibble over the best-in-class C#/Unity game being considered 100% C#.
  - sudosysgen 7y ago
    Unity is also quite far from being known for the best performance.
cmdshiftf4 7y ago
>The renewed interest in C++ and other compiled languages is an indication of the need to get more efficient. I kind of disagree with this based on intuition alone. Most developers, professional developers, are using web tech (JS stack in particular - Node and hyped front-end frameworks). Yet we"re seeing "interest" in compiled languages such as Rust, despite almost nobody using it professionally and almost nobody doing much with it outside of simple proof of concepts. To me it points toward a developing sense of insecurity in modern professional developers that simply being a JS dev isn't really programming/development and they've to "prove" themselves with lower level tech. Something that indicates that, for me, is in StackOverflow's 2019 survey [0] the most used tech was JS and that which surrounds it, followed by Python and other easy-to-get-going-well-supported tech. Yet the "Most Loved" was Rust. I could be wrong, and I'm open to being, but I intuitively I don't believe the interest in performant technologies is in the face of the sheer bloat we've seen, particularly from the web-front. >Programmer skill will become more important in the future. My prediction on this, not so AI specific, is that developing and deploying web-tech will continue to become easier and easier, meaning it'll take less people to do it. Sure, work may arise from developing countries/economies to supplant a drop in demand for it in the developed world, but maybe not. Combined with a potential bubble burst in tech, I think those relying on web dev for a living could be in trouble in the coming decade. I don't foresee much in terms of companies trying to optimize operational costs by instructing their devs to write their code more efficiently with memory/performance in mind to reduce operating costs, and thus spur a push toward jumping on compiled languages. If anything, cloud computing will continue to get cheaper and cheaper as the big 3 continue to try and absorb as much marketshare as possible. [0] https://insights.stackoverflow.com/survey/2019#overview https://insights.stackoverflow.com/survey/2019#overview
- steveklabnik 7y ago
  Rust is used for far more than proofs of concept, and is deployed at some of the largest tech companies in some of their key products.
  - cmdshiftf4 7y ago
    Not disagreeing with that. Although, in re-reading the above, I have made a grave mistake above, contrasting most used with most loved. SO's "most loved" is measured by "of those professional using this language, how many responded that they love using it", so in the case of Rust it's 83.5% of the 3% using it professionally. In retrospect I think my point would be better made by pointing at the difference between the technologies being used professionally and the technologies "most wanted", where Go and Rust are in the top 20% of wanted but the bottom 40% for Go and bottom 20% for Rust. I'll leave the original intact for posterity but what's cited is done so erroneously.
c-cube 7y ago
I'm hopeful about Crystal filling this niche in the future.

Forge36 7y ago

What the future holds is hard to grasp, the piece shared with me yesterday was "we'll spend the next decade removing features, at no loss to functionality" One of the biggest pieces of bloat I've seen is doing the same thing in multiple places, and the new feature not being an improvement over the old workflow in 90% of cases, the efficiency gained 10% was lost in the other 90%

wool_gather 7y ago
> the piece shared with me yesterday was "we'll spend the next decade removing features... Sounds like an interesting read; do you mind sharing a link (or submitting it to HN)?

rini17 7y ago

What will be probably most interesting to watch: the collision between hardware constraints and ever-increasing complexity of standards like Unicode and HTTP.

Zigurd 7y ago

If you look at the volume of software that needs to be produced, and at the trend to include software in more products, and at the entrepreneurial imperative that risk capital is the most expensive resource, it looks very unlikely that handcrafted machine instructions will play a greater role in the future. Cloud computing and SaaS have extended the deadline for coming up with an answer to "What comes after Moore's Law." But it is much more likely to not be based on every coder learning what us olds learned 40 years ago. Instead, optimization is more likely to get automated. Even what we call "architecture" will become automated. People don't scale well, and the problem is larger than un-automated people can solve.

thedevelopnik 7y ago
I don’t think that handcrafted machine instructions are what is necessary. Even switching from languages like Ruby or JS (Node) to languages like Go or Elixir yields tremendous efficiency improvements. Beyond that, developers being conscientious of what they send over the wire, and being just a bit critical of what the framework or ORM produces also can yield substantial gains. I say this as a “DevOps” guy who is responsible for budget at a mid-size startup, where we’re hitting scale where this becomes important. We save about 8 production cores per service that we convert from Rails to Go. Devs lose some convenience, yes, but they’re still happy with the language, and they’re far from writing hyper-optimized, close to the metal code.
- deleted 7y ago
  [deleted]
- pdimitar 7y ago
  You mentioned it yourself early in your comment but IMO going from Rails to Go is a bit weird. Rails to Phoenix (Elixir) is much easier and productive for many devs, it turned out. Elixir itself is almost completely staying-out-of-your-way language as well -- meaning that if your request takes 10ms to do everything it needs then it's almost guaranteed that 9.95ms of those 10 are spent in the DB and receiving the request and sending the response; Elixir almost doesn't take CPU resources. I worked with a lot of languages, Go/JS/Ruby/PHP/Elixir included. Elixir so far has hit the best balance between programmer productivity and DevOps happiness. (Although I can't deny that the single binary outputs of Go and Rust are definitely the ideal pieces to maintain from a sysadmin's perspective.)

uncle_j 7y ago

Every few years something like this gets written. I remember similar things being written in 2004-2005 before the Core 2 line of processors came out. There is still improvements being made to the current tech or new takes on the current tech that aren't incorporated yet in the current bunch of consumer processors. Also I happen to think that what makes a computer fast is the removal of bottlenecks in the hardware. You can take quite an old machine (I have a Core 2 Quad machine under my desk) slap in an SSD and suddenly it doesn't feel much slower than my Ryzen 3 machine.

markrages 7y ago
I first heard this when I was in school in the mid nineties.
gameswithgo 7y ago
except now it has actually been true for years. clock rates aren't increasing. advances in performance have been only from things that are tricky for developers to efficiently leverage (cache, simd, more cores). We need developers who understand these new low level details as much now as we needed that kind of developer in the past.
- uncle_j 7y ago
  > except now it has actually been true for years Sure it is true. It isn't a tech journo writing a quick piece to get some clicks. I am quite cynical these days. There hasn't been any competition in the Desktop CPU space for years until 2019. Also clock rates haven't increased since the mid-2000s (there were 5ghz P4 chips). Clock rates being an indication of speed stopped being a thing back then when I could buy a "slower" clocked Athlon XP chip that was comparable to a P4 with a faster clock. Also more stuff is getting offloaded from the CPU to custom chips (usually the GPU). > We need developers who understand these new low level details as much now as we needed that kind of developer in the past. I suspect that there will get better compiler and languages. I work with .NET stuff and the performance increase from a rewrite to .NET core is ridiculous.
  - 7y ago

ledauphin 7y ago

I just don't buy this. I cut my teeth as a HPC programmer working with C and writing no-lock algorithms. There will always be a need for that, but realistically the vast majority of software being developed is simply not performance-critical. It's designed to work at human speed. Advances in language, compiler, and runtime implementations will continue to keep up with any growth in the need for performant applications for the foreseeable future, despite the looming collapse of Moore's Law.

falcolas 7y ago
Even if the software only needs to respond at a certain speed, scale will quickly make you either pay through the nose for better hardware or optimize the software so that it can respond in a small fraction of the original speed. The trick, as always, is finding balance between paying for hardware and paying developers.
- tluyben2 7y ago
  But that is the case now too and in my experience it swung to paying through the nose for hardware in general; as more or less a sidetrack I take on projects where I optimise (mostly online) systems. Example; a few weeks ago a startup asked me to check out their setup as they were spending almost 30k$/mo on AWS. I spent a few days optimising and now they are down to less than 10k$. With some more work it will be a few 1000$; there is still so much wrong. But that is less low hanging fruit so it will be a lot more expensive. Still well worth it imho. People really bought into the ‘people are more expensive than hardware’ as an excuse to get screwed like this. For $5k in human cost, these guys (and their investors) now save 200k/year in hosting. And this is not an isolated story; I am working on another one at this very moment. Programmers have become so incredibly sloppy with the ‘autoscaling’ and ‘serverless’ cloud ‘revolution’.
  - ledauphin 7y ago
    You're quite right that there's plenty to optimize. It's not that there isn't money in optimizing. It's that there's often not _enough_ money in optimizing to rise to the level of the top N priorities for a business.

tomrod 7y ago

This is a topic that really interests me, but I couldn't read the article -- either a paywall, ad-wall, or some other reader-hostile blocker incongruent with the foundation of the Internet prevents usability. Ah well. I'll join the conversation regardless. For all the programmers out there -- _how do we do this?_. I came into programming through Matlab and Python in Economics and Data Science. I don't have formal training in software engineering. I know some C, some Fortran, and have a journeryman's understanding of how my tools interact with the hardware they run on. Where can I learn how to be extremely efficient and treat my operating environment always as resource constrained? Am I correct in seeing the rise of point-and-click cloud configuration hell-sites like AWS are masking the problem by distributing inefficiently? (sorry if unrelated, spent hours debugging Amazon Glue code last night and struck me as related). In other words -- how can we tell what is the path forward?

bordercases 7y ago
The fundamental tradeoff is between control and abstraction. Better control typically means going closer to machine/operational semantics, better abstraction typically means going to denotational semantics. Compilers are what mediate between these two domains, but tend to become more bloated as they have to accommodate both more diverse hardware and more numerous languages. This helps the working programmer ignore the problem of writing good code but only for so long. It only delays the inevitable as the returns from clever compilation can't go on forever, and in fact these returns become more volatile as hardware architectures become more complex (typically through more cores or extra caches, incurring synchronization costs). Thus for maximum performance through binaries one would have to practice tweaking compiler settings which just creates another layer of abstraction and defeats the point of having this step automated for you. Programmer training in particular needs to become both more comprehensive and more specialized. More comprehensive means knowing how each layer of abstraction gets built up from the most common machines (like x86). More specialized means filtering out a lot of people who were trained-for-the-tool and facilitating more cross collaboration between those that can program in a domain but not program for performance. This might mean better methodologies for prototyping across domains or experimentation with organizational structures to complement such methodologies. Functional algebraic programming as a paradigm still seems somewhat underrated to me as a way of cross-cutting conceptual boundaries and getting programmers refocused on how their code is interpreted from the point of denotation. But it comes at great risk from continuing the trend towards more redundant abstraction which is responsible for bloatware. At that point it seems that knowing how these problems are solved without classes types and libraries, or at least how classes types and libraries resolve the complexities of just doing it using the native capabilities of the operating environment (and recursing down to the point of maximal control), might be a big improvement, as it means reversing the greater-abstraction trend. Under these discretions languages like OCaml and Rust seem to make the cut. A lot of good ideas from these languages seem to seep into the design of others. But the white whale is browser programming/web programming, as the browser has become the de facto endpoint for universal application deployment. WASM may or may not fix this. But then we just get to compilers again. This talk did the most for developing my point of view here: https://www.youtube.com/watch?v=443UNeGrFoM https://www.youtube.com/watch?v=443UNeGrFoM Choice quotes include "If you're going to program, really program, and learn to implement everything yourself" and "At first you want ease, but in the end, all you'll want is control." Or just take up another field. We probably need more farmers and doctors than programmers now.

pjc50 7y ago

The major problem areas are those where it's economically "best" to do the computationally inefficient thing. The obvious example is the quick-to-build MVP, but many of the bigger problems come from platform conflicts. Because we have at least five different actively uncooperating operating system platforms, it's hard to build portable native apps - so people build electron apps instead. We also use the web browser as a competitive battleground; due to coordination problems only one programming language and UI model is possible, although another is creeping in via webassembly. Then there's the ongoing War On Native Apps. Every platform holder would love to take the 30% cut of the profits and veto which applications can run on the platform. We're left with Windows (non-app-store) and sort of MacOS (although watch out for notarisation turning into a veto in the future). And sadly this has very real benefits in malware prevention. Systems which run arbitrary code get exploited. Beyond that there's cryptocurrency, where finding a less-efficient algorithm is a design goal to maximise the energy wasted, in order to impose a global rate limit on "minting" virtual tokens.

bordercases 7y ago
Now this is horror.
contingencies 7y ago
Don't forget the benefits of portability and the need to hire people as factors contributing to the use of higher level, generally less efficient languages: a few days back I read a description of C as a "hard to find skill these days".
- zozbot234 7y ago
  There are plenty of people with real skills in C working in embedded. It might even be easier to find C than C++ developers.
  - mikehollinger 7y ago
    I challenge you to find a C “boot camp.” In fact doesn’t this point to a gap in the marketplace? Where are my “IOT ALL THE THINGS / 5G / Edge” bootcamps? Where are the “leetcode” challenges that talk about proper sampling rates for an 8-bit A/D converter, or implementing a closed loop PID in a 16-bit architecture? I suspect that that’s what the Grandparent comment is commenting on — there’s so much talking about the former and so little talking about the latter - even if every computer engineer graduating from a ABET-certified institution is these skills.

qwerty456127 7y ago

Why do we need more computer power? I haven't upgraded my laptop since 2009 (well, I've replaced its HDD with an SSD 2 years ago and it made a huge difference) and I'm okay. Some people insist on photorealistic 3D graphics in the games they play, I agree that's cool but wouldn't say that's anything close to important.

jryb 7y ago
It’s critical for a lot of scientific and industrial applications. Too many things just can’t be done without a supercomputer.
- btrettel 7y ago
  I disagree. I did my masters' on computational fluid dynamics (CFD) and I'd say that a large fraction of supercomputer use (in fluid dynamics at least) is wasted. Mostly because people take naive approaches and end up computing the wrong thing, set up their simulation poorly, reinvent the wheel, use HPC on something that can be computed by hand, etc. If they read more of the literature they'd have a more solid grasp on things and use the software much more efficiently when they do use it. My philosophy at the moment is to use HPC only when I've exhausted other possibilities. I think many people jump to HPC prematurely. The simpler approaches are so much cheaper that I think it's usually worthwhile. I'm skeptical of the argument that it's cheaper to use HPC than it is to use more efficient methods in this case, because the more efficient methods are often something like a few days spent reading to find the right equation or existing experimental data vs. at least that much setting up a simulation and longer to run it. Edit: Bill Rider has a bunch of blog posts that make similar points: https://wjrider.wordpress.com/2016/06/27/we-have-already-lost-to-the-chinese-in-supercomputing-good-thing-it-doesnt-matter/ https://wjrider.wordpress.com/2016/06/27/we-have-already-los... https://wjrider.wordpress.com/2015/12/25/the-unfortunate-myth-of-the-hero-calculation/ https://wjrider.wordpress.com/2015/12/25/the-unfortunate-myt... https://wjrider.wordpress.com/2016/05/04/hpc-is-just-a-tool-modeling-simulation-is-what-is-important/ https://wjrider.wordpress.com/2016/05/04/hpc-is-just-a-tool-... https://wjrider.wordpress.com/2016/11/17/a-single-massive-calculation-isnt-science-its-a-tech-demo/ https://wjrider.wordpress.com/2016/11/17/a-single-massive-ca... https://wjrider.wordpress.com/2014/02/28/why-algorithms-and-modeling-beat-moores-law/ https://wjrider.wordpress.com/2014/02/28/why-algorithms-and-...

jingfire 7y ago

I like the statement saying that software is only limited by human imagination. Meanwhile it is also the case that better hardware brings more possibilities to what we can do.

The_rationalist 7y ago

Are there any progress/path to progress for making competitive 3D cpus/asics? I understand that 3D has thermal issues but couldn't this be prevented by increasing (dead) dark silicon and maybe water cooling inside the 3D chip? Not directly comparable but brains are state of the art of computing and are tri-dimensionals.

matt2000 7y ago

It seems like there might be a pretty straight up tradeoff between difficulty of developing software and quantity of software produced. So the more we attempt to optimize at a lower level, the more time it takes to develop, and the less software someone can make and maintain. So, given that - would you rather lose 30-40% of the apps you use and like, but the rest are faster? Or keep using everything you have now? There are exceptions to this, as with everything, but it's not as easy as this article makes it sound, i.e. "Just make faster stuff dummy!" There's always a cost.

zozbot234 7y ago
That's just not true. In fact, we're losing 30%-40% of the software we use and like every single day simply because people write utter crap and then pointlessly rewrite it over and over. If we placed more focus on having sane development practices and good computer assists for developers, we'd ultimately find it easier to develop software and maintain it over time, such that there'd be little or no need to throw stuff away altogether.
Falkon1313 7y ago
We have cheap ubiquitous personal computers that can display streaming high definition video, with audio streams and subtitles, on a virtual screen inside a virtual reality - while multitasking and running other programs in the background. The hardware's plenty good enough for daily use. The problem is that software practices have gotten so bad that a simple text messenger or email client uses at least as many resources as that program that's streaming HD video within a virtual reality, just to send or receive a few bytes of text now and then. I'd be ok with losing 30-40% of the overbloated apps, because then they could be replaced with apps that don't need 2GB of dependencies to left-pad a string. We've really gone overboard on the "code reuse is great" and "don't reinvent the wheel" to the point that every program tries to include as much as possible of all code ever written and every wheel ever designed.
pdimitar 7y ago
> would you rather lose 30-40% of the apps you use and like, but the rest are faster? Or keep using everything you have now? Dude, I agree to lose at least 80% of them, most are useless and with bad UX on top of that. Even worse: they are distracting. At some point hiring the programmers to pour software by the kilogram becomes a visible problem -- when the businessmen wake up to the fact that the amortised cost of a job sloppily done (say, over the course of the next 2 years) is much higher than investing 20-30% more upfront. That's what the article is arguing for, IMO.

n_ary 7y ago

The article read to me like one of those posted every 6-8 months with random thoughts someone had in one morning reminiscing old days with oranges compared to sports cars and complete disregard that, as time marches on, things change, people(customers/users) want more, convenience is prioritized. I'll also reminiscence a bit: back in 2000s, my 266MHz, 64MB, 4.1GB HDD PC would let me install a 2GB full feature third person adventure game(Legacy of Kain: Soul Reaver, for exampler) worth nearly double digit hours of play, currently it takes 2x of disk space to install a basic platformer giving 1-2h of fun. Every new game lags to hell on a new PC because I have opted for 1 year old GFX card. I can view a PDF nicely with SumatrPDF yet Adobe Acrobat Reader takes 3-digit MB to offer same feature & 5x more time to start. I could use IRC in 2000s while Slack takes all of my RAM available. A website back in days would be few kB, I mean people here frequently compare HN with Jira or how funny it is that Netflix has to spend engineering effort to improve time-to-first-render on it's landing page which is static! Those are facts, not so good: Soul Reaver vs Assassin's Creed is bad idea, because people didn't mind if grass was just flat texture or hero looked like walking cubes. SumatraPDF can open a PDF but Adobe Reader gives me annotation, form filling, signing etc. NFS2 was just racing, NFS:Heat players demand customizing exhaust gas color. Netflix home page loads more images combined than "back in days" and must adapt to big or small screens so it looks great everywhere. Jira lets me drag-n-drop a ticket while it took x3 time to update same ticket back in days in several form refreshes. HN is the simplest CRUD, it just lets me vote and post basic text, heck it delegated search to algolia(a different service)! The features Slack offers will require 5-7 extra different services if I were to use IRC. But those kinds of reality don't get posts up-voted, so instead they are always like ranting about why Whatsapp needs more resources than the SMS app when both lets me send text to someone else? Anyways, things change over time, in 2000s, my PC would lag if I opened MSWord & had windows Media player playing some HD videos or a game would crash if I tabbed out of it to check something. But now I have 20+ tabs open that live update stock tickers and have texts infested with hundreds of advert monitoring things while a tiny window plays current news in corner while am typing away happily in IntelliJ IDE, and have a ML model training in background. Now I can also record a HD version of my gameplay and tab out too. I think, in future complex development will take place in the cloud, we'll probably have high speed internet everywhere and online IDE or similar so everything happens in cloud. Similarly how 4GB HDD costed a fortune in 2000s but same price gets me a x100 capacity now, cloud resources will improve while prices will go down. :)

nickpinkston 7y ago

We're mostly fighting Murphy's Law, not Moore's law. As said below, most problems are so far from being compute/$ or otherwise technically limited and far more about organizational / political issues putting vast inefficiencies into these systems and priorities that fund their creation.

wpietri 7y ago
Definitely. Honestly, I'd be excited if hardware stopped progressing. Ever-better hardware and ever-shifting platforms cover up a multitude of organizational sins. There's much less incentive to write good code given the rate at which code gets thrown out, and given what people are willing to spend on their AWS bills before asking if something could perhaps be improved.
- pdimitar 7y ago
  Yep, agreed. But to be fair, hardware will stop progressing pretty soon IMO. PCIe 4.0 backbone is quite strong and a lot of companies, when buying workstations or servers based on it, won't move on from it for quite a while. Or so I hope.
fuzzfactor 7y ago
From the article: >In a lecture in 1997, Nathan Myhrvold, who was once Bill Gates’s chief technology officer, set out his Four Laws of Software. 1: software is like a gas – it expands to fill its container. 2: software grows until it is limited by Moore’s law. 3: software growth makes Moore’s law possible – people buy new hardware because the software requires it. And, finally, 4: software is only limited by human ambition and expectation. Codified anti-recycling.

JustSomeNobody 7y ago

Right now, most organizations (and developers) are focused on developer speed/productivity. As compute resources plateau, some developers will be required to focus on compute efficiency and speed. There will always be a limit to how fast you want your CRUD web app to run vs how much you want to spend on developers, though.

pdimitar 7y ago
You are correct on the outset. I am simply observing the pendulum being on the one extreme end for a long time now though -- businesses always optimise for minimum time to deliver a new product and then pay very hefty consulting fees to fix the mess that could have been easily avoided in the first place (by making the project's development time 20% longer) -- which I am willing to bet my balls would not have been fatal for the business, in like 90% of the cases. For things to go well and optimally, the pendulum should never be on the extremes. Sure, you guys are in a hurry. OK. But I must protect my name and your interests and must do a good job as well. Don't make me emulate a bunch of clueless Indians, please. Just go hire them. Businessmen aren't very good at compromises when it comes to techies. I am still coming to terms with that fact and to this day I cannot explain its origins and reasoning well.

LargoLasskhyfv 7y ago

Stock photo shows voltage regulator circuitry beneath cpu, most likely SMD capacitors. I wonder if the author thinks these are the parts he is writing about?

userbinator 7y ago
Those are the decoupling capacitors under the CPU socket. A very odd choice of photograph for this article, but perhaps an ironic hint that we need programmers who also know more about the hardware...
mtreis86 7y ago
At the least the editor does, as that photo is captioned, "Only so many transistors can fit on a silicon chip."

champtar 7y ago

One of the best 2h practical course that I had was just write the fastest square matrix multiplication. You could use any language, any algorithm, just no libraries. The target was a 32 core CPU server (this was ~10 years ago). At 5000x5000 all the Java and Python attempts were running out of memory. In C, We tried some openmp, some optimized algorithm, but in the end the best trick was to flip one of the matrix so that memory could be always prefetched. Out of curiosity another student tried GNU Scientific Library, it turned out to be ~100 times faster. My take away was find the right tool for the job! A fun read on cloud scale vs optimized code is this recent article comparing ClickHouse and ScyllaDB (https://www.altinity.com/blog/2020/1/1/clickhouse-cost-efficiency-in-action-analyzing-500-billion-rows-on-an-intel-nuc https://www.altinity.com/blog/2020/1/1/clickhouse-cost-effic...)

jonas21 7y ago
Yeah, I wouldn't be surprised if the majority of code performing large matrix multiplications these days was written in Python and executed on GPUs by libraries like Tensorflow and PyTorch. With the right abstractions, programmers can be "lazy" and still get great performance.
- srg0 7y ago
  Matrix multiplication is usually done by a platform-specific BLAS library (BLAS is an API, there are multiple implementations, e.g. Intel MKL, OpenBLAS, cuBLAS). There are some other linear algebra APIs/libraries, but this is what's used the most. Most of the numerical code that cares about performance for linear algebra uses this API and links an appropriate implementation.
- otabdeveloper2 7y ago
  The 'written in Python' you speak of is actually Fortran under the hood.
agumonkey 7y ago
reminds me of the dude who managed to parse TB with awk instead of whatever spark like product was trendy

kraig911 7y ago

How many years was it where bridges were made only out of wood? I feel engineers before us had the foresight to see the possibilities but lacked the tools and understanding. I fear only when people realized the economy needed to support large mammals crossing a bridge at one time did they really engineer bridges to support that weight. I think the same metaphor could be said for computing.

pdimitar 7y ago
Yeah, most people only get creative only when they absolutely must, and not one minute earlier.

peterwwillis 7y ago

Does the sad realization occur to anyone else that if all software was open instead of proprietary, we probably would already have the most optimized, most efficient, most advanced software? Instead, most of it's proprietary, so we've been re-inventing the wheel for decades. I remember how well and how fast software worked 20 years ago. Today I have to reboot my telephone to make a call.

noisem4ker 7y ago
I think there's so much more code already than people are capable and willing to work on. Exposing my business' code to the world would only add to the pile. Open source as we know it is the perfect playground for trying out new technologies, just for the sake of it or for building resumes. This is exactly "reinventing the wheel" as you say it. Last, I'm not sure of the link between open source and software quality.
mkl 7y ago
This doesn't make sense to me. There's lots of open source software that's widely used, but most of it is not the "most optimized, most efficient, most advanced". I think you are looking at the past with rose-tinted glasses. The software I remember from 20 years ago was generally slow, clunky, unstable, and often didn't work very well.

xvilka 7y ago

Finally, a time for Electron and JVM to go away.

deleted 7y ago

[deleted]

jlj 7y ago

Functional programming is something to watch and learn. It can help take advantage of multi-core single machines and distributed computing alike because it is thread safe due to using immutable variables and the mathematics behind pure functions. Compared to OOP, no locking, concurrency, or race conditions to worry about if used correctly.

Ericson2314 7y ago
Functional program helps immensely, but I don't think you are describing it quite right. You cannot to distributed systems without concurrency. Even if you don't have low level synchronization failures, you still need to watch out for determinism. Fortunately we have the math for that (usually order theory). I make this point as someone whose job is Haskell. Too many people expect awesome magic sauce and basically write the same old imperative stuff in functional programming languages: not in the small but in the large. There's still plenty of benefit of using a good language for that, but you won't get zomg auto-parallelism.
- jlj 7y ago
  Meant that it enables concurrency and parallelism without having to worry so much about the mechanics of it, which helps take advantage of multiple cores as described in the article. Immutable data structures and pure functions avoid data corruption when two or more threads are working on the same data. OOP requires a lot of code to get the same result, true? I'm new to FP myself and it seems like if done wisely it simplifies multi thread, parallel processing quite a bit.
  - Ericson2314 7y ago
    I would check out https://github.com/reflex-frp/reflex https://github.com/reflex-frp/reflex which is truly a godsend for concurrency but actually uses loads of mutation internally. Haskell helps loads here but the mechanisms are a lot more complex and nuanced than the circa 2000 ideology you were saying.
- pdimitar 7y ago

Ericson2314 7y ago

We are having worse and worse latency, though not bad throughput, but the real issue is complexity. We just keep on pilling more crap on top of the old crap. I'm lucky at work we write lots of stuff to avoid the tell/mound, but hello! where is the rest of the industry on this? [You can use our stuff if you like, it is all public. Let's rebuild together.]

pier25 7y ago

There’s also the environmental factor nobody takes into account. Less CPU cycles means less emissions. When a piece of software is used by millions or even billions it must be significant.

xaedes 7y ago
There is actually a paper about this topic: "Energy Efficiency across Programming Languages"
- pier25 7y ago
  Thanks I'll check it out!

thewebcount 7y ago

I don't think this article is seeing the whole picture. The author talks about how programmers used to have to cram a program into 16KB of RAM (or ROM) and it had to be efficient. But that came at a huge cost. Reading 6502 Assembly with variables that could only have up to 6 characters for their names, and were all global was a huge pain in the ass! We have great optimization tools freely available these days, and when necessary they are used. We also have great standard libraries with most languages that make it fairly easy to choose the right types of containers and other data structures. (You can still screw it up if you want, though.) As soon as it becomes economically necessary to write more efficient code, we will be tasked with that. I work on professional software and we do a hell of a lot of optimization. Some of it is hard, but a lot of it could be done by regular programmers if they were taught how to use the tools.

mjpuser 7y ago

We also have a mantra against optimization until you know that you need to. It seems too cost and time prohibitive to put these things on the programmer to maintain, and that we need to develop tools to help optimize our code. Maybe the next generation of optimization techniques will be runtime instead of compile time. We already have dbs with optimizers, so maybe there will be programming languages with optimizers?

rs23296008n1 7y ago

Usually poorly performant code needs optimisation through a change of approach or mindset. It is the way we are thinking about the problem that is lowering performance. Not necessarily the hardware itself. I've seen locking brought forward as a critical limit. Long discussions about new hardware and adding nodes and all sorts of expenditure required. We need a larger kubernetes. More GPUs! I've also been in the situation where we switched to a plain redis queue (LPOP, RPUSH) scheme and gotten 10x the improvement just by lowering message overhead. A lot of the very complex solutions require so much processing power overhead simply because they involve wading through gigabytes. Better alternative solutions involve less gigabytes. Same hardware, different mindset. Not even talking about assembly language or other forms of optimisation being required. Just different philosophy and different methodology. Perhaps we need programmers with the mental flexibility to run experiments and be open to alternatives. (Spoiler: we've already got plenty of these people.)

pdimitar 7y ago
We have a good number of them indeed but nobody wants to pay them to fix most of the IT area. Ironic, right.
- rs23296008n1 7y ago
  Or we can't get them past the HR hiring policies that eliminate all candidates. Been through that myself. I even got multiple tech leads to sit the testing and watched them fail. They were already on the team yet would not be able to get on the team. Absurd but true. Contracting is such a strange world. I've drifted so far into it I've lost the ability to see how salary based people even get work. All I can do is keep the door open for as many people as possible. Sometimes I need to actually assert the door into existence. This was something I didn't know was possible until recently.
  - pdimitar 7y ago
    Can you tell me more? Sounds quite humorous. And quite usual...

tus88 7y ago

Wtf would the Guardian know.

hyko 7y ago

No we’re not – no we don't.

lousken 7y ago

Yea, it's really annoying when IS vendor said their solution needs 16GBs of RAM for every computer when it's just all basic stuff like dashboards, graphs, tables etc. Even modern PC games still don't require this amount.

stebann 7y ago

When I read articles similar to this one, I can't avoid asking myself how can universities take a more integrated approach to disciplines related to software engineering and computer science. I know that we can't learn all the stuff that's going around, but some standard organization should be put on the table. I felt it many times while studying this lack of "low level" preparedness.

m0zg 7y ago

You don't need "new" programmers. Just dust off some "old" programmers who are now merely 40-50 years old. There's plenty of life still in us, and we can tell a pointer from a hole in the ground.

axilmar 7y ago
We are too expensive for them, it seems.

Priem19 7y ago

“The only consequence of the powerful hardware I see,” wrote one, “is that programmers write more and more bloated software on it. They become lazier, because the hardware is fast they do not try to learn algorithms nor to optimize their code… this is crazy!” This is remarkably accurate for games as well. Insurgency: Sandstorm for example. I was full of hope when I learned it was being developed in Unreal Engine which supports large scale combat much better than Insurgency's source engine. Unfortunately when it came out if performed much worse than its predecessor. Working with these engines has become so easy you don't really have to 'think' anymore and can just keep throwing stuff in.

a_ranom_dev 7y ago

Title should be changed to needing old programmers, as many comments have hit upon.

luord 7y ago

There were several good points both for and against the article in this comment section. I was pleasantly surprised, usually the threads caused by posts like this turn into "static typing vs dynamic typing" or "functional vs object oriented" flamewars. As for my own opinion: yes, optimization is key, but we gotta remember not to make it premature. Take advantage of the fast hardware to actually create something; once we know that the something is viable, let's refactor and optimize.

pdimitar 7y ago
Literally every experienced programmer would like to do this. But when you get to that last stage the shot-callers are like "nah, it's fine" and you never get to the optimisation. I've seen many products die simply because customers get frustrated with laggy or buggy experience and leave. By the time the businessmen wake up, it's usually too late.
- codeisawesome 7y ago
  Which means that Business Analysts need to save the world by proving to the shot-callers things similar to what Amazon found (a few ms of lag in the site load caused $$$ of revenue loss). The ever improving Observability stack combined with strong analytics on the client-side can make this possible. Perhaps regulation around Climate Effects (or carbon taxes on inefficient software) might also bring about an industry-wide change of attitudes (and incentives).
  - pdimitar 7y ago
    Trouble is, most businessesmen I worked with would give you a blank stare if you tell them they need a business analyst.