1. https://en.wikipedia.org/wiki/StarLogo

> Programming as a profession is only moderately interesting. It can be a good job, but you could make about the same money and be happier running a fast food joint. You're much better off using code as your secret weapon in another profession. People who can code in the world of technology companies are a dime a dozen and get no respect. People who can code in biology, medicine, government, sociology, physics, history, and mathematics are respected and can do amazing things to advance those disciplines.

https://learnpythonthehardway.org/python3/advice.html

But it's like math, if you know it well enough, you'll find ways to use it everywhere. If you don't, you won't. You have to be the type of person that likes to innovate. Its hard to sell to prospective employers, but its great for demonstrating value once you are with an organization. All of my previous employers fight over trying to get me back when I've found myself looking for work. ...Now I work for myself and make my own work and I've priced myself out of their offers, but that's not so bad.

I would be interested in thoughts from anyone with ML experience who has reviewed said course's materials?

Formally from school, I've only had 3 semesters of scientific programming in Fortran and a shitload of math. That and years and years of building models and massaging data in Excel.

Mostly I'm just really used to learning a new API/tool and applying it to new things.

A lot of the ML stuff hasn't been fancy ML, just basic things but applied in really clever and novel ways.

In my limited experience, it's a mixed bag.

Good: you get special treatment/opportunities because of a unique skill set and increased visibility on the end results of what you do.

Bad: management doesn't really know what you do between software releases, you're paid the going rate for your industry while SWEs make far more, and in-house software quality standards might not be established/followed.

As a tangential bonus, I've accidentally converted my PhD research coworkers to strict git/markdown thanks mostly to typora (windows application). I showed one person what my work flow and version history look like for some internal documentation and now they do the same and convert to word/pdf as a last step. As far as I can tell, no one outside of the math/cs intersection has the patience for latex.

Source: in that boat.

Edit: In regards to market rates, that can be alleviated somewhat in follow up negotiations (6-12 months in or so). It's hard to convince someone what you're worth / what your value proposition is when they're not used to hiring software people. You need to demonstrate your business effect first, since they typically don't have a clear picture of it.

It's already a huge pain dealing with know-nothings inside of tech firms. Now imagine having to cater to know-less-than-nothings somewhere else.

1. you _won't_ be happier running a fast food joint - the work is gruelling, and it's so easy to go bust. And you won't bring home six figures

2a. people who _actually_ can code are scarce, even in the tech industry. Source: conducted over 300 interviews

2b. quite logically, your coding skill will be most appreciated and compensated at a Big Tech Co, not at a government department where they will be simply unable to see the difference

As a young person with an interest in software programming (currently studying chemical engineering but still write C code now and then), what do you look for when trying to find out people who can _actually_ code?

examples of simple things: DFS/BFS walks; simple Project Euler problems; or "write a simple game in terminal, maybe with some form of minimax search" (a bit harder), or maybe a parser for simple arithmetic expressions

Granted I don't know anything about that business, a quick google search comes up with an article from 2015 saying running a McDonald's provides an average annual profit of $150k so it sounds about in the right ballpark range: https://www.mymoneyblog.com/mcdonalds-franchise-cost-vs-prof...

My source is from the McDonald’s franchise disclosure documents. The money blog mentioned in sibling comments claim it’s less.

Very possible I skimmed and may have read it incorrectly, accounting is not my thing. As I have now reached the maximum amount of effort I'm willing to put into a forum comment, I'm not going to dig any further. But if you can tease out better information, I'd be curious to know.

Average profit margin 26-28% Average gross sales 2.2 - 2.6M Average operating income before rent/tax: 570k - 716k

"The rent paid to McDonald’s will vary based upon sales and McDonald’s investment in land, site improvements, and building costs."

It looks like that rent paid to McD's home planet is somewhere in the neighborhood of 10% of that investment (yearly? I guess?) but it seems to average about 100k-150k.

There are tons of software "engineers" who try to escape fintech for FAANGs or even startups, coming from top tier firms like Goldman and McKinsey.

Likewise, bioinformatics generally pays a lot less than traditional SWE roles.

So what I have seen is the exact opposite in practice: people with minimum coding skills in other fields trying to jump into tech firms.

Any time, a piece of paper is passed around or when people enter data manually you can either automate or improve the process. People are prone to errors.

