vedantroy

Does anyone know why Bash has low usability?

It seems like Bash has tons of footguns and unintuitive syntax. Is this just because the language grew organically?

This reminds me of my `jsmv` tool, which I use for manipulating the file-system in place of Bash / find:

https://github.com/vedantroy/jsmv

That last statement was very bold. Do you think there is a direct link between open-sourcing this library and increased telemetry? What about VSCode and increased telemetry?

"It's common among people who think Javascript is a serious language".

I can't tell if you think JS is not a serious programming language.

I don't understand the desire for terse code, it makes things harder to read.

I also think Typescript makes the right tradeoffs, yes it may not have a Haskell-level type system, but in return, it has amazing integration with JS code and existing libraries, and no runtime.

As a side note, coming from someone whose previous exposure to type systems was Java and Kotlin, Typescript seems to have a pretty powerful type system. Yes, it may not have some/many Haskell-level features but I question whether those would have been necessary in the first place. At some point a more rigorous type system must stop generating value, otherwise we would all be using coq.

I think the larger issue is that shell scripts are intrinsically bad for writing readable code.

Consider the "cut" line in the shell script vs the "map" line in the JS script. The map line is easy to understand because it uses a chain of simple functions (map, split, array access, and lastly trim). The "cut" line has to cram all of this functionality into a few command line arguments instead of composing basic building blocks together.

I mean look at this: What does "only delimited" mean, what does "fields" mean, I might just be an illiterate boor but I don't remember what delimiter means off the top of my head (something like seperator, I assume).

cut --only-delimited --fields 2 --delimiter '|'

The JavaScript version is easier to read because it uses fundamental building blocks in the language that are

1. Super intuitive. (Split seems pretty easy to understand, especially when you know the input is a string, similarly everyone knows [1] means array access).

2. Widespread. You have probably encountered all of those JS functions before, I'd say the chance of encountering the "cut" utility is a bit less.

Summary: Shell just fundamentally sucks because it outsources a lot of functionality to various executables, each which have their own command line arguments. The ideal method is to use a programming language with consistent, composable, building blocks.

I am not a rust expert, but I assume the recent many programming languages have a keyword for function declaration is so that functions can be first class objects.

Sometimes I feel like I'm forced to take verbatim notes on my computer, even though I know that's bad for my learning.

Specifically, I'm reading a very detailed textbook on databases. I feel that if I don't take notes I will forget most of the content in the textbook because the textbook is so information dense, but at the same time, whenever I take notes they end up being word-for-word copies of the text because the textbook is already so concise/word-efficient.

Most of the time, I don't see an issue with non-native looking UIs. Oftentimes, non-native UIs look better.

VSCode and Atom both look great and they're non-native. I also think Slack looks pretty good too. Except for MacOS, native UI widgets generally seem to be pretty ugly.

Even Microsoft is embracing non-native UI for its own Microsoft Office platform.

Web-apps/material design, look sexy.

Out of curiosity, why doesn't the stack layout use flexbox? It seems like flexbox is the perfect fit for such a layout.

This is definitely an overly ambitious project idea, but now that Google has Jetpack Compose and Apple has SwiftUI, and the web has React, I wonder if it would be possible to make a "meta-framework" that uses a single code-base to compile user written code into source code written in those 3 frameworks respectively.

Then you would get truly native, cross-platform development.

Now, the probability this would ever work is 1%, but it's something that has lingered in my mind anyway.

I feel like unusual language syntax isn't an issue, as long as the syntax is understandable/readable once the programmer learns the syntax.

It doesn't take too long to pick up and become comfortable with a new syntax in a programming language.

Imo, the reason some esoteric languages fail are not purely because their syntax is obscure but because even once you learn the syntax, it is still hard to understand the code (example: Brainfuck).

With Rust, once you learn the new syntax, you can understand Rust code with relatively little effort.

I feel like JSON is a decent format for storing human-readable configuration data.

The use of brackets means if something is broken, you'll know explicitly because your IDE will throw a fit. Formats that are white-space dependent can have subtle errors that aren't easily recognizable on first glance.

The 2 problems with JSON are multiline string support and comment support, but JSON5 solves both of those problems. Sure JSON5 isn't JSON, but YAML isn't JSON either. No matter what you're going to need a library to parse a config file, so why not stick to something based on a widely used data-storage format?

I noticed Rust was not your list of languages. Is Rust fundamentally different then these languages? If so, why?

I don't know whether Article 11/13 are good or bad (although at first glance they seem to be bad), but I don't think this attitude of "forcing freedom" onto others is good.

The entire attitude that I should "regain [my] freedom" seems condescending. I don't want to use a P2P alternative to YouTube or Reddit, because 99% of the content is on Reddit/YouTube.

I'm well aware that YouTube collects and sells my personal data, I just don't care.

The idea that legislation is good because it forcefully restricts my choices (indirectly, by harming YouTube), thus preventing me from harming myself seems to be a form of unneeded parenting/hand-holding/babying that I'm not a fan of.

That just isn't possible. Javascript is necessary for many features in today's web.

My point is that people keep on saying Facebook is harming me through its data collection, but no one has provided an example. Same with you, you assert that Facebook is harming me without giving evidence or examples of how the data is being misused.

>It surprises me that the majority of my family can still tolerate Facebook (and instagram/whatsapp etc.) despite what is known.

I'm not sure why it's super surprising. Facebook's data collection has never personally harmed me. I like Facebook because it helps me stay connected and tools like whatsapp/messenger are some of the best cross-platform messaging tools.

