34 ms·

Programming breakthroughs we need

• bawolff 4y ago
  I feel like a lot of boilerplate is a choice, that often comes from frameworks being used. I disagree with the text criticism as well. The reason we spend time thinking and reasoning about code, is not because its text format. Its because that's the job. We aren't scribes just copying books. The hard part of programming is figuring out what to do, not writing it out. Well i am sure better visualizations or something could offer minor improvements to comprehending code bases, i doubt it will change things significantly. We will always spend most of our time trying to figure out what we need to do not doing it.
  • Garlef 4y ago
    > I feel like a lot of boilerplate is a choice, that often comes from frameworks being used. [...] I disagree with the text criticism as well. The representation as text files is also part of what's causing the boilerplate. As an example: How would you reduce the devops and configuration boilerplate in a monorepo? In your typical JS microservice, a lot of code is not actually JS but yaml, json, terraform, etc. And it is very hard to abstract these away since a lot of tools rely on the existence of actual files. Of course you can use code generation and other macros to manage the units in your monorepo (nx.js does this). But this is very instable since you might need to tweak some file resulting in your macros not working any more. My take would be that textual representation is a local maximum. And our needs have outgrown this maximum. We're spending 90% of our time to innovate to push the boulder up the remaining 10% of this very hill. But there are most likely other hills with a much higher peak.
    • treis 4y ago
      >In your typical JS microservice, a lot of code is not actually JS but yaml, json, terraform, etc. And it is very hard to abstract these away since a lot of tools rely on the existence of actual files. This is a problem of your own making, though. If you don't do a microservice architecture in JS and do a modularized monolith in Go, as an example, you don't have to write any of this code.
  • jillesvangurp 4y ago
    Anything that feels repetitive, like writing boiler plate code, is something that can, should, and probably will be automated eventually. This is a constant if you are a programmer, whatever you are doing today that is repetitive, you'll likely be using some better way of doing that in the future. And as Alan Kay says, the best way to invent the future is to invent it. I'm always on the lookout for doing the same things with less repetition. Boiler plate usually results from people using something that was not originally designed to do that thing or not designed that well. It's indicative of some kind of design friction or feature creep. When it works, people just do more of it without really thinking about what they are doing or why. If you see people copy pasting the same blobs of code over and over again, that's a good sign something is wrong. At some point that becomes the way things are done and people start nit picking each other about doing it properly and then inevitably somebody comes along and does a thing that is vastly simpler and accomplishes the same thing. Happens over and over again. Some people then inevitably resist that new way of doing things because they are really invested in the old way. But the way our industry works is kind of Darwinist; so those things tend to die out quickly once something better comes along. The two mistakes people in this industry make over and over again is assuming that 1) they know it all and 2) things don't change. Because things actually do change, and usually for good reasons, the former requires work to stay true. Some skills last longer than others and not all change is great. If you are just coasting and writing the same stupid code over and over again like it's ground hog day, it's going to eventually run out on you.
• Taikonerd 4y ago
  > Maybe you could write tests as queries that would test a whole set of possible programs, not only the current version of your program at the moment. I think that the future of programming is more sophisticated static analysis. Programmers will write statements like, "every code path that writes to the Payments database must have called validate_user()." Then, the tooling will confirm that rule with every commit. We kind of have this already (for example, Facebook's Infer tool [0]), but I think it will become much more important in the coming decade. 0: https://github.com/facebook/infer https://github.com/facebook/infer
  • hcarvalhoalves 4y ago
    Watch this (skip to 1:17:28 to see a quick demo, the rest of the video is the explanation): https://youtu.be/OyfBQmvr2Hc https://youtu.be/OyfBQmvr2Hc It’s exploiting logic programming to query for a program that satisfies some condition.
    • spikej 4y ago
      But take a step higher and you get this https://youtu.be/FvNRlE4E9QQ https://youtu.be/FvNRlE4E9QQ
  • vsareto 4y ago
    To set up an example, Azure has some API management stuff that could let you do this before you even got to your code. Writing a tool to make sure that API management rule exists would be different than static analysis. I'd agree with you, but not all of the business logic like that is going to live in code in the future.
• manv1 4y ago
  What we need before all this is a better way of specifying program behavior, both at a high and a low level. In mobile there are multiple tools that you can use to prototype UI behavior. They allow you to specify navigation, transitions, clickable areas, behaviors when clicked, swipe actions, etc. They're this way so that the UI behaviors can be seen before coded (to an extent - not every prototyping tool does everything). For code, well, only formal specifications get to that level. I haven't actually seen one of those outside of software engineering books, but I presume they exist in more critical fields. Commercial software doesn't really use them because they're too much work.
  • Taikonerd 4y ago
    This Hillel Wayne post [0] mentions a startup called Sketch.systems [1], which I think is sort of like what you said? It's not just a UI prototype; you build a model of the underlying state of the system as you transition from screen to screen. 0: https://www.hillelwayne.com/formally-specifying-uis/ https://www.hillelwayne.com/formally-specifying-uis/ 1: https://sketch.systems/ https://sketch.systems/
  • dugmartin 4y ago
    There was a lot of money poured into doing this in the 80s and 90s without much success. Maybe it is time to try again? https://en.wikipedia.org/wiki/Fifth-generation_programming_language https://en.wikipedia.org/wiki/Fifth-generation_programming_l...
• js8 4y ago
  I would suggest to author to look at functional languages, like Haskell. These are based on principles of function composition and referential transparency. The move from testing to static analysis is happening there, in the expressiveness of the type system, and its inferences. Functional languages are on the forefront of experimentation with new type systems.
  • fullstackchris 4y ago
    > The move from testing to static analysis Are you claiming that static analysis of code can replace the concept of writing tests completely? If so, I'm very skeptical.
    • js8 4y ago
      Depends on the type of the test. The larger the system is, the more unexpected interactions can happen, and the more need for testing. But if we are talking about unit test on the level of functions, yes, I think they can be replaced.
• zwkrt 4y ago
  There’s a lot of complaining and not a lot of suggesting going on in this article so I don’t take it for very much. I feel like the author got a job and realized that it almost exclusively involves writing glue code and tests and looking at text diffs, so how convenient to imagine a world where they didn’t have to do the boring parts of their job.
  • SKILNER 4y ago
    I think the author is identifying problems. Problems most people just take for granted. I give the author credit for that.
  • foolfoolz 4y ago
    very much agreed. i don’t like the term glue code. when people say glue what they usually mean is their applications specific business logic
    • 082349872349872 4y ago
      a Shannon-inspired taxonomy (note the indefinite object; ymmv): - glue code: given the outputs, you can reconstruct the inputs. this code translates between formats, between systems, etc. - parsley code: given the outputs, you could reconstruct the inputs. this code "gussies up" its inputs: it takes table rows to JSON, or JSON to framework objects, PDF, etc. so in principle the original data is still there, but once the outputs are sufficiently complex the inputs become extremely awkward to reconstitute. - crunch code: given the outputs, you have no hope of reconstructing the inputs. this code does real computation, and forgets stuff. Example: You can get a source program given only an executable, but you won't get the source that it was compiled from (nor will you, without a lot of work, even get a source you're willing to read)
  • baobabKoodaa 4y ago
    I think you're being unnecessarily harsh. I get your point about OP presenting problems, not solutions, but on the other hand, they are a programmer & they are clearly trying to automate the repetitive parts of the job. Isn't that basically the essence of programming: what good programmers should be doing is automating as much of their job as possible.
• bluesnowmonkey 4y ago
  Software reuse-in-the-small is a solved problem, but reuse-in-the-large seems unsolvable. That’s been the state of things for decades. Testing is hard because the requirement for correctness is often absolute and inflexible. When software is allowed to be a little incorrect, then yeah testing gets much easier.
  • fullstackchris 4y ago
    Yep. And your "reuse-in-the-large" I'd argue is also a side effect of reality itself. Take any market sector or industry, not just software - I suspect the "easyness" of directly reusing and copying any complex system is vanishingly small. If that were not the case, we would have infinite choices and brands of any complex product ever made!
• jrm4 4y ago
  Eh, unfortunately the one programming breakthrough the world actually needs is one that would drastically change, and perhaps harm, most of the people around here. We need more "Excels." More and better tools that let "regular" people program.
  • spikej 4y ago
    Or more realistically the rapid application development tools need to be better so we're not bogged down dealing with latest fad or resume driven development
    • vsareto 4y ago
      There's not much reason to improve things. No one's out here saying "you don't get this job because you chose new technologies when they weren't needed". Even if you can equate glue code with trash, we seem to have unlimited space or a black hole to throw that trash.
    • jimbob45 4y ago
      What more do you want beyond Wix and VB.NET? People just don’t use RAD stuff anymore because…well I don’t know why.
  • PeterWhittaker 4y ago
    Excel programming errors cost business $$$ https://www.cnbc.com/amp/id/100923538 https://www.cnbc.com/amp/id/100923538
    • genghisjahn 4y ago
      You’re right. All business should get rid of spreadsheets to save money.
      • pessimizer 4y ago
        We can't blame spreadsheets for the cited errors, because they're errors in arithmetic rather than Excel bugs. All businesses should get rid of arithmetic.
• julius 4y ago
  Maybe future programming systems can use an assertive pattern, where software developers only define what the software is supposed to do. And the programming systems generates a program that fulfills all assertions. Then when the software designer finds that the software does something wrong, he can simply add assertions. Its a little like TDD but without coding. For GUI applications it would be cool to define assertions via natural language and the programming system drawing pictures to explain what it understood.
  • RcouF1uZ4gsC 4y ago
    My intuition is that making all the assertions to write correct code with decent performance and scaling is at least as complicated as writing the code.
  • cholantesh 4y ago
    Isn't that what low-code solutions claim to offer?
    • jocro 4y ago
      This is closer to no-code, but yeah. Main reason to make the distinction is that most systems that parade themselves as "low-code" today are IME indistinguishable to high-code development to your average joe. Even taking this example, the level of value totally depends on the degree of abstraction you can trust the computer to perform for you. There is a tremendous amount of nuance to human language and while we've come a very long way in that field of study, it's still a hard nut to crack.
      • cholantesh 4y ago
        I would agree. In my current role, we have a dedicated, growing team that builds such applications which tells me all I need to know.
  • Taikonerd 4y ago
    Like declarative programming? [0] I agree with you: assertions in natural language would be a killer app. [0]: https://en.wikipedia.org/wiki/Declarative_programming https://en.wikipedia.org/wiki/Declarative_programming
• coding123 4y ago
  If an AI can now draw a rembrandt, then it's not far off that an AI can read this: Regular users are allowed to edit their own books. Editors are allowed to edit any books with the same account id. The public can read about any book that is not in draft status. I need a domain model where users can write books with the following properties: userId, accountId, title, author, status. status is an enum supporting draft, published, no longer available I know this seems like a completely different paradigm, but I think we were wrong about General AI needed to replace programmers - we just didn't know how "normal AI" would go without being General AI. I can also see this extended into the front-end at least for rudimentary forms. I can imaging someone doing a transfer AI to make front-ends have a consistent and nice looking feel that can change pretty easily - perhaps to match the user making the request.
  • WJW 4y ago
    Assuming you mean that to be a rough draft for the spec of a book management app, you wouldn't need an AI to parse that and generate code. A simple DSL is enough and indeed the "spec" you wrote could be implemented in about ten minutes with Rails, devise and pundit. (I imagine most other popular backend webdev languages have similar libraries available)
    • rmetzler 4y ago
      I wonder if the author of the blogpost ever tried Rails’ convention-over-configuration approach. It might be exactly what he means when he says he gets to write less boilerplate.
  • ElectricalUnion 4y ago
    > I think we were wrong about General AI needed to replace programmers So, the hard part of software is figuring out what you actually need done. You still need the person writing the system requirements to be precise, accurate and not ambiguous, or you need General AI to figure out if the supplied system requirements meets those requirements. And when things inevitably goes wrong, or requirements change as they always do, "you just" have to review and rephrase your entire requirement list, or you need General AI to do that for you.
