Hacker News new | past | comments | ask | show | jobs | submit login

Very much agree. Programming notation, like math, is supposed to be easy to convey exact meaning, unlike human language.

Every attempt there has been to make code look like English hasn't worked out well. SQL, for example, is incredibly verbose, with complex syntax. This obscures what is otherwise very good semantics. I think this is why a lot of people hate writing queries.




I rather think Math is a good counter example. Or physics rather. There aren’t enough greek letters in the alphabet to satisfy the average academic paper. You first have to load in your memory the meaning of 20 different symbols then decypher a formula before you can process it.

Now people who read lots of papers are probably used to this exercise but that doesn’t mean it’s a good thing (you can get used to running on one leg, but that doesn’t mean there aren’t better ways to run!). I am of the opinion that initials, or full words should be used in formula.


Those who are not used to the terminology of physics or math would not be able to follow a paper no matter whether it was stuffed with the Greek alphabet or nice descriptive names. They'd be baffled by the formulae and concepts and lack the understanding needed to see the trees through the forest even if it were written like prose, maybe even more so as a formula at least gives some idea of what goes in and what comes out, what belongs together and in what order things are to be seen by virtue of some easily understandable symbols. While it is a fact that some people - often those who lack self-confidence - revel in being obtuse to increase the appearance of them being the guardians of some semi-magical 'Knowledge' this is not the reason why STEM-fields tend to gravitate to their own 'secret languages'. This starts in school where children learn that 1 + 1 = 2 instead of take the abstract number one, add another abstract number one and you now have the abstract number two.


All those symbols are necessary for readable math though. For millenia people did math as you describe, and it worked very poorly compared to modern math notation.

For example, how would you write something like a tensor H_i^{kl} (pretend those are rendered sub and superscripts)?

Looking at that symbol, I immediately understand that H is a tensor with one lower index and two upper. Now, it precise words, it would probably be something like:

"Let H be a tensor with lower index i and upper indices kl."

Oh wait, we've already had to define all the variables anyway (since we don't want to specialize it to an individual tensor, because that would be useless). Why not just use a bit more notation and write it as H_i^{kl}?

If we ran out of letters, we'd have to use Greek ones. Now we are back to where we started.


And yet after 30+ years no one had adequately managed to replace it. God help us if it's one of those json based abominations. My main complaint with sql is that it can be somewhat difficult top make DRY.


CTEs can go a long way toward that, as can stored procs


LATERAL joins can help with reusing calculations https://www.periscopedata.com/blog/reuse-calculations-in-the...


Wow that's a bad example. Any decent query engine (which I'm assuming Postgres has) would reuse common subexpressions.


Even if duplicate expressions are optimized by the engine, they hurt the readability and maintainability of the query, especially if they are big and complex.


As can views.


> SQL, for example, is incredibly verbose, with complex syntax. This obscures what is otherwise very good semantics.

I disagree; I think SQL syntax is one of the things that make it very clear and easy to use; it's got a couple of warts, especially related to automated tooling (the biggest being fixed order of clauses with SELECT before FROM), but it's exceptionally well fit for it's purpose.

> I think this is why a lot of people hate writing queries.

I've known more people comfortable with SQL and thrown by typical programming languages than the reverse.


>I've known more people comfortable with SQL and thrown by typical programming languages than the reverse.

Non-programmers often find SQL queries easier, and simple SQL queries are intuitive. Programmers, who are likely to do more complicated ones, usually don't like it. At least in my experience.

The issue is that it is hard to quickly visually parse complicated queries, like big CTEs. Having it in a less English-like notation would go a long way to fix this.


I'm a programmer who has had to do plenty of complicated SQL queries; the difficulty I've had with those has been about 10% quirks in the design of SQL, and 90% bad database design that I'm not in a position to fix.


Well, even if you had a good database design, you'd only then be able to argue that a greater portion of the problem is SQL.


Personally, I much prefer writing queries in plain SQL than using an ORM unless it’s for trivial things.


SQL is like the only language I like. It's so easy and unambiguous. What I read is what happens.

Whenever I work on a -nix box I grit my teeth with frustration at how OLD and UNFRIENDLY it feels. I'm shocked that people can still accept any of these archaic texts, whether is be for elitism/gatekeeping ("you aren't really into computers, otherwise you'd get it"), or for tradition ("it's the way it's always been, why bother changing what I know, despiteot being an inconvenience for everyone else who isn't in our group").

Why not just write your language to have three or four syntaxes (as a suggestion: compressed, C-style, shorthand, and verbose, with plugins for adding new syntaxes or spoken languages, dual screen for pair programming accessibility) and with the press of a button be able to swap between them? This way anyone can read your code in whichever way they please.

Maximize accessibility to all. It's not that hard.


>Every attempt there has been to make code look like English hasn't worked out well

Not true. Ruby is incredibly readable


I'm not a Ruby programmer but have over the course of my career had numerous occasions where I had to look at "incredibly readable" Ruby code.

No, no it isn't. Sure, you can infer some meaning in the various "DSLs" without knowing any Ruby but you're left facing exactly the problems of ambiguity the GP pointed out.

You know what the words mean because they're just English words but you don't know their exact definitions in that specific context. And even if two "DSLs" use some of the same vocabulary that doesn't mean the words will mean exactly the same thing.

It's just hiding the arbitrary implementation behind a very ambiguous API that might read as two completely different things to two different readers. Let alone trying to manipulate the program (at which point you realise that even though it's supposedly a "DSL for laypeople" you still need to understand Ruby idiosyncrasies to be able to work with it).

Ruby is not incredibly readable. Ruby is however capable of letting you create APIs that make code look a lot like plain English language. That doesn't mean the code "reads" like plain English language because unlike plain English language it's just a bunch of whimsical function and variable names with arbitrary implementations.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: