11 ms·

Any comment on what is so special about this?

by mizzao 10y ago

nine_k 10y ago
If you ever wondered where Go took a lot of good ideas from, look at Modula / Oberon.
- theamk 10y ago
  In the code the link points to, I just see another C-like language. What "good ideas" should I be looking at? I am not Oberon expert, but in any other language I'd say this code is pretty bad: - logic errors: We keep going even if error occurs (none of the error checks have return in them). - In two different source files, "System" is imported under two different names. Is this just to confuse the readers? - Hardcoded string length (Mod.s:17). If someone to change the message, you have to be very careful to update the length. - Arbitrary constants (why '2' in Mod.s:23)?
  - OneOneOneOne 10y ago
    > In the code the link points to, I just see another C-like language. To be fair Oberon's roots go back to Pascal and not C. Pascal predates C. :)
    - theamk 10y ago
      I used to program in Pascal long time ago (Turbo Pascal dialect), but the link does not show any of Pascal-specific functionality. Where are types with unusual range (var i: 0..15)? Where are arrays with non-zero based ranges? Where is the neat interface/implementation separation? Is there runtime-based range checking? Because I do not see it, and I bet if I changed this "17" to "117", it will just send extra 100 bytes of un-initialized memory over the socket. This particular code does not have any pascal-y language features. What is the point of the post? If it was to demonstrate that Oberon is good for teaching / real stuff / general purpose programming / something else, then it failed. To me, the points of the post is: "hey, this language is not dead! We can now fork() and do socket ops!". Is this intentional?
      - lobster_johnson 10y ago
        The hard-coded string length is some test code. It's not an indicator of a weakness in the language. Oberon has Strings.Length(), which returns the length of a string. The OP's link points to a test directory. Go look at the actual source code: https://github.com/norayr/voc/tree/master/src Oberon has all the features you describe: Range types, bounded arrays, and so on. It doesn't have the interface/implementation split (though it has a "DEFINITION" block you can use); modules contain both the interface and implementation, and you export symbols with "*" (or "-" for read only). Basically, Oberon-2 > Oberon > Modula-2 > Modula > Pascal. Oberon adds interfaces, open arrays, type-bound procedures (similar to Go's struct methods), etc. It's an evolutionary improvement/tweak over the previous languages. If you know any of them, Oberon-2 will be very familiar.
        kristianp 10y ago
        Clickable link from parent: https://github.com/norayr/voc/tree/master/src https://github.com/norayr/voc/tree/master/src
  - soapdog 10y ago
    Oberon and its siblings are awesome. I believe that to fully appreciate Oberon & friends, you need to have a bit of context on its creation and usage. Oberon is a language by Niklaus Wirth, so it is not a C-like language, it is a different branch of the Algol family, it is the Pascal branch were we have Pascal, Modula and Oberon (in their different versions). This family of languages are very easy to port and to construct performant compilers. They are not only easy to learn from a student point of view but also can be used for real useful work. In its home university in Zurich, they created the oberon system which is a computer hardware, operating system, programming language and userland applications solution that they used all over the university. This was done when GUIs and the Mac were in its starting years (circa 1987). Sometimes I feel that Pascal and its successors are not fully appreciated by our world that grew too enamored with C. There were some awesome ideas and solutions created there in Switzerland at that time when create a full package of hardware and software was something that people still tried to do. If you're interested in exploring things further here are some links: https://en.wikipedia.org/wiki/Oberon_(operating_system) https://en.wikipedia.org/wiki/Oberon_(operating_system) https://schierlm.github.io/OberonEmulator/ https://schierlm.github.io/OberonEmulator/ http://www.projectoberon.com/ http://www.projectoberon.com/
    - eudox 10y ago
      >Sometimes I feel that Pascal and its successors are not fully appreciated by our world that grew too enamored with C. There were some awesome ideas and solutions created there in Switzerland at that time when create a full package of hardware and software was something that people still tried to do. Having been taught Modula-2 in Programming 102 class in college (this was a year ago), I disagree completely. Software development has this camp with a contrarian, 'this was done at Xeroc PARC' mentality where we're using terrible computers because Smalltalk or the Lisp machine or Oberon failed and nasty Unix took over. But when you actually have to use these languages, well, they're terrible. They're C, with all its flaws, but a more indented/structured syntax. Pascal, Modula, and Oberon have no lessons that have not been learnt by some or another language, and done better.
      - _ph_ 10y ago
  - e12e 10y ago
    The hard-coding of the length of the "aff" string and/or re-use of the "s" (size) variable does indeed look odd: s := SIZE(String); aff := "Affirmative, Dave"; (...) s := 17; n := Unix.Write(sock, S.ADR(aff), s); As far as I can gather from: https://github.com/norayr/voc/blob/master/src/lib/v4/Strings.Mod https://github.com/norayr/voc/blob/master/src/lib/v4/Strings... this implementation uses some kind of c strings (not familiar with Oberon in general, but I thought that the norm was something like Pascal strings?): "Strings provides a set of operations on strings (i.e., on string constants and character arrays, both of which contain the character 0X as a terminator). All positions in strings start at 0. Strings.Length(s) returns the number of characters in s up to and excluding the first 0X." It would seem that: s := String.Length(arr); should be the sane equivalent to "s := 17;"
  - nine_k 10y ago
    Good ideas from the language(s), not the source code linked. * Coroutines, a crown jewel of Go. * Proper modules, separate files for interface and implementation parts. * Nicer type system, with ranges, enumerations, ordered types and arrays indexed by any ordered type; can't remember if it ever had sum (aka variant) types. * IIRC Oberon had an 'object system' very similar to Go's, with functions having a receiver and struct-based 'classes'. * Obviously far fewer (if any) undefined behaviors than C. * Low-level access; it was entirely possible to write an interrupt handler in Modula-2, access address-mapped ports, etc.
    - coldtea 10y ago
      >Proper modules, separate files for interface and implementation parts. Proper modules are great, but I wouldn't call the "separate files for interface and implementation parts" a good feature. That's a throwback to languages like C. It's not DRY, and it's also busywork -- the interface can trivially be created/inferred from the implementation file alone.
      - nine_k 10y ago
        It was easy to give your customers the proper interface files (they were compilable), so they could code against your interfaces. They are much lighter than the object files (it was the time of the floppy disk and 2400 modems). One point of having interface files separate is tools like `make`. If the interface file's timestamp did not change, the interface is the same. It would probably be nicer to have two compilation artifacts, the extracted human-readable interface part and the object-file implementation part. It (in my case TopSpeed Modula-2) was waaaay faster than e.g. Borland C++ wading through endless .h files.
        coldtea 10y ago
        >It was easy to give your customers the proper interface files (they were compilable), so they could code against your interfaces. They are much lighter than the object files (it was the time of the floppy disk and 2400 modems). And how would they test/run their code, since the interfaces would at best link, but not run anything, being only stubs? >It would probably be nicer to have two compilation artifacts, the extracted human-readable interface part and the object-file implementation part. Yes, if interface-only coding was possible for the clients, and disk space was at a premium yes. Anything but having to manually write interface AND implementation.
  - tanakian 10y ago
    Hello, >another C-like language Oberon is also a system programming language. I guess, the code would not look as C-like to you, if it would use some threading or socket library, may be written in "oop" way. It might create an impression of being close to C because it uses the same way of dealing with sockets as people do in C usually. If the code would use TThread and TSocket classes, like in Object Pascal, it might look different. It requires less efforts to create wrappers, than to write libraries. Probably if there were more "speakers" of the language, then there would be more ready to use libraries for developers. This also may explain why that code could be improved, as you have pointed out - it serves more as an example of how to write a wrapper, rather than example of how to, or not to, program in Oberon. I also know that the code could be improved, I can add that for instance I do not like that the main server module imports SYSTEM module, which flags it as unportable and potentially dangerous. But never thought that it could appear at such a crowded space as HN and deferred the improvements. Also, I did not think the code deserves a lot of attention. >What "good ideas" should I be looking at? To me it is important that it's low level and system programming language which, if compared to C, is still is more safe and less error prone. It is important to me that Oberon is modular. That types, variables, functions are "private", unless explicitly exported. Strong typing. Type checks across module boundaries. In Oberon systems I could point out dynamic module loading, tasks vs threads, active objects in the language, single address space operating system is controversial but interesting. These are good ideas I can mention without even thinking.
