9 ms·
Objective-Smalltalk
- stesch 13y agoSee the last time this was discussed on Hacker News: https://news.ycombinator.com/item?id=6917740 https://news.ycombinator.com/item?id=6917740
- davesims 13y agoThis is pretty unhelpful as this (your) submission wasn't discussed at all.
- weddpros 13y agoAs a long time Smalltalk lover, I can only UP this project ! I'll have no use for it immediately, but it's good to know where it can be found.
- mseepgood 13y agoWhat's next? "Functional lambda calculus"?
- mpweiher 13y agoCreator here. Yes, the name is half joke, half serious. Gotta have some fun :-) At one point I was going to call it just "Objective-", but that seemed like going a bit too far.
- stcredzero 13y agoI would have called it Objective. That way, when the press asks, "What is your objective?" you just show them.
- skittles 13y agoThe readme has a typo: dervied should be derived
- k__ 13y agoHow about crappy PHP? :P
- mpweiher 13y agoBut you repeat yourself? :-P
- jhenahan 13y agoI think they missed the opportunity for a pun with Self[1]. [1]: http://selflanguage.org/ http://selflanguage.org/
- gojomo 13y ago"C with Pointers" "Javascript for the Browser" "Structured Query SQL Language"
- tomjakubowski 13y ago> "Javascript for the Browser" Unfortunately not so redundant these days.
- protomyth 13y agoF-Script is another project that brings Smalltalk syntax (with extensions) to OS X. It has active forks and some neat array processing.
- sebastianconcpt 13y agoSo Objective-C with an unpolluted syntax. That could be nice!
- stcredzero 13y agoSo Objective-C with an unpolluted syntax. Otherwise known as Smalltalk.
- rtpg 13y agoAre there any smalltalk fans out here that can point out to the unenlightened the "interesting" aspects of Smalltalk? It seems to have quite the following.
- weddpros 13y agoPros: Smalltalk is a very simple object oriented language, dynamically typed and GCed, it has closures (used everywhere!). It has NO keywords at all, and a very simple syntax. Smalltalk is very readable. It also has amazing IDEs/debuggers. It's very easy to learn. And it was born in 1972, just like me! Cons: aging technology with very little traction, no fast VM (compared to JVM), no multithreading... I switched to Java in 1996 because the future of Smalltalk was cloudy. I'd switch back to Smalltalk if it could run with the same performance as Java. It's a really amazing language.
- stcredzero 13y agono fast VM (compared to JVM), no multithreading Back in 1996 Smalltalk VMs were still outperforming Java VMs on real workloads, in large part due to not having multithreading. (Makes GC simpler and faster.) Also, there were multithreaded Smalltalks around.
- weddpros 13y agoYes, Java had no JIT in 1996... But it had corporate traction, and good marketing ("it's an internet technology!"). Nowadays, I choose the language I want to work with, but I don't switch back to Stk because of speed.
- pjmlp 13y agoYes, I got to play with VisualWorks at the university that time, but then Java took over the enterprise.
- kilon 13y agoPharo and Squeak use the CogVM , its a VM that supports JIT compilation and as such is very fast. Its not as fast as Java because afterall Java is static typed. However there is a way to get even faster than JAVA code. Pharo comes with a library named "Nativeboost". Nativeboost is essentially an inline assembler. But unlike C/C++'s inline assembler of using assembly syntax, the inline assembler of Nativeboost uses Pharo syntax as each assembly command is a Pharo object like everything inside Pharo. Also because VM will stop all execution when it executes assembly code, you can enjoy raw machine code speed. Thus you can have Pharo code that can outperform Java code. If Assembly is not your thing , Nativeboost can be used also as a FFI to call C dynamic libraries. Currently C++ is not support because of name mangling but its possible to compile a C++ library as C library to be used by Pharo. Also Nativeboost's FFI offers support for Objective C as well. There are also two projects to run smalltalk on Java, one is called redline smalltalk, the other's name eludes me now. There is also another project to bring Smalltalk to Java including even the Smalltalk IDE called "RTalk". But that project seems to be vaporware for now.
- eonil 13y agoInteresting. I had a quick look, but I don't see any mention about memory management. Because it must have fully deterministic realtime aware architecture to replace or complement Objective-C, and memory management strategy is one of the most important stuff. If it's based on typical (non-deterministic) GC, then it won't be that much interesting anymore. Also, I think using `<-` instead of `:=` would be better for a new Smalltalk dialect. With proper editor support, the arrow sign will look far better then colon-equal sign.
- mpweiher 13y ago"deterministic [..] architecture" Yes, important point and one of the fundamental design consideration. Objective-Smalltalk uses the underlying ObjC runtime, so reference counting it is. No GC, unless you run it on Apple's deprecated GC or GNUStep with Boehm. Your choice. The "<-" character pair is actually supported, Unicode left arrow would also be nice. As a matter of fact, assignment is not a built-in operator as with Smalltalk, but a family of dataflow connectors that includes constraints. The right-arrow "->" is also supported for architectural connection, such as when connecting the IN and OUT ports of a flow-based system or up-/downstream composite scheme handlers: (ref:file:{env:HOME}/Sites -> (MPWCopyOnWriteScheme memoryCache) -> (MPWSchemeHttpServer serverOnPort:8081)) start:nil. This creates a web-server with the "Sites" directory of your home directory, via an in-memory cache.
- eonil 13y agoOh it's getting even more interesting! Do you have any plan to add hygienic macro and coroutines? AFAIK, coroutines were always supported in traditional Smalltalk, but if you're based on objc runtime, it may not possible. So I am asking this.
- coldcode 13y agoAs an iOS programmer and long time Objective-C fan, I like the direction it is going. How is the memory management done? Since ARC is basically done by the compiler I wonder if that can be leveraged?
- mpweiher 13y agoYes, either ARC or something comparable is planned. Alas, significant parts of ARC are implemented in the ObjC frontend clang rather than the LLVM backend, so that will be a bit of work. Fortunately, there are other ways of achieving largely the same effect, and in the end it's just ASMOP.
- coldcode 13y agoASMOP - isn't that the solution to everything ;-)
- kilon 13y agowhat makes me skeptical is this "Generic raw pointers are not supported". The goal of C type languages are to offer performance not ease of use. So if that means loss of performance kinda defends the purpose. And if I want ease of use I rather use Pharo . But I support the effort, and I am certainly very interested to see what will come out of this :)
- pjmlp 13y agoThe thing is that it is possible to have both, like the Pascal branch of languages proves. Or if Apple had kept investing into Dylan, for example.
- kilon 13y agoyes definitely , I am not saying its not possible. Afterall Objective C itself supports manual memory management and GC . I was just wondering if Objective Smalltalk has something similar.
- Dewie 13y ago> The thing is that it is possible to have both, like the Pascal branch of languages proves. Do you recommend any particular languages for this purpose, nowadays?
- pjmlp 13y agoIt is a bit hard to recommend any besides Ada. Thanks to Ada Core, the issue with Ada compilers costing a small fortune is no nonlonger true. Given its support for Ada compiler in GCC. At least in Europe, Ada seems to be having an increase in usage, specially in areas where human lifes are at risk. I don't have a real measure for that, just by watching how Ada presence has been growing at FOSDEM. For remaining Modula, Oberon and Pascal dialects, there is no industry support any longer, except a few niche places.
- mpweiher 13y agoAn important point. ObjST does offer different variations of the concept of a "pointer". The first is a ref:. This is a reference to a resources, so a generalization of what a pointer is. Specific scheme providers can return refs that are effectively pointers, so for example a reference to the name of a person: nameRef := ref:var:person/name This eliminates the need for string-based techniques such as Key-Value-Coding (KVC), for example when binding user-interface elements. A text-field can just take a ref, and manipulate that: nameRef value:'Pascal'. This will set the name of the person to 'Pascal'. A ref:file: is a reference to a file. Storing that in another file creates a symbolic link: file:linktohome <- ref:file:{env:HOME} In addition, scheme providers are extensible. So for example if you need to access a hardware register at a specific address, you could have a mem: scheme provider: mem:0x10f := 23. Assuming you have the correct permissions :-) In terms of performance, that is often better provided by bulk collections. Pointer indirections are actually a major drain on processor performance these days. So the broad idea is to provide performance via bulk primitives, hardware access via scheme-providers and aliases/references via first class references ('ref:'). "Generic raw pointers" should then be largely unnecessary, specific pointers can be provided as necessary.
- LinaLauneBaer 13y agoThe given example for HOM is a bit unfair. From their docs: for ( NSView *aView in [[self view] subviews] ) { [aView setNeedsDisplay]; } They use this as an example to show that Objective-C is bad. However you can rewrite that with: [self.view.subviews makeObjectsPerformSelector:@selector(setNeedsDisplay)]; That being said: I think that Objective-C could move faster as a language. We have seen Apple to speed up the development of Objective-C during the last few years and I think that Apple will move even faster in the future.
- mpweiher 13y agoRight, I used an example from real code rather than a made up example. The difference is that makeObjectsPerformSelector: doesn't handle non void returns, only handles limited argument numbers and types (and needs a separate version of the core method for each). #( 1 2 3 4 5 ) collect + 5 This also works with HOM, as does -ifResponds, -async etc.
- fmateoc 13y agoI don't mind trying to come up with less boilerplate syntax, but how does the reader of the code know when something is a HOM or a normal message? The above example is valid syntax in existing Smalltalk, a Smalltalk developer would interpret it as collect returning a value that would be added to 5. I think this ambiguity is much worse than any advantage compactness might bring.
- fmateoc 13y agoJust as an example, writing #( 1 2 3 4 5 ) + 5 would actually be even more compact and more intuitive. A Smalltalk developer would interpret this as #+ being implemented in Collection, and the expectation would be that the implementation of #+ would be something like + arg ^self collect: [:each | each + arg]
- LinaLauneBaer 13y agoObjective.st has a very clean syntax. But this can also be done with Objective-C: [[@[@1, @2, @3] valueForKeyPath:@"@sum.self"] integerValue] + 5 This can be improved: @implementation NSArray (Private) - (NSInteger)collect { return [[self valueForKeyPath:@"@sum.self"] integerValue]; } @end And then you can write: [[@[@1, @2, @3] collect] + 5; I know: HOM is a more abstract/generic thing. If it was built in the language you could just use it as is without reinventing the wheel all the time... I just want to point out that Objective-C can be made look nice as well :)
- pjmlp 13y agoProject Etoile offers something similar, Pragmatic Smalltalk http://etoileos.com/etoile/features/languagekit/ http://etoileos.com/etoile/features/languagekit/
- mpweiher 13y agoProject Etoile is awesome! It is also further along in the Obj-C/ST integration than ObjST. What distinguishes ObjST is that it is taking the language further in terms of expressive power and adaptability, with Polymorphic Identifiers, (higher order) messaging mediated via first class references and dataflow connectors.
- stefanu 13y agoEtoile is great project with many interesting concepts. I always wished that Apple would somehow get inspired by the LanguageKit. I guess that AppleScript was good enough... I miss the talks of pre-Etoile days on #gnustep.
- stefanu 13y agoStepTalk is another Smalltalk-ObjectiveC legacy framework, originally meant for Smalltalk-like scripting of ObjectiveC apps/tools. It was built for GNUstep but worked on early versions of Cocoa as well: https://github.com/stiivi/StepTalk https://github.com/stiivi/StepTalk. It is no longer maintained, therefore it might need a little bit of refreshment. It is light-weight SmallTalk interpreter on top of ObjectiveC objects. See the examples for better idea of what it does: https://github.com/Stiivi/StepTalk/tree/master/Examples https://github.com/Stiivi/StepTalk/tree/master/Examples
- mpweiher 13y agoHi Stefan! StepTalk was and is definitely a great addition, and I think the more we have of these the more likely it is that we will finally get to program in something better than we have now. Maybe it's an idea whose time has finally come :-)
- stefanu 13y agoThanks Marcel. Nice work with Objective Smalltalk too. Irony is that at that time the Smalltalk people didn't see the advantages of frameworks like StepTalk. I got a few "Why don't you just use Smalltalk?" questions on ESUG conference in 2003 – on one hand they were not happy that Smalltalk use was a bit declining (or at least not thriving, compared to other languages/environments), but didn't wanted to see a compromise solution. Only the pure Smalltalk way was the proper way. > Maybe it's an idea whose time has finally come :-) ... where web == one large distributed Smalltalk image? I'm all for that! ;-)
- erikj 13y agoIs it dynamic language like Smalltalk-80?
- gress 13y agoFantastic! The only question is, will Apple be able to evolve Objective-C faster than this can be made into a production ready tool?
- mpweiher 13y agoAlas, Apple can't really evolve Objective-C in the direction of simplicity at this point due to backwards compatibility concerns, and the complexity of (a) 2 language syntaxes and (b) the history of some unfortunate decisions leaves little room in the syntax for some of the more interesting enhancements. I did not take this step lightly, being an old Objective-C hacker myself (did my own implementation on an Amiga with Aztec C in 1987...)
- e12e 13y agoInteresting. Does this support/run on/with alternative platforms like gnustep, or does it require os x for development and only target ios/osx? Would it be feasible to port?