search

objectionary / eo

EOLANG, an Experimental Pure Object-Oriented Programming Language Based on 𝜑-calculus
https://www.eolang.org
MIT License
1.01k stars 128 forks source link

A hybrid, not a true language? #74

Closed amihaiemil closed 7 years ago

amihaiemil commented 7 years ago

I like the idea of a language that comprises the rules described in Elegant Objects. However, can't it be a true language of its own, with its own vm or compiler directly into bytecontent?

If you simply translate it into java or c# you only add a rather useless layer.

First concern that comes to mind: why should I even struggle to learn a new syntax? Why shouldn't I simply apply the principles in my java code directly? I think that better than doing such a hybrid, you should develop a framework that encloses everything... one that provides objects such as If, For and While, for instance.

Second concern The world has already seen what a disaster such an idea is: GWT is the best example. Java that turns into Javascript at compile time. Everyone lost it when it came out, started writing software with it and now we're stuck with maintanance work and truly hidden and dubious bugs because, well, Java can't possibly work like JS unless you do some dirty tricks behind...

So forgive me, but I think if you go down this path, you will be making GWT 2 or worse.

alexpanov commented 7 years ago

Are Scala and Clojure disasters too?

amihaiemil commented 7 years ago

@alexpanov I haven't looked into them, to be honest. But think about the principle, how easy it is to make a wrong step - implement something on your side that translates poorly on the other one. Not to mention more languages are in discussion here, not just Java.

I think Scala and Clojure's designers have to pay a huge amount of attention to details in order not to make such a mistake...

amihaiemil commented 7 years ago

@alexpanov and all in all, I think it would be easier to make it from scratch, with its own vm, than to struggle and accomodate other languages and ecosystems. If it's something cool, it's gonna fly fast and a proper ecosystem will be built around it.

alexpanov commented 7 years ago

@amihaiemil ultimately, it is a trade-off between catering to intricacies of the existing platform and doing your own vm from scratch. For what it's worth, my opinion happens to be that it makes sense to take advantage of already existing platforms and build on the work that other people have done. Plenty of people know Java and there is at least a slim possibility of them contributing. With an all new platform, they are essentially left out.

Basically, it's a no true Scotsman fallacy. I disagree with the premise and, thus, with the conclusion.

amihaiemil commented 7 years ago

@alexpanov but don't you agree that it might be easier to write it from scratch than catter for other platforms? Implementation and bug-promptness wise speaking.

And what about my first idea? Why should I struggle to learn the new syntax in the first place? If I want to learn it I have to completely understand all the principles it stands for, and if I understood them, why not simply apply them in writing Java, since it's going to be Java anyway? Why do I need a black courtain in between?

alexpanov commented 7 years ago

@amihaiemil no, I do not agree with that either. I don't know. I have never written a compiler and I do not know whether it's easy to write it from scratch or have it compile into some other form of language or byte code.

I can only learn from other people and it seems like many more nice and progressive languages get created based on an existing platform. Examples are TypeScript, ES6 and Kotlin aside from the ones that I have mentioned before.

The only language that I am aware of that was created from scratch is Go. It was backed by Google though.

Why should I struggle to learn the new syntax in the first place

You make that decision for yourself. I can't make it and neither can anyone else for that matter. One possible reason however may be that you are unhappy with your current platform and want to do better OO. Or you want to explore different paradigms and evaluate them.

since it's going to be Java anyway

Why do you use Java if it's going to be Assembly anyway? Why use computers if in the end it's just a bunch of 1s and 0s? One possible answer is productivity. Or maybe discipline. Again, you are the one to decide.

There is a good list of core values and premises that the language is going to be based upon. That is the most important part. What it compiles into is unimportant to me. Interoperability and existing libraries are.

amihaiemil commented 7 years ago

@alexpanov I see... well, we are aimply not on the same page then. Not a tragedy.

About compiling... there's a common algorithm,, steps that you have to do. First you calculate the symbols table, get rid of redundancies auch as spaces and a bunch of other steps.. basically working with regexes, and/or finite automata and such things.

I'm not an expert, I only had a course in college. And yes, for sure it would be easier. For one thing, you dont have to know java amd c#. Imagine that instead of working with simple basic operations, you have to figure out Java's classes, what and when to use; what claswes will your compiled code use at runtime, for instance? Maybe it's just me, but it seems all so complicated. And we havent mentioned speed anywhere so far :D

