22 ms·

What was the last breakthrough in computer programming? (2019)

132 points by ColinWright 5y ago

sfblah 5y ago
This is at least part of the reason that reasonably strong engineers can learn a new programming language in under a day. The paradigms just aren’t that different. I realize there’s a cottage industry of folks creating new languages all the time. But when you read the docs they all bucket into a few categories, and the differences are syntax, tooling and how system services are accessed. All that being said, these three categories do matter. Programming using tools like autocompletion, syntax highlighting and the like does speed productivity. But, like human language, at some point the “right” set of primitives are discovered. From that point on changes become more about culture and fads than concepts.
- gcanyon 5y ago
  Try learning J in a day. It...won't go well -- but in a good way. :-) As you say, for many languages the paradigm is some variation of C, and the concepts are largely interchangeable. Then you approach something like J, where (trivial example) +/%# returns the average of a list by composing three functions: + sums; % divides; # counts; with a modifier / that distributes + throughout the list; and you begin to realize you're not in Kansas anymore. https://en.wikipedia.org/wiki/J_(programming_language) https://en.wikipedia.org/wiki/J_(programming_language) I don't think the "right" set of primitives is as obvious as you say. Obviously branching and loops are foundational to many languages, but even those are optional given the right design, and they can be implemented in very different ways.
  - raxxorrax 5y ago
    ÅF - Fibonacci in 05AB1E that are less than the current number on the stack - Good tip for when you get THAT code interview and can pick the language. Just need to know the code for Å if you are not from Denmark.
  - dahfizz 5y ago
    That's just a syntax over map() and reduce(). There are no new / different primitives in J, just a new syntax that emphasizes the use of arrays.
    - gcanyon 5y ago
      It's a bit ironic that we're essentially having a blub language debate on ycombinator's web site. I'll defer to Paul Graham's response: http://www.paulgraham.com/avg.html http://www.paulgraham.com/avg.html
  - IncRnd 5y ago
    J is essentially APL. I think the point is that J is functionally equivalent with many other languages, only differing in syntax but not in paradigm.
    - karmakaze 5y ago
      I would say that you have to think in a different style so would classify as a different paradigm and not just syntax.
      - blacktriangle 5y ago
        Going back to the original comment, the statement was that any experienced engineer could learn a language in a day. At risk of gatekeeping, I'd argue that by definition any experienced engineer would have some experience with an array based language like APL or MATLAB so that no, J does not qualify as a different paradigm.
        goatlover 5y ago
        I guess it depends on how much past experience they had with an array-based, stack-based, logic-based, pure functional or lisp family language, and how long ago that was. I can believe an experienced engineer can learn the basics of any language in a day. But being proficient and idiomatic is another matter.
        gcanyon 5y ago
        The implication of the original comment was that any C-style language engineer could learn any C-style language in a day. I'd even argue that point, but it definitely doesn't get you J in a day, except that an supports most C-style syntax. So you can program in J like a C-programmer in a day. You definitely can't program like a J-programmer. And to say a competent engineer would already have array-language experience sidesteps the point.
        IncRnd 5y ago
        The original comment said nothing about C-style languages. That must be something you read into their comment. Learning J is like learning Perl or regular expressions. Nobody really wants to engage in such an activity, but people do what they need to do. Depending on their level of experience, a person who understands imperative and declarative paradigms along with the language's execution model can absolutely learn J within a day, because it only differs in syntax from the existing languages.
  - karmakaze 5y ago
    But even this is an example of finding 'a' (not 'the') right set of primitives as APL is from 1966.
  - derefr 5y ago
    Definition by function/combinator composition isn’t weird to a modern programmer (Haskell does a lot weirder); and vector processing isn’t really weird either — even Java programmers are familiar with chaining transformations and reductions on Streams these days. Instead, not knowing J, the only† thing that’s weird about that J expression to me, is that both +/ and # are receiving the same implicit vector argument, without any Forth-like “dup” operator needing to precede them. Are these operators defined to take an implicit single receiver vector? (Maybe whichever one’s on top of a “vector result stack” separate from a “scalar result stack”? Maybe the first one passed to the implicit lambda expression this code would be wrapped in?) Or is syntax sugar here hiding the argument, the way Smalltalk hides the receiver in successive expressions chained using ; ? What would a compact-as-possible J expression look like, to sum up the contents of one vector, and then divide the result by the cardinality of a different vector? ————— † Well, there is one other, more technical thing that’s “weird” about the expression above: it’s the fact that, unless +/ is a identifier separate from +, then the lexeme-sequence + / has to either derive its AST by lookahead, or by + being a stack literal and / an HOF. But then % is, seemingly, a binary infix operator. You don’t usually find both of those syntax features in the same grammar, both operating on arbitrary identifier-class lexemes, as it would usually cause an LALR parser for the language to have shift-reduce ambiguity. Unless, I suppose, the lexeme / isn’t lexed as “an identifier” terminal, but rather its own terminal class—and one that’s illegal anywhere but postfix of an identifier.
    - gcanyon 5y ago
      Frankly, I suck at J. I've solved a few dozen project Euler problems with it, but that's about it. If you want to see how deep the weeds get, check out this essay on solving the n-queens problem: https://code.jsoftware.com/wiki/Essays/N_Queens_Problem https://code.jsoftware.com/wiki/Essays/N_Queens_Problem J programmers just think differently.
    - gcanyon 5y ago
      + is a "verb" / is an "adverb" -- it modifies the functionality of whatever verb it is applied to. Almost all verbs can be binary or unary, sometimes with surprising (to me, a newbie) consequences. I have no idea how it gets handled underneath the hood.
- raxxorrax 5y ago
  But you don't know common compiler/interpreter pitfalls, tooling, frameworks... so in the end you still need a long time to get familiar with it for productive work. Sure, you know the vocabulary, but it will still take time to learn the rest.
mark_l_watson 5y ago
Nice read. Personally, I am not as unhappy with the state of tooling. With LSP, many programming languages are getting better VSCode, Emacs, Vi, etc. support. XCode is actually nice to use, on a fast M1 Mac. I think wide adoption of deep learning is the biggest breakthrough in recent years. EDIT: I have used Lisp heavily for 40 years, and I have done a few Smalltalk projects.
gcanyon 5y ago
I think Kay's complaint about engineering rigor ignores the explosive growth of programming. Sure, bridge-builders have rigor; there's also probably about the same number of them today as there were 50 years ago. The number of programmers has grown by at least two, maybe three orders of magnitude over the last half century. And more importantly, almost anyone can do it. A kid whose closest approach to structural engineering is building a balsa bridge for a weight competition can also write and release an app for Android or iOS that will be seen by millions. Even if it's not a success, it's still just as real a program as MS Office. That level of access guarantees amateur-level code, and the rigor Kay is suggesting would kill the software industry as we know it.
- DubiousPusher 5y ago
  Yeah and I'll tell you, as someone wbo gets to look at a lot of those CAD models that are suposedly introducing rigor, they're often in exactly the same kind of condition as internal codebases.
- Joker_vD 5y ago
  Well, rigor and quality in building industry are location dependent. I've read a blog of a builder who describes how architects regularly produce dangerous (too thin or just simply missing load-bearing beams) or straight up impossible (gable of negative size, yep) designs. The solution is that the builders just build whatever makes sense and sometimes the contractors simply don't notice.
  - Fantosism 5y ago
    I'm ignorant in this domain, but wouldn't it be up to the structural engineer to make sure the plans are sound? I always thought that architects dream it up and engineers are responsible for the physics.
- Jtsummers 5y ago
  > That level of access guarantees amateur-level code, and the rigor Kay is suggesting would kill the software industry as we know it. I don't believe this follows. The level of rigor he's lamenting could be constrained to certain categories of software, based on their impact or information content. Amateur or informally specified systems can still satisfy everything else. There is no reason for most systems that don't touch PII or critical systems or other similar categories of software to have serious engineering behind them if people don't want them to.
