4 ms·

Previous discussion: https://news.ycombinator.com/item?id=6047576 https://news.ycombinator.com/item?id=6047576 This has tons of sugar; if you're just intereste

by TheDong 12y ago

Previous discussion: https://news.ycombinator.com/item?id=6047576 https://news.ycombinator.com/item?id=6047576 This has tons of sugar; if you're just interested in how this stuff is possible in C it would probably be more instructive to look at the GNU library libffcall[0] which implements trampolines. The code is simpler and there's less syntactic sugar obscuring what's going on. Of course, the linked articles on the Cello home page are instructive too. I've yet to actually use Cello myself since I feel like if you hack C up that much, you might as well just use something like C++, C#, Rust or what have you and gain even more benefits, like a mature ecosystem that's highly compatible with the features you're using while I worry Cello, when relying on normal C libraries, might require you to slip back into some C-isms that Cello desires to avoid due to your dependencies not caring. [0]: https://www.gnu.org/software/libffcall/ https://www.gnu.org/software/libffcall/

pjmlp 12y ago
> I've yet to actually use Cello myself since I feel like if you hack C up that much, you might as well just use something like C++, C#, Rust .... Since the early 90's I never understood why some programmers insist in using what is basically a portable macro assembler for higher level programming. It was already primitive when compared with the likes of Modula-2 and Turbo/Apple Pascal, not to mention all the other alternatives even higher level.
- agumonkey 12y ago
  Wasn't there some issue with Pascal type system being too restricting sometimes (the unfortunate lack of cast) ?
  - hsitz 12y ago
    You're probably remembering something from Brian Kernighan's 1981 essay, "Why Pascal Is Not My Favorite Programming Language". Lack of unsafe typecasts, as well as (I think) all of Kernighan's other main points in that essay were cured in Pascal implementations by end of the 80's. But by that time C had captured all the mindshare.
  - AnimalMuppet 12y ago
    It wasn't just the lack of a cast. (IIRC, you could work around that with variant records if you really had to, though it was really clumsy.) Another, unfixable problem was that the size of an array was part of the type of the array. This meant that you couldn't ever access past the end of an array, which was good. It also meant that you could never have a variable-sized array - you couldn't even talk about the type of such a thing. This meant that Pascal was completely unusable for writing, say, a memory manager (what type would you give to the return from an allocation)? But that's a low level problem. It also meant that Pascal couldn't be used for a numeric simulation where the size of your grid was a user-supplied runtime value. Note that I am only talking about the original (Wirth/UCSD) Pascal. I believe that Turbo Pascal fixed the variable-sized array problem.
    - pjmlp 12y ago
      Those problems were not part of the Pascal dialects. The largely ignored Extended Pascal ISO standard also had those issues fixed. The first Mac OS versions were written in Apple Pascal.
      - agumonkey 12y ago
        I knew about Apple programs being in Pascal, but the whole OS ? did they resort to inline asm ?
        pjmlp 12y ago
        Yes, they did use Assembly. When implementing an OS avoiding Assembly is impossible. Even if intrisics are used instead, they are just another way of using Assembly like instructions. There are lots of informations in this book, "Revolution in The Valley: The Insanely Great Story of How the Mac Was Made".
        agumonkey 12y ago
        Yes indeed, I forgot about that. I wonder if there ever was a purely 'compiled' OS from some declarative form.
  - pjmlp 12y ago
    No, that was a problem only with the original Pascal as designed by Niklaus Wirth for teaching purposes. None of the Pascal dialects that extended it with features for professional programming suffered from it.
    - GFK_of_xmaspast 12y ago
      Large parts of my undergraduate curriculum in the early 90s (at a mid-size well-funded public school in the united states) used pascal, and the unix and vms compilers we used most certainly suffered from the 'different array sizes are different types' issue.