jachinte commented 7 years ago

@amihaiemil It's not only that. You should look at existing projects, there is so much work and details you have to implement yourself. what about garbage collection? what about type checking? operators? basically working with regexes, and/or finite automata says that you need to go beyond a simple expression language to a general purpose language. Java may not be the best language, but its JVM is great; that's why languages like Clojure, JRuby, Jython, Kotlin, etc. are using it.

About compiling... there's a common algorithm,, steps that you have to do. First you calculate the symbols table, get rid of redundancies auch as spaces and a bunch of other steps.. basically working with regexes, and/or finite automata and such things.

IMHO, it's easier to map concepts from EO to Java than implementing the JVM from scratch. That also allows the language maintainers to focus in the language concepts instead of implementation details.

amihaiemil commented 7 years ago

@jachinte cc @alexpanov I get your points, they make sense; I also understood Alex's points. Of course it's not an easy job to write something from scratch.

But, as I said above (maybe not so clearly), the simple fact that I have a black "curtain" between what I write and what ends up actually being executed, I find terrible, especially since here we are translating from simpler to more complicated (eo is supposed to be lighter than java).

Here is a metaphor: eo skins Java alive, meaning that it takes almost everything away from it - and then wants to be translated into and work exactly like it.

Again, I like eo and the principles behind it - it's just that I don't see how you would make those work in Java well and without the risk of introducing serious bugs.

An example - some time ago I had a task in which I had to remove a null check from the code (you can see this PR if you have the patience). My problem was, essentially, that I didn't know how to represent a missing password other than null - how do you do it? I tried empty string then Yegor said that there might be servers that accept empty string passwords. Other then that, any combination of chars can be a password.

My question is: how do you represent such a case in eo and then translate it into Java? Whatever you do, on the Java side it's going to have to be a null somewhere, and you have no null on eo's side.

It's scenarios like these that make me run from hybrid languages :)

jachinte commented 7 years ago

@amihaiemil EO is not a hybrid language. The final user (developers) should not have to deal with Java at all, but EO only. That is the way most Domain Specific Languages work. How many times have you looked at the bytecode generated by the JVM? yet you write Java and not bytecode; the concepts in both sides are different, with different limitations and capabilities. I am pretty sure the generated code by EO will follow all the good practices Yegor promotes in his blog, but that is work of the compiler, not the EO developer.

amihaiemil commented 7 years ago

@jachinte

EO is not a hybrid language. The final user (developers) should not have to deal with Java at all, but EO only.

Yes, maybe "hybrid" is not the best word for what I meant. By "hybrid" I meant that it relies on another third-party platform, not that the developer would have to know both sides of the matter :)

alexpanov commented 7 years ago

I didn't know how to represent a missing password other than null - how do you do it?

The way to do that is to create a Password interface and two implementations: MissingPassword and PresentPassword (or with a better name). Without going too deep into the code of the library you were trying to improve, implementing equals and hashCode would probably do. Then you simply compare the two Passwords. MissingPassword is never equal to other Passwords. Granted, it does require more changes to the code base.

By "hybrid" I meant that it relies on another third-party platform

Java relies on JVM and compiles to bytecode, JVM runs on an operating system. Do you see that as a problem too?

amihaiemil commented 7 years ago

@alexpanov come on, don't act like you don't get my concern... all I said was that it seems very complicated and bug-prompt and that I don't see why I would learn a new syntax rather than applying the principles directly, by writing java (since it's going to be that anyway)

And you didn't answer any of my questions properly, you just flipped it and pointed out other side of the matter...

jachinte commented 7 years ago

@amihaiemil, EO is a different language. When someone tells me about a language and all the good features it has, the last thing I do is ask about the compiled code. And the reason is simple, I should not have to touch that code, not even read it. Instead, I ask about its good features; for instance, how would I manage concurrency and shared state? which feels unnatural and is error-prone in Java, is there a Java-like generics equivalent? can I access types data at runtime?, does it have a module concept or I have to use tools instead?, etc. I am not trying to say those are features to look up in a language, I am saying that my concerns are about what I can do in the language, and how. Then I compare with the languages I already know/use.

I would ask about the compiled code if I am concerned about speed. Is it a compiled or interpreted language?. However, modern machines allow us to sacrifice speed, and in exchange gain better abstraction in our programs. Yegor has a better phrase I think: computers are cheap and programmers are expensive.

