Programming a serious project in smalltalk

I'm thinking about writing an enterprise level software in smalltalk as opposed to something like C++. the reason being that it is much, much easier and clearer to work with than C++ or even Rust for that matter. the only con is the lack of third-party libraries, but this is the type of software where you would be writing everything from scratch anyways. Think something on the level of Unreal Engine 5. is this a crazy idea? I know that it's an old language but so is C++, except that smalltalk is way better designed than C++. it's much more coherent, and even dare say intelligent compared to the mess that is C++. and in theory it can be optimized when it comes to performance. I will be using a custom smalltalk implementation of course.

>>42833 >I will be using a custom smalltalk implementation of course. I don't know any Smalltalk but why not use Pharo? I was looking at the free books and the Pharo MOOC and it seemed to be the right way. Are you going to implement Smalltalk using the Blue Book or something else? P.S. I would appreciate any learning resources for Smalltalk.

>>42834 >I don't know any Smalltalk but why not use Pharo? Well, I'm also new to smalltalk. initially I'll be using Pharo. but I think for extensibility sake you'd eventually want a custom implementation.

I don't know your situation or your constraints, but I would definitely say: go for it. We don't get enough from well-designed languages, especially smaltalk. I think we should strive to make more and better software with it. Put another way, why would we choose to torment ourselves with the likes of C++ when we could choose Smalltalk? I can recommend "A Little Smalltalk" by Timothy Bud, which is about an implementation of a little smalltalk in C. Since you opened the smalltalk thread, I had thought of making a sort of hybrid lisp/smalltalk environment, that is, to implement a smalltalk-like environment in lisp using CLOS. I know their designs are somewhat different but maybe some point in between can be found.

>>42833 You mention Unreal Engine 5 and I'm curious: Do you intend for performance to match something like that, or are you just referencing it due to its size? Without real constraints or requirements its impossible to know if its a bad idea. That said, if performance isnt critical (as it is in graphics pipelines, HFT, rtc) then its unlikely you'll get a Smalltalk implementation, custom or not, fast enough to satisfy those use cases acceptably. But if performance is secondary or lower, as it usually is, there's mothing wrong with using Smalltalk. It's a great and odd little language. >>42839 I wouldn't doubt if CLOS is powerful enough to fully implement Smalltalk in it, and Lisp is already image based so that comes as a default. Only difficult step would be the graphical development environment, unless you choose text like GNU Smalltalk of course.

>>42840 >>42839 It's more akin to Blender than Unreal regarding size and capabilities. The emphasis isn't primarily on real-time, low-latency, or ultra-high-end graphics typical of games and game engines, although it does incorporate real-time networking for collaborative design. There is the possibility that it could grow into something akin to Unreal depending on the demands of the user-base. another thing is accurate real-time physics that is networked as well. that is a goal in mind. so as you see OO would be a perfect fit for this type of software.

>>42846 Math is, pretty generally, not Smalltalks strong suit. Given all numerals are represented as objects theres a lot of boxing going on and it isn't really practical for something like real-time physics imo. Could work of course, but using FFI to write optimized (ideally even SIMD enabled) physics pipelines that are used by a Smalltalk system would likely be much more resilient and performant. I still don't really know what you're making though, so its possible the slower math operations don't really matter.

>>42848 I mean, in terms of pure speed and data handling sure, OO in smalltalk style especially seems like it would present a lot of unnecessary overhead. but in reality it is perfectly suited for modelling physics or physical objects. you can always optimize later.

>>42852 As I said, I don't know what your performance criteria is. But it's not about the style, it's about memory representation. The fact that the numerals are all boxed can cause memory to rarely get cached in registers or cache lines, or for the values that do get cached to get replaced by the same value as the Smalltalk runtime cannot guarantee that they are the same. This is the entire reason why a VM like Java's has primitive, unboxed types that allow them to be represented in a more immediate form. I don't know if a Smalltalk implementation maintains implicit unboxing like Common Lisp's SBCL (since as far as I'm aware, there's little optimization you can do due to how you can arbitrarily adjust objects in Smalltalk at any time) but if there is then that can help to resolve the innate memory delay caused by boxed values. The point being is that there is no "optimize later" if Smalltalk's memory representation simply doesn't permit effective caching for complex, multi-step equations. But that doesn't really matter if your performance criteria allows slowdowns or delays.

Go for it. People may give you their opinion about a tool, but if the language clicked with what you are looking for, why do you need someone else's approval to give your vision the green light? What you should really be concerned about: What will your product offer that others do not? But... allow me to stir up a bit of discord: Keep in mind that way more developers know how to work with C++ against those who know how to use Smalltalk, which is more of a niche language. I mention this in case you decide to open source it or whatever. I hope I'm wrong, but I've noticed that using a little-known programming language causes many people to choose not to get involved with a project. Unfortunately, many don't understand that “popular” is not synonymous with “good.” But don't let that stop you; maybe your project will make Smalltalk popular again (you have to be optimistic about life). Whatever you do, I wish you every success and hope your idea goes far.