During my first Introduction to Programming course at university, I was taught Java. One thing that I found very troubling is that it wasn't easy, or possible in many cases, to change the programming language. Sure, you can write new functions or methods or classes, but I can't change the keyword for an if-statement. I also remember the TA saying "why would you want that?" I caught myself thinking "if we can program a computer, then why can't we program a language?"
15 years later, I still have this issue a bit, except I made my peace with it. It is what it is. There are some exceptions though! Such as: Lisp, Smalltalk and similar languages. It's in part why I have worked for a company that professionally programmed in Pharo (a Smalltalk descendant [2]). I remember hacking a very crude way for runtime type checking in Pharo [1], just for fun.
I'm not a Ruby programmer, all I know is that Ruby has some things that are identical to Smalltalk. But my question to the author would be: if you long for things like keyword arguments, type hints and namespaces why don't you program it in the Ruby language yourself?
Or is that really hard, like most other languages?
The language is the easy part. Getting tool support for your language change is the hard part. Getting the library ecosystem to adopt it is even harder.
I think that's why extremely flexible languages have seen limited adoption - if your language is more of a language construction kit where everyone can implement their own functionality, everyone has to implement their own tool support (or, more likely, live without any) and there's a limit to how far you can go with that. The best languages find the sweet spot where they give you enough flexibility to implement most reasonable programs, but are still constrained enough that tools can understand and work with all possible code.
Lets not equate silly and possibly dysfunctional string substitution macros with macros in higher level languages, which let you inspect and act according to the structure of the AST.
But that's an implementation issue. Do you really want to say, work on a project where somebody renamed "if" to "wenn" because they thought writing code in German would be neat?
If you want to make a special use tool, you can write a function like custom_if(cond, then_callback, else_callback) in most languages.
Maybe I'm just getting old, but as time goes by I like it more and more when things are obvious and non-magical.
I would rather risk the possibility of dealing with a project where someone did something unorthodox and clearly wrong than work with a language that tries to forbid a priori everything it considers unorthodox. Not that I'm out to defend C's awful clumsy macros, but it's no better when the alternative is nothing at all.
> Do you really want to say, work on a project where somebody renamed "if" to "wenn" because they thought writing code in German would be neat?
Ha, no, I wouldn't. Because to me it is important, that anyone can read the code, not just me or a German speaking developer. Just like I wouldn't translate "if" to Chinese. The point is, that this translation serves no purpose. Or rather its benefit, if any, is not sufficient to justify it being done and deviating from the standard. Macros can be useful and justified. But these string substitution macros ... Meh, rather rarely, I guess. Maybe for when you don't have "true" and "false" or something.
Some useful examples of macros are: Threading/pipelining, timing, function contracts. Things where the order of evaluation needs to change. Things one cannot easily do with functions alone. Your example of "custom_if" is actually a good one, depending on what "custom_if" does. If it needs its arguments to not be evaluated, unless an earlier argument meets some criteria, it would be a good candidate for a macro. Those things are not done using string substitution macros.
There is metaprogramming support in Java, but it's not as inviting and friendly as hygienic macros or Ruby patching. The obvious example is reflection, with which you can do a lot of bizarre things, some of which are useful sometimes. Another is annotations, which is heavily used by libraries in a way similar to how macros are used in certain Lisp like languages.
The reason “custom” programming languages (sometimes called macros) are not popular is that (statistically) no one wants to learn a custom language for each project. People want to learn the basics as few times as possible. Orgs prefer to standardize, most businesses are not snowflakes.
It can be done, but it is not economical, and therefore not practical.
> I also remember the TA saying "why would you want that?"
Is a typical response of someone without the background and without the imagination. It may well be, that doing Java-only for too long robs one of both. An alternative response could have been: "What a fascinating idea! How would you apply that? / What would you do with that?"
I am happy for you, that you found the exceptions and that your picture of the computer programming world is not as incomplete and bleak as that of the TA back then.
As someone who spent a fair chunk of time as a TA for comp-sci classes...
If you're in my room asking me how to change the keyword for "if"...
"why would you want to do that?" is entirely the appropriate answer.
---
Not because the concept of modifying the language itself is necessarily bad, but because the structure of the relationship here isn't neutral. The students in the class are here asking me questions that almost always relate to homework, exams, projects, or tasks.
From experience - You usually see this type of question when the student is actually trying to accomplish some other goal, and can't figure out how to do it.
So "Why would you want to do that?" is not dismissive... it's goal seeking.
help me understand the goal you have in the context of the current work that you are seeking to accomplish by modifying the "if" keyword. Until I understand what you're working towards, it's hard for me to appropriately scope my answer.
Further... I'm not really paid to spitball conceptual language design with you (fun though it may be!). I'm here because a large chunk of the students in the class are genuinely struggling and need basic assistance understanding the existing class concepts.
During my first Introduction to Programming course at university, I was taught Java. One thing that I found very troubling is that it wasn't easy, or possible in many cases, to change the programming language. Sure, you can write new functions or methods or classes, but I can't change the keyword for an if-statement. I also remember the TA saying "why would you want that?" I caught myself thinking "if we can program a computer, then why can't we program a language?"
15 years later, I still have this issue a bit, except I made my peace with it. It is what it is. There are some exceptions though! Such as: Lisp, Smalltalk and similar languages. It's in part why I have worked for a company that professionally programmed in Pharo (a Smalltalk descendant [2]). I remember hacking a very crude way for runtime type checking in Pharo [1], just for fun.
I'm not a Ruby programmer, all I know is that Ruby has some things that are identical to Smalltalk. But my question to the author would be: if you long for things like keyword arguments, type hints and namespaces why don't you program it in the Ruby language yourself?
Or is that really hard, like most other languages?
[1] https://youtu.be/FeFrt-kdvms?si=vlFPIkGuVceztVuW&t=2678
[2] Fun fact, I learned about Lisp, Smalltalk and Pharo through HN! So I know most of you know but I suspect some don't.