[HN Gopher] Free Oberon: Cross-platform Oberon IDE
___________________________________________________________________
Free Oberon: Cross-platform Oberon IDE
Author : AlexeyBrin
Score : 97 points
Date : 2023-11-12 14:28 UTC (8 hours ago)
(HTM) web link (free.oberon.org)
(TXT) w3m dump (free.oberon.org)
| WillAdams wrote:
| Every time Oberon comes up, I wonder how it would have done if it
| had had a "normal" graphical interface, and some aesthetically
| minded person such as Keith Ohlfs or Susan Kare to make it
| attractive by the standards of the average user/developer.
| pjmlp wrote:
| Isn't this normal enough?
|
| https://www.progtools.org/article.php?name=oberon§ion=co...
|
| Good enough when placed against many UNIX windows managers, or
| the developer beloved Plan 9 and Inferno GUIs.
|
| It failed because like Xerox, it stayed mostly inside ETHZ
| walls, a few European universities and zero industry interest,
| too much focused on building UNIX clones.
| cyberax wrote:
| > Isn't this normal enough?
|
| It definitely is not normal enough. It's a whole operating
| system, after all.
|
| > It failed because like Xerox, it stayed mostly inside ETHZ
| walls, a few European universities and zero industry
| interest, too much focused on building UNIX clones.
|
| Not really. It failed because Oberon was not a great language
| even in the 2000-s. Right now it's not even good enough for
| teaching purposes.
| pjmlp wrote:
| Apparently it was good enough to inspire Go authors, and
| everyone that enjoys its influences in Go, as the ultimate
| design in language simplicity.
| cyberax wrote:
| As an inspiration for some of the ideas? Maybe. As a
| language in itself, Oberon was crappy even at that time.
|
| From the very start, Go was utterly practical, designed
| to be used for actual programming, and not PhD theses.
|
| So compared to Oberon, Go had hash maps from the start.
| It didn't have the SCREAMING PROCEDURE/RECORD/VAR case-
| sensitive keywords, Go had multiple return values for
| error handling from the start, better namespacing
| support, variable declaration in-place, full support for
| UTF-8 for strings, etc.
|
| And of course, Go has lightweight threads and channels,
| making it a great language for servers.
| pjmlp wrote:
| If you are stuck with a tunnel vision of the 1992's
| version of Oberon, yeah.
|
| Except that Active Oberon from 1996, sorted out most of
| those cases.
|
| Hash maps don't need to be built-ins, as proven in many
| languages.
|
| Active Objects take care of lightweight threads and
| channels.
|
| Oberon, the OS, was also good enough for Go's hero Rob
| Pike to implement ACME and RIO on the same UX principles,
| re-use Oberon-2 (yet another version you ignored) method
| syntax, and Oberon's SYSTEM package as unsafe.
|
| Screaming keywords, only an issue when someone doesn't
| use an editor with automatic capitalization, only an
| issue for Notepad-like users.
| cyberax wrote:
| We're talking about Oberon here, not about its clones.
| And I based my reply on Oberon-2. It definitely sucked.
|
| > Hash maps don't need to be built-ins, as proven in many
| languages.
|
| Except Oberon doesn't have generics.
|
| From the very beginning, Go included very practical
| "magic" generic functions: append, len, cap, delete.
| Along with slices, they allowed Go to flourish without
| generics.
|
| Oberon only has LENGTH.
|
| > re-use Oberon-2 (yet another version you ignored)
| method syntax
|
| Here's Go: "func (c Type) DoSomething(hello, world
| string) (int, error)". Here's Oberon: "PROCEDURE (c:
| Type) DoSomething(hello, world: STRING): INTEGER;" (error
| handling is for wimps).
|
| It is similar, but not the same. Go also has structural
| polymorphism, which Oberon lacks.
|
| > Screaming keywords, only an issue when someone doesn't
| use an editor with automatic capitalization, only an
| issue for Notepad-like users.
|
| IT LOOKS UGLY, AND IT MATTERS A LOT, WHEN YOU MOSTLY READ
| THE CODE.
|
| So yep, I maintain that Oberon is a shitty language. It
| might be useful as a starting point for new language
| design, but that's it.
|
| It has never been practical, and on its own it only ever
| "succeeded" in the ETH where professors just forced
| students to use it.
| Rochus wrote:
| > _It 's a whole operating system, after all._
|
| You can use that one which easily starts on all platforms
| without taking control of the PC:
| https://github.com/rochus-keller/oberonsystem3
| WillAdams wrote:
| Maybe, but that's not what's being shown on the linked
| website.
| pjmlp wrote:
| Maybe because the linked Website is not the original
| Oberon, and derived OSes done at ETHZ.
|
| The question of the parent naturally should be answered in
| regards to what was available during the 1990's.
| WillAdams wrote:
| Working from uncertain organic memory, but yes, the other
| screens look much better.
|
| I've actually always been quite fond of the concept of
| Oberon --- wondering if this implementation might work
| well for a potential future pet/side project: making a
| graphical front-end for METAPOST/METAFONT.
| pmontra wrote:
| I remember Oberon. My take is that it failed to become a
| mainstream language because we were using C to write system
| tools and browsers, Visual Basic and Visual C++ to write
| Windows apps and PHP and Java to write web apps. Those filled
| most niches.
|
| Delphi and the Pascal languages were on a downward spiral of
| popularity. C was the incumbent. PHP was easy to install and
| solved a problem that most developers had: write a web app
| quickly. Java and the Visual languages were backed by big
| companies. Oberon was not. It was a curiosity at best. I
| remember other languages from back then: Eiffel and Modula 3.
| They resurface sometimes in HN posts.
| troupo wrote:
| The graphical interface is the least of its problems.
| Qem wrote:
| How does FreeOberon compare to FreePascal, in terms of standard
| library and third party libraries available? Is it a practical
| development environment, in the sense of not needing to reinvent
| every wheel to use it?
| anta40 wrote:
| https://free.oberon.org/docs/en/
|
| On a glance it looks pretty limited, I see no way to access OS
| API, no networking, etc (more or less like Turbo Pascal).
|
| Perhaps sufficient as educational tool.
| hnlmorg wrote:
| Syscalls were the OS APIs back in the Turbo Pascal days. DOS
| didn't have an SDK like we now expect. But people still
| pulled off some pretty sophisticated stuff in Pascal
| (personally, I wrote a DOS GUI frontend (like pre-Win 3.x) in
| Turbo Pascal)
| anta40 wrote:
| Ah, I still remember those DOS interrupts :)
|
| And of course, modern Pascal compiler like FPC provides OS
| specific units to do that.
| benj111 wrote:
| int 0x80 was/is the x86_32 way of doing syscalls in linux.
|
| im not sure if sysenter, used on 64bit systems is classed
| as an interrupt.
|
| the sdk is just a layer on top of that.
|
| ive never used c on dos, it woukdnt surprise me if they
| used a similar library to linux. theres certainly nothing
| preventing it.
| BaculumMeumEst wrote:
| This project is cool as hell. I really appreciate that it has
| very straightforward instructions and takes no time to get up and
| running, it's just a git clone and an install command.
|
| The only quirk I ran into is that when I ran graphical programs,
| I would get a full-screen window with a blank prompt; I needed to
| move that window to another workspace in order for the running
| program to be displayed. The IDE seems to get smushed into the
| bottom corner of the screen in KDE and gnome for some reason
| (which I could work around by toggling windowed mode with
| alt+enter and then dragging the window to resize), but it works
| fine in i3.
|
| Between discovering this and finally getting around to trying the
| Factor language, I'm afraid I'm going to be very unproductive on
| my side projects for a while..
| benj111 wrote:
| >I'm afraid I'm going to be very unproductive on my side
| projects for a while
|
| I infer that your main project is discovering things that may
| one day help you be more productive in your side projects.
|
| It could be worse. Ben Eater was just trying to get his web
| browser working like he wanted...
| anta40 wrote:
| Quick look at
| https://github.com/kekcleader/FreeOberon/blob/main/src/make....:
|
| It uses ofront (Oberon-2 to C translator), and let GCC do the
| heavylifting. Let's check if this thing can be easily built on
| macOS...
| andai wrote:
| See also: Oberon+: https://news.ycombinator.com/item?id=35209102
|
| Code Examples: https://oberon-lang.github.io/
|
| Context: https://github.com/rochus-keller/Oberon
| zozbot234 wrote:
| The TUI IDE is kinda interesting, looks a lot like QuickBasic,
| Turbo C and other old-style DOS apps. But otherwise, it would be
| a lot more sensible these days to just code an Oberon-specific
| language server, that you could use with any IDE.
| bitwize wrote:
| Oberon is much more a language/library/IDE/operating system,
| like a Pascal-flavored Lisp machine. This is a bit like saying
| "Emacs Lisp is great but what I really want is a language
| server for it so I can write it in VS Code."
| zozbot234 wrote:
| This project just uses a C transpiler and creates plain
| binaries, though. It's not running under any sort of bespoke
| environment.
| minroot wrote:
| Too much at 4:20 AM
___________________________________________________________________
(page generated 2023-11-12 23:00 UTC)