echelon 5y ago
Kay is looking at a microscopic part of a vast and evolving ecosystem. Take a look at deep learning, Kay. (In a sense, building models is a new type of programming, solving problems that are difficult to describe.) Or maybe something a little closer to home, like Rust. It vastly improves the state of the world at the boundaries of the software layer.
gcanyon 5y ago
I think to understand the "next" level of programming it's important to broaden our definition. "Programming" should be more like "defining a system to turn a specific input from a defined input set into a corresponding action or output." That's too broad, because it includes the formula =A1*2 in Excel. But at some greater level of complexity, an Excel spreadsheet transforms from "a couple formulas" to "a structured tool designed to keep track of our orders and invoices" -- in other words, a program. On that basis, the recent advances include spreadsheets, database tools, and JavaScript along with other scripting languages.
karmakaze 5y ago
There isn't so much in languages features themselves, but in their implementations. GC can be largely pauseless for many practical purposes and a GC language can be within 2x-3x the performance of C-like languages. Also the amount/cost of memory has improved so that we can use immutable datastructures and functional style in many contexts, which definitely feels like a 'level-up'. Concurrency has been getting easier too, with many languages supporting coroutines/async and/or threads. Reference capabilities are exciting as in Pony, Rust, or Clean. In general there's a great convergence where ergonomics are improving (editors, compilers, build/package systems) and each language evolves to adopt features of other languages. I just dabbled into the Sorbet type checker after not writing any C++ since the 90s, and it was surprisingly browseable/readable and could copy/paste the concepts based on recent Ruby, Java/Go knowledge.
- scythe 5y ago
  >GC can be largely pauseless for many practical purposes and a GC language can be within 2x-3x the performance of C-like languages. To that end, it seems like only recently we've seen automatic reference counting [Obj-C, Rust, Swift] and/or compile-time garbage collection [Mercury] in a non-toy implementation. "Breakthrough" is a difficult word because it refers to discovery and impact, with the latter coming long after the former, and it's not clear if ARC is really a game-changer for any serious applications, but it seems interesting at least.
  - steveklabnik 5y ago
    (Rust does not do automatic reference counting)
    - dcow 5y ago
      Sure it does: `Arc::new(thing)`
      - steveklabnik 5y ago
        That is atomic reference counting, not automatic reference counting. With automatic reference counting, you do not need to wrap the variables, and you do not need to increment or decrement the counter. Rust requires that you actively make your values reference counted by wrapping them explicitly, and makes you bump the count explicitly. It uses RAII to decrement the count automatically though.
mikewarot 5y ago
Metamine represents the latest breakthrough in programming, it offers a mix of tradition declarative programming and reactive programming. The "magical equals" for lack of a better term, lets you do "reactive evaluation", the opposite of lazy evaluation. If any of the terms that a term depend on change, the result is updated, and all it's dependencies, etc. You can use the system clock as a term, thus have a chain of things that update once a second, etc. Being able to use both reactive and normal programming together without breaking your brain is a whole new level of power. It's brilliant stuff, and it seems to have been yoinked from the internet. 8( Here's a previous thread about it: https://news.ycombinator.com/item?id=27555940 https://news.ycombinator.com/item?id=27555940
- pharmakom 5y ago
  Can’t this be expressed as a library in Haskell or even F# though?
  - AnimalMuppet 5y ago
    That style sounds like it's mutating variables when other variables change (that is, mutate). That doesn't sound like a good fit for Haskell...
    - kian 5y ago
      Haskell is great at mutating variables. Reactive programming was even pioneered in it. It's just that the Monads that allow you to do this are somewhat like sticky tar - everything they touch becomes a part of them. The traditional structure of Haskell programs is to build a pure functional 'core', and layer around that the 'sticky' parts of the code that need to interact with the outside world.
      - AnimalMuppet 5y ago
        OK, but the "reactive" programming sounds like how you build the core. So I still question whether that style fits well with Haskell.
api 5y ago
I wouldn't call it a breakthrough as the ideas are not new, but I consider Rust to be a major practical advancement that brings ideas into the mainstream that were formerly just for "academic" languages. It's the first IMO viable alternative to C and C++ for systems programming ever, and its safety features represent a successful transfer of provable-safety ideas of academia into a practical language that people actually want to use for real stuff. As for true breakthroughs I'd say the last big one was modern deep learning.
platz 5y ago
So if Pizza Hut wants a checkout cart they need to rent a supercomputer to plan the implementation?
- mlosgoodat 5y ago
  He was speaking as if it was still 1980s. Now we have cloud based ML doing the optimization finding. ML will (eventually) be able to generate biz logic code, and most assuredly infrastructure config (a cloud API has a limited set of possible configs of value to our sorting patterns), UI code (we gravitate towards a limited set of UX it seems), to solve much of our daily programming work. ML can’t invent future ideas, it can’t evolve itself without us making new hardware for it. But it will implode the blue collar dev job market eventually.
  - platz 5y ago
    how many years is eventually
    - ausbah 5y ago
      5-10 years, every year
  - Zababa 5y ago
    > ML can’t invent future ideas, it can’t evolve itself without us making new hardware for it. But it will implode the blue collar dev job market eventually. I have doubts about that. Open source code seem to achieve a large part of the same function as ML (implement "boring" code for the Xth time) but it only has increased the number of blue collar devs. On the other hand, some no-code tools are opening programming to a large number of people (Excel, actions with your iPhone, things like that). Programming is one of those things that everyone would benefit from knowing, but time is limited, so anything to lower the barrier of entry will just lead to more programming. And more programming means even more programming (someone has to develop the no-code tools, the cloud infrastructure, etc).
    - 5y ago
jimbokun 5y ago
I think the biggest programming productivity boosts since 1984 haven't been about programming languages, but about tools. Specifically, distributed version control and dependency management tools. Being able to collaborate with developers anywhere in the world, and being able to pull in any library with a single declarative line in a configuration file, increases productivity more than any improvement to a programming language ever could.
- ComodoHacker 5y ago
  >Specifically, distributed version control and dependency management tools. Indeed, without these tools dependency hell wouldn't be possible! /s
  - kenjackson 5y ago
    Oh, we still had it!
    - hnfong 5y ago
      Evidence - This started happening in the 1990s (latest) before tools like git and npm was a thing: https://en.wikipedia.org/wiki/DLL_Hell https://en.wikipedia.org/wiki/DLL_Hell
- chasd00 5y ago
  I agree, could you imagine doing something like Java Spring without maven or the equivalent? It wouldn't be possible.
pharmakom 5y ago
IMO probably monads. Next might be Unison lang or dependent types.
- hollerith 5y ago
  >>What was the last breakthrough . . . ? >IMO probably monads. So, you believe there have probably been no breakthroughs since 1990?
  - pharmakom 5y ago
    Well it depends how you define breakthrough doesn’t it. There have absolutely been advances.
wmanley 5y ago
I feel like Kay has taken a rather too narrow view of what counts as programming. IMO here are the breakthroughs in the last 20 (ish) years: 1. Stack Overflow - search for your problem, copy and paste the answer. 2. git - Revision control that is low enough overhead that you need to have a reason not to use it. 3. Open-source software as a commodity - Unless you've got very specific requirements there's probably a system that can do most of your heavy lifting. (Almost) no-one writes their own JSON parsers or databases or web frameworks. Using open-source software is low overhead and low risk compared to engaging with some vendor for the same. 4. Package managers - By making it easy to include other peoples code we lower the bar to doing so. The common thread here is code-reuse. None of the above are programming languages, but all have driven productivity in building systems and solving problems.
- AnimalMuppet 5y ago
  I would add: Better, more complete libraries shipping standard with languages.
- orthoxerox 5y ago
  Code reuse was the holy grail of the 90's. People expected classes to be the unit of code reuse, then enterprise services, then after a dozen years of disillusionment we finally got the recipe right.
  - still_grokking 5y ago
    We finally got the recipe right? How? With micro-services? Or Kubernets clusters? Or copy-paste from SO? Or is it more about Linux packages? Maybe NPM? I'm really not sure we've got this right by now. Actually everything is over and over rewritten. May it be because of the language used, may it be because of frameworks, or architectures. Polyglot runtimes that could enable true code reuse at least across language boundaries (like GraalVM) are just emerging. For the higher build blocks though there's still nothing to enable efficient reuse. (People try of course. So mentioning micro-services was no joke actually).
- kenjackson 5y ago
N1H1L 5y ago
LLVM could very well be thought of as major breakthrough. The intermediate representation format has enabled so many compiler and languages now, that it's pretty insane in my opinion.
abetusk 5y ago
It always feels like Alan Kay is wistfully talking about how there could have been an alternate future where he and his ilk would do programming and computer engineering the "right way" and somehow the world has lost it's path. He waxes eloquent about how he enabled the genius's at Xerox PARC to do deep work and how they changed the world. I find his talks inspiring but I also find it tone deaf that he doesn't understand the situation he was in nor does he see how the world has changed. Xerox PARC was, in my opinion, a by product of top down "waterfall" like business practices that he happened to be at the apex of. For most of the rest of us, we have to get by with minimal funding and try to push ideas to an over saturated market. What really irks me is how he still has this view that somehow if all the worlds intellectuals just got together or just got funding, somehow they would come up with the next genius ideas and could deliver it to the rest of the world, like god's messengers. Here's what he missed: * Free and Open source. It's not software that's eating the world, it's free and open source software that's eating the world. Most of the worlds infrastructure runs on FOSS and we'd be living in a developer hellscape of choosing between which Apple and Microsoft crippling licensing fees we'd need to pay just to have the privilege of compiling our programs. * Git. Git has allowed project management and software sharing with ease like nothing before. Even though GitHub is a proprietary enterprise, it's created massive value to the community through it's ease of sharing. * Javascript. Write once run anywhere? Javascript is the only language that comes even close. Data representation that's portable? JSON is the only one that comes close. Javascript has it's warts but it brings the best of functional languages in a procedural languages skin. Javascript is the only reason I don't dismiss functional languages off hand, because Javascript actually makes those concepts useful. * Docker (and perhaps some WebAssembly/Javascript environment). I think we're closing in the idea that Linux boxes are the analogues of "cells", where each has their own local environment and can be composed to form larger structures. Linux images may seem bloated now but when space and compute passes a threshold of cheap/fast, it won't matter. * GPUs. Moores law is alive and well with GPUs. "Out of the box" gets you a 10x-100x speedup on algorithms ported from CPUs. I've heard of 1000x-10000x in some cases. It's not just raw performance, it's also designing data structures that work on GPUs, are more data centric and are designed for small, independent and highly parallel workloads. And I'm sure there are many more. I would add cryptocurrency but maybe that falls outside of the "programming" scope. For all his preaching, Alan Kay still doesn't "get it". If there's a billion dollar monopoly that has a small, independent research group that has no ceiling to funding and has Alan Kay as it's head, great, I'm sure they'll come up with some wonderful ideas. We don't live in that world anymore and the playing field has been leveled because of the points above and many more (maybe even more simply just because cheaper compute is available). It never really occurs to Alan Kay that maybe his type of research is not the only way. Better yet, maybe Alan Kay's style of research is gone because we've discovered better ways. If Alan Kay really wants to see the worlds next ideas birthed into existence, why isn't he at the forefront of free and open source, championing the software that enables people to his type of fundamental research? If you really want a trillion dollar ROI, invest a few million in FOSS.
Fire-Dragon-DoL 5y ago
Isn't Rust's compile time memory and concurrency safety a decent breakthrough?
- DetroitThrow 5y ago
  I'm not sure that was a breakthrough made by Rust, but I think people agree that Rust was the first language that provided those things that people actually have wanted to use outside academia and narrow industry groups.
  - scns 5y ago
    30-40 years after being invented.
agent327 5y ago
Since I left university (eighties) I have only been positively impressed by two languages. One was the Wolfram language. I haven't used it; I'm just going on the demo here, but the idea of having not just a powerful language, but also a massive database with useful information to draw from, seems to elevate it above the usual sad collection of new ways to spell variable declarations and loops. The other is Inform. I haven't used that either, and of course it is highly domain-specific, but within that domain it seems a pretty damn cool way to write text adventures. All of the graphical programming systems seem to fail the moment they scale up above what roughly fits on one screen. Labview is a disaster once it is more than just a few boxes and lines. And everything else is, as far as I can tell, just the same bits and pieces we already had, arranged slightly differently. We were promised hyper-advanced fifth-generation programming languages, but the only thing that seems to come close is Wolfram, and that's hardly mainstream. I'm occasionally wondering if the whole field might not improve mightily if we stopped focusing so much on languages, and instead focused on providing powerful, easy to use, elegant, well-documented APIs for common (and less common) problems. Using something like OpenSSL, or OpenGL, or even just POSIX sockets, is just an exercise in (largely unnecessary) pain.
- feoren 5y ago
  It sounds like you and Alan Kay are both expecting novel problems to be solved by new programming languages. That is an extremely inefficient way to do it: you need to come up with new compilers, documentation, standard libraries, communities, etc. Instead, programming languages have become general enough that most new problems are being solved within existing languages, instead of by inventing new ones. I have no idea what a "hyper-advanced fifth-generation programming language" is even supposed to look like. > I'm occasionally wondering if the whole field might not improve mightily if we stopped focusing so much on languages, and instead focused on providing powerful, easy to use, elegant, well-documented APIs for common (and less common) problems. But a programming language is nothing but a well-documented API! How would your suggested solution even differ from a programming language?
  - agent327 5y ago
    That's not quite it. Let me explain... The first computer language I used was BASIC. It was excellent for what it was, but clearly it had a limit on how much you could do with it, on account of it missing amenities like named functions, variable scopes, etc. A 'function' was simply a line further down the program that you branched to using GOSUB. And there was only one scope, which was fine since the space available for actually writing programs was a microscopic 23KB anyway. It had for-loops, but GOTO was still very much present as a tool to control program flow. Moving on from there, I learned Pascal, which was clearly a major step up in terms of what you could achieve. Using the primitives available in Pascal (structured programming, named functions, scopes, etc.), it is possible to write larger programs than you can in BASIC: the higher level of abstraction makes it easier to reason about larger programs. From there C++ was another step up: the ability to define objects and encapsulate a great deal of implementation detail is another weapon in your toolbox to combat chaos, thus allowing you to write ever more complex programs without losing control over what they are doing. And then... there was nothing. There appears to be no step beyond object-orientation that lets you create even larger programs with even less effort. There may be languages that are syntactically easier than C++ (although after using it for a quarter century it no longer bothers me), but they just hide minor implementation details, at the cost of lower performance. That's not greater abstraction, it's just greater convenience. What we were all hoping for was that next step: languages that provided an even higher level of abstraction, allowing you to create even larger programs without losing the ability to reasoned about them. This was what 5GL promised, but which we didn't get because nobody could figure out what they would look like. Apparently we have reached a maximum level of abstraction that we can express with source. So the progression of computer languages looks somewhat like this: 1GL (plain assembly), 2GL (unstructured languages like BASIC), 3GL (structured languages like Pascal), 4GL (object-oriented languages), 5GL (not, as of yet, invented). Each level represents a clear step up in terms of abstraction, and after four steps we seem to have run out of steam, and are now mostly busy reinventing things we already had with slightly different syntax. To me, at least, that's a disappointment. My disappointment with available APIs is perhaps simply because I program a lot in C++, which inevitably means having to deal with an anemic standard library (there's not even a standardized socket interface in there), and a wild array of C-libraries. Some of these are very good, with an elegant interface design and excellent documentation, but many are just painfully bad, with virtually no documentation, and apparently every effort made to confuse the hell of out their potential users. Really, some of this could be so, so much better...
