For the best experience on desktop, install the Chrome extension to track your reading on news.ycombinator.com
Hacker Newsnew | past | comments | ask | show | jobs | submit | history | more wojcech's commentsregister

How do you make capital?


Is that meant to be a trick question?

Wikipedia says: "In economics, capital goods, real capital, or capital assets are already-produced durable goods or any non-financial asset that is used in production of goods or services." (https://en.wikipedia.org/wiki/Capital_(economics))

So, you just produce it in a factory or at home etc.

See also http://www.investopedia.com/ask/answers/051115/what-capital-... and https://en.wikipedia.org/wiki/Capital_formation


Probs to github for the disclosure. And congratulations to gitlab for probably getting a nice boost in on premise support contracts:)


Github Enterprise is on-premise too.

I don't know that this would make you necessarily want to make both the change to self-hosting, and the change of platform.


Because there is one critical characteristic in a private repository, and they failed to execute. Moving on-prem doesn't fix that failure, it just mitigates fallout.


It seems highly unlikely this commit made it into a GitHub Enterprise release.


We'll never know, which is a problem unto itself.


> Like smoke a weed, workout, work at a burger joint as a burger flipper and date my daughter's best friend.

Smart way to get your kids to find you a job. I like it


If I have to guess, the primary organ used in prediction of the future, especially catastrophes


Tar is just bundling into a single file AFAIK. There is a slight benefit depending on your compression tool to tar and then compress, because (AFAIK again)some tools compress files individually and then write them into a hierarchical file(I guess this is what xz does as well, since it's searchable?). If you tar first, these tools will work better, since they encode patterns found in all files instead if doing it per file(which means e.g. if there is a header once per file, that will get compressed in the tar.comorpress, not in the . compress)


I've created sortedtar Brewster if this assumption and while it is correct tree benefit is mostly negligible except for some edge cases.


I am that person. Coming from an electrical engineering/Low Level programming background

HTML is a Markup language. I get those.

CSS is stylesheets and in my opinion very straightforward. The hard part is making designs that are functional and beautiful and making it cross browser compatible, but CSS has very few warts if the "wtf" variety

JavaScript and it's ecosystem is disgusting for me. It's not hard, I can write stuff in it, it's ugly. I just don't want to touch it if I can avoid it. Pure personal preference. Typescript and elm help me to minimise the work I have to do in that mindspace. Maybe vue aims at similar clientele with less taste for statically typed/functional programming


You admit you understand it and it's just a personal preference. Therefore you're not that person.

The stated goal of making templating accessible to programmers isn't to shield people who don't like JS, it's to shield non-programmers who don't understand programming languages. This is the absurdity I'm arguing against.

If it was just about making JS look different, there would be no need to use Vue in the first place.


I thought the point also was not to mix the programming language in with the display logic, which was done a lot with PHP in the past, resulting in messy applications.


Yeah, and that idea was always pretty stupid. They'd create some some new, terribly ugly, syntax. Maybe at first functions were limited, nut inevitably, they'd add connectors for every function in the "host" language (php/js/...). Or just something generic, allowing you to do something like <this-is-definately-not-a-programming-language native="Kernel.exec('sudo rm -rf /'"/>.

OF course it meant you had to learn a new language, even though you were perfectly capable of perfectly suitable language already. But at least designers didn't have to learn "programming".

There's no way around this. Templates need logic, mostly for loops (or maps, same difference), or dynamic formatting.


Templates need some level of logic, yes. Putting the entirety of the business logic in your templates is not only bad, but dangerous. Because unless you're replicating your business logic in your non-template code, I can change things in the DOM, and potentially corrupt the system.

Unless I completely miss the boat about how Angular/React/Vue/etc are supposed to be used. I only know from my previous years of seeing it done in the way I mentioned above, and every time, the work always ended up duplicated in the non-template code.


What's your definition of business logic?


  > "make it easy for non-programmers to write templates"
  > I feel like that has been an illusory strawman from the start.
You're right, the nonprogramming web designer may be a rare bird. Even if they exist, they don't exist long. I have always believed that someone can pick up the rudiments of programming in a couple of weeks. Someone who starts out writing HTML and CSS will eventually rub up against JavaScript. In time they will incorporate a snippet of JavaScript here and there. First it will be mindlessly pasted from the Internet. But after reading enough blogs, they will be bundling React and adhering to the functional programming paradigm to load their own blogs. Come to think of it, I wish there were more people who knew just HTML and CSS.

More seriously, I myself know HTML, CSS, and a few programming languages, but unless the page is very simple I still like to separate things into template files. I prefer Handlebars, but often I just use PHP's alternative syntax.

  > apparently suffer from a nervous breakdown if they have to look at
  > an if-block or understand a for-loop
Well, if-blocks and for-loops are the two main pieces of logic I think every template syntax must have. Mustache said it wrong. Templates should not be "logicless." Templates should be "processingless": they should not have side effects or further manipulate the data. This is okay:

  {{#if items}}
  <ul>
      {{#each items}}
          <li><a href="{{url}}">{{name}}</a>: {{description}}</li>
      {{/each}}
  </ul>
  {{else}}
      <p>none</p>
  {{/if}}
This is less nice:

  <p>Any items you have will be listed below:</p>
  <? $q = pg_query('select * from items') ?>
  <? if (0 !== pg_num_rows($q): ?>
      <ul>
      <? while ($item = pg_fetch_assoc($q)): ?>
          <? if (userCanSeeItem($_SESSION['username'], $item['id'])): ?>
          <li>
              <a href="<?= h($item['url']) ?>"><?= h($item['name']) ?></a>:
              <?= h(ucfirst($item['description'])) ?>
          </li>
          <? endif ?>
      <? endwhile ?>
      </ul>
  <? else: ?>
      <p>none</p>
  <? endif ?>
The problem is not ifs and loops nor the use of raw PHP, with its alternative syntax. The problem is the database calls (pg_query), controller-esque function calls (userCanSeeItem) and text clean-up (ucfirst). This kind of stuff should be hidden inside a model-esque function (getItemsOfUser($username)) which returns a ready-to-print associative array.

I use templates not because I'm scared of all that. Instead it's sort of like the recently re-loved functional programming paradigm. Template files should have no side effects. I know that once I stuff the data into a template, then nothing else will happen besides output to the user's screen.


> I know that once I stuff the data into a template, then nothing else will happen besides output to the user's screen.

Exactly. It's that WTF moment of having database and HTTP queries spring from unexpected locations that you are trying to avoid.


Vue's single-file components (html, js, and scoped css) are super-appealing to me.

The message is something like: "These concepts you understand and use all the time? We aren't going to make you abstract them away. We're going to use them as the foundation for a new way to build apps."


You're not the only one who finds JS and its ecosystem disgusting.


Indeed, just finished the book "Cod" which gives some fascinating details for one example of new England (and also "nonslaving" European countries) indirectly profiting of the slave trade


To add onto the admirals statement, I have two kinds of critical bugs mentally:

Critically dangerous, but understandable(complex crypto/ interactions). Those do not indicate low code quality.

Critically stupid/unwise(you know what these are, e.g. the libressl rant list). These do.


I'm going to be that guy: me, their philosophies are almost completely incompatible^^


I'd be very interested if you don't mind:)


Consider applying for YC's Summer 2026 batch! Applications are open till May 4

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search:

HN For You