4 ms·

It's fascinating that you see this as a functional construct. The call/return mindset is incredibly strong, and we map (sic) everything to it, no matter whethe

It's fascinating that you see this as a functional construct. The call/return mindset is incredibly strong, and we map (sic) everything to it, no matter whether it's appropriate or not. What is actually there is a connection expression, connecting two objects. The first object is a data source, generating values at a fixed rate. The second object is a reference to the object identified by the polymorphic identifier "gpio:17". What is that? Pin 17 on the Raspberry Pi GPIO connector. But "gpio:17" is the current value. By taking the ref:, I can talk about the variable itself, which I can connect as a sink of a dataflow. In fact, I can connect any variable as the sink to a dataflow. So the following: #Blinker{ #seconds: 1, #active: true} → ref:file:/tmp/blinker.txt. would change the contents of the file in question every second. It would not append to the file, that would be accomplished by getting the stream: #Blinker{ #seconds: 1, #active: true} → ref:file:/tmp/blinker.txt asStream. Or you could just use stdout: #Blinker{ #seconds: 1, #active: true} → stdout. But coming back to ref:gpio:17, to me this seems about as effectful as possible, in my test setup that literally lights up an LED, so about as non-functional as you can get.

magicalhippo 5y ago
I was very confused by the GPIO example. Where does active get set to false, and after how long?
- ghusbands 5y ago
  It doesn't, I think. Active is whether or not the blinker is active; though I'd have expected a default for that. The blinker is itself switching on and off. Making it inactive would probably stop it doing that.
  - magicalhippo 5y ago
    Ok, now I'm properly confused. So #Blinker has some code not shown that actually does what the C-like code below does? I assumed active was to turn the GPIO high, given that the code was supposed to implement the same logic. edit: yeah ok I see it now: describe the actual relationship, make that explicit, and instead keep the procedural code that maintains it as a hidden implementation detail.
    - mpweiher 5y ago
      Exactly! :-) If it could be explained better, I am all ears!
      - magicalhippo 5y ago
        If the point was to hide the #Blinker implementation, then a simple code comment that #Blinker is implemented elsewhere would have probably helped me on my first pass. Not a huge deal though :)
  - mpweiher 5y ago
    Exactly correct. Having active elements activate immediately is a good choice for simple examples like the one shown. For larger constructions, you typically want to have built the whole thing before starting it up.
pwdisswordfish8 5y ago
I am just wary of people badly reinventing an old idea with different names and trying to sell it as the next best thing since sliced bread. And since this is Hacker News… So far I’m not seeing anything other than names that would differentiate this from already-known paradigms. (And by the way: pre-sliced bread sucks.)
- mpweiher 5y ago
  "I am not seeing anything here that would differentiate this from a Turing machine" "I am not seeing anything here that would differentiate this from x86 assembly" ¯\_(ツ)_/¯ Anyway, if you insist on mapping something new in computing onto something you already know, you will pretty much always find some way of accomplishing this. While it might seem clever, it really just reiterates Turing-completeness, and so is not particularly interesting. The question is whether your mapping is appropriate (it's not) or straightforward (also not). Of course, this is a problem, because to understand something, you typically first have to map it onto something you already understand, but the key is to not stop there. As to "something new": no, software architecture is not new. Not new at all. The seminal book is from 1996: Software Architecture: Perspectives on an Emerging Discipline, by Mary Shaw and David Garlan. https://www.amazon.com/Software-Architecture-Perspectives-Emerging-Discipline/dp/0131829572 https://www.amazon.com/Software-Architecture-Perspectives-Em... The paper trail is much older. There is an entire discipline behind this, and in this discipline, FP is a small corner of the small corner that is the call/return architectural style, of all the myriad of architectural styles available. You can argue that this whole discipline of computer science with conferences, many thousands of peer-reviewed articles, many books etc. is all just BS, but I think you'd have a hard time arguing that case. And it would be you who'd have to make the case, because the discipline is well-established. All Objective-S does is to say "hey, let's take this talk of connectors and components seriously and program with them". It's also not the first language to do this, there was ArchJava. Alas, this was an extension of Java with architectural constructs such as connectors, which is the wrong way around: connectors are more general.

magicalhippo 5y ago

I was very confused by the GPIO example. Where does active get set to false, and after how long?

ghusbands 5y ago
It doesn't, I think. Active is whether or not the blinker is active; though I'd have expected a default for that. The blinker is itself switching on and off. Making it inactive would probably stop it doing that.
- magicalhippo 5y ago
  Ok, now I'm properly confused. So #Blinker has some code not shown that actually does what the C-like code below does? I assumed active was to turn the GPIO high, given that the code was supposed to implement the same logic. edit: yeah ok I see it now: describe the actual relationship, make that explicit, and instead keep the procedural code that maintains it as a hidden implementation detail.
  - mpweiher 5y ago
    Exactly! :-) If it could be explained better, I am all ears!
    - magicalhippo 5y ago
      If the point was to hide the #Blinker implementation, then a simple code comment that #Blinker is implemented elsewhere would have probably helped me on my first pass. Not a huge deal though :)
- mpweiher 5y ago
  Exactly correct. Having active elements activate immediately is a good choice for simple examples like the one shown. For larger constructions, you typically want to have built the whole thing before starting it up.

pwdisswordfish8 5y ago

I am just wary of people badly reinventing an old idea with different names and trying to sell it as the next best thing since sliced bread. And since this is Hacker News… So far I’m not seeing anything other than names that would differentiate this from already-known paradigms. (And by the way: pre-sliced bread sucks.)

mpweiher 5y ago
"I am not seeing anything here that would differentiate this from a Turing machine" "I am not seeing anything here that would differentiate this from x86 assembly" ¯\_(ツ)_/¯ Anyway, if you insist on mapping something new in computing onto something you already know, you will pretty much always find some way of accomplishing this. While it might seem clever, it really just reiterates Turing-completeness, and so is not particularly interesting. The question is whether your mapping is appropriate (it's not) or straightforward (also not). Of course, this is a problem, because to understand something, you typically first have to map it onto something you already understand, but the key is to not stop there. As to "something new": no, software architecture is not new. Not new at all. The seminal book is from 1996: Software Architecture: Perspectives on an Emerging Discipline, by Mary Shaw and David Garlan. https://www.amazon.com/Software-Architecture-Perspectives-Emerging-Discipline/dp/0131829572 https://www.amazon.com/Software-Architecture-Perspectives-Em... The paper trail is much older. There is an entire discipline behind this, and in this discipline, FP is a small corner of the small corner that is the call/return architectural style, of all the myriad of architectural styles available. You can argue that this whole discipline of computer science with conferences, many thousands of peer-reviewed articles, many books etc. is all just BS, but I think you'd have a hard time arguing that case. And it would be you who'd have to make the case, because the discipline is well-established. All Objective-S does is to say "hey, let's take this talk of connectors and components seriously and program with them". It's also not the first language to do this, there was ArchJava. Alas, this was an extension of Java with architectural constructs such as connectors, which is the wrong way around: connectors are more general.