Hacker News Reader

Comment by skybrian | Hacker News Reader

The part I'm most skeptical of is Eve's universal use of set-based semantics, whether it's needed or not. It seems like making sets and single values look different in the code would be more understandable than making everything look the same. Treating them as different types might be a good way to catch errors, too.

But SQL is very successful so maybe they'll do okay anyway.

View on HN

My startup Velox.io (https://velox.io, which is looking to go live in the next couple of months) is working on the same issue. Right now writing code is overly verbose (and often brittle). The author does make some good points around unifying API, Database and Application code. Most code is centred about moving data from A-B, with some logic applied to it.

Eve done some interesting stuff, as has Linq from .net, AWS's Lambda's, even Kx's Q in the way it handles temporal data.

My hypothesis that writing software can be greatly improved; There is a lack of programmers, yet most people are capable of creating spreadsheets (and writing formulas). Using spreadsheet is similar to programming, what makes programming much more complex is the different systems involved and lack of rapid feedback.

People have been trying to make programming easier/ accessible since the days of Hypercard, but no one has really cracked yet.

Edit: Downvote if you will (I've spent years on this), at least write a comment to say why.

> People have been trying to make programming easier/ accessible since the days of Hypercard, but no one has really cracked yet.

There is no shortage of good programming languages and useful paradigms. The problem is how to interface with existing systems written in a different language with a very different mindset (e.g. your operating system). Someone has to write code to bridge those abstractions, and that only happens if enough resources are concentrated at the right place.

> yet most people are capable of creating spreadsheets (and writing formulas)

Not in my experience.

Is that true though? To me, the difference between a simple spreadsheet and say, a floppy bird, is that the spreadsheet requires one to know about rows and columns, and basic math (sum, average). It's a pretty simple abstraction that matches, say, a sheet of paper with a list scribbled on it.

Whereas, say, flappy bird, requires you to think about a lot of other abstractions one is less familiar with, and juggle those. User input, graphics. I think it's the complexity of abstraction and the difficulty of reasoning about it and juggling all the bits in your head, that makes it hard. I think that's a skill you really have to have or learn. Just because some people van add two cells doesn't mean they can easily create their own abstractions f.ex

You can kinda roll your own "single value type":

  search
    a = [#singleton]  
    b = [#singleton]  
    a != b

  commit @error
    [#error #description: "Multiple values for singleton!"]

I'm sure that's not the actual pattern you'll be using. My point is only that Eve provides a solid low-level foundation to implement higher-level patterns like a single-value type.

"My point is only that Eve provides a solid low-level foundation to implement higher-level patterns like a single-value type."

That's the problem. As long as single-value type is a higher level abstraction you are going in the opposite direction from "programming for everyone".

I don't see the problem with having a beginner-oriented interface rest on an extra abstraction layer.

Eve : Markdown :: Eve-based tools for everyone : a WYSIWYG editor

This is actually the most elegant aspect of Eve.

You're always working with an abstract/fuzzy value that represents all possible values given some constraints, and only have to resolve a concrete instance when you absolutely need to. More often than not, were working with ordered sets, not single elements.

Yes. I'm with the idea of a relational language, and I "discover" the same idea. In most languages,the scalar is the default and the collection is the special case. However, more often than not, you want to operate in collections than scalar.

So, I have find that this kind of code make sense:

    for i in 1:
        print i

This help to generalize a lot of things.

Reply on news.ycombinator.com