- RogerL 12y ago
  In general, because those languages essentially declared things were 'bad' that aren't bad at all. Sometimes you have to mung data. Pull it in off a serial bus, strip out the header, rearrange it for the next thing you are sending it to, and so on. Other times you really do need/want some kind of dynamic dispatch or duck typing. You can do that with void* and function pointers. Ugly, yes, and error prone to boot, but possible. These days hardware is a lot faster. Back then I was writing my own graphics implementations because Windows GDI was way too slow for what I was trying to do. Just for a pretty ordinary app. Today, I am still concerned with how my data lies on the CPU cache. I need to access cards with C api's. It is nice to think about things like rust, but in my current company we have 2 decades worth of C&C++ code. It works with everything; we know that if a new card comes out it will come with a C API, we know that we can hire C programmers. The debuggers are astonishingly good (seriously; compare Visual Studio's debugger to thrashing around with some open source debugger for some other language. It's a production language, for professionals, to get shit done. It's not going anywhere for a long, long time. Not putting down the other languages - I use Python whenever I can, as it is such a joy to use. Anything other than C/C++ for most of my production code? Not in the foreseeable future. If you feel the urge to quibble about that last sentence, recall how much existing code I (and by extension, the world) already have. Never, ever, can we afford to throw that away. Shall we write some horror show of Haskell, Erlang, Javascript, and Clojure interfacing into 'legacy' code that in fact would need to be updated all the time? No thanks. For all the hand wringing about memory management, between smart pointers (rolled my own before there were library versions) and RAII I can't remember the last time I spent a serious amount of time chasing down a resource leak. Maybe early 90's? I dunno, but it seems that I spend more time debugging Python code where I am passing in a variable of the wrong type and Python just silently spits out the wrong thing in response. Would I like a 'better' language than C? Absolutely! Do I see one in my future? Not really. Because it is actually awesome at doing the kinds of things that need to be done.

by TheDong 12y ago

pjmlp 12y ago

> I've yet to actually use Cello myself since I feel like if you hack C up that much, you might as well just use something like C++, C#, Rust .... Since the early 90's I never understood why some programmers insist in using what is basically a portable macro assembler for higher level programming. It was already primitive when compared with the likes of Modula-2 and Turbo/Apple Pascal, not to mention all the other alternatives even higher level.

agumonkey 12y ago
Wasn't there some issue with Pascal type system being too restricting sometimes (the unfortunate lack of cast) ?
- hsitz 12y ago
  You're probably remembering something from Brian Kernighan's 1981 essay, "Why Pascal Is Not My Favorite Programming Language". Lack of unsafe typecasts, as well as (I think) all of Kernighan's other main points in that essay were cured in Pascal implementations by end of the 80's. But by that time C had captured all the mindshare.
- AnimalMuppet 12y ago
  It wasn't just the lack of a cast. (IIRC, you could work around that with variant records if you really had to, though it was really clumsy.) Another, unfixable problem was that the size of an array was part of the type of the array. This meant that you couldn't ever access past the end of an array, which was good. It also meant that you could never have a variable-sized array - you couldn't even talk about the type of such a thing. This meant that Pascal was completely unusable for writing, say, a memory manager (what type would you give to the return from an allocation)? But that's a low level problem. It also meant that Pascal couldn't be used for a numeric simulation where the size of your grid was a user-supplied runtime value. Note that I am only talking about the original (Wirth/UCSD) Pascal. I believe that Turbo Pascal fixed the variable-sized array problem.
  - pjmlp 12y ago
    Those problems were not part of the Pascal dialects. The largely ignored Extended Pascal ISO standard also had those issues fixed. The first Mac OS versions were written in Apple Pascal.
    - agumonkey 12y ago
      I knew about Apple programs being in Pascal, but the whole OS ? did they resort to inline asm ?
      - pjmlp 12y ago
        Yes, they did use Assembly. When implementing an OS avoiding Assembly is impossible. Even if intrisics are used instead, they are just another way of using Assembly like instructions. There are lots of informations in this book, "Revolution in The Valley: The Insanely Great Story of How the Mac Was Made".
        agumonkey 12y ago
        Yes indeed, I forgot about that. I wonder if there ever was a purely 'compiled' OS from some declarative form.
- pjmlp 12y ago
  No, that was a problem only with the original Pascal as designed by Niklaus Wirth for teaching purposes. None of the Pascal dialects that extended it with features for professional programming suffered from it.
  - GFK_of_xmaspast 12y ago
    Large parts of my undergraduate curriculum in the early 90s (at a mid-size well-funded public school in the united states) used pascal, and the unix and vms compilers we used most certainly suffered from the 'different array sizes are different types' issue.
RogerL 12y ago
In general, because those languages essentially declared things were 'bad' that aren't bad at all. Sometimes you have to mung data. Pull it in off a serial bus, strip out the header, rearrange it for the next thing you are sending it to, and so on. Other times you really do need/want some kind of dynamic dispatch or duck typing. You can do that with void* and function pointers. Ugly, yes, and error prone to boot, but possible. These days hardware is a lot faster. Back then I was writing my own graphics implementations because Windows GDI was way too slow for what I was trying to do. Just for a pretty ordinary app. Today, I am still concerned with how my data lies on the CPU cache. I need to access cards with C api's. It is nice to think about things like rust, but in my current company we have 2 decades worth of C&C++ code. It works with everything; we know that if a new card comes out it will come with a C API, we know that we can hire C programmers. The debuggers are astonishingly good (seriously; compare Visual Studio's debugger to thrashing around with some open source debugger for some other language. It's a production language, for professionals, to get shit done. It's not going anywhere for a long, long time. Not putting down the other languages - I use Python whenever I can, as it is such a joy to use. Anything other than C/C++ for most of my production code? Not in the foreseeable future. If you feel the urge to quibble about that last sentence, recall how much existing code I (and by extension, the world) already have. Never, ever, can we afford to throw that away. Shall we write some horror show of Haskell, Erlang, Javascript, and Clojure interfacing into 'legacy' code that in fact would need to be updated all the time? No thanks. For all the hand wringing about memory management, between smart pointers (rolled my own before there were library versions) and RAII I can't remember the last time I spent a serious amount of time chasing down a resource leak. Maybe early 90's? I dunno, but it seems that I spend more time debugging Python code where I am passing in a variable of the wrong type and Python just silently spits out the wrong thing in response. Would I like a 'better' language than C? Absolutely! Do I see one in my future? Not really. Because it is actually awesome at doing the kinds of things that need to be done.