-
I have zero interest in Dolphin as a user, but man do I enjoy most of their technical articles about the problems and solutions they encounter. Particularly the issues emulating older integer GPU tech using modern floating-point GPUs https://dolphin-emu.org/blog/2014/03/15/pixel-processing-problems/ https://dolphin-emu.org/blog/2017/07/30/ubershaders/
-
A realization I recently had:
Why don’t we abstract away all display affordances from a piece of code’s position in a file? That is, the editor reads the file, parses its AST, and displays it according to the programmer’s preference (e.g., elastic tabstops, elm-like comma-leading lists, newline/no-newline before opening braces, etc). And prior to save, the editor simply runs it through an uncustomized
prettierfirst.There are a million and one ways to view XML data without actually reading/writing pure XML. Why not do that with code as well?
-
-
And once you take it a step further, it’s clear that it shouldn’t be in a text file in the first place. Code just isn’t text. If you store it as a tree or a graph in some sort of database, it becomes possible to interact with it in much more powerful ways (including displaying it any way you like). We’ve been hobbled by equating display representation with storage format.
-
This talk touches on this issue, along with some related ones and HCI in general: Bret Victor: The Future of Programming
-
God, I have been trying to recall the name of this talk for ages! Thank you so much, it is a great recommendation
-
-
Text is great when (not if) your more complicated tools fail or do something you can’t tolerate and you need to use tools which don’t Respect The Intent of designers who, for whatever reason, don’t respect your intent or workflow. Sometimes, solving a problem means working around a breakage, whether or not that breakage is intentional on someone else’s part.
Besides, we just (like, last fifteen or so years) got text to the point where it’s largely compatible. Would be a shame to throw that away in favor of some new AST-database-thing which only exists on a few platforms.
-
I’m not sure I get your point about about intent. Isn’t the same already true of, say, compilers? There are compiler bugs that we have to work around, there are programs that seem logical to us but the compiler won’t accept, and so on. Still, everybody seems to be mostly happy to file a compiler bug or a feature request, and live with a workaround for the present. Seems like it works well enough in practice.
I understand your concern about introducing a new format but it sounds like a case of worse-is-better. Sure, we get a lot of convenience from the ubiquity of text, but it would nevertheless be sad if we were stuck with it for the next two centuries.
-
-
I’ve never seen anyone casually swap out the compiler for production code. Also, for the longest time, if you wrote C++ for Windows, you pretty much had to use the Microsoft compiler. I’m sure that there are many embedded platforms with a single compiler.
If there’s a bug in the compiler, in most casss you work around it, then patiently wait for a fix from the vendor.
So that’s hardly a valid counterpoint.
-
-
Yes, I’m aware of that, but what does it have to do with anything I said?
EDIT: Hey, I went to Canterbury :)
-
“I’ve never seen anyone casually swap out the compiler for production code” sounded like you were saying people didn’t tend to compile the same production code on multiple compilers, which of course anyone that compiles on windows and non-windows does. Sorry if I misinterpreted your comment!
My first comment is in response to another Kiwi. Small world. Pretty cool.
-
-
-
-
-
-
-
This, this, a thousand times this. Text is a good user-interface for code (for now). But it’s a terrible storage and interchange format. Every tool needs its own parser, and each one is slightly different, leaving begging the amount of cpu and programmer time we waste going from text<->ast<->text.
-
Yeah, it’s obviously wasteful and limiting. Why do you think we are still stuck with text? Is it just sheer inertia and incrementalism, or does text really offer advantages that are challenging to recreate with other formats?
-
The text editor I use can handle any computer language you can throw at it. It doesn’t matter if it’s BASIC, C, BCPL, C++, SQL, Prolog, Fortran 77, Pascal, x86 Assembler, Forth, Lisp, JavaScript, Java, Lua, Make, Hope, Go, Swift, Objective-C, Rexx, Ruby, XSLT, HTML, Perl, TCL, Clojure, 6502 Assembler, 68000 Assembler, COBOL, Coffee, Erlang, Haskell, Ocaml, ML, 6809 Assembler, PostScript, Scala, Brainfuck, or even Whitespace. [1]
Meanwhile, the last time I tried an IDE (last year I think) it crashed hard on a simple C program I attempted to load into it. It was valid C code [2]. That just reinforced my notion that we aren’t anywhere close to getting away from text.
[1] APL is an issue, but only because I can’t type the character set on my keyboard.
[2] But NOT C++, which of course, everybody uses, right?
-
To your point about text editors working with any language, I think this is like arguing that the only tool required by a carpenter is a single large screwdriver: you can use it as a hammer, as a chisel, as a knife (if sharpened), as a wedge, as a nail puller, and so on. Just apply sufficient effort and ingenuity! Does that sound like an optimal solution?
My preference is for powerful specialised tools rather than a single thing that can be kind of sort of applied to a task.
Or, to approach from the opposite direction, would you say that a CAD application or Blender are bad tools because they only work with a limited number of formats? If only they also allowed you to edit JPEGs and PDFs, they would be so much better!
To your point about IDEs: I think that might even support my argument. Parsing of freeform text is apparently sufficiently hard that we’re still getting issues like the one you saw.
-
I use other tools besides the text editor—I use version control, compilers, linkers, debuggers, and a whole litany of Unix tools (grep, sed, awk, sort, etc). The thing I want to point out is that as long as the source code is in ASCII (or UTF-8), I can edit it. I can study it. I might not be able to compile it (because I lack the INRAC compiler but I can still view the code). How does one “view” Smalltalk code when one doesn’t have Smalltalk? Or Visual Basic? Last I hear, Microsoft wasn’t giving out the format for Visual Basic programs (and good luck even finding the format for VB from the late 90s).
The other issue I have with IDEs (and I will come out and say I have a bias against the things because I’ve never had one that worked for me for any length of time without crashing, and I’ve tried quite a few over 30 years) is that you have one IDE for C++, and one for Java, and one for Pascal, and one for Assembly [1] and one for Lua and one for Python and man … that’s just too many damn environments to deal with [2]. Maybe there are IDEs now that can work with more than one language [3] but again, I’ve yet to find one that works.
I have nothing against specialized tools like AutoCAD or Blender or PhotoShop or even Deluxe Paint, as long as there is a way to extract the data when the tool (or the company) is no longer around. Photo Shop and Deluxe Paint work with defined formats that other tools can understand. I think Blender works with several formats, but I am not sure about AutoCAD (never having used it).
So, why hasn’t anyone stored and manipulated ASTs? I keep hearing cries that we should do it, but yet, no one has yet done it … I wonder if it’s harder than you even imagine …
Edited to add: Also, I’m a language maven, not a tool maven. It sounds like you are a tool maven. That colors our perspectives.
[1] Yes, I’ve come across several of those. Never understood the appeal …
[2] For work, I have to deal with C, C++, Lua, Make and Perl.
[3] Yeah, the last one that claimed C/C++ worked out so well for me.
-
For your first concern about the long term accessibility of the code, you’ve already pointed out the solution: a defined open format.
Regarding IDEs: I’m not actually talking about IDEs; I’m talking about an editor that works with something other than text. Debugging, running the code, profiling etc. are different concerns and they can be handled separately (although again, the input would be something other than text). I suppose it would have some aspects of an IDE because you’d be manipulating the whole code base rather than individual files.
Regarding the language maven post: I enjoyed reading it a few years ago (and in practice, I’ve always ended up in the language camp as an early adopter). It was written 14 years ago, and I think the situation is different now. People have come to expect tooling, and it’s much easier to provide it in the form of editor/IDE plugins. Since language creators already have to do a huge amount of work to make programs in their languages executable in some form, I don’t think it would be an obstacle if the price of admission also included dealing with the storage format and representation.
To your point about lack of implementations: don’t Smalltalk and derivatives such as Pharo qualify? I don’t know if they store ASTs but at least they don’t store text. I think they demonstrate that it’s at least technically possible to get away from text, so the lack of mainstream adoption might be caused by non-technical reasons like being in a local maximum in terms of tools.
The problem, as always, is that there is such a huge number of tools already built around text that it’s very difficult to move to something else, even if the post-transition state of affairs would be much better.
-
Text editors are language agnostic.
I’m trying to conceive of an “editor” that works with something other than text. Say an AST. Okay, but in Pascal, you have to declare variables at the top of each scope; you can declare variables anywhere in C++. In Lua, you can just use a variable, no declaration required. LISP, Lua and JavaScript allow anonymous functions; only the latest versions of C++ and Java allow anonymous functions, but they they’re restricted in that you can’t create closures, since C++ and Java have no concept of closures. C++ has exceptions, Java has two types of exceptions, C doesn’t; Lua kind of has exceptions but not really. An “AST editor” would have to somehow know that is and isn’t allowed per language, so if I’m editing C++ and write an anonymous function, I don’t reference variables outside the scope of said function, but that it can for Lua.
Okay, so we step away from AST—what other format do you see as being better than text?
-
I don’t think it could be language agnostic - it would defeat the purpose as it wouldn’t be any more powerful than existing editors. However, I think it could offer largely the same UI, for similar languages at least.
-
And that is my problem with it. As stated, I use C, C++ [1], Lua, Make and a bit of Perl. That’s at least what? Three different “editors” (C/C++, Lua/Perl (maybe), Make). No thank you, I’ll stick with a tool that can work with any language.
[1] Sparingly and where we have no choice; no one on my team actually enjoys it.
-
-
Personally, I’m not saying you should need to give up your editor of choice. Text is a good (enough for now) UI for coding. But it’s a terrible format to build tools on. If the current state of the code lived in some sort of event-based graph database for example, your changes could trigger not only your incremental compiler, but source analysis (only on what’s new), it could also maintain a semantic changelog for version control, trigger code-generation (again, only what’s new).
There’s a million things that are currently “too hard” which would cease to be too hard if we had a live model of the code as various graphs (not just the ast, but call graphs, inheritance graphs, you-name-it) that we could subscribe to, or even write purely-functional consumers that are triggered only on changes.
-
-
-
-
-
-
Inertia, arrogance, worse-is-better; Working systems being trapped behind closed doors at big companies; Hackers taking their language / editor / process on as part of their identity that needs to be defended with religious zeal; The complete destruction of dev tools as a viable business model; Methodologies-of-the-week…. The causes are numerous and varied, and the result is software dev is being hamstrung and we’re all wasting countless hours and dollars doing things computers should be doing for us.
-
I think that part of the issue is that we haven’t seen good structured editor support outside of Haskell and some Lisps.
Having a principled foundation for structured editor + a critical mass by having it work for a language like Javascript/Ruby, would go a long way to making this concept more mainstream. After which we could say “provide a grammar for favorite language X and get structured editor support!”. This then becomes “everything is structured at all levels!”
-
I think it’s possible that this only works for a subset of languages.
Structured editing is good in that it operates at a higher level than characters, but ultimately it’s still a text editing tool, isn’t it? For example, I think it should be trivial to pull up a list of (editable) definitions for all the functions in a project that call a given function, or to sort function and type definitions in different ways, or to substitute function calls in a function with the bodies of those functions to a given depth (as opposed to switching between different views to see what those functions do). I don’t think structured editing can help with tasks like that.
There are also ideas like Luna, have you seen it? I’m not convinced by the visual representation (it’s useful in some situations but I’m not sure it’s generally effective), but the interesting thing is they provide both a textual and a visual representation of the code.
-
-
-
-
-
Smalltalk. The word you’re looking for is Smalltalk. ;)
-
-
Possibly, but I’m only talking about a single aspect of it: being able to analyse and manipulate the code in more powerful ways than afforded by plain text. I think that’s equally possible for FP languages.
-
-
-
Ultimately I think this is the only teneble solution. I feel I must be in the minority in having an extreme dislike of columnar-style code, and what I call “white space cliffs” where a column dictates a sudden huge increase in whitespace. But I realize how much it comes down to personal aesthetics, so I wish we could all just coexist :)
-
Yeah, I’ve been messing around with similar ideas, see https://nick.zoic.org/art/waste-web-abstract-syntax-tree-editor/ although it’s only vapourware so far because things got busy …
-
-
You can’t convert to elastic-tabstop style from that, and without heavy language-grammar knowledge you can’t do this for 4-space “tabs” generally.
Every editor ever supports this for traditional indent style, though: http://intellindent.info/seriously/
-
To be clear, you can absolutely render a file that doesn’t have elastic tabstops as if it did. The way a file is rendered has nothing to do with the actual text in the file.
It’s like you’re suggesting that you can’t render a file containing a ton of numbers as a 3D scene in a game engine. That would be just wrong.
Regardless, my point is specifically that this elastic tabstops thing is not necessary and hurts code readability more than it helps.
The pefantics of clarifying between tabs and tabstops is a silly thing as well. Context gives more than enough information to know which one is being talked about.
It sounds like this concept is creating more problems than it solves, and is causing your editor to solve problems that only exist in the seveloper’s imagination. It’s not “KISS” at all, quite the opposite.
-
-
-
Because presentation isn’t just a function of the AST. Indentation usually is, but alignment can be visually useful for all kinds of reasons.
-
-
I’m torn between thinking it’s terrible how much digital history we’ve lost already, and thankful that we’re not carrying forward even more crap than we already are.
Sometimes, impermanence itself should be part of a thing. Think of a sand mandala, or the burning man. It exists only to be lost.
-
-
That’s hardly the point I was trying to make. But think about how many times you’ve waxed nostalgic about something from your childhood, only to re-watch / re-play it and it turns out to be shite, and now you no longer enjoy those old memories?
-
I love that! It’s the only true opportunity for me to experience anything like what it’s actually like inside the mind of a different person. (Some people with MPD experience remembering “someone else’s memories”. I’m just a little bit envious…)
But I’m guessing that again misses the point you were going for?
-
-
-
-
This is super-interesting, I can’t wait for support to roll out to more browsers.
-
Obligatory Rich Hickey https://www.youtube.com/watch?v=34_L7t7fD_U
-
Doesn’t seem to be a lot of content here. Right now if you wanted to move away from Intel for whatever reason, the only viable choice for the
{x}Prolines isn’t ARM, it’s Power. And there’s no way they’re going to do that. There’s also no way in hell Apple will allow the Mac line to fragment into two separate architectures unless they’re 100% compatible. Fat (or mostly-compiled) binaries and identical frameworks would be the order of the day.In addition to that, I don’t know if anybody’s noticed but they’re pretty clever over at Intel. I’ve yet to see anything resembling a proof that ARM scaled up to compete with 86/Power for processing would still retain its power (as in watts) advantage.
My prediction remains: The cheap machines will go ARM, and soon (by mid-2020). Apple has emulated CPUs smoothly before, and Windows 10 does it now. The Pro machines will not (for a few years at least), although I wouldn’t be surprised to see Apple make their own GPUs for them, and to possibly even slap 4-or-5-ipads’ worth of ARM+GPU into the Mac Pro (as co-processors) for GPGPU loads. Jobs that are “embarrassingly parallel” are the kind of things you want to run with a pro machine, but you won’t give up single-threaded performance that only deeply pipelined complex CPUs like 86 and Power can give you.
-
-
There’s no way they don’t already have a full build for ARM hidden away somewhere, and probably still maintain one for Power as well, just to keep the code portable. They had it running secretly on Intel for years before they switched.
-
-
-
-
I think the author would benefit from looking at Quorum which was designed with syntax and semantics chosen based on research into what made languages easier or harder for people to learn (see: https://quorumlanguage.com/evidence.html).
There haven’t been many attempts at reproducing the results that were used to drive the design of the language, but it still seems like a more worthwhile starting place than COBOL and english grammar.
-
I didn’t know about this, chur!
-
-
Everybody I work with is a “full stack engineer” in the sense meant by this. And that applies to just about every team I’ve been on since I started working.
-
Leaving aside the difficulties of actually reading code in “natural language” programming models, even if one were to master such, at some point you’re going to need to do something that hasn’t been defined in your nice cosy universe, and you’ll have to learn the implementation language underneath– but you’ll have almost no skills that are transferable, it’ll be like having to start all over again.
-
When the author mentions OO:
There’s a very specific poor design at the core of the whole, well, not concept in the abstract, but ideology as practiced.
I can’t resist myself to refuse the notion of OO ideology. What does ideology even mean here? Let me guess:
If one tries to understand the theory behind OO, and fails, and applies some of the ideas in an apparant chaotic way that resemblences it.
But this, in my opinion, happens with most things one tries to learn. No blaim to the student, for he is only interested in learning more!
Let me close with a poem:
Object-orientation without subclasses is like functions without arguments.
-
Inheritance is not important for OO programming at all. It’s about substitutability, and if done the way it was originally intended, message passing.
-
Inheritance and subclassing are different. In inheritance, one imposes a constraint declaratively (say, “these objects must be a subclass of other objects”) and that can be done, often without any verification what so ever. Subclassing, in contrast, just exists even if one would not explicitly implement it. Consider:
The expected object was Y, now we substitute for some object X. This substitution only makes sense when X is compatible with Y.
There exists a compatibility relation between Xs and Ys, let’s call it the “compatible” relation.
If X is compatible with Y, and Y is compatible with Z, then X is compatible with Z. Every X is compatible with itself. There exists the most compatible object (say, nil, that can always be substituted). There exists the least compatible object (say, the empty object, which is compatible only with itself).
Just from substitution, we arrive at subclassing: our “compatible” relation now takes place of subclassing. This does not have to be checked by a compiler, it could equally persist only in the programmers’ mind.
Consider how subclassing works differently for: languages with inheritance declarations, algebraically typed languages (cf. coercions), un(i)typed languages.
One can also argue that the notion of “compatibility” only makes sense whenever one works with errors. Again, errors can be kept implicit or explicitly declared as exceptions. Without errors, every object could be substituted for another, and everything is compatible!
Why do I call them classes of objects and not just sets of objects? Technical, mathematical terminology: objects are non-well-founded, non-hereditary, graph-like constructions, while most people assume set theory to be well-founded, hereditary, tree-like.
-
-
-
Related: I was thinking about playing some meat-space solitaire recently, and I remembered that I had a pack of these lying about I’d bought ages ago: https://www.areaware.com/products/solitaire-cards?variant=14622412804 I really like them, although the pixellated corners feel terribly odd in your hands.
-
TL/DR: Data warehousing.
-
-
This. I have a good amount of experience writing C code and maintaining larger C applications, and C can be a real pain to deal with. Not to mention that it exposes a whole host of nasty security vulnerabilities. Finally, it seems a bit too low-level for these kinds of applications. I’m very confused by the choice of C here.
-
I’m guessing it’s because C is the main API for SQLite? I do I agree that C is an interesting choice here, maybe something more like Lua?
-
-
-
you can pledge your way out of it,
You can’t. Their kernel and firmware still processes network-facing data. It might still do damage. How much is an unknown until the setup gets the kind of rigorous pentesting we see on Windows, Chrome, the SFI schemes, and recently x86 CPU’s. It does have a nice security by obscurity benefit on top of methods that provably increase work for attackers.
-
-
There’s no string manipulation in HTTP servers, right?
Right?
-
-
Ow, my brain!
Very interesting post, although I was hoping it would be about analog systems.
-
Huh, I didn’t realize the 8086 only had a 20 pin address bus. Makes everything seem a bit more sane, although why make the segments overlap? I can’t see the benefit and it makes expanding the address space that much harder.
-
I guess one (tiny) benefit of having segments overlap every 16 bytes is that a malloc() implementation could return pointers of XXXX:0000 format, i.e. only concern itself with segments? And then, if you want to index into such an array, you can put the array element’s index/offset in a register without having to add a base address offset, since the array always starts at 0000 (within the given segment).
-
-
More silly trivia: All wintel PCs boot with line 20 disabled, in order to default to 8086 mode. And if you turn it on, you talk to the keyboard controller. Some quick googling led me to an example here: https://github.com/Clann24/jos/blob/master/lab2/code/obj/boot/boot.asm#L29
Of course these days all these devices exist on-die, but back in the day they would have been discrete ASICs.
-
-
Zig is great, and you mob should all pitch in a few bucks a month to help get it to production-readyness :D
-
This community has people who know compilers, type systems, optimizing C, parallelization, concurrency, test generators, IDE’s, technical writing, and language marketing. Just to name a few things relevant to a PL implementation. Probably better for Zig if they donated brains and time instead of money. ;)
-
I contributed non-working 32-bit port. :) As far as I know the first attempt to port Zig at all.
-
-
Well this is worrying, particularly since I’ve just now heard of it :-/
-
Really not happy about this. I mean, I recognize that mac gaming is a tiny sliver market anyway, but this essentially will kill the desktop mac games market, although it’ll mean ports from mobile will get much easier.
But really, is that what we want? Thank god for Bootcamp I guess?
-
OpenGL already seems to be an afterthought for most game developers. It’s basically only a Linux/Mac target in practice, no? For Windows, game devs usually target DirectX, and for PS4 and Xbox, there isn’t even OpenGL support. Games today sometimes even run better on Mac using DirectX under Wine compared to using the native macOS OpenGL, although that admittedly makes them less accessible to the average user.
-
-
-
-
Well, MoltenVK is a thing apparently, so I guess if Vulkan does take over, maybe it won’t be /too/ bad as a macos target?
EDIT: also looks like (based on very quick searching) that unity and unreal both support Metal as a target already. Being that ios also uses metal, I assume they likely have a vested interest in supporting it there.
-
-
-
-
-
It’s not going to stop working, they’re just marking it as no-longer a priority that may stop working in a future update. I can’t imagine anybody is going to be forced to update to whatever future version of MacOS does not include OGL by default. If it’s that important to the industry, people other than Apple will pick up the implementation work. Most professional tools already support Metal and Vulcan, and it seems pretty clear to me that on all platforms, the trend away from OGL is going to continue. Vendors of various rendering and scenegraph libraries can work with their customers to determine what backends they need to support.
-
-
-
Yes npm-driven development is insanity, as is the host (as in metric fuckton) of different tracking systems being deployed against users of the web.
None of these things warrants the power-grab that is AMP.
Time to take another look at Julia, I remember thinking it seemed really nice, if half-baked, last time I looked into it.