Niklaus Wirth has died

Post by pjmlp » Thu, Jan 04, 2024, 6:36 AM UTC

kragen wrote: post #198

pjmlp wrote: post #139

Earlier quoted context omitted.

Indeed, however the experience with crashes and security exploits, has proven that scaling processes, or even distributing them across several machines, scales much better than threads.

preemptively scheduled processes, not cooperatively scheduled

Post by pjmlp » Thu, Jan 04, 2024, 6:45 AM UTC

dragonwriter wrote: post #233

musicale wrote: post #232

Earlier quoted context omitted.

It's a shame that Pascal was largely abandoned (except for Delphi, which lived on for a while); I believe several Pascal compilers supported array bounds checking, and strings with a length field. In the 1980s this may have been considered overly costly (and perhaps it is considered so today as well), but the alternative that the computing field and industry picked was C, where unbounded arrays and strings were a com…

The industry picked C when Pascal was still widely supported, not as a result of it being abandoned.

Post by vaxman » Thu, Jan 04, 2024, 7:10 AM UTC

Post by vidarh » Thu, Jan 04, 2024, 7:17 AM UTC

kragen wrote: post #256

vidarh wrote: post #231

Earlier quoted context omitted.

I'm aware of the idea. I'm also aware that I can read and understand a whole lot of pages of code in the amount of time it takes me to decipher a few lines of K for example, and the less dense codes sticks far better in my head. I appreciate brevity, but I feel there's a fundamental disconnect between people who want to carefully read code symbol by symbol, who often seem to love languages like J or K, or at least he…

i keep hoping that one day i'll understand j or k well enough that it won't take me hours to decipher a few lines of it; but today i am less optimistic about this, because earlier tonight, i had a hard time figuring out what these array-oriented lines of code did in order to explain them to someone else textb = 'What hath the Flying Spaghetti Monster wrought?' bits = (right_shift.outer(array([ord(c) for c in textb]),…

    textb = 'What hath the Flying Spaghetti Monster wrought?'

    p textb.bytes.product((0...8).to_a).map{_1>>_2}.map{_1 & 1}

    class Array
      def outer(r) = product(r.to_a)
      def right_shift = map{_1>>_2}
    end

    p textb.bytes.outer(0...8).right_shift.map{_1 & 1}

    class Array
      def &(r) = map{_1 & r}
    end

    p textb.bytes.outer(0...8).right_shift & 1

    textb = 'What hath the Flying Spaghetti Monster wrought?'
    
    class Object
      def k = KArray[*self.to_a]
    end
    
    class String
      def k = bytes.k
    end

    class KArray >_2}.k
      def &(r) = map{_1 & r}.k
    end

    p textb.k.outer(0...8).right_shift & 1

Post by LispSporks22 » Thu, Jan 04, 2024, 7:23 AM UTC

senderista wrote: post #271

kragen wrote: post #258

Earlier quoted context omitted.

in the 02000s there was a lot of interest in software transactional memory as a programming interface that gives you the latency and throughput of preemptive multithreading with locks but the convenient programming interface of cooperative multitasking; in haskell it's still supported and performs well, but it has been largely abandoned in contexts like c#, because it kind of wants to own the whole world. it's diffic…

I was considering making a startup out of my simple C++ STM[0], but the fact that, as you point out, the transactional paradigm is viral and can't be added incrementally to existing lock-based programs was enough to dissuade me. [0] https://senderista.github.io/atomik-website/