rurban 5y ago
SAT solvers applied. You can now solve unsolvable problems, like practical formal verification in big C/C++ codebases. There's no need anymore to write test cases, as formal verification tries all possible input values, not just a few selected. It also checks all possible error cases, not just the ones you thought about.
- AnimalMuppet 5y ago
  Could you expand on what you mean by this? Because it sounds like a level of hype bordering on nonsense. 1. How is a SAT solver going to do formal verification? How do you turn a formal verification into a SAT problem? 2. You can only formally verify what your formal verifier can handle, which is usually somewhat less than "everything". Can your SAT-driven formal verifier verify that the worst case response time of the system is less than X? 3. Formal verification tends to be slow. If I can write and run unit tests orders of magnitude faster than the formal verifier, then the formal verifier is going to not be used much.
  - rurban 5y ago
    Lookup what CBMC does. SAT solvers will also be also be applied in traditional compilers soon. The remaining problem with formal verification and compilation is proof of termination, which is not a SAT problem. Running all test cases via cbcm is magnitudes faster than writing 100% coverage (only line cov, not covered values) tests. It's like one day vs one month. And I've never seen code with full value test coverage. For guaranteed timing you need special tests, not a SAT solvers. The solver just helps with the proofs.
    - AnimalMuppet 5y ago
      Even if everything you say is true, it's true the first time. Then I make a change to the code. Now if I have unit tests, I have to fix a test (maybe minutes, maybe an hour) and re-run the tests (minutes). Or I have to re-run the formal verification (a day).
      - 5y ago
