You are viewing archived messages.
Go here to search the history.

Doug Moen 2021-12-20 04:20:30

This is a question about writing compilers. I need to design an IR. Mine is for a pure functional + imperative language. What currently seems popular is SSA with block parameters, not phi nodes, which at least handles the imperative side of my language. My special concern is supporting efficient compile time evaluation (as well as partial evaluation). I guess I want the IR to be a compromise between supporting a fast interpreter (for compile time evaluation) vs supporting conventional compiler optimizations. Does anybody have experience with this?

Alex Bender 2021-12-20 13:48:55

looks like this could be interesting for you, but I'm not on the topic so cant say for sure

https://futureofcoding.slack.com/archives/C0120A3L30R/p1639986127090700

[December 19th, 2021 11:42 PM] rasen.dubi: :tada: I finally finished the IR refactoring after struggling with it for the last three weeks. I have decided to go without CPS as I understood that CPS is better suited for later stages of compilation.

I have also discovered <https://www.youtube.com/watch?v=Ntj8ab-5cvE|Swift Intermediate Language (SIL)>, which inspired my IR design quite a bit. And I found https://github.com/bytecodealliance/wasmtime/tree/main/cranelift|Cranelift, a compiler framework (like LLVM) that focuses on JIT compilation—it might be a good target to support in the future.

https://www.alexeyshmalko.com/alpha-7/

Matthew Linkous 2021-12-20 16:00:53

In Unix everything is a file which makes allows simple, reusable tools like ls, cd, cat, etc to be used across the whole system. However, files have their drawbacks as well: primarily that they're difficult to merge or detect changes which is useful for syncing, collaborating, and/or subscribing to data.

Has anyone seen any alternatives to this paradigm? My startup is currently exploring the idea of append-only logs as our core primitive instead of files. We're not building a new kernel but we're attempting to create a new programming environment with collaboration and reactivity as core tenants. Would love to hear other perspectives on the subject!

Daniel Krasner 2021-12-20 16:41:56

@Matthew Linkous some of this thread is likely relevant to you: https://futureofcoding.slack.com/archives/C5T9GPWFL/p1636714161079200

[November 12th, 2021 2:49 AM] konrad.hinsen: A recurrent topic in this community is "Why do today's programming system so strongly rely on text files, and can we do better?" This tweet made me think of a possible answer: epistemic transparence (of text) vs. epistemic opacity (of data formats requiring more specialized tools for inspection). We have so many tools for inspecting text files that it's hard to imagine that someone could sneak in a tool that deliberately misrepresents the information in a file. Human-readable data encodings in text files thus provide acces to a shared ground truth. The tools intermediating between bits in memory and UIs (screens etc.) are so simple that they are easy to understand and easy to verify and validate. Even for relatively simple structured binary formats such as tar, this is no longer true. https://twitter.com/slpnix/status/1457642326956855296

Daniel Krasner 2021-12-20 16:47:21

but in general there are many great systems out there which have gone past the teletype/terminal and punch card stack/file model of programming and dealing with information. Smalltalk is one example or NLS for a more historical one.

Matthew Linkous 2021-12-20 16:52:19

Ah yes Smalltalk is a great example. Having the file not be the single source of truth but instead an optional artifact of your program is an interesting concept.

Matthew Linkous 2021-12-20 17:00:31

I think my focus is less on the representation of a program but more towards the representation of data or system state.

For example:

If you wanted to create a global source of a user's mouse position in a Unixy system, you might designate a file that is continuously overwritten by the kernel that other processes could stream in. However, if you had multiple mice (somewhat contrived I know) then you either must deal with locks, create multiple files, or make the file append-only. The same is true for a lot of multi-writer applications--especially collaborative text editing.

So it makes me wonder: can/should files be completely replaced with append-only logs.

Daniel Krasner 2021-12-20 17:07:21

Unclear to me what you mean by <<log>> here. If you are thinking of building interactive, interpreted environment then the static flat file model/metaphor is only going to make it an upstream battle. You can image an message based system like Smalltalk, or an actor one as in the Carl Hewitt sense (in your mouse example, you can have each mouse be an actor sending a message to some hardware manager actor, no need to files or logs of any kind) or you can come up with another like model or better yet metaphor.

