>>108810175
Pharo community is almost non-existent.
Smalltalk community (of which it's a derivative) is almost as small.
Zero jobs.
Dynamically typed (wrong side of history).
And despite its size, I can name several prominent devs who transitioned.
One of whom, regrettably, even 41%'d, despite having a wife and kids; this, after years of projecting an image on social media of being a happy, pink-haired, coding trans lesbian.

>>108810284
None of these are arguments

>>108810293
Having a tiny a community, no jobs, dynamic typing (considered a net negative by most devs now), and a tendency to disproportionately make devs transition aren't arguments?
If you think I'm joking about the trans thing, another one (also very capable, like the first) is Australian, and a type 1 diabetic.

>>108810344
You're literally saying it's bad for nonlanguage reasons. fucking assembly has jobs, doesn't means it's a good thing. you dumb aids monkey.

>>108810388
>doesn't means it's a good thing. you dumb aids monkey
Think for a moment: Pharo (and Smalltalk) are uber obscure, to the point that they're absent from all language popularity surveys and 99% of /g/ has never touched them, yet I can name multiple members of its tiny community who've "transitioned."
Doesn't that suggest that my opinion is informed enough, with enough experience, that it shouldn't be so quickly dismissed?
Meanwhile, what familiarity with any of this have you've demonstrated?

Proceed with exhibit B

>>108810175
even with a disgustingly complicated VM its slow as shit
not that pleasant to use
not pure
not interesting

>>108811616
Popularity is not a good metric given that most of humanity are shit eating monkeys.
you know how many people are capable of coming up with systems like smalltalk in the first place? hell, even people that can design lower level languages are rare. 99% of /g/ and humanity for that matter are morons that if not for the invention of ANY language would've happily stuck to coding in assembly.
and the trans thing... who the fuck cares you brain dead moron. I hope you get cartel-ed you dumb imbecile.
so you have no argument.

>>108811661
Nigger, fucking Unreal Engine is a goddamn VM at this point. and yet it is used everywhere and so is Unity and Google Chrome.
this isn't the 70s anymore, we can run virtualized software just fine

Pharo is fun until you have to figure out how to distribute a binary to other people who don't use Pharo.

>>108811759
Yeah it's so hard to just ship the vm... like you do with dotnet and jvm.

>>108811783
>ship the vm
ick, just let me build a static binary

>>108811692
>we can
Just because it's possible and other people do it, doesn't say anything about whether we should or not. The choice of doing that should be justified and expressed if you want to convince anyone.

>>108811852
Modern software has rendered this question irrelevant. nobody cares anymore, hardware is fast and virtualized software is bound to get more efficient in time even on older hardware.
C++ is used to write software that is by definition what would've been considered a VM just a few decades ago. Windows, Google Chrome, Firefox, Unreal Engine, Unity, the many many softwares written in JavaScript, Python and C# are all virtualized. you have decades of catching up on the industry to do grandpa. The benefits of high level languages outweigh the pros of compiled languages by eons.

>>108811887
You just repeated your last post but in more words.
I won't do that I will just refer back to mine for reconsideration >>108811852

>>108811903
The idea here is that you are giving useful abstraction away for speed. that is the only thing compiled languages give you.
and given that it is possible to optimize VMs and given that hardware it self can change to accommodate those changes, this leads us to conclude that compiled languages would almost entirely be left in the dust eventually. occupying a small niche as bootloaders for higher-level systems and languages. this is a prediction claim I'm making. and it should be easy to see that abstraction is the future of compute. the many benefits of high-level systems simply outweigh the fine low-level control that compiled languages give you. the future of those languages is for optimization only, written applications or useful software would eventually only be written in high-level languages. it is already the case somewhat.

>>108811921
This is predicated on binaries.
What you just wrote applies when distributing source code.
Compilers advance no different than vms and the benefits mentioned come from the reinterpretation. The only difference between them for this point is when a vm decides to reinterpret code. You could just as easily rebuild a compiled program for a new platform with a new compiler no different than you would reinterpret a jar on a new jvm.
Likewise with tracing at runtime.

>>108811942
There are things you can't get from compiled languages. like in the example from the OP where you can edit the system in real-time.
there is no save->compile->wait-for-compilation->run
in Smalltalk it is just edit->see-result-now
that's a level of prototyping not possible with say C++. I mean, I think there are some C/C++ debuggers that sort of emulate this but this is not the point.

>>108811984
Being able to edit code in real time is nowhere near as useful as you think it is
VM-based programming languages are slow and this is only becoming a bigger issue because processors aren't really getting faster
The way forward is compiled languages that actually compile quickly, because there's big gains to be made there, compilers can be 10-100 times faster than they currently are

File: 1768573270111.jpg (74 KB, 819x1024)

74 KB JPG

>>108810175
>C++
Cmon, that's like shooting fish in a barrel. On top of loads of boilerplate syntax and retarded defaults baked into the language, needless verbosity is enforced by the community as well.
>https://stackoverflow.com/questions/1452721/whats-the-problem-with-using-namespace-std
>Implicitly using 1 namespace is bad...because implicitly using 2 namespaces might cause a conflict
Hate reading other people's C++ because it always looks like unreadable garbage.

>>108812182
Pure languages offer other advantages: metaprogramming can come "for free" (as in Lisp) while keeping a small, uniform mathematical syntax. Rapid prototyping—already mentioned—shouldn’t be underestimated; it’s a major productivity gain. With pure languages you can model real-world problems naturally using both object-oriented and functional approaches. Because the program is pure, it’s straightforward to gather runtime statistics without writing convoluted instrumentation to extract data from a live system. You can also compile high-level languages, but that’s a tangent: the real distinction here is pure vs. impure languages. The programmer’s experience is richer with pure languages, which enable smarter, more reactive live systems.
you're throwing all of this away for raw speed. which you can still technically get with pure language compilers anyhow.

>>108812691
pure languages have nothing to do with metaprogramming, lisp isn't pure. Assuming you mean pure as in functional purity
rapid programming is good but there's rapid as in "compiles in less than a second" and rapid as in "I can edit the code while the program is running"
You don't need the second

>>108812182
>Being able to edit code in real time is nowhere near as useful as you think it is
provide an objective argument for this that doesn't boil down to "i'm a super mega genius so i don't need nice things"

>>108812699
Of course you do, you're deluding yourself if you believe that you don't. Take gamedev as a prime example. nothing beats being able to see the result of your code on work it self out in the game world immediately

>>108812704
Like I said here >>108812699 you can just have a program that compiles fast instead of directly editing the code at runtime

>>108812710
A game is a complex state machine which you can easily break completely by editing the code while it's running

>>108812714
i'm not asking you to explain why compilers that aren't dogshit are a good thing, i am asking you to explain why real time editing is simply not useful.
besides, you can literally have both. SBCL for example is a native AOT compiler that also supports interactive development

>>108812714
Or you can have a program that displays immediately, as you're modifying the code. you can even see the values change while you're still deciding on the exact values or even code structure.
why give yourself an input delay of a few seconds to hours with compile time? depending on the codebase size. you can also get fancy visual debugging tools for free which accelerate development more than anything else.

>>108812729
>Or you can have a program that displays immediately, as you're modifying the code
You can have a bunch of objects already instantiated, and you want to change the way things work so you modify the objects data layout and immediately the whole program crashes
The only thing it's useful for is tweaking single values or things that have no dependent effects, and you can just use data files for that you don't need dynamic coding

>>108812735
>and you can just use data files for that you don't need dynamic coding
But you have to manually code that for every project from scratch and come up with a format or use a thirdparty one which you have to again manually integrate. you can actually have that built-in AND it would use the same syntax as the language itself if we're talking about a homoiconic language. another problem with impure languages is that you're not getting proper objects for example

>>108811686
he does have a point though. it's making people trune out like rust. and without going into excessive detail, what that essentially indicates is that it's an anti-language. it defines itself by what it is against, not by what it is. That is, it identifies a valid problem in the space (compilation times) and then throws everything else out the window the same way a programmer throws the rest of his project out the window to debug something.

and like you said, you have to be pretty high level to develop this stuff, so when you pair that with a small community it means a lot more work on your part. building things from scratch that would come prebuilt from a library in other languages. suddenly waiting for a compile isn't so bad.

and if you're one of those guys who is going to be like 'screw you, I'll do that anyway even though I don't have to because I'm a genius and I'll build the framework that will change the way programming works for everyone...' then pursuing that will put you at a SEVERE risk of trooning out. your mind will snap and you'll go the full 9 yards with giant plastic tits because you will have literally made yourself go insane with autism

>>108812754
Reading a value from a data file is extremely simple
What are you talking about pure languages, do you mean functionally pure or something else?

>>108810175
Define "pure language".

>>108812767
Pure language where all of the language basic computational units are made of the same thing. no 10 random different primitives or where control flow is also an all together separate system.

so with Smalltalk everything is an object including if statements

>>108812779
You're going to have to be more specific there, every language as different types of things, be it floats or integers at the most basic level

File: 9o0jax-186704588.jpg (3 KB, 150x150)

3 KB JPG

>>108812763
...

>>108812781
Well Smalltalk doesn't. everything is an object.
variables are objects "if" is an object.

>>108812791
define object

>>108812779
>Pure language where all of the language basic computational units are made of the same thing.
This doesn't mean anything.

>>108812792
Object in the programming sense usually means data coupled together under a single internal state. so a C struct is loosely an object. as a unit.
from a relational point it also means it inherits data from other objects and can communicate to other objects through messages to change their internal state.

>>108810175
this seems like a useless level of abstraction, I can already open a board by clicking a button, why add extra steps?

>>108812814
Yes but it's done in a shitty hacky way.
modern Windows only copied what Xerox did with Smalltalk in a very shallow sense.
from the user experience you almost can't tell. but internally it is not the same at all.

>>108810284
>>108810344
>>108811616
rents free

File: 1737420627853075.jpg (14 KB, 300x300)

14 KB JPG

I tried using Pharo on arch and it kept crashing all the time. I thought that it must have been arch problem so I booted up windows and while the crashes were less frequent they sure happened all the same.

>>108812792
data abstraction technique where the data (the attributes) are hidden by a set of operations (the interface). an object is both the attributes and the interface (unlike an abstract data type).

>>108812735
>You can have a bunch of objects already instantiated, and you want to change the way things work so you modify the objects data layout and immediately the whole program crashes
in smalltalk, objects are sending/receiving messages, the internal data layout doesn't matter at all. it's like actors in erlang.

Threadly reminder: if you have getters and setters, you are not using real objects.

>>108813130
you are. getters/setters allow you to hide the data under an interface, enabling all kind of interface abstraction techniques (a.k.a design patterns).

>>108813147
>it's "hidden" because instead of foo.x=y you have to do foo.setX(y)
Cargo cult programming.

>>108813124
The internal data layout does matter because if you change it the program will crash, unless the language is entirely dynamic and uses hash tables for fields like lua

>>108813160
again, smalltalk relies on messaging, there is no field. an object handle the messages by itself. it's a complete black box.

>>108813151
it's not about the syntax but about having and dealing with interfaces instead of data. for example, the observer pattern can only work if an object doesn't allow direct access to its attributes.

>>108813151
Think about inheritance.

>>108813188
>for example, the observer pattern can only work if an object doesn't allow direct access to its attributes.
That's obviously false. Are you brown or what?

>>108813196
>Think about inheritance.
Ok. What about it?

>>108813174
internally they still have fields

>>108813230
>internally
yes and? only the object is aware of its layout.

>>108813235
and if you change that layout at runtime the program will crash

>>108813225
https://en.wikipedia.org/wiki/Observer_pattern

please tell me how an object is made aware of any state change if the attributes are modified outside of the object interface.

>>108813229
An object may inherit or re-implement setters and getters. Here a small example in pseudo code

Interface Rectangle:
  getX(x)
  setX(x)
  getY(y)
  setY(y)
  getArea()
  
  
class RectangleLazy implements Rectangle:
  int x
  int y
  
  setX(x):
    this.x = x
  
  getX()
    return this.x
    
  setY(y):
    this.y = y
  
  getY()
    return this.y
    
  getArea()
    return this.x * this.y
    
    
class RectangleCached inherits RectangleLazy
  int area
  
  cacheArea():
    this.area = this.x * this.y
    
  setX(x):
    this.x = x
    cacheArea()
    
  setY(y):
    this.y = y
    cacheArea()
    
  getArea():
    return this.area

>>108813248
By using any language that lets you define the semantics of a property read/write. OOP users always labor under the false premise that the only way to do a thing is the strictly inferior and crippled way offered by their paradigm, but your observer pattern argument is tangential to my point: if your bundle of data is a genuine object, how come other objects are setting its state?

>>108813276
>An object may inherit or re-implement setters and getters.
Why is this desirable and what does it negate the fact that your supposed object's guts are still leaking and the world can play around with them?

>>108813296
Nothing is leaking, attributes are private. Only the interface Rectangle matter here. You may even do a factory to avoid dependency on its implementations.

>>108813326
>Nothing is leaking
Then how come random external code can set your object's internal state? Caveman-tier magical thinking never went away.

I don't get it. So it's a language for you to make minesweeper games really easily?

>>108813332
What are you even talking about? No code can't access the attributes here, wtf.

>>108813346
You're crippled in the mind. In a very literal, clinical sense. You have a mental deficiency. You write a subroutine that writes to an "internal" piece of data, then you get completely baffled by the idea of external code using it to do just that, believing that adding one level of indirection to it somehow changes the meaning of the outcome.

>>108810175
Man, you suck at minesweeper.

>>108810284
pharo is trannyware? (or used to be)

>>108810284
There's usecase for both static and dynamic typing, it's one of the stupidest wars in tech the factions are too stupid and stunted to see beyond their own needs

>>108813372
It's not a subroutine, we are not writing assembly. It's a method. You obviously lack basic knowledge about OOP and software engineering.

>it somehow changes the meaning of the outcome.
Yes it does, for obvious reasons. Considering the above code:

Rectangle a = new RectangleLazy()
Rectangle b = new RectangleCached()

a.setX(3); a.setY(4)
b.setX(3); b.setY(4)

a.getArea() == b.getArea() // true

a.setX(5);
b.x = 5;

a.getArea() == b.getArea() // false

>>108813413
>It's not a subroutine
Kek. Crippled in the mind, like I said.

I wonder if POOmonkeys ever reflect on why they're forced to use setters in the first place. Does it ever occur to them that if an object's "own" properties are set externally and are subject to external invariants, then those properties actually characterize some overarching system rather than that object?

>>108813527
>POOmonkeys
>reflect
only when they use smalltalk

>>108810175

Where can I download a ISO for smalltalk on the metal? freebsd icewm firefox here

>>108810284

you sound like a rust or clojure user
maybe julia

how close am I?

>>108810344
try the mooc

https://mooc.pharo.org/

aidaweb.si

https://github.com/seasidest/seaside

https://youtu.be/E3eDDSPCf7c?si=OB1yOAh170z2d5tR

File: 1777925755352p.png (822 KB, 1536x890)

822 KB PNG

>>108814959
A Clojuresista wouldn't be against dynamic typing THOUGH

>>108810175
don't know what picrel is supposed to be, but it looks like TempleOS-tier schizoware.

>>108813130
problem isn't having getters and setters at all; it's what they're intended for
if you just out of principle make fields private and then add public getters and setters that allow freely setting the value of a field of that object, that's indeed pointless - just use public fields

>>108813527
>why they're forced to use setters in the first place
it's a result of bad teaching
pretty much all teachers can't program themselves - if they could, they would go work as programmers and not teachers

>>108811686
I have code in both the Pharo and Squeak images, the VM (admittedly not much) and was the primary dev for years of one of its most popular libraries.
You, on the other hand, seem to have just discovered this.
Pharo abandoned Monticello in favor of Git (which doesn't track code at the granularity of a method, so they lost method-level history), made a github account mandatory, and deprecated mailing lists in favor of Discord, and it's done fuck-all to increase the popularity of the language.
If Pharo hasn't taken off by now, it never will.
Even if they added gradual typing, VSCode integration or other trendy shit, it's still "old" tech that will never be "hip."
And LLMs have probably reduced its value proposition substantially in the prototyping and RAD space.
>>108814959
What about my (tactfully) transphobic posts led you to believe I'm a Rust programmer?
At this point I use modern C++ wherever I can.

>>108813296
>Why is this desirable
you can then provide different implementations of the same interface of getters/setters. for example, an extending class could be mapped to some database or web service and read/write values using a remote location, rather than just a field on the object

>what does it negate the fact that your supposed object's guts are still leaking and the world can play around with them?
depending on what the object actually does, what's its context and how long its lifespan is, this might be a complete non-concern
for example, a Parameter Object instantiated shortly before using it as a single parameter for a method is unlikely to cause issues related to leaking state

>>108810175
with gtk3 https://rmod-files.lille.inria.fr/Videos/fosdem/gtk-spec-live.mp4

this the power of repl+gui. now we have html5 which is not different but for some reason /g/ look down on webdev and things like electron.

>>108811692
reading comprehension, anon

>>108810284
Dynamically typed is actually the right side of history. Strong vs weak is easier: everyone agrees strong is the right way. But the only people who complain about dynamic don't know what dynamic typing even is, they always confuse weak with dynamic, and assume javascript is the only language that is dynamic and so ascribe js-specific flaws to dynamic typing, which is just not how it works. For example, the oft-quoted difficulty of dynamically typed languages to tell you in advance about typos, but actually many languages, including lua and common lisp, do just this, despite dynamic typing.

The wrong side of history is no correctness validation. But types are the wrong construct for this. The Tigerbeetle team use a thing they call 'tiger style' which is gayspeak for: they write asserts for all inputs and all outputs of each function. If you program this way, obviously types become useless (even though they use zig, which is typed, they clearly have no benefits there).
If you just use basic types instead of complex type hierarchies, you do not benefit from types.
If you use complex type hierarchies, they will be buggy and ill designed unless you planned them well.
Planning is something that is only viable if requirements are preset, at which point you should be using tests (ala TDD) rather than a complex type hierarchy, because the type hierarchy won't be enough as they are either too complex (coq-style) or too simple (everything else). There's a rust, which has a relatively simple type system yet more involved than garbage like java or c, is known only for 'rewrite it in rust' projects: only projects where you already have the spec are amenable to the use of such type systems.
Asserts are an alternative to tests that have pros and cons. Overall, I believe the right solution is an annotation system that's a bit in the middle between tests and asserts (validation should be closer to code, but not in prod, and more case/logical than types).

>>108815900
This. The clojure dictator in chief routinely gives talks about how dynamic typing is the way to go and static typing is a meme. Clojurefags can't possibly be against dynamic typing.

>>108818992
It's very different. This video is similar to the lisp + cepl experience: extremely powerful to a level people who haven't tried can't comprehend. It's truly mindblowing what you can do with these kinds of workflows. Webshit uses hackarounds with specialized dev servers with websocket connections on the client and file watchers to serve changes, and these changes often go stale because of things like caching issues. They also don't manage state correctly, because they were not built for this, often requiring full reloads to test things.

>>108819905
>they write asserts for all inputs and all outputs of each function. If you program this way, obviously types become useless
the whole point of having types in the first place is not to have to explicitly assert everything everywhere

>>108819937
And my point is that types are either not powerful enough to replace asserts, or it is too complex for the programmer to express the invariants in the type system to the point people don't do it in practice. Asserts somehow manage to remain simple enough for actual real-world use, while also being more powerful than correspondingly simple type disciplines.

assert abs(a-b) <= 0.5, "${__fn_name__} ${__file__}:${__line__} Distance out of range"

Try the above in a type system. The 3 key issues:
- Concise expression of "complex" test conditions
- Good error messages making it easy to identify the actual fault rather than 5 pages of type errors
- Optionality (you can start without these asserts and only add them after you are happy with the function body, etc.)

I don't know any type system that can do all 3. Most can't even do the first 2, and none that I know that can do the 1st one can do the 3rd as well.

I argue that any type system that can do all 3 is no longer a type system, but an assertion annotation system. If you think otherwise (i.e. if you see asserts like these as being an ad-hoc type system) then it's more a semantic argument than anything.

>>108819905
I think the truth is somewhere in the middle. Dynamic typing of common lisp and contracts work well enough for me.

However, I think that types are useful not just for correctness. In many cases they help model the domain.

I mean Hindley-Milner type system specifically and those that share some of its features. The downside is that the resulting domain model, although precise, becomes very rigid at some point unless you bring in bizarre functional abstractions.

>>108819984
>In many cases they help model the domain.
My argument is that modeling the domain is something that only becomes relevant once the domain is well defined. This is seldom the case, and when the model breaks down, it is often required to rewrite the scaffolding used to establish it in the first place.
Hence, if the system is already well-defined, I argue that the proper approach is tests, because it models much more than types can, and are easier to throw away than types are.
I don't disagree, however, with the overall premise that "structural annotations help model the domain, and domain modeling can help ensure a cleaner code architecture". Mostly my argument is about the type (heh) of annotations that ought to be used. The reason I then say that dynamic typing is correct is not in opposition to structural annotations, but rather in opposition to the very specific structural annotation system that is implied by types.

Exactly like you say, hindley-milner-based type systems end up with extreme amount of ceremony to work AROUND the type system once the program becomes somewhat complex, and god help you if any of your dependencies decide to even slightly modify the type contracts used as the mandatory constant wrapping and unwrapping of fields to satisfy type constraints even though you're really only interested in passing around the underlying data means that such changes cascade through the entire codebase.

Actually I should add one more thing to >>108819968

Granularity.

Asserts can be far more granular than types typically are. E.g. you can assert that a has a field called x and that it has a value in a range, and you don't give a shit if a also has a field called w, or if the field changes from small int to big int, or anything like that.

>>108811887
>Windows, Google Chrome, Firefox, Unreal Engine, Unity, the many many softwares written in JavaScript, Python and C# are all virtualized.
And way too many of them are total shit, both in terms of bugs and performance. Like sure, there might be fewer segfaults and system crashes on average but there's shit in Windows that is absolutely retarded slow. Just opening the god damn file manager takes hundreds of milliseconds. And this is all while being insanely gluttonous with memory. Modern Operating Systems and these ""virtual machines"" jump through all kinds of ridiculous hoops to hide all the wasted memory (which translates into slow performance when stale content has to be reloaded). This is before we even get into all the fucking calls out to remote services.

Unreal is a modern engine designed and heavily-optimized for 3D graphics performance and gaming, and it's stupid to compare to random other runtimes that just happen to b e evolved from accidents of computing history like Javascript (which is an insane frankenstein monster of a language ecosystem).

There are scenarios fit for dynamic types and scenarios where it really matters how your program and data are laid out in memory, whether its done explicitly or through structuring your program so the compiler can optimize it effectively.