![User banner](https://programming.dev/pictrs/image/762f7689-0b74-46d6-b173-f56abcb848e9.jpeg)
minecraft can work really well for learning how tp program, when I was 9 that is how I started, unfortunately its been a long time since I took that course but if you are willing to do the research there should be a some for server programming and java modding at least that is what I took over 11 years ago at this point, and maybe javascript for gametest framework for bedrock edition. there is also minetest which is a little better for learning but isn't minecraft so is a little bit more annoying but lets you modify basically anything you want which is very fun. also a great way to learn boolean algebra/circuit design in minecraft/minetest, redstone can be used to make micro computers like calculators, fun and can be applicable to making games in minecraft which makes it more engaging as well. also the minecraft commands can be put into a mcfunction file as you can imagine this can be generated by outputting text to the file, this is great because you learn file io and a programming language and mostly he would be using math to generate things so teaches math, its limited but that is something he would find fun that is super easy and can be done in basically any language.
redstone/mcfunctions I personally like this approach on top of the course because it gives him something useful so should hopefully encourage him to play and program after he finishes lessons and etc...
I currently don't have 1 favorite there are so many really cool languages. but here are 2 and some that have inspired me.
- Common Lisp for sheer Technological prowess has some very advanced features that I dont see very often, runtime recompilation, code as data, data as code, debuggers, images, redefinition, macros , perf measuring, recompilation during errors to fix bugs etc... and has a algebraic syntax which can be nice.
- D for general purpose, again has features that are not common, optional GC, C compiler, zero allocation c strings, Lowlevel purity, and can be as Fast/Faster than C, and as simple as python(in the base language obviously pythons packages make up for basically all of its flaws). Languages that have inspired me not favorites but changed the way I think are APL, Factor, Scheme, Lobster, Unison, and Koka, I hope you enjoy the read if you check any of those out.
I thought I was going to disagree at first, because I am forced to use multiple DSLs for several projects I work on, however after I thought about it I hate the those DSL's because they are not actual programming languages they are overly restrictive. more limiting than assembly, thus why I am using an actual language to create my own DSL that mainly uses the language as its host, so its not really a full DSL just a few extra functions on top of an actual language. so surprisingly I pretty much agree.
I would say Elixir, Ocaml, Rust, Haskell, Scheme, Clojure, Common Lisp all have great examples of large and small DSL's that are very convenient, I would also include libraries as DSLs a C example would be something like Raylib, or SDL, and I would consider the code below an example of a micro DSL in Common Lisp.
(loop for i from 0 to 100 by 2
for x from 10 by 10
do (print (list i x)))
so I think I mostly agree.
yeah like everyone else is saying use it, whatever way you can. for me I used notepad++ and the terminal for a while, then to simplify the process I switched to Emacs/NeoVim. really depends on what you want you dont need to use a terminal based editor. if you are on windows or linux their are a couple important things to learn first to help fast track the process. I use windows so these are from that perspective specifically but its not limited to windows.
learn how to set environment variables. you can use environment variables to make some command line tools available everywhere, example, fuzzy finder, grep/ripgrep, fd, robocopy, curl, chocolatey. and more some are preinstalled like curl, others need to be installed like chocolatey which is a package manager for windows that installs programs like ripgrep, but for each you can just download an exe and set a env variable.
quickly open the terminal in a directory if you have the file explorer open, at the top of the window is your path if you replace that path with cmd it will open the terminal in your current directory.
make your own CLI tools, and use others. grep lets you search through all the files in a directory recursively this is incredibly powerful when you learn how to use it well. fd lets you do the same thing as grep but just for the file names, so you can search your entire computer for a specific file name. chocolatey helps you manage your installed programs, and helps you install them. robocopy is a fast multi-threaded copy built into windows. fzf lets you search through a directory but it updates live. curl is complicated but it basically lets you download something from the command line.
operations there are different piping and other operations you can do directly in the command line but I am not to versed in that it would be best to watch some videos, but one is exe > test.txt this will put the output of the exe/command into a file called test.txt. I am not too versed in the other operations but I know their is one for piping the output of one command into the input of another.
I have been working on something similar, not in Rust but the general consensus of what I found still should be helpful.
interpreted languages are easy however typically not as efficient as what you would want especially because you know people will take the language and run to the moon with it.
Jit Compiled language with a good Jit these are fast enough especially for a text editor or other utilities that you normally wont need a fully compiled language and when you do then you can use bindings which should be a rare occurrence which is nice.
Binded languages are pretty good they typically have been around for a while people know them and its a safe bet, something like Lua with its Jit is quite fast, or javascripts Jit .
Fully compiled my concern I had with this approach is people would need the compiler tool chain just to do basic edits which for developers that just want to use the editor and not configure it will be very annoying or borderline impossible. the specific scenario I had trouble with was a config file generator I made for work I make a lot of these and I sent the code a long with it however they needed to download the compiler to use the script which meant I basically had to re run it every time myself. with a text editor you may not think this will be necessary until someone shares the editor with a friend. of course if you pack the compiler into the editor this would work.
another concern is compile times, I think users when changing their config could get annoyed if they need to compile something every time, they want to test a new setup.
the big benefit with fully compiled is hopefully your users will be using the same language as yourself, and this makes it a lot easier to debug user level code. of course this should be the case with any of these options if you primarily use the same language as your users however going fully compiled makes the separation between dev and user much smaller. and the second being speed that will make the editor quite fast.
I would make a numbered list of the best to worst option however it really depends on if you want to keep the project completely in Rust or not, for my project I wanted to use one language so I went with the fully compiled approach , with a language that contains a runtime eval, so it depends on what you want out of the editor.
personally I prefer the fully compiled approach I think it makes a lot more sense, next would be a language implemented in Rust.
"sense" as in my mental model of the project. ^
For users I find they tend to prefer a language that they are already familiar with, such as lua, javascript, or python however I tend to find the usefulness to be surface level helps the very beginners but I think it makes it harder for people who really want to make something useful.
in quite a few games/programs/editors I use, scripting languages tend to not be very well documented because the devs rarely see the scripting language when developing, however when the "scripting language" is the same as the main dev language the users can use the main dev documentation also for scripting in a lot of cases. thus why I think Neovim and Emacs work so well, doesn't need to be the same language as long as devs use the scripting language enough to get irritated at its flaws.
"main dev language" in terms of time spent by the developers in the language ^
hopefully this helps and makes sense.
I would say the same as most it really depends on what you are doing, I program in Lisp a lot so Emacs is a natural fit. Vi/Vim/Neovim are in my opinion Technically better they are smaller and simpler however Emacs is a much bigger and more versatile. I ended up choosing Emacs specifically because it was bigger and more versatile. I do plan on giving Vim a try again sometime to see if it fits my needs better, once learning Vim Keybinds/Motions I find it relatively easy to switch between them, except when it comes to the editor specific apps like Org Mode.
Like some others have mentioned the biggest part of emacs and vim is the Vim Keybinds/Motions this is something you can take to almost every editor since most editors have the majority of keybinds/Motions.
(you mentioned you use Nano so you may already find this to be true with Nano as well)
The Second biggest thing you learn from Emacs/Vim is how to use the terminal better, when I started out using intellij I didnt realize the command prompt was a command prompt, when I switched to notepad++ and used the terminal I began understanding how the terminal actually worked and it has helped me a lot, I find myself using the fd utility to find documents and ripgrep to search through config files even when I am not programming and it makes me way faster than my coworkers (I work as an artist) when we are searching through some of are more intense config files I find stuff first. I switched to Emacs/Vim to unify my workflow because I was using Notepad++ and the Terminal, now I understand Intellij better because I actually started looking things up, Emacs/Vim for better or worse force you to learn. now if I ever want to try out a language it does not matter if it has a language server I can use a small set of universal tools to get done what needs to be done.
I would say a full IDE is probably faster however Vim Motions can save a lot of time, because with Vim Motions worse case scenario you use the mouse which is what you would have done anyway if you didnt know them, so it can only save you time.
I will say the biggest danger is tinkering too much and wasting time on your Emacs/Vim config files, for me I havent really touched my config files in over a year, only thing I have done is add some languages too it and changed the theme.
I sometimes do some Java development but its very rare so I dont know the language well enough to use Emacs or Vim to program Java I normally just use IntelliJ with Vim Motions. but for my main dev projects I use Emacs.
Third benefit is a Very customizable Editor; for work and for side projects I use languages that are not very common so they dont have great support in IDE's so if I ever want a feature I can make it myself. a common feature is structural editing.
yeah it has a really good blend of features, I think that it could have saved quite a few large companies a lot of money, as well, like facebook who keep re programming stuff, with D they could have used the same language and they would have very rarely re programmed anything, and when they did they would have been able to re use some code. so I am quite surprised it didnt catch on, but it did have a few problems, one being it got relatively popular too quick before it could mature. GC problems, and being too experimental, a very good language is hidden behind a lot of features.
my opinion is a good language needs these qualities. Portable, Safe, Fast, Easy.
which seems to be similar to the author of the article. the language I have found to match the criteria the most is the D programming Language, its so mediocre in every area.
3 separate compilers, gcc llvm and mars backends. can be as safe as you want it to be, with constructs for purity, GC, and contracts built in. can be as fast as you want it to be it is a systems language and gives you all the necessary tools to go down to C level or below with a good in line assembly, but generally the idiomatic code is fast enough you dont need to go to the C level.
it is also very easy, you have a lot of C libraries and D libraries you can use and with a built in C compiler (currently beta) you can import C libraries easier, it also has a similar syntax to C so its very easy to rewrite C code in D, it has an optional GC so if you are going for max performance you can beta test algorithms quickly using the GC and when you are ready for max performance you can do it all manually, or you can use the feature to test what is using the GC so you can avoid the GC in loops, I did this in a game recently, I used the GC to setup all memory at the beginning and turned off the GC so I would never use it in a loop,
another nice feature is functional features that make the language cleaner to write. I dont think this approach of being perfectly mediocre is necessarily the best but at least on paper its very good, and in practice there have been companies (specifically Weka Digital) that swear by the approach, they can use one language for both testing out ideas and the final product. but again in a lot of cases you dont want a language that is good at everything you want one that is good for your use case.
also the article was very interesting, language design fascinates me and the article was a good read really enjoyed it. currently planning on learning Haskell and Zig soon should be fun to compare these once I am comfortable with them.
I tend to use print way to much especially considering the programming language I am using has a debugger built in and I dont use it nearly enough. ok I do use break so I can stop execution paired with printing but I really need to start actually using it. however yes debuggers are awesome if anyone hasn't tried one out give it a try, even if you are using a smaller lesser known language a lot of languages are more compatible than you think, I recently used windbg with the D programming language if you haven't heard of that language, exactly, so give your language of choice a few google searches and see if there are any that work.
I like statically typed languages more than untyped, however the more I get into strict typing it just seems like compile time predicates/asserts. which is something you can use in a lot of languages to get strict typing. I mainly use Common Lisp and it has several things built in like DEFTYPE and you can create predicates to specify a type. though obviously not mandatory it can be quite nice. so I guess at the moment I am more in the middle I use types when they seem useful and dont when I am in a hurry or they are not needed.
I currently use Common Lisp, it is considered functional but its sort of in between. I use CL to generate voxel art which is what my employer is paying for so they really don't care what I use. I also use a couple functional DSL's one of which is literally just math applied to voxels, and the other is more akin to a fancy config file format.
![MrJay](https://programming.dev/pictrs/image/2ffe2605-b5ee-400a-9f2f-f0d721e91895.png?format=webp&thumbnail=64)
Voxel Artist, Programmer and graphics Enthusiast. Most used languages are Common Lisp and D Currently learning Zig Haskell and Lobster I program games for fun, and generate/Modify voxel art for work. Current side project: Rendering Engine Main Project: general Voxel art utilities.