-
I’ve continued working on my solo entrepreneur SaaS product, NewBusinessMonitor. I’ve added a feature where users can save searches they’ve made so they can recall them later. I also moved all georadius queries from Redis to PostgreSQL, and I’ve added caching with Redis. This week I want to combine the saved searches with scheduled reports, so every morning you can wake up with a CSV of specific types of businesses you’re interested in.
Tech: Haskell, Elm, Nix.
-
-
I’ve been working on my solo entrepreneur SaaS product, NewBusinessMonitor. I’ve been adding cosmetic touches and I’m trying to make the site work better on a mobile device, as to my surprise, most of my traffic comes from mobile devices.
I’m adding a feature where users can save searches they’ve made, and recall them later. After that, I want to add historical financial data to each company.
Tech: Haskell, Elm, Nix.
-
If that is your definition of “full-stack engineer”, then I absolutely count myself as one. I thought the joke around that title was that “full-stack” is far more than just the web services and UI of a typical web app.
I wonder also if I’m the only one who finds it weird when someone quotes themselves.
-
The best part of my current day job’s policy is that meetings are not obligatory. I make the most of my daily standups by not attending. I’m not concerned about taking 10 minutes to discuss something in the morning. It’s the fact that we’re holding a synchronised ritual with zero value in what should be a distributed and asynchronous team that plays on my mind and frustrates me to no end right at the beginning of my working day.
Last year we didn’t have project managers — we were self managed. We had a strong culture of documentation. Everyone on the team had a habit of writing papers to articulate their thoughts, and tasks were thoroughly annotated in Trello with both technical and business context.
Now we bring in a project manager (because that’s just what you’re meant to do, right?), and the first reflex for every instance of dialogue (or indeed, monologue!) is a synchronous meeting. Documentation quality (and I don’t mean code library documentation) has plummeted.
When I inevitably run a tech team full time, there will be no ritual standups, and there will be no project managers. And there sure as hell won’t be any “Agile Coaches”. You’re all banned.
-
All that time I’m studying diversity and inclusion is time I’m not shipping a product.
-
If you need to spend 40 hours just to treat your peers as peers you will never ever be successful. Cooperation and mutual gain is the foundation of success. You’re going to waste so much time butting heads that you’re never going to get anything shipped.
If you are a startup founder I highly recommend 37 Signal’s rework. He cuts through a lot of the cargo culting of larger corporations in startup culture and gets to evidence based strategies.
-
I’m not sure if your comment agrees with mine or not.
In any case, I have brought more women into tech than men, but not as part of any political crusade. I just happen to hang out with women more. Sadly, some of these women have decided tech is not for them because they don’t want to deal with the people who spend most of their time talking about diversity.
I have worked with and still work with brilliant women, and we do great work together. It really is as simple as that. Or perhaps I live on a different planet. Who knows.
Edit: I’ve shipped products alone and in teams. And I have a copy of Rework, and I’ve read it (and thoroughly enjoyed it) twice — it’s not particularly long. None of this is going to change my position.
Edit 2: The motivation for my original terse and provocative comment was the author’s list of 10 ways to become a 10x developer. I think the list is largely nonsense, but that absolutely isn’t to say I disagree with all of the points. Most of them are common sense and generally adhered to by decent people. Some of the points however veer into typical SJW territory of quotas and affirmative action, which I strongly reject as a left-leaning liberal.
-
Again, if you need to spend 40 hours a week for the indefinite future to educate yourself on diversity, inclusivity and equality you have no place running a business. If women are leaving your business because you’re talking so much about diversity then stop doing lip service.
-
If women are leaving your business
…But, they aren’t?
I said I know women who have left tech after having to deal with people who are only interested in talking about diversity. This has happened after I sent these women to events like RailsGirls and similar.
Please try reading more carefuly.
-
In my defense it was a particularly ambiguous line. The main thing I viewed as dangerous was not being willing to investigate or understand diversity or inclusion. I’ll admit part of this might be a misunderstanding as a result of where we live? We don’t really have the same intense everything about diversity environment where I am. Instead it’s usually a token statement with not much action behind it. Most workplaces around where I am have a stark wage gap between men and women. The root problem is that when you don’t have solidarity with minorities or other traditionally oppressed groups, it can basically be used as a wedge to drive all wages and labor rights down.
Being said yeah I don’t carte blanche accept everything the author wrote either.
Edit: I don’t see anywhere in the article where it talks about quotas…
-
I understand. And in that case, I think we mostly agree with one another. Your comment about location is pertinent too; the social climate in the US is nothing like what it is in, e.g. Sweden or Poland. I’m not sure this is understood by everyone.
The article didn’t explicitly mention quotas, but at least in my experience I believe point #10 is a euphimism for just that.
-
Yeah that’s fair. As I’ve said in response to klingtnet too recently I’ve literally had to defend even having a discussion about bigoted terms on this site. There’s a sort of identity conflict going on that seems to be distracting from the root of using solidarity as our primary way of relating. When you see some demographic being attacked you speak up, not because you support them, but to create a herd immunity. There are those who seek to divide up the public in some faint hopes of being on top. In reality any group seeking to divide the public will themselves be divided and controlled.
-
-
-
-
-
-
-
I frankly can’t tell anymore. It seems like lobsters has recently gotten an influx of individuals who are arbitrarily hostile to random demographics. I’ve recently been butting heads with people who seem to think that any sentiment against hostility or towards civility is somehow going to ruin their lives. Not saying jgt is that kind of person but the interactions with various others prior have definitely made me more defensive.
-
The term is Shrödinger’s asshole.
-
No, my position on this has not changed. I still think the original article is mostly political propaganda. As I clarified in an earlier comment, I believe the author is using a euphimism for affirmative action — a concept which in my experience has increased polarity, and in some cases even driven women away from our industry.
The women I work with explicitly do not want to be treated differently. They do not want to be thought of as “woman programmers”. They are programmers. They do not want handouts. They want equal respect as peers, which is of course what they deserve. Affirmative action is not equal; it’s a handout.
I am surprised I have to explain this to you, and I’m even more surprised that the Lobsters community is cool with a user nonchalantly calling another user an asshole.
I have some choice terms for you, but I’ll keep them to myself.
-
Uhm, sorry it wasn’t clear, but I wasn’t calling you an asshole. The comment I’m replying to explicitly says:
Not saying jgt is that kind of person but the interactions with various others prior have definitely made me more defensive.
I simply linked to a concise term for the behavior voronoipotato was describing.
-
-
-
-
I’ll concede that there is always some sarcasm [a personal weakness of mine] when I touch on this issue. That’s because it’s important, and it affects some people dear to me. Do I want a more diverse industry? Of course! I just don’t believe that all of the most vocal diversity advocates are going the right way about it, for the reasons explained in some of my previous comments.
-
I’d appreciate it if you were more clear with your sarcasm in the future so that I won’t be tilting at windmills. I personally am fond of the “ :V “ face to denote jokes/sarcasm. There are people (I grew up with) who still think that a woman’s role is only to take care of the home. They aren’t old, they’re like 27. So for many there is still a discussion being had about whether this is even a problem we want to solve.
-
-
-
-
-
404
-
Yeah, I’m disappointed that happened. I renamed the file in Git, and I guess GitHub/Jekyll just gave up hope. It’s still live at http://jezenthomas.com/deploying-a-haskell-web-service-with-nix
edit I think this is to do with GH’s recent GH Pages version bump. All my links are now broken from the outside, and I have to explicitly specify a trailing slash.
-
I’d like to provide a more sympathetic outside perspective.
There are a few common complaints about Elm and Elm community:
With regards to blocking discussion, I think the logic is something like this:
I would prefer that the discussions weren’t removed or locked, but on the other hand, it’s got to be grating to deal with the same entitled, uninformed or complaining comments all the time. I’ve read most of these discussions, and other than people venting, nothing is ever achieved in them. My reflexive reaction is to be uncomfortable (like a lot of other people) but then, there is also a certain clarity when people just say that they will not engage in a discussion.
With regards to insufficient communication, I think the main things to understand is that Elm is an experiment in doing things differently, and it’s causing a clash with conventional understanding. Elm is about getting off the upgrade treadmill. So, for example, when a new release like Elm 0.19 comes out, it happens without a public alpha and beta phases, and it’s not actually the point where you go and immediately migrate your production code to it! It’s only the point to start experimenting with it, it’s the point where library and tool authors can upgrade and so on. (There was quite a bit of activity prior to release anyway, it just wasn’t advertised publicly.)
Finally, the most contentious example of a “feature” getting removed is the so called native modules (which basically means the ability to have impure functions written in JS in your Elm code base). As far as I can tell (having followed Elm since 0.16), native modules were always an internal implementation detail and their use was never encouraged. Nevertheless, some people started using them as a shortcut anyway. However, they were a barrier to enabling function-level dead code elimination which is the main feature of the 0.19 release, so the loophole was finally closed. Sure, it’s inconvenient for people who used them, but does anyone complain when, say, Apple removes an internal API?
Ultimately, Elm is just an open source project and the core maintainers don’t really owe anybody anything - no contracts are entered into and no funds are exchanged. They can do whatever they want.
Of course, there is a question of the long term effects this approach is going to have on the community. Will it alienate too many people and cause Elm to wither? Will Elm remain a niche language for a narrow class of applications? That remains to be seen.
Over the years, I have come to believe this is a vital part of building a community. Using draconian tactics to stomp out annoying comments is using power unwisely and worse yet – cripples your community in multiple ways.
The first thing to remember is that when a comment (entitled, uninformed or otherwise) comes up repeatedly – that is a failure of the community to provide a resource to answer/counter/assist with that comment. That resource can be a meme, a link, an image, a FAQ, a full on detailed spec document, whatever. This type of thing is part of how a community gets a personality. I think a lot of the reason there are a bunch of dead discourse servers for projects is too stringent policing. You should have a place for people to goof off and you have to let the community self police and become a real community. Not entirely, obviously, but on relevant topics.
This constant repetition of questions/comments is healthy, normal, it is the entrance of new people to the community. More importantly, if gives people who are just slightly deeper in the community someone to help, someone to police, someone to create resources for, even to a degree someone to mock (reminding them they aren’t THAT green anymore) – a way to be useful! This is a way to encourage growth, each “generation” of people helps the one that comes after them – and it is VITAL for building up a healthy community. In a healthy community the elders will only wade in occasionally and sporadically to set the tone and will focus on the more high minded, reusable solutions that move the project forward. Leave the minor stuff be done by the minor players, let them shine!
Beyond being vital to build the community – it is a signal of where newcomers are hurting. Now if documentation fixes the problem, or a meme… terrific! But if it doesn’t, and if it persists … that is a pain point to look at – that is a metric – that is worth knowing.
Yeah, each one of these people gives you a chance to improve how well you communicate, and to strengthen your message. But shutting down those voices then run the risk of surrounding yourself with ‘yes people’ who don’t challenge your preconceptions. Now, it’s entirely up to the Elm people to do this, but I think they are going to find it harder to be mainstream with this style of community.
Note that I’m perfectly fine with blocking and sidelining people who violate a CoC, or are posting hurtful, nonconstructive comments. You do have to tread a fine line in your moderation though. Being overly zealous in ‘controlling the message’ can backfire in unpredictable ways.
Anyway, I continue to follow Elm because I think the designer has some excellent ideas and approaches, even if I do disagree with some of the ways the way the community is managed.
I don’t think the two jobs (managing the community and managing the project) should necessarily be done by the same person. I actually think it probably shouldn’t. Each job is phenomenally challenging on its own – trying to do both is too much.
Yeah, completely agree! I think it would take a huge weight of that person’s shoulders too! :)
I don’t think Evan personally moderates the forums. Other people do it these days.
But, they do it on his behalf? This policy of locking and shutting down discussions comes from somewhere. That person directly or indirectly is the person who “manages” the community, the person who sets the policies/tone around such things.
I personally have no idea, I am not active in the Elm community.
I’m not sure who sets the policy and how.
That’s a very interesting perspective, thanks.
I’ll add the perspective of someone who loved Elm and will never touch it again. We’re rewriting in PureScript right now :) I’m happy I learned Elm, it was a nice way of doing things while it lasted.
In Elm you may eventually hit a case where you can’t easily wrap your functionality in ports, the alternative to native modules. We did, many times. The response on the forum and other places is often to shut down your message, to give you a partial version of that functionality that isn’t quite what you need, to tell you to wait until that functionality is ready in Elm (a schedule that might be years!), or until recently to point you at native modules. This isn’t very nice. It’s actually very curious how nice the Elm community is unless you’re talking about this feature, in which case it feels pretty hostile. But that’s how open source rolls.
Look at the response to message linked in the story: “We recently used a custom element to replace a native modules dealing with inputs in production at NoRedInk. I can’t link to it because it’s in a proprietary code base but I’ll be writing an speaking about it over the next couple months.”
This is great! But I can’t wait months in the hope that someone will talk about a solution to a problem I have today. Never mind releasing one.
Many people did not see native modules as a shortcut or a secret internal API. They were an escape valve. You would hit something that was impossible without large efforts that would make you give up on Elm as not being viable. Then you would overcome the issues using native modules which many people in the community made clear was the only alternative. Now, after you invest effort you’re told that there’s actually no way to work around any of these issues without “doing them the right way” which turns out to be so complicated that companies keep them proprietary. :(
I feel like many people are negative about this change because it was part of how Elm was sold to people. “We’re not there yet, but here, if we’re falling short in any way you can rely on this thing. So keep using Elm.”
That being said, it feels like people are treating this like an apocalypse, probably because they got emotionally invested in something they like and they feel like it’s being changed in a way that excludes them.
You’re right though. Maybe in the long term this will help the language. Maybe it will not. Some people will enjoy the change because it does lead to a cleaner ecosystem and it will push people to develop libraries to round out missing functionality. In the short term, I have to get things done. The two perspectives often aren’t compatible.
I’m personally more worried about what will happen with the next major change where Elm decides to jettison part of its community. I don’t want to be around for that.
If people encouraged you to use native modules, then that was unfortunate.
I’m not sure I understand the issue with custom elements. Sure, they’re a bit complicated and half baked but it certainly doesn’t require a research lab to use them (in fact, I’ve just implemented one now).
I would agree, however, that the Elm developers have a bit of a hardline approach to backward compatibility. Perhaps there is a misunderstanding around the state of Elm - ie whether it’s still an experiment that can break compatibility or a stable system that shouldn’t.
I’m not sure how I feel about backward compatibility. As a user, it’s very convenient. As a developer, it’s so easy to drown in the resulting complexity.
I’ll go one further and say I’m quite glad those discussions get locked. Once the core team has made a decision, there’s no point in having angry developers fill the communication channels the community uses with unproductive venting. I like the decisions the core team is making, and if those threads didn’t get locked, I’d feel semi-obligated to respond and say that I’m in favor of the decision, or I’d feel guilty not supporting the core devs because I have other obligations. I’m glad I don’t have to wade through that stuff. FWIW, it seems like the community is really good at saying “We’re not going to re-hash this decision a million times, but if you create a thread about a specific problem you’re trying to solve, we’ll help you find an approach that works” and they follow through on that.
I don’t have a lot of sympathy for folks who are unhappy with the removal of the ability to compile packages that include direct JS bindings to the Elm runtime. For as long as I’ve been using Elm the messaging around that has consistently been that it’s not supported, it’s just an accidental side effect of how things are built, and you shouldn’t do it or you’re going to have a bad time. Now it’s broken and they’re having a bad time. This should not be a surprise. I also think it’s good decision to actively prohibit it. If people started using that approach widely, it would cause a lot of headaches for both the community and hamstring the core team’s ability to evolve the language.
and
Do you believe your perspective would change if you didn’t agree with the developers decisions? Obviously I have a different perspective but I am curious if think you would still have this perspective if you were on the other side?
Additionally, just because the core team has “made a decision” doesn’t mean it wasn’t a mistake, nor that it is permanent. Software projects make mistakes all the time, and sometimes the only way to really realize the mistake is the hear the howls of your users.
I’m pretty confident I wouldn’t change my position on this if I wasn’t in agreement with the core team’s choices. I might switch to PureScript or ReasonML, if I think the trade-offs are worth it, but I can’t see myself continuing to complain/vent after the decision has been made. I think appropriate user input is “I have this specific case, here’s what the code look like, here’s the specific challenge with any suggested alternative” If the core team decides to go another way after seeing their use cases, it’s clear we don’t have the same perspective on the trade-offs for those decisions. I can live with that. I don’t expect everybody to share my opinion on every single technical decision.
As an example, I use Clojure extensively at work, and I very much disagree with Rich Hickey’s opinions about type systems, but it’s pretty clear he’s thought through his position and random folks on the internet screaming differently isn’t going to change it, it’ll just make his job more difficult. I can’t imagine ever wanting to do that to someone.
It’s been my experience that the folks who can provide helpful feedback about mistaken technical decisions rarely howl. They can usually speak pretty clearly about how decisions impact their work and are able to move on when it’s clear there’s a fundamental difference in goals.
We fundamentally disagree on this point (and the value of the noisy new users), and I don’t think either of us is going to convince the other. So, I think this is a classic case of agree to disagree.
I think what bothers me the most about the core team’s approach to features is not that they keep removing them, but that for some they do not provide a valid alternative.
They’ll take away the current implementation of native modules, but coming up with a replacement is too hard, so even though the core libraries can use native code, us peasants will have to do without.
They won’t add a mechanism for higher rank polymorphism because coming up with a good way to do it is hard, so even though the base library has a few magic typeclasses for its convenience, us peasants will have to make do with mountains of almost duplicated code and maybe some code generation tool.
So where does that leave Elm right now? Should it be considered a production-ready tool just by virtue of not having very frequent releases? Or should it be regarded as an incomplete toy language, because of all the breaking changes between releases, all the things that haven’t been figured out yet, and how the response to requests for ways to do things that are necessary in real code is either “you don’t need that”, which I can live with most of the time, or “deal with it for the moment”, which is unacceptable.
I think Elm should make it more clear that it’s ostensibly an unfinished project.
I don’t think this is a fair characterization of the core team’s reasons for not supporting those features. I’ve read/watched/listened to a lot of the posts/videos/podcasts where Evan and other folks discuss these issues, and I don’t think I’ve ever heard anyone say “We can’t do it because it’s too difficult.” There’s almost always a pretty clear position about the trade-offs and motivations behind those decisions. You might not agree with those motivations, or weigh the trade-offs the same way, but it’s disingenuous to characterize them as “it’s too hard”
I exaggerate in my comment, but what I understood from the discussions around rank n polymorphism I’ve followed is basically that Evan doesn’t think any of the existing solutions fit Elm.
I understand that language design, especially involving more complex features like this, is a hard issue, and I’m sure Evan and the core team have thought long and hard about this and have good reasons for not having a good solution yet, but the problem remains that hard things are hard and in the meantime the compiler can take an escape hatch and the users cannot.
I always struggle with this line of questioning because “incomplete and broken” describes pretty much all of the web platform in the sense that whenever you do non-trivial things, you’re going to run into framework limitations, bugs, browser incompatibilities and so on.
All you can do is evaluate particular technologies in the context of your specific projects. For certain classes of problems, Elm works well and is indeed better than other options. For others, you’ll have to implement workarounds with various degrees of effort. But again, I can say the same thing for any language and framework.
Is it good that it’s so easy to bump up against bugs and limitations? No. But at least Elm is no worse than anything else.
Taking a tangent, the main problem is that Elm is being built on top of the horrifically complex and broken foundation that is the web platform. It’s mostly amazing to me that anything works at all.
To me the problem is that Elm is not conceptually complete. I listed those issues specifically because they’re both things that the compiler and the core libraries can do internally, but the users of the language cannot.
No, Elm is a language, and not being able to do things in a language with so few metaprogramming capabilities is a pretty big deal compared to a missing feature in a library or a framework, which can easily be added in your own code or worked around.
But how is this different from any other ecosystem? The compiler always has more freedom internally. There are always internal functions that platform APIs can use but your library cannot. Following your logic, we should condemn the Apple core APIs and Windows APIs too.
No, what I meant is that the core libraries use their “blessed” status to solve those problems only for themselves, thus recognizing that those problems effectively exist, but the users aren’t given any way to deal with them.
But there are actually solutions on offer: ports and custom elements. What’s wrong with using them?
Ports are very limiting and require much more work to set up than a normal library, and I haven’t used custom elements so I can’t speak for those.
There’s also no workaround for the lack of ad-hoc polymorphism. One of the complaints I hear the most about Elm is that writing json encoders and decoders is tedious and that they quickly become monstrously big and hard to maintain; often the json deserialization modules end up being the biggest modules in an Elm project.
This is clearly a feature the language needs (and already uses with some compiler magic, in the form of
comparable,appendable, and so on).Having worked with ClojureScript on the front-end for the past 3 years, I strongly disagree with this statement. My team has built a number of large applications using Reagent and whenever new versions of ClojureScript or Reagent come out all we’ve had to do was bump up the versions. We haven’t had to rewrite any code to accommodate the language or Reagent updates. My experience is that it’s perfectly possible to build robust and stable tools on top of the web platform despite its shortcomings.
I think the ease of upgrades is a different discussion. There is a tool called
elm-upgradewhich provides automated code modifications where possible. That’s pretty nice, I haven’t seen a lot of languages with similar assistance.My point was, you cannot escape the problems of the web platform when building web applications. Does ClojureScript fully insulate you from the web platform while providing all of its functionality? Do you never run into cross-browser issues? Do you never have to interoperate with JavaScript libraries? Genuinely asking - I don’t know anything about ClojureScript.
My experience is that vast majority of issues I had with the web platform went away when my team started using ClojureScript. We run into cross-browser issues now and then, but it’s not all that common since React and Google Closure do a good job handling cross-browser compatibility. Typically, most of the issues that we run into are CSS related.
We interoperate with Js libraries where it makes sense, however the interop is generally kept at the edges and wrapped into libraries providing idiomatic data driven APIs. For example, we have a widgets library that provides all kinds of controls like data pickers, charts, etc. The API for the library looks similar to this to our internal widgets API.
Sounds like a great development experience!
Let me clarify my thinking a bit. For a certain class of problems, Elm is like that as well. But it certainly has limitations - not a huge number of libraries etc.
However, I think that pretty much everything web related is like that - limitations are everywhere, and they’re much tighter than I’d like. For example, every time I needed to add a date picker, it was complicated, no matter the language/framework. But perhaps your widgets library has finally solved it - that would be cool!
So I researched Elm and got a feel for it’s limitations, and then I could apply it (or not) appropriately.
I would agree, however, that the Elm developers have a bit of a hardline approach to backward compatibility. Perhaps there is a misunderstanding around the state of Elm - ie whether it’s still an experiment that can break compatibility or a stable system that shouldn’t.
I’m not sure how I feel about backward compatibility. As a user, it’s very convenient. As a developer, it’s so easy to drown in the resulting complexity.
Yeah, I agree that the main question is around the state of Elm. If the message is that Elm isn’t finished, and don’t invest into it unless you’re prepared to invest time into keeping up, that’s perfectly fine. However, if people are being sold on a production ready language that just works there appears to be a bit of a disconnect there.
It’s obviously important to get things right up front, and if something turns out not to work well it’s better to change it before people get attached to it. On the other hand, if you’re a user of a platform then stability is really important. You’re trying to deliver a solution to your customers, and any breaking changes can become a serious cost to your business.
I also think it is important to be pragmatic when it comes to API design. The language should guide you to do things the intended way, but it also needs to accommodate you when you have to do something different. Interop is incredibly important for a young language that’s leveraging a large existing ecosystem, and removing the ability for people to use native modules in their own projects without an alternative is a bit bewildering to me.
I have the opposite experience. Team at day job has some large CLJS projects (also 2-3 years old) on Reagent and Re-Frame. We’re stuck on older versions because we can’t update without breaking things, and by nature of the language it’s hard to change things with much confidence that we aren’t also inadvertently breaking things.
These projects are also far more needlessly complex than their Elm equivalents, and also take far longer to compile so development is a real chore.
Could you explain what specifically breaks things in your project, or what makes it more complex than the Elm equivalent. Reagent API had no regressions in it that I’m aware of, and re-frame had a single breaking change where the original
reg-subwas renamed toreg-sub-rawin v 0.7 as I recall. I’m also baffled by your point regarding compiling. The way you develop ClojureScript is by having Figwheel or shadow-cljs running in the background and hotloading code as you change it. The changes are reflected instantly as you make them. Pretty much the only time you need to recompile the whole project is when you change dependencies. The projects we have at work are around 50K lines of ClojureScript on average, and we’ve not experienced the problems you’re describing.I was hoping to read other points of view on that matter, thanks for taking the time writing down yours!