• smallstepforman 4y ago
  I’ve been programming for over 30 years, and never been as productive as before. Need to load and decode a jpeg/png, I grab stb_image.h. Need to decode an ogg file, libogg. Need to decompress, libz. Need to decode video, libavformat. Need physics, libbullet. Need truetype fonts, freetype. Need a GUI, Qt. Need SSL, libssl. My day becomes selecting libraries, integrating them, and testing integration. My business code is < 20% of our entire codebase. And I’m much more productive in 2022 than in 1992.
  • swatcoder 4y ago
    That’s funny because I feel like my day became cleaning up those kinds of projects as their countless dependencies rot. It feels anything but productive.
    • mynegation 4y ago
      What is your alternative then? Vendored-in dependencies with their ossified security vulnerabilities? Or figuring out homegrown code of dubious quality for the functionality that is not core business of the company/product?
      • swatcoder 4y ago
        Nothing so dramatic. The alternative is judicious inclusion of dependencies rooted in thoughtful, experienced engineering. Robust, comprehensive libraries from reliable vendors can provide a lot of value and are slow to rot. These can be anticipated and added early so that they’re made good use of and can become the first tool to reach for before adding other dependencies. Think React, lodash, QT, boost, etc. Meanwhile, I acknowledge that most other packages and repos are of far more dubious quality than anything my team would write, have no accountability to my team or stakeholders, receive few/no code reviews when added or updated, introduce conflicting style/semantic conventions, and generally expand the surface area for bugs and vulnerabilities by including many lines of code that have no relevance to the project. There are no strict rules, but these are the sort of considerations that weigh in.
• 082349872349872 4y ago
  > usually the biggest problem is an enormous amount of CRUD boilerplate that looks very similar in each project, but it's nevertheless different in important details. Once upon a time, a lot of microprocessor code was written in assembly. Then C came along, and many of the assembly people said: "whoah, hold on, I use different calling conventions in different places for good reason; what do you mean every C function is going to use a whole stack frame even if it's never re-entered?" But now 99+% of programmers don't care about sub-kb stack frames, and probably most of them even consider C too low-level[0] to touch. I've said elsewhere[1] that much of the ceremony of cloud sw dev reminds me of 1960's mainframes — so what is the equivalent of a "structured programming" toolchain for the cloud, that takes some higher level description of inputs, outputs, and logic[2], and then generates not-entirely-ludicrous boilerplate to mash it all together? [0] in hindsight, C's big advantage back in the day was that it mixed much better with assembly than purer HLLs. [1] https://news.ycombinator.com/item?id=32467919 https://news.ycombinator.com/item?id=32467919 [2] compare the "environment division" of COBOL with Terraform, and the "data division" with Swagger. I mean, we've definitely progressed on many fronts since then, but certainly not on the axis of "lack of verbosity"[3]. [3] OTOH, Conway's law suggests that multiple-team projects will always wind up with multiple configuration in multiple places.
  • marcosdumay 4y ago
    The interesting part is that no, function calls do not all use an entire stack frame, unless you compile your code for debugging. Compilers are smart enough to reencode the calling into just registry shifting, or even inline the entire thing.
    • 082349872349872 4y ago
      Agreed, compilers do now. In 1978, they did not. (although maybe even then things like BLISS, on minis, did?) The machine I learned C with maxed out at 64K data. Needless to say, the compiler was not doing much beyond peephole optimization.
      • marcosdumay 4y ago
• SKILNER 4y ago
  Great post - the one word missing, "maintenance." Most programming work is done maintaining/enhancing existing code. The greenfield work is a piece of cake by comparison. You want to do the hard stuff? Maintain existing code you're not familiar with. The problems around maintaining unfamiliar code are huge, largely unsolved, expensive and risky. There's a little branch of computer science called Program Comprehension and no one pays any attention. Though most programming money is spent on maintenance.
  • danielvaughn 4y ago
    I always tell my clients - the difference between writing code and maintaining it, is the difference between raising your hands and keeping them raised indefinitely.
    • iovrthoughtthis 4y ago
      powerful image!
    • baq 4y ago
      great analogy. totally stealing this.
    • deepakkarki 4y ago
      Or the difference between conceiving a child and raising one :)
      • danielvaughn 4y ago
        Ha, love this one.
      • metaltyphoon 4y ago
        I always smile when a green field project starts and then they claim its “Clean Code”. No, you won’t known if it was clean code until years down and the system will need updates. Then and only then you can reflect and see how hard it was to changes things in it.
• 29athrowaway 4y ago
  My 2 cents: There are thousands of projects trapped into formatting hell because nobody wants to touch git history. We need a standard to fix formatting programming without messing up history.
  • LesZedCB 4y ago
    convert code to sexprs, diff the tree, track those changes not the text on a 2d grid
  • x1xx 4y ago
    To some extent this can be addressed with `--ignore-revs-file`: https://www.git-scm.com/docs/git-blame#Documentation/git-blame.txt---ignore-revs-fileltfilegt https://www.git-scm.com/docs/git-blame#Documentation/git-bla... An example: https://www.moxio.com/blog/43/ignoring-bulk-change-commits-with-git-blame https://www.moxio.com/blog/43/ignoring-bulk-change-commits-w...
  • joshlemer 4y ago
    Some code formatters such as Spotless (https://github.com/diffplug/spotless/tree/main/plugin-gradle#how-can-i-enforce-formatting-gradually-aka-ratchet https://github.com/diffplug/spotless/tree/main/plugin-gradle...) allow you to format code only in files that have changes against some designated branch such as `master`. So, you check out your feature branch, make changes, do some commits, and run spotless. Only the files which have some changes between your workspace and the master branch will be formatted. This allows you to gradually format the project as and when files would be changed anyways.
• jesperlang 4y ago
  There is a lot of interesting work on program as non-text/model at Unison: https://www.unison-lang.org/learn/the-big-idea/#richer-codebase-tools https://www.unison-lang.org/learn/the-big-idea/#richer-codeb... Until these ideas go into mainstream, treesitter has resulted in some interesting improvements to e.g Neovim. I use it extensively for AST based selection/navigation and along with conceal I can hide/transform a lot of noise characters in text source code.
• Aqueous 4y ago
  I've thought about this issue so very many times, and I feel that until someone creates a system capable of understanding the underlying purpose of the code, we will not be able to automate this stuff away. I think the issue is that all of the things the author wants a breakthrough for is exactly what makes programming hard. We don't have systems intelligent enough to reason about a contract between two systems so as to create a general-purpose solution for things like glue code. The subtle differences that are there and that require us to do this work over and over again with small variations are precisely why programming requires intelligence.
  • 082349872349872 4y ago
    Part of the "structured programming" revolution was that the compilers said "any color you want, as long as it's black": they were general-purpose glue code generators by declaring everything to use the standard contract. (later, optimizing, compilers would spend a lot of effort to reason about different contracts, and in recent times, "undefined behavior" would come to surprise people who were used to the rather laxer approach to contracts in earlier days, but these are epicycles.) There will always be work doing things over and over again with small variations, but I for one am glad to no longer be making variations on decisions like "will this parameter be coming in a register (which?) or on the stack (and if so, with what alignment)?"
  • w10-1 4y ago
    Charles Simyoni's Intentional Software attempted systems "capable of understanding the underlying purpose" targeted at both programmers and business people. It was (hidden) parameterization all the way down. They invested several engineer decades and got no where. Microsoft bought them out for their patents.
  • commandlinefan 4y ago
    > we will not be able to automate this stuff away We can't even automate testing of code (no matter how much "test automation" you have, you have manual testers too). That's orders of magnitude easier than automating the creation of the code in the first place.
• whatsakandr 4y ago
  A paradigm that Dave Farley has mentioned could be on the same level as OOP or structured programming is a completely asynchronous programming language. Every operation would have no garunteee of executing immediately. Such a thing may unlock more performance for cheaper on modern multicore cpus.
  • 082349872349872 4y ago
    When we tried async-everything in the 1980's we discovered that there is such a thing as too-fine grained parallelism: the sweet spot (problem dependent!) is where communication and computation are balanced.
• flyaway123 4y ago
  A lot of the thought process here seems to move into Bret Victor's talk on 'Inventing on Principle'[0] [0] https://youtu.be/EGqwXt90ZqA https://youtu.be/EGqwXt90ZqA
  • hunterx 4y ago
    mostly just a glimpse of that talk, perhaps better suited is the one about programming he gave at Dropbox. In my opinion quite more in-line with what's being said.
  • panstromek 4y ago
    This was en excellent talk, exactly in the direction was talking about. Thanks for the link.
• myco_logic 4y ago
  > It feels like there's an unexplored dimension of abstraction here. Something where generics, interfaces and higher order functions are too static and low level primitives. Something where it's really difficult to pinpoint what exactly is the repeated pattern here and how to exploit it. Instead of generic framework that can do everything, I'd like an efficient way do something specific. This bit reminds me a lot of a concept Aaron Hsu mentions in his fantastic talk on anti-patterns in the Iversonian languages[0], a paradigm he terms "Idioms over Libraries". The idea being that because of the expressive power of APL's primitives programmers often opt for utilizing easily recalled snippets of symbols over the importing of library code to implement common functionality. This facet of array-lang culture can be seen with sites like APL Cart[1], which serve as indexes of these frequently used snippets. I think a lot of people miss that this is one of the major advantages induced by the terseness of these languages (it's not just about code-golfing for the implicit joy of laconicism). By allowing for the direct expression of algorithms in the same context they are being used, APL and its kin enable one to tweak and optimize these idioms on a case-by-case basis: precisely the kind of specificity the author of this article is asking for. [0]: https://youtu.be/v7Mt0GYHU9A?t=1027 https://youtu.be/v7Mt0GYHU9A?t=1027 [1]: https://aplcart.info/ https://aplcart.info/
• agentultra 4y ago
  I think we need two breakthroughs (maybe three): 1. Less code. Operating systems have become obscenely bloated and restrictive. There is an enormous amount of power in the hardware we run our stuff on these days but you can't even touch it as a programmer anymore. 2. Powerful proof assistants and code synthesis. I love low-level programming but even the most hardcore, brilliant people I've met can easily introduce show-stopping security flaws into software without realizing it. It turns out that programming is hard and without rigorous models and proofs humans are really poor at understanding programs. We naturally hand-wave away details which get us most of the way there but these are discrete systems and details matter a lot. As for testing... I agree, unit tests are often insufficient but probably the lowest bar you could convince typical industry software developers to hurdle to prove the correctness of their programs. Even then, as the author notes, they will come kicking and screaming with their opinions. There are far better options and strategies but as soon as you mention property testing or formalization you'll lose about 90% of the room so you have to pick your battles. The trouble is that most startups are motivated to accidentally stumble upon a market niche and in this day and age that often means, "something with computers." They're not in it to write reliable, robust software that is efficient and performs well on a target platform. They're writing code that they can cash out on and never see again. Very different world. The final breakthrough we need is to fund research labs again. Technology isn't inevitable and civilizations in the past have lost the ability to build and maintain it. We shouldn't let that happen again if we can help it.
• jacknews 4y ago
  "Writing tests is time-consuming, usually doesn't scale, and it easily creates tight coupling with implementation, which makes change difficult." Amen.
  • commandlinefan 4y ago
    > The only thing worse than testing is not testing, but testing is not much better. Even more amen.
• hospadar 4y ago
  I have some beefs: > To be more specific - for most web projects I work on, I have a very similar yaml file for CI, Dockerfile, Very similar, but not actually the same - of course there's always a tradeoff between control and convenience. Maybe you don't like where kubernetes, $CI_TOOL_OF_CHOICE, etc puts that tradeoff, but that's why there's a zillion tools and languages out there, because someone wanted a slightly different tradeoff > Changing the program is the most common thing we need to do in our work, it's the reason our job even exist. And yet, most of programmer's time is spent reading or planning how to change the code. I think I fundamentally disagree with the idea that "reading or planning" are second-class activities here. I think that one of the highest purposes of a programming language is is to communicate to other humans, unambiguously, what the program is intended to do. I think most languages have a sweet spot for "good at communicating for $TYPE_OF_PROBLEM" - it'd be a nightmare to read the assembly code for say a AAA videogame and try to figure out if it's a FPS or RPG game, but if the intent of a program is to do a small thing in a super-architecture-specific way, probably assembly is a great choice - exactly because some other human will see _exactly_ what you mean. If I have to work in a big complex codebase, it's great to use a very structured language like java/rust/etc where all the many, many pieces are (or at least can be) clearly named. I'll have no idea which CPU registers are twiddled when, but I don't care, and neither did the author of that code (presumably why they chose a high-level language). On the extreme end - a tool like excel which is AWESOME for getting computations done and presenting the results, but is (IMO) not the best for communicating _how_ to do those computations. Do every single one of the cells in this column have the same formula? If not why? Is that intentional? I thing programming languages are awesome exactly because of the extreme, explicit precision and repeatability that they allow us to communicate with, but certainly not all problems [that are currently solved with programming languages] require that kind of rigor.
• sshb 4y ago
  Agree with most of the points in the article. I’ve tried to attack this party by generating code and leaving all other maintenance to developer without any framework constraints: https://github.com/sashabaranov/pike https://github.com/sashabaranov/pike
• fillest 4y ago
  I think, the problem is: the production of languages (and libraries especially) is way too much market-driven, there is too little cooperation, too little time spent to polish and to model at least some major use cases. Also the quality of education is too poor, too focused on time-to-market - it makes harder for non-seniors to understand e.g. complex type systems (which are required for more usable languages anyway). A language is released too prematurely -> some companies start to use it -> design problems become clear, but the language is in a compatibility trap at this stage -> e.g. it becomes a swamp or it slowly becomes a monstrosity of design afterthoughts and crutches. It probably even wouldn't require much more spending from corporations, only some initiative. They anyway already invest considerably in language&toolchain development, but often with wasteful goals.
• kgr 4y ago
  I think FOAM does most of what the author is asking for. A quick explanation is provided in this video: https://www.youtube.com/watch?v=S4LbUv5FsGQ https://www.youtube.com/watch?v=S4LbUv5FsGQ And more details can be found at: https://github.com/kgrgreer/foam3#videos https://github.com/kgrgreer/foam3#videos FOAM is a modelling framework that generates cross-language boilerplate for you, but it takes a much broader view of what constitutes boilerplate than most systems. Typically, it can generate between 95-98% of a working cross-language cross-tier system. FOAM helps you create features for modelled data. Features include things like a Java/Javascript/Swift classes to hold your modelled data, code to marshall to/from JSON/XML/CSV/etc., various GUI Views, and support for storing your data in various databases or file formats. However, FOAM models are themselves modelled, meaning they're afforded all of the above benefits as well. This lets you apply the MVC technique of having multiple views work against the same underlying data-model concurrently (say a grid and a pie-chart in a spreadsheet), so that you can choose the best view or views for your current need. When treated this way, your code is no longer text (but it can be, if that's one of your views), and you can easily view and store it in many different ways and more easily programmatically manipulate it.
• mannykannot 4y ago
  There's a touch of "let them eat cake" in the author's expectation that these difficult problems could be easily solved, if someone just put a little thought into it. This is perhaps most clearly revealed here: "Changing the program is the most common thing we need to do in our work, it's the reason our job even exist. And yet, most of programmer's time is spent reading or planning how to change the code." Combined with the disdain for testing those changes, it seems the author wants a magic programming wand.
  • guhcampos 4y ago
    This. The author lost me there, I just scrolled past the rest to the conclusion. This guys seems to believe produtivity equals amount of information produced, and fails to grasp the basics of creative work, which is exactly thinking.
• carapace 4y ago
  All this stuff exists, and most of it is decades old. The reason we don't make (better) use of it is that IT is a fashion driven field that ignores prior art (as the author of TFA demonstrates.)
• alexashka 4y ago
  This to me sounds like someone whose job it is to dig holes and fill them back in, asking for an improved shovel, or exercises for his lower back. There is nothing wrong with improving shovels, exercises are great. But why are we digging holes? :) What does using a modern subset of C++ prevent us from achieving, that we really want? Are programming tools the bottleneck of modern society? Do we really need 100s of computer games released each year, 1000s of funded start-ups trying to become unicorns, a 'metaverse'? Do we need all that? Or would we rather have UBI, land value tax and enough sanity in society so that women choose to have children again? You tell me :) If you say 'we can have both', can we really?
