That the kind of thing that run away to north pole, killing many in its journey.
What would the perfect programming language look like?
- Thread starter iljitsch
- Start date
Many years ago my professor in the "Intro to Compilers" course was one of the authors of the GNU Forth compiler. A couple of his grad students were absolute bonkers in Unreal Tournament. I have some painful memories of getting completely pasted in Assault, and by their statements he was even more of a madman in it.
Did you, by chance, refer to this type of thing?
Running Forth from cassette tape on my C64 definitely made me think the language was/is interpreted.
Last edited:
It can be. It can also be compiled. One of the nice things about Forth is that it's very small... it worked great on 8-bit machines with their limited memory.
Also the design of the language (implicit stack for passing and return ing arguments) makes the compiled/interpreted decision unlikely to cause issues with lexical treatment of variables.
I always had the impression that Forth was amazing for single developers who owned a project, or maybe small teams who worked closely. But was otherwise a write-only language that would not scale to larger teams or larger projects. Convince me otherwise??
Well, it's is the kind of programming language where it is really easy to refactor and extract functions, given that cut/paste is all that takes.
On the other hand, without a namespace and package system, name collisions seem pretty much guaranteed. That said, adding namespaces isn't too difficult.
On the other hand, without a namespace and package system, name collisions seem pretty much guaranteed. That said, adding namespaces isn't too difficult.
I grew up with BBC BASIC, which had IF, THEN and ELSE; as well as named functions and 'procedures'. It entirely avoided the use of GOSUB and GOTO <line number>. It also had REPEAT .. UNTIL. Later version had WHILE.
I don't know about the perfect language, but Haskell with the GHC extension hell resolved, and with maybe with slightly more robust name hiding facilities (first class modules ala ML or Scala would be nice, but that's unlikely to happen), would be close to my perfect language.
Was that AI generated?
It also resembles how I (a non-native English speaker) was taught to write while in school in 80/90s. However unlike me it is too perfect.
I get the feeling the link on "imperative programming" is actually subtle SEO spam. Reporting, letting mods decide.
Someone else (likely the same actual person/entity) has done the same in other places here. I reported those. looks like the ban hammer of moderation has taken effect
LISP is like a secret club—once you learn the handshake, everything makes sense. Until then, it’s just parentheses-induced suffering!
Last edited by a moderator:
That's why the Python innovation of indenting to create blocks is so great. Could that work for Lisp?
While good indentation is critical to making your Lisp readable, I don't think that syntactic white space would help much with Lisp. After all, you need some way to differentiate function / macro calls from symbol reference, and that is what the parentheses do, the first item after one typically* being a call and anything else being a reference.
Also, most of the time, you aren't writing blocks of statements in Lisp, like you would in a procedural language. Instead you end up writing a single statement that the data flows through. You can break it up a bit with let, but the overall paradigm is still less about writing a list of small steps and more about describing what those steps combine to do.
* unless someone is doing something with macros or you are using
'Excuse my naivete, my background is mostly doing statistical analysis, data wrangling, and some numerical analysis in Python, Matlab and similar. But, it seems like there is always tension between making domain specific languages designed for algorithms in a fairly narrow domain and general purpose languages (which could probably just be thought of as another niche). Where and how do you decide to address different domains with libraries versus a different language?
The numpy library for Python provides great functionality for scientific computing, but it also seems to break with Python's style. Python seems to avoid dealing with data types and bit width, numpy has a wide array of such types. Python is well suited for iteration, numpy is well suited to vector operations and iterating over arrays is generally discouraged. I'm not sure how much Python experience would aid someone looking at numpy heavy code. So why a library for Python, rather than a distinct language like Octave or Julia?
The numpy library for Python provides great functionality for scientific computing, but it also seems to break with Python's style. Python seems to avoid dealing with data types and bit width, numpy has a wide array of such types. Python is well suited for iteration, numpy is well suited to vector operations and iterating over arrays is generally discouraged. I'm not sure how much Python experience would aid someone looking at numpy heavy code. So why a library for Python, rather than a distinct language like Octave or Julia?
Given ambiguity, I suspect not terribly well, at least, when not referring to something like a named algorithm. After all, it doesn't take much phone tech support to convince yourself that natural language isn't terribly good at such specificity and detail.
I mean, true, but, at least it doesn't change it's behavior randomly each time you run it through the compiler.