- talideon 10y ago
  That, and Algol 68.
coldtea 10y ago
Where is pjmlp when we need him?

Any comment on what is so special about this?

by mizzao 10y ago

Any comment on what is so special about this?

nine_k 10y ago

If you ever wondered where Go took a lot of good ideas from, look at Modula / Oberon.

theamk 10y ago
In the code the link points to, I just see another C-like language. What "good ideas" should I be looking at? I am not Oberon expert, but in any other language I'd say this code is pretty bad: - logic errors: We keep going even if error occurs (none of the error checks have return in them). - In two different source files, "System" is imported under two different names. Is this just to confuse the readers? - Hardcoded string length (Mod.s:17). If someone to change the message, you have to be very careful to update the length. - Arbitrary constants (why '2' in Mod.s:23)?
- OneOneOneOne 10y ago
  > In the code the link points to, I just see another C-like language. To be fair Oberon's roots go back to Pascal and not C. Pascal predates C. :)
  - theamk 10y ago
    I used to program in Pascal long time ago (Turbo Pascal dialect), but the link does not show any of Pascal-specific functionality. Where are types with unusual range (var i: 0..15)? Where are arrays with non-zero based ranges? Where is the neat interface/implementation separation? Is there runtime-based range checking? Because I do not see it, and I bet if I changed this "17" to "117", it will just send extra 100 bytes of un-initialized memory over the socket. This particular code does not have any pascal-y language features. What is the point of the post? If it was to demonstrate that Oberon is good for teaching / real stuff / general purpose programming / something else, then it failed. To me, the points of the post is: "hey, this language is not dead! We can now fork() and do socket ops!". Is this intentional?
    - lobster_johnson 10y ago
      The hard-coded string length is some test code. It's not an indicator of a weakness in the language. Oberon has Strings.Length(), which returns the length of a string. The OP's link points to a test directory. Go look at the actual source code: https://github.com/norayr/voc/tree/master/src Oberon has all the features you describe: Range types, bounded arrays, and so on. It doesn't have the interface/implementation split (though it has a "DEFINITION" block you can use); modules contain both the interface and implementation, and you export symbols with "*" (or "-" for read only). Basically, Oberon-2 > Oberon > Modula-2 > Modula > Pascal. Oberon adds interfaces, open arrays, type-bound procedures (similar to Go's struct methods), etc. It's an evolutionary improvement/tweak over the previous languages. If you know any of them, Oberon-2 will be very familiar.
      - kristianp 10y ago
        Clickable link from parent: https://github.com/norayr/voc/tree/master/src https://github.com/norayr/voc/tree/master/src