• remram 4y ago
  I don't see the problem with boilerplate or editing code. Even using a template with your CI/CRUD boilerplate/deploy scripts/... is no problem if you have version control, you can easily see what comes from the template, what you've changed, and reconcile with a new version of the template. What is the problem? That not 100% of the code in the file is business logic or only exists in that project? When I receive a letter, there is plenty of boilerplate there: addresses, greetings, sign offs, business hours... does that really get in the way of my reading the message, once I'm used to the format? The information is there if I need it, easy to ignore if I don't, and easy to copy-paste for the author who will update if needed (e.g. closed exceptionally or something). Is the author running into a problem or just complaining about perceived inefficiencies that don't actually get in anyone's way?
• mikewarot 4y ago
  >Also notice how writing the refactoring as a query over the model is actually not that difficult. I can imagine how I would write an SQL query like that in a few lines. On the other hand, writing an automated refactoring system in IntelliJ or VSCode sounds like a lifetime problem, and it's kinda unsolvable. No, it really isn't unsolvable. I saw the demo for DION[1] after following a comment[2] here, and it was close enough to some ideas that I also thought were unsolvable, until I saw their demo. They made a brilliant choice, use the model to regenerate source code. This transforms the problem into something much easier to work on. I'm an old Pascal programmer, so I did what I always do, fired up Lazarus (the Free Pascal based IDE) and started writing code.[3] It doesn't do any actual work, except for showing off the main concept. Abstract syntax tree on the left generates almost usable Pascal code on the right. Selecting code then selects the right part of the tree that generated it. I've only got a few hours into it, and it's already doing things I would have thought impossible, trivially. There's no reason you, dear reader, couldn't do the same with your own programming language. We're at one of those points in history where 5 people invent the same thing. The future is going to be a lot better once we can directly manipulate Abstract Syntax Trees instead of source code. 1 - https://media.handmade-seattle.com/dion-systems/ (watch the 1st video!) 2 - https://news.ycombinator.com/item?id=32372707 3 - https://github.com/mikewarot/treehouse
  • panstromek 4y ago
    > No, it really isn't unsolvable. I was talking about some specific cases - e.g. rename is unsolvable for some languages with macros (like Rust, in the linked article). Of course, DION solves that by going from opposite direction, which I think is the key (also got a lot inspired about this from their demo)
• the_af 4y ago
  Everytime someone proposes a non-textual representation of code I cringe. There's a reason no one single alternative has triumphed over text. And many have been proposed! Standards are hard. Proprietary tools lock you in. Text is universal (OK, restricted to plain ASCII, which is a big deal but has already happened). You can open and modify a text file with whatever editor of your choice, the simplest possible editing tool. Some weirdos (joking) even print source code. That reading, not modifying, is the primary operation to be done on source code is an unchangeable fact of life. You won't be able to change anything without inspecting it first, and no representation is going to save you from that -- and it's undesirable to wish for this, in fact.
  • mikewarot 4y ago
    >Standards are hard. Proprietary tools lock you in. Text is universal (OK, restricted to plain ASCII, which is a big deal but has already happened). You can open and modify a text file with whatever editor of your choice, the simplest possible editing tool. Some weirdos (joking) even print source code. Ideas are impossible to specify precisely, which is why we use words, with all their myriad definitions. However, if you apply enough computing power, you can autoencode your way to a compact expression of ideas as a 384 dimensional vector (like Word2Vec), that is non-standard, but exact for that particular model, with those particular weights. You can then repeat the process in multiple languages, and with parallel texts, language translation becomes something that can be automated. The abstract syntax tree doesn't have to be something that can be shared to be a very powerful tool. It certainly doesn't have to be standardized. Just as there's no rational choices made in the 384 dimensions generated by word2vec, there doesn't have to be anything other than a binary format the tool can load and save, in order to work. If you can ingest multiple languages, and regenerate them as output, translation between programming languages becomes almost trivial.
    • the_af 4y ago
      Thanks for your reply! I'm not sure if this is what you're saying, but I think the AST is not meant for "human" consumption (so it'd be outside the scope of this debate, I think), but also, translations that result in alternative and radically different representations between what you see and what I see can be problematic. "I don't understand your program, it's hard to follow." "What do you mean? The yellow and black colors alternate quite nicely." "Colors? What do you mean? I only see triangles arranged in a jarring manner, and they are hard to navigate." "Navigate? Everything fits in a single board of yellow and black colors, no need to navigate anything." Etc.
• probablypower 4y ago
  For me it is the separation of business logic and data from the programming implementation. Often the workflow in automating a work process is: - Worker has intuition on how things work - Specialist starts automating and running into exceptions, walls - Worker explains exceptions as they're discovered - Specialist adds spaghetti to the 'clean' business logic model they started with - This keeps going until the end result looks like what the worker expects - The worker then sees a datapoint they think is incorrect, but they can't check it because the business logic is embedded in software, code, database stored procedures, etc. - The specialist is then called back into debug and resolve the issue. At my workplace we run into this issue constantly, where the ability to modify/adapt the business logic is lost through automation, and it becomes obscured to the point that the intuitive workers can't trust that the logical model is right. There needs to be better separation of business logic from models so that programmers don't need to 'dig' into business processes and exceptions, and workers don't need to deal with part of their responsibility being shoved into a black box that they're not sure they totally trust or can adapt easily should a need arise.
  • csours 4y ago
    Wow. I would say the complete opposite. Why are you writing a program for work unless you are helping to solve a problem? The implementation only exists to work with business logic and data. Excel is an implementation that does not care about business logic and data. Anyone can add their own business logic and data.
    • akersten 4y ago
      That most of the business world lives and breathes Excel is a testament to OP's point. Companies can cram whatever garbage logic they like into a spreadsheet and no one has to call a developer Microsoft because their pivot table isn't doing The Business Thing that they expect - the end users simply have the power to understand and fix the problem themselves.
      • csours 4y ago
        Sure, but then what is your job? Making Excel? No one needs you to make Excel, it already exists.
• enriquto 4y ago
  Just give me modern and complete hardware drivers for plan9.
• jaredcwhite 4y ago
  As a dyed-in-the-wool Rubyist, I consider Ruby the pinnacle of high-level, abstracted, expressive programming for the contexts I care about (small web applications largely written by solo devs). What's sad to me is that the modern follow-up to Ruby seemingly doesn't exist. Every hot "language du jour" which has come after Ruby has gone BACKWARDS. Lower-level, more systems programming oriented. Maybe even compiled. Static typing everywhere. It's utterly baffling to me. "Why are you using Ruby? You should use…Rust! (Go! Zig! Fill-in-the-blank nerd hype!)" Lol. What I actually want is a new programming language/environment which makes Ruby look like programming pointer arithmetic in C by comparison. Something so advanced, so high level, that much of the time you're really just describing patterns and flows and data models and extensions, and then letting the computer determine the most efficient way to develop those code paths and execute them. Unfortunately, I'm a bit cynical on this front. I believe the reason this doesn't exist is because it's at cross-purposes with programmer nerd culture. Many programmers enjoy the nitty-gritty of low-level coding. They fear abstraction. They fear "magic". They fear things like "implicit imports" or "duck typing" or "many ways to express the same method/function/algorithm" etc. because it's all nebulous and fuzzy compared to the safe confines of deterministic math & logic. "If I declare that this variable MUST BE AN INTEGER, then it MUST BE AN INTEGER. The idea you could pass me a string instead? UNACCEPTABLE !!!#%@!" In other words, I don't have high hopes that great UX for forward-looking developers will come from present-day programming culture. For a quantum leap in DX, we probably need people who aren't die-hard programmers to engage in blue sky thinking. We need to talk to artists, philosophers, linguists, psychologists, and other experts in social & historical cultural dynamics. They can provide the insight we lack. Because for every "this is an integer, damnit!" type out there, there are probably many, many more who would see 123 and "123" and think THAT'S THE SAME THING. :-D
  • BlargMcLarg 4y ago
    Pretty sure I speak for a majority of experienced devs when I say: we don't fear abstractions. We fear abstractions made by others, including our former selves, in the all to often occurring context of "business wants it done by yesterday and we have zero idea what the requirements actually are". All the while we're still figuring things out and having 30 minute discussions on the most miniscule things.
• yaccz 4y ago
  > the text is just a tool to manipulate some abstract model of the program. yup. > When you think about it this way, it becomes clear that using a textual source code is really inefficient way to manipulate this model. Hard nope. All the attempts at different approach were a failure so far. Text so far is the best thing we have because text can be analyzed formally and computed with by computers. This is the result of the work that's being going for at least like 200 years in philosophy, logic, and math. What we really need is to bridge the gap between programming and math as industry standard, not academical exersise somehow. But I highly doubt eliminating text as source code is it.
  • touisteur 4y ago
    To add to this, I think text still needs to be the canonical representation of programs. But we're still ways away with tools to express ways we want to modify, generate code. I think the late Pieter Hintjens had the right of it: we should generate code more often (I know it's polemic here). Not behind some magic curtains like the overly complex (for me) and difficult-to-inspect c++ templates but actual code generators. One example: recordflux [0] generates, from a high-level dsl, SPARK code that can be proved to be Absent of Run-Time Error. It has a model checker for high-level constraints but lays out serialisation/deserialisation code to access fields. They've been recently working protocol/session-level modeling and it's getting very interesting. I have a similar tool that I use to generate AORTE serdes code, but once you have that, you can go on to generate fuzzers, proxies to other techs. We're probably also missing a way to target interesting intermediate representations of programs (either Why3 VCs, cbmc GOTO, but maybe also to lean 4 or whatever temporal logic tool of the day, or other automated/assisted proof or generation environments). Writing those is a huge undertaking every time, and a lot of duplicated potentially buggy effort. I look at the amazing work that's been done (and still being done) to bring up libadalang, a parsing and high level semantic query tool that changed my day-to-day coding paradigm. One of the missing pieces of the puzzle is to me the 'generic parser and semantic specification' that would generate an interpretor and all those proxies for you. [0] https://blog.adacore.com/recordflux-from-message-specifications-to-spark-code https://blog.adacore.com/recordflux-from-message-specificati...
  • panstromek 4y ago
