Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

> This is how I solved the third problem, by the way: [insert unreadable scribbles of a madman]

when will array enthusiasts understand that having first letter A does not mean the language should be aimed at Aliens?

get over your "code golf" tendencies and start thinking about *readability* - give us long names, give us brackets, give us ASCII and stop pulling everything into a single line in examples - _THEN_ you'll have your first tiny chance of being heard and taken seriously

aim design at common people, not gurus



> when will array enthusiasts understand that having first letter A does not mean the language should be aimed at Aliens? […] get over your "code golf" tendencies

I've always assumed that people working on these languages come from a heavy maths background, so to them the sequence of symbols is more “naturally” readable. So saying “if array language people used words I'd understand better” is not unlike saying “if the Chinese would only speak English there would be less language barriers”. Not wrong, of course, but perhaps not a reasonable expectation.


English is the langua franca of programming. If you want your solution accepted, you have to meet your audience where they are.

In similar fashion, when engines were first invented and were being sold to miners, they didn't expect miners to understand the scientific terms around energy, they invented a term that could be easily understood: horsepower. Every miner could wrap their head around the work that twenty horses could do.

Here, x̄ or μ may mean average, but how do you pronounce either? Most are unfamiliar. Identifiers "avg()" or "average()" are more approachable, and already in use in spreadsheets for similar reasons.


> English is the langua franca of programming.

I am not an English native speaker, but learned programming before even starting with learning English. In my head, the English keywords used in programming languages are thus just abstract (mathematical) symbols that are incidentally also English words.

As part of my work, I also work with Russian programmers, who, as long as they lived in Russia, hardly ever had to understand anything in English as part of their programming job ("Russia is so big that it is not necessary to learn English"). Just to be clear: they nevertheless attempted to learn English while living in Russia, but because of of intellectual interest, and not because it was necessary or helpful for their programming jobs. I heard rumors that a similar stance holds for China.

Thus: English may be the lingua franca of programming in North America and some European countries, but clearly not worldwide.


> Thus: English may be the lingua franca of programming in North America and some European countries, but clearly not worldwide.

So, you don't have "for" or "while" loops where you live? Not even a "main" function?


Relevant part of the comment

> the English keywords used in programming languages are thus just abstract (mathematical) symbols that are incidentally also English words

Explanation: People learn python without understanding meaning of keywords used. One must understand what ‘for’ means in python (i.e. repeated execution), but there is absolutly no necessity to understand what it means in English ( https://www.merriam-webster.com/dictionary/for )


Sorry, but mathematics notation is not THAT cryptic. Yes, it prefer single-letter variables, but there are not a lot of special notation.

Summation (Capital Sigma), Multiplication (Capital Pi), integration, roots. Limit? "lim". Logarithm? "log", etc.

It is not like 50 glyphs of array languages. It is maybe 5 glyphs and 10 other conventions (like division over-under, root and power). Also, mathematics notation is 2D and multi-size (capital sigma is much larger than variable names and numbers, summation indices on under and over sigmas is much smaller) which helps immensely. Same formula written in one font in one line will be much less comprehensible.

UPDATE: Yes, I forogot about E-inverted (exists) and A-inverted (for all), and two or three common operators related to sets (includes, subset), but they are not needed for calculations even in math, only for theorems. And array languages are not theorem proofers.

Each area of math could have its own special notations too, but I don't expect that category theory specialist will understand notation of very specialized complex functions paper.


When I say “from a heavy maths background” I mean more than arithmetic, basic algebra, calculus and such. Set theory has quite a dictionary of symbols & conventions and I assume a lot of the array language terminology/symbols comes from there, complexity theory has some of its own too, and so forth. Take a look at some substantive mathematical proofs in various areas and tell me there are only 15 glyphs/conventions that are commonly used!

> Sorry, but mathematics notation is not THAT cryptic.

It can certainly be that information dense. Whether that is considered cryptic or not is in the eye of the beholder.

> It is maybe 5 glyphs and 10 other conventions

Heck, we've got more than 5 glyphs just for expressing (in)equality: =, ≡, <, >, ≤, ≥, ≠, ≢, ≈ (and those are just from memory of doing maths to A-level nearly three decades ago, a couple of years of CompSci after that, & programming since, and that isn't touching on symbol sets from subsets of mathematics like set theory).

> Each area of math could have its own special notations too, but I don't expect that category theory specialist will understand notation of very specialized complex functions paper.

