latte

Outside Google, ClojureScript (with a "j") used to depend on the Closure compiler (with an "s") - partly because the library that came with the compiler provided a Java-like API which was convenient as the Clojure language was originally written targeting Java, and partly because the language had quite a large runtime and tree shaking was necessary for performance. You also had to write extern declarations if you used outside code, much like you have to manually declare types for untyped dependencies in when using Typescript.

Edit: ClojureScript still depends on Google Closure.

I find it frustrating that web development moved away from encouraging developers to use a collection of consistent visual styles and basic components (like Bootstrap offered - and even Bootstrap itself is moving towards being a collection of utility classes).

It's very frustrating to have to make a lot of decisions around standard component styling on each new project.

You're absolutely not alone. This is what Paul Graham's post "Maker's Schedule, Manager's Schedule" is about.

http://www.paulgraham.com/makersschedule.html

The majority of the content and comments on HN tell about the benefits of remaining an IC and not moving into management.

Why do people need to convince each other _not_ to move into management by content like this?

To get a balanced view - what are the advantages of becoming a manager? What are the rewarding parts of managing people?

By who's authority should the word "who's" be spelled "whose" and not "who's"?

In all seriousness, it's interesting to see how the live language is diverging from the rules. The dual ending "-ayim" is supposed to be used with the singular stem: nekuda(-t) - giving nekudatayim "two dots", and likewise shnatayim "two years", dakatayim "two minutes", etc. But in practice, speakers classify dual as plural and use the form with both plural and dual endings: nekudotayim, dakotayim

You probably meant 𐤁𐤓𐤀𐤔𐤉𐤕.

Side note: to a Jew, this obsession of Christians over Hebrew and Biblical things feels rather... creepy - although I can't quite rationalise it.

Here is my story:

- got an applied maths / CS degree in the beginning of 2000s, followed by a non-STEM master's degree and almost 10 years in a non-tech career

- burned out, quit job

