Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Orthogonal Persistence

github.com

Post reply on HN
Print view View original

31–38 of 38 posts

Re: Orthogonal Persistence

#31

Post by jinjin2 »

aeontech wrote: post #26
geophile wrote: post #18

That phrase certainly brings back memories, from when I worked at an object-oriented database startup. The object-orientation was actually pretty unimportant, (except for those products that brought in persistence via inheritance -- so not really orthogonal). No, the point was adding a new storage class to programming languages. I worked at Object Design, and we had (IMHO) an incredibly elegant approach. In our appro…

That sounds fascinating! Does anything like this exist now in the open source world?

The closest I know of is Realm, which is an amazing object database and seems to do a lot of what the op describes. But after the acquisition by MongoDB they seem to have drifted a bit more in a document database direction.

Re: Orthogonal Persistence

#32

Post by mpweiher »

jdougan wrote: post #28
geophile wrote: post #18

That phrase certainly brings back memories, from when I worked at an object-oriented database startup. The object-orientation was actually pretty unimportant, (except for those products that brought in persistence via inheritance -- so not really orthogonal). No, the point was adding a new storage class to programming languages. I worked at Object Design, and we had (IMHO) an incredibly elegant approach. In our appro…

How would you compare it to Gemstone/S? I spent a large chunk of the 90s working on a maintenance management system witha GS back end.

Can you describe your experience working with that GS backend?

Re: Orthogonal Persistence

#34

Post by pilgrim0 »

It seems like the Tuple Space [1] model for distributed computing, put forth by Linda, lends itself perfectly for this use case. I very much appreciate the ratio of simplicity to power offered by tuple spaces. At it’s original form maybe it’s too simple, but there are many ways it can be improved upon and brought into modernity.

[1] https://en.m.wikipedia.org/wiki/Tuple_space

Re: Orthogonal Persistence

#36

Post by jdougan »

mpweiher wrote: post #32
jdougan wrote: post #28

Earlier quoted context omitted.

How would you compare it to Gemstone/S? I spent a large chunk of the 90s working on a maintenance management system witha GS back end.

Can you describe your experience working with that GS backend?

What is is you want to know?

Re: Orthogonal Persistence

#37

Post by geophile »

jdougan wrote: post #28
geophile wrote: post #18

That phrase certainly brings back memories, from when I worked at an object-oriented database startup. The object-orientation was actually pretty unimportant, (except for those products that brought in persistence via inheritance -- so not really orthogonal). No, the point was adding a new storage class to programming languages. I worked at Object Design, and we had (IMHO) an incredibly elegant approach. In our appro…

How would you compare it to Gemstone/S? I spent a large chunk of the 90s working on a maintenance management system witha GS back end.

I could have answered that question as much as 20 years ago. It’s been a while …

Re: Orthogonal Persistence

#38

Post by jerf »

dTal wrote: post #24
jerf wrote: post #17

Earlier quoted context omitted.

Or, to put it another like, like visual programming, like "programming languages should be able to wear syntaxes like themes", like "there ought to be some sort of nocode type solution with all the power of conventional programming but easy enough for anyone to pick up", there are reasons why this is not how all programming works already. Good ones and big ones. And none of those reasons are that nobody has had the i…

Offtopic perhaps, but I am interested in reading an explanation of the good, big reasons why not "programming languages should be able to wear syntaxes like themes". Racket seems quite an interesting counterpoint, and I've never heard it argued as fundamentally flawed.

The people who think syntax should be worn like themes do not realize how deeply syntax interacts with a language. It isn't a skin.

Your homework, should you choose to do it, because of course I can't make you and don't really care :), is to write a "Haskell theme" for Python. The theme must retain *args and **kwargs capabilities, as well as all other Python capabilities, though those two things will be one of the first major issues you hit. On the flip side, write a Python theme for Haskell. (This one based on my own stabs at it doesn't have such problems with the capabilities of the language, but it sure does take all of Haskell's elegance and wrap it in the grace of an elephant with a sprained leg.)

Also, bear in mind my claim is not that it can't be done. My claim is more like, nobody would want to use the resulting language with the resulting "skin". Languages are not all the same. Even dynamic versus static imperative languages don't really "skin" very well; compare idiomatic Ruby ActiveRecord-based code with Rust code. The differences are not just skin-deep.

Post reply on HN