i_s

Maybe we have to subsidize zoomers until we can figure this out.

Xledger | Mid/Senior Software Engineer | Colorado Springs, CO | ONSITE NO-VISA | 90K - 150K | https://xledger.com

Xledger is a cloud ERP system that gives customers better control of their businesses. We are expanding our team in Colorado Springs, and are looking for strong generalists to help us create best-in-class functionality for our customers.

Technology: .NET, SQL Server, Redis, Clojure, ClojureScript, ClojureDart, Postgres

You:

- Have a deep understanding of how the web works (HTTP, databases, caching, API's, etc)

- Have experience building and deploying several web applications

- Are comfortable with relational databases (we use SQL Server and PostgreSQL)

- BONUS: experience with Clojure

Our hiring process consists of a few video interviews and often a short (30 - 60 LOC) work sample submission.

Contact [email protected] with resume, and if available, links to some of your work (e.g., Github profile).

Note: No remote position or visa sponsorship available. Please don’t apply unless you know you can already legally work in the US.

If I type the name of an enum, then `.`, (and for my settings explicitly request autocomplete suggestions from VsCode), I either don't get anything, or I get a list of 50+ identifiers that have nothing to do with the enum. There seem to be a lot of cases like that where there is a very obvious context, but the suggestions are completely detached from that context. Stuff that works for any mainstream language like Java or TypeScript in just about every IDE or editor with a plugin.

KSON looks interesting. Where I work we did a metadata type project in Pkl recently, which is somewhat similar. Unfortunately, developments on the tooling front for Pkl have taken an extremely very long time. Not sure the the tooling/LSPs are anywhere close to what the language offers yet.

I like the language embedding feature in KSON - we would use that. Have you thought about having functions and variables? That is something you get in Pkl and Dhall which are useful.

Couldn't you just use static classes? I don't see how that would be a factor at all, seems like a very superficial reason that would be easy to work around.

Yea, I came here to say the same thing. Anders' reasons for not going with C# all seem either dubious or superficial and easily worked around.

First he mentions the no classes thing. It is hard to see how that would matter even for automated porting, because like you said, he could just use static classes, and even do a static using statement on the calling side.

Another one of his reasons was that Go was good at processing complex graphs, but it is hard to imagine how Go would be better at that than C#. What language feature that Go has, but C# does not supports that? I don't think anyone will be able to demonstrate one. This distinction makes sense for Go vs Rust, but not for Go vs C#.

As for the platform / AOT argument, I don't know as much about that, but I thought it was supposed to be possible now. If it isn't, it seems like it would be better for Microsoft to beef that up than to allow a vote of no confidence to be cast like this.

Here is one in 73 lines of F# by Jon Harrop:

https://gist.github.com/isaksky/6681cfad8ced1708a04b2eca92fc...

I've read this a few times over the years and I think the argument is sound. But I wonder if it is sound in the same way this statement is:

"It is better to go picking blueberries before they are fully ripe, that way you won't have much competition."

I say higher earners and you think I'm talking about billionaires? Deranged.

I'm just people at higher than the 50th percentile. Say 75th percentile, which probably includes a lot of people from HN.

Norwegians are rich if you look at the average, but if you compare higher earners there vs the U.S. I would say they are actually poor. For example, take an above average software developer in the US and compare them to one in Norway - you will see a massive difference, especially in disposable income.

I'm not sure the use of 'accidentally' was sincere. But I like this choice of words in your post in your first version:

> unmercenary assumptions

Not if he does the type of job hopping typical in silicon valley. There are plenty of programmers who only stay at a job ~2 years, and never have to maintain a program over a long period. You could imagine such a person saying 'this worked well at my last job' and just keep introducing that kind of pattern to new companies, eventually with '20 years of experience'.

I'd argue .NET isn't actually that great of a multi language platform. We have a mixed F# and C# solution at work, and that split sometimes causes a lot of friction. If you have some C# code that depends on F# code, that constrains your ability to have F# code depend on C# code. You need to be very careful about how you organize your work to get a good solution (more than on other platforms.)

In the JVM world, mixing languages works a lot better, because you can compile .class files instead of whole assemblies. So mixing clojure and Java, for example, is very easy to do in any order.

Sounds like 'Age of Em' by Robin Hanson: https://ageofem.com/

Saying there is an absence of evidence (of a leak) isn't useful by itself unless they also indicate whether that is evidence of absence (of a leak). I.e., they should indicate whether it is likely that they would have caught it if a leak had occured (e.g., via extensive logging).

> This doesn't make much sense. MSSQL does these already I think (except the first)

We tested all of these before taking the time to do the rewriting, and no, either they don't, or they way they did it isn't good enough. You can say I'm lying if you want, I'm not going to spend time arguing about it.

To check if rewrite rules are still helpful, yea - we just read release notes and test manually.

We've never had a rule change from being beneficial to detrimental. For most of them, I don't think that would be possible, because they just involve giving Sql less irrelevant things to chew on. For a few of them, like the manual scalar function inlining, I could see that being possible, so we will just need to keep checking.

For rewrite rule order, I guess we just do the ones that can enable other optimizations first. So far, that has been pretty simple to determine. For example, when we trim joins from inner queries, we first trim their selections (depending on what is actually used in the outer queries).

At my work, we often parse and rewrite a query before handing it off to SQL Server, because there are a lot of cases where Microsoft misses obvious optimizations. Sometimes there are also optimizations we can do because of things we know at compile time, but don't fit in the type system of SQL. The impact varies all the way from just shaving off 10% of the execution time, to changing some queries from timing out in a web request to executing in a few hundred milliseconds.

A few examples:

- Inlining scalar function calls (less impactful now with Sql Server 2019)

- Removing joins from a query when we know it won't impact the number of records

- Deepening where conditions against derived tables

- Killing "branches" of union queries when they can be determined to not matter statically

Yes, we could write the queries that way in the first place, but it would make them harder to compose, more verbose, and harder for the programmer to communicate intent. Not to mention, often the user can impact what the query will be, making it less feasible.

You think I'm saying "don't be different for any reason." What I'm actually saying is "don't be different without a good reason". Python for example has been criticized for the breaking changes in version 3, which caused a lot of problems for the community, arguably without a good reason.

> You may as well complain that the C guides didn't work in Java.

Java borrowed a lot of syntax from C, and it has been very successful. If Java had instead taken the powershell approach of needlessly deviating with the syntax, it probably would not have become as popular as it did. So that example supports the opposite of what you thought it does.

> It is a complete re-imagining of what a shell scripting language is. Hardly surprising that it isn't backwards compatible

By why does having richer return types necessarily mean you need to deviate from most other languages for the escape character (backtick in Powershell, but usually backslash)? That doesn't seem related, and it greatly impacts the initial impressions people get.

> The thing that disappoints me is that nobody from the *NIX world has tried to bring the same ideas there. They're good ideas.

I agree, and I hope someone does. But if they do, I hope they just focus on the ideas, and leave out the small and unimportant incompatibilities powershell decided to add.

I want to like powershell because of the richer return types, but it has so many strange deviations from normal shell languages that it is hard to get productive in it.

I remember testing out some new languages and toolchains and following the guides, but I would often get many of them that would not work because I was using powershell. Powershell has different syntax for escaping (backtick), starting arrays (parens), etc., that makes many commands completely incompatible (even very short ones).

Xledger Inc | Junior Software Engineer | Colorado Springs | Onsite | Full-time

Xledger (ERP / Accounting & Financial Management Software) is expanding the R&D team which focuses on UI improvements, performance, and development tools. We are looking for Junior Software Engineers (even new grads) to help us create best-in-class functionality for our customers.

Technologies:

C#, SQL, Clojure, ClojureScript

Apply here:

https://www.ziprecruiter.com/job/f570bec9

Yea, making it so statements are composing via YAML was a very poor choice. One case I had was needing to change my actions so that steps D, E, and F could be retried together. What is the github YAML specification for decrementing a 'tries_remaining' variable, then going back to a previous step? I couldn't find it, so ended up just having to rewrite the action so that most of the steps are now in one bash script.

Not being able to execute it locally has also wasted a lot of time, and people needing to make 50+ changes to the master branch until they get it right.

I mostly agree, but every now and then there is actually a good reason to override/re-implement them. For example, let us say you are using virtualized components [0], so all available elements have not necessarily been rendered to the DOM (making Control-F useless).

[0] - https://github.com/bvaughn/react-virtualized

Yea, we've had the same problem. I've started to ask our designer just show the thing that should be changed, with 0 other context.

An idea for Figma to mitigate this problem: make a browser extension that can export pages to figma documents. That would make it much easier to have up-to-date designs when doing web development.

I thought so too, at first, but now I'm really down on it. Ecto Changesets work fine for flat data, but when you have to deal with nested data, it becomes a nightmare, because you have to use these special functions to read and update the data. Doing that in a nested context just gets really clunky, especially coming from Clojure, where I would just do something trivial, like

    (assoc-in changeset [:children 1 :title] "New title")

Xledger | Senior Software Engineer | Colorado Springs, CO | ONSITE NO-VISA | 100K - 140K | https://xledger.com

Xledger is a finance, project, and business information system (ERP) that gives customers tighter control of their businesses.

We are expanding our team in Colorado Springs, which focuses on UI improvements, performance, and development tools. We are looking for Senior Software Engineers to help us create best-in-class functionality for our customers. Experience with Clojure/ClojureScript is a plus.

Our hiring process consists of phone interviews and sample work submissions (and/or open-source work review).

Note: No remote position or visa sponsorship available. Please don’t apply unless you know you can already legally work in the US.

Apply at our ziprecruiter posting: https://www.ziprecruiter.com/job/723556eb

Xledger | Senior Software Engineer | Colorado Springs, CO | ONSITE NO-VISA | 100K - 140K | https://xledger.com

Xledger is a finance, project, and business information system that gives customers tighter control of their businesses.

We are expanding our team in Colorado Springs, which focuses on UI improvements, performance, and development tools. We are looking for Senior Software Engineers to help us create best-in-class functionality for our customers.

You:

- Have experience building and deploying several web applications

- Have a deep understanding of how the web works (HTTP, databases, caching, API's, etc)

- Can pick things up quickly

- Have high standards

- Can focus and get things done

- Are comfortable with relational databases (we use SQL Server and PostgreSQL)

Nice to have:

- Frontend experience (React, reagent, re-frame)

- Experience with Clojure/ClojureScript

Our hiring process consists of phone interviews and sample work submissions (and/or open-source work review).

Contact [email protected] with resume, and if available, links to some of your work (e.g., Github profile).

Note: No remote position or visa sponsorship available. Please don’t apply unless you know you can already legally work in the US.