21–30 of 74 posts
I don't use it because at this point it's alien in the world of modern computers. Back when Smalltalk was in its prime it wasn't just a programming language, it was essentially your operating system, complete with its own graphics system, window manager, etc. This hasn't changed, but instead of being the basis of your system it's essentially another OS running on top of whatever your poison of choice is. I think toda…
A lot of times people like the idea of a thing more than the thing. Meanwhile, a lot a people hate on C++, which they're only able to do because they learned its nuanced spec, which they only did because it had already reached critical mass in the wild, because it worked everywhere and was, despite the complaints, comprehensible, if hard to get perfect in the language-lawyer way.
Now, as a follow-up: is anything holding back Rust?
Earlier quoted context omitted.
You have to have a metric for 'better'. If its 'utility' then yes something popular is better than something unused.
You're either saying something that is tautologically true (more popular things have more "utility" because they're used more because they're more popular), or is clearly false by any metric that a majority of experts in CS or language design, or even industry professionals, would agree on.
Something that isn't used at all (or much) has very low utility.
I don't use it because at this point it's alien in the world of modern computers. Back when Smalltalk was in its prime it wasn't just a programming language, it was essentially your operating system, complete with its own graphics system, window manager, etc. This hasn't changed, but instead of being the basis of your system it's essentially another OS running on top of whatever your poison of choice is. I think toda…
[deleted]
I recently tried out Pharo with a simple, achievable goal in any language worth using these days: fetch a document from a website, parse it, and display all the href's with titles. It was a very pleasing experience!
I basically evaluated the code I'd expect to use to fire up this application in a scratch area. Naturally it didn't work. It dropped me into an interactive debugging session. From there I just started writing and compiling the missing methods and objects. I kept doing this until my original evaluation just started working. No recompilations or context switches between editors and compilers and the like. Best of all I could just close down the image and take a break. When I booted it back up everything was right where I left it.
If given the opportunity to use it on a project I'd give it a shot. It was one of the most refreshing computing experiences I've had since I got hooked on Common Lisp.
I worked in a Smalltalk shop, smalltalk is not that great. I've discussed it at length, my problems with it. As a language it is impressive what they built at the time. In practice it was a terrible pain in the ass with tons of "ravioli" code everywhere. The language has no qualms with letting you wreck havoc within the standard base classes, which makes integrating anothers code almost impossible.
Oh I do want to add that it is a language behind a paywall as well. Which i find rather strange. Being charged as a customer to one) use their language and two) being charged per user we allowed into the environment. Because Smalltalk is an enclosed runtime (similar to Java, but much worse). We had to tell them how many users would be using non-developer editions of the runtime and they charged us for that.
Open source kind of killed this way the industry used to work forcing companies to find other ways of revenue, except for big corporations that kind of still work this way.
A lot of times people like the idea of a thing more than the thing. Meanwhile, a lot a people hate on C++, which they're only able to do because they learned its nuanced spec, which they only did because it had already reached critical mass in the wild, because it worked everywhere and was, despite the complaints, comprehensible, if hard to get perfect in the language-lawyer way.
This argument reduces to saying that anything popular and widely used is actually better than anything unpopular but beloved by language enthusiasts. This simply isn't the case. Many, many factors beyond merit contribute to language popularity and usage.
Earlier quoted context omitted.
Now, as a follow-up: is anything holding back Rust?
Anyone who understands Rust's good points (and there are many) is probably already using Haskell. What compelling advantage does Rust have over Haskell to justify the cost of switching (and, more importantly, the cost of losing higher-kinded types, and of adding macros)? Manual memory management is unlikely to be enough.
Earlier quoted context omitted.
Now, as a follow-up: is anything holding back Rust?
Anyone who understands Rust's good points (and there are many) is probably already using Haskell. What compelling advantage does Rust have over Haskell to justify the cost of switching (and, more importantly, the cost of losing higher-kinded types, and of adding macros)? Manual memory management is unlikely to be enough.
Rust bridges the gap between industry C++ programmers with the ideas of Haskell. Sure you might not see a lot of codebases migrated from Haskell to Rust (not that there are a massive amount of anyway), but you will likely see C++ codebases migrated over to it, and Haskell programmers that want their library to be widely used may start greenfied projects in Rust instead of Haskell.
You are looking at it from a Haskell -> Rust conversion cycle, when that isn't really important from either a numbers standpoint or how Rust is positioning itself.