When is it the right time to rewrite code from scratch?
-
If by 'write glue' you mean 'use the provided interop/IPC libraries', then yes, you have a point
-
It's not just using those libraries. It is defining API for the objects that the libraries can use and adapting the API that the libraries provide on the other side to actually feel sensible in the target language and so.
And this is also the reason why it's hard. Because each language has somewhat different concepts and ways of doing things and the abstractions that make sense in one don't in the other, so you have to tweak and adapt.
-
-
I am used to it.
I am just saying it would be great if there was something that would make it easier. And to be honest I have not seen many attempts at trying to do something about it generally.
-
The CLR's type system isn't rich enough to support Haskell.
I do not believe you.
It may be slow because it's emulating stuff it doesn't have native operations for, but there's nothing preventing someone from doing it. Get to it, slacker.
CLR is basically machine code. If you can write a Haskell compiler that compiles to x86, you can write one that compiles to CLR. (Hell, you can probably map x86 -> CLR 1:1, or close to it.)
-
You may end up with some issues with interoperability even then. The reasons stated for Lisp's CLOS not being ported are essentially that it handles multiple inheritance and floating point numbers in a substantially different way. I take that to mean that even if you did, you'd lose out on several of the reasons for putting it on the CLR. Sometimes it works (IronRuby, IronPython, etc), but sometimes it's probably not worth the effort.
-
I'll giv e you floating-point; a language that doesn't use IEEE754 could have difficulties on the CLR. Multiple inheritance though, that'll work; C++ can be compiled to target the CLR after all.
-
Multiple inheritance though, that'll work; C++ can be compiled to target the CLR after all.
Assuming it works the same way... I haven't studied the CLOS or C++ MI, but there certainly could be some strange differences... they can probably be programmed around, but again, we're probably past the point where the effort is worth it.
-
Whatever. Who cares.
The point is:
-
You can write a library in an arbitrary language and use it from another language
-
But only if you give up on that stupid shitty compiled language buggy bullshit and join the rest of us here in the 21st century
I don't want to spend a month arguing about fucking floating point formats, the point is made. If you agree with the point, fine. If not, make a counter-point that doesn't rely on arguing about fucking floating point formats. Also die.
-
-
Interoperability has nothing to do with whether the code is compiled, bytecode, interpreted or executed by means of sacrificial pigeons.
All it requires is a clearly-defined interface.
For proof, everything that runs on Windows is obviously compatible with C. Because Windows was written in C.
-
Assuming it works the same way... I haven't studied the CLOS or C++ MI, but there certainly could be some strange differences... they can probably be programmed around, but again, we're probably past the point where the effort is worth it.
Multimethods would likely be a trip-up for interop.
1) You can write a library in an arbitrary language and use it from another language
- But only if you give up on that stupid shitty compiled language buggy bullshit and join the rest of us here in the 21st century
Hrm -- challenge to you: implement a Clojure multimethod in Plain Ol Java. (Or C# if you're using the CLR version of Clojure.)My point: for modern values of "use" -- which not only means "call functions and use data items from", but "extend types from", you can still run into issues in a bytecoded VM environs.
-
Lesson learned: people only read the bits of my post in list form.
Now die.
-
-
Now die.
hmm... my todo list is a bit long, but i think i can slot that task in for about fifty years from now.
-
Hrm -- challenge to you: implement a Clojure multimethod in Plain Ol Java. (Or C# if you're using the CLR version of Clojure.)
Why? OO languages already have dynamic dispatch, why would we want to half-ass it?
-
But only if you give up on that stupid shitty compiled language buggy bullshit and join the rest of us here in the 21st century
Funny how I'm arguing with someone on another topic about how Web Apps aren't automatically superior, and his argument is that relying on the browser for executing your web app means no installation, etc.
And yet, people are bemoaning the idea of a universal platform for jit-compiled languages. Which is just another form of a framework that gives you everything you need to be platform independent, etc.
Why reinvent the compilation wheel?
.NET already abstracts compiling directly to hardware.
-
OO languages already have dynamic dispatch
C# only does if you use the
dynamickeyword, which is about as useful as saying you can use pointers withunsafe.
-
Lesson learned: people ... read ... bits of my post ...
Hey, we have things to do. Get to the point.
-
Why? OO languages already have dynamic dispatch, why would we want to half-ass it?
I mean that you have a defmulti in a Clojure interface you're implementing -- and you need to implement it from Java (or C#)...
And OO dispatch is single dispatch, btw.
-
Oh right, pedantic dickweedery. It's been awhile.
Do you need more frequent reminders? I'm asking for a friend.
-
Nobody's stopping you from making a Java that compiles to .NET.
I went to JavaONE or something in the late 90s and one of the exhibits was someone selling (IIRC) an Ada compiler that produced Java bytecode.
-
i think i can slot that task in for about fifty years from now.
-
well obviously that is a rough estimate based on current science. ;-)
-
Still holding out hope for immortality?
-
there's always hope.
-
Huh? Haskell's type system is significantly more expressive than the CLR's. The CLR isn't capable of doing the kinds of type inference and type checking Haskell compilers do.
I'm with @RaceProUK; I don't see why the CLR comes into it. I mean, I can see why it could come into it to provide better support (to allow the generation of smaller code or faster code) but I don't see why you couldn't have a Haskell/CLR. GHC can compile to C, and C doesn't do the kinds of type inference and type checking Haskell compilers do either.
-
And OO dispatch is single dispatch, btw.
TDEMSYR
The way you handle dispatch and whether or not something is OO are entirely separate concerns.
-
Technically, yes. Practically... I don't know any language I would categorize as OO that does anything but single dispatch.And OO dispatch is single dispatch, btw.
TDEMSYRThe way you handle dispatch and whether or not something is OO are entirely separate concerns.
Edit: apparently there is a Python package that adds multimethods to Python, and (as mentioned above and I kind of zoned across), C# supports it. So I take back what I said mostly.
-
Sure, but how are you going to link to your new library? GHC keeps interface files around for libraries, and does type checking at compile/link time.
I've seen some projects that partially manage this issue for, for example, LLVM's intermediate language. But a lot of type information gets lost, and it is on you (the developer) to make sure that it works (and not the compiler). Not so easy considering that Haskell's type system is richer.
In other words, the question isn't whether you can build a library, but how you would use it, given that whatever you pass in needs to be "compatible" with the type of the function.
-
In other words, the question isn't whether you can build a library, but how you would use it, given that whatever you pass in needs to be "compatible" with the type of the function.
So you can't check things that get passed in and reject those that don't match? That sounds like your richer type system is effectively shittier.
-
Not so easy considering that Haskell's type system is richer.
It doesn't matter how rich the type system is; at the end of the day, it's all just bits and bytes. All that's necessary is for both sides to agree on an interpretation.
-
Type erasure. Type checking happens at compile time, and then the runtime never has to check types again.
-
The type is the interpretation...
-
I am willing to believe that to get type correctness you need to have the whole Haskell program available, because then you don't need to push type correctness to the CLR. But is that any different from the current situation? Can I use GHC to compile a Haskell library to C or to native code and link that against a Haskell program?
-
never has to
Is that "can't" or normally doesn't because compiler checks it? As the first is shittier.
-
-
So you can't check things that get passed in and reject those that don't match? That sounds like your richer type system is effectively shittier.
If you need dynamic checks to enforce your type system, you're not implementing Haskell. You may be implementing something that uses the same syntax as Haskell and has the same semantics for type correct programs, but not Haskell.
-
It's a feature, not a bug. Fewer conditionals.
-
And type erasure means the library "doesn't have an interpretation" that other programs can agree to, because the interpretation is made implicit in the "bits and bytes" at compile time.
-
And? Marshalling is impossible or something?
-
It's a feature, not a bug. Fewer conditionals.
There is a difference between not needed and can't put in. Just cause it automatically has a belt doesn't mean that not being able to put in suspenders (as libraries should be doing) is good.
-
I don't know any language I would categorize as OO that does anything but single dispatch.
Common Lisp. Oh, you don't count CL as an OO language, despite having one of the most powerful type systems ever invented? This is yet another orthogonal concern.
-
That's exactly the problem. We can trivially marshal pure data, by choosing an encoding, but how do we handle type checking when we marshal functions or monad actions? If we marshal a lock, how can we check that the key we put in fits?
-
And what does any of this have to do with the right time to rewrite code from scratch???
-
If you want to use a Haskell library in .NET, your option is pretty much to re-write from scratch...
-
Oh, excuse me; I seem to be forgetting that Haskell is some über-language that's impossible to link to any other language, despite having to run on an OS written in C.
@Captain said:If you want to use a Haskell library in .NET, your option is pretty much to re-write from scratch
Bullshit; you just can't accept there's such a thing as interop
-
you just can't accept there's such a thing as interop
To be fair it sounds like his one true chosen language makes it a bitch and a half to do because of not being able to do type checking outside compile time.
-
Yes, it runs on an OS written in C. And it consumes C values. Super. How does that imply that its "easy" to link Haskell libraries and consume Haskell values and functions from C programs? (Hint: it doesn't)
-
But, but, bad messy things could ruin the immaculate purity of his Haskell code's execution!
-
So Haskell can interop with other languages now?
