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.

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).