svachalek 5y ago
Early programming language advancements were about abstracting away the basic repetitive stuff (function call stack manipulation) and the hardware details (register selection, memory addresses). They did it in a way that was minimally "leaky"; debugging a C program you may be aware of the call stack and registers, but most of the time you'll be just fine working at the abstraction level of function parameters and local variables. Since then we've added tons more boilerplate and hardware to the standard application deployment, it runs over multiple servers and clients using various network protocols, interacts with databases and file systems, etc. But modern solutions to these are mostly code generation and other leaky layers, it's likely you can't debug a typical problem without reading or stepping through generated code or libraries. What I'd like to see in a new programming language is some abstraction of an application that has persistent data and is distributed, with the details being more or less compiler flags. And comes with debugging tools that allow the programmer to stay at that level of abstraction. But most new language announcements come down to some new form of syntactic sugar or data typing.
DesiLurker 5y ago
I'd say being able to program GPUs as general purpose compute devices & general SIMD vectorization in high level language is pretty significant. it has opened up many applications like machine learning previously unavailable. IMO some C++20 features like coroutines rank pretty high in introducing new ways of programming.
- ColinWright 5y ago
  I have a question about that, and despite asking in several places, and reading lots of documents, I've ever been able to find an answer that makes sense. Maybe you can help me. I have an algorithm that I used to run on a SIMD machine. It's a single, simple algorithm that I want to run on lots of different inputs. How can I run this on a GPU? From what I read about GPUs it should be possible, but nothing I've read has made any sense about how to do it. Can you point me in a suitable direction? My contact details are in my profile if you'd like to email to ask for more information. Thanks.
  - emllnd 5y ago
    Hi Colin. A few ways to go about it, requires getting some initial tedium done to get started. I would recommend the course https://ppc.cs.aalto.fi/ https://ppc.cs.aalto.fi/ as a resource, goes through specifics of implementing an example data-crunching program using both a vectorized/SIMD CPU approach (ch1-2) and a GPU approach (ch4, using Nvidia Cuda specifically). Another approach would be to upload data to GPU in dx/vulkan/metal/opengl buffers or textures and run shaders on them, plenty of resouces out there but I understand it’s tricky to find a suitable one. Happy to discuss more
  - DesiLurker 5y ago
    I think you'd be better served by using something like OpenCL. especially if it was already running on simd core then it should be relatively straightforward to port to openCL. the mental model to follow would be to think of a gpu as a collection of identical simd machines that are programmed in simplified version of C. thinking further, if you have never programmed gpgpu processors you may be better off porting your code using NVIDIA CUDA (assuming you are targeting desktop graphics). it had better tools and overall a better ecosystem.
lordnacho 5y ago
My problem with this is it sort of implicitly assumes that languages are the unit of progress. It's unlikely that we will get progress solely by coming up with better languages, it's more like different people invent different tools to suit different problems. In the explosion, we are more likely to find what we need. I don't think I've ever used just one language for a project. The progress at least personally is that there are now so many resources to use a bunch of different languages to knit together a solution that a lot more can get done. You can write your low latency code in a variety of languages, and ship the data via a web server to a browser or a mobile app. For every part you have several choices of tech to use, and they're realistic choices with lots of help online. Almost everything is available for free, so you can try all sorts of libs without committing to one. There's no longer a need to sit down with a textbook and learn a bunch of stuff before starting, you can just jump in with a brief tutorial and explore the language or lib as you discover them. The plethora of choices also teaches you a lot about languages in general, because you see so many that you can start to make generalizations.
RivieraKid 5y ago
Maybe calling these "breakthroughs" is a stretch, but anyway... Swift. I think that this is the best general purpose language ever created. By "best" I mean that it has the highest productivity (which is determined by readability, static safety, expressiveness, etc.) after normalizing for factors outside of the language spec, e.g. tooling, libraries, compilation and runtime speed. React and Svelte. The first breakthrough was React, the second generation is Svelte and similar frameworks. Async / await. This is a major improvement to the readibility and mental model simplicity of the most common type of concurrency code.
analog31 5y ago
I would consider microcontrollers and programmable logic. They outnumber "real" computers and completely reshaped electronics.
beckman466 5y ago
holochains
tibbydudeza 5y ago
Everything just seems to be a rehash or improvement on C++. I just want better tools i.e low code that non-programming people can use to express what they want a computer to do - something better than Excel.
dd444fgdfg 5y ago
I don't think languages will really "progress" much, in the way that art doesn't progress. That's not to say it wont evolve to suite it's environment.
- still_grokking 5y ago
  Large parts of computer science are about languages. There is a lot of progress. (Research needs to be novel usually). Only that that progress arrives at mainstream usually 20+ years later, in very small batches. So it's not very visible when looking only on the practically relevant things.
  - scns 5y ago
    Very much this. The idea for the borrow checker is from the 80s IIRC. Slowly approaching mainstream with Rust.
AtlasBarfed 5y ago
SSDs Breakthroughs imply practical considerations, and SSDs were the last major improvement to hardware that also required software changes.
Too 5y ago
The biggest shift lately is probably on the ops side. The role sysadmin or DBA hardly exists anymore as full-time jobs. With the goals of containerization and avoiding snowflaking giving lots of positive spill-over effects for the developer side as well. Today i can snapshot the volume of my containers, completely format my computer, download and reinstall Ubuntu from scratch. Download and install any IDE and all tools i need, clone a project from github, npm install thousands of dependencies, spin up a docker-compose network with a distributed nosql database and a a few services, commit and push a MR giving relevant test results back from github CI and someone reviewing the code - All in one day. 10-15 years ago (without even considering the difference in download-time) every step here would be at least a day each, involving complicated configurations and often causing non revertible modifications to the host system. Containerization and sandboxing can also be seen as being big enablers for the mobile app stores and untrusted browser applications being able to deploy to clients instantly. I'd also say UI frameworks are a big deal. Both Windows, Android, iOS and the Web have much more powerful tools than say Win32 or whatever old baseline one wants to compare with. Especially declarative web front end frameworks like React and Vue. Some might call these fad-frameworks, but i for sure can write better web-apps with less than half the number of lines, and with much less spaghetti, compared to what we used to do in 2005 (just close one eye for the webpack complexity), if that's not a paradigm shift i don't know what is. Unfortunately this hasn't always resulted in much better applications for end users when looking at the average app, probably due to lower barrier of entry and race to the bottom. Programming languages, IDEs and tooling overall are miles better than before, even if it's hard to pin any specific milestone to where the shift happened, all small gains add up to a big deal on all fronts. C++ is still C++ and Java is still Java but even there a lot of the verbose boilerplate is reduced giving much better ergonomics. Then you've got things like Kotlin, Typescript and other hybrid-dynamic/static + hybrid-OO/functional languages getting improved and more widespread, Async everywhere, Rust bringing something on the table to finally replace C/C++, package managers used by everyone really enabling code-reuse. You now also got almost all popular languages converging and being equally capable doing everything, not one language per use-case. Then there are tons of other cools things like GPGPU, machine learning, big data, EBPF, crypto and security. It's just too much to grasp.
8eye 5y ago
wasm
blippage 5y ago
I think that programming is the most confused discipline there is. I've mentioned this in previous posts. In any other field there is usually an established body of knowledge, either in science of professions like accountancy. In programming we're still arguing about whether the debits should go on the left and credits on the right, or vice versa. By that I mean, facetiously, we're still arguing about what programming language to use. Most new sciences - e.g. electronics - gather a mature body of knowledge relatively quickly. We know exactly how transistors work and how to use them, for example. Nobody argues about how to calculate the current flowing through a wire. This, to some extent, happened in programming, especially early, but the matter still seems far from settled. Some poster on here once noted that there are no new paradigms in programming. Their argument is that not functional, OO, or other invention, as good as they are, constitute a paradigm shift. A paradigm shift is so fundamental that it uproots our whole conceptions about how the universe works; like the shift away from using epicycles to describe the motion of planets to using a theory of gravitation. I've been tinkering around with microcontrollers lately, and it has given me a perspective that I suspect many don't have. I like C++, and I think it's suitable for high-level programming, due to things like deterministic garbage collection and niceties like strings and vectors. But I've come to the conclusion that C++ is marginal, at best, on microcontrollers. Things tend to be far more static, so these niceties do not bulk large. But C++ also needs extra fiddle if you start from scratch. Things like exceptions need effort to implement. C is low-level. You get to build things block by block. If your microcontroller supports some nifty hardware acceleration feature, then you can use that. And that's the thing. A high-level language is an abstraction. It can't decide what should happen at a very low level. So you have a convenience, but you also take a hit. So perhaps looking for a better language is a chimera, because how you do something is dependent on what it is you're trying to do. It also means that C is never likely to go away as a language, and that C++ was a clever idea in that it built on C.
- hnfong 5y ago
  > Most new sciences - e.g. electronics - gather a mature body of knowledge relatively quickly. We know exactly how transistors work and how to use them, for example. Nobody argues about how to calculate the current flowing through a wire. Ever since we made computers fast enough to implement basic things in the 1980/1990s, the debate has never been a "scientific" one. It's all about programmer preference and psychology. Equations about electricity is relatively simple. Yet we don't have equations about programmer brains. The only way we can "scientifically" experiment with programming languages is to invent new languages/features and see how programmers react. Do they make fewer mistakes? Do they see increased productivity? Do they "like" it or even swear by it? To a very large extent (more-so than most would imagine), trying to pin down "programming best practices" is like trying to set a standard for writing novels. You have common tropes and literary devices (aka "design patterns"), but the expressiveness of languages (both human and computer) makes it hard to make final, scientific conclusions. The electricity on a wire thing is really much more simpler.
