Miranda released as free software • Hacker News Board

Re: Miranda released as free software

#111

Post by Volt » Sun, Mar 01, 2020, 3:56 AM UTC

kick wrote: post #101

comex wrote: post #59

Earlier quoted context omitted.

As far as I know, all three of those languages are interpreted. They might be good at slinging together predefined operations with fast implementations written in another language (C)… as long as you’re operating in parallel on large arrays, so that you spend more time inside the C functions than actually interpreting. But if you need to write your own operations or just do anything that’s isn’t massively parallel, n…

k is faster than hand-written C in many cases, and significantly faster than compiled Haskell.

You're ignoring the main point of the comment though:

>For example, you couldn’t write a performant compiler in them.

Re: Miranda released as free software

#112

Post by terminaljunkid » Sun, Mar 01, 2020, 7:11 AM UTC

kick wrote: post #41

jolux wrote: post #15

Earlier quoted context omitted.

"the art of writing compilers and interpreters has effectively been lost" I'm curious, how does that happen? Were the techniques used in compilers and interpreters of yore never recorded for posterity in academic papers or technical documentation?

Spent a good while thinking on your question: The best stuff was all proprietary for decades. Even now, we only got Miranda's source code weeks ago. Miranda was written in the 1980s! It's the same for a lot of languages. Nial's the example I usually bring up for one that was freed far too late. People with the domain knowledge that would have helped deal with the complexity of modern systems are all either retired, h…

> The best stuff was all proprietary for decades.

Well, maybe. But it is hard to believe if most of those things aren't rediscovered in these decades. And IIRC that GCC took over partially because it was quite better. GCC / LLVM appear to implement every new technique in someone's PhD thesis like Diophantine equation solvers into optimization passes. I suspect it is no longer the case.

If you're saying compiler itself is slow, well the rat race among compilers is producing benchmark binaries (sadly). But given how much we have advanced, I suppose fine grained incremental compilation should be norm in every compiler.

> Turbo Pascal, too

Here I suppose you are talking about compile speeds. Well Turbo Pascal had the advantage that it was integrated with an IDE. Eclipse and IIRC visual studio can also reach those speeds using incremental / background compilation.

> We'll probably never see the source code behind any version of the k interpreter by Arthur Whitney

I have heard a about this K. What is this? Is this an array programming language like APL? I would like some pointers.

> Having portable compilers that try to heavily optimize is a mistake. Again here there are tradeoffs. People like the comfort of portability and thus don't care about small performance increments as long as code performs reasonably well. Although I would think we can have a peephole optimizer that can optimize based on target machine upon installation.

> No one seems to know what a CPU cache is!

While this may be true for normal programmer, compiler implementers care quite a lot about caches. Especially most JIT optimizations are about cache.

> Compiling to C / LLVM IR doesn't make sense.

Sure that's a tradeoff. But that allows to implement compilers in less time and utilize most optimizations.

However I too think the progress in compilers has stalled in these years. There are native programming languages being created. But it is almost Compile to C or embracing LLVM monoculture. Appreciably Go didn't do that. And due to proliferation of scripting / JIT languages, there's not much scope for optimizing or fast compilers. In particular I am sceptical of LLVM monoculture. The compilers rat race prioritizing benchmarks above other things isn't going to end well. Moreover my gut feeling is today's compiler infrastructure is not suitable for High level languages.

Re: Miranda released as free software

#113

Post by pjmlp » Sun, Mar 01, 2020, 7:50 AM UTC

onei wrote: post #90

pjmlp wrote: post #69

Earlier quoted context omitted.

Compiling to bytecode is almost a decade older than BCPL, was the way to go at Xerox PARC and most mainframes that survive to this day.

From what I can tell, Xerox PARC didn't exist until 1970 and apparently used Smalltalk, which was after BCPL in 1967. I don't doubt you're correct, so do you have any links for earlier bytecode examples?

Burroughs Large Systems, released into the market in 1961, nowadays sold as Unisys ClearPath MCP mainframes.

Xerox PARC had Smalltalk, Mesa (later Mesa/Cedar) and Interlisp-D.

The platforms would first load the respective microcode into the CPU for the bytecodes used by the desired workstation environment.

Initially Xerox PARC made use of BCPL, but quickly they realised it wasn't the best way to write systems software and created Mesa to replace it.

After all, BCPL was intended to bootstrap CPL, not to write fully systems with it.

Other 60's computer companies were making use of either Algol or PL/I dialects, all the way up to the 80's.

Lots of juice papers at Bitsavers.

Re: Miranda released as free software

#114

Post by ferzul » Sun, Mar 01, 2020, 7:53 AM UTC

kick wrote: post #99

chrisseaton wrote: post #65

Earlier quoted context omitted.

I think you’re conflating language design with language implementation. If I’m being paid to write a Ruby compiler then ‘keep the language simple’ isn’t an option available to me, is it. And the techniques from the 80s would be absolutely hopeless at compiling and optimising Ruby. A lot of the implementation approaches you’re talking about work brilliantly for a single-pass compiler for a trivial language like Pascal…

I'm not conflating anything, as far as I'm aware. The question was: "the art of writing compilers and interpreters has effectively been lost" I'm curious, how does that happen? Were the techniques used in compilers and interpreters of yore never recorded for posterity in academic papers or technical documentation? I think I did a pretty good job in answering it, although it was a bit rambling. The people on the stand…

i know you're in high demand in this thread, but if it's possible to publish that folder (or the refs therein) that would be nice.

Re: Miranda released as free software

#115

Post by ferzul » Sun, Mar 01, 2020, 9:50 AM UTC

brmgb wrote: post #29

saagarjha wrote: post #26

Earlier quoted context omitted.

> Haskell is still stuck with most of the wrong decisions they made in '88 Which ones?

While I don't agree with the general snarkiness towards Haskell of the commenter you are replying to, being lazy by default could be seen as Haskell original mistake. It was interesting from a research point of view though.

it's hard to call the sine qua non of a language a bad design decision. if it were, the language would be dead. haskell survives because it's a lazy purely functional language with some industry support. bad design decisions have to be something apart from that.

Re: Miranda released as free software

#116

Post by ferzul » Sun, Mar 01, 2020, 10:01 AM UTC

9q9 wrote: post #73

kick wrote: post #51

Earlier quoted context omitted.

Haskell was written as academia's response to Miranda's licensing fees. Were Miranda freeware (but not source available or Free Software), it probably would still be well-known. It's still taught in many universities. I certainly agree that most languages should be libre, but clearly it's not necessary for success. k has brought billions of dollars of profit, but is the most proprietary of all languages. C# developer…

Miranda's cost was a big problem, but not the only one. The other core issue that lead to the creation of Haskell was Miranda's license that essentially prohibited using it as a tool for programming language research. For good reason, Turner (Miranda's creator) wanted to avoid the fragmentation of Miranda into different dialects. From [1]: > [T]he easiest way to move forward was to begin with an existing language, an…

over a long enough time frame, it seems his view is standard. nowadays, there's not really a haskell standard other than ghc. there's other haskells than ghc (e.g. ghcjs) but they're all forks of ghc. research is achieved by enabling extra features

(i guess eta isn't tracking ghc, but i think that's because of unviability rather than a specific intention to fork the language.)

Re: Miranda released as free software

#117

Post by hope-striker » Sun, Mar 01, 2020, 10:53 AM UTC

chombier wrote: post #85

nicoburns wrote: post #79

Earlier quoted context omitted.

Rust.

If you don't box all your closures, functional programming in Rust gets tedious quite quickly. But if you do, I guess it's no longer that fast...

> If you don't box all your closures, functional programming in Rust gets tedious quite quickly.

Somewhat true, but argument position and return position impl Trait have made that slightly nicer.

Re: Miranda released as free software

#118

Post by pjmlp » Sun, Mar 01, 2020, 11:13 AM UTC

saberience wrote: post #84

LessDmesg wrote: post #37

Here's an idea I have: never close-source any programming language, make 'em free and open from day zero. Languages are not products, but infrastructure, like roads. They benefit and grow from the number of users, not from paywalls. Closed languages tend to fade into obscurity. That's why everyone knows Haskell and nobody knows Miranda, everyone knows Java and nobody Eiffel. I laughed when I read that the author of S…

How is JVM miles ahead of the CLR? All I ever hear (at my current and previous jobs) is about how Java's runtime and tools are miles behind .Net and the CLR.

As someone that works with both platforms since the early days.

It supports more platforms and implementations than CLR ever will, including bare metal deployments with real time GC.

Thanks to those implementations, there is a plethora of GC algorithms and JIT/AOT optimizations not yet available in CLR, like AVX-512 auto-vectorization, JIT code caches with PGO, tiered JIT compilation, real time GC, GC able to deal with multi-TB heaps with ms pauses, ...

If you want something like VisualVM or JFR, you need big pockets for Visual Studio Enterprise, and it still doesn't match in capabilities.

Naturally the CLR has other things going for it like having had NGEN since day one, value types, reiffed generics and designed from the get go to support multiple languages, including C++.

Re: Miranda released as free software

#119

Post by voidhorse » Sun, Mar 01, 2020, 2:17 PM UTC

kick wrote: post #103

voidhorse wrote: post #86

I've been playing with Miranda a little bit since seeing this yesterday, and man, I gotta say, the quality of the REPL environment and documentation is amazing. Everything is laid out plainly, and you can learn how to work with the language in a matter of minutes. Even the readme was one of the best I've ever encountered. It makes no undue assumptions and leaves no work up to the reader. It even notes that one may ne…

I shared this comment with a friend because it made me happy that something I posted was getting more than a surface-level review, and they responded like this to your last paragraph: This is an interesting note to end on, because I'm not sure licensing and funding is one of the main factors that leads to this sort of thing. I think rationally designing environments in a holistic way is just sort of a lost art among…

That's great! I think your friend's take is sound and I agree with that being the likely root cause. I do wonder if there's a certain relationship between a closed project, however, and rational, focused design—not a necessary relationship at all, but perhaps a synergistic/convenient one (closed or tight-knit projects lending themselves to singular, disciplined visions, projects that are fundamentally open having a greater tendency to allow less focused design decisions creep in).

I would agree on the "lost art" and "anarchy" — this definitely gives me something to think about!

And I'm glad you shared this! I had a blast checking it out.

Re: Miranda released as free software

#120

Post by 9q9 » Sun, Mar 01, 2020, 6:13 PM UTC

ferzul wrote: post #116

9q9 wrote: post #73

Earlier quoted context omitted.

Miranda's cost was a big problem, but not the only one. The other core issue that lead to the creation of Haskell was Miranda's license that essentially prohibited using it as a tool for programming language research. For good reason, Turner (Miranda's creator) wanted to avoid the fragmentation of Miranda into different dialects. From [1]: > [T]he easiest way to move forward was to begin with an existing language, an…

over a long enough time frame, it seems his view is standard. nowadays, there's not really a haskell standard other than ghc. there's other haskells than ghc (e.g. ghcjs) but they're all forks of ghc. research is achieved by enabling extra features (i guess eta isn't tracking ghc, but i think that's because of unviability rather than a specific intention to fork the language.)

I think the difference is that today nobody is preventing you from forcing GHC or adding features, while back in the early 1990s, Research Software Ltd, the company creating Miranda, would probably have prevented others from forking Miranda. 30 years ago, the value of open source and the network effect for programming languages was not widely understood. In particular, giving away from free and without restrictions a company's core IP was inconceivable for traditional businesses!