Matthew Linkous 2021-12-20 17:29:00

Yeah I see what you mean. I think my concern is around persistence and syncing. So I guess if we think in terms of an actor that is in charge of receiving messages/updates from each mouse actor and then can respond to messages that request the mouse state then the internals whether it's in memory, stored in a SQL DB, file, etc doesn't matter because it's a black box which for the most part is a good thing. However, I'm thinking more in terms of composable data structures. So if you instead think of each mouse as a stream, then to have multiple mice you would just interleave your streams. I.e. I think what I'm getting at is more of building on top of an event-bus rather than addressable messages. Like it decouples the source and the recipient.

Matthew Linkous 2021-12-20 17:34:39

My experience with the actor model is more in the Erlang world than Smalltalk and I have always enjoyed the each process/actor is completely isolated and could be it's own complete computer. However, I've always found the ideas of publishing to streams or channels more intuitive and ergonomic for shared state than exchanging messages. For example in this mouse example, if I had a drawing app then I would likely need to poll the "mouse agent" every 16ms which seems much more awkward than piping mouse changes into the application e.g. mousePos() |> draw() then the actual drawing application/process/actor is decoupled from the mouse agent. Which you could model with files but it seems like a different data structure would be more suitable

Daniel Garcia 2021-12-21 00:00:36

I think Nushell represents everything as a table

Matthew Linkous 2021-12-21 13:01:56

Yeah I love that idea!

Deepak Karki 2021-12-21 20:51:24

https://news.ycombinator.com/item?id=29590681

Ask HN: How would a programming language look if designed by non-programmer>

Since it’s hard to find such a person, who understands CS/Math/can program machines but never used “normal” programming languages

I do wonder how it’d be designed, maybe current approach sucks?

OOP is beautiful itself, it > enables normal people> to model complex systems that’ll be running on computers, but can we get even better?

Jack Rusher 2021-12-27 12:03:03

Historical footnote: Lisp was discovered/invented by a non-programmer.

Srini K 2021-12-21 23:29:21

My answer to this question got to the top of the thread: https://news.ycombinator.com/item?id=29625625

It was a hurried response for sure, but I guess it was still a nice reminder

Matthew Linkous 2021-12-22 19:51:12

I really like your “home cooking” analogy and frequently share a very similar one regarding cooking that I think goes one step further.

The issue with “home cooking” as a goal is that in relation to computing most people are consumers/diners/users and not programmers/chefs. So it’s not that we need more programmers and home chefs, I think the problem is that the gap between a home chef and a restaurant owner is so massive and exists the same way in software.

To extrapolate, let’s consider an example:

You’re a talented home cook that has an awesome new dish that you have perfected and want to share with the world. Great! Now how can you actually do that? You basically have two main options:

  1. Publish your recipe online (equivalent to open-sourcing on Github)

Pros:

  • Free to distribute

  • Unlimited reach

Cons:

  • Your users have be a home-cooks themselves to consume the recipe

  • You don’t make any money

  1. Start your own restaurant and serve your dish to patrons (equivalent to creating your own SaaS startup)

Pros:

  • You actually make money

  • Your users can be anyone (no cooking required)

Cons:

  • Extremely costly and risky to pursue

  • Requires many more skills and responsibilities to pursue (like hiring staff, renting a space, accepting credit cards, supply chain optimizing, etc)

  • Limited initial scale (usually just one location to start)

So what if there was a third option...

What if every person had their own personal chef that could make any recipe your request and shop for the required ingredients on your behalf...

We wouldn’t need to rely on restaurants to enjoy highly skilled culinary creations. This would be awesome but clearly unfeasible in this cooking example but is entirely feasible in the software space. If each person had their own personal server, we could build and share full stack apps (and monetize them!) without having to build VS-funded software services.