While each area will have specialist notation that is not commonly understood by those unfamiliar with the area, most maths people will understand a chunk of the notation from a number of areas. I don't consider myself a maths person and I know the basic glyphs from a couple of areas when I see them.


If the language looked more like type set mathematical notation it would be much more approachable.


> { ⊃ ⍵ ⊇⍨ ↑⍒≢¨ ⍵ /⍨ 2≥ (⊂"aeiou") (+/∊⍨)¨ ⍵ } io:read "dict.txt"

> At this point, comments suggesting the code is “unreadable” are bound to be thrown around, but once you learn a handful of symbols, this is in fact significantly more readable than the kinds of formulas I see on a regular basis in Excel.

To your point: what would this look like using English words as identifiers rather than unicode soup whose names I have likely never heard of? It isn't like those characters are easy to find on my keyboard.


> It isn't like those characters are easy to find on my keyboard.

Don't let your dreams be dreams (I actually have one): https://www.pckeyboard.com/page/product/00UA41P4A


The solution is obvious: better keyboards


The glyphs are not a barrier to use or learning. Learning them is no more difficult than learning the keywords and syntax of any other language. The real difficulty lies in thinking in terms of arrays and array operations rather than conditionals and loops.


>The glyphs are not a barrier to use or learning.

perhaps not to you but perhaps they are for a large number of people who are used to seeing words they recognize, surely being able to read a simple program before you have learned and guess what it means will be a great comfort to people and make them feel that yes, they can learn this.

A bunch of incomprehensible glyphs might interest someone like a puzzle solving challenge, but not everyone will want to solve a puzzle in order to first start to learn a language.


> perhaps not to you but perhaps they are for a large number of people who are used to seeing words they recognize, surely being able to read a simple program before you have learned and guess what it means will be a great comfort to people and make them feel that yes, they can learn this.

This argument was already used in the past to justify the very verbose syntax of COBOL.


Cobol's argument was that it was easy to learn.

My argument was that a language that looked comprehensible might invite learning, which is not exactly the same thing.


COBOL was infinitely more successful and adopted than any of these languages so...


> This argument was already used in the past to justify the very verbose syntax of COBOL.

Looks like we found Goldilocks zone of programming languages in years after first version of COBOL.

BASIC is too little, COBOL is too much.

Array languages is less than BASIC.

And it is Perl which is humiliated for line noise all these years!


> Looks like we found Goldilocks zone of programming languages in years after first version of COBOL.

Considering the current state the Goldilocks zone of programming languages is like calling the verbose style in which mathematical proofs were written down in the early modern period the Goldilocks zone of writing down mathematical proofs. :-(


Also, mathematicians are much more well- and long-trained than typical programmer.

And it is good in both ways: some times ago there was idea that everybody should learn a little of programming (see, for example, BBC program in UK which brings us BBC Micro and, later ARM processor ;-) ), because now almost everything is computer (including my wahsing mashine). Now, it is not popular idea, now all corporations try to build non-programmable walled gardens, but it was not so always.

COBOL (and SQL) were created with managers, not programmers, in mind. Goal was to allow managers automate their business-processes without calling for IT consultant.

Spreadsheets are VERY near to this goal. I've seen A LOT of business and finance automation made in excel by people, who will punch you in the face, if you say them that now they are programmers.

If we want to have very specialized, PhD-requiring languages, it is perfectly Ok. But then don't try to sell them to Spreadsheet users.


> But then don't try to sell them to Spreadsheet users.

The problem rather is that "fetching people where they are" regarding the programming language design means keeping these people stupid. Instead, you should market the programming language to spreadsheet users by explaining them how the new kind of thinking that the programming language enables lets their intellectual potential explode.


Problem is, many people (including many power Excel users) don't want to "lets their intellectual potential explode". Job is trading time for money. Not something for rising self-esteem or even something interesting. You could try to play "you will do more in less time" card, but it is often not true (unfortunately), and in corporate world person who do more in less time get more tasks and not the rise.

My experience shows, that programmers love their job and want to be better for sake of being better much more often, than other employees (and it is considering norm - like "show your github profile" on hiring, do you know cases when auto mechanic is required to show custom-build car to get job in the shop?). And even among programmers it is not universal rule, I know some colleagues (very competent ones, need to say) for whom it is simple job, not passion. They don't read bleeding-edge papers on CS, they don't have pet projects and, even, may not own computer at home - PlayStation/XBox and smartphone is enough for them, because computers are tool of trade, not home necessity.