jakeogh 5y ago
comptime fixed macros in a practical implementation: https://andrewkelley.me/post/zig-programming-language-blurs-line-compile-time-run-time.html https://andrewkelley.me/post/zig-programming-language-blurs-...

132 points by ColinWright 5y ago

This is at least part of the reason that reasonably strong engineers can learn a new programming language in under a day. The paradigms just aren’t that different. I realize there’s a cottage industry of folks creating new languages all the time. But when you read the docs they all bucket into a few categories, and the differences are syntax, tooling and how system services are accessed. All that being said, these three categories do matter. Programming using tools like autocompletion, syntax highlighting and the like does speed productivity. But, like human language, at some point the “right” set of primitives are discovered. From that point on changes become more about culture and fads than concepts.

gcanyon 5y ago
Try learning J in a day. It...won't go well -- but in a good way. :-) As you say, for many languages the paradigm is some variation of C, and the concepts are largely interchangeable. Then you approach something like J, where (trivial example) +/%# returns the average of a list by composing three functions: + sums; % divides; # counts; with a modifier / that distributes + throughout the list; and you begin to realize you're not in Kansas anymore. https://en.wikipedia.org/wiki/J_(programming_language) https://en.wikipedia.org/wiki/J_(programming_language) I don't think the "right" set of primitives is as obvious as you say. Obviously branching and loops are foundational to many languages, but even those are optional given the right design, and they can be implemented in very different ways.
- raxxorrax 5y ago
  ÅF - Fibonacci in 05AB1E that are less than the current number on the stack - Good tip for when you get THAT code interview and can pick the language. Just need to know the code for Å if you are not from Denmark.
- dahfizz 5y ago
  That's just a syntax over map() and reduce(). There are no new / different primitives in J, just a new syntax that emphasizes the use of arrays.
  - gcanyon 5y ago
    It's a bit ironic that we're essentially having a blub language debate on ycombinator's web site. I'll defer to Paul Graham's response: http://www.paulgraham.com/avg.html http://www.paulgraham.com/avg.html
- IncRnd 5y ago
  J is essentially APL. I think the point is that J is functionally equivalent with many other languages, only differing in syntax but not in paradigm.
  - karmakaze 5y ago
    I would say that you have to think in a different style so would classify as a different paradigm and not just syntax.
    - blacktriangle 5y ago
      Going back to the original comment, the statement was that any experienced engineer could learn a language in a day. At risk of gatekeeping, I'd argue that by definition any experienced engineer would have some experience with an array based language like APL or MATLAB so that no, J does not qualify as a different paradigm.
      - goatlover 5y ago
        I guess it depends on how much past experience they had with an array-based, stack-based, logic-based, pure functional or lisp family language, and how long ago that was. I can believe an experienced engineer can learn the basics of any language in a day. But being proficient and idiomatic is another matter.
      - gcanyon 5y ago
        The implication of the original comment was that any C-style language engineer could learn any C-style language in a day. I'd even argue that point, but it definitely doesn't get you J in a day, except that an supports most C-style syntax. So you can program in J like a C-programmer in a day. You definitely can't program like a J-programmer. And to say a competent engineer would already have array-language experience sidesteps the point.
        IncRnd 5y ago
        The original comment said nothing about C-style languages. That must be something you read into their comment. Learning J is like learning Perl or regular expressions. Nobody really wants to engage in such an activity, but people do what they need to do. Depending on their level of experience, a person who understands imperative and declarative paradigms along with the language's execution model can absolutely learn J within a day, because it only differs in syntax from the existing languages.
- karmakaze 5y ago
  But even this is an example of finding 'a' (not 'the') right set of primitives as APL is from 1966.
- derefr 5y ago
  Definition by function/combinator composition isn’t weird to a modern programmer (Haskell does a lot weirder); and vector processing isn’t really weird either — even Java programmers are familiar with chaining transformations and reductions on Streams these days. Instead, not knowing J, the only† thing that’s weird about that J expression to me, is that both +/ and # are receiving the same implicit vector argument, without any Forth-like “dup” operator needing to precede them. Are these operators defined to take an implicit single receiver vector? (Maybe whichever one’s on top of a “vector result stack” separate from a “scalar result stack”? Maybe the first one passed to the implicit lambda expression this code would be wrapped in?) Or is syntax sugar here hiding the argument, the way Smalltalk hides the receiver in successive expressions chained using ; ? What would a compact-as-possible J expression look like, to sum up the contents of one vector, and then divide the result by the cardinality of a different vector? ————— † Well, there is one other, more technical thing that’s “weird” about the expression above: it’s the fact that, unless +/ is a identifier separate from +, then the lexeme-sequence + / has to either derive its AST by lookahead, or by + being a stack literal and / an HOF. But then % is, seemingly, a binary infix operator. You don’t usually find both of those syntax features in the same grammar, both operating on arbitrary identifier-class lexemes, as it would usually cause an LALR parser for the language to have shift-reduce ambiguity. Unless, I suppose, the lexeme / isn’t lexed as “an identifier” terminal, but rather its own terminal class—and one that’s illegal anywhere but postfix of an identifier.
  - gcanyon 5y ago
    Frankly, I suck at J. I've solved a few dozen project Euler problems with it, but that's about it. If you want to see how deep the weeds get, check out this essay on solving the n-queens problem: https://code.jsoftware.com/wiki/Essays/N_Queens_Problem https://code.jsoftware.com/wiki/Essays/N_Queens_Problem J programmers just think differently.
  - gcanyon 5y ago
    + is a "verb" / is an "adverb" -- it modifies the functionality of whatever verb it is applied to. Almost all verbs can be binary or unary, sometimes with surprising (to me, a newbie) consequences. I have no idea how it gets handled underneath the hood.
raxxorrax 5y ago
But you don't know common compiler/interpreter pitfalls, tooling, frameworks... so in the end you still need a long time to get familiar with it for productive work. Sure, you know the vocabulary, but it will still take time to learn the rest.

mark_l_watson 5y ago

Nice read. Personally, I am not as unhappy with the state of tooling. With LSP, many programming languages are getting better VSCode, Emacs, Vi, etc. support. XCode is actually nice to use, on a fast M1 Mac. I think wide adoption of deep learning is the biggest breakthrough in recent years. EDIT: I have used Lisp heavily for 40 years, and I have done a few Smalltalk projects.

gcanyon 5y ago

I think Kay's complaint about engineering rigor ignores the explosive growth of programming. Sure, bridge-builders have rigor; there's also probably about the same number of them today as there were 50 years ago. The number of programmers has grown by at least two, maybe three orders of magnitude over the last half century. And more importantly, almost anyone can do it. A kid whose closest approach to structural engineering is building a balsa bridge for a weight competition can also write and release an app for Android or iOS that will be seen by millions. Even if it's not a success, it's still just as real a program as MS Office. That level of access guarantees amateur-level code, and the rigor Kay is suggesting would kill the software industry as we know it.

DubiousPusher 5y ago
Yeah and I'll tell you, as someone wbo gets to look at a lot of those CAD models that are suposedly introducing rigor, they're often in exactly the same kind of condition as internal codebases.
Joker_vD 5y ago
Well, rigor and quality in building industry are location dependent. I've read a blog of a builder who describes how architects regularly produce dangerous (too thin or just simply missing load-bearing beams) or straight up impossible (gable of negative size, yep) designs. The solution is that the builders just build whatever makes sense and sometimes the contractors simply don't notice.
- Fantosism 5y ago
  I'm ignorant in this domain, but wouldn't it be up to the structural engineer to make sure the plans are sound? I always thought that architects dream it up and engineers are responsible for the physics.
Jtsummers 5y ago
> That level of access guarantees amateur-level code, and the rigor Kay is suggesting would kill the software industry as we know it. I don't believe this follows. The level of rigor he's lamenting could be constrained to certain categories of software, based on their impact or information content. Amateur or informally specified systems can still satisfy everything else. There is no reason for most systems that don't touch PII or critical systems or other similar categories of software to have serious engineering behind them if people don't want them to.

echelon 5y ago

Kay is looking at a microscopic part of a vast and evolving ecosystem. Take a look at deep learning, Kay. (In a sense, building models is a new type of programming, solving problems that are difficult to describe.) Or maybe something a little closer to home, like Rust. It vastly improves the state of the world at the boundaries of the software layer.

gcanyon 5y ago

I think to understand the "next" level of programming it's important to broaden our definition. "Programming" should be more like "defining a system to turn a specific input from a defined input set into a corresponding action or output." That's too broad, because it includes the formula =A1*2 in Excel. But at some greater level of complexity, an Excel spreadsheet transforms from "a couple formulas" to "a structured tool designed to keep track of our orders and invoices" -- in other words, a program. On that basis, the recent advances include spreadsheets, database tools, and JavaScript along with other scripting languages.

karmakaze 5y ago