- spent about a year working on pet projects and (re-)learning programming, then a couple of years on a startup with co-founders (which didn't gain much traction)

- moved to a different country for a developer job. I didn't want to ask my old connections for recommendations, so I just took an offer from a small company that found me on Monster or something similar

- after a couple of years, things at the company became worse, so I started looking for a new job. By that time, I had a circle of friends in the new country, some of which worked at FAANGs and asked me if I wanted a referral.

- I had remembered most of the theoretical stuff needed for LC interview from my CS course from 15 years ago, so I just needed to refresh it, cover the topics I didn't know and have some practice. That took me about a month or two of weekends, evenings and lunch breaks.

- I was so frustrated with my job that I took leetcoding as a pleasurable distraction - I didn't really need anything to maintain discipline. The country was in lockdown, so I didn't have much else to do anyway.

- the whole process from deciding to change jobs to getting an offer took about 4 months. I interviewed at around 5 companies, got 2 offer (one FAANG and one non-FAANG) and decided to take the FAANG one instead. Not sure if this job is a viable road to FIRE (and not sure if this concept is for me at all) but I like it so far.

The argument that US companies have a larger addressable market is valid, but it doesn’t seem particularly convincing. Israel’s domestic market is tiny, and most Israeli start-ups go global from day 1. Probably partly because of that, Israel’s tech salaries are generally above those in the UK, being second only to US salaries. I don’t see anything that prevents, say, a French tech company from going global from day one and unlocking the same value per engineer as Israeli companies do. Many companies based in Cyprus, Estonia or Belarus plan to go global from day one too.

Also, the global market forces (i. e. the demand for engineers from US companies and the overall increased impact per engineer thanks to globalisation) are driving the salaries upwards globally. However, this effect seems to be less pronounced in the EU than it is in other countries. As an example, in Russia in the last several years engineering salaries (while remaining modest in absolute terms compared to UK / US) have become a multiple of those of other white-collar workers, making engineers quite a privileged class. However, in Western Europe, a senior engineer’s salary and a (for example) bank compliance officer’s salary are still within the same range.

Is there any app segment or niche safe from being killed by Google?

Why is Facebook singled out vs. all social media? I feel worse after half an hour spent reading Twitter, Reddit or even Hacker News than after half an hour spent on Facebook or Instagram.

The amount of hate I see on the first three platforms is much higher.

The principles listed in the article look like general common-sense design principles. I can hardly imagine anyone designing a system without understanding the problem domain first - and likewise, the problem domain usually drives the underlying models (because what else can they be driven by)? I acknowledge that something the design process strays away from the original domain requirements (especially among the less experienced teams), but that usually feels wrong irrespective of the design philosophy. So the definition of DDD seems a bit tautological.

I would appreciate an explanation of what DDD is by counterexample - i.e. what are examples of non-domain driven design process? Especially, examples of successful or mostly successful projects - i.e. where the disconnect from the problem domain does not feel wrong from the start.

As someone from outside the EU, I had to go through the bureaucratic hassle described in the article to get into the UK.

After Brexit, the visa requirements were somewhat relaxed in comparison to what they had been for non-EU citizens. For example, previously to hire a non-EU citizen, an employer had to advertise the vacancy on the market for a certain amount of time to 'prove' that they cannot fill it with an EU citizen. Now this requirement, if I remember correctly, has been abolished.

I am against Brexit for a number of reasons, but the differences in immigration rules for different people were too heavily affected by the 20th century war alliances, which have thoroughly influenced the current shape and composition of the EU. I am glad that the playing ground is now somewhat more even.

> Edit: this might make the kids think you need some 'magical' insights to do math and if they don't see it they are not apt for it, while the opposite might be true.

That's a valid point. However, what's the opposite to having insights? Is that following routines and/or exhaustively exploring the entire problem space (which the first problem in the GP comment seems to teach)?

Teaching those might have higher pedagogical value than conditioning children to find insights (as - at least at first sight - the increase in skill in those is more directly linked to the effort the child invests in learning) However, the von Neumann story in your sibling comment suggests that some people (and so, some children in the class) will perform routines faster than the other children no matter what. Seeing a "shortcut" solution gives a chance to those who are slower at routines to arrive at a solution fast, too.

Moreover, a lot of real-world problems (in academia as well as in business - from my limited experience in both) are exercises in pattern matching and finding shortcuts rather than in an exhaustive exploration of the problem space - and helping children to collect an arsenal of tricks (and more importantly, teaching them to look for insights and patterns by giving them multiple trick-based problems over the years) prepares them to handle those real-world problems.

Basically it would be ideal to have a query builder that is easily integrated with shells and notebooks (so that it can be used outside the context of writing programs in a specific languages) and that is accepted across the community.

SQL and the relational model mostly works well and it's probably not practical to redo the enormous amount of work that was invested in SQL and its implementations and extensions.

As someone who frequently used SQL for analytics and less frequently for app development, I would gladly use a language that would transparently translate to SQL while adding some syntactic niceties, like Coffeescript did to JS:

- Join / subquery / CTE shortcuts for common use cases (e. g. for the FK lookups that are mentioned in the article)

- More flexible treatment of whitespace (e. g. allow trailing commas, allow reordering of clauses etc.)

And for the language to be usable, it would probably need: - First class support for some extended SQL syntax commonly used in practice (e.g. Postgres's additions)

- integration with console tools (e.g. psql), common libraries (e.g. pandas, psycopg2) and schema introspection tools

- editor support / syntax highlighting.

It would probably be good to model the syntax of that language on some DSL-friendly general purpose language (like Scala, Kotlin or Ruby).

My experience in Go in production is limited to ~150 lines of code I wrote to contribute a small feature for one Terraform provider.

The provider in question is a very thin wrapper over an API library. The feature I added contained almost no business logic of its own and would probably take 15-20 lines in a more expressive language.

Based on that experience, I would not choose Go for a project of my own (unless it could directly benefit from Go's strengths, i.e. unless it required fast startup, portability and concurrency).

The website is down right now, here's the archive link if anyone is interested:

http://web.archive.org/web/20210418161124/https://midrange.t...

The birth of our child was the greatest contributor to both happiness and stress for my wife and myself. Everything else that happened last year is inconsequential in comparison to that.

If I understand correctly, by "well-adjusted" you mean "a person who has no evident quirks" (like being a Tolkien fan to the extent of naming your practice Lorien, or blogging extensively in a way that can be perceived as pseudo-intellectual or pretentious).

Why do you think it's important for a person to be "well-adjusted" in order to be trusted? Why do you believe that a person who has visible quirks cannot be trusted as a mental health professional (or even needs help himself)?

Does the same thinking apply in your eyes to other professions? Would you likewise distrust, for example, a quirky lawyer, or a quirky manager?

> most GraphQL-based web services only accept POST requests (not also GET requests)

A GraphQL server should generally be able to accept GET queries according to the spec [1]. Are there any common implementations that don't follow this?

[1] https://graphql.org/learn/serving-over-http/#get-request

GraphQL specifies schema and documentation, and implementations usually come with introspection tools, which is not the case for REST. It would be more fair to compare GraphQL to something like Swagger.

That said, GraphQL libraries and tooling tend to be less fragmented and more ready to use than for equivalent REST stacks, which makes development much easier. A simple API built in Python with Graphene looks terse and declarative, while doing the same with Django REST Framework requires adding pages of plumbing code to build an equivalent REST API.

Re: GraphQL being a pain for a backend development - I don't quite understand that argument. If you want to keep a tighter control over the schema, you can have it - the API schema does not need to be a reflection of the underlying data schema with all its relationships - it should be the front-end developer's job to convince you that this or that complex relationship needs to be exposed via GraphQL and let you make sure that it's served efficiently.

Telegram is fine for a single-user setup or for a small team. If you need better multi-user and multi-channel support, you can use Slack.

Both have an easy to use bot API and both support adding action buttons to messages that you can connect to your app's webhooks.

Using a messenger, in my experience, feels more convenient than using an email client when dealing with automations. You can view messages by channel, you don't have to deal with GMail assigning random categories to your emails, and the UI is faster.

I wonder what makes people launch new products using non-metric units in 2020.

Oil trading has a tradition of using barrels, but crop areas are measured in hectares and water volumes in cubic metres in most parts of the world.

Not sure if that's relevant - but were you aware that you can pass GraphQL inputs as plain JSON in variables?

In the vast majority of cases, you don't need to build mutation inputs (or anything else, really) in GraphQL syntax. Python requests library should be more than enough if GraphQL is being used the right way.

You have to thank the OFAC regulations for that - they have created issues for both businesses and customers in the name of political goals that don't have any relation to them.

Reading the original article takes effort, in part because it may be hosted on a slow-loading site with a bad UI, have intrusive ads, be long, uninteresting and / or written in a language that's difficult to read.

I wish HN had at least snippet previews for submissions (like in Twitter, WhatsApp or Facebook) so that I could look at them without following a link and decide whether to open them or not based on more information than just the title.

VCs' duty is to act in the interests of their limited partners, so they have to make investments that they think will generate the highest returns, within the fund's investment mandate.

It may make sense for the activists to apply pressure on the limited partners (many of these being institutions with some social / public angle, such as pension funds, university endowments or sovereign and municipal funds) to demand higher diversity of founders from the venture funds they invest in.

Some large-scale investors have a history of adopting a social or environmental based elements in their investment strategy (for example, Norway's SWF divesting from coal and oil companies) - probably similar moves (but aimed at equal opportunities for all backgrounds) can be demanded from major US based asset management institutions - I don't see why, just to take an example, Harvard's board of trustees can't agree to that - even if that change is not directly aimed at generating the highest return on investment, it may be the right move from the longer term societal development perspective and for the university's brand value.

This has been discussed in the responses to the tweets, but still couldn't find a definitive answer - why Basic?

I started with Basic too when I was a kid, but if I were to teach my child programming now in 2020, I would choose Python as a first language. It has many graphic tools, and it looks even more beginner-friendly than Basic.

Just in case - Luminus has options for adding re-frame and kee-frame (an add-on which adds a lot of convenience stuff to re-frame) to a new project.

Can't comment on WhatsApp's security profile, but it's probably the least convenient among the messengers I use - there is no easy way to access the API to set up a bot for my personal use or do any other kind of scripting / automation. I hope that it will change at some point.