• gervwyk 4y ago
  Excellent insights in this article. I've approached building web apps as data models. It works really well for our team. This was how / why we started to develop Lowdefy [0], to express a web application with a data model. We've been experiencing the benefits of this - I really need to start writing about it. Writing this app model in json or yaml might not be ideal start, but once you have that creating a IDE / GUI builder / next thing on top of that becomes really a simple task while reaping all the benefits of defining an program / app as a data model. [0] - https://github.com/lowdefy/lowdefy https://github.com/lowdefy/lowdefy
  • panstromek 4y ago
    That looks pretty cool, I will look at that. I already had this idea many times (and I think anybody who done some web stuff must have had, too), but it always felt apart when you consider all edge cases you want to handle differently.
    • gervwyk 4y ago
      Thanks. Yeah, we’ve been building all kinds of things. Anything form dashboards, crud, public forms, ver advanced forms with complex validation and logic and even full MRP and CRMs. Of course there is an egde, for now it’s stuff like pub/sub, server oauth etc. But mostly seems like these edge cases can be supported as features later. It seems like the abstraction is working really well thus far, separating the business logic, into operator functions, from the app and backend stuff is really key to this. Really looking forward to the next phase where we get to create all nice programs tools in front of the program model to provide a superior dev ex :)
• graycat 4y ago
  Fundamental, foundational, unavoidable, overwhelming, invincible but just dirt simple truth: Please sit down for this. And may I have the envelope, please? Drum roll? ===>>> In computing, meaning is crucial. Computer source code doesn't mean anything. <<<=== Computer code obeys strict syntax rules, but those rules do not give meaning. So far, sorry 'bout this, essentially, to date, there is only one good and significant approach to meaning -- writing in a natural language, e.g., English. Did I mention, sorry 'bout that. In simple, blunt terms, in well written code, the comments which provide the meaning are more important, especially for maintenance, than the actual code that gets executed. Sorry 'bout that. Beyond that, beyond any doubt, far and away, in well done software, the most important part is the well written documentation. I should put this word documentation in all caps, ultra bold face, with flashing lights -- well written documentation. Sorry 'bout that. For my code for my startup, early on I wrote out some documentation in TeX, with the crucial core pure/applied math, data handling, etc. Then I wrote some notes about the code. The code is just awash in documentation, 100,000 lines of typing and 24,000 programming language statements. Right, on average 4 lines of typing for each programming language statement. I had some external events pull me off the work of my startup, but now I'm returning to it and finding my old documentation just crucial, terrific. Even though it is all my project and code, I still need all the documentation, and it works great -- let's me understand again right away. Don't believe me or argue with me. Instead, learn from D. Knuth who has demonstrated very well that he is really good with software. See what he did, and how and why, with his literate programming -- more like reading a book in English about something in engineering than just source code. Right, long many software projects at IBM and the US DoD went through stacks and stacks of layers of planning, requirements, specifications, ..., before any code was written. Then for any change, might have to go through the hundreds of pounds of paper of the documentation to get it up to date again -- a real pain, bottleneck, boat anchor to progress, etc. Right. Need a better way. But apparently their documentation process was too clumsy or some such. On the other hand, if the software is for an airplane and it is you who is going to fly on that plane, then maybe .... Net, the meaning is crucial, and the code doesn't mean anything. The meaning is in the documentation written in a natural language, e.g., English. Sorry 'bout that. One more point: We can try, but I see little hope soon. We can try to design a programming language with syntax so expressive that the meaning is automatically obvious and no more documentation is needed. Did I mention I see little hope soon? Sorry 'bout that.
• AnthonBerg 4y ago
  Dependently typed programming languages: * Solve a lot of these issues * Exist
• the_other 4y ago
  I stopped reading at this point: > We spend endless amounts of time bikeshedding the right syntax, indentation level, tabs vs spaces, or where to put code in the structure of files, but this all feels just pointless - these are all properties of text, but the text is just a tool to manipulate some abstract model of the program. No we don't spend endless time doing this. We automate as much of that as possible. I haven't cared about syntax for whitespace for years (I mean, I care and I have opinions, but I almost never have to work on it). One item from the list, which we can't automate, is a really important part of the job: "where to put code in the structure of files". This is an intrinsic part of the solution modelling. Often this is something you want to change as the project expands. What are the modules and objects of your application? What are their responsibilities? Does this new object now have responsibility for that thing over there? These are key questions to answer on a daily basis. I agree with the complaints against boilerplate. Boilerplate can help decide where a bit of code should live, but it also gets in the way when changing that decision is the best thing to do. We don't teach or celebrate refactoring enough (at least, not in the places and projects I've worked). Perhaps I should read more of the article...
• ChrisMarshallNY 4y ago
  I liked the section on testing[0]. I tend to write far more testing code, than the CuT, itself. Many of my various widgets have test harnesses that are, in and of themselves, full-fat, App Store-ready apps. I find test harnesses are generally better (for me), than unit tests[1]. I was just thinking about this, this morning. I'm what people refer to as a "crusty oldtimer." I wrote my first program (Machine Code) in 1983, so I've seen some changes in the landscape. These days, the general posture of many shops seems to be "Our programmers suck, and can't be trusted to write code güt." Sadly, this is not necessarily an inaccurate stance. It tends to result in highly defensive IT infrastructure and process, though, with heavy reliance on languages and strict, rote methodologies. I used to write a lot of code in C++. Nowadays, people seem to freak out, at the thought of writing in C++. It's entirely possible to write safe, performant code, in C++, but it isn't enforced by the language. The same for PHP, which I've used a lot. It's also quite possible for bad programmers to write truly nightmarish code in both languages. I know of which I speak, having written quite a bit of said "nightmarish" code. That's one of the reasons I write fairly good code, these days. The conventional wisdom seems to be that we need to rely on the tools (languages, IDEs, VCS, CI/D, etc.), to assure good code. That's fine, but it seems to stem from an unwillingness to invest in the most expensive component in a cubicle; the software engineer. This is a long, tiresome discussion, with no one willing to change their minds, so I'm not going to follow up on it. I did notice that this posture seemed to start in the mid-1990s. Before that, companies put ridiculous amounts of trust and investment in us. [0] https://yoyo-code.com/programming-breakthroughs-we-need/#testing-and-correctness https://yoyo-code.com/programming-breakthroughs-we-need/#tes... [1] https://littlegreenviper.com/miscellany/testing-harness-vs-unit/ https://littlegreenviper.com/miscellany/testing-harness-vs-u...
• danschumann 4y ago
  The future of programming probably resembles the holodeck on Star Trek, or minecraft redstone.
• w10-1 4y ago
  Programming is encoding: some reduction of reality into a model suited to algorithms doing what we need. The reduction to model and scope to algorithms are necessary and unavoidable. All of the criticisms made are objections to the selected model or limited set of algorithms. That includes text as the standard "model". By contrast, IBM VisualAge in the 1990's had a true AST-based model of the code, and showed text as views. It did (some) amazing things, but people hated it because there was no way to make it do other things they wanted. I would add the disparity between the granularity of commits and comments. Clearly, I should be able to describe specific changes in a file and provide high-level account of a long-running task without collapsing everything into one history. Proposal: A single AST model, configurable for multiple languages, with JVM & LLVM back-ends, and automagic support for IDE's via LSP and program transforms like language conversion, slicing, and aspects. The killer app there would be transforms for parallelism to the processor-specific vector instructions. That would capture more of the value of the oncoming onslaught of processor architectures.
  • galaxyLogic 4y ago
    One of the brilliant things about Smalltalk was its change-management. You didn't just store programs, you stored "changes" to existing programs which assumes a context of existing 'classes" into which such changes can be applied. Contrast that with current CVSes like git where you don't store changes to the objects you create or have created earlier, but just changes to which files exist in your (git-based virtual) file-system. Git only knows about things like "files" and "folders", not about objects the user creates. Therefore you can not view a git-repo as a set of changes to your "program", it is only a set of changes to files and folders.
    • ElectricalUnion 4y ago
      Git don't even know about "folders", it's just implied from file names stored in the git trees. https://git.wiki.kernel.org/index.php/GitFaq#Can_I_add_empty_directories.3F https://git.wiki.kernel.org/index.php/GitFaq#Can_I_add_empty... > Currently the design of the Git index (staging area) only permits files to be listed, and nobody competent enough to make the change to allow empty directories has cared enough about this situation to remedy it. > Directories are added automatically when adding files inside them. That is, directories never have to be added to the repository, and are not tracked on their own. > You can say "git add <dir>" and it will add the files in there. > If you really need a directory to exist in checkouts you should create a file in it. .gitignore works well for this purpose (there is also a tool MarkEmptyDirs using the .NET framework which allows you to automate this task); you can leave it empty or fill in the names of files you do not expect to show up in the directory.
• galaxyLogic 4y ago
  I've often thought about similar idea(s), the program is constructed out of nested components, almost like LEGOs. When we play with LEGOs we don't need a "programming language". Or do we? But what is a "language"? It is a set of "legos" of different types like 'verbs', 'nouns', 'adjectives' which can be combined in many different ways, but only according to the lego-rules of syntax. Some lego-pieces can not be combined together. The ways LEGOs can be combined is a "syntax definition" the designers at the LEGO headquarters came up with. LEGOS are a language. So I don't think it is possible to program computers without a programming language. Even configuration needs some kind of language to give you the flexibility you need.
  • sleepybrett 4y ago
    Lego created a visual programming language for their mindstorms system that is exactly this. It's very similar to scratch and while it lets you get things done and you can build some pretty amazing things with tools like that. The ... second order tooling... just isn't there. We have a huge amount of tools running around that can deal with code as text, but there are no analogous tools for these visual programming environments. I've dug into some of these tools in the past, wrote some projects using things in the 'creative coding' space like quartz composer, touch designer, vvv ... at a certain point the visual clutter gets you and, at least in my experience, it was just faster to rewrite in a creative coding framework like openframeworks/c++.
• mst 4y ago
  > If the text is just a view, it doesn't matter how it's written. Let everybody customize it the way they want. I don't care if you put opening brace on a new line, I don't even want to care. Interlisp did this.
• preseinger 4y ago
  > Program is not a text, [it is] a model I don't think so. In fact, I think this perspective is actively harmful. A program is whatever the human beings who maintain that program operate against. I mean there are many possible representations of a program, and there are different ways to evaluate those models, but the model that most precisely expresses the AST of the logic of the program, or the call sequence of the von Neumann execution of the program, or whatever else? These models are incidental. The thing that matters is whatever humans read and interpret and mentally model. And for the moment that's source code.
  • dleslie 4y ago
    Indeed, in a way the author is saying that the meaning is independent of the text; which, in literary circles, was once hotly debated. I land on the textual side of the line; the medium is as important to the meaning as the abstract concepts that might be components of it. Multiple tellings of the same story carry different meaning, sometimes subtly, when they are each one of oral, text, photo, painting, or film. I believe the same is true of programming. A solution in C is fundamentally distinct from a solution in ladder logic, or Haskell; even if they solve the same problem.
  • cultofmetatron 4y ago
    to add to that, this programming is a model is how we got smalltalk. a collection of interesting ideas from which its peripheral ideas got pillaged into other languages while leaving the core idea to just smalltalk.
  • ablob 4y ago
    How is it harmful? > A program is whatever the human beings who maintain that program operate against This does neither invalidate the statement that "Program is not a text", nor that "[it is] a model". > And for the moment that's source code. How is wanting to change that harmful? Source code can have flaws like ambiguity (see C++'s need for typename). Deeming a call for improvement on the existing representation of a program harmful is a fine way to stop any progress at all. We would still be putting in raw numbers into memory with that attitude. On another note: I think what matters is what the computer actually does. Whatever I, as a human, read and interpret has no meaning at all if the computer decides to "read and interpret" it differently. And the only limit with representing what the computer actually does should be your imagination.