Programs are not mathematical proofs, and when they are (in systems like Coq) they, maybe, will be better with mathematical notation.

Also, all these comparisons with mathematical notation left out that mathematical notation is not linear and one-font-size-fit-all, as our programs, even in array languages.


I don't see how I can easily input those glyphs. Selecting them by clicking on a symbol, as it seems is an option in one screenshot, is really out of the question. That's just clumsy. Special key combinations is also something I really dislike. It's too slow. I disable dead-keys, for example, I much prefer to be able to enter e.g. '~' directly, instead of dead-keying it (as is that "standard", apparently, for my national layout). For me it's much faster and easier to enter a string, a keyword, instead of moving my hands, or, shudder, mouse, in strange ways to insert some symbol. I don't need symbols, I need names and words, those I can enter as fast as I can think.


> The glyphs are not a barrier to use or learning. Learning them is no more difficult than learning the keywords and syntax of any other language.

Of course they are! I can't type them in on my keyboard without doing a google search first.

It's a barrier according to all definitions of the word. It's unnecessary friction. It's slower to type in when learning. It's slower to read when learning.

Compare it to a language that isn't bragging about how smart you are if you know it - all those barriers are removed.


In most editors you can type ``fn_name to insert the symbol, and move on to `s single letter shortcuts when you start using the functions enough. If you need to read, just hover over the symbol and it will give you its name; even without that, the surface level is small enough that you can get acquainted with 90% of them in a week with regular use, compared to "more accessible" languages and all their hidden gotchas


"compared to "more accessible" languages and all their hidden gotchas"

----

Yes because APL or array languages in general have absolutely no hidden gotchas ...


You know what’s even simpler? Just using “fn_name” directly in the program.


> I can't type them in on my keyboard without...

You mean like how you've got to find out how to type accented characters - á or ö for example?

The glyphs are available as a keyboard layer which you can easily find and install, or simply enable on Linux.

Yes there is an initial hurdle when you're learning, but the same applies with +-×÷, and any languague with a different alphabet/symbol set! Once learnt however, the ~50 odd symbols are all the primitive functions, and then have speed and ability like maths to write and play with expressions.


> Yes there is an initial hurdle when you're learning, but the same applies with +-×÷, and any languague with a different alphabet/symbol set!

Thee difference is, with any other new programming language I already know those! IOW, it's not a barrier.

> Once learnt however, the ~50 odd symbols are all the primitive functions, and then have speed and ability like maths to write and play with expressions.

50? You'll forget them if you don't use them. Still a barrier, even when not learning anymore.

Look, I get that there's a speed upgrade, but it's a balance, and 50 is way too much for something that you'll forget easily due to lack of usage.

For example, why bother with 26 elements that compose to all the words in the English language? One can simply memorise the most frequent 30000 words and assign a different rune to each one.

Obviously, we don't do that. The languages that do do that get outcompeted by the ones that don't.

The simple reality is that languages, both human and programming, have to match what the average human is most productive in. It doesn't matter that genius developers are more productive with esoteric runes; their experience is irrelevant because they aren't doing the grunt work that 99.9999% of programming entails.


People who need to type those characters often have localized keyboards where this is obvious. In addition, those are not special characters but compositions of characters, so adding them to a keyboard is relatively inexpensive in terms of key cost.


Yes, exactly like that.

I don’t want any characters in my computer program I don’t see on my keyboard.


As it's much easier to start learning a language that uses a familiar alphabet, simply not being able to easily represent basic characters in your head is a huge barrier to overcome.


> simply not being able to easily represent basic characters in your head is a huge barrier to overcome.

In the modern technical world, you are basically surrounded by mathematics; thus a lot of people (in particular nearly all programmers) have already seen many such symbols.


Doesn't matter. If it is pitched as an alternative to spreadsheets being that much less straightforward is a big downside. And downsides will be used by actual people to weigh their decisions.

Why not make it straightforward first and then when people understand it, introduce the shortcuts? Not nerdy enough?

Sometimes I have the feeling that a certain type of peogrammer doesn't even want others to understand what's going on, what they want is bending them to their own will and conventions.


Ergonomics matter regardless of the paradigm.


> The real difficulty lies in thinking in terms of arrays and array operations rather than conditionals and loops.

This is just a restricted form of functional and high order programming. It's slightly unusual but many people feel comfortable with it.


Also, I could say from my own experience, that studying Vietnamese is much-much-much simpler (in the beginning at least) than Chinese.

Chinese, theoretically, is more simple language than Vietnamese in terms of grammar structures and such. But Vietnamese uses Latin alphabet (augmented with diacritics) and for western person it is huge help when you start to learn language. Maybe, on B2+ level it is not relevant anymore, but when you try to study language from zero it is blessing (again, for western person).


That’s just true. Keywords like “for”, “while”, “if”, “then”, “else” are helpful mnemonics for English speakers. And they are well known by non-English speaking programmers already.

So the only audience where this is not true, is non-English speakers who want to learn an array language as their first programming language.


See recent discussion about (irrelevancy) of literate programming in modern world, where we have good readable identifiers in our code instead of single-letter variables of BASIC and control structures instead of GOTO hell.

IMHO, it is relevant to discussion about array languages.


the glyphs (and the fact they do different things depending on the arguments) do make them very ungooglable.


What are you talking about? I don't even know how to _make_ most of those symbols this isn't true of any of the dozens of programming languages I've used in various capacities. The people disagreeing with the original comment are so deeply inside a bubble i'm worried about them


An obvious compromise is to have a dual representation, one terse and one that’s spelled out. You could then toggle between them when seeing unfamiliar symbols.

The fact that nobody selling me on these arcane runes talks about something like that tells me it’s more about code golf for them.


I don't want to do the same things for boolean operations, or arithmetic, or pointer (de-)referencing in C like languages. Why would I want to do so when equally familiar with a larger range of symbolic operations?

Somehow the usual culprits of +-/*|^&% get a free pass on this, and are somehow less arcane than symbols like ⍋ or ⊃.

There's nothing inherent about this, it's about familiarity, and once familiar, everyone always prefers the symbols over spelling it out like plus, minus, divide, multiply...


It’s funny because lisp enthusiasts will say “yes, lisp is harder to learn with all the parentheses, but trust me, it’s worth it” And then list some actual benefits.

Whereas APL fans will insist it’s not hard while listing no benefits besides dense code.


well yeah, dense code is the whole argument. It means you don't have to know any library, because it's so dense you can just write the whole thing from basic elements. You never have to look up anything!*

* except for the fact you're supposed to remember the idioms for everything : https://aplwiki.com/wiki/FinnAPL_idiom_library


The usual culprits show up on standard keyboards. That’s a huge advantage.


The lack of familiarity was exactly my point? If you make a new language with a + symbol but spelled out the other functions, newcomers would understand it immediately. If you have whatever that Christmas tree symbol is, newcomers will be continuously looking up what they mean. You are making the language harder to learn for the sake of code golf.

And if you had a toggle-able mode, you could still have your code golf.


For what is worth, you can use the keywords 'and', 'or', 'xor' etc. in C an C++ like you can in python. I for one greatly prefer them.


Personally, I do not find that long names, brackets and general verbosity helps _me_ with "readability". The less concise it looks the less likely I am to read it. And if there is too much to read, I will definitely not read it. Just because someone has entertained themselves by writing lots of verbose code does not mean I want to read it. Skimming it and searching through numerous directories of source code files is not the same thing as actually reading each file from beginning to end.

As it happens, I find terse languages, and "code golf", as more approachable and thus readbale. It is lower volume, more concise and compact. Generally, I can read all of it. I use an ASCII-based array language that uses brackets: https://en.wikipedia.org/wiki/K_(programming_language)

I am not sure why I prefer writing less code as opposed to writing more code. Maybe I just dislike typing. In any case, I am thankful these languages exist. For both reading and writing.

To insinuate that no one takes array languages seriously would of course be wrong, as one can see from the above Wikipedia page.

The question I have is why anyone who prefers popular verbose languages would care about the discussion of unpopular array languages on HN. Why even bother to comment and complain. If array languages are incomprehensible and unpopular, then why pay any attention to them. Appeals for verbosity over terseness do not seem to be working for the vast majority of Javascript I see in webpages from the larger so-called "tech" companies running the most popular websites.

Array languages are very easy to avoid. Imagine trying to avoid Python. Not easy (speaking from experience).

Telling array language authors to make their languages more verbose is like telling Bob Dylan to play what people want to hear and only then will he have a "tiny chance of being heard and taken seriously".

(Also wondering if commenter meant braces not brackets.)


> Personally, I do not find that long names, brackets and general verbosity helps _me_ with "readability".

Thank you, 1vuio0pswjnm7


> Personally, I do not find that long names, brackets and general verbosity helps _me_ with "readability". The less concise it looks the less likely I am to read it. And if there is too much to read, I will definitely not read it.

in some sense it is a "thesaurus vs ancient egyptian" argument

I can totally understand that it would be infinitely nicer to build Stargate and go fight Goa'uld or inherit knowldge of the galaxy-spanning Asgard - but it's the events of "Yes, Minister" that actually do happen in our, real, world

> As it happens, I find terse languages, and "code golf", as more approachable and thus readbale. It is lower volume, more concise and compact. Generally, I can read all of it. I use an ASCII-based array language that uses brackets: https://en.wikipedia.org/wiki/K_(programming_language)

"A case of MUMPS" (https://thedailywtf.com/articles/A_Case_of_the_MUMPS) is on The Daily WTF. "WTF" is exactly the default behaviour of people encountering these codegolf-ed langs

> The question I have is why anyone who prefers popular verbose languages would care about the discussion of unpopular array languages on HN. Why even bother to comment and complain.

you're the seller, I'm the buyer

array enthusiasts advertise their product, listing advantages - we reply with "my problems with it are this, this and this. How can you fix it?". Yes I'm interested. No, I don't agree that my concerns are empty.

> (Also wondering if commenter meant braces not brackets.)

technically, I meant parenthesis. But nowadays, and especially in programming world, all 3 are synonyms and you just add [curly/round/square] in front

brackets are just easiest of the 3 for me to recall


Dylan did play what many people wanted to hear. He was an incredibly successful and popular artist.


Bob Dylan played what people wanted to hear. True or false.

https://pitchfork.com/thepitch/855-dylan-goes-electric-newpo...

"In 1965 Dylan was only 24 years old, but he had already gone through a lot of changes and been criticized and attacked for each of them. His first performances as a teenage rock'n'roller were met with laughter and jeers. When he turned to folk music, the high school girlfriend who had shared his early passions was troubled, asking why he'd given up "the hard blues stuff." When he turned from singing traditional folk songs to writing his own material, old supporters accused him of becoming "melodramatic and maudlin"-one, stumbling across a typescript of "The Times They Are a-Changin", demanded, "What is this shit?" When he turned from sharp topical lyrics to introspective poetic explorations, followers who had hailed him as the voice of a generation lamented that he was abandoning his true path and "wasting our precious time." When he added an electric band, he was booed around the world by anguished devotees, one famously shouting "Judas!""

https://www.mojo4music.com/articles/stories/robbie-robertson...

"We got booed all over North America, Australia, Europe, and people were saying this isn't working and we kept on and Bob didn't budge. We got to a place where we would listen to these tapes and say, "You know what? They're wrong. And we're right." Eight years later, we do a tour, the [1974] Dylan/Band tour, we play the same way, same intensity and everybody says, "Wow, that was amazing." The world came around - we didn't change a note.

The obvious thing we learned - that everybody learned - was there was a new way of songwriting. There was a much more colourful, descriptive, humorous, outrageous thrill ride of wordplay. We hadn't seen this before - this was breaking some big rules. I remember saying to Bob one time, "Maybe there's too many verses in this" (laughs), and he said, "There probably are, but that's what I was thinking about when I wrote it." His spirit was on fire, and he was knocking down the boundaries that had been built up around music. It excited me to be part of this revolution."

https://www.nytimes.com/1998/10/11/arts/music-when-dylan-s-g...

"BUT Dylan was too smart and too stubborn to let hidebound listeners prevent him from making the best music of his career.

The hecklers were wrong about the music, as most of them would probably admit now."

https://ultimateclassicrock.com/bob-dylan-goes-electric-newp...

"The New York Times' Robert Shelton, whose 1961 review of a Dylan concert is considered to have launched Dylan's career, wrote, "The young audience's displeasure was manifested at the end of most of the numbers, by booing and shouts of `we want the old Dylan.' The young star plowed valiantly on, with the sort of coolness he has rarely displayed on stage."