There isn't so much in languages features themselves, but in their implementations. GC can be largely pauseless for many practical purposes and a GC language can be within 2x-3x the performance of C-like languages. Also the amount/cost of memory has improved so that we can use immutable datastructures and functional style in many contexts, which definitely feels like a 'level-up'. Concurrency has been getting easier too, with many languages supporting coroutines/async and/or threads. Reference capabilities are exciting as in Pony, Rust, or Clean. In general there's a great convergence where ergonomics are improving (editors, compilers, build/package systems) and each language evolves to adopt features of other languages. I just dabbled into the Sorbet type checker after not writing any C++ since the 90s, and it was surprisingly browseable/readable and could copy/paste the concepts based on recent Ruby, Java/Go knowledge.

scythe 5y ago
>GC can be largely pauseless for many practical purposes and a GC language can be within 2x-3x the performance of C-like languages. To that end, it seems like only recently we've seen automatic reference counting [Obj-C, Rust, Swift] and/or compile-time garbage collection [Mercury] in a non-toy implementation. "Breakthrough" is a difficult word because it refers to discovery and impact, with the latter coming long after the former, and it's not clear if ARC is really a game-changer for any serious applications, but it seems interesting at least.
- steveklabnik 5y ago
  (Rust does not do automatic reference counting)
  - dcow 5y ago
    Sure it does: `Arc::new(thing)`
    - steveklabnik 5y ago
      That is atomic reference counting, not automatic reference counting. With automatic reference counting, you do not need to wrap the variables, and you do not need to increment or decrement the counter. Rust requires that you actively make your values reference counted by wrapping them explicitly, and makes you bump the count explicitly. It uses RAII to decrement the count automatically though.

mikewarot 5y ago

Metamine represents the latest breakthrough in programming, it offers a mix of tradition declarative programming and reactive programming. The "magical equals" for lack of a better term, lets you do "reactive evaluation", the opposite of lazy evaluation. If any of the terms that a term depend on change, the result is updated, and all it's dependencies, etc. You can use the system clock as a term, thus have a chain of things that update once a second, etc. Being able to use both reactive and normal programming together without breaking your brain is a whole new level of power. It's brilliant stuff, and it seems to have been yoinked from the internet. 8( Here's a previous thread about it: https://news.ycombinator.com/item?id=27555940 https://news.ycombinator.com/item?id=27555940

pharmakom 5y ago
Can’t this be expressed as a library in Haskell or even F# though?
- AnimalMuppet 5y ago
  That style sounds like it's mutating variables when other variables change (that is, mutate). That doesn't sound like a good fit for Haskell...
  - kian 5y ago
    Haskell is great at mutating variables. Reactive programming was even pioneered in it. It's just that the Monads that allow you to do this are somewhat like sticky tar - everything they touch becomes a part of them. The traditional structure of Haskell programs is to build a pure functional 'core', and layer around that the 'sticky' parts of the code that need to interact with the outside world.
    - AnimalMuppet 5y ago
      OK, but the "reactive" programming sounds like how you build the core. So I still question whether that style fits well with Haskell.

api 5y ago

I wouldn't call it a breakthrough as the ideas are not new, but I consider Rust to be a major practical advancement that brings ideas into the mainstream that were formerly just for "academic" languages. It's the first IMO viable alternative to C and C++ for systems programming ever, and its safety features represent a successful transfer of provable-safety ideas of academia into a practical language that people actually want to use for real stuff. As for true breakthroughs I'd say the last big one was modern deep learning.

platz 5y ago

So if Pizza Hut wants a checkout cart they need to rent a supercomputer to plan the implementation?

mlosgoodat 5y ago
He was speaking as if it was still 1980s. Now we have cloud based ML doing the optimization finding. ML will (eventually) be able to generate biz logic code, and most assuredly infrastructure config (a cloud API has a limited set of possible configs of value to our sorting patterns), UI code (we gravitate towards a limited set of UX it seems), to solve much of our daily programming work. ML can’t invent future ideas, it can’t evolve itself without us making new hardware for it. But it will implode the blue collar dev job market eventually.
- platz 5y ago
  how many years is eventually
  - ausbah 5y ago
    5-10 years, every year
- Zababa 5y ago
  > ML can’t invent future ideas, it can’t evolve itself without us making new hardware for it. But it will implode the blue collar dev job market eventually. I have doubts about that. Open source code seem to achieve a large part of the same function as ML (implement "boring" code for the Xth time) but it only has increased the number of blue collar devs. On the other hand, some no-code tools are opening programming to a large number of people (Excel, actions with your iPhone, things like that). Programming is one of those things that everyone would benefit from knowing, but time is limited, so anything to lower the barrier of entry will just lead to more programming. And more programming means even more programming (someone has to develop the no-code tools, the cloud infrastructure, etc).
  - 5y ago

jimbokun 5y ago

I think the biggest programming productivity boosts since 1984 haven't been about programming languages, but about tools. Specifically, distributed version control and dependency management tools. Being able to collaborate with developers anywhere in the world, and being able to pull in any library with a single declarative line in a configuration file, increases productivity more than any improvement to a programming language ever could.

ComodoHacker 5y ago
>Specifically, distributed version control and dependency management tools. Indeed, without these tools dependency hell wouldn't be possible! /s
- kenjackson 5y ago
  Oh, we still had it!
  - hnfong 5y ago
    Evidence - This started happening in the 1990s (latest) before tools like git and npm was a thing: https://en.wikipedia.org/wiki/DLL_Hell https://en.wikipedia.org/wiki/DLL_Hell
chasd00 5y ago
I agree, could you imagine doing something like Java Spring without maven or the equivalent? It wouldn't be possible.

pharmakom 5y ago

IMO probably monads. Next might be Unison lang or dependent types.

hollerith 5y ago
>>What was the last breakthrough . . . ? >IMO probably monads. So, you believe there have probably been no breakthroughs since 1990?
- pharmakom 5y ago
  Well it depends how you define breakthrough doesn’t it. There have absolutely been advances.

wmanley 5y ago

I feel like Kay has taken a rather too narrow view of what counts as programming. IMO here are the breakthroughs in the last 20 (ish) years: 1. Stack Overflow - search for your problem, copy and paste the answer. 2. git - Revision control that is low enough overhead that you need to have a reason not to use it. 3. Open-source software as a commodity - Unless you've got very specific requirements there's probably a system that can do most of your heavy lifting. (Almost) no-one writes their own JSON parsers or databases or web frameworks. Using open-source software is low overhead and low risk compared to engaging with some vendor for the same. 4. Package managers - By making it easy to include other peoples code we lower the bar to doing so. The common thread here is code-reuse. None of the above are programming languages, but all have driven productivity in building systems and solving problems.

AnimalMuppet 5y ago
I would add: Better, more complete libraries shipping standard with languages.
orthoxerox 5y ago
Code reuse was the holy grail of the 90's. People expected classes to be the unit of code reuse, then enterprise services, then after a dozen years of disillusionment we finally got the recipe right.
- still_grokking 5y ago
  We finally got the recipe right? How? With micro-services? Or Kubernets clusters? Or copy-paste from SO? Or is it more about Linux packages? Maybe NPM? I'm really not sure we've got this right by now. Actually everything is over and over rewritten. May it be because of the language used, may it be because of frameworks, or architectures. Polyglot runtimes that could enable true code reuse at least across language boundaries (like GraalVM) are just emerging. For the higher build blocks though there's still nothing to enable efficient reuse. (People try of course. So mentioning micro-services was no joke actually).
kenjackson 5y ago

N1H1L 5y ago

LLVM could very well be thought of as major breakthrough. The intermediate representation format has enabled so many compiler and languages now, that it's pretty insane in my opinion.

abetusk 5y ago

It always feels like Alan Kay is wistfully talking about how there could have been an alternate future where he and his ilk would do programming and computer engineering the "right way" and somehow the world has lost it's path. He waxes eloquent about how he enabled the genius's at Xerox PARC to do deep work and how they changed the world. I find his talks inspiring but I also find it tone deaf that he doesn't understand the situation he was in nor does he see how the world has changed. Xerox PARC was, in my opinion, a by product of top down "waterfall" like business practices that he happened to be at the apex of. For most of the rest of us, we have to get by with minimal funding and try to push ideas to an over saturated market. What really irks me is how he still has this view that somehow if all the worlds intellectuals just got together or just got funding, somehow they would come up with the next genius ideas and could deliver it to the rest of the world, like god's messengers. Here's what he missed: * Free and Open source. It's not software that's eating the world, it's free and open source software that's eating the world. Most of the worlds infrastructure runs on FOSS and we'd be living in a developer hellscape of choosing between which Apple and Microsoft crippling licensing fees we'd need to pay just to have the privilege of compiling our programs. * Git. Git has allowed project management and software sharing with ease like nothing before. Even though GitHub is a proprietary enterprise, it's created massive value to the community through it's ease of sharing. * Javascript. Write once run anywhere? Javascript is the only language that comes even close. Data representation that's portable? JSON is the only one that comes close. Javascript has it's warts but it brings the best of functional languages in a procedural languages skin. Javascript is the only reason I don't dismiss functional languages off hand, because Javascript actually makes those concepts useful. * Docker (and perhaps some WebAssembly/Javascript environment). I think we're closing in the idea that Linux boxes are the analogues of "cells", where each has their own local environment and can be composed to form larger structures. Linux images may seem bloated now but when space and compute passes a threshold of cheap/fast, it won't matter. * GPUs. Moores law is alive and well with GPUs. "Out of the box" gets you a 10x-100x speedup on algorithms ported from CPUs. I've heard of 1000x-10000x in some cases. It's not just raw performance, it's also designing data structures that work on GPUs, are more data centric and are designed for small, independent and highly parallel workloads. And I'm sure there are many more. I would add cryptocurrency but maybe that falls outside of the "programming" scope. For all his preaching, Alan Kay still doesn't "get it". If there's a billion dollar monopoly that has a small, independent research group that has no ceiling to funding and has Alan Kay as it's head, great, I'm sure they'll come up with some wonderful ideas. We don't live in that world anymore and the playing field has been leveled because of the points above and many more (maybe even more simply just because cheaper compute is available). It never really occurs to Alan Kay that maybe his type of research is not the only way. Better yet, maybe Alan Kay's style of research is gone because we've discovered better ways. If Alan Kay really wants to see the worlds next ideas birthed into existence, why isn't he at the forefront of free and open source, championing the software that enables people to his type of fundamental research? If you really want a trillion dollar ROI, invest a few million in FOSS.

Fire-Dragon-DoL 5y ago

Isn't Rust's compile time memory and concurrency safety a decent breakthrough?

DetroitThrow 5y ago
I'm not sure that was a breakthrough made by Rust, but I think people agree that Rust was the first language that provided those things that people actually have wanted to use outside academia and narrow industry groups.
- scns 5y ago
  30-40 years after being invented.

agent327 5y ago

Since I left university (eighties) I have only been positively impressed by two languages. One was the Wolfram language. I haven't used it; I'm just going on the demo here, but the idea of having not just a powerful language, but also a massive database with useful information to draw from, seems to elevate it above the usual sad collection of new ways to spell variable declarations and loops. The other is Inform. I haven't used that either, and of course it is highly domain-specific, but within that domain it seems a pretty damn cool way to write text adventures. All of the graphical programming systems seem to fail the moment they scale up above what roughly fits on one screen. Labview is a disaster once it is more than just a few boxes and lines. And everything else is, as far as I can tell, just the same bits and pieces we already had, arranged slightly differently. We were promised hyper-advanced fifth-generation programming languages, but the only thing that seems to come close is Wolfram, and that's hardly mainstream. I'm occasionally wondering if the whole field might not improve mightily if we stopped focusing so much on languages, and instead focused on providing powerful, easy to use, elegant, well-documented APIs for common (and less common) problems. Using something like OpenSSL, or OpenGL, or even just POSIX sockets, is just an exercise in (largely unnecessary) pain.

feoren 5y ago
It sounds like you and Alan Kay are both expecting novel problems to be solved by new programming languages. That is an extremely inefficient way to do it: you need to come up with new compilers, documentation, standard libraries, communities, etc. Instead, programming languages have become general enough that most new problems are being solved within existing languages, instead of by inventing new ones. I have no idea what a "hyper-advanced fifth-generation programming language" is even supposed to look like. > I'm occasionally wondering if the whole field might not improve mightily if we stopped focusing so much on languages, and instead focused on providing powerful, easy to use, elegant, well-documented APIs for common (and less common) problems. But a programming language is nothing but a well-documented API! How would your suggested solution even differ from a programming language?
- agent327 5y ago
  That's not quite it. Let me explain... The first computer language I used was BASIC. It was excellent for what it was, but clearly it had a limit on how much you could do with it, on account of it missing amenities like named functions, variable scopes, etc. A 'function' was simply a line further down the program that you branched to using GOSUB. And there was only one scope, which was fine since the space available for actually writing programs was a microscopic 23KB anyway. It had for-loops, but GOTO was still very much present as a tool to control program flow. Moving on from there, I learned Pascal, which was clearly a major step up in terms of what you could achieve. Using the primitives available in Pascal (structured programming, named functions, scopes, etc.), it is possible to write larger programs than you can in BASIC: the higher level of abstraction makes it easier to reason about larger programs. From there C++ was another step up: the ability to define objects and encapsulate a great deal of implementation detail is another weapon in your toolbox to combat chaos, thus allowing you to write ever more complex programs without losing control over what they are doing. And then... there was nothing. There appears to be no step beyond object-orientation that lets you create even larger programs with even less effort. There may be languages that are syntactically easier than C++ (although after using it for a quarter century it no longer bothers me), but they just hide minor implementation details, at the cost of lower performance. That's not greater abstraction, it's just greater convenience. What we were all hoping for was that next step: languages that provided an even higher level of abstraction, allowing you to create even larger programs without losing the ability to reasoned about them. This was what 5GL promised, but which we didn't get because nobody could figure out what they would look like. Apparently we have reached a maximum level of abstraction that we can express with source. So the progression of computer languages looks somewhat like this: 1GL (plain assembly), 2GL (unstructured languages like BASIC), 3GL (structured languages like Pascal), 4GL (object-oriented languages), 5GL (not, as of yet, invented). Each level represents a clear step up in terms of abstraction, and after four steps we seem to have run out of steam, and are now mostly busy reinventing things we already had with slightly different syntax. To me, at least, that's a disappointment. My disappointment with available APIs is perhaps simply because I program a lot in C++, which inevitably means having to deal with an anemic standard library (there's not even a standardized socket interface in there), and a wild array of C-libraries. Some of these are very good, with an elegant interface design and excellent documentation, but many are just painfully bad, with virtually no documentation, and apparently every effort made to confuse the hell of out their potential users. Really, some of this could be so, so much better...

rurban 5y ago

SAT solvers applied. You can now solve unsolvable problems, like practical formal verification in big C/C++ codebases. There's no need anymore to write test cases, as formal verification tries all possible input values, not just a few selected. It also checks all possible error cases, not just the ones you thought about.

AnimalMuppet 5y ago
Could you expand on what you mean by this? Because it sounds like a level of hype bordering on nonsense. 1. How is a SAT solver going to do formal verification? How do you turn a formal verification into a SAT problem? 2. You can only formally verify what your formal verifier can handle, which is usually somewhat less than "everything". Can your SAT-driven formal verifier verify that the worst case response time of the system is less than X? 3. Formal verification tends to be slow. If I can write and run unit tests orders of magnitude faster than the formal verifier, then the formal verifier is going to not be used much.
- rurban 5y ago
  Lookup what CBMC does. SAT solvers will also be also be applied in traditional compilers soon. The remaining problem with formal verification and compilation is proof of termination, which is not a SAT problem. Running all test cases via cbcm is magnitudes faster than writing 100% coverage (only line cov, not covered values) tests. It's like one day vs one month. And I've never seen code with full value test coverage. For guaranteed timing you need special tests, not a SAT solvers. The solver just helps with the proofs.
  - AnimalMuppet 5y ago
    Even if everything you say is true, it's true the first time. Then I make a change to the code. Now if I have unit tests, I have to fix a test (maybe minutes, maybe an hour) and re-run the tests (minutes). Or I have to re-run the formal verification (a day).
    - 5y ago

svachalek 5y ago

Early programming language advancements were about abstracting away the basic repetitive stuff (function call stack manipulation) and the hardware details (register selection, memory addresses). They did it in a way that was minimally "leaky"; debugging a C program you may be aware of the call stack and registers, but most of the time you'll be just fine working at the abstraction level of function parameters and local variables. Since then we've added tons more boilerplate and hardware to the standard application deployment, it runs over multiple servers and clients using various network protocols, interacts with databases and file systems, etc. But modern solutions to these are mostly code generation and other leaky layers, it's likely you can't debug a typical problem without reading or stepping through generated code or libraries. What I'd like to see in a new programming language is some abstraction of an application that has persistent data and is distributed, with the details being more or less compiler flags. And comes with debugging tools that allow the programmer to stay at that level of abstraction. But most new language announcements come down to some new form of syntactic sugar or data typing.

DesiLurker 5y ago

I'd say being able to program GPUs as general purpose compute devices & general SIMD vectorization in high level language is pretty significant. it has opened up many applications like machine learning previously unavailable. IMO some C++20 features like coroutines rank pretty high in introducing new ways of programming.