Yes, Facebook has downsides, but I've never experienced a privacy-related downside.

Someone should provide a link to an article that exposes some really nasty stuff about Facebook--I already know Facebook knows my address and my likes/dislikes and probably what sites I browse (since many sites use Facebook tracking), and it reads my messages, but in a way, I don't really care about those things because Whatsapp and FB Messenger are free.

The point is that developers don't want to be testing against multiple browser/rendering engines--hence why Electron was built.

Maybe having multiple engines is good (although maybe the benefits are overstated since nowadays most engines align with the spec instead of implementing non-standard extensions like ActiveX), but it's not good for people for who want to quickly, and with low effort, develop desktop applications.

The point of the parent comment was that developers chose Electron over other frameworks for reasons such as speed of development, and DeskGap does not align with those reasons.

I'm not sure why people (were) downvoting the parent comment.

Typescript (and normal Javascript) both support async/await very well as long as you use Babel to compile your code.

Infact, you don't even need to use Babel to compile your code because a large portion of browsers natively support async/await: https://caniuse.com/#search=async

I'm not sure why people say you need libraries that support async/await. In JS/TS, async/await are built into the language itself and most libraries utilize the Promise API, which means they also support async/await (since async/await is built on top of promises).

Something I've wondered about with Web Assembly applications is, how do I actually view the web assembly/compiled blob? E.g--with normal Javascript, I can go to "sources" tab in developer tools and download all the JS, but how do I download the wasm?

Am I misunderstanding how web assembly works?

I always viewed it as a transaction--go to the news site and read the news, in exchange they will sell data on what articles you're reading, etc.

I was fine with that transaction. In fact, I would rather have them sell my data instead of charging money.

Consumers have a choice on whether or not they want to go to these sites, it's not like they are forced to give away their personal information to news sites.

I would say the GDPR blocking news sites is a net negative because it denies consumers the choice to read news stories.

I'm not too worried about the constant "framework hype". Although there are many frameworks, React is a solid option that remains relatively dominant. Yes, others exist like Vue and Angular--but I can be pretty confident that React isn't leaving anytime soon.

Similarly, with C++ there are also many packages to do the same thing. This summer I was using TLS and I found a variety of options, OpenSSL, mbedTLS, wolfSSL, etc. etc.

I do agree that it is tiring to learn some of React's accessories. I have never used Redux and when I do need some form of global state management, I think I will use MobX.

The complaints about code base quality and "stupid e-commerce websites" don't seem to be problems inherent to Javascript, although I suspect the problems Javascript solves are less interesting than the ones C++ solves.

All in all, I feel like C++ (for me) has been more difficult than Javascript due to a lack of standardization and the community being less beginner friendly.

That being said, I was trying to use a relative obscure feature (SGX) in C++, whereas with Javascript I stick to relatively mainstream applications.

You shouldn't make broad statements like that. In my personal experience, I have found Javascript much easier than C++. If I want to install a package, I can just do "npm install <package_name". Also, 0-configuration bundlers like Parcel make building complex projects very easy.

Now, I'm sure some people have an easier time with Makefiles, but I've found it even easier to get up and running in Javascript. Most of the tools in Javascript (create-react-app, Webpack, etc.) are very user friendly, making setup trivial.

It is best not to speak with such authority/certainty that C++ is easier to use than Javascript.

I don't think FB has that many unseen costs.

I don't really care if FB sells my information to advertisers, so they can market products to me more effectively.

I don't care if FB co-operates with other companies in order to suggest friends to me.

FB adds a lot of value to my life (messaging & finding out about events).

What I truly dislike about FB is that it creates information bubbles, so people are never exposed to viewpoints outside of their own. Also FB doesn't regulate false information/alt-right propaganda enough.

Obviously, I would prefer if FB didn't sell my data, but at the end of the day it doesn't impact me at all.

That being said, if I ever become an important figure who is running a business that is competing with Facebook in some way, then I'll be sure not to use their service.

I don't understand this hatred of Javascript. The only websites I've felt were actually bloated are news sites with a lot of ads, but that's not a problem with Javascript as much as it is a problem with excessive ads.

What counts as information-centric? A lot of basic things (commenting, searching, liking a post) require Javascript. If you want to use pretty animations, there's a high probability you need Javascript.

Making information-centric sites only use HTML/CSS would significantly decrease the capabsilities and attractiveness of the sites.

If you don't want to have your "dirty laundry aired out in public courts", then don't have dirty laundry.

I don't see why monoculture (as long as the browser engine is good) is bad. Unlike the era of Internet Explorer, Chromium-based browsers are actually consistent with official standards.

On websites like "caniuse.com", a site which checks for support of the latest JS/HTML/CSS features, Chrome consistently ranks 1st. These features are all official features of the HTML/JS spec, not arbitrary Google-specific extensions.

Ensuring that more people use a browser with the Chromium-engine will allow web developers to use the latest features.

WebKit is a form of harmful monoculture. I'm ok with Blink's monoculture because it is probably the best rendering engine out there and inferior engines can't compete. But Apple's is creating an artificial monoculture by only allowing WebKit on iOS. This allows Apple to not innovative on WebKit and deliberately cripple new web technologies, so that people are forced to make native apps.

I think more then "prettier UI" is necessary. I switched from Windows to Linux a few months ago, and while I appreciate being able to use more developer tools and not have annoying ads in my OS, I feel like Linux is just more unstable. My wifi/bluetooth randomly stop working, forcing me to restart my computer. That's unacceptable.