Right now, I am rewriting a mission critical application, some trivial changes will save hours a week and improve the integrity of the information. It is not as exciting as writing algorithms but it is nice to see an application written by you used by 200+ people.

Off the top of my mind:

https://sellercentral.amazon.com/forums/c/selling-on-amazon/... https://community.ebay.com/t5/Tools-Apps/bd-p/tools-apps-db

I know similar situations have to be all around us. The problem, as you say, is finding out about them.

- more than 10 documents per day on year average, e.g a bank will receive new annual reports only in some calendar months but in massive scale

- average number of pages or lines of text per document, the longer the document the more mistakes will be made by humans, as they don't have the time to read everything in detail

- average pay of the FTE who is able to understand and process the document manually should be higher than the average pay of all employees in the company, to make sure the documents encapsulate business value

It's not a fixed set of KPI but helps us to sort out too narrow use cases.

By we I refer to the team behind my startup Konfuzio:

http://www.konfuzio.com/en/

Small payback : on your English home page under "Operation of the software" > "Information security", there's one too many sentences:

> We set the highest standards both when creating the software and when processing your data. Both when creating the software and when processing your data we set the highest standards.

(First one is better imho).

Here you go. Good luck, it's 80 questions. (My pet theory is that going through all those questions is already an answer in itself)

I'd recommend that people start with something "easy" like Elm, and then transition to Haskell via frameworks like Miso or Reflex. That's exactly what I did.

This project of mine used to be in Elm & Go, but now uses Haskell throughout: https://github.com/srid/slownews

  Location: Munich, Germany
  Remote: Yes (remote only)
  Willing to relocate: n/a
  Technologies: JavaScript, TypeScript, Elm, Haskell
  Email: maxhallinan <at> gmail.com

Also there's https://futureofcoding.org which has a growing community of language and tool designers focused on live-coding languages. There's a good number of projects being developed by members there.

You can see a large fraction of the users have taken the time to optout, perhaps as much as a third (!) of those who can. Considering how passive most users are, this tells me that the new & expensive Reddit design is indeed loathed.

Necessary for what (or for whom)?

The author of Beautiful Racket, Matthew Butterick, is a lawyer and a typographer. He is not a computer scientist. And yet, he designed a DSL called Pollen for creating web-based books. Pollen has been quite successful within the Racket community.

My understanding is that Racket is predicated on the idea that people like Matthew, as much as people like your computer scientists, are the best authors of DSLs. They are the ones who understand the domains they're working in. If the division you predict ever does exist, it is because the tools have failed to make people who are not computer scientists capable of creating the DSLs they need to solve their problems. It's not because languages are inherently better designed by experts in the domain of programming languages.

That said, there's many ways to write code and learn to code, and I think of the web programming bootcamp style or the cookie cutter college grads who go through four years learning how to program in X language to work at fancy company Y. My point is that many routes are just not focusing on the higher level design skills that I think are needed to make good libraries/frameworks/DSL's.

To clarify, I'm not saying you have to be a PL expert, simply good at program and language design, which I think is what lacks in many places and could create such a division. That skill is/should be accessible to everyone.

>many routes are just not focusing on the higher level design skills that I think are needed to make good libraries/frameworks/DSL's.

I have observed that too. But I don't think this is about who is and isn't a computer scientist, whether self-taught or formally trained. I think it's more a change in the way people relate to programming languages. Perhaps programming languages were commonly assumed to be principally an academic topic. Perhaps it's not that more people are becoming computer scientists but that more people are finding non-academic ways to relate to programming language design. I think what Butterick did was to build the tool he needed to do a job (write a book). So language design becomes just like any other form of hacking.

>Why wouldn't the author qualify as a self taught computer scientist though?

Butterick himself is adamant that he is a lay person. He compares himself to a "squirrel in a ferrari": https://www.youtube.com/watch?v=IMz09jYOgoc And that's his point in that talk - Racket makes it possible for even the lay person to build the language they need.

He spent many minutes motivating it. If you support some functionality to a client (as a library, or a service, or more abstractly), and then later want to relax the constraints that you require from those clients, this should be an acceptable change that they shouldn't have to worry about / be broken by. Like if all of a sudden some REST api no longer requires a specific HTTP header to be present in requests, then this change shouldn't break clients that have been including that formerly-required header all along.