• MiguelX413 4y ago
  > We spend endless amounts of time bikeshedding the right syntax, indentation level, tabs vs spaces, or where to put code in the structure of files, but this all feels just pointless - these are all properties of text, but the text is just a tool to manipulate some abstract model of the program. This is why I always use black for Python, cargo fmt, prettier, etc. for my code.
• rawgabbit 4y ago
  I find it interesting, there are no comments about the author's argument that programming today is inefficient as the most popular "model" are relational databases. "* I imagine this model as a relational database...it becomes clear that using a textual source code is really inefficient way to manipulate this model.*" It wasn't too long ago, object oriented programming, ORMs, and NOSQL was in fashion. I believe that was a dead end. I don't believe relational databases are the end all or be all either. What has stood the test of time is the double entry accounting transaction journal entry. In this model, the journal entry is the system of record. And you can have multiple distributed systems creating these entries at the same time. You collect and aggregate these entries to display the "balance" at a specific point in time. To me, this is what Kafka distributed logs powerful. Distributed logs builds on a proven concept.
• jimnotgym 4y ago
  What I want is VB6 yet using Python to script. I also want it to be cross platform. We used to write whole gui programs in an evening, compile and release them as an exe.
• callinyouin 4y ago
  The whole "program is a model" part makes me think of Smalltalk's image-based system. I never really got used to programming this way myself, but I do think an image-based environment might check some of the author's boxes. With the right tooling, a Lisp might even be a decent choice.
  • Qem 4y ago
    For those wishing to experiment what a current image-based development environment feels like, I recommend Pharo. Probably is the most advanced open-source development environment in the tradition of Smalltalk, available today. Main site: https://pharo.org/ https://pharo.org/ MOOC: https://mooc.pharo.org/ https://mooc.pharo.org/
    • garfieldnate 4y ago
      I tried to go through the Pharo mooc and learn a bit, but dealing with bugs and jank in an complex and unfamiliar UI made me drop the idea pretty quickly. The object orientation aspect of it was interesting, but I just can't get behind a language which is tied so deeply to the use of a poorly maintained UI. At a first glance I'm liking the approach offered by Unison, where you work with an image but everything you need can be done from the terminal, which I think is much easier to maintain and make portably. Creating a nice UI for it can be treated as a separate problem.
• alphanumeric0 4y ago
  "Software testing doesn't work".. and "No matter how hard we try, it just sucks." then the next sub-heading: "I want simpler testing". Okay, well, you just said it doesn't work, but you still want (simpler) testing?
• loquisgon 4y ago
  The essential complexity in today's coding is that code is created by humans. Therefore humans, we have to understand existing code bases to modify them and this is non-trivial. We also have to understand "what" needs to be built, that is the infamous "requirements". I think eventually coding will be automated away with artificial intelligence. I did not think like this for a long time in my career (that programming will be automated I mean) but neither I thought that computers would be able to create "deep fakes" and things like understanding & speaking human languages.
• jrvarela56 4y ago
  Something like Clojure inside Glamorous Toolkit (GTK) would make me a happy camper. The discussion about text is a moot point bc GTK makes it easier to create different visual representations of your code. Clojure makes it easier to keep code as either basic data types ([], {}) or functions without reaching for custom DSLs which OO defaults to. That and that everyone adopts it so there's plenty of libraries and a community :D. Seems like Clojure will get there with beefed up REPL workflows ala Calva/Portal. Community is amazing rn but tbd how it 10-100x (if ever).
• revskill 4y ago
  We do have. It's ReactJS, or component composition on the frontend. On the backend, it's nothing new. Just use functions and problem solved.
• Jeff_Brown 4y ago
  Does testing really suck, or is the problem that specifying and being even moderately sure your program actually does, what it's supposed to is hard?
• Lapsa 4y ago
  no ideas who this fella is and too lazy to look up his huge achievements. but I dislike the way he is thinking. I mean - it's already there. go and research Smalltalk stuff or something.
• infogulch 4y ago
  This is part of a comment I made on The State of State Machines (2021) [1] which is a Google Project Zero post about how complex state machines were exploited. > I feel like we will continue to run into these kinds of issues to the end of time unless can figure out: 1. How to precisely describe the properties we want the final system to have, 2. How to 'compile' from a higher-level language/layer into a lower-level language while maintaining all those properties. At the least this will require us to: 3. Define the precise semantics of each layer and enforce that every construction in and implementation of that layer adheres to it strictly. > Layers/languages should verifiably maintain these properties through every translation via paths like: eula/privacy policy, requirements, UX, UI, state machine, source code, AST, IR, ASM, machine code. Every one of these layers should have a well-defined execution model that is isomorphic with other layers, modulo metadata. For example: source code === AST [+ comment/whitespace/filesystem metadata], AST === IR [+ name/desugaring/applied-optimizations metadata]. All undefined behavior at every layer must be exterminated by definition or avoided by construction. [1]: https://news.ycombinator.com/item?id=25836398#25838252 https://news.ycombinator.com/item?id=25836398#25838252
• bambataa 4y ago
  Text does feel like a really slow way to work sometimes. A while ago in a React app I needed to keep some state around so lifted it from component state hooks to a context. Very mechanical work. It feels like we should be to say “move these to a context consumed by A, B, C” and just have it all done automatically. Is there anything inherent to React/JS that stops something like IntelliJ implementing that?
  • panstromek 4y ago
    > Is there anything inherent to React/JS that stops something like IntelliJ implementing that? Yes, actually. It's a problem for dynamic and weakly typed languages. IDE can't assume much properties about the program so it can't do many of the refactorings reliably. On top of that, React and many web frameworks build on some DSL (like JSX) and build-system specific project structure and source transforms that the IDE can't reason about very well. As a result, such refactorings often need to be implemented by the IDE for each specific framework separately. This is exactly the area where starting with a semantic model first would help a lot.
• bcheung 4y ago
  I've had very similar thoughts and have wrote about them here. I would be interested in discussing more. https://github.com/brennancheung/wasmtalk https://github.com/brennancheung/wasmtalk Some key takeaways from the above link: - The programmer's tool should be a tool for manipulating an annotated AST (not text) - There should be many different types of UX's for different scenarios, each maps to and from an AST in a UX that is optimal for the developer for that scenario - We must be conscious of human brain limitations and cognitive psychology and work within those constraints - "Reading" and "Writing" code should have different UX's because they are radically different use cases - Use RPN. It models the real world. Humans are designed to manipulate their environment in an incremental manner seeing the result each step of the way. When we have to plan out and write code for an extended period of time, trying to play compiler in our head, we overload our brain unnecessarily and highly likely to make simple mistakes. - Testing should be a first class citizen in the developer experience and indeed baked into how we develop at a fundamental level that it seems strange that they are even decoupled to begin with.
• steve76 4y ago
• mike_hearn 4y ago
  Here's a few thoughts on how to make strides towards what this guy wants, but with tools and features that largely exist today. RE: Boilerplate A significant amount of the boilerplate he talks about comes from the web stack not being designed for what we use it for. That leads to a need for a complex three tier architecture, ad-hoc app-specific protocols layered on top of HTTP, and then lots of ad-hoc logic to convert that protocol to and from the underlying database protocols. Consider how much less code you'd have in a two tier architecture that looks like this: 1. An app that runs on the user's machine, which connects directly to: 2. Your RDBMS, which knows about every user of your app and imposes security/privacy ACLs on them in the standard manner using views/row based security/etc. In this architecture there is no web server, no REST, no JSON, no JWTs, and therefore also entire classes of security bugs are eliminated in one go (XSS, XSRF, SQL injection, non-transactionality triggered race conditions etc). There are also no load balancers because your DB driver already knows how to do client side load balancing, and a variety of other advantages. When you need more than just standard SQL CRUD operations you write server side function plugins for your RDBMS in a language of your choice and let the DB protocol and servers act as an RPC protocol that happens to support batching, transactions, large result streaming/paging all built in. In effect the RDBMS itself becomes the application server. Today we don't build apps like this for a few different reasons, mostly related to the inconvenience of distributing desktop software outside a web browser. But that's solvable! And in fact my current project is a company that makes a tool that makes distributing desktop apps as easy as distributing web apps is [1]. With that and a technology like Kotlin Multiplatform + Jetpack Compose, or with JavaFX, you can write a single frontend app that runs on every desktop OS, Android and iOS (where you can write a custom SwiftUI GUI with shared business logic or re-use the Android UI code if you don't need pixel perfect native UI. There are a few other issues that are all also solvable e.g. tunneling DB protocols through proxies, OAuth/SSO integration, streaming code to the client etc. And as a pattern it really benefits from a powerful RDBMS. But once you have the foundation of brain-dead simple app packaging+signing+notarization from your laptop, with smooth auto update to clients, suddenly you have lots of options to massively simplify up and down the stack. RE: Text vs abstract code models. Another big win if you go this route is you suddenly have way more language freedom. The author talks about wanting a database to store his code, but then talks about Rust, for which IDE support is limited. If you use a language with really good IDE support like Kotlin or Java, then your IDE is building a database like the one he wants already. He says it's painful to query that DB but that really depends a lot on what you know and what languages you use. IntelliJ has a structural search+replace feature that lets you do example based queries, and it also has a console and plugins that let you do on the fly queries and structural changes by writing code against their PSI API. You don't have to write full blown plugins [2]. [1] https://www.hydraulic.software https://www.hydraulic.software [2] https://plugins.jetbrains.com/plugin/7282-liveplugin https://plugins.jetbrains.com/plugin/7282-liveplugin