ColinWright 5y ago
I have a question about that, and despite asking in several places, and reading lots of documents, I've ever been able to find an answer that makes sense. Maybe you can help me. I have an algorithm that I used to run on a SIMD machine. It's a single, simple algorithm that I want to run on lots of different inputs. How can I run this on a GPU? From what I read about GPUs it should be possible, but nothing I've read has made any sense about how to do it. Can you point me in a suitable direction? My contact details are in my profile if you'd like to email to ask for more information. Thanks.
- emllnd 5y ago
  Hi Colin. A few ways to go about it, requires getting some initial tedium done to get started. I would recommend the course https://ppc.cs.aalto.fi/ https://ppc.cs.aalto.fi/ as a resource, goes through specifics of implementing an example data-crunching program using both a vectorized/SIMD CPU approach (ch1-2) and a GPU approach (ch4, using Nvidia Cuda specifically). Another approach would be to upload data to GPU in dx/vulkan/metal/opengl buffers or textures and run shaders on them, plenty of resouces out there but I understand it’s tricky to find a suitable one. Happy to discuss more
- DesiLurker 5y ago
  I think you'd be better served by using something like OpenCL. especially if it was already running on simd core then it should be relatively straightforward to port to openCL. the mental model to follow would be to think of a gpu as a collection of identical simd machines that are programmed in simplified version of C. thinking further, if you have never programmed gpgpu processors you may be better off porting your code using NVIDIA CUDA (assuming you are targeting desktop graphics). it had better tools and overall a better ecosystem.

lordnacho 5y ago

My problem with this is it sort of implicitly assumes that languages are the unit of progress. It's unlikely that we will get progress solely by coming up with better languages, it's more like different people invent different tools to suit different problems. In the explosion, we are more likely to find what we need. I don't think I've ever used just one language for a project. The progress at least personally is that there are now so many resources to use a bunch of different languages to knit together a solution that a lot more can get done. You can write your low latency code in a variety of languages, and ship the data via a web server to a browser or a mobile app. For every part you have several choices of tech to use, and they're realistic choices with lots of help online. Almost everything is available for free, so you can try all sorts of libs without committing to one. There's no longer a need to sit down with a textbook and learn a bunch of stuff before starting, you can just jump in with a brief tutorial and explore the language or lib as you discover them. The plethora of choices also teaches you a lot about languages in general, because you see so many that you can start to make generalizations.

RivieraKid 5y ago

Maybe calling these "breakthroughs" is a stretch, but anyway... Swift. I think that this is the best general purpose language ever created. By "best" I mean that it has the highest productivity (which is determined by readability, static safety, expressiveness, etc.) after normalizing for factors outside of the language spec, e.g. tooling, libraries, compilation and runtime speed. React and Svelte. The first breakthrough was React, the second generation is Svelte and similar frameworks. Async / await. This is a major improvement to the readibility and mental model simplicity of the most common type of concurrency code.

analog31 5y ago

I would consider microcontrollers and programmable logic. They outnumber "real" computers and completely reshaped electronics.

beckman466 5y ago

holochains

tibbydudeza 5y ago

Everything just seems to be a rehash or improvement on C++. I just want better tools i.e low code that non-programming people can use to express what they want a computer to do - something better than Excel.

dd444fgdfg 5y ago

I don't think languages will really "progress" much, in the way that art doesn't progress. That's not to say it wont evolve to suite it's environment.

still_grokking 5y ago
Large parts of computer science are about languages. There is a lot of progress. (Research needs to be novel usually). Only that that progress arrives at mainstream usually 20+ years later, in very small batches. So it's not very visible when looking only on the practically relevant things.
- scns 5y ago
  Very much this. The idea for the borrow checker is from the 80s IIRC. Slowly approaching mainstream with Rust.

AtlasBarfed 5y ago

SSDs Breakthroughs imply practical considerations, and SSDs were the last major improvement to hardware that also required software changes.

Too 5y ago

The biggest shift lately is probably on the ops side. The role sysadmin or DBA hardly exists anymore as full-time jobs. With the goals of containerization and avoiding snowflaking giving lots of positive spill-over effects for the developer side as well. Today i can snapshot the volume of my containers, completely format my computer, download and reinstall Ubuntu from scratch. Download and install any IDE and all tools i need, clone a project from github, npm install thousands of dependencies, spin up a docker-compose network with a distributed nosql database and a a few services, commit and push a MR giving relevant test results back from github CI and someone reviewing the code - All in one day. 10-15 years ago (without even considering the difference in download-time) every step here would be at least a day each, involving complicated configurations and often causing non revertible modifications to the host system. Containerization and sandboxing can also be seen as being big enablers for the mobile app stores and untrusted browser applications being able to deploy to clients instantly. I'd also say UI frameworks are a big deal. Both Windows, Android, iOS and the Web have much more powerful tools than say Win32 or whatever old baseline one wants to compare with. Especially declarative web front end frameworks like React and Vue. Some might call these fad-frameworks, but i for sure can write better web-apps with less than half the number of lines, and with much less spaghetti, compared to what we used to do in 2005 (just close one eye for the webpack complexity), if that's not a paradigm shift i don't know what is. Unfortunately this hasn't always resulted in much better applications for end users when looking at the average app, probably due to lower barrier of entry and race to the bottom. Programming languages, IDEs and tooling overall are miles better than before, even if it's hard to pin any specific milestone to where the shift happened, all small gains add up to a big deal on all fronts. C++ is still C++ and Java is still Java but even there a lot of the verbose boilerplate is reduced giving much better ergonomics. Then you've got things like Kotlin, Typescript and other hybrid-dynamic/static + hybrid-OO/functional languages getting improved and more widespread, Async everywhere, Rust bringing something on the table to finally replace C/C++, package managers used by everyone really enabling code-reuse. You now also got almost all popular languages converging and being equally capable doing everything, not one language per use-case. Then there are tons of other cools things like GPGPU, machine learning, big data, EBPF, crypto and security. It's just too much to grasp.

8eye 5y ago

wasm

blippage 5y ago

I think that programming is the most confused discipline there is. I've mentioned this in previous posts. In any other field there is usually an established body of knowledge, either in science of professions like accountancy. In programming we're still arguing about whether the debits should go on the left and credits on the right, or vice versa. By that I mean, facetiously, we're still arguing about what programming language to use. Most new sciences - e.g. electronics - gather a mature body of knowledge relatively quickly. We know exactly how transistors work and how to use them, for example. Nobody argues about how to calculate the current flowing through a wire. This, to some extent, happened in programming, especially early, but the matter still seems far from settled. Some poster on here once noted that there are no new paradigms in programming. Their argument is that not functional, OO, or other invention, as good as they are, constitute a paradigm shift. A paradigm shift is so fundamental that it uproots our whole conceptions about how the universe works; like the shift away from using epicycles to describe the motion of planets to using a theory of gravitation. I've been tinkering around with microcontrollers lately, and it has given me a perspective that I suspect many don't have. I like C++, and I think it's suitable for high-level programming, due to things like deterministic garbage collection and niceties like strings and vectors. But I've come to the conclusion that C++ is marginal, at best, on microcontrollers. Things tend to be far more static, so these niceties do not bulk large. But C++ also needs extra fiddle if you start from scratch. Things like exceptions need effort to implement. C is low-level. You get to build things block by block. If your microcontroller supports some nifty hardware acceleration feature, then you can use that. And that's the thing. A high-level language is an abstraction. It can't decide what should happen at a very low level. So you have a convenience, but you also take a hit. So perhaps looking for a better language is a chimera, because how you do something is dependent on what it is you're trying to do. It also means that C is never likely to go away as a language, and that C++ was a clever idea in that it built on C.

hnfong 5y ago
> Most new sciences - e.g. electronics - gather a mature body of knowledge relatively quickly. We know exactly how transistors work and how to use them, for example. Nobody argues about how to calculate the current flowing through a wire. Ever since we made computers fast enough to implement basic things in the 1980/1990s, the debate has never been a "scientific" one. It's all about programmer preference and psychology. Equations about electricity is relatively simple. Yet we don't have equations about programmer brains. The only way we can "scientifically" experiment with programming languages is to invent new languages/features and see how programmers react. Do they make fewer mistakes? Do they see increased productivity? Do they "like" it or even swear by it? To a very large extent (more-so than most would imagine), trying to pin down "programming best practices" is like trying to set a standard for writing novels. You have common tropes and literary devices (aka "design patterns"), but the expressiveness of languages (both human and computer) makes it hard to make final, scientific conclusions. The electricity on a wire thing is really much more simpler.

jakeogh 5y ago

comptime fixed macros in a practical implementation: https://andrewkelley.me/post/zig-programming-language-blurs-line-compile-time-run-time.html https://andrewkelley.me/post/zig-programming-language-blurs-...