I’m currently working on this project with the aim to allow us “home cooks” to build apps for each other without storing each others data but also make those easy to use for the people that just want to eat and not cook. We’re doing this by creating a space for general purpose personal cloud computing that developers can target and user can install with just one-click.

Kartik Agaram 2021-12-22 21:02:14

Sounds like sandstorm.io? I was recently reminded of it..

Matthew Linkous 2021-12-22 23:47:54

Yes a similar idea with more of a focus on developer experience and end-user-programming

Kartik Agaram 2021-12-23 00:35:24

That's an interesting take 😄 I'm curious to hear more about how you're thinking about it.

Konrad Hinsen 2021-12-23 08:07:01

I'll add my usual complaint about the term "end user". It implies an industrialized production system in which there are a few developers and a large number of users, with an enormous gradient of expertise and agency.

The group of people I see as being left out are the craftspeople who use industrially produced components and tools to create situated artefacts. People who have more domain competence than the upstream designers of components of tools, but less knowledge about low-level details, optimization techniques, etc. An analogy from cooking could be the staff of a hostel or cafeteria.

Konrad Hinsen 2021-12-23 10:48:27

Kartik Agaram Sandstom looks interesting. I like the data-centric approach it takes. Do you have first-hand experience with it?

Matthew Linkous 2021-12-23 15:12:20

Konrad Hinsen in the computing metaphor would this be more like Sysadmins and back-office developers?

One product decision we’ve made is that every app built on our platform has a generated REPL/terminal, so if you want more precision you can drop into that instead of using a GUI. This also enables cross-app workflows e.g. you could write a command like “focus 45” that would put a 45 min block on your calendar and mute your notifications for that duration.

In general the above is totally doable in your OS if you only use local, native apps but doesn’t work when you are using SaaS or cloud based tools. So we aim to centralize your cloud apps on to one generalized platform so we can bring back writing programs yourself without needing to reach for yet another service like Zapier.

Konrad Hinsen 2021-12-24 08:46:13

Sysadmins and back-office devs would be part of that group, but it would also include many professionals whose job description does not (for now) directly refer to computing. Much like we have "computational scientists" already, I expect there will be "computational architects", "computational luthiers" and many others in a future that creates a space for them.

That's where the cooking analogy fails: computation can/should be a medium rather than a technology, in a way that cooking can't be.

Matthew Linkous 2021-12-22 19:51:12

I really like your “home cooking” analogy and frequently share a very similar one regarding cooking that I think goes one step further.

The issue with “home cooking” as a goal is that in relation to computing most people are consumers/diners/users and not programmers/chefs. So it’s not that we need more programmers and home chefs, I think the problem is that the gap between a home chef and a restaurant owner is so massive and exists the same way in software.

To extrapolate, let’s consider an example:

You’re a talented home cook that has an awesome new dish that you have perfected and want to share with the world. Great! Now how can you actually do that? You basically have two main options:

  1. Publish your recipe online (equivalent to open-sourcing on Github)

Pros:

  • Free to distribute

  • Unlimited reach

Cons:

  • Your users have be a home-cooks themselves to consume the recipe

  • You don’t make any money

  1. Start your own restaurant and serve your dish to patrons (equivalent to creating your own SaaS startup)

Pros:

  • You actually make money

  • Your users can be anyone (no cooking required)

Cons:

  • Extremely costly and risky to pursue

  • Requires many more skills and responsibilities to pursue (like hiring staff, renting a space, accepting credit cards, supply chain optimizing, etc)

  • Limited initial scale (usually just one location to start)

So what if there was a third option...

What if every person had their own personal chef that could make any recipe your request and shop for the required ingredients on your behalf...

We wouldn’t need to rely on restaurants to enjoy highly skilled culinary creations. This would be awesome but clearly unfeasible in this cooking example but is entirely feasible in the software space. If each person had their own personal server, we could build and share full stack apps (and monetize them!) without having to build VS-funded software services.

I’m currently working on this project with the aim to allow us “home cooks” to build apps for each other without storing each others data but also make those easy to use for the people that just want to eat and not cook. We’re doing this by creating a space for general purpose personal cloud computing that developers can target and user can install with just one-click.