At $3 Million, New Award Gives Medical Researchers a Dose of Celebrity - <AUTHOR> http://www.nytimes.com/2013/02/20/science/new-3-million-prizes-awarded-to-11-in-life-sciences.html?hp

<comment><USER2> I'm impressed and anything that promotes and furthers fundamental science gets a thumbs-up from me.

However, I do find the process a little odd. Specific things irk me like the ability to win multiple times and all winners also being on the selection committee. _"Dr. Levinson [CEO of Genentech], in consultation with his colleagues, helped Mr. Milner select the first Breakthrough winners. These winners will form a committee that will select future winners, Mr. Milner said,"_ I also dislike this [1], but I guess you have to start somewhere. The Nobel Committee's aren't without controversy [2]. The prize money seems unnecessarily large but that's an easy way to 'compete' for recognition with more established prizes. It also helps since more research is collaborative in nature so a split of the prize is still meaningful.

It'll be interesting to see whether these prizes succeed in putting science more in the public eye. I'm not convinced they will unless the foundations involved also do the extra work of marketing and promoting the winners (rather than marketing the prize itself, as this article does).

[1] I was a research scientist so this 'industry influence' in the selection process immediately rubbed me the wrong way (industry promoting it's own interests etc etc). Though those feelings may not be warranted in this case.

[2] <http://en.wikipedia.org/wiki/Nobel_Prize_controversies>

</comment><comment><USER3> In response to the comments about whether this would provide incentive to those that would practice science, I would argue that it's probably not the point. Rather, it rewards those who think big and encourages risk-taking, both qualities that are not necessarily associated with the biological sciences, where incremental success is the norm.

Quoting Milner: "With the mapping of the genome sequence there are expectations of significant progress in the next 10 or 20 years so I think the timing is really appropriate to create an incentive for the best scientific minds" [1]. In other words, with a timeframe of 10-20 years, you're talking about people already in science. To get up to this level in 10 years, you'd have to be pretty damn brilliant.

Personally, I look at this like some icing on an already delicious cake, and cements my commitment to a strategy to fill in some huge gaps in biological knowledge within the next 5-10 years.

[1] [http://www.guardian.co.uk/science/2013/feb/20/breakthrough-p...](http://www.guardian.co.uk/science/2013/feb/20/breakthrough- prize-silicon-valley-entrepreneurs)

</comment><comment><USER4> Academia has managed to function just fine without this prize for a long time. What's the sudden need for this, aren't academics supposed to be intrinsically motivated people, rather than extrinsically motivated? I've always disliked the Nobel prize as a concept too. Is this prize really going to cause anyone to become an academic? If not then its just rewarding persistence and good luck, which just re-enforces the staus quo.

<comment><USER5> I don't think Milner is trying to motivate scientists, I think he is trying to see what happens when they get a break from writing grants (which is pretty contrary to enforcing the status quo).

The people getting these certainly have more flexibility to work on blue sky projects.

<comment><USER6> Or he wants to encourage more people to work on immortality research.

</comment></comment></comment><comment><USER7> Do awards like this lead to more research being done? It's easy to throw large sums of money at problems, it's harder to hand out lot's of smaller amounts. I suspect that if this money was awarded as smaller grants to many researchers it would have a much bigger impact.

</comment><comment><USER8> Wonder if this will help incentive invention, in the same way that prize money for security vulnerability incentive security researchers to vulnerabilities in software.</comment>


The western U.S. is locked in the grips of the first human-caused megadrought - <AUTHOR> https://www.washingtonpost.com/weather/2020/04/16/southwest-megadrought-climate-change/ <comment><USER2> Source: [https://science.sciencemag.org/content/368/6488/314](https://science.sciencemag.org/content/368/6488/314)

</comment><comment><USER2> Whats the word on desalinization? How expensive would it be; how much water can it produce? Anyone here in the field?

<comment><USER3> Desal is not only energy intensive but generates a problem of what to do with the resulting increased-salinity brine which is toxic to the draw area. And your plant has to be designed to handle corrosive source and effluviant.

Likely it will ultimately needed but we are a long way from it being viable at scale.

[https://en.wikipedia.org/wiki/Desalination#Considerations_an...](https://en.wikipedia.org/wiki/Desalination#Considerations_and_criticism)

</comment></comment><comment><USER4> From the article: Humans "Contributed", Not caused.

Agenda much here on HN?

<comment><USER5> _Anthropogenic trends in temperature, relative humidity, and precipitation estimated from 31 climate models account for 47% (model interquartiles of 35 to 105%) of the 2000–2018 drought severity, pushing an otherwise moderate drought onto a trajectory comparable to the worst SWNA megadroughts since 800 CE._

From the abstract. If I'm reading this correctly, the contribution itself is what tipped us over into mega drought territory.</comment></comment>


Agile Usability Engineering - <AUTHOR> http://www.interaction-design.org/encyclopedia/agile_usability_engineering.html <comment><USER2> I got excited by the name, but the details are disappointing.

"In their opinion, iterative rapid prototyping is like trial-and-error design and may never lead to an optimal solution if too many stakeholders are involved and too many opinions influence the design process. Instead, their usage-centered design approach is based upon abstract models to describe users, tasks and content."

Yikes! Supposing that rapid prototyping fails because of too many "stakeholders" and "opinions" misses the point. The role of a designer is to manage the process which leads to a design. If a designer doesn't sufficiently manage input, ANY process will fail.

Abstracting the user, tasks, etc, is all well and good for providing a stable platform for design, but it turns the iterative design process into a waterfall process. It smacks of designer equivalent of "Why does the spec keep changing?"

It also says that this allows the designer to design for tasks, not expectation. However how can you be sure your design fits the task without trialling it?</comment>


Elixir web development 101: collaborative todolist with realtime updates - <AUTHOR> https://blog.openbloc.fr/elixir-phoenix-web-development-101-todo-app/ <comment><USER2> I'm so excited about Elixir these days. I would love to see more cookbook examples of using Elixir but NOT as a Ruby/Rails replacement.

While the concept is not new to me, I have recently become totally infatuated with the concept of green threads, actor models, etc... for dealing with concurrent processing. This is literally what Erlang was designed to do, and Elixir makes it user friendly.

The real beauty of Elixir/Erlang is being able to run hundreds of thousands of concurrent "threads" (co-operative in userspace, not OS-level).

Anyway I do not mean to detract from the post here -- just feel like a todo list is not a shining-star example of Elixir and would love to see some more hackers post their concurrency work here.

<comment><USER3> >I would love to see more cookbook examples of using Elixir but NOT as a Ruby/Rails replacement.

I would love to see more examples that get away from web dev with Elixir. While it's great with the Phoenix framework there is so much more to Elixir than that. Trying to deploy an elixir daemon has been a pain and I haven't found much around that. There is escript and distillery and while I haven't tried distillery for non-phoenix apps, escript works but deploying is still a pain.

<comment><USER4> Hey, I've went through the "trouble" of using continuous deployment with elixir and distillery.

Since the project I'm working on is open source, you can see how I've done it. It's still far from perfect but maybe it could be a place to start.

Elixir app is on [https://github.com/hackerexperience/helix](https://github.com/hackerexperience/helix). You'd probably be interested on `lib/release.ex` and `rel/`.

For the ci, our infrastructure playbooks are at [https://github.com/hackerexperience/infrastructure](https://github.com/hackerexperience/infrastructure), and you probably want to look at `roles/{helix, erlang, elixir}`.

Hit me up if you have questions our would like to discuss further. Email is on profile.

Btw, here's a great presentation about the topic: [https://youtube.com/watch?v=H686MDn4Lo8](https://youtube.com/watch?v=H686MDn4Lo8)

<comment><USER3> Thanks for this, I'll take a look and definitely hit you up if I have questions.

</comment></comment></comment></comment><comment><USER5> > channel.on('update:todo' ...

> channel.push('delete:todo' ...

> Have a CRUD interface over websocket

REST over websockets. What's the advantage over HTTP? I know websockets allow for pushing data to clients, but this is pull so apparently there should be no advantage, only more code to write.

Edit: maybe you're sharing updates among all the users connected to the server. Still, for sending requests HTTP is enough. Any performance advantage by using websockets?

<comment><USER6> This is interesting when you want near realtime performances, as you don't have all the culprint of a http request : you basically just send a few octets (a json document, or even just a simple value), and you don't have to build a request and negotiate a connection.

This is not something obvious because we have helpers to make http requests, but there are many things going on while issuing a http request (building headers, encoding body, etc) [1]. A socket (be it a websocket or a classic socket) has this advantage that all the negotiating part is already done and you just have to send the message, in whatever format you want. Decoding the request on server side is way easier too.

[1] [https://en.wikipedia.org/wiki/Hypertext_Transfer_Protocol#Me...](https://en.wikipedia.org/wiki/Hypertext_Transfer_Protocol#Message_format)

<comment><USER7> I've been out of front-line web development for a while. Are Websockets supported widely enough that a developer can reasonably assume they are available and not have to worry about workarounds such as comet/long polling?

<comment><USER8> Yes, I would say they're an expected browser feature these days, with over 94% global browser availability [0] (basically anything >= IE10).

The cool thing about Phoenix specifically is that they provide a JS client to integrate with a Phoenix Channels [1] backend that will automatically fail- over to long-polling if window.WebSocket is not available [2]. These Phoenix Channels are set up to be transport agnostic, so you don't have to write any special backend or client code to handle one way or the other, it "just works" for the most part.

[0] [https://caniuse.com/#search=Websockets](https://caniuse.com/#search=Websockets)

[1] [https://hexdocs.pm/phoenix/channels.html](https://hexdocs.pm/phoenix/channels.html)

[2] [https://github.com/phoenixframework/phoenix/blob/master/asse...](https://github.com/phoenixframework/phoenix/blob/master/assets/js/phoenix.js#L693)

</comment></comment></comment></comment><comment><USER9> Non-representative anecdote : i've recently heard of two teams that started using elixir, they both came from a ruby background, and in both case they weren't using OTP.

They both justified using elixir because it was "closer to ruby" (???), and they both seemed to live a pretty difficult time with that language. Which makes me wonder : why would you ever want to use such a special language (purely functional isn't for everyone) if you don't have any scalability issue, and don't even use OTP ?

<comment><USER10> I've seen a few (as in 2 ;) ) examples of this myself. And this is what "scares" me the most for elixir's future/potential. I think it's a great language/tech but ruby enthusiasts rushing into it thinking that it's "just like ruby but faster" may have a very bad influence on where the language goes. They may bring a lot of ruby best practices that don't transpose at all in elixir/erlang world.

<comment><USER9> That was indeed my underlying point. I see elixir more as "erlang with easier syntax", than "ruby with a more powerful runtime".

aka : you should get to understand erlang design decisions prior to jumping into the tech. Which probably means having more experience than building the typical low load website made with RoR.

<comment><USER5> I'm in the fourth month of a Phoenix project, which shields me from almost all of OTP, and I agree with your point. Maybe even "Erlang with a Ruby syntax" would be too much. Similarities with Ruby don't go any further than "def" "do" "end" and many library modules and functions deliberately named to mimic corresponding modules and methods in Ruby. Everything else is different, both syntax and semantic.

After 10 years of Rails, all things considered Elixir and Phoenix are pretty good.

The best feature of the language so far is pattern matching. It can be used in the arguments of function definitions. It makes all the "if"s go away. It seems strange after 30 years of programming, but a program without conditionals is easier to read.

Not having to use an external background job framework is great news too. Just spawn your processes to send a mail, process something asynchronously and store the result in the database. No Sidekiq (or Celery if you're into Python.)

On the awful side, Ecto is too low level and it feels like a self inflicted pain. I understand the reasons behind its design decisions, but the typical web application or mobile backend don't need all of that. Actually the team working with me on this project wrote a lot of code to build queries and wrap them into another layer to return {:ok, result} / {:error, reason} tuples. We're calling them from controllers more or less as Model.get_something(args). I checked it now and we have zero occurrences of " from " in controller code. All the queries are confined inside a model. If we were using Rails ActiveRecord would have written all that code for us. Instead we had to use a more verbose query syntax, write our functions and tests. This is a net loss of productivity.

There are some modules that can be mounted on the top of Ecto to make it look like ActiveRecord or other ORMs for other languages. I'm looking forward to using Ecto.Rut in my next project. I hope I'll never have to use Ecto directly.

[https://github.com/sheharyarn/ecto_rut](https://github.com/sheharyarn/ecto_rut)

We almost didn't use the supervisor layer of the language (somewhat like systemd/init for who's not familiar with it.) I used it in smaller projects and I feel like it's a little too complicated. Same for defining a GenServer, more complex and verbose than exposing the same functionality with methods from a object. I know we have to split the code between what runs in the client process and what runs on the server process, but I feel there should be a vanilla GenServer that handles the most straightfoward case inside the behavior, which is no code in the client with the exception of passing the arguments to the server. Maybe use the name, sigils or module attributes to declare if there will be a synchronous return value.

Anyway, Elixir is still young and there is time to smooth the rough edges. So far it's an acceptable contender and definitely better than the popular scripting languages when concurrency is important.

<comment><USER11> Don't take this the wrong way, but it sounds like you're approaching this from the perspective that Rails' way is the "correct" way when in fact almost everything about Rails' doctrine will cause you problems over the life of a project.

> We're calling them from controllers more or less as > Model.get_something(args). I checked it now and we have zero occurrences of > " from " in controller code. All the queries are confined inside a model.

Yeah, that's almost a best practice, except you're regarding the "model" (the terminology is 'schema' in Ecto) as primary instead of building it as a separate context or application (depending on your preferred approach to modularity within Elixir/Phoenix). For that matter, I fail to see the advantages of `Model.get` over `Model |> Repo.get(id)`.

> If we were using Rails ActiveRecord would have written all that code for us.

There's not a substantial difference between the kind of AR usage that's on the happy path and the equivalent query in Ecto.

> I know we have to split the code between what runs in the client process and > what runs on the server process, but I feel there should be a vanilla > GenServer that handles the most straightfoward case inside the behavior, > which is no code in the client with the exception of passing the arguments > to the server

You mean like an Agent[1]?

[1] [https://hexdocs.pm/elixir/Agent.html](https://hexdocs.pm/elixir/Agent.html)

<comment><USER5> First of all thanks for the detailed answer. It contains many interesting points.

I don't think that AR is correct, I think that AR is more convenient than Ecto in many cases we run into in web development. With AR I don't have to write my own queries and encapsulate them into functions (but it's kind of what we do with scopes) and it has a more compact syntax. Ecto is more flexible, but that flexibility is not needed in most cases. Anyway when we must really be flexible we write queries in SQL and manually unmarshal resultsets. ORMs/Data Mappers are for simple and medium use cases.

I still didn't run into problems with the AR approach. Maybe it's because all of my projects were medium or small sized. I found AR to be perfect for them to the point that I want to disguise Ecto as AR using Ecto.Rut.

> you're regarding the "model" (the terminology is 'schema' in Ecto) as > primary instead of building it as a separate context or application

This sounds interesting but I fail to understand what you mean. Would you mind explaining or posting a link? Thanks.

> I fail to see the advantages of `Model.get` over `Model |> Repo.get(id)`

It's shorter but not by much. One reason is that Repo doesn't mean much to me, so it could be hidden. What I care about is Model. But getting values out of the db is not such a pain. Inserting and updating is, because they are more verbose. I quote Ecto.Rut for the insert

        Post.insert(title: "Awesome Post", slug: "awesome-post", category_id: 3)
        # instead of:
        # changeset = Post.changeset(%Post{}, %{title: "Awesome Post", slug: "awesome-post", category_id: 3})
        # YourApp.Repo.insert(changeset)

If all of those extra characters are for extra flexibility (maybe for using more repositories in future?) then it smells of premature optimization. I'll happily do without it.

Regardless of this discussion, IMHO a thing that Ecto should fix is requiring developers to write both the migration and the schema. It's either the AR way, migration first and auto generated model, or the Python way, model first and auto generated migration. We got some bugs because we didn't write the same things inside the migration and the schema. Mistakes happens and the tools we use should help us not the make them. Ecto is not DRY but it should.

Btw, the compactness argument applies more or less to all of Ruby vs Elixir because of the object.oriented.notation.is.shorter than the Module1.functional |> Module2.way |> Module3.of |> Module4.composing. Aliases help to some degree but they add clutter to the top of the file. It's a little nuisance but pattern matching more than evens it.

I have to look more into Agent (thanks) but it seems exactly the opposite of what I want: write in the module only the code that should run in the server. Probably what I'm looking for is a macro that writes a vanilla GenServer for me hiding all the functions run on the client.

<comment><USER11> I think I came off snarkier than I intended to above, thank you for reading that gracefully.

> I still didn't run into problems with the AR approach. Maybe it's because > all of my projects were medium or small sized. I found AR to be perfect for > them to the point that I want to disguise Ecto as AR using Ecto.Rut.

Perhaps its a stylistic thing, but recent versions of Ecto feel quite natural to me. I frequently use Ecto _without_ a database by using it for embedded schemas (which I don't embed)—they're basically just structs that I can use with changesets a little more cleanly.

As someone else noted, you don't have to use changesets for the happy path interactions like simple inserts. It really just comes down to whether you can live with the Repo as the first thing you type instead of the schema.

> This sounds interesting but I fail to understand what you mean. Would you > mind explaining or posting a link? Thanks.

Rails teaches us to look at the model as the primary point of business logic. In my view this is putting the cart before the horse. By putting the Model (big M, not little m) we limit our thinking around abstractions to what we can represent structurally in the database. A well-designed, thought-out application model (little m, not big M) encompasses much more than database tables. With AR, even if you try to create behaviors on fat models, ultimately the only vocabulary you have to work with are those nouns the database allows you.

Ecto does something subtle but important: it demotes your data schema to just that—data. Behavior is modelled in the messages you pass between processes, which is why you see so many people in the elixir community jumping into architectural techniques like eventsourcing. While things like Ecto.Rut add some conveniences, they also encourage promotion of the data to the central artifact of the system. After building Rails applications from small to very large over 10 years, I can say for my part I want to stay as far away from that as possible. Its convenient until its not, and when you can start to feel the pain of it, its very difficult to unwind its effects throughout your system.

re: agents, maybe what you're looking for is ExActor: [https://github.com/sasa1977/exactor](https://github.com/sasa1977/exactor)

Worth noting, especially if you're in the first 12-18 months of using Elixir: OTP is incredible, but it takes time to wrap your head around all its pieces. I usually recommend new users coming from an MVC framework just try to muddle along using Phoenix as they would Rails until they start getting comfortable with things like supervision trees and GenServers... and then the fun really starts. All the rest of it, like Ecto's hands-off approach to the database, really starts to make sense around that time.

<comment><USER5> ExActor is more or less what I was looking for. It deserves its 491 stars (492 now.) A big thanks for that!

After so many years of software development I don't like unnecessary complexity, that's why I'm keen to shave off features from Ecto and GenServer (and a lot of other tools, not only in Elixir) and settle for a subset with an easier API.

That said, you have a point when you write that AR's approach is "convenient until its not, and when you can start to feel the pain of it, its very difficult to unwind its effects". The project I'm working on is an MVP. Who knows where my customer is going to be in 12 month. What I know for sure is that using Ecto cost them some extra time to deliver because of all that boilerplate we had to write. Would I add an extra layer between the db and the logic in a Rails application if its requirements imply complicated logic and interactions? Probably yes. We can put any kind of objects in the models (or lib) directory of Rails, not only ones derived from AR.

<comment><USER11> I think I'm still left with the impression that you may be making things a little harder on yourself than they need to be, or perhaps better stated, than they need to be _now_... Ecto's API has gotten streamlined over the last few versions, such that in most common operations, I can't see much more than a cursory cosmetic difference in the APIs, like starting the call chain from the Repo instead of the Schema. What I will readily concede is more complicated is the support for things that are widely considered to be antipatterns, like STI and polymorphic associations.

> After so many years of software development I don't like unnecessary > complexity, that's why I'm keen to shave off features from Ecto and > GenServer (and a lot of other tools, not only in Elixir) and settle for a > subset with an easier API.

This is what I'm missing—there's essential and accidental complexity, and when I look at GenServer, I see an API that's been shaved down by decades of practice in Erlang to its most essential complexity. Even ExActor is just a set of macros for generating those essential parts—it basically just saves on typing, not skipping functionality. Ecto hasn't had the years of legacy that OTP has, so its API has fluxed a bit in the last few years, but its still something I think is cut down to the bare minimum for healthy database interaction.

This kind of discussion is best handled by email, i think, and mine is in my profile—feel free to send a gist of something that illustrates what you're talking about, and maybe I'll have a better understanding of what aspects of the API are headaches. I'm really curious what I'm missing about your perspective here.

</comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER12> If you're doing development with a web socket layer, it's entirely worth it to try out Phoenix Channels before you commit to another stack. It makes your life so much easier.

There are a lot of other great reasons to use Elixir though.

<comment><USER13> Phoenix Channels feels like cheating because it's just so intuitive and you get so much performance straight out of the box. It's obscene! Maybe I'm used to Ruby perf that this blew me away so much.

On free tier heroku dyno and the $7 postgres hobby dev, performance was around 27,000 messages sent per second before POSTGRES started complaining. It wasn't even the app itself that was complaining, it was postgres. This was sent via websocket using phoenix channels and persisted to the database.

If you're a backend guy, add this tool to your repertoire - you'll become a wizard and just have tighter code with less headaches.

</comment></comment><comment><USER14> I really like absinthe with apollo/subscripions on the frontend for realtime updates.

</comment><comment><USER15> OT, but what software did you use to make those gifs on Ubuntu?

<comment><AUTHOR> Hi, I used gtk-recordmydesktop (beware it will freeze your desktop under Ubuntu 17.10 Gnome but works fine under Unity). It gives you an .ogv file and then there's some editing to get a gif. I described the process at the end of: [https://blog.openbloc.fr/javascript-es2015-starter- kit/](https://blog.openbloc.fr/javascript-es2015-starter-kit/)

Mainly convert the .ogv to .mp4 with ffmpeg (don't have the command here), create a png palette from the video so your gif colors are more accurate and use ffmpeg to create the gif:

        ffmpeg -y -i video.mp4 -vf fps=10,scale=800:-1:flags=lanczos,palettegen palette.png
        ffmpeg -i video.mp4 -i palette.png -filter_complex 'fps=1,scale=800:-1:flags=lanczos,setpts=0.25*PTS[x];[x][1:v]paletteuse' todoApp.gif

This gives you a 800px wide gif, with 1FPS, and sped up 4 times (setpts=0.25) :)

<comment><USER16> Why make a gif from this rather than a webm (seeing as you obviously know what you're doing with ffmpeg)?

<comment><USER17> What does webm support look like these days? Last I checked neither Safari nor IE had webm support.

</comment></comment></comment></comment><comment><USER18> Elixir is pure pleasure. Coming from a ruby background, I din't have huge difficulty in understanding the syntax, and unlike other functional languages like Clojure, it's not an abrupt change from procedural paradigm. You can still assign variables in functions etc.

<comment><USER19> Elixir should absolutely be an abrupt change from the procedural paradigm, and much closer conceptually to Clojure than Ruby.

In Clojure you can still stick something in an atom or volatile and easily update it in place... doing that is a lot more involved in Elixir.

</comment></comment><comment><USER20> How would you compare this with the same app done in Clojure? How would development and result be different?

</comment><comment><USER21> I think as the tooling /IDE support for Elixir improves, so will adoption.

</comment><comment><USER22> I really like absinthe with apollo/subscripions on the frontend for realtime updates.

</comment><comment><USER22> Does it generate real-time performances and analytics?

</comment><comment><USER23> Elixir Deez Nutz</comment>


Trying to recreate one aspect of Y Combinator - <AUTHOR>

I'm fascinated about one aspect of Y Combinator - and curious if it is replicable.
Could you quantify the most meaningful motivations that help you build your companies during the week between YC dinners at YC HQ? Specifically, what drives you regarding peer review?
Paul Graham has written that one of the more amazing aspects of YC is the peer conversations that occur during the weekly dinner. Per Mr Graham, companies often "show off" progress made since the last dinner. This mechanism of friendly competition and perhaps accountability seems to drive dedicated company building in a constructive way.
While I'm certain that office hours with YC staff is just as important, that is difficult to duplicate for obvious reasons.
But - assuming that the odds are correct and we don't get into YC - I'm very curious about replicating this aspect of peer review and accountability.
We're planning on getting together with a few other pre-revenue startups that are trying to figure out problem-solution and product-market fit in their space - which is kind of where we are as well.
For lack of a better description, we're trying to form an accountability group - to give us the drive to hit our weekly milestones, and discuss problems encountered for missing milestones. Perhaps, prospectively over time such a group, as they all become familiar with one another, could offer meaningful trouble-shooting with knowledge of intimate details that are time and phase aware of your company's state.
This is perhaps the one thing I'm most jealous of YC companies that are actively in the program. I'd love to somehow recreate this. Access to amazing mentorship is certainly a close second.
My initial guesses on things that matter:
1. Companies should be in similar phases for all participants to get equal value - using "lean" startup lexicon, an example might be companies that are trying to figure out "product-market" fit.
2. Meeting face to face on a regular basis.
3. Are YC companies "showing off" to each other in cliques - meaning... is there greater value in us keeping our peer-review/ accountability meetup to just a few companies? If it is indeed clique dependent, what would you say is the optimal number?
Are there other things that aren't as obvious or intuitive? Am I dead wrong on some of the assumptions?
I'm hoping to start experimenting - any insight would be extremely helpful. For some reason if we can't get in YC, then I'm hoping something like this can help us a bit.
Thanks in advance.
Cheers,
Subbu <comment><USER2> 2\. Face to face only works in areas with high startup density. Not sure if it really matters?

<comment><AUTHOR> Hi Peter - I think you're right, and that's another plus for YC. Getting a class together of 40+ startups, you're bound to meet like-minded startups to form your "peer-review" clique (if that's what happens).

In Chicago, we've experienced difficulty in finding other startups who would be interested in forming an accountability group with us, just because our location isn't really "startup rich" (compared to NYC or the Bay Area).

I think once you've found your group, then you should be set, of course, assuming all participants buy the concept.</comment></comment>


Feds Want to Subject Every Burning Man Attendee to a Warrantless Drug Search - <AUTHOR> https://reason.com/2019/06/14/the-feds-want-to-subject-every-burning-man-attendee-to-a-warrantless-drug-search/ <comment><USER2> It's totally not fun when the landowner gets to impose rules on the land they own.

Whether the landowner (feds) in this case _should_ own so much land west of the Mississippi is a whole other thing. A strong argument can be made that the over ownership of land by the feds is completely unfair and likely unconstitutional.

<comment><AUTHOR> Ownership of significant portions of Western States (close to 85% in the case of Nevada [0]) has long been a complaint but is unequivocally constitutional inasmuch as many of the Western states were created from Federal land and the Constitution explicitly grants the Federal Government the right to regulate and dispose of the land as it sees fit. Also, a positive aspect to Federal land ownership is the creation of massive National Parks in many of the states where the Federal Government is a significant land owner. Such parks would have been unlikely if ownership of the land had been vested in the states themselves which traditionally have lobbied to have the land deployed more "productively" (agriculture, mining, etc). This is an ongoing issue in such places as Utah where local state officials have lobbied, and succeeded, in having the the size of Federal lands reduced.

[0] [https://www.vox.com/2015/2/16/8046349/federal-government- lan...](https://www.vox.com/2015/2/16/8046349/federal-government-lan..).</comment></comment>


Ask HN: Should Hacker News change the 80 character limit? - <AUTHOR> I feel like the 80 character limit is too limiting.<p>How do  you guys feel about that? <comment><USER2> What 80 character limit?

The textarea entry, for example, is 60 cols and 6 rows, but it's also resizeable (at least in Firefox) to much larger.

<comment><USER3> Titles are 80 characters, I believe.

<comment><USER2> Ahh. Then no, I don't feel it's limiting.</comment></comment></comment>


Larry Wall has approved renaming Perl 6 to Raku - <AUTHOR> https://github.com/perl6/problem-solving/pull/89 <comment><USER2> From what I could tell, Raku appears to be from Rakudo, the Perl 6 compiler, which is a shortened form of rakuda-dou (="way of the camel" in Japanese). Rakudo also means "paradise". The "raku" from "way of the camel" means "camel", while the "raku" from "paradise" means "fun" or "enjoyable" (or "music").

Incidentally, it also happens to sound similar to "roku" (="six").

<comment><USER3> So as a Japanese speaker, I don't think I ever would have made the 'raku' == 'rakuda' camel connection.

Also, while 'raku' is the reading for 楽, which connotes easy, simple and other good things, it is also the reading for a bunch of other characters--namely, 落, which means or carries the connotation of falling, declining or otherwise missing the mark.

When I see the 'raku' transliteration in the context of Perl, I think of 落. Not sure if that says something about my subconscious perception of Perl or not, but I can't help but think 'Raku' is a bad choice for the name of a language mired in indecision and falling from public favor.

On another note, I find the inclination of tech projects towards poorly translated Japanese words amusing. It nicely compliments the phenomena you see in the use of random English words for the naming of Japanese cars, condo buildings, and other 'prestigious' products. So if you find that ridiculous, you should find these 'Japanese' technology names ridiculous as well.

<comment><USER4> Raku isnt falling from public favor, it hasn't made it yet. It's an entirely different language to Perl 5. Like the difference between C and C# or Java.

<comment><USER3> Yea, sorry I'm not super familiar with the project, but that is the general vibe I get about Perl.

Interestingly enough 落(raku) also has the connotation of failure or missing the target, so not very auspicious in the context of a new language either!

<comment><USER5> _> that is the general vibe I get about Perl._

Perl <=5 _did_ make it, it was quite big in the 90s and early 2000s.

</comment></comment></comment></comment></comment><comment><USER6> Naming matters. Nim changing from "Nimrod" matters. Cockroachdb's name is offputting. Perl 6's name has caused endless confusion and by itself sabotaged both Perl 5 and Perl 6. Perl 6 has interesting ideas but I don't even want to touch it because its naming issue is so toxic. I'm glad they're going to rename it.

<comment><USER7> Is there a TLDR on what's wrong with the name "Perl 6" for those of us who have zero context?

<comment><USER8> I believe the issue was that Perl 6 had too many changes that made it hard to convert apps from earlier version.

That created some kind of limbo where people weren't sure if they should use perl 5 or perl 6 ("why develop in perl 5, when it is probably a dead end and perl 6 is the future" and at the same time "why should I convert to perl 6, what if it will be a failure and I wasted my time?")

By renaming it, it revives Perl 5 so developent can continue, and at the same time Perl 6 is presented as a new language, now whichever wins will be based on its merit.

<comment><USER9> Also, importantly, reflecting that they are in no more competition than Perl and Ruby are.

</comment></comment></comment></comment><comment><USER10> Kudos for making this change! This is what the folks at Microsoft should have done when ASP became ASP.NET and ASP.NET became ASP.NET Core. I know... keeping the root of the name the same makes management think the technology is fundamentally the same (and, therefore, cheaper) but the SEO confusion trying to find the right version of an answer is a PITA.

Secondarily, while Perl has never appealed to me I am more likely to admit I'm checking out Raku because the chances that someone will ask me to look at and debug their cousin's friend's manager's Perl 3 CGI app is considerably reduced.

<comment><USER11> > Kudos for making this change!

Rakudos, even!

</comment></comment><comment><USER12> I'm amazed that Perl is still around. I personally find it the least readable language that I've ever used, and that includes a lot of languages. But some people really seem to love it, for reasons a bit beyond me.

<comment><USER13> How familiar are you with Perl, and how much have you used it?

Most of the anti-Perl comments I've heard have been from people who really didn't know it very well, if at all.

Some of them might have glanced at some Perl code and saw a dense regex and dismissed it as "line noise". Well, yeah, if you don't know regexes you would be forgiven for thinking it was line noise, but if you did know regexes it should look no more like line noise than a similarly dense regex in any other language.

For a long time now, Perl has allowed regexes to be commented. Commenting dense regexes and splitting them up in to short regexes assigned to judiciously named variables is just good style in any language, and has been the norm in Perl for a long time. Furthermore, modern Perl style guidelines advise code to be written with verbose, English words instead of ancient Perl one-character special variable names.

So setting aside both dense, uncommented regexes and ancient single-letter special variable names, both of which have been recognized as poor style in Perl for decades now, I'm really not sure what the complaints about Perl readability are about. To me it looks really no uglier than any other mainstream language, and one could easily make the argument that any other mainstream language you care to name is uglier in some of its own ways.

If you include non-mainstream languages, some languages which have a lot of fans here on HN are arguably a lot less readable than Perl to someone only familiar with traditional Algol-style languages. In particular, I'm thinking of Forth and Haskell. Yet you rarely hear complaints on here about their readability.

<comment><USER14> >How familiar are you with Perl, and how much have you used it?

It's what my company's entire code base is written in. So every hour of every work day for the past 6 months.

>To me it looks really no uglier than any other mainstream language, and one could easily make the argument that any other mainstream language you care to name is uglier in some of its own ways.

It's no one thing, but a bunch of little things that compound on top of each other. Until you get something like this:

while (<>) { ($h{$_}++ == 1) && push (@outputarray, $_); };

Mostly though it's how it's used. It can technically do anything, so a lot of the times it is asked to do everything. Until one day you wake up to find you have hundreds of perl files, all tens of thousands of lines long, that all interconnect in an insane Object Oriented hierarchy soup stretching across every conceivable programming space - from database control to money processing to security to web site design.

<comment><USER15> > while (<>) { ($h{$_}++ == 1) && push (@outputarray, $_); };

That's a business culture thing. If you set the expectation, that it's okay to do that, people might do that. If you set the expectation that it's not okay, people shouldn't.

The equivalent C and Python are likely just as ugly (given that the equivalent python might be using a far too complex range statement or put it on a single line using : and ;, which is possible...).

That said, as bad code goes, that's not really that bad. The only non-standard things are <> and $_, and if you don't know what those are, you really haven't done the minimum of learning about the language (<> might be somewhat exotic in that form depending on the codebase, but $_ is not something you can get way with not knowing about). In all, the major problem with it is that it's not commented and uses poor variable names, which is something every language needs to deal with. I would write it like so if I wanted it on a single line (but I would probably use 2-3 lines):

        # Report each duplicated line once
        my (%lineseen,@linedups); # This was required in yours too right? I assume you're using strict...
        while (<>) { (++$lineseen{$_}==2) && push(@linedups, $_); };

But I would likely opt for the following if doing it myself:

        # Report duplicate lines once
        my %lineseen;
        my @linedups = grep { ++$lineseen{$_}==2 } (<>);

Assuming I was using <>, which I generally don't since File::Slurp is usually available and clearer.

<comment><USER16> There's always <STDIN> if <> is too cryptic. I think what most fail to grok, if they've only glanced at Perl, is context. Above all Perl is a context-based language. It's the opposite of Python's spell-everything-out approach but just as valid. Perl also excels at whipupitude.

<comment><USER15> Except that <> isn't just <STDIN>, it reads from each line of each file specified as an argument on the command line _or_ STDIN if no files were specified. This dual use (and magical-ness) is why I shy away from it in actual programs (but it is useful for one liners, which is why it does this), as it can be confusing.

Some people will look at this as evidence that Perl should be relegated to one-liners, but I find _immense_ usefulness in combining my more engineered aspects with one-liners, and providing myself with a "project evaluator". What I do is create a simple bash script which just calls perl and sets the library include path to the project lib, includes a few useful things to always have (Path::Tiny, Try::Tiny, Data::Dumper, etc), and passed the rest of the args to Perl. Using DBIx::Class for SQL manipulation and/or using complex API client libraries I've written _combined with_ the abilities of perl to do things easily as a one-liner is _amazing_.

</comment></comment></comment></comment></comment></comment><comment><USER17> This is great news both for Perl and for Raku. I will probably bother to take a serious look at Raku now, sometime, if anything just for curiosity. Why not before? I have no good answer for that.

But my main worry about it is that I suspect it has brought along with it the community's dysfunctional fascination with over-the-top cleverness and arcane constructs. I'll probably stick with Python and Perl 5 on an as-needed basis, but Raku will be fun to look in on for brain stimulation.

My best case hope is maybe it's clarified some things! Like having an agreed on best practice for how objects are implemented, that would be nice.

<comment><USER18> Why not before? Because Perl is you know, dead. Jokes aside, it's a pretty nice language apart from the !$double .@sigils. If I'd switch from Perl 5, I'd probably switch to Ruby, as Perl 6 oops Raku is quite slow.

<comment><USER19> Ruby is also quite slow. The last benchmarks I saw makes it pretty clear Raku has closed the gap with Ruby (at least the mainline C implementation of Ruby) on a lot of fronts, and is likely to be faster for many things in another year or two and the VM gets better at optimization. My google fu isn't up to finding those benchmark results now, but it's no secret that Ruby is pretty sluggish compared to Perl 5.

<comment><USER18> I sure hope it will be faster because in my own tests it's slower than Tcl. And I've tested at least two releases a year since october 2016 when the stable Rakudo came out.

Ruby 2.5 has a _jit_ which uses the C compiler to generate dynamically linked objects. It looks more like a workaround but it produces fast code. Then there's Jruby, Rubinius, Truffle, mruby. Crystal too, which is a different language but yet similar. No need to learn Go. Just take your Ruby background and pretty much start using it for writing Crystal.

<comment><USER20> The CRuby 2.6 JIT using gcc or clang improves some benchmarks but makes real applications slower, sadly.

Thankfully JRuby already has a functioning JIT and TruffleRuby is getting very close to a 1.0 release.

</comment></comment></comment></comment></comment><comment><USER21> I really wish the Perl 6 -> Raku change could let it catch up with other languages such as Python.

Edit: sorry for the confusion. I meant popularity-wise. I wish the change would clarify to people that Perl 6 and Perl 5 are basically two different languages and people should at least consider Perl 6 as an option when they start a new project.

<comment><USER22> Assuming you mean rename the next version of a programming language — I think that's a horrible idea. The entire point of continuing with the previous name is that eventually the community will move onto the new language. I'm guessing Perl 6 made too many incompatible changes from Perl 5 though I don't know much about them.

<comment><USER23> Perl 6 started out as a plan for the next version of Perl.

Over the _years_ (announced in 2000, delivered in 2015) it evolved into a distinct language.

In the meantime, Perl5 suffered from the Osbourne Effect.

Meanwhile a rift developed in the Perl community. Some are for Perl 5 forever. Some are Perl 6 forever. Some Perl 5 people blame Perl 6 for Perl 5's perception as a dead language. Some Perl 6 people blame Perl 5's reputation for being "write only" and "dead" for difficulty getting people to try Perl 6.

IMHO, both sides are correct, both sides over-state their case.

Renaming Perl 6 has been discussed for close to a decade, by people who are Perl 5, Perl 6, and just plain Perl partisans.

It's been a difficult decision. Many people have worked very hard on both projects, and have strong feelings tied up in the issue. Important contributors to the projects have quit as a result the issues.

This isn't a change that was lightly made. It's far bigger than the Python 2 to Python 3 divergence. It's more like moving from C to C#.

</comment></comment></comment><comment><AUTHOR> This has been a huge deal for the Perl community.

First, it was thought that Perl 6 would be the replacement for Perl 5.

But it was long ago recognized that there was no clear upgrade path from Perl 5 to Perl 6, so it was agreed that Perl 6 was a "sister" language to Perl 5 rather than the successor.

Except that many people expected that Perl 6 would be the replacement, so that stalled many projects. So an "alias" for Perl 6 was created, but that didn't seem to help.

Larry has now agreed with the change and Perl 6 will be renamed to "raku" and Perl 5, which has regular, major releases every year, will now be able to simply be "Perl" and be free to continue on its own way.

If I had my choice, I'd program in raku because it's a lovely language addressing many pain points (including being one of the few dynamic languages with a working concurrency model). But it's not adopted widely enough yet for that to happen. Time will tell ...

<comment><USER24> > Larry has now agreed with the change and Perl 6 will be renamed to "raku" > and Perl 5, which has regular, major releases every year, will now be able > to simply be "Perl" and be free to continue on its own way.

I hope that doesn't mean that when Perl needs a major number version change again, they'll chose 6. It would be pretty confusing to have 2 Perl 6.

<comment><USER25> It's not uncommon to leap frog versions in such cases. PHP went from 5 to 7, for instance.

<comment><USER26> But that's because PHP6 was dumped after being in development for a while.

<comment><USER19> This is not entirely unlike that. Somewhere along the way, everybody realized Perl 6 was not the path forward from Perl 5, and so Perl 6 never really took the place of Perl 5, just like PHP6 never took the place of PHP 5. It looks like a pretty similar scenario, if you squint, I think.

It makes little difference for Perl that this experiment in a next generation version of the language is still alive and going its own way. The result is the same...people kept moving forward with version 5, and if it needs a new version, it can't use version 6 because 6 was already used for that other experiment (that failed to take the place of Perl 5).

</comment></comment></comment></comment></comment><comment><USER27> I kinda wish something like this would happen with LuaJIT, so it can get out of Lua's shadow.

Lua has breaking changes all the time, which makes sense for its original purpose — embedding — where you don't need to follow updates. As such the version supported varies among different environments. But LuaJIT has an ecosystem that they try not to break. It's more of a "conventional" scripting language because of that. It also has an FFI that isn't in plain Lua.

</comment><comment><USER28> If anyone is interested in working with the language, AFAIK, DuckDuckGo's backend is primarily written in Perl.

<comment><USER29> Perl 6 / Raku introduces so many new constructs that is almost an entirely new language.

</comment></comment><comment><USER30> I find Perl 5 best for the kinds of fire-and-forget text processing scripts that are a bit too complicated for awk but not involved enough to bring in a "real" language. It's a double-edged sword - in a throwaway script it's awesome to not have to bother converting between the number 12 and the string "12", both numeric and string operators will work on them the same way. In a large project that kind of thing is just going to cause a bunch of untraceable bugs due to unidentified invisible behavior. Or you need to resort to weird hackarounds like "0 but true". Also: $_ is like that, only more so.

CPAN invented the software repository, and I'm glad it was there so PyPI/Gems/NPM/etc. could learn from its mistakes.

Every few years I tried an alpha of Perl 6, but it was always too slow and unstable to get anything real done, and it was always a totally different implementation from the previous one I'd tried. Maybe this name change shows they're getting serious now.

<comment><USER31> Didn't CTAN predate CPAN?

<comment><USER30> It did, but CTAN was just a network of FTP mirrors. CPAN was that initially too, but quickly got supporting software to automatically download/update packages and resolve dependencies, which AFAIK nobody else did at the time. Even Linux package managers didn't get that until a couple years later.

</comment></comment></comment><comment><USER32> May Perl 5 live forever. Amen.

</comment><comment><USER33> The naming is a very good idea since it really is a totally different language and the numbering made it seem like an incremental upgrade. Whether it's too late will remain to be seen. Also, now maybe there is space for an actual Perl 6! :-)

</comment><comment><USER34> Can someone explain to me, for what kinda of new projects would they use Perl/Raku in 2019 at all?

<comment><USER35> A lot of my colleagues in NLP and text processing still prefer to write in Perl. Granted they are mostly the old guard but it is prevalent in academic language technology research.

<comment><USER36> .. in the old guard of language technology research I guess, because in my NLP lab, no one knows the first thing about Perl (everything is done in Python)

<comment><USER37> More than that. I wrote my first machine learning project in Perl.

Perl 5 is better than Python in many ways, but worse in other ways. Raku seems to have none of the downsides Perl 5 had, but all of the upsides. Raku looks like it could be a valid replacement for Python in the ML space.

Also, back then, Perl 5 had better libraries than Python. Though, that was quite a while ago.

</comment></comment></comment></comment><comment><USER38> Fifteen years too late. But I suppose better late than never.

<comment><USER39> Had they done it fifteen years earlier, I think Perl could have been the language to learn for Data Science. It still is a fantastic language to slice, clean up, and extract information from text files, and it was already very widely used in bioinformatics.

<comment><USER40> I don't think the name change was the problem here, rather it wasn't complete until recently.

<comment><USER41> "a fantastic language to slice, clean up, and extract information from text files, and it was already very widely used in bioinformatics" is a description of Perl 5, not Perl 6.

Even if Perl 6 is completed, I don't think it is a practical workhorse for many real world situations.

To me being able to create grammars in Perl 6 to parse text data sounds really compelling. However, every time I have played around with them, Perl 6 has been so slow, that I have reverted to using regular expressions in another language.

</comment></comment></comment></comment><comment><USER42> One thing that fascinates me about Raku/Perl6 is how hard it leans into object-oriented programming at a moment when so many other new languages seem to be trending in a distinctly functional direction.

</comment><comment><USER43> The Author point to [1] for reason for Raku instead of Camelia.

One thing that struck me,

 _12\. Both raku.com and raku.org are currently available._

I was surprised that a 4 letter .com or .org is still available. So I looked it up and turns out to be not true.

And it was interesting half of the discussion had domain name availability as factor.

[1] [https://github.com/perl6/problem- solving/issues/81#issuecomm...](https://github.com/perl6/problem- solving/issues/81#issuecomment-520216578)

<comment><USER9> raku.org is no longer available because it is controlled by the Raku project.

</comment></comment><comment><USER44> It will have quite interesting implications, especially for former Perl 5 syntax enthusiasts. One could say in Polish they "code in cancer" ("programuje w raku").

<comment><USER45> Not "z raku"?

<comment><USER44> No. "Z raku" would mean that "raku" accompanies you and the play on words would be gone because it would be either "programuje z raku" ("one is accompanied by raku the programming language") or "programuje z rakiem" ("codes having/with cancer").

</comment></comment></comment><comment><USER46> What utility does Perl provide in a world dominated by python?

<comment><USER47> Legit question.

Movable Type is about the only blog framework not written in PHP. If you thought Perl was a bad language, PHP is way, way worse. And Movable Type is also the only one that can use Postgres for storage.

I could not find any blog engine in Python.

<comment><USER38> There are static site generators written in Python you could use to publish a blog, like Pelican ([https://blog.getpelican.com/](https://blog.getpelican.com/)) and Lektor ([https://www.getlektor.com/](https://www.getlektor.com/)). But yeah, if you want software that works like WordPress and generates pages dynamically on the fly, I'm not sure there's any good Python-based alternatives.

 _> If you thought Perl was a bad language, PHP is way, way worse_

In fairness to PHP, it's a lot better today than it used to be. (Though modern PHP would probably strike a Pythonista as too Java-ish.) And WordPress has had tons of engineering resources poured into it for a decade-plus now, whereas Movable Type has been maintained on a relative shoestring due to its fall from popularity.

<comment><USER47> It is hard to imagine why anyone would want to generate blog pages on the fly, but somehow it is what everyone does.

</comment></comment></comment></comment><comment><USER5> Larry's actual approval (although he has basically said before that the community doesn't need his approval anymore) is here: [https://github.com/perl6/problem- solving/pull/89#pullrequest...](https://github.com/perl6/problem- solving/pull/89#pullrequestreview-300789072)

</comment><comment><USER48> [https://cnet4.cbsistatic.com/img/DaSY- sXB3xqiXQZImbypEvHPdec...](https://cnet4.cbsistatic.com/img/DaSY- sXB3xqiXQZImbypEvHPdec=/1092x0/2019/05/22/1b710a6b-5f4d-4987-a046-c23674b221a3/picard- meme-facepalm.jpg)

</comment><comment><USER49> I used a workflow automation system at my previous gig that used java heavily on the backend. Rakuraku Workflow was the name. I hated it. The name, that in japanese means something like "easy easy" (楽々) didn't help much. It was a mess.

</comment><comment><USER50> So will there be a Perl 6 then, or are Perl 5-ists stuck on that major version forever?

<comment><USER51> Apple and Microsoft have basically proven that you can jump major version numbers and no one will really care.

</comment></comment><comment><USER52> I wish them the best of luck, but in my experience rebranding a seriously off track project is often the treatment of last resort. It's the vancomycin of struggling projects.

</comment><comment><USER53> Is that from the Bible?

<comment><USER54> Does not sound like anything from the Bible I have ever read. Theres other commentary on this HN post about the many meanings of the name though.

<comment><USER55> It is - the book of Matthew, specifically.

<comment><USER54> You're thinking of "Raca" from Matthew, it wouldn't make sense for him to call it based on that verse though since it's not a pleasant word. Jesus specifically says not to call your brother Raca. Why would he call his language that...

</comment></comment></comment></comment><comment><USER56> Good move. The name 'Perl' has connotations (good or bad depending on who you ask), but this language always seemed like a different kettle of fish.

Names matter.

</comment><comment><USER57> so, raku is shortened for rakudo the perl compiler. rakudo itself might be japanese but i can't confirm.

google, in their infinite wisdom, doesn't want to translate the word because they think i am typing it wrong and they know exactly what i meant to type... but anyways, i think it has to do with paradise or heaven, but i could be wrong.

</comment><comment><USER58> Hallelujah! Great decision :) it will give Raju a chance to be viewed without the "line noise" lens of Perl 5.

<comment><USER59> I'm disappointed they didn't take my suggestion to rename Perl 6 to "$#_@;\>&%}`[*~!^)".

<comment><USER60> I'm disappointed that's not executable. :)

</comment></comment></comment><comment><USER61> In Russian "raku" is a genitive of cancer / a derogatory term used for noob users.

</comment><comment><USER62> Can someone give the rest of us some context on this?

<comment><USER63> Perl5 -> Perl6 has been highly contentious.

Perl6 is basically a different language much to the chagrin of many Perl users. A lot of Perl users are entrenched in Perl5.

FWIW: I'm unclear why people continue to use Perl at all, I moved on in 2011.

<comment><USER64> In the same boat on the "why haven't people moved on"... Perl use to be ubiquitous but over time it's really gone to the wayside vs. Python tooling for more complex stuff, and back to basic BASH for the simple scripting needs.

Every time Perl comes up in a professional environment for me I'm reluctant to say I'm capable, because it's always a hacked-together mess from an engineer who's likely no longer with the company. (obviously this is VERY anecdotal to my career)

I dropped Perl from my resume about a decade ago because I just frankly don't want to work with it. The language is terse, and I don't think anyone who's starting off these days would be spending their time well by learning it. Make your own opinions, but mine is/has always been "ewww."

<comment><USER65> > it's always a hacked-together mess from an engineer who's likely no longer > with the company. (obviously this is VERY anecdotal to my career)

That's what programming is.

<comment><USER59> False equivalence. I'd choose a hacked-together mess from an engineer who's likely no longer with the company written in Python over Perl any day.

</comment></comment></comment></comment></comment><comment><USER66> A long overdue marketing move.

</comment><comment><USER67> If raku failed to catch on whilst it was named Perl it has even less chance to catch on now.

</comment><comment><USER68> raku is a type of pottery firing, also from Japan.

</comment><comment><USER69> It would be cool if Les Claypool played Larry Wall in the movie.

</comment><comment><USER40> Will Zoffix return?

<comment><USER40> Not sure how to edit, but for those who don't understand this comment, Zoffix was a key Perl6 contributor who recently left because the community and Larry Wall wouldn't change the name to something else like "Raku" among other things I guess. Now that they have made this change, I'm curious if he'd ever come back and start running the test suites again.

</comment></comment><comment><USER70> Julia has a really great threading model coming in v1.3, which is likely to be released this month: [https://julialang.org/blog/2019/07/multithreading](https://julialang.org/blog/2019/07/multithreading)

It already supports a variety of parallel techniques but it's about to get easier and safer (e.g. safe I/O).

<comment><USER71> Is Julia getting more stable? I remember that was the big issue a few years ago, especially since it calls so many weird CUDA apis.

<comment><USER72> Well, that's what reaching 1.0 was supposed to represent, but I don't (get to) use it (for the kind of work I do) so I cannot say for sure if that actually worked out in practice.

<comment><USER73> There were packages I wanted to add features to last week that I've used daily for years, and when I went to go check them out, I noticed they hadn't been touched since the 1.0 release which is now over a year ago. So I think the stability of 1.0 has worked out well since, in contrast to pre-1.0, these days core packages don't even need maitanance and will still continue to work perfectly well for years.

</comment></comment></comment></comment><comment><USER74> the programming community never ceases to amaze me

</comment><comment><USER75> [http://tpm2016.zoffix.com/#/13](http://tpm2016.zoffix.com/#/13) \- There is so many good ideas to copy to Rustlang!

</comment><comment><USER76> This should have happened with Python 2/3.

<comment><USER77> I'm not sure I agree with you but I can't imagine why you're getting downvoted. It's definitely an argument worth making.

<comment><USER76> Nobody likes hearing their favorite language trashed.

</comment></comment></comment><comment><USER78> Call me a pessimist, but its too little too late... I learned regex in perl so the language will always have a soft spot in my heart. But Python has trounced Perl for almost any task. There simply is no reason to learn perl unless youre in the unfortunate position of managing some legacy stack.

<comment><USER24> > But Python has trounced Perl for almost any task.

Well, I think Perl beats Python in quick and concise one-liners written from the command line, doesn't it?

Not that I know much Perl, though.

<comment><USER18> It does but it's still annoying to write on a line as opposed to Ruby or Lua. Writing Python one liners with significant whitespace is out of the question I guess.

<comment><USER79> Raku includes an incredible amount of new tools for writing one-liners. Furthermore, you can convert your one-liner into a command line app simply by wrapping the code in a `sub MAIN($pos-arg, :$named-arg) { ... }`.

<comment><USER18> Yes but it has a VM penalty for at least more than 500 ms in my box, which is kind if dissapointing.</comment></comment></comment></comment></comment>


How the pandemic should make us rethink college financial aid - <AUTHOR> https://nypost.com/2020/06/12/coronavirus-should-make-us-rethink-college-financial-aid/ <comment><USER2> College financial aid is not feasible at the moment. The world should strongly look at alternatives to the regular college with so many people now accustomed to online learning.</comment>


Customers Enjoy The Little Things - <AUTHOR> http://www.entrepreneuraddict.com/your-customers-enjoy-the-little-things/

<comment><USER2> I remember when the Morton's Steak story was originally published. Apparently the recipient of the Steak is rather well known and Morton's recognized this and capitalized on the fact that they could get good marketing out of it. Morton's probably would never have done the same for just anyone.

<comment><AUTHOR> I think there is some truth to that. The original customer said he didn't think that was true. He believed it was because he was a good and loyal customer. Who knows really....

Thanks for the input.</comment></comment>


Show HN: Would any lawyers on here use something like this? - <AUTHOR> https://legalparse.com/

<comment><AUTHOR> Current todo list:

* Word/ODF document import support

* Dropbox API integration

* Google Docs API integration

* Support for the Ctrl-S and Ctrl-P keyboard shortcuts

* Perhaps fleshing out the UI a bit more to allow viewing and interacting with documents from Dropbox/Docs

\---

A few questions, if anyone has any answers:

* Does the current model of storing the document client-side (like a traditional office document) rather than server-side make sense usability-wise at all? (perhaps a moot question as soon as I add Dropbox support, either way)

* Is my current method of sending the rendered PDFs secure with a standard Apache configuration, or will I need to move to something like a simple cookie-based authentication? I currently have it set up to put a random hash code in the file name and delete the file after 10 minutes, but I'm concerned that there may be something in the HTTP protocol or some way of fiddling with wget -r which will return the names of each public file on the server.

* What kind of revenue model makes sense for this? I'm fine giving it away for free, but if it gets enough traffic that I need to move it off the free tier of EC2, it will be hard to justify taking a loss to keep it running. I have a couple ads up now, but I doubt I'd be able to do much more ad-wise without ruining the product in the process. Do any of the above suggested features (or others) seem like a reasonable basis for a freemium upgrade? Or would it make sense to simply start directly charging after a certain "beta" period? (If so, does something like $1 per use / $5 per month / $50 lifetime seem reasonable?)</comment>


Why do incoming spam SMS cost money in the US? - <AUTHOR> I'm originally from Europe, where strong consumer protection laws make it free to receive SMS.
Here in the US I activated a prepaid plan, which charges $0.20 per SMS, including incoming ones.
The problem is that the phone number I got must have been used in the past, because I receive tons of confirmation SMS and marketing spam, which all are charged against my plan.
How is this legal? I purchase $10.00 of credit and it gets spent on nothing I personally did, with no way for me to block it.
This looks really punitive to the people who cannot afford the $19.00 option for unlimited text!
Are there ways to deal with this situation? If not, how can I help the US society to change this practice? <comment><USER3> For automated texts, legally, there have to be ways of unsubscribing. Try replying to them with "STOP," as even if the spammer doesn't configure it, usually the upstream SMS provider has it built-in to remove you from getting further texts.

In general, essentially everyone in the US has an unlimited message plan, and if not, many carriers don't charge for incoming. My recommendation to how to fix this is to vote with your wallet. Switch to a prepaid provider with better SMS rules.

I'm assuming based on the $0.20/message cost, that you're using AT&T prepaid, which has some of the highest SMS fees for prepaid plans.

<comment><AUTHOR> You are right, and I know AT&T is not the cheapest, but I am forced to use it for the time being. There are a number of reasons why one would need to stick with one operator or the other.

What I question is the fact that I have no control on incoming SMS, and still I get charged for them.

Most of the 4-5 digit numbers mention the STOP options, but I get messages from 10-digit numbers like the following:

"Tracie! Breaking report: This fruit burns up to 10lbs of fat in 14 days! Enjoy this special update here al49.xyz/ketonews"

The same message, a different number every time. Basically everyone in the US is forced to have unlimited text and calls in order not to pay for incoming marketing, how fair is this?

<comment><USER3> Huh, I don't think I've ever gotten spam like that before via SMS.

It seems to be personalized to the previous holder of the number, who I assume is named 'Tracie.' I'd see if you're able to get another phone number, as this 'Tracie' was quite liberal with giving out their number to anyone and anything.

</comment></comment></comment><comment><USER4> Yeah this was mind blowing when I first moved to the US.

The idea that someone can cost you money without your consent is insane. I vaguely recall incoming calls also costing money when I first came here - <USER2> I got a lot as the previous owner of the number clearly hadn't been paying bills...

<comment><USER5> Calls are something you can choose to not accept, but SMS is not..

<comment><USER4> Yes, but if you don't know who's calling you, and you're expecting a large number of calls (as happens when you first move to a country), or if you don't have caller id (which can lie, or just isn't present of land lines) you have to pick up. And then you get charged for having a "conversation".

I feel the rate of spam would decrease somewhat if telcos in the US were not permitted to charge for receiving calls or text messages. (Maybe the latter "service" messages requiring an explicit acceptance message before they're allowed to charge?)

</comment></comment></comment><comment><USER6> US Telecom and Banking industries are very primitive compared to many countries, so no you cannot do much. Sad but reality. You can either pay for unlimited text or pay for each SMS.

</comment><comment><USER7> Unlike E-Mail and landline phones, unsolicited calls and messages on mobiles and in regular mail are not illegal. Perhaps because both USPS and AT&T make a decent amount of cash off this.

<comment><USER8> WhatsApp and other messaging apps have practically killed sms for personal one on one communications. The only thing still prepping up SMS is the bulk messaging such as notifications and marketing.

<comment><USER9> "practically killed"? No one I know uses WhatsApp; they all text

<comment><USER7> Depends on where. Europe, Asia, Latin America. SMS is dead. Messaging apps rule. Viber, WhatsApp, Telegram, Line, WeChat, depending on region.</comment></comment></comment></comment>


3D Printer Specifications explained - <AUTHOR> http://www.productchart.com/3d_printers/info/ <comment><AUTHOR> A page for people who get into 3D printing and want to get an overview of what the specs are about.

Pretty much a rough first draft. If you are into 3D Printers and think some section should be extended or changed, let me know.</comment>


Free user manuals and guides online to download - <AUTHOR> http://www.usermanuals.tech/ <comment><USER2> Looks a useful site. But the supposed testimonials are hilarious!

Actually, scrap the "useful" comment. Site is hopeless. Search function doesn't find anything, not even manuals listed on their own front page. And said manuals are all ancient and freely available all over the web anyway</comment>


Startups Can Generally Solicit Starting September 23 - <AUTHOR> https://rockthepost.com/blog/general-solicitation-takes-effect-september-23/

<comment><USER2> In my mind, it's the whole requirement of being an "accredited investor" that is the real hurdle. I ran into this a few years ago when a friend of mine opened a brewery. He was taking investments, but since it was a private company you had to be an accredited investor (which I wasn't). In the end I ended up being able to give him some money for potential returns but we had to jump through some legal loopholes.

</comment><comment><USER3> It was the best of times, it was the worst of times ... [http://shoeshinestocktips.com](http://shoeshinestocktips.com)

</comment><comment><USER4> This might be a dumb question, but why does the law require that an investor is "accredited"? Why does their income and net worth matter? If someone only made a measly $100k last year and wants to invest in my company, why wouldn't they be allowed to?

<comment><USER5> I believe it's to prevent lower net worth individuals from losing their life savings. The inability to make a big bet on a single company. Paternalism basically.

</comment></comment><comment><USER6> "permits an issuer to engage in general solicitation or general advertising in offering and selling securities pursuant to Rule 506, provided that all purchasers of the securities are accredited investors" This is huge.

</comment><comment><USER7> So how far are we from real crowd-funding? i mean no requirement of accredited investors? i'm sure someone is already working on that bill ...

<comment><USER8> From TFA: "When Title III of the JOBS Act takes effect – likely in 2014 – this number will multiply as any individual will be able to invest in private offerings."

</comment></comment><comment><USER9> It will be interesting to see what kind of investment platforms (like kickstarter) this will create.

<comment><USER6> printmoney.federalreserve.gov

</comment></comment><comment><USER10> I'm trying to figure out the barrier-to-entry for scam artists, and they seem pretty low.

<comment><USER11> Your marks have to be filthy rich. That's about it, though.

</comment></comment><comment><USER12> Provided solicitations are limited to accredited investors...

<comment><USER13> What's an accredited investor?

edit: Nevermind, it's a person with at least $1,000,000 in assets or $200,000 dollars in income.

<comment><USER14> And the problem with the "new rules" is that they require the "accredited investor" to provide all sorts of documentation to the startup, to certify that they are, indeed, an "accredited investor". We're talking tax returns, or a certified document from their accountant, etc.

This is going to add extra friction to the process and may negate a lot of the purported benefits of this whole mechanism, given that investors were previously allowed to simply "self certify" their status as an "accredited investor".

See, for example, [http://wraltechwire.com/will-sec-rule-506-c-changes-help- cur...](http://wraltechwire.com/will-sec-rule-506-c-changes-help-cure-your- capital-needs/12693425/)

for some discussion on that point.

<comment><USER15> can't they do that by proxy? i go to my bank, i show them evidence that i have made $200k or more in the last 2 years, or that i have a million+ net worth. i get the document notarized, i give the company the notarized document by the bank as evidence. my paperwork stays private.</comment></comment></comment></comment>


OrientDB 2.2 Released – Open-Source Graph Database - <AUTHOR> http://orientdb.com/released-orientdb-v2-2/ <comment><USER2> Has anyone had any luck with Orient and large database?

I tried to use it with a 80,000,000 product database with about 60,000,000 updates a day (edges between sellers and products labeled by price) and it was unusable with the same sizing as a mySQL database that handled it easily.

It seemed great though. Especially since neo4j open source is quite restrictive (clustering is a commercial only feature not available in the OSS version).

<comment><USER3> I had the same problem with a fairly 50/50 read/update database, about 20M reads/20M updates a day. Brought it to it's knees. Postgres handled it no problem.

</comment></comment><comment><USER4> worth reading: [http://orientdbleaks.blogspot.com.ar/2015/06/the-orientdb- is...](http://orientdbleaks.blogspot.com.ar/2015/06/the-orientdb-issues-that- made-us-give-up.html)

I've had several issues with the "distributed" setup among others.

</comment><comment><USER5> Was thinking of using neo4j for an upcoming project. Did anyone benchmark OrientDB against Neo4j

<comment><USER6> A 3rd GraphDB vendor, ArangoDB, did benchmark both of them. You can find the results on their blog at [https://www.arangodb.com/2015/10/benchmark- postgresql-mongod...](https://www.arangodb.com/2015/10/benchmark-postgresql- mongodb-arangodb/)

</comment></comment><comment><USER7> Definitely, worth checking out! Much stable and fast.</comment>


Why Women Don't Apply for Jobs Unless They're 100% Qualified - <AUTHOR> http://blogs.hbr.org/2014/08/why-women-dont-apply-for-jobs-unless-theyre-100-qualified/

<comment><USER2> [https://en.m.wikipedia.org/wiki/Glass_ceiling](https://en.m.wikipedia.org/wiki/Glass_ceiling)</comment>


Meet Raphie: A 15 Year-Old Developer Who Built ShareBrowse - <AUTHOR> http://www.forbes.com/sites/alextaub/2012/08/16/meet-raphie-a-15-year-old-developer-who-built-sharebrowse/

<comment><USER2> This guy is really talented. What he built at AngelHack, could easily turn into a $100MM product if pursued full-time. I'm sure he'll have some great accomplishments in the years to come.

</comment><comment><USER3> Rockstar!</comment>


Ask HN: Where is Paul Graham on Google+? - <AUTHOR>

I can't find his profile anywhere... Not on there yet? Most of the technorati seem to be on there so far. Even some celebrity-types are making a showing. <comment><USER2> Nobody invited him I guess... poor guy! :)

</comment><comment><USER3> Presuming he's not on there. I don't believe he has a Facebook account either.</comment>


Agile Development: A quickstart guide to doing it right - <AUTHOR> http://rubypond.com/blog/quickstart-guide-to-agile <comment><USER2> _Throw out the tools you're using_

I'd like to underline this about a thousand times.

(disclaimer: I teach agile to teams) What I see over and over again is folks picking up agile and a) getting too religious about it, and b) immediately making it 5 zillion times more complicated than it has to be. Usually with the use of tools (but creative minds have been known to create manual monstrosities)

If I could eliminate people who already know everything (either pro or con) and folks who for some reason want to complicate everything? Life would be a lot easier for agile teams.

I saw a guy once -- no shit -- that had created a 20-tab spreadsheet to "do" agile. Each sprint close he forced the team to sit down while he went through each item on a projector. Their backlog had 600 items in it. It was like taking a big dump truck with manure and just covering the team in it. I insisted they move to a physical storyboard, and when I checked up with them a few weeks later they had this storyboard that looked like the wiring diagram for a 57 Chevy. Colors and lines and tags and color-coded cards.

Agile is easy, but it's possible to screw it up if you keep trying hard enough. Start simple and then add what you need.

<comment><USER3> (disclaimer: Agile consultants ruined the software group I work in.)

Making good software is hard, and anyone claiming to have a magical process that guarantees good software is selling snake oil. I can appreciate your wanting to make a buck, but would also seriously appreciate it if you could find some other industry besides software development to go screw up.

<comment><USER4> Convicting one for the sins of others?

<comment><USER3> Ever notice that virtually all Agile success stories are written by Agile consultants and not by developers? Ever notice that nobody actually claims to have built anything from scratch with Agile?

The stories all read the same. Product has already been built. Developers stuck bike shedding over some piddly detail, when lo and behold the Agile consultant arrives to cut through the Gordian knot by placing the developers on a strict regimen of myopic thinking and inattention to detail.

Agile is bullshit.

<comment><USER5> I actually know a startup with a team of about 9 people who are doing just fine with agile (since the beginning).

Could you elaborate with some more substantial criticism?

<comment><USER3> I worked at a cool little company where we built a useful product. We just built it. We didn't use waterfall, agile, or any real process. We just made sure to communicate and only hired people with good judgement and critical thinking skills. A big (very big) company decided they liked our product and bought the company.

After acquisition, our new overlords decided that our process, i.e. using our brains, wasn't compliant with whatever standards they had for development. In came the agile consultants, scrum masters, TDD, CI, etc. All the things you hear these blog posts evangelize about. It brought development to a total halt as all these assholes put in their $0.02 about how we needed scrums, sprints, user stories, and story points. Developers couldn't work on the features they knew were important without cutting through miles of red tape (finding a "customer" to make a story, breaking that story down into the actual work that needed to be done, moving the story through the backlog, estimating points for the stories, etc).

Like I said above. It ruined my software department. I wouldn't wish agile on my worst enemy.

<comment><USER6> Ahhh it actually sounds like your team was originally being Agile: <http://agilemanifesto.org/>

As opposed to how a lot of people land up doing Agile: <http://www.halfarsedagilemanifesto.org/>

<comment><USER7> _Ahhh it actually sounds like your team was originally being Agile_

This statement is unfalsifiable; this kind of retroactive defense makes Agile out to be an ever-moving goalpost. If any effective, basically "good," organic team behaviour was "Agile" to begin with, there is no identifiable differentiating criterion of Agile methodology from any other mode of small- scale collaboration.

<comment><USER6> Interesting point. The thing is, any Agile method is supposed to evolve with the team. Long running Agile teams are often not following any one methodology but rather using the best bits of a bunch of them, in a way that works for the team.

This stuff is mostly common sense so you will find that many small teams are often Agile even if they don't know it. Modern software dev is really more about effective communication and collaboration then technology and tools.

My take on it is: If what you are doing aligns with the Agile Manifesto and its Principles, then you are Agile even if you are not doing TDD, peer- programming, daily stand ups etc. No matter what the zealots are telling you to the contrary.

<comment><USER2> Agreed. Another way of putting this: Agile is best practices for iterative, incremental development. Applied agile means borrowing/stealing practices from others, and more importantly creating and adapting your own processes to your particular team.

</comment></comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER8> I can't endorse putting developers and customers directly together. In my experience, customers view developers as something between magicians and freaks. Many will not take seriously a developer in sandals, shorts and a a T-shirt with some kind of geeky slogan.

Developers on the other hand, often lack the patience and tact to work directly with people who don't understand technology at their level. They tend to divert the conversation to the "interesting" problems that they want to work on and conveniently don't discuss the details of all the reports that the system needs to produce.

When developers and customers get together, they talk past each other because they're almost speaking different languages. Or they get sidetracked on minutia and lose sight of the larger goals.

There is definitely a place for a person who can be comfortable in a business suit talking to customers, understanding their needs and priorities in their terms, and then translating that into user stories (often with developer assistance) back at the office.

<comment><USER9> I'd be very unhappy working in an environment like the one you described. I consider myself a developer, but I've worked directly with customers most of my career. If I were cut off from that, and had a BA standing between me and the end user/customer, I'm sure the resulting product would suffer.

It's no surprise that we'd come to such different conclusions. I think that a dev who is capable of working well with customers would be so frustrated with a BA that he'd quit, or (more likely) never take the job in the first place. So it isn't random chance that you never meet these developers - they're probably avoiding the kind of organizations you work for. I'm not saying you don't work with talented programmers, I'm just saying that a BA-heavy workplace that probably filters out the kind of developer who has the patience and tact to work with customers.

</comment></comment><comment><USER10> The hardest part of doing Agile is to change the mindset of the people. They're used to working in an iterative/mini-waterfall schedule and used to be bounded by "processes".

With Agile, suddenly there are less "processes" even though there are still some things that they should follow (TDD, Continuous Integration, always have test automation in many levels, etc).

<comment><USER11> Is this not the point of RUP? To create an iterative, agile methodology that looks like a waterfall at a high level? I think the problem you define is the exact reason that RUP becoming so popular, but I admit that I may misunderstand.

</comment></comment><comment><USER12> Some good stuff in here, but I was reminded of Paul Buchheit's classic statement: limited life experience + overgeneralization = advice

</comment><comment><USER13> The only piece that I would add to this article is the concept of a daily morning scrum. For virtual teams this can be accomplished via Campfire. For those who don't know about a daily scrum, the idea is that you take 5-15 minutes (the shorter the time the better) first thing in the morning and everybody goes through briefly 1) What they did yesterday 2) What they're working on today 3) Anyone they need to sit down with to help them become unblocked / discuss a feature with. Doing so every morning is a great way to keep everyone on the same page and provides a good balance between autonomous time and keeping everyone on the same page.

Doing this meeting while standing helps to keep the meeting short and to the point, and if you find yourself engaging in discussion about a particular feature / item / issue..."take it offline". Don't use everyone's time to discuss something that should be discussed at a later time when everyone else could be in flow.

<comment><USER14> I find the daily morning scrum meeting a major "zone killer". It's completely orthogonal to how I function that I often spend a major part of the day just recovering from it.

I arrive in the office ready to roll, motivated, head full of ideas that have matured during the night, breakfast and commute. I can litterally arrive, sit down and crank out code (or whatever task is on). And then it's daily morning scrum meeting, and even that 5 or 10 minutes (when done right, a thing I've never seen with my own eyes) totally kills this mental state. 99% of the time my task is self-sufficient enough that what other team members do is completely irrelevant to me and I rarely have any insight to give them either. And I don't remember nor even care what I did yesterday, it's done, forgotten, check the SVN commit logs if you want to know about it. So I zone out, then the meeting is over and I've half-forgotten what I was doing so it's time to look at the latest meme on reddit.

I'd gladly settle for a daily _evening_ scrum meeting: \- What did you do today? \- What bothered you? \- What will you do tomorrow? put that in the back of my mind and go home, I'm sure I'll have sorted things during the night to be useful tomorrow.

</comment></comment><comment><USER15> Good stuff. I plan to share this with each development manager on my team. We've learned many of these lessons the hard way. Others, we've decided not to pursue. For example, we have found working together in a team room is extremely helpful when working through a new model design, etc. So we have a 3 days in, 2 days virtual model.

Along the lines of removing technology, we've enjoyed using a mockup tool (like Peldi's Balsamiq or Mockingbird) for capturing story flows and wireframes. I know it's tech, but these tools do such a good job of removing the tech it's barely visible.

And from the article, a diagram that captures the idea behind MVP fairly well: <http://rubypond.com/images/scheduling-stories.png>

</comment><comment><USER16> Great article, but what if you're a BA with a great idea and super low budget?

You can either: a) Learn to develop applications on your own (potentially slowing your time to market and reducing product quality)

b) Develop the requirements and hire someone else to build it (cheaply and effectively if you've got a good team in India)

c) Take on a developer as a partner (diluting equity and who knows if he's the right guy for the job until you've learned more about the nature of the solution needed?)

My contention is that its not worth diluting equity with an additional partner until you've put out a product yourself that tests of all your original assumptions.

<comment><AUTHOR> In that scenario, you're not a BA you're the customer because you want _your_ idea developed. So hire a competent developer to make that idea come to life. The core problems with being a BA are the same, you'll skew the implementation with your own pre-conceived notions of how you think things should be done. Given you're not capable of doing the work, you really shouldn't have any input on that.

I don't tell my accountant how to do their job, despite having numerous opinions on how things should be structured. She takes my input on board, and tells me what I should actually be doing.

How you decide to remunerate them is an entirely different problem.</comment></comment>