As someone that writes a lot in Rust, I have a longstanding dream to make a compiler for a subset of the language, since I don’t use all features of Rust and my hope is that this way I could have fast debug builds (in terms of compilation time) while I develop, with simplified borrow checker and so on. So then I can iterate faster. That’s one of my dreams. But I have not had time to even look at it yet, as the other code I work on takes precedence at the moment.
I'd like a GC (no borrow checker) version of Rust. There's so many cool concepts in the language that I'd like to know how useful it is in different contexts. (Compiled without a VM, option types, no nulls, easy error handling without exceptions...)
I don't think borrow checking plays a significant roles in most projects compiling performance. Running `cargo check` generally runs a lot faster (after the first run) than `cargo build`, even if it runs borrow checking, etc. AFAIR macro expansion, LLVM code generation and linking takes a lot of time, but it depends on the project.
I think you would be better served by a simplified, less optimized code generation, as from what I understand LLVM is the thing that takes a lot of time. You can see this pattern in Crystal and Swift for example, that also use LLVM and are also relatively slow to compile, compared to OCaml or Go which have their own backend.
Haven’t looked at the rust compiler code base, but often with languages you can hack together subsets via deletions and comments and flags of existing compilers.
Hadn't heard of this book yet! From my cursory glance this looks like quite a good introduction into language implementation, which is just what I've been looking for myself, thanks a lot!
My favourite FizzBuzz is in Haskell, I found it in this talk by Kevlin Henney[0], and looks like this:
fizzes = cycle ["", "", "Fizz"]
buzzes = cycle ["", "", "", "", "Buzzes"]
words = zipWith (++) fizzes buzzes
numbers = map show [1..]
fizzbuzz = zipWith max words numbers
Henney explains in detail in the video, but it makes use of lazy evaluation to create an infinite list of FizzBuzzes, and also uses no if statements. I find it intellectually exciting, but make no claims on readability
Most of the languages ideas I have aren't focused around syntax these days, rather about automating some tedious part of programming. Two that have stuck with me for a few years now:
1.) A language for plumbing. Basically, this is a mini-language for defining data structures and how they're shipped around different devices and processed. Think of protobufs or Apache Avro, but also including functionality like conditionals & flow control, rich collection operations like map/filter/fold, account & device management libraries, and most importantly, an Actor-based syntax (somewhat like Erlang) where entities like "The user's iPhone" or "The user's smartwatch" or "the database" just exist like process handles, and you can send messages to and from any of them. It'd then compile down into idiomatic Swift/Kotlin/Java/C/SQL to run on appropriate machine, so that your UI code just includes a library and you don't need to rewrite all your data plumbing, serialization, and business logic for each client platform.
2.) A language where you literally can use machine learning like if-statements. Basically it'd have functionality to dump out a feature vector (an array-of-structs), visualize it in a Jupiter notebook, label it (or send it off to Mechanical Turk for labeling), and then feed the labeled data back into any of multiple classifier types for use in an if-statement. Once trained, the model and training data would be checked in as if they were source code, and could be attached to code and versioned the same way that an algorithm would be. You'd run your program in two modes: in training mode, the program executes as much of the code path it can until it gets to an untrained classifier, then dumps out the data for that and starts the labeling/training process to generate the trained model. In execution mode, it uses the generated models to actually make flow-control decisions.
Doubtful I'll ever have time to implement either one of these, but at least at the moment, they're somewhat timely and don't have convenient solutions. I think syntax is basically a solved problem, and don't really care about it.
I would build around a constrained high-level concept. Something like actors, perhaps. It would be assembly-like, command-oriented.
I would then build a visualization environment which shows what the actors are doing, possibly step-by-step. It would show them moving values between registers and buffers. It would show messages passing between actors. It would show new actors create and finished actors die and errors get dumped into the canvas.
Your concept as an end-user would be that you're programming these automatons. You could clearly visualize what's occurring and debug control-flow or algorithmic issues by stepping through their movements.
Maybe not a great idea in the long run, but if it was a weekend lang jam, that's what I'd do.
2. Apparently there's going to be a theme? So that might make whatever wacky language I've been mulling a bad fit. I'm rather curious about how that will play out
Another "crazy" idea: I'd like the compiler to reformat code to match strict style conventions.
Why? Sometimes there's no "right" style. Sometimes novices need training wheels. In the long run, style doesn't matter, but in big projects code is easier to read when style is consistent. It's also easier to onboard when code follows industry-standard styles.
Would it be better when a language gently pushes everyone to the same style?
The usage of `unless` strikes me as unmaintainable and "smart", not in a good way tbh. The types are all other the places, too. What is it even doing exactly? Appending a string to a null value..?
I think there's a lot of opportunity in the 2d domain, in both directions.
You might have a picture represent a program, like Piet [1]. Or you might have a language specifically designed to show certain types of pictures, like TeX or Processing or more narrowly, PlantUML.
Another area to explore is the distributed space. Perhaps a language with Kubernetes capabilities as first-class objects.
I'd like a language that makes it easy to mock and dependency inject without doing anything special.
IE, if in my business logic, I write "new Foo()", I'd like to be able to write a unit test where I say something like, "whenever I wrote 'new Foo()' swap in this mock object instead."
Or, in a module that's an entry-point, I'd like to say, "whenever I wrote 'new Foo()' swap in this subclass instead."
I've spent so much time refactoring to make code mocking and dependency-injectable.
> You can code in any programming language you'd like to create your project, so long as the language is part of the Debian/Ubuntu or Arch package repo (or one of the language-specific repos, like Rust's cargo).
So seems like it should be fine! Go ahead and make a racket :)
[+] [-] codetrotter|4 years ago|reply
[+] [-] gwbas1c|4 years ago|reply
[+] [-] bilkow|4 years ago|reply
In the perf site you can see some examples: https://perf.rust-lang.org/
[+] [-] Zababa|4 years ago|reply
[+] [-] brundolf|4 years ago|reply
[+] [-] tyingq|4 years ago|reply
[+] [-] verdagon|4 years ago|reply
[+] [-] breck|4 years ago|reply
[+] [-] dangoor|4 years ago|reply
http://craftinginterpreters.com
[+] [-] Melonai|4 years ago|reply
[+] [-] codr7|4 years ago|reply
https://github.com/codr7/swifties
[+] [-] skohan|4 years ago|reply
[+] [-] agalunar|4 years ago|reply
[+] [-] fouc|4 years ago|reply
I'm not sure I've ever seen a more readable compact fizzbuzz than this version in coffeescript
[+] [-] D7x7w9pHnT|4 years ago|reply
[0]https://youtu.be/LueeMTTDePg?t=2891
[+] [-] nostrademons|4 years ago|reply
1.) A language for plumbing. Basically, this is a mini-language for defining data structures and how they're shipped around different devices and processed. Think of protobufs or Apache Avro, but also including functionality like conditionals & flow control, rich collection operations like map/filter/fold, account & device management libraries, and most importantly, an Actor-based syntax (somewhat like Erlang) where entities like "The user's iPhone" or "The user's smartwatch" or "the database" just exist like process handles, and you can send messages to and from any of them. It'd then compile down into idiomatic Swift/Kotlin/Java/C/SQL to run on appropriate machine, so that your UI code just includes a library and you don't need to rewrite all your data plumbing, serialization, and business logic for each client platform.
2.) A language where you literally can use machine learning like if-statements. Basically it'd have functionality to dump out a feature vector (an array-of-structs), visualize it in a Jupiter notebook, label it (or send it off to Mechanical Turk for labeling), and then feed the labeled data back into any of multiple classifier types for use in an if-statement. Once trained, the model and training data would be checked in as if they were source code, and could be attached to code and versioned the same way that an algorithm would be. You'd run your program in two modes: in training mode, the program executes as much of the code path it can until it gets to an untrained classifier, then dumps out the data for that and starts the labeling/training process to generate the trained model. In execution mode, it uses the generated models to actually make flow-control decisions.
Doubtful I'll ever have time to implement either one of these, but at least at the moment, they're somewhat timely and don't have convenient solutions. I think syntax is basically a solved problem, and don't really care about it.
[+] [-] pfraze|4 years ago|reply
I would then build a visualization environment which shows what the actors are doing, possibly step-by-step. It would show them moving values between registers and buffers. It would show messages passing between actors. It would show new actors create and finished actors die and errors get dumped into the canvas.
Your concept as an end-user would be that you're programming these automatons. You could clearly visualize what's occurring and debug control-flow or algorithmic issues by stepping through their movements.
Maybe not a great idea in the long run, but if it was a weekend lang jam, that's what I'd do.
[+] [-] klyrs|4 years ago|reply
1. That would be telling.
2. Apparently there's going to be a theme? So that might make whatever wacky language I've been mulling a bad fit. I'm rather curious about how that will play out
[+] [-] gwbas1c|4 years ago|reply
Why? Sometimes there's no "right" style. Sometimes novices need training wheels. In the long run, style doesn't matter, but in big projects code is easier to read when style is consistent. It's also easier to onboard when code follows industry-standard styles.
Would it be better when a language gently pushes everyone to the same style?
[+] [-] breck|4 years ago|reply
[+] [-] Doxin|4 years ago|reply
[+] [-] neysofu|4 years ago|reply
[+] [-] jnwatson|4 years ago|reply
You might have a picture represent a program, like Piet [1]. Or you might have a language specifically designed to show certain types of pictures, like TeX or Processing or more narrowly, PlantUML.
Another area to explore is the distributed space. Perhaps a language with Kubernetes capabilities as first-class objects.
1. https://www.dangermouse.net/esoteric/piet.html
[+] [-] gwbas1c|4 years ago|reply
IE, if in my business logic, I write "new Foo()", I'd like to be able to write a unit test where I say something like, "whenever I wrote 'new Foo()' swap in this mock object instead."
Or, in a module that's an entry-point, I'd like to say, "whenever I wrote 'new Foo()' swap in this subclass instead."
I've spent so much time refactoring to make code mocking and dependency-injectable.
[+] [-] blamestross|4 years ago|reply
[+] [-] yellow_lead|4 years ago|reply
[+] [-] y2bd|4 years ago|reply
[+] [-] breck|4 years ago|reply
[+] [-] m_arnold|4 years ago|reply
[+] [-] userbinator|4 years ago|reply
[+] [-] bbojan|4 years ago|reply
[+] [-] azhenley|4 years ago|reply
https://twitter.com/pltgames
[+] [-] rmetzler|4 years ago|reply
Or something like a lovechild of sed, awk, seq, and cut, with regexp match groups and string interpolation.
[+] [-] benibela|4 years ago|reply
That would be XPath/XQuery
I have spent 15 years implementing that in Xidel
>Or something like a lovechild of sed, awk, seq, and cut, with regexp match groups and string interpolation.
Sounds like Perl
[+] [-] mepian|4 years ago|reply
[+] [-] spdegabrielle|4 years ago|reply
https://racket-lang.org/
[+] [-] cdrini|4 years ago|reply
So seems like it should be fine! Go ahead and make a racket :)
[+] [-] mustknow2201|4 years ago|reply
[0] https://github.com/Slord6/Spice
[+] [-] miccah|4 years ago|reply
[+] [-] diogenesjunior|4 years ago|reply
[+] [-] Mikeb85|4 years ago|reply
> You can build an interpreter or a compiler, so long as it can run or build examples of code in the programming language you create.
No you create a language, but it needs to be able to run. So need to either build a compiler or interpreter to make the language do things.
[+] [-] spdegabrielle|4 years ago|reply
[+] [-] Karsteski|4 years ago|reply
[+] [-] lioeters|4 years ago|reply
[+] [-] tincholio|4 years ago|reply
[+] [-] rodrick_setsoff|4 years ago|reply
[+] [-] jhgb|4 years ago|reply
[+] [-] 0b01|4 years ago|reply
[+] [-] brundolf|4 years ago|reply
> You can build an interpreter or a compiler, so long as it can run or build examples of code in the programming language you create.
[+] [-] Amin699|4 years ago|reply
[deleted]