Hacker News Reader

Comment by owenm | Hacker News Reader

This is an impressive achievement, given there’s a whole language plus IDE. Kudos to the author. I couldn’t see any indication of what the author plans to use it for - I hope he can share more below?

I’m intrigued by the LeanQt library as well that the IDE uses (https://github.com/rochus-keller/LeanQt) too.

View on HN

> what the author plans to use it for

Thanks. I e.g. re-implemented the Smalltalk-80 VM in Luon (see https://github.com/rochus-keller/Smalltalk/), and I consider implementing an Interlisp VM (see https://github.com/rochus-keller/gingko/) which uses LuaJIT, which was an important motivation to interrupt my Micron language project to implement Luon.

nice! do you feel like oberon has something that gives it an edge over more currently popular languages, or is it just a matter of personal preference?

Actually, I only use original Oberon when I'm migrating the old Oberon systems. My interest lies in finding out how I would have to modify original Oberon to be as productive as I am used to with e.g. C++, but still adhering to the goal of simplicity. My version, which I call Oberon+ (and to which Luon is quite similar, whereas Luon is even simpler), goes in this direction.

Actually an "edge over more currently popular languages" from my humble point of view is the goal and maintenance of simplicity. The term is subjective, but if you look at many of today's completely overloaded languages, it is intuitive to understand.

I have to ask, "why?" in the spirit of if you're smart enough to write an Oberon on top of Lua and then use that to write a Smalltalk VM then you're certainly smart enough to get around a complicated language and tolerate a lack of some simplicity.

Probably a similar reason why equations are simplified in mathematics. If something is not represented or implemented as simply as possible, there is obviously overhead or redundancy. In the sense of the lean philosophy, that would be waste.

Simple solutions are also less prone to errors and easier to modify and expand. This reduces the probability of errors and makes it easier to maintain and update the system.

Simplicity makes systems (and programming languages) easier for users to understand and use. This leads to greater user-friendliness and reduces the learning curve, resulting in a more positive user experience and, in turn, a lower error rate.

I'm sure there are many more reasons (apart from the obvious proof by authority, which is based on the statements of, for example, Einstein or Wirth).

The Interlisp VM sounds awesome - I would love to see Notecards on Windows/Linux/Mac natively!

What do you mean by "natively"? Ahead of time compiled, or just working? If the latter, the present VM is already available on the mentioned systems. In my version, Gingko, I additionally removed a lot of outdated code to increase platform independence.

Amazing that you also managed to implement Smalltalk besides Oberon and Luon - all of them with IDEs!

Wow!

And by the way the startup speed of the IFE is just insane! it is actually faster than my simple text editor!

One of the most delightful places I’ve used Lua recently is in TurboLua, which gives the Lua VM access to all the necessary signals/pipes for writing high speed network applications, among other things. (https://turbo.readthedocs.io/en/latest/)

Do you see there being a way to make a TurboLuon with current specs?

I don't use TurboLua, but I think it's feasible to build a Luon adapter module if need be. The necessary 'extern' keyword is already part of the spec.

Amazing project!

I get the appeal to write an IDE from scratch, especially if you are already an expert in writing GUIs with your framework of choice! I wonder if it would make more sense to spend that time writing a language server protocol daemon. That way, you could make your language available in any IDEs your users like that support LSP.

I'm usually working on older machines on which the IDE's supporting language servers would be much too slow or wouldn't work at all because of incompatibilities. I like lean tools with little dependencies. But there is a parser in moderate C++, so maybe someone else will implement such a daemon.

Could I ask why you find yourself working on older machines? Work? A fan of retro computing? Something else?

It's excellent hardware, I have many redundant copies and thus high availability, the system just works, I automatically take care of efficient implementation, and the generated executables have high probability to work on all newer Linux systems. And I'm too old to always chase for the new new version.

Optimizing your code for slow machines is a really great thing. I wish more people would do it. If your code runs well on a slow computer then it'll run well on anything better too. A lot of code these days only runs "well" on very fast computers...

I mainly develop TXR on a refurbished Intel box with a CPU that's like from around 2009 or something. It takes at least three times longer to rebuild everything than on modern machines. (It does have 32 gigs of RAM which is good for multiple virtual machines.) In fact I have one Dell box that was a server in a startup company that shut down in 2010. And that box builds the code significantly faster.

Even VIM has support for LSP in extensions, I'm sure there's some lightweight LSP supporting editors out there.

I am actually glad that this person developed the IDE. Please download the IDE and try it. It is exceptionally fast. When I compare the speed with that of IDEs like Visual Studio Code etc, the difference is night and day.

Reply on news.ycombinator.com