Similarly, if you provide something to clients, and you add functionality to provide a response in all circumstances, not just some, then this should not break clients either.

This clearly is not true of `Maybe` / `Option[T]` and I think it's a pretty fair critique. Maybe we should be using Union types in these situations instead.

Union Types don't compose straightforwardly because they flatten; maybe this is desirable in some cases but the rationale in Hickey's talk leaves me unconvinced. The only practical use case for union types I'm aware of is smoother interfacing to dynamically typed APIs; any nice examples for something beyond that?

That would be a breaking change. And should be, if you're into that sort of thing.

The objection is to the opposite case: What was a T is now an Option[T]. I don't know Scala specifically, but that's a breaking change in every typechecked language I know. Rich is arguing that it shouldn't be. But it could be possible even in typed languages through union types. For example, you can do this in TypeScript by changing T to T | undefined, which is a superset of T.

I think the point remains that, while this is not a breaking change from a contractual viewpoint, most type systems would deem it incompatible.

I've learned that videos of his talks are just not worth my time.

His point is that Maybe a should be composed of all the values of a, plus one more value, nil. A value of type a is a member of the set (nil + a). Why should having a more specific value reduce the things you can do with it? It breaks composition, fundamentally. It's like saying (+) works on integers, but not on 3. I'm saying this someone who really enjoys type systems, including haskell.

No, that's a simple union type. There are very good reasons for Maybe to be different than unions (Maybe can nest meaningfully, simple unions can't.)

Maybe Maybe a is valid, and often useful, type.

Of course, if you have a function of type a -> b and find out you need a more general Maybe a -> b, instead of a breaking change, you just write a wrapper function that produces the correct result for Nothing and delegates to the existing function for Some(a) and you're done without breaking existing clients.

(Now, I suppose, if you're u had something like Scala implicits available, having an implicit a -> Maybe a conversion might sometimes be useful, though it does make code less clear.)

Fundamentally because it would require you to conjure up a value of type b from nowhere when the Maybe a is Nothing. If we view the function type as implication this would not be valid logically without some way of introducing that value of type b.

You could imagine some function from Nothing -> b that could rescue us. But since it only handles one case of the Maybe type, it is partial (meaning it could give undefined as an answer). There is basically two total functions that we could change it to:

   * Maybe a -> b in which case we are back where we started.
   *  Unit -> b which essentially is just b, which can be summed up as meaning we need some kind of default value to be available at all times.

Now this is only "illogical" because we don't postulate a value of type b to be used as this default.

> It's like saying (+) works on integers, but not on 3

No, it's like saying (+) must work on all integers AND a special value nil that is not like any other integers, but somehow included in them and all other data types. We can't do anything with this nil value since it doesn't carry any data, so in the case of (+) we would essentially have to treat it as an identity element.

This is good though, since (+) has 0 as an identity element, so we can just treat nil as a 0 when we encounter (+). However, when we want to define multiplication we still need to treat nil as an identity element (since it still doesnt carry any data), except the identity element for multiplication is 1. This would be repeated for every new function that deals with integers.

So by mashing together Maybe and Integer we have managed to get a frankenstein data type with an extra element nil which sometimes means 0 and sometimes means 1.

Why not just decompose them into Maybe and Integer and supply the default argument with a simple convertion function like fromMaybe?

(FWIW, I actually agree with Hickey that using Maybe in api design is problematic and I've encountered what he's talking about. But while that might be an argument for where he wants to take Clojure, it's not an argument for dismissing type theory the way he does.)

I guess I overlooked it because the other way is so logically trivial, since it basically boils down to A -> B => (A || Nothing) -> B, which is just an or-introduction. So if you wanna implement Maybe generically the "work" lies on the other side.

But since Hickey's argument sort of is that we shouldn't implement Maybe generically, I guess my argument here becomes circular. (Begging the question maybe?)

Yeah, that's (part of) Hickey's point. That the "best" type systems fail this test, and require manual programmer work to solve this problem. Again, I'm saying this as someone who really appreciates Haskell.

In this regard I really like OCaml:

    let get_something = function
      | Some x -> x
      | None   -> raise (Invalid_argument "Option.get")

Maybe Clojure's standard library just isn't that focused on vectors? Python stdlib doesn't support this as well, but NumPy does.

Further his exposition on `Either a b` was built on a lack of understanding of BiFunctors.

The icing on the cake was his description of his own planned type theory. What he described was, as I could decipher from his completely ignorant ravings, a row-based polymorphic type system. However he passes off his insights as novel rather than acknowledging (or leveraging) the decades of research that have gone into type theory to describe the very system he is trying to build.

Worse, he continued to implore his audience to spread FUD about type theory, claiming several times, "it is wrong!"

Here's my response to his talk, which I found insightful:

https://lobste.rs/s/zdvg9y/maybe_not_rich_hickey#c_povjwe

Also, I think your comment suffers from the problem here, where you invoke "type theory" without any elaboration:

https://lobste.rs/s/zdvg9y/maybe_not_rich_hickey#c_ioeyob

Rich has taken the time to explain his thoughts very carefully, and his clear about what his experience is, and domains he is talking about. Whereas I see a lot of vague objections without specifics and that aren't backed up by experience.

Here's my understanding of one of your points: required fields in a data serialization format place an onerous burden on consumers. So in proto3, every field is optional, and this permits each consumer to define whats required for its own context.

Unfortunately, I can't find any connection between the dilemma at Google and the suitability of the Maybe type. You say this:

>The issue is that the shape/schema of data is an idea that can be reused across multiple contexts, while optional/required is context-specific. They are two separate things conflated by type systems when you use constructs like Maybe.

I agree - the value of a field might be a hard dependency for one consumer and irrelevant to a second consumer. But Maybe has nothing to do with this. If the next version of protobuf adds a Maybe type, it would not obligate consumers to require fields that they treat as optional. It would just be another way to encode the optionality, not optionality as a dependency but optionality of existence. A required input could still be encoded as a Maybe because the system can't guarantee it's existence. So Maybe is simply an encoding for a value that isn't guaranteed to exist. And that's exactly the scenario you described in proto3 - now every field could be encoded as a Maybe.

A second point that stuck out to me:

>I didn’t understand “the map is not the territory” until I had been programming for awhile. Type systems are a map of runtime behavior. They are useful up to that point. Runtime behavior is the territory; it’s how you make something happen in the world, and it’s what you ultimately care about. A lot of the arguments I see below in this thread seemingly forget that.

Your worldview here is very different from my own, and perhaps while this difference exists, there won't be much mutual understanding. I don't find any relationship between types and anything I understand as "runtime behavior". Types are logical propositions. The relationship between programs and types is that programs are proofs of those propositions. Runtime does not enter into the picture. That's why constraint solvers work without running the program.

I would say that "X doesn't understand type theory" is becoming a common form of "middlebrow dismissal" [1], which is discouraged on HN.

And that's exactly the scenario you described in proto3 - now every field could be encoded as a Maybe.

No, in protobufs, the presence of fields is checked at runtime, not compile time. So it's closer to a Clojure map (where every field is optional) than a Haskell Maybe.

This is true even though Google is using statically typed languages (C++ and Java). It would be true even if Google were using OCaml or Haskell, because you can't recompile and deploy every binary in your service at once (think dozens or even hundreds of different server binaries/batch jobs, some of which haven't been redeployed in 6-18 months.) This is an extreme case of what Hickey is talking about, but it demonstrates its truth.

I don't find any relationship between types and anything I understand as "runtime behavior".

Look up the concept of "type erasure", which occurs in many languages, including Haskell as I understand it. Or to be more concrete, compare how C++ does downcasting with how Java does it. Or look at how Java implements generics / parameterized types.

[1] http://www.byrnehobart.com/blog/why-are-middlebrow-dismissal...

From his talk he hasn't convinced me that he understands Haskell's type system. Not only does he misunderstand the contract given by `Maybe a` but he conflates `Either a b` with logical disjunction which is definitely a false pretense. He builds the rest of his specious talk on these ideas and declares, "it [type theory] is wrong!"

He goes on to describe, in a haphazard and ignorant way, half of a type theory. As I understood it these additions to "spec" are basically a row-based polymorphic type system. Why does he refuse to acknowledge or leverage the decades of research on these type systems? Is he a language designer or a hack?

I can't even tell to be honest. He has some good ideas but I think this was one of his worst talks.

To apply your own standards, have you been a prolific Clojure contributor/hacker/user? Have you contributed to any major open source Clojure projects?

Can you actually say what about Maybe/Either he got wrong because it seems like he understands it perfectly well, speaking as a Scala developer.

I was trying to address the points he made but parent appealed to his authority which I haven't found convincing.

> To apply your own standards, have you been a prolific Clojure contributor/hacker/user? Have you contributed to any major open source Clojure projects?

I have been a user on a commercial project. It's a fine enough language. I wouldn't call myself an expert. And I haven't given a keynote address where I call out Clojure for getting things I don't understand completely wrong.

> Can you actually say what about Maybe/Either he got wrong because it seems like he understands it perfectly well, speaking as a Scala developer.

His point about Maybe was misguided at best. The function `a -> Maybe a` is a different function than `a -> a`. Despite his intuition that the latter provides a stronger guarantee and shouldn't break code, callers may be expecting the Functor instance that the `Maybe` provides and therefore is a breaking change.

His point about `Either a b` was perhaps further from the mark. It is not a data type that represent logical disjunction. That's what the logical connective, disjunction, is for. Haskell doesn't have union types to my knowledge. Either is not a connective. It's a BiFunctor. His point that it's not "associative" or "communtative" or what-have-you simply doesn't make sense. In fact he calls Either "malarky" or, charitably, a "misnomer."

To his credit he says he's not bashing on type systems, only Maybe and Either. But he later contradicts himself in his conclusions. He goes on about reverse and how "the categoric definition of that is almost information free." And then, "you almost always want your return types to be dependent on their argument..." So basically, dependent types? But again, "you wouldn't need some icky category language to talk about that."

So again, I think he has some surface knowledge of type systems but I don't think he understands type systems. I'm only a beginner at this stuff and his errors were difficult to digest. I think if he wanted to put down Maybe and Either he should've come with a loaded weapon.

He's had better talks to be sure! I just don't think this one was very good. And in my estimation was one of the poorer talks this year.

I don't agree with Hickey, but isn't there a connection between Either as a basic sum type and logical disjunction via the curry-howard correspondence?

And wouldn't "forall a b. Either a b" be the bifunctor, since it has a product type/product category as it's domain, while the result "Either X Y" (where X and Y are concrete types, not type variables) has the semantics of logical disjunction ie. it represents a type that is of type X or type Y?

That’s what makes his talk strange. He talks about types as sets and seems to expect Either to correspond to set union? If he understood type theory then he’d understand that we use isomorphism and not equality.

You can express type equality in set theory and that is useful and makes sense.

But it doesn’t make sense in his argument.

Malarky? Come on. Doesn’t have associativity? Weird.

I don't really follow that. How can it be a breaking change? Can you give an example?

Where your downstream parsers match on `Nothing` and assume the stream hasn't been consumed in order to try an alternative parser or provide a default.

If you change an equation to use `option` instead you have a completely different parser with different semantics.

I was thinking of a case where I use your function in a combinator that depends on the Functor and Monoid instances provided by the `Maybe` type. If you change your function to return only the `a` and it doesn't provide those instances then you've changed the contract and have broken my code. And I suspect it should be easy to prove the equations are not equivalent.

Perhaps, maybe, public apis like protos shouldn't encode requiredness of any piece of data (I actually fully agree with this).

But that says nothing about whether or not my private/internal method to act on a proto should care.

Another way of putting this is that requiredness ahiuslnt be defined across clients (as in a proto), but defining it within a context makes a lot of sense, and maybe/optional constructs can do that.

Or iow, other peopleay use your schema in interested and unexpected ways. Don't be overly controlling. Your code on the other hand is yours, and controlling it makes more sense. So the arguments that rely on proto-stuff don't really convince me.

(I work at Google with protos that still have required members).

That's pretty much my point. Hickey is very clear what domains he's talking about, which are similar to the domains that protos are used in -- long-lived, "open world" information systems with many pieces of code operating on the same data.

People saying "Rich Hickey doesn't understand type systems" are missing the point. He's making a specific argument backed up by experience, and they are making a vague one. I don't want to mischaracterize anyone, but often I see nothing more than "always use the strictest types possible because it catches bugs", which is naive.

I agree with your statement about private/internal methods. I would also say that is the "easy" problem. You can change those types whenever you want, so you don't really have to worry about modelling it incorrectly. What Hickey is talking about is situations where you're interfacing with systems you don't control, and you can't upgrade everything at once.