I guess the question is more like this (clearly doesn't compile):

Is it going to double the entire list 3 times or double the first 5 elements?

This is kind of the cruz of FP and lazy evaluation. In theory, an infinite list would return 5 elements and do fine if it is lazy, but would never complete if it isn't lazy.

i believe lazy evaluation is only supported in transducers in ramda, so as written that example would be doubling the whole list. ofc in that specific example you could rewrite to take first: pipe(take5, double, double, double)(L).

but i understand your point now.

as a practical matter this has never come up for me. and i strongly disagree that this feature is the crux of FP, although it's nice. the crux of FP is immutability and composition.

I don't think I've seen it, but I could be wrong.

But yeah, something like this is what I'm thinking of, only with resources for moving from one level to the next.

Incidentally, if you've read thru that example, I'm curious what you or others would consider a good time for someone to be attempting to enter the work force as a programmer, generally speaking. Should one wait until they're almost solidly level 2? A good mix of 2 and 1? 60% 2, 35% 1, 5% n/a or 0?

This might be helpful: https://www.google.com/about/careers...velopment.html

If lazy evaluation wasn't a part of FP, the function compositions wouldn't be able to run fast enough to compete with imperative approaches. Just as recursion and looping are different approaches to the same result, imperative and functional should have some line connecting each other, or one breaks down in lieu of the other. More specifically, without lazy evaluation, an optimal compilation of FP programs couldn't exist.

Of course, I may be wrong-headed on this, this is my general interpretation (sorry, it is terrible and isn't right, but hopefully shows the point):

Not Lazy:Lazy:

This is how I see the difference between lazy and not-lazy. Granted, I'm over-doing the lazy part, but my interpretation is that the lazy trying to near O(n), but not-lazy would end up being O(n^2). I don't think it is totally unfair to say that the function chaining without lazy evaluation ends up going near O(n^2), but as always, I may be way off base here.

Curious about this, too.

A bit further down there is an "experience" row though, which shows "professional experience" for lvl1 as 2-5 years and lvl 2 as 6-9 years.

Extrapolating from that, I don't think you'd need to be a "solid 2" just to start working, no?

Well that would be one of the 0 or N/As

You should start working as soon as someone will hire you, and expect the composition of your job to change as you progress.

I always understood access modifiers to mean
public: everything
protected: class & subclasses
private: class

I've been doing more Java recently though, and it seems like in Java protected means exposed at the package level, if I read it right? WTF? I always sort of thought protected (my first definition) should usually be the default, but with Java that breaks encapsulation. Am I thinking about this right / is there something else I should use?

attempt to enter the work force as soon as possible. like, I would say as soon as you have a decent understanding of object oriented principles, data structures, algorithms and mvc. further, it is my understanding that most companies will really keep the training wheels on you for a long time.

I mean, that's all I know, and after just starting to work, and being around other new hires, I am in no way disadvantaged. and 21 out of 22 of the ppl that completed my bootcamp had a job within a month of completion. its hard for me to think that any of them are very far along in that matrix.



so pretty much, if you can find your way into a job, do that as soon as possible. its a lot nicer to get paid to do this stuff than to pay to do it.

Actually if this is right:
https://docs.oracle.com/javase/tutor...sscontrol.html
it's even worse than you thought. No modifier means that the class and the package can see it, but NOT subclasses??

You should use private as the standard modifier anyway. Essentially, protected/public are exposed on an API level and default/private are not.

Ugh that makes zero sense to me... I would think there needs to be a Y/N/Y/N??

I think you could make a good case for private as the default, but for my uses (note, I don't really do any API-type work) I inherit and want to override stuff so often that "protected" (my first definition) is used so much more often.

Either way I don't want external things to see it.

Makes me wanna switch over to C# (among a ton of other things, but this is really bothering me right now lol)...

I don't see any problem with this fwiw, Java is just a library focused language and this is reflected here. In your case I guess you can use the "default" modifier and have the subclasses in the same package?

Protected (even your definition) is exposed outside the package, you wouldn't want to use this too widely. Other developers may extend your classes and work with the protected members, so you have to take special care of these.

No external user of your work should place code in your package, if they do they are probably aware that they are working around the intended API.

Hmm... I don't think either definition of protected allows it to be exposed outside the package. It seems Java = everything INSIDE the package, but my definition is basically private + subclasses.

Generally my logic is about limited direct property access - I want non-derived classes to use getters instead of myObj.property. With Java's definition, code (within the package) can use myObj.property, but with C#'s it cannot.

I guess maybe I should just be using more packages and not care that internally classes can access each other's properties? That philosophy would make sense, although less preferrable.

I think that makes sense and I do it the same, but nobody from the "outside" should place stuff into your package anyway. So just don't use myObj.property yourself and there is no problem. For private/package private you basically don't give any guarantees and are free to change them as needed in future versions.

Protected on the other hand is part of the API, it is perfectly standard for other developers to use your protected members in their code by extending your classes, and they will expect that updates to your code won't break their code in future versions.

Yea that makes a lot of sense for something like API development. My only usage right now basically is for personal/solo game development. So yea I'll just have to self limit external classes in the same package from not doing myObj.protectedProperty - but I think it's better language design to just not allow me to do it in the first place.

My first OO learning experience was C++ so those definitions are how I think about everything.

So much this.

I waited waaay too long. When I started applying to entry level, I was only hit back with mid and senior level offers.

Mid level interviews are hard to get because yes, people actually do have 6 to 10 years experience, and well... I don't, but it is a miracle that anyone would ever talk to me at all. I never felt like I was flapping in the wind, but I'd love to be a fly on the wall and see how people with the requisite experience handles themselves.

Senior Level interviews are a lesson in evisceration and walking away licking your wounds.

I have two months of professional programming experience and that job was probably senior level.

Noodle, just start applying and see what kind of response you get. I guarantee that you are able to hook into a Jr level and at least experience a few phone and face-to-face interviews. I'd go further and say that you have > 80% chance of landing one of those jobs.

I don't think you need a bootcamp either. The first step is getting over the fear of looking like a moron in an interview, and trust me, that is going to happen far less often than you fear. Maybe 1 / 25 interviews will have you walking away feeling like you are a screw up, but the rest, you'll be fine.

Ideally he wants to find an opportunity where he gets to "create" a lot of software. There is no doubt that crappy jobs are out there where companies have projects are destined to fail.

Developer evangelist job in Paris - only a little programming experience required (?!?)

Nice to see someone being upfront about not caring much about experience. You gotta start somewhere.

Personally, I hated working in Paris. Surprisingly, neither the language, people nor their perceived snobbery bothered me. The hours felt brutally long.
Start used to be latish, around 9am, but everyone would religiously take a minimum 2 hour long lunch break which meant you'd be falling asleep towards the final hours. Rarely got out before 7pm.
Pay was rather lackluster, too.

I think it was the super long lunch that bothered me most. You would be expected to join a large group from work (or be perceived as outsider who hates everyone), wait ages for your food and had to deal with their ridiculously rude waiters. And no, they weren't rude because I spoke english; I actually speak passable French. Enough to get around. They were just as bad with the locals.

Other people had issues with the commute as rentals are not affordable in central Paris. I had the luxury of staying in a hotel close to work most of the times I had to work over there.

Wow, rereading this a bit later it sounds way more negative than intended.

While I personally wouldn't want to live in Paris, it was one of my favourite cities to visit for an extended weekend in Europe. Been there at least 5 times outside of work and enjoyed it every time.

Wow, I'm a man that likes his long lunches but even I couldn't deal with two full hours for lunch. Think 90 minutes was my best work so far.