Without ever practically using this system, my first impression is that this is how mech operating systems would have to be.
At a certain complexity of vehicle, you would need all of: manufacturer base features/diagnostics, safe-mode control, an open market of source code to add in, pilot preferences, and then real nerd stuff where you customize in your own routines. All the while being able to explore a live running system as it is running without having to trust closed binary only software.
Of course the world we live in would never go this way, proprietary unknowable, pre-government hacked, unrepairable trash it is for us.
Pharo 12
91–100 of 116 posts
Re: Pharo 12
#92Earlier quoted context omitted.
> i have actively explored working with pharo. Then you must already know more than me, about what's available now. Too much? https://github.com/feenkcom/gtoolkit > … given the image based development you tend to start with a current version of pharo and then keep to that version until you are done. I think of it as image based development: not image based version control.
what do you mean by image based version control? i mean the lack of version control inside the image can be considered a problem, as you have to connect to external tools go get it, lest you save a copy of the image as a version (which is what i would call image based version control), which that is not practical at all. but that is not what i meant. i was talking about the problem that when i develop an application…
> that amounts to a lot of work
Why? Are you making a lot of changes that conflict with the distro?
"Guideline 120 Avoid modifying the existing behavior of base system classes." :-)
1996 Smalltalk with Style page 95
https://rmod-files.lille.inria.fr/FreeBooks/WithStyle/Smallt...
Re: Pharo 12
#93Earlier quoted context omitted.
Yes last time I checked they had their own versioning system as well... it's one thing to learn a language but having to learn a whole new set of tools put me off in the end. I guess I can see the argument that the Smalltalk files are not plain text but rather images (or something), but having to basically download a second OS within the OS just to write Hello World was off putting. I realise that that's also can mak…
Funnily enough, I'd compare the image and versioning differences to managing Postgres rather than non-image based languages. Postgres has to deal with images (backups) and versions (migrations). Maybe selling image-based systems in both cases needs a little work or formalisation (best practices and all that)? Image-based systems seem more about data management rather than code management. Just some random thoughts
In the beginning source code in text files :-)
"Within each project, a set of changes you make to class descriptions is maintained. … Using a browser view of this set of changes, you can find out what you have been doing. Also, you can use the set of changes to create an external file containing descriptions of the modifications you have made to the system so that you can share your work with other users."
1984 "Smalltalk-80 The Interactive Programming Environment" page 46
"At the outset of a project involving two or more programmers: Do assign a member of the team to be the version manager. … The responsibilities of the version manager consist of collecting and cataloging code files submitted by all members of the team, periodically building a new system image incorporating all submitted code files, and releasing the image for use by the team. The version manager stores the current release and all code files for that release in a central place, allowing team members read access, and disallowing write access for anyone except the version manager."
1984 "Smalltalk-80 The Interactive Programming Environment" page 500
https://rmod-files.lille.inria.fr/FreeBooks/TheInteractivePr...
Re: Pharo 12
#94Earlier quoted context omitted.
what do you mean by image based version control? i mean the lack of version control inside the image can be considered a problem, as you have to connect to external tools go get it, lest you save a copy of the image as a version (which is what i would call image based version control), which that is not practical at all. but that is not what i meant. i was talking about the problem that when i develop an application…
> that amounts to a lot of work Why? Are you making a lot of changes that conflict with the distro? "Guideline 120 Avoid modifying the existing behavior of base system classes." :-) 1996 Smalltalk with Style page 95 https://rmod-files.lille.inria.fr/FreeBooks/WithStyle/Smallt...
it's not the code conflicts, but all the modifications i made to the environment. addons i installed, configurations i changed, windows i opened, code snippets i have in a workspace/playground. pharo is to much like a desktop, and switching to a new version of pharo is like reinstalling my computer and setting up my desktop from scratch.
there is no tool that would just take every change i made to the original pharo image and apply it to the new one.
you know like docker where your base image is immutable and changes to that image are saved in a separate image that is layered on top. so that you can replace the base image while keeping your changes.
Re: Pharo 12
#95I started a new job in Smalltalk one year ago without any previous experience with the language (background in Scheme, a bit of Common Lisp / Clojure, C, C++, Java, Python, Haskell and a couple of other languages). I had three pair programming sessions in the beginning and that was it, it took me one month to get a grasp of the codebase I have to maintain/develop further. The application is huge, but the tooling and…
This top comment is stark contrast to the one right below it. I guess pure oo is a love hate thing
Re: Pharo 12
#96I check every release hoping that they finally fixed rendering for HiDPI. Guess I'll have to keep waiting.
Re: Pharo 12
#97Weirdest programming language/IDE/Runtime/everything I've ever attempted learning. The sheer oddity + lack of real world example code floating around made it feel impenetrable. To put it into perspective, picking up Rust and writing entry level but real world applications was a walk in the park after coming to terms with the ownership system.
How would you compare this to say, writing WinForm applications in Visual Basic 6?
Re: Pharo 12
#98I check every release hoping that they finally fixed rendering for HiDPI. Guess I'll have to keep waiting.
i ran into this problem too. i was able to make it mostly work by changing the font size.
Re: Pharo 12
#99Earlier quoted context omitted.
Pretty sure Pharo has had GPU-support for a long time, and there's RoarVM for "manycore" applications in Smalltalk.
> Pharo has had GPU-support for a long time For highly parallel general-purpose computations? Tell us more! https://chapel-lang.org/docs/technotes/gpu.html As-already stated in this discussion RoarVM "hasn't been touched in over 10 years". This discussion is about the Pharo 12 release and supposedly RoarVM is "compatible with Squeak 4.1 and Pharo 1.2 ". https://github.com/smarr/RoarVM
Kinda weird to move the goal posts like this.
Re: Pharo 12
#100I started a new job in Smalltalk one year ago without any previous experience with the language (background in Scheme, a bit of Common Lisp / Clojure, C, C++, Java, Python, Haskell and a couple of other languages). I had three pair programming sessions in the beginning and that was it, it took me one month to get a grasp of the codebase I have to maintain/develop further. The application is huge, but the tooling and…
This top comment is stark contrast to the one right below it. I guess pure oo is a love hate thing
I used to dislike OOP and favor functional programming languages, until I started working with Smalltalk. I guess the fact that blocks are closures and also first-class objects make up the difference somehow. I learned that programming paradigm is not the main factor I appreciate in a language, but also the elegant/coherent design, simplicity, liveness of the programming environment etc.
Also since most of the time developers spend debugging programmings, today I think languages should be designed with improved debugging features in mind. Statically programming languages are doing great progress here (always heard great things about error messages from Rust). Smalltalk and Common Lisp OTH, besides having nice error messages, also have exceptions with resumable semantics. The hability to always get a debugger during an exception without unwinding the stack is such a huge help (specially for dynamic languages), allowing one to fix a running program and continue working.
I maintain/develop a complex Smalltalk GUI desktop application and rarely restart it during development (which always take a while, since stuff like connecting and loading data from the database takes some time). Also I can always fire up the debugger to inspect objects I want to change (like dialogs etc), edit code and run it in any frame of the stack (like a REPL everywhere) etc. Maintaining this codebase in a dynamic programming language with exceptions that use the traditional termination model would be a nightmare, every crash would require a restart, and you don't have a compiler to help you. It's no surprise that people just turned to statically typing for this kind of system.