The Agile movement was all about dropping the process hoop jumping and focusing on solving problems efficiently, that's why it was considered extreme. Too extreme, as the one true implementation to rule them all is worse than what the agile movement was revolting against. This is how the game is played, over and over and over again; any movement that threatens the narrative is embraced, corrupted and ultimately used as a weapon against its core values.
Agreed, that's one of the more important advantages of Common Lisp in my book. But the reason it works so well is that the standardized version was based on plenty of experience and experimentation, and that it's powerful enough to be extended from user code; same goes for C to some extent.
Whoa. I'm afraid to look ;-) My immediate thought is, "lets combine all the mental fun of stack juggling from forth with the tree juggling from lisp." My brain hurts!
Combining aspects of Lisp with aspects of Forth is not a new idea. The RPN calculators offered by HP used a language called RPL ("Reverse Polish Lisp")[1], including a user-level version (a little more Lisp-y) and a system-level version (a little more Forth-y). While RPL is what came immediately to my mind, I doubt it's the only historical example of such a combination; people have been drawing similarities between the Lisp family and the Forth family for ages.
While I do get that feel with PostScript, as far as I can tell it was accidental rather than a conscious design decision.
The stack-oriented nature of PostScript appears to have been influenced by the engineers' experiences with working with some stack-oriented architectures from Burroughs [1], rather than from Forth. Some aspects of PostScript were influenced heavily by other languages in use at Xerox PARC during the Interpress era [ibid], most notably Cedar, but considering that Interlisp was also in use at the time, it's not unreasonable to conjecture that it had some influence; however, any such Lisp influence was likely subconscious, and none of the people working on Interpress or PostScript or their forebears seems to explicated such an influence (as far as I can find).
Charles Geschke and John Warnock, the co-founders of Adobe, both deny any influence from Forth, suspecting that some overlap of design requirements between the two languages led to the shared properties [2]. I know that can be hard to believe, given the striking similarity of the two languages, but it's not the only time that concatenative programming would have been independently invented: Manfred von Thun's Joy language is likewise similar to Forth, but, again, not inspired by it. Whereas the similarity of PostScript to Forth can be explained by a simultaneous need for portability and dynamism in tightly-constrained environments, Joy's similarity to Forth is a result of a desire for algebraic manipulation of program text (Forth's (somewhat) having this property may have been a conscious design decision, but I'd bet cold, hard cash that it was a happy accident).
Indeed, any of these stack-oriented concatenative languages are computationally equivalent to a transformation monoid (algebra of functions and function composition) where evaluation proceeds according to a (possibly effectful) term-rewriting relation. Viewed in this light, the stack effectively becomes a mere implementation detail as far as the semantics are concerned, but I think that any language designer starting with such a monoid+rewriting semantics, when facing reasonable implementation on real hardware, is likely to come up with something quite similar to Forth &c. That is to say, starting with a low-level focus on efficient and portable implementation, or starting with a high-level focus on code representation as algebraic terms, there's a good chance you'll wind up with something similar to an established concatenative language, whether you mean to or not.
Besides basic semantics, there's not that much stack juggling going on really. Cixl offers four stack operators, drop, dup, swap and clear; the idea is to use more convenient constructs like let bindings, closures and multi methods to keep the stack tidy.
There are several leaner alternatives for application scripting, is it really worth dragging V8 around to get that capability? Lua would be one alternative. The reason I'm asking is that I'm working on a more Forth-inspired alternative[0] for application scripting myself, and I'm curious about the reasons for defaulting to the crappiest language ever invented and an implementation controlled by one of the biggest corporate bullies around.
> defaulting to the crappiest language ever invented
Since we're trolling now, there is plenty worse around, like Python(the only language that manages to have worse scoping rules then pre-ES6 javascript, which is quite a feat), Cobol and LUA. JS ES6 is just fine. The trick is not to use the crap parts.
Lisp trades some of the strictness and static typing of Haskell and Scala, and the convenience of Python I guess; for more raw power. You won't really have a clue what macros are capable of before you see it yourself, I wholeheartedly recommend using Let Over Lambda (https://letoverlambda.com) as a guide. The other side of the coin is that you'll spend the rest of your days waiting for mainstream languages to catch up, but that's true of Haskell as well to some extent.
I don't know about "won't have a clue what macros are capable of before..." -- there are quite a few use cases for macros which can be described easily to any programmer, even those who never used Lisp.
I would like to believe it would suffice to say "macros in Lisp allow you to fully extend the the language with new primitives and abstractions in a way that no other language does", but examples are always helpful.
Lisp has a macro called setf, which takes any call which gets a value -- whether from a local function variable, or a class, to an array or hash table entry -- and converts it to the corresponding setter call. (If you define your own value places/types, there are also functions to make setf aware of how they work, so this isn't restricted to just some defined set of features in the language. Anything that holds a value in Lisp can be "setf" to a new value.)
There are a couple of other "big" Lisp macros in the language standard like with-open-file (which ensures a file is closed once control flow exits the body), loop (does pretty much what it says on the tin: provides whatever looping method you might want), or handler-case (try-catch style error handling; yes, Lisp allows for other methods).
Or how about the example I recently saw in a cryptography library. Since a lot of cryptographic algorithms use integer math modulo some giant number, this library defined a macro "mod-n" which took a base and some Lisp code, and re-wrote the code so the common integer math functions (addition, multiplication, etc.) would only return values "modulo {base}" --that is, return only values between 0 (inclusive) and base (exclusive). This meant their modulo math code looked (nearly) the same as normal, just standard arithmetic functions. This wasn't a very large macro either: only around 10 lines long (and about half of that being the list of operator replacements).
Note that let over lambda is ... let's say controversial among lispers. I think it is very good at teaching how to write macros, but very bad at teaching what macros one ought to write. It's a bit like that bit about making ruby accept bare words in Wat[1]. The fact that lisp lets you do the things that LoL presents is fine, learning how to do this is good. If you actually do this in production code, that's bad.
I'm not quite as enthusiastic about their choice of funding target. There are plenty of other worthy languages and tools out there that could use that money better in my mind. It's the C++/Java thing all over again, but stepped up several notches; to the point where it's creeping me out since I can't even mention C online without being attacked by the Rust Brigade; and they just don't give up, it's like one of those shitty zombie movies where you have squirting body fluids and jaws chopping at you from every angle. I don't think they need any more money; more like therapy, chill pills and rooms with soft walls/locked doors for a while.
This funding was for verification work, which was applied to Rust. Rust is a relatively new language, and hasn't been the focus of much research yet. C and C++, in contrast, has already been the subject of tons of research and tooling. For example, Wikipedia lists 28 static analysis tools for C, and none for Rust:
Is there a particular project for a particular language you think is promising and just needs some funding? Or does it just irk you when other people are happy?
EDIT: I'm also not sure why you assume that none of this EU funding is going to your language(s) of choice; have you checked?
From my knowledge, the ERC funds fundamental science. In my personal area (theoretical physics), people tend to move from Fortran to C++ nowadays. As an effect, mostly readability decreases (without linear algebra libraries) or the compiler doesn't help anymore with compile-time bound checks (so people use run-time bound checks with assertions instead). Not even to mention the years of wasted time for people finding bugs in their parallel codes. And all codes with the "HPC" badge are parallel nowadays. I think supporting a modern ecosystem is a good decision if people move away from C++ towards Rust or Julia (another ERC... http://opendreamkit.org/).
(Note: Please don't feed the trolls. Nobody has time for language rants)
How is questioning the choice of project to fund feeding trolls? I was under the impression that diversity was mostly considered a good thing, that has to go for perspectives as well. I just don't get why Rust desperately needs a lot more money than any other tool that's equally useful, they were already pretty well funded by other organizations.
This is one research grant on Rust among tons of grants on other projects. And it funds research. When somebody has equally valid research project on C, rest assured it’ll be funded as well, as it has already happened (EDIT) with research on abstract interpretation, separation logic and so on.
Right, question something and you just don't want others to be happy. Good luck with that. Every C compiler and major C library out there to begin with, given that it's the most important and fundamental language in the real world right now. C++ already pulled this trick, it lead nowhere but in circles.
This is a great place to engage in intellectually stimulating conversations. I, among many others, would love to read your objective thoughts about the fundraising choice.
Instead you've decided to facetiously label rustaceans as psychotic and mentally ill because they like sharing an upcoming technology.
I don't know what reaction you wanted but it won't be a positive one here.
Every C compiler and major C library out there to begin with, given that it's the most important and fundamental language in the real world right now. Did you get it this time?
Have you been living under a rock lately, or are you just pulling the oldest trick in the psychopath book; condemning others for reacting to abuse? Sharing and attacking others for not agreeing is not the same thing, I hope we agree so far.
C is fundamental and important now, but are you really not sick of it? Don't you wish we had a language that made it easier and more intuitive to program? Because many of us do. I'm personally rather tired of the boilerplate and legacy issues that come up when writing C -- Seriously, some of them being as simple as writing identical function signatures in multiple files.
It works but we live in a time where we can move on. We don't have to be discontent with an old technology. We have the momentum and community to, who knows, maybe even totally replace C one day.
People are already making games and servers out of Rust. I think that's huge and definitely worthy of further funding and research of all sorts; People are using this technology whether you like it or not!
Did you get it this time?
Anyway, I'm sorry to hear you felt abused for having a differing opinion on a forum somewhere. I understand how emotionally compromising it must be to have your opinions challenged! Hopefully people will treat you with great respect in the future and use C forever.
No, that's my point; there are thousands of very experienced and dedicated coders out there who are not sick of it; because we've been around long enough to not blame our tools, and we have enough experience to appreciate its unique strengths. I'm all for simpler and more intuitive, but Rust is the opposite of that; it's rigid and complex if anything. Why does everything have to be a competition? Why can't several technologies be allowed to coexist? This is not about having your opinions challenged, you need to work on your reading comprehension; this is about not attacking others for expressing different preferences from your own.
I would alternatively suggest you improve your conveyance of thoughts. It's clear now you have a rationalized and objective view of the situation, but it took us three or four replies to understand your underlying reasoning.
When you start a comment chain by needlessly bashing the users of technology X, and don't really support your opinion of them with anything factual, what are you hoping we read there? It feels like you want us to read between the lines and assume you have a better reason to bash them; That's mindreading, and unfortunately something none of us can do.
I think many Rust advocates, myself included, tend to foresee an eventual obsoletion of C because of theoretical overlapping purpose. We see Rust providing certain development luxuries without the usual heavy performance decrease accompanying them. While we can't say for sure, we think a majority of people will prefer having those luxuries in the future.
The most compelling thought for me is: In a world where Rust had more complete libraries, and most developers knew Rust instead of C, is there an incentive to learn and use C for new projects?
It's a complete matter of opinion but I think it's the reason most rustaceans "hound" on C devs. I don't think there would be such an incentive. I find them equally complex in their own ways, but also find more benefits with Rust versus C.
And not everyone who needs/wants that is going to prefer Rust's complexity and rigidness to the simplicity and flexibility of C, or the even more complex yet more flexible C++. It's preferences, priorities; not black or white; no one has any right to force anyone to do anything. As long as humans are in the loop we're going to have bugs, what kinds of bugs will depend on priorities.
Until we have as much code written in Rust as is currently implemented in C, experience hasn't shown anything. The same claims and promises have been made for C++ in relation to vanilla C for ages, and it's just not true. An experienced C coder (which arguably takes longer to achieve) will perform as good as a C++ coder of equal skill level. All they do is trade complexity and convenience for simplicity and flexibility; it's a matter of preference, not life and death.
This working group literally just proved that a significant subset of Rust is safer than any comparable subset of C++. This isn't a matter of opinion. What more proof do you actually want than a formal proof? I seriously wonder what people think the whole point of this paper was.
There's a lot of talk about full stack developers lately, I'm still waiting to find the first full stack manager. Someone who's visionary, yet realistic; confident, yet empathic; powerful, yet humble. I feel like there's some truth to the saying that the best leaders are those who don't consider themselves fit to lead.
I've seen a variety of managers doing bad jobs, and it never makes me think I could do it better. It makes me think about managerial problems, and how they are inherently difficult because of conflicts of interest.
On the other hand, I got tired of technical problems, because the real problems always seemed to be managerial where I worked.
It's not magic; it's vast amounts of experience; writing more code than, and twisting brains in ways that, normal people can't even imagine; and sticking with it for decades. I have no idea if I'm 5x or 10x or whatever, what I do know is that it's extremely rare to come across people who are more dedicated to the craft and/or have invested more in their skills.