• mpweiher 4y ago
  This resonates deeply with me (and my research project). 1. Glue code and boilerplate waste Yes, yes and yes! Glue code is the dark matter of software [1] My hypothesis is that the reason we have to write so much glue code, and that it's always sufficiently different is that we don't have the right architectural abstractions. Specifically, our programming languages only support (essentially) procedural abstraction (procedures, functions, methods). With Objective-S [2][3], I've been introducing language support for other architectural styles. It's been a slog, but recently things are starting to really click together, particularly the combination of "stores and streams" is very powerful and eliminates tons of boilerplate, often reducing it to the "connection operator" → Which not only happens to be very brief, it's also generic/polymorphic. 3. Why don't frameworks work? Also really very perceptive observations. Frameworks sort of work, but they tend to be limited by having to represent their domain in terms of procedural abstractions. 4. Non-textual code/modeling I don't think this is the problem. Modeling is a problem, but a large part of that is because the systems/models we need to build are non-procedural, and so our textual code can only be a meta-program or meta-system that then constructs the actual system. Which is not visible/present in the code we write, but only exists in the running system and in our heads. If we close that semantic gap, having that model expressed textually shouldn't be a huge problem. The problem is not the text, it's the wrong abstractions that our text expresses. 5. Testing Not sure the idea of generic testing is that useful, because the key to testing (for me) is its concreteness. That said we can reduce test friction a lot, I think. [4] 6. UI construction You don't need UI mockups and prototypes - you just program the real thing, because it's that simple. If the user doesn't like it, you can completely restructure it easily. Yes. I've seen a lot of mockup tools, and it always seemed obvious that writing the real UI should be just as easy (or easier). With NeXT's Interface Builder, we had a large part of that, but sadly Apple has had it languish so horribly that nowadays even imperative code is often preferable, and the fluent APIs such as SwiftUI or React, Flutter etc. seem vastly preferable, despite their deep flaws. [1] https://blog.metaobject.com/2021/06/glue-dark-matter-of-software.html https://blog.metaobject.com/2021/06/glue-dark-matter-of-soft... [2] http://objective.st http://objective.st [3] https://news.ycombinator.com/item?id=32444300 https://news.ycombinator.com/item?id=32444300 [4] https://blog.metaobject.com/2020/05/mpwtest-reducing-test-friction-by-going.html https://blog.metaobject.com/2020/05/mpwtest-reducing-test-fr...
• samsquire 4y ago
  I work on this problem everyday, I am at 450+ journal entries of thoughts from concurrency, parallelism, desktop environment behaviour and programmatic expression. (see my profile) I am working on the expression problem at this time.
• MarkSweep 4y ago
  RE: Program is a model There are some more advanced refactoring tools now available. These tools enable you to write code to detect bad code patterns and even automatically fix them. You can use them to write one-off transformations of code too. Rust has Dylint [1] and C# has Roslyn Analyzers [2]. Facebook has tooling [3] that helps writing CodeMods, enabling authors to generate changes for thousands of files at a time. The thing I really would like to see is a smarter CI system. Caching of build outputs, so you don't have to rebuild the world from scratch every time. Distributed execution of tests and compilation, so you are not bottle-necked by one machine. Something that keeps track of which tests are flaky and which are broken on master, so you don't have to diagnose spurious build failures. Something that only runs the test that transitively depend on the code you change. Automatic bisecting of errors to the offending commit. [1] https://github.com/trailofbits/dylint https://github.com/trailofbits/dylint [2] https://docs.microsoft.com/visualstudio/code-quality/roslyn-analyzers-overview https://docs.microsoft.com/visualstudio/code-quality/roslyn-... [3] one example: https://github.com/facebook/jscodeshift https://github.com/facebook/jscodeshift
  • EdSchouten 4y ago
    > The thing I really would like to see is a smarter CI system. Caching of build outputs, so you don't have to rebuild the world from scratch every time. Distributed execution of tests and compilation, so you are not bottle-necked by one machine. This is already achievable nowadays using Bazel (https://bazel.build https://bazel.build) as a build system. It uses a gRPC based protocol for offloading/caching the actual build on a build cluster (https://github.com/bazelbuild/remote-apis https://github.com/bazelbuild/remote-apis). I am the author of one of the Open Source build cluster implementations (Buildbarn).
• feoren 4y ago
  So, so much is misguided about this article. Yet, the opinions expressed are actually quite common, and I think represent some widespread and fundamental misconceptions about software development, so they're worth addressing. Apparently this comment was too long for HN, so I'll address the points individually in child comments to this one.
  • feoren 4y ago
    > Most code I write doesn't do anything interesting, it's either some boilerplate or glue for connecting subsystems together. That's your fault. There's not some line where "interesting code" lives on one side and "boring glue code" lives on the other. I agree that you don't want boring glue code, but you also don't want highly interesting code either! Every block of code should be "mildly interesting": doing about one interesting thing. Your job is to evenly spread the intrinsic complexity of the problem over code blocks to make this happen. If you're writing boring glue code that doesn't solve part of the problem interspersed with highly interesting code that handles 15 different cases, your code is lumpy! So many people talk about spending too long on boilerplate glue code, but you're stitching this part and that part of the code together for a reason -- for a reason that can be expressed in domain logic and user stories -- right? (If not, you truly are wasting your time, but that's only because that whole code block doesn't deserve to exist.) So express the reason for stitching that code together in the glue code, and now it's mildly interesting, just like all of your code should be. It blows my mind that the same people who complain about over-abstraction also complain about spending too long in the weeds of boilerplate code. You're so used to bad abstractions that you've given up, and then you whine "why can't I do this at a higher level!?" Because you've stopped trying, that's why! Learn to write better abstractions, and keep tweaking them when they become awkward. Finding a good abstraction is really hard, but absolutely worth it when it happens. And there are meta strategies you can learn to make it easier.
  • feoren 4y ago
    > Some projects try to package this into a single framework, but this approach doesn't always work either, because it necessarily introduces new generic mechanisms and complexity If the author doesn't want to have to learn "new generic mechanisms and complexity", then they'll certainly hate any huge breakthroughs in programming, because of course such a thing will come with lots of new generic mechanisms and complexity. The reason single frameworks always fail is because they are single. The combination of technologies and abstractions is as important (or moreso) than the individual technologies themselves, and those are decisions you need to be able to make and change independently. Use small libraries that are focused on doing one thing well, are mildly interesting, and can be tweaked or swapped out without impacting everything else in your code. Don't use "single frameworks". > A good hint is the recent GitHub Copilot development. Absolutely not! This is entirely the wrong direction! You still have bloated code that you need to test and maintain, but instead of it being your code, it's the code of some (literally) brainless intern who has an unbounded potential for stupid errors? All "scaffolded code" is doing what the compiler (or some abstraction) should be doing. Writing code the first time is the easiest part. Why do you want help with the easiest part, at the cost of making the hard part harder? > And yet, most of programmer's time is spent reading or planning how to change the code. Is the author really just another person who thinks that programmer productivity is based on the number of times they hit their keyboard? This is so off the wall that it threw me for a loop. You just complained about writing too much boilerplate, and you want people to think less and type more? This is insanity! The two most productive activities, by far, a software developer can do are: - Discuss the problem space with other programmers and experts with a whiteboard nearby - Stare out the window with the problem on your mind The author wants us to do less of this!?
• eternityforest 4y ago
  Glue code is used to piece together libraries. I think it's a sign you used the right libraries and aren't reinventing. It's boring, but glue code essentially describes why your project is not the same as every other apo using those libraries. Boilerplate is a thing that happens when libraries don't have sane defaults. It's one of the more unpleasant things about Docker et al. I wish we had a dev climate where something like Linux Standard Base could take off. I find frameworks to be perfectly fine, as long as you break out of the "Perfectly fit the code to the vision in my head" model and go for "How do I make this product using only these high level blocks I have, without modifying them". Frameworks are great as long as you don't fight them. Using a distro like Mint? Don't try to swap out core system services. Using a declarative web framework? Don't try to do some synchronous imperative stuff it was never meant to handle. I get the feeling a lot of programmers really value creative freedom and don't want to feel like they are playing a rail shooter, just coding the one obvious thing the opinionated tools tell them to do, and then they have a bad time when they use tools that were specifically designed to remove any need for interesting code.
  • mst 4y ago
    What do you have in mind when you talk about LSB for Docker?
    • eternityforest 4y ago
      A lot of why we have containers is to stop dependency hell, but having a stable platform to built on is another way to achieve that without containers at all. Of course it seems like the other reason we use them is to bundle multiple services together, but I'm not exactly a microservice fan to begin with. In any case, I don't see why we couldn't have an OS that makes debian packages into containers, sharing things that are needed by multiple containers as appropriate while allowing overrides. Android apps have a pretty nice model. If Android were a bit more open and had a few modifications to better support that use case, it seems like Dart/Android would make a pretty nice backend, assuming the ecosystem was there. Android proved the benefits of an extremely opinionated inside the box kind of system, making APKs run on Linux and Windows seems like it would have a ton of uses.
• tonymet 4y ago
  more investment is needed in code generation . the best platforms i’ve worked on had ample code generation tools eg to generate a API out of a spec
• Myrmornis 4y ago
  I think that a programming breakthrough that we need is better (graphical) formalisms for describing how software systems are intended to work. We can do better than drawing boxes and arrows with no clearly defined semantics. I don't mean formal models of how a program actually does work (i.e. I'm not talking about Petri Nets or CSP, although I'm not a computer scientist and couldn't tell you much about those things): what I'm talking about is a better language, or collection of visual formalisms, for referring to the components that we really _mean_ when we draw software designs using boxes and arrows. So something like UML, but that actually helps describe application/system function, rather than mind-numbingly documenting an OO codebase. There wouldn't necessarily be any connection between this and code (although you could perhaps imagine generating high-level automated tests from a description of how the system should work) -- the aim would simply be to have a more sophisticated way of communicating about how we intend or hope that our designs will work.
  • mayank 4y ago
    There's a hierarchical modeling paradigm/tools called C4 that (while being boxes and lines) helps with the zoom-in/zoom-out nature of understanding systems: https://c4model.com/ https://c4model.com/
    • Myrmornis 4y ago
      Thanks, I have seen that but never really looked into it. Have you found it useful?
• nathias 4y ago
  I think the breakthroughs we need is to program something else than just ad-serving machines.
• JoeAltmaier 4y ago
  So much right in that. In the old days we had compilers linkers and loaders. They all did the wrong thing. Compilers did text translation to semantics and generated code. The linker combined code from several sources and produced a loadable image. The loader checked for compatibility and relocated an instance to an address. Instead, the compiler should have stopped at semantics. The linker should combine semantic modules into an abstract execution model. The loader should generate code for the target machine at the target offset. We have some of that in different paradigms today. But still we transmit far too much of lame abstraction in large wads, with all the important semantics erased. Sigh.
  • 082349872349872 4y ago
    Or, one step up: The linker should combine semantic modules into an abstract set of cloud-deployable images. The loader should instantiate those images in the target cloud, with all their edges configured so the graph nodes connect properly. (physically connecting logical graph nodes having been exactly why the linker/loader were messing with offset relocation on single machines)