- soapdog 10y ago
  Oberon and its siblings are awesome. I believe that to fully appreciate Oberon & friends, you need to have a bit of context on its creation and usage. Oberon is a language by Niklaus Wirth, so it is not a C-like language, it is a different branch of the Algol family, it is the Pascal branch were we have Pascal, Modula and Oberon (in their different versions). This family of languages are very easy to port and to construct performant compilers. They are not only easy to learn from a student point of view but also can be used for real useful work. In its home university in Zurich, they created the oberon system which is a computer hardware, operating system, programming language and userland applications solution that they used all over the university. This was done when GUIs and the Mac were in its starting years (circa 1987). Sometimes I feel that Pascal and its successors are not fully appreciated by our world that grew too enamored with C. There were some awesome ideas and solutions created there in Switzerland at that time when create a full package of hardware and software was something that people still tried to do. If you're interested in exploring things further here are some links: https://en.wikipedia.org/wiki/Oberon_(operating_system) https://en.wikipedia.org/wiki/Oberon_(operating_system) https://schierlm.github.io/OberonEmulator/ https://schierlm.github.io/OberonEmulator/ http://www.projectoberon.com/ http://www.projectoberon.com/
  - eudox 10y ago
    >Sometimes I feel that Pascal and its successors are not fully appreciated by our world that grew too enamored with C. There were some awesome ideas and solutions created there in Switzerland at that time when create a full package of hardware and software was something that people still tried to do. Having been taught Modula-2 in Programming 102 class in college (this was a year ago), I disagree completely. Software development has this camp with a contrarian, 'this was done at Xeroc PARC' mentality where we're using terrible computers because Smalltalk or the Lisp machine or Oberon failed and nasty Unix took over. But when you actually have to use these languages, well, they're terrible. They're C, with all its flaws, but a more indented/structured syntax. Pascal, Modula, and Oberon have no lessons that have not been learnt by some or another language, and done better.
    - _ph_ 10y ago