Calling the crowd "rude," "immature" and "noisy young boors," [Dylan] couldn't help note the positive reaction given to "Like a Rolling Stone," which by now was a hit. "Evidently the hostility extends only toward things with which they aren't familiar," he sneered.

[Hostility toward things with which they arent't familiar. Like HN commenters' hostility toward array languages.]

This song-and-dance with his audience continued over the course of the next year."

http://www.goldminemag.com:80/article/bob-dylan-gets-religio...

"The show opened with as excitedly noisy a crowd as Dylan had ever faced, 2,300 souls jammed in, and all with their own loudly exclaimed wish list of favorite Dylan songs and expectations. Fourteen years earlier, you could imagine the 1965 Newport Folk Festival buzzing with similar anticipation and excitement ... and reacting with similar bemusement as the show took shape. Only it was not the sacrilegious explosion of electricity that left the audience reeling in its seats.

As he led the band through a 19-song set, Dylan did not play a single song that predated his religious conversion. Even the encore was uncharted territory. "Blessed Is The Name Of The Lord" and "Pressing On" were both new songs, and though the former rocked and the latter soothed, the crowd was in no mood to be impressed.

Afterwards, Dylan congratulated himself on not playing a single song he'd ever performed onstage in the past, and when the subject of his fans' expectations was broached, he simply shrugged. "Oh, yeah, that's right. They want the old stuff."