• jmull 4y ago
  The author wants to do away with the program as text source code but doesn't suggest another way to represent a program. You're going to have to perceive and manipulate your program in some way. Maybe it will be great to get rid of code, but then what will you have instead?
  • michelledepeil 4y ago
    I think you misinterpreted that. Their gripe wasn't with a textual representation of code, but the fact that we interact with it as text, not in any form. And that fundamentally limits the power of the tools we use to interact with it, according to the OP. Of course everything can have a textual representation eventually. Your final question, "what will you have instead?", really nails the point of the article, as that's basically what the author is asking (to be invented).
    • westoncb 4y ago
      I propose one solution here ("How to Make View-independent Program Models"): http://westoncb.blogspot.com/2015/06/how-to-make-view-independent-program.html http://westoncb.blogspot.com/2015/06/how-to-make-view-indepe... —but many people have tackled or are tackling this problem ("structure" or "projectional" editor will lead you there if you're curious).
  • aappleby 4y ago
    Plaintext is a serialization format for source code.
  • panstromek 4y ago
    > The author wants to do away with the program as text source code but doesn't suggest another way to represent a program. Quoting the article: > I imagine this model as a relational database - you have tables like `structs`, `fields`, `functions`, `arguments` and relationships between them. I really want something like that pretty specifically. We still use text to edit data in SQL database, but you can also use queries to view or manipulate it. That's the idea.
• richardfey 4y ago
  I disagree whole heartedly with everything written in this post..whoah. I am almost thinking this was written as a sort of provocative summary of what are *not* the software problems to solve.
• 7373737373 4y ago
  Access and Resource Security - I want to look at a program and be able to tell "this program will never be able to do/write/read X" at one glance. Encapsulation, capability security and metering all the way. Let every dependency be in its own sandbox, with the minimum rights it needs. We need a language that can do all that, without relying on another language to spin off more sandboxes (like WebAssembly which requires Javascript) and without overhead - one that supports "internal encapsulation" instead. And not an incomplete approach like Java either, instead create a VM that ensures a sandbox can never access anything external, unless it is explicitly imported/passed.
• ecopoesis 4y ago
  I would love to see a language that considers tooling a first class problem. Most (all?) languages barely consider complex projects with 100s of dependencies and large multi-step builds. Java shouldn't have to wait for Maven and Gradle to come along, and Python shouldn't be shackled to piss-poor systems like pip. This is something Rails gets very right. Bundler and Rake make Rails one of the nicest development environments there is. But we can and should do better. Why is DLL-hell still a thing? Imports should specify versions, defaulting to a default if none is specified. Languages barely even consider versions today, they are almost always hacked on via magic text strings in filenames. Why do tools like Dependabot and Renovate need to parse a million dependency formats to figure out versions? The language runtime or build system should produce that as a first class output. Deployment and documentation are other places most languages ignore and delegate to a variety of crappy external tools. Build Server Protocol is a good step in the right direction, but it barely scratches the surface. It would be great to see a language that prioritizes the parts of the developer experience that aren't writing code.
  • deleted 4y ago
    [deleted]
  • deleted 4y ago
    [deleted]
  • plafl 4y ago
    >But we can and should do better. Why is DLL-hell still a thing? Imports should specify versions, defaulting to a default if none is specified. Languages barely even consider versions today, they are almost always hacked on via magic text strings in filenames. So suppose you fix the version number when you import the library. You then need to copy paste the version number to other imports in your code base? Or maybe you mean each import may have different versions? which is all right until you need to pass some data between two versions of the same library. This wouldn't be so difficult if semantic versioning or another equivalent was respected, but we know it's a lie. This wouldn't be a problem at all if there were some kind of contracts in place when using modules/package/whatever instead of a silly number based on convention but how to specify the contracts is not that easy, and it's similar to say having static typing. I think improving versioning it's doable but it's very hard. I'm all about improving tooling, I have been obsessing for a few months about the sad state of program documentation and navigation. Why is the computer doing nothing while I think so hard while I'm programming? Why there is so little money in this space?
• guhcampos 4y ago
  I don't want to be too harsh but I think I strongly disagree with everything the author claims, and I've scrolled through the comments and found the criticism needs a touch. 1. Writing glue code and boilerplate is a waste / Why not use a framework? The author complains about boilerplate just to circularly complain about frameworks hiding "important details you care about". This, to me, denotes a failure to recognize some pretty basic trade-offs of any kind of development: you either create your own axioms and start something new or base your work on previous art by others. The more you want to customize, the less prior art you can use. He seems to want to "eat the cake and have it too". 2. Editing code in general doesn't work well / Program is not a text / Program is a model / Do we need a language? This section makes no sense to me. Everything is a language, whatever format he desires to abstract away all formats will need a language to be coded into. Language is a tool to convey meaning and achieve communication, it does not matter if it's text, pictures, sounds, whatever. It just so happens that written language is the single most ubiquitous communication method ever developed by humanity, and the formalization of syntax and semantics are there to reduce the ambiguity which is natural to natural language. The author seams to believe that we should achieve a single natural language that conveys meaning without ambiguity, or that some other form of communication can better represent the programmer intention than text. I would love to understand exactly how, because to me it seems like a pointless argument in the way it's presented. 3. Testing/Correctness / I want simpler testing Again, the author does not seem to understand WHY testing is difficult. To me, it's very obvious that testing is hard simply because 1. proving a complex system is hard and often impossible as we all learn in CS101 and 2. Testing itself requires conveying the meaning of the requirement correctly, and as with all communication there are always failures in this process. Once more the author seems to want a magic wand, ignore the trade-offs and, I don't know, fix all communication problems ever to have existed through human existence? 4. What is the vision? Finally, the author tries to force upon the reader an argument that everyone's perspective is wrong, that some sort of revolution is required - and possible - to make all these desires come true. I think this misses the point by such a long shot, like the good old Product Manager that "just wants things to be done and doesn't care how". I may be the one incapable of changing my perspective and thinking outside the box, but I have a feeling that if such a revolution was possible - and most importantly - unanimous - we'd had some glimpse of it already. Note how every single argument of the author is - to my interpretation - fundamentally tied to a communication problem. All the issues mentioned converge on difficulty to encode a message in such a way that it is interpreted correctly by the receiver, be it a machine or a person, in a unambiguous way. This problem is so much bigger than programming, so much bigger than engineering, so much bigger than Science. I'd argue that this is THE fundamental open problem of humanity, and believing that there is some sort of final solution is extremely naive.
• aappleby 4y ago
  Plaintext is a serialization format for source code.
• unmasked_poker 4y ago
  I solved this for me with a custom visual studio extension. It allows me to quickly specify a pattern that will create new code or change existing. The extension will show a so called Code Lens for each possibility to apply the pattern. This way for all the tasks I find my self doing over and over again I design the pattern as some kind of master and then apply it again and again on hundreds of locations in many projects. (some things I have solved this way: prisma schema, GraphQL resolvers, frontend code matching my backend API including full typings, ...). Saves me tons of work but I still have 100% controll over the code.
• fegu 4y ago
  It sounds like he needs to try Haskell, or strong typed functional in general. Less boilerplate, less testing, less worry when changing code later.
• akomtu 4y ago
  The #1 thing we need is a paradigm shift w.r.t complexity. We know that complexity, as the number ofvthongs you need to keep in mind to see the big picture, grows with the size of the project, but that growth varies greatly. A bad programmer writes code in such a way that complexity grows quadratically: it quickly crosses the threshold of being understandable by anyone and then the project is better to be redone. A decent programmer keeps the complexity linear by separating it into pieces with clear interfaces and behaviors. A great programmer can keep this growth sublinear, logarithmic maybe, but it's an art - this is what makes huge projects possible (linux, etc.) The paradigm shift would be a formal way to enforce low complexity growth, so even mediocre programmers can't f-k it up, similar to how syntax correctness is enforced. The #2 thing is documentation, which is in a very sad state right now: everyone writes boatloads of unstructured text that vaguely amd loosely explains something, and newcomers have to either parse this mess, or ask those who know for a digestible summary. This happens because text, the way we write it, poorly represents our thought models. We've learned to split text into words, words into paragraphs, and paragraphs into chapters, and we've even invented content tables, but all that isn't enough to deal with the enormous complexity of software we have today.
• teleforce 4y ago
  I'm surprised that the author did not even mention about GC and I think it's another programming breakthrough after structured programming. Currently GC for compiled languages like Go and D (optional) are considered as disadvantages rather than an advantages for high performance systems. Perhaps if we can get AI enabled GC that has good performance as manual memory management in C++ and Rust it will be a genuine breakthrough for modern programming languages.
• fleddr 4y ago
  I believe already some 2 decades ago Bill Gates said that the biggest failure in software is the lack of productivity gains in software development. Just to cherry pick a dramatized example. In the late 90s, one of my first programming experiences was in Delphi. It's a very visual way to program. You drag and drop a UI together from standardized elements. You could data bind things like input fields to a data source. You'd double click a button and it takes you to the already created "onclick" event where you do the actual coding. In a way, this is still similar to how you can "program" Microsoft Access today. In this same period (I was in a computer science study) I was moaning to my teacher how tricky programming in C was. I made tiny memory management errors crashing the entire PC, with zero debug output. His words: "Don't worry. By the time you get to work, you'll just do modeling". Now I work on the web. It's been 30 years since Delphi and instead of productivity gains, we've taken steps in the opposite direction. There is no standardized UI library. JavaScript has no standard library. There's no single unified architecture. There's no standard tool chain. It's all very low level after which we stitch together fragile semi-abstractions. I know it's an imperfect comparison, but I hope it gets the point across. It's all far too low level and fragile. This doesn't just hurt productivity, also accessibility. It's simply not beginner friendly.
  • thaumasiotes 4y ago
    > JavaScript has no standard library. >> Math.sin(1.57) 0.9999996829318346 This would be pretty surprising output if there were no standard library.
    • accountofme 4y ago
      I think the gp meant standard UI library...
      • thaumasiotes 4y ago
        There's a standard library for that, too, but it's not exactly high-level. https://developer.mozilla.org/en-US/docs/Web/API/Document/createElement https://developer.mozilla.org/en-US/docs/Web/API/Document/cr... At a higher level, that's pretty much what React is.
• visarga 4y ago
  The breakthrough is probably going to be a GPT-N model. It needs a few tweaks to be good enough - for example to be able to handle complex projects. The glue code is always going to be an impossible problem from the point of view of language design, can't standardise, every case is different in a different way. Only a human or a language model are flexible enough to adapt to this kind of variance. We're going to love our glue generator and won't be able to understand how we used to write that code by hand.
  • fullstackchris 4y ago
    Excellent. Asimov's "decay of empire" scenario approaches! (every living human eventually forgets how to repeat, or even interperet how the complex systems undergirding our entire society works, eventually rendering maintenance impossible)
• tomphoolery 4y ago
  I really love this point: https://yoyo-code.com/programming-breakthroughs-we-need/#program-is-not-a-text https://yoyo-code.com/programming-breakthroughs-we-need/#pro... In my day-to-day JavaScript programming adventures, I typically encounter issues around paths and how they're imported. There has been so much energy devoted to parsing a string and reading the file it (probably) points to, and we just assume that what we're importing from that file is actually what is in it. Maintaining all of my static imports in JavaScript feels like I'm doing something that a compiler or bundler should be doing, not a human being. Go has the right idea, it considers every file in the current directory to be part of the same package. This is really useful because you basically don't have to think about file importing anymore. I love being able to compartmentalize my Go programs without having to worry about updating a bunch of path imports all over the place. It lets me just focus on the code and sort out the organization later on when the project gets bigger. Of course, when the project _does_ get bigger, that's when you start having to grok how packages work and how they're built. This isn't a huge problem but it's definitely a learning curve that you don't necessarily need to overcome when you're first starting out, so it's a bit of a skill jump. I feel like there should be a programming language where the module system is deeply integrated with the package management system, and they are both baked into the language using syntax. This way, you can optimize those systems without disturbing how programs work, and the programs can specify what stuff they need from each package. Rather than deciding on some kind of folder/file convention for what a "module" is in your language, this one would put that responsibility on the programmer. A package would be defined by specifying its unique name, and the code that can be imported out of it. export package "fs" { export module File { export function read(path: string) { // ... } } } And then the `read()` function can be imported like this in your own app: import { File } from "fs" export package "my-app" { export module App export function start() { File.read("README.md") } } } You'd run this function on the command line by specifying it as your "entry point" like lang --run 'my-app#App.start()' Or, you can compile it into a program with lang --compile 'my-app#App.start()' --output ./app I don't know if a "registry" is really needed for these packages, as that might unnecessarily centralize the whole thing. Technically, since the language doesn't care at all about file paths, you can store packages however you want in your system. Literally `wget "https://github.com/some/pkg/releases/latest https://github.com/some/pkg/releases/latest" | gunzip` should be enough to start using the package, but of course having a CLI for managing this stuff will also be table stakes.
• cram0202 4y ago
  Programming is a bureaucracy. It is like saying "Fill form B7910-2A, go to room X830, get a stamp from the manager, get form H342...".
• mw888 4y ago
  I’m for reinvention, and if thinking radically is what it takes to make the more typical and known processes evolve, so be it. I do have skepticism about a model liberated from the text file - most tools fall back heavily on our use of language as our most powerful tool, the extent that a visual system like a UI replaces that usually represents equal constraints on what you can do. But constraints are what make programming languages great and easier to work with than machine code. If this boils down to a hierarchy of constraints the question that needs to be asked is “why are there so many different ways of constraining a program’s behavior” (via programming languages)? If there were only one way, much of the innovation wished for here, as abstract as it may be, would have probably already been worked on. Instead the base shifts constantly and the techniques for building changes everywhere. Sometimes I wonder why all of programming can’t boil down to C code. Python would first be translated to C, Rust would be an analysis engine for C, etc. It is elitist to make programming a meta language and field of study just to understand and use effectively, even if not consciously done. The lack of standardization, compared to what could be, drives this complexity. You’ll know programming has revolutionized again when an order of magnitude more people can do it without dedicating chunks of their life to it.
• magarnicle 4y ago
  I can't find the article now, but I remember reading about SecDB and comparing it to programming in traditional languages. The point that stuck with me is that the software industry has spent decades taking other industry's data and lifting it from flat files into databases, yet our own code is still in flat files.
• stephc_int13 4y ago
  Good luck trying to create something more powerful and versatile than text to create programs. Text is a seemingly basic, simple and even crude format. Ancient, outdated even? My opinion is that our perception about the simplicity of text is related to Moravec's Paradox, and is an illusion. Reading and writing text is something we take for granted, but this is a skill we all have to painfully learn at a young age, and we're so good at it that it seems transparent. Text is very abstract, the fact that we, humans, are trained to easily parse and decipher it is the reason why it is so powerful for us. I don't see any replacement in the foreseeable future.
  • spartanatreyu 4y ago
    I think you would be very interested in the experiments and results shown here: https://dion.systems/blog_0001_hms2020.html https://dion.systems/blog_0001_hms2020.html Dion Systems were working on changing the format of text to an AST format, that can be represented in different forms of text as needed, and the changes and implications it creates for developers. I think I heard that these developers are now working for Epic on a new programming system replacing the node-based blueprint programming system (think Scratch) for UE5 (probably using an ast based programming system that can be viewed in different text/node forms).
    • stephc_int13 4y ago
      Well, I've seen this before, and I think this is misguided. I wish them good luck with their effort.
  • quickthrower2 4y ago
    This is true. Especially for programming where you can be asked to do anything at all that is computable. If you massively limit the scope then Excel is a fine interface. Try making blogging software in Excel though. Do lawyers have want to move away from text and to something better? No. But for simple rules you can do no wordy things, like a no smoking sign or a locked door to indicate a rule. Formatting issues can be resolved by using an autoformatter. Tools can be made to visualise the code too.
• Invictus0 4y ago
  This feels like "how can mirrors be real if our eyes aren't real" but applied to programming languages. It literally reads like fever dream nonsense.
• andrewstuart 4y ago
  I'd like to see: the concept of the network should become tightly integrated - I should not have to jump through hoops to send network requests and evaluate their responses handling errors should be extremely standardised in such a way that the programming language defines how it is done and all programming languages do it the same way a programming language like Rust - inherently safe to do sophisticated multithreaded low level coding, guaranteed ot be memory safe and guaranteed not to have race conditions, but without the complexity of Rust a programming language dramatically better at team coding - the idea of microservices is a terrible way of solving this problem an internet that is type safe from top to bottom and all the type safety is the same typing system or at least compatible -all data and applications should talk through a ubiquitous type safe way of communicating a much more obvious way, perhaps visual, of connecting data/functions/interfaces together - the typing systems I describe above should make it possible to just click code together
• xupybd 4y ago
  I feel like Scott Wlaschin has helped me overcome some of these problems with his book (https://www.bookdepository.com/Domain-Modeling-Made-Functional-Pragmatic-Programmers-Scott-Wlaschin/9781680502541 https://www.bookdepository.com/Domain-Modeling-Made-Function...) It's not perfect but defining your types so it's hard to get into error states is amazing. https://fsharpforfunandprofit.com/posts/designing-with-types-more-semantic-types/ https://fsharpforfunandprofit.com/posts/designing-with-types... It's like having database constraints but at compile time.
• indymike 4y ago
  Programming has always been making really detailed instructions that tell machine what to do. The article could have been written in 1989, 1995, or 2005 and really been materially the same. Glue code, boilerplate, tests, frameworks, languages, and maintaining existing code all things that developers complain about. All things waiting for the next magical solution... We largely build software the same way with the same tools (I'm looking at an Emacs window). One line at a time (or one boilerplate paste at a time). It's been decades since I sat down with Turbo C and discovered the ID, and decades since I drew my first UI on a NeXT Cube. Decades since Java, Python and C#. We've never found a way to program at a higher level - we're still stuck processing strings, parsing text, formatting text... all these little details that make it really hard to work at a higher level of abstraction. And all little details where each developer does it just enough differently that we can't be sure what our code really does... I guess that is how job security works.
  • 082349872349872 4y ago
    > We've never found a way to program at a higher level Compare 1950-1970 with 1980-now. We found a way to program at a higher level then; why shouldn't we be able to now?[0] In the meantime, as a minor win, I'll note that most of my $WORK codebases in the XX were heavy on pointer[1] manipulation, while very few of them are in the XXI. [0] let's hope the gap between structured programming and its replacement is not going to be as long as that between Euclid and Lobachevsky! [1] "pointers are the goto of data structures" (bastardized Tony)
• AtlasBarfed 4y ago
  I think the biggest waste is lack of interoperability and usablity of libraries and code between languages. There is SO MUCH CODE out there. To some degree that is a bad thing, but there are genuinely good libraries in other languages that would be nice to more seamlessly utilize in other languages. Generally, there isn't a "best of breed" movement to actively track which implementations and approaches to things (json deserialization/serialization, http client, regular expressions, high speed I/O, algorithms and data structures. Instead, good approaches organically move around, or are at the whim of the steward of a language recognizing and pushing for some new language, approach, etc. Often good approaches or libraries or interfaces are shut out from another ecosystem over nothing more than dogma or reactionary hated in the worst case. Instead, if one language gets a good library, you either interface at the OS level or you have to migrate to that language if the library is that critical. The JVM was close to this, with Jython, JRuby, Javascript, Groovy, Clojure, and lots of other languages runnable within JVM code. Ultimately, notably Ruby where the JVM was the fastest runtime for Ruby for a time, rejected that approach. But I think it was the right approach fundamentally, if the politics got in the way. LLVM may have that potential, but it seems to tied to compilerland. OS-level interop seems generally a failure, either because of OS balkanization or other concerns.
• loh 4y ago
  > Writing glue code and boilerplate is a waste > Why not use a framework? These 2 sections highlight exactly the problems I've been trying to solve with Molecule.dev. I agree with the author that software development has somewhat stagnated, and I believe something like Molecule.dev is the future. It isn't perfect and there's still a lot of work to be done, but I'm certain it's headed in the right direction. The codebase is currently in the process of being repackaged (it'll be an MIT licensed monorepo) so that developers can more easily play with it, and so that it can be more easily integrated into existing systems, as starter apps are not a frequent enough problem to build a scalable business from. This repackaging is taking longer than normal because all the investors I've spoken to apparently don't see the value in it (yet), so I've been looking for contract work to stay afloat. (Know anyone?) > Testing and Correctness > I want simpler testing I built something else in early 2020 to address this exact problem as well, TestFront.io. I haven't touched it in a while (so don't sign up) but I may return to it eventually. It's open source. I've tried many testing tools/frameworks and none of them quite do what TestFront.io does. There is a pretty similar tool which someone turned into a very successful business (actually can't remember the name of it now), so there's definitely some value in it, but from what I saw when trying it, it's still not quite up to par with TestFront's granularity and ease-of-use. I'd like to return to TestFront some day, but for now there are bigger fish to fry.
• vineek 4y ago
  Very nice article. Literate programming might have some interesting features in this direction. The not so obvious thing is how it can scale. A very good example of literate programming can be found in the fantastic book Physically Based Rendering [1]. It also has a preface discussing it [2]. The authors write a full physically-based rendering system in a declarative fashion. This approach has also led to a nicely adapted web-based version of the book [3]. Although we have successful examples like TeX and HTML, it would be very interesting to see this approach explored further by a more modern language or programming methodology. [1] https://pbrt.org/ https://pbrt.org/ [2] https://www.pbr-book.org/3ed-2018/Introduction/Literate_Programming https://www.pbr-book.org/3ed-2018/Introduction/Literate_Prog... [3] https://www.pbr-book.org/3ed-2018/contents https://www.pbr-book.org/3ed-2018/contents
• thoweuri2343 4y ago
  Most of these problems were solved by Lisp-machines.
• garfieldnate 4y ago
  >IntelliJ helps you with things like "extract parameter" or "inline function", but I wanted to do stuff like... In the same vein as the developments around LSP, TreeSitter, etc. I had the idea that one could create a scripting language dedicated to refactors. The language would make it simple to talk about the AST of your programming language and provide simple primitives for safely transforming it. Doing this in a language-agnostic way is pretty difficult, though. There seems to be some discussion among the LSP folks here (https://github.com/microsoft/language-server-protocol/issues/61 https://github.com/microsoft/language-server-protocol/issues...) but no resolution. It's worth thinking about!
• bshanks 4y ago
  This paper might be of interest: David Harel, Guy Katz, Rami Marelly, Assaf Marron. Wise Computing: Towards Endowing System Development with True Wisdom https://arxiv.org/abs/1501.05924 https://arxiv.org/abs/1501.05924 It describes an idea called "wise computing" or "behavioral programming" which i'm not sure that i fully understand, but it sounds like the idea is to allow IDEs to help more, via additional formal reasoning about code in the manner of an expert system AI.
• urthor 4y ago
  > I imagine this model as a relational database - you have tables like structs, fields, functions, arguments and relationships between them. When you think about it this way, it becomes clear that using a textual source code is really inefficient way to manipulate this model. It's very error-prone and requires tons of additional processing. See Kent Beck shaking with rage at the passing of Smalltalk.