- e12e 10y ago
  The hard-coding of the length of the "aff" string and/or re-use of the "s" (size) variable does indeed look odd: s := SIZE(String); aff := "Affirmative, Dave"; (...) s := 17; n := Unix.Write(sock, S.ADR(aff), s); As far as I can gather from: https://github.com/norayr/voc/blob/master/src/lib/v4/Strings.Mod https://github.com/norayr/voc/blob/master/src/lib/v4/Strings... this implementation uses some kind of c strings (not familiar with Oberon in general, but I thought that the norm was something like Pascal strings?): "Strings provides a set of operations on strings (i.e., on string constants and character arrays, both of which contain the character 0X as a terminator). All positions in strings start at 0. Strings.Length(s) returns the number of characters in s up to and excluding the first 0X." It would seem that: s := String.Length(arr); should be the sane equivalent to "s := 17;"
- nine_k 10y ago
  Good ideas from the language(s), not the source code linked. * Coroutines, a crown jewel of Go. * Proper modules, separate files for interface and implementation parts. * Nicer type system, with ranges, enumerations, ordered types and arrays indexed by any ordered type; can't remember if it ever had sum (aka variant) types. * IIRC Oberon had an 'object system' very similar to Go's, with functions having a receiver and struct-based 'classes'. * Obviously far fewer (if any) undefined behaviors than C. * Low-level access; it was entirely possible to write an interrupt handler in Modula-2, access address-mapped ports, etc.
  - coldtea 10y ago
    >Proper modules, separate files for interface and implementation parts. Proper modules are great, but I wouldn't call the "separate files for interface and implementation parts" a good feature. That's a throwback to languages like C. It's not DRY, and it's also busywork -- the interface can trivially be created/inferred from the implementation file alone.
    - nine_k 10y ago
      It was easy to give your customers the proper interface files (they were compilable), so they could code against your interfaces. They are much lighter than the object files (it was the time of the floppy disk and 2400 modems). One point of having interface files separate is tools like `make`. If the interface file's timestamp did not change, the interface is the same. It would probably be nicer to have two compilation artifacts, the extracted human-readable interface part and the object-file implementation part. It (in my case TopSpeed Modula-2) was waaaay faster than e.g. Borland C++ wading through endless .h files.
      - coldtea 10y ago
        >It was easy to give your customers the proper interface files (they were compilable), so they could code against your interfaces. They are much lighter than the object files (it was the time of the floppy disk and 2400 modems). And how would they test/run their code, since the interfaces would at best link, but not run anything, being only stubs? >It would probably be nicer to have two compilation artifacts, the extracted human-readable interface part and the object-file implementation part. Yes, if interface-only coding was possible for the clients, and disk space was at a premium yes. Anything but having to manually write interface AND implementation.
- tanakian 10y ago
  Hello, >another C-like language Oberon is also a system programming language. I guess, the code would not look as C-like to you, if it would use some threading or socket library, may be written in "oop" way. It might create an impression of being close to C because it uses the same way of dealing with sockets as people do in C usually. If the code would use TThread and TSocket classes, like in Object Pascal, it might look different. It requires less efforts to create wrappers, than to write libraries. Probably if there were more "speakers" of the language, then there would be more ready to use libraries for developers. This also may explain why that code could be improved, as you have pointed out - it serves more as an example of how to write a wrapper, rather than example of how to, or not to, program in Oberon. I also know that the code could be improved, I can add that for instance I do not like that the main server module imports SYSTEM module, which flags it as unportable and potentially dangerous. But never thought that it could appear at such a crowded space as HN and deferred the improvements. Also, I did not think the code deserves a lot of attention. >What "good ideas" should I be looking at? To me it is important that it's low level and system programming language which, if compared to C, is still is more safe and less error prone. It is important to me that Oberon is modular. That types, variables, functions are "private", unless explicitly exported. Strong typing. Type checks across module boundaries. In Oberon systems I could point out dynamic module loading, tasks vs threads, active objects in the language, single address space operating system is controversial but interesting. These are good ideas I can mention without even thinking.
talideon 10y ago
That, and Algol 68.

coldtea 10y ago

Where is pjmlp when we need him?