ReconWell | (Senior/Staff) Full Stack Software Engineer | REMOTE in Germany/Switzerland | 70-100k€
At ReconWell, we’re a dynamic, small company dedicated to app development for psychiatric hospitals. Partnering with a prestigious university psychiatry in Switzerland, our work is at the forefront of mental health research and application.
We value tight integration of domain experts into our engineering. Using our specialised platform we deliver software faster and better than many others in this space. Quality management and regulatory requirements are central to our business.
Looking for a self-driven, curious person to join our engineering team. Should bring at least a few years of relevant experience.
You would be expected to start from an area where you're most comfortable in (Frontend, Backend, Ops, QA, DSL, ...) and grow from there. Eventually you should be able to work on all parts of our codebase without mentoring.
I'm Philip, CTO of ReconWell and my email is philip@reconwell.de
Thanks, that looks interesting. AFAICT it only covers the editor/IDE parts, though, and that's not even close to "most" of what I mentioned. How does it help create linters and checkers? How does it ease integration with debuggers and build systems? Plus, you have to use JetBrains to get even that. Nothing against JetBrains, but that's not going to help at most companies which have already settled on other tools. It looks like a slightly easier way to create the core part of a DSL, but I'm not sure that solves the problem of the result being an "alien" thing that other developers will develop distaste for.
It uses a projectional editor, so there is only one way of "formatting" the code and no need for a linter. The typesystem is very powerful and allows a language engineer to create arbitrary checks on the language which are executed inside the IDE.
I have not tried building a debugger for a DSL in MPS, but it might be achievable, at least if you're targeting Java as a generated language.
Build integration is available for Maven and Gradle.
I'm thoroughly convinced that software engineering efficiency can be increased by at least one order of magnitude by letting domain experts and product owners directly modify the product through a well defined DSL.
To create that ideal dsl one has to both know the domain well enough and have the technical skills which is a rare combination so i'm rather sceptical of this claim.
Besides any dsl can only help with well understood repeatable problems, for problems that aren't covered by a dsl, software engineers are still required.
The fundamental role of software engineers is to build easy to use and insightful interfaces to understand complex data generated/collected from the real world.
To do that one needs to have the skill to organise information and control complexity by data hiding not exactly the skills product owners and domain experts are known for.
We built the first open-source feature store for ML, https://github.com/logicalclocks/hopsworks , when every existing proprietary feature store (Uber Michelangelo and Bighead at AirBnb) were shouting about how their DSL for feature engineering was the future.
Fast-forward 2 years and it is clear that Data Scientists want to work with Python, not with a DSL. We based our Feature Store on a Dataframe API for Python/PySpark. The DSL can never evolve at the same rate as libraries in a general-purpose programming language. So, your DSL is great for show-casing a Feature Store, but when you need to compute embeddings or train a GAN or done any type of feature engineering that is not a simple time-window aggregation, you pull out Python (or Scala/Java). I am old enough to have seen many DSLs in different domains (GUIs, aspect-oriented programming, feature engineering) have their day in the sun only to be replaced by general-purpose programming languages due to their unmatched utility.
The article (controversely, maybe) classifies libraries for general-purpose programming languages as internal DSLs. One could argue that Data Scientists working with libraries in Pythin are already using a DSL, just with an escape hatch into the general-purpose world.
I don't think proper vertical DSLs should be made marketed towards people who are comfortable working in a general-purpose language. I see them as a way to help non-technical domain experts work on code instead of specification. Limiting the possibilities of what one can write, like with MPS' projectional editor, is a feature here and not a bug.
A library is not a DSL, despite what the learned authors may claim. In fact, there are a couple of examples of "successful" DSLs in the data world - you could argue that Talend and DBT are visual programming tools for ETL pipelines. Defintely Zapier- which is just for integrating services that have well-defined REST APIs.
I think that Clang generated binaries won't run on Windows versions below 7, if I remember correctly it has something to do with implementing SEH but I could be completely wrong and it could also have nothing to do with their decision but it makes sense - they moved to clang for compiling Linux binaries to simplify build process and they are a big driver behind Clang on Windows.
I'd be very surprised to hear this. Clang and Rust both use LLVM, and Rust can generate binaries for XP (with a few caveats). Of course, the fact that LLVM no longer supports running on XP means that the Rust compiler itself doesn't run on XP (not that it ever did).
Talentry is building the future of employee referral programs with our SaaS offering. We have won customers among established german and international companies and solid financing.
I'd love an adblocker with a blacklist instead of whitelist so I could keep the ads on for the long tail of my browsing and remove them only on sites that go overboard.
At ReconWell, we’re a dynamic, small company dedicated to app development for psychiatric hospitals. Partnering with a prestigious university psychiatry in Switzerland, our work is at the forefront of mental health research and application.
We value tight integration of domain experts into our engineering. Using our specialised platform we deliver software faster and better than many others in this space. Quality management and regulatory requirements are central to our business.
Tech Stack: Kotlin, TypeScript, JetBrains MPS (Language Engineering, DSL), Spring Boot, React Native
Looking for a self-driven, curious person to join our engineering team. Should bring at least a few years of relevant experience.
You would be expected to start from an area where you're most comfortable in (Frontend, Backend, Ops, QA, DSL, ...) and grow from there. Eventually you should be able to work on all parts of our codebase without mentoring.
I'm Philip, CTO of ReconWell and my email is philip@reconwell.de