Pittsburgh's KDKA TV station even filmed the fans' exodus, with one disgruntled ticket-holder snapping to the cameraman, "He stinks. He's the worst. He's bad. It's a waste."

Dylan's audience was furious. Shocked. Cheated. It was Newport all over again, or maybe the Manchester Free Trade Hall, later on in that so-controversial 1965 tour, when the bootlegger's tape was suddenly interrupted by a bellow of "Judas!""


This is what I love in Uiua[1]. That operators can be written as english words instead of unicode symbols. Makes it quite similar looking to functuinal point free code.

[1]: https://www.uiua.org/


even if Uiua has english words - it does not show them on the frontpage (instead presenting virtual keyboard of its own, differently shaped monstrosities), so there's a lot of marketing left to do


Is that some sort of joke language? The use of colour is fascinating in the same way as seeing a car accident.


Why? Just use TypeScript at that point. The whole point of those languages is the notation as a tool for better thought.


Notation doesn't have to be obscure symbols, the power of the array languages goes well beyond their syntax.


Have you ever read Euclid's The Elements? It's all prose and relatively obtuse. Compare that against the modern notation equivalent and you'll see how empowering the algebraic formulation is. The semantics are the same, but the presentation absolutely makes a difference. APL is not 100% about the symbols, but a huge part of being a tool of thought comes from the suggestivity that symbolic notation offers.


