Re:Steve Jobs, NeXTSTEP, and Early Object-Oriented Programming
by mpweiher on Wednesday November 13, 2024 @05:34PM
(#42130941)
The Four Stages of Objective-Smalltalk
https://blog.metaobject.com/2019/12/the-4-stages-of-objectiv...
Its first two stages are just that, but it has moved beyond, for good reasons.
Re:Steve Jobs, NeXTSTEP, and Early Object-Oriented Programming
by Aeglaecia on Wednesday November 13, 2024 @05:14PM
(#42130711)
surely after 20 years this already exists , someone posted a header the other day that makes c syntax python like , macros are enough to accomplish what youre describing? i dont perceive it as efficient to force codebase contributors to relearn their ingrained language syntax , possibly more efficient for those having newly learned a language tho ...
Re:Steve Jobs, NeXTSTEP, and Early Object-Oriented Programming
by cxr on Wednesday November 13, 2024 @11:18PM
(#42133127)
> i dont perceive it as efficient to force codebase contributors to relearn their ingrained language syntax
That's why it's important that the transformation be reversible and what the gofmt-like code formatters are for.
Re:Steve Jobs, NeXTSTEP, and Early Object-Oriented Programming
by lukeh on Friday November 15, 2024 @05:14AM
(#42145509)
Apple did implement this around the Mac OS X transition (I guess, probably Steve Naroff did it?) but it was not pursued, in favor Java bindings (which funnily enough are back in fashion with swift-java).
It's really kind of a bummer that we don't have well-known examples of "skinnable" programming languages already. The closest we get are the ones that let you choose your set of keywords for different locales in case you don't want to work with an English-based PL and those block based languages that let you manipulate them as blocks or edit the textual form. I firmly believe that PL skinning would really benefit so many otherwise worthwhile languages that get short-shrift because of negative reactions to the surface-level details. I'm referring in particular languages like those in the Pascal family. (You could also conceive of e.g. a skin for Golang that doesn't have leading caps be the determiner for whether a function is public or not. There are lots of applications for this, and the variations are a non-issue when you have an ecosystem with strong norms about applying a code formatter (like gofmt), which can dictate the format of the canonical on-disk representation.)