I don't see why I would learn a new syntax rather than applying the principles directly, by writing java

alexpanov commented 7 years ago

don't act like you don't get my concern

I don't act like it. I really do not share them. I am aware of points you are making in general and I believe them to be a form of a logical fallacy. I am truly not concerned with performance during the prototyping stage. I mean, even the basic syntax is not yet finalized.

And you didn't answer any of my questions properly

Some of the questions you are asking, I am not able to answer and sincerely admit to. However, I only see three questions really.

If there are any questions you still have that you believe to not have been addressed, maybe it would help to lay them out in a more formal way. Just a suggestion though.

I still want to know if you perceive Java being compiled into byte code and byte code into something else to be a problem. Do you?

amihaiemil commented 7 years ago

@alexpanov Again - I don't have a problem with compiling something into something else in general. Every language works like that eventually. I have a concern specifically about eo <-> java, mainly because eo is so different in so many ways than Java.

I said above: it takes away so much stuff from Java and then wants to be compiled into and work just like it So it's so different in concepts that the safest (safest, not easiest) way would be to have it's own world, I believe. And I also believe it's a cool enough idea to fly on its own, not on the back of others.

My first example was GWT - I tell you, everytime I am forced to work with it (we have some apps in house), I compile the Java module and get a single minified JS file.. I can only imagine what kind of crap did those guys do to turn all my java into a minified js file. Then comes the nightmare: the build done on my laptop works because it's done with oraclejdk, the one from the CI sometimes fails because it's done with openjdk - I change the jdk and it still won't work etc etc. I think you get the picture.

And again, I understand your arguments, but still they don't make my fear go away.

Lastly, I thought about this ticket for quite a long time before opening it. At first I didn't want to open it, I sort of knew the answers already, but you know how it is: when you have something on your mind you'll eventually let it out :D

alexpanov commented 7 years ago

@amihaiemil I understand what you mean. GWT is indeed a bitch.

I think if you look into Clojure a bit, some of your concerns may go away. It's a completely different language that runs on the JVM. Granted, it compiles to byte code, not Java code. Still, it shows that it's at least possible.

stain commented 7 years ago

I think compiling through Java is a good way during prototyping of the language to see what it looks like in the "classic" world.

If we come to a stage where some of the Java code starts looking weird, e.g. an EO constructor call becomes a series of unwrapped Java helper methods and encapsulations, in a way that direct link is broken and your argument comes into play. Probably this will be more an issue for the object definitions than for the type declarations. EO's objects might in Java world have to live as static fields, subclasses or in a massive call stack. We need flexibility in this - and if we're already at bytecode level this is harder to change.

But that would would then be the moment to try to compile directly to JVM bytecode instead, as done by Scala, Groovy and Clojure. It is not new ground, even Android Dalvik converts from JVM bytecode to native calls, so that's a hardware (and library) compatibility ecosystem I don't think we want to dismiss.

I think once we are at that stage could it make sense for brave souls to look at compiling directly to machine code - or even still an other intermediary like Go. EO as it stands could be a good candidate for that; a pure and thread-safe functional object oriented programming language can be executed in many different ways.

If we go straight to compiling directly to a particular CPU architecture I think that deviates us strongly from our goal of making an Object oriented programming language. I would argue that living in isolated compatibility islands is what has long hampered classical non-C-compatible languages. Languages like Python and Ruby "cheated" by making it easy to wrap C functions - but at the cost of bad stuff like a Global Interpreter Lock and difficulties in portability and library installation.

yegor256 commented 7 years ago

@amihaiemil ultimately, we will have multiple compilers. One will compile to JVM bytecode, another one to PHP, another one to Ruby and then another one to x86 binary code. EO is language of a high-level, that's why we don't really care about technical details of the code it compiles to. We need to build a clear and solid OO-concept, which will prove that a true object-oriented programming may actually work -- this is our goal. There are so many languages on the market that are fast, concurrent, etc. But there are none, which are truly object-oriented.

amihaiemil commented 7 years ago

@yegor256 Glad you took the time to have a look here :D

yegor256 commented 7 years ago

@amihaiemil I added this: https://github.com/yegor256/eo/commit/ca09a124d402ced662e13c9322e4b504f3dc09af Thanks for raising this concern, it was really valid.