Overloading operators by position (left, right, infix) for related meanings and effectively modifying operators by concatenating them with other operators in sufficiently orthogonal ways are major and unusual achievements of APL, and they run much deeper than syntax.


Yes, and it gets multiplied by the power of the notation, once you get familiar with it.


many people would choose TypeScript over PHP

there is demand for readable replacement of regex

write-only languages stop giving "better thought" right after you stop writing that part of the code


I want to apologize to both PHP and Perl communities. It's possible that I might've mixed up the two of you, because I don't remember which one managed to compile&run 90% of text-recognition app results of paint stains on the walls...


Why use TS when you can use JS in any browser console


I'm presuming that the parent is more of a TypeScript person ;)


Everything is unreadable before you learn it.


Problem is how much time one does need before it is readable.

Had a guy that tried to push LaTeX as documentation writing tooling for the whole company.

Sales guys went with Confluence. They were more concerned with actually closing million dollar contracts than learning fancy typesetting system.


Good notation is worth an extra brain, or how does the bastardized Kay quote go...


And people with special APL keyboards

https://www.pckeyboard.com/page/product/00UA41P4A


I agree that in a team you should not use code golf for others to review your work. But for your own explorations or because your team can read easily your code golf then use it when is appropriate.


> aim design at common people, not gurus

It's not necessary to make everything toddler-safe; we already have Python.


That's orthogonal. C is very readable, yet you can easily shoot your leg off.


> That's orthogonal. C is very readable, yet you can easily shoot your leg off.

Or, you could use C++ which, on one hand is hard and obtuse to read, and on the other hand, has 10x as many footguns as C.


That's because you aren't using Modern C++. You can write Modern C++ safely, you just need to use the right set of features and not the other ones.

Here is a short read on this topic,

https://www.amazon.ca/Embracing-Modern-Safely-John-Lakos/dp/...

It's only 2661 pages. Yes, that is almost 3x longer than The Rust Programming Language, 2nd Ed.




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

Search: