121–130 of 130 posts
Alan Kay said: "Current software is built like the pyramids... By the arduous labour of thousands of slaves. That is because we still don't have the equivalent of the Arch. That allows Notre Dame to have 3 times the volume of the keeps pyramid with a third of the mass." Since it seems you are building such an arch I thing a good name could be: NotreDameLang. ArchLang.
Earlier quoted context omitted.
Yes and? EVAL isn’t call/return, it’s a mathematical function from type S-expression to type S-expression modulo some details. At least it was to start, Lisp now has side effects which considerably opens up the domain of easily expressed programs. Perhaps you’re confused because you’ve never done anything nontrivial in a modern Lisp and the word function is so heavily overloaded? Here[1] is an example of the Actor mo…
Interesting. > EVAL isn't call/return, it's a mathematical function Hmm...a "function" you say. What do you do with a function in a computer system? I mean, for it to actually do something? Look at it? Digest it? Sing it? Or maybe... call it? And when that function is done, after you called it what does it do? Dissolve? Perambulate? Or maybe: return ? Of course, a function that you call and that then returns has abso…
Lisp is not generally following an eval/apply model and/or call/return model.
(send foo :beep)
* SEND is a function, it's is called with the evaluated args, it may return or not
* SEND is not a function and does something arbitrary
Generally the model is:
(operator ...)
For example (throw 'foo "hello"), where THROW is a built-in special operator which transfers control.
b) it could be a function, which is more like a procedure. The function could also do transfer control to some other place and never return, for example by calling THROW or by other operators which transfer control
c) it could be a macro. The args don't need to be evaluated. Thus no eval/apply. The macro returns code, which gets executed. Again this could use other primitives, which transfer control.
d) it could be a function itself like ((lambda (x y) ...) 13 14)
What it needs: the first element in a Lisp form needs to be an operator, which is usually a symbol with some meaning: special operator, function, macro.
Scheme then in the mid 70s added that the first element is evaluated and can be a general variable. Thus in Common Lisp:
(let ((actor (create-actor :name 'foo)))
(send-async actor :init))
(let ((actor (create-actor 'foo)))
(actor :init))
> my-actor async messge_args
Writing it as
(send my-actor :async message-args)
If we want write
(my-actor async message-args)
a) switch to a model like in Scheme, where the actor would be a function object
or
b) write a translator for a new language to ordinary Lisp
or
c) write a new evaluator for that
Earlier quoted context omitted.
> You don't seem to know prolog well if you consider more "algorithmic" or "procedural" than, say, smalltalk. Actually: I do. Which is why I gave the precise reasons for what I wrote, which in turn your critique does not touch on at all. So again: Prolog is very much a system that computes answers to questions. If you have a Prolog-based system that does not, please point it out to me and I will be happy to have a lo…
"computes answers to questions" applies to any system with a REPL. That's really not a technical term at all. If you want to be more precise, you could say prolog tries to satisfy the goal it's passed (via unification and resolution). That's not the same as the call/return paradigm. The only unifying concept (heh) for these two is, well, "computes something". Anyway, for me, that confirms that your statements are not…
I'll get on that right after you come up with a quantifiable metric for expressiveness.
¯\_(ツ)_/¯
Earlier quoted context omitted.
I didn’t respond regarding Algol because you said nothing of immediate relevance requiring a response. I’m familiar with the history of Algol 60. I’m not interested in regurgitating wikipedia with you. Here[1] is a good primary source on the history of programming and significance of Algol in context for you to read. Note that call/return is nowhere mentioned. Stop chasing tangents and address your core misunderstand…
OK, thanks for clarifying that you did not understand what I wrote in the least bit and have no intention of learning, not even so far as looking at the relevant information on Wikipedia, which would help clear up your misunderstandings. Once again: ALGOL is the ALGOrithmic Language. It might have something to do with algorithms. Now please tell me what the main structuring mechanism for code is in Algol (and C, for…
Earlier quoted context omitted.
OK, thanks for clarifying that you did not understand what I wrote in the least bit and have no intention of learning, not even so far as looking at the relevant information on Wikipedia, which would help clear up your misunderstandings. Once again: ALGOL is the ALGOrithmic Language. It might have something to do with algorithms. Now please tell me what the main structuring mechanism for code is in Algol (and C, for…
Quoted post unavailable.
Please see https://news.ycombinator.com/item?id=32466681.
Earlier quoted context omitted.
> What makes Objective-S more general than other languages? They describe that on the site. The notion is that most of our modern languages are more geared towards expressing algorithms and data structures, and not so great for expressing programs better suited to different architectural styles that don't necessarily follow a strict call/return type of semantics. That's not entirely wrong. You can build a library/eDS…
Thank you for getting it and expressing it so clearly. > You can build a library/eDSL in a call/return language that will implement other architectures, but it will still look and behave like a call/return abstraction EXACTLY! We can build, but we cannot express . So it will look like a weird/complicated call/return abstraction, because it isn't "native". So you get a tradeoff between architecture and simplicity, a t…
And 1986 "Computer World" Aug 25 p75 "Smalltalk/V reportedly features … a built-in Prolog compiler…" ;-)
https://books.google.com/books?id=uVHbRM6mU9gC&lpg=PA75&dq=h...
I've watched Marcel's efforts with admiration for his commitment for a long time. I looked at this and browsed some of the examples, and something clicked for me finally. I did a good solid 20 years of dedicated Smalltalk. When I started doing Objective-C, I was glad I could send messages, but noticed a number of differences. One of the things that you don't see just comparing syntax between Smalltalk and Objective-C…
thanks for the kind words!
Objective-S tries to be expression-oriented in its call/return parts, it even goes a bit further than Smalltalk in that the return of a method is the last expression of the method (like Erlang/Elixier, if I understood you correctly, and like Smalltalk blocks). For example here are some methods:
-numberOfSteps { 8. }
-description { "". }
/:table/:index {
|= { self dictionariesForQuery: "select * from {table}" | at: index. }
}
/:table {
|= { self dictionariesForQuery: "select * from {table}". }
}
/:table/:column/:index {
|= { self dictionariesForQuery: "select * from {table}" | at: index. }
}
/:table/where/:column/:value {
|= { self dictionariesForQuery: "select * from {table} where {column} = {value}". }
}
#!env stsh
filter toupper |{ ^object stringValue uppercaseString. }
(stdin -> toupper -> rawstdout ) run
Coming back to void: if I want to have interop with Objective-C, I must also support void returns, and they do come in handy here and there. For example, stsh uses a method declaration in comments after the shebang to make scripts more method-like, including argument parsing and return values. The following script expects a single integer argument and prints the result of adding three to that number to stdout:
#!env st
#-addToThree:arg
arg+3.
]./add3.stsh
1 missing parameters (of 1): arg =
#!env st
#-sawk:file
file csv: { :time :latitude :longitude :depth :magnitude |
stdout println:"Magnitude: {magnitude} location: {latitude},{longitude} time: {time}".
}.
] ./earthquakes-sawk.st https://earthquake.usgs.gov/earthquakes/feed/v1.0/summary/all_month.csv
Magnitude: 2.8 location: 58.3441,-133.2808 time: 2022-08-19T10:19:16.173Z
Magnitude: 0.35 location: 33.5856667,-116.8071667 time: 2022-08-19T10:18:54.980Z
...
Objective-C's default return type actually is "id" [1], and methods tended to return either some result or self up to NeXTstep 3.3, just like Smalltalk. So what changed? Distributed Objects. If your receiver is a distributed object, having a return value means that you have to marshal something, send it over the wire and synchronise on the return value. So they removed the default self returns.
With regards to types: I like type annotations, as long as I am not forced to add them everywhere and not constrained to the expressiveness of the type system. Having a bit of (checked) documentation is super-helpful when browsing code, having to chase down senders and implementors in order to figure out what a method does is super annoying. And of course Objective-C (and C) interop is crucial, as is the ability to compile some code to be as efficient as equivalent C code without needing a Heldencompiler/HeldenJIT. As soon as I add native compilation :-)
[1] https://blog.metaobject.com/2014/03/cargo-cult-typing-or-obj...
Earlier quoted context omitted.
I'm sure I've written more than most other people currently alive. ObjC is one of the most readable languages around. That's mostly because of the param:value syntax, which is much better than C-like syntax because you can see the parameter names. But the long method names aren't a problem once you have autocompletion. They also make it clearer what the best name for a method is - if you call something fmt() you star…
I used to agree, but things like Jakt have an even better version: https://github.com/SerenityOS/jakt Notable differences: 1. param:value is used, but convention is param:value not the gratuitous Engrish verbingParamProposition:value ObjC inherited from Smalltalk. 2. param: is optional if the variable holding value in the calling function is named "param" at compile time. This pushes you to name your params "param" e…
Smalltalk does not have this convention.
Earlier quoted context omitted.
Yes, exactly: these architectural styles should not be built into the language. And (mostly) aren't, in Objective-S. You should be able to build them yourself within the language and then they should have linguistic support that is as good / indistinguishable from built-in stuff. Just like Smalltalk does with, say collections: most languages have/had built-in support for one type of collection (or maybe two), typical…
Alright then, what if the architectural style one wants is type-level metaprogramming? Or even just having a rich type system with inference, like Haskell? Can objective-S do that? What about monads, typeclasses, etc. which are arguably pretty extensible and DSL-y too (see Xmonad for example)? If not, maybe this whole definition of "general purpose" is just meaningless.
That's not an architectural style. ¯\_(ツ)_/¯
Earlier quoted context omitted.
> Note: very pleased that the box serving the site is pretty consistently at less than 1% CPU during the HN hug of death. The connection has timed out Tempt not the fates, for they are cruel -- or, alternatively, the "hug" is not one thing --- https://github.com/mpw/Objective-Smalltalk#readme is the repo linked from the Download page in Wayback, for those into such things (but based on a recent commit, it's not Open…
Weird. Just checked and it's still up, hasn't even restarted. Not sure why you think the presence of copyright makes something open-source. All open-source licenses depend on copyright, otherwise the code would be in the public domain.