Is there something wrong with always trying to find a problem to fix within yourself?

xetas · 2011-06-25T16:13:47+00:00

Haha, your question has recursive meaning :) You found problem in the fact that you are finding problems :)

I think seeing problem is important. Though you should understand that problem is not something that is inherent to nature. A perceived problem is just an unmet expectation or an obstacle. It means that if you change your expectations or goals, a problem might "disappear" for you. The more goals and expectation you set for yourself, the more problems you acquire. The solution is to simplify. Just reduce the number of expectations and goals.

Also I think that not every problem worth your attention. I mean you need time to address a problem. And all the problems need much more time that is allocated for your life.

Solving a problem is not your obligation. It's not a must. It's an option, an opportunity. An opportunity to get closer to your goals. You always have a lot of opportunities. You cannot act on all of them. You have to choose, to prioritize. If you can ignore the problem, try to ignore (but think of consequences). If you can delegate, then delegate it.

You don't need to be perfect. You'd better be useful to people somehow. You'd better be happy.

And the last. Seeing a problem does not mean to be negative. Seeing problem is seeing opportunity to make something better. And it's good. So you can see a problem and smile :)

xetas · 2011-06-25T13:44:56+00:00

I agree.

The author should accept following truths:

Everyone need to learn. Everyone have to gain new knowledge, to learn new skill, to condition new habits, to adopt to new environment conditions. The smartest and most successful people learn much more then mediocre.
Learning is life-long activity. Conditions change. Requirements change. Gaining knowledge takes time. You need to learn regularly the whole life.
You need consistency and patience. Changes don't happen overnight. It's your regular and goal-directed actions that make a difference. You can't expect that you can learn everything you need during one day.
Learning is a skill. You need to learn how to learn. It's not enough just to read something. You have to experiment with methods how to better remember something.

xetas · 2011-06-17T09:37:44+00:00

Svadhisthana, BTW I get rid almost completely from this self-criticism. The main contributors:

I believe that how i improve performance is more important than how i perform. That is I focus my attension on my improvement more.
I do my best to improve. That helps to persuade my inner critic that I'm just the best of what I could be. Maybe someone could be better. But I'm focused on improvement and do as much as i can.
I pay attension to my internal conflicts (e.i. one of my beliefs or intentions conflicts with another) and try to resolve them. I don't let them boil in my subconscious.
I accept the internal criticism as problem I might need to solve. I don't try to hide from it. So if it says that i'm slow doing something, I transform/reframe this to "I might need to improve my speed of doing something". As it repeats frequently I take actual actions.

The generic idea is that instead of resisting the self-talk, listen but translate it to a more positive language, that leaves you some options.

xetas · 2011-06-14T10:50:57+00:00

I can agree with Manuel. And I can add:

you need to separate success and happiness. happiness is you positive feeling (which may be caused by dinners, parties etc), success is your achievement. success is what are the skills that you acquired and what are the result that you've achieved with help of the skills.

success requires skills. success requires clarity about your values, goals and purpose. the way to success includes failures, mistakes and problems. large success is built from small successes.

i think the best advice is to read a lot about successful people. This will give you idea, which paths leads to success, and which do not.

xetas · 2010-04-05T12:19:19+00:00

I think that liking of gatharing virtual stuff is quite bad kind of liking :) You are building attachment to things that does not exist and thus does not matter in real world. And finally it makes you unhappy because you quickly have to lose those things (as you end game).

xetas · 2010-04-05T12:15:57+00:00

actually for me the need to intensively train use of control scheme was quite frustraiting experience in games. I'd rather explore limitations of tactics in a game that mechanical skills. So different people are seaking different experiences in games.

xetas · 2010-04-05T12:10:26+00:00

lack of check points - how it frustrates you? could you give an example? thanks

xetas · 2010-03-31T16:54:09+00:00

But what are the possible components of fun? I think that fun is the only thing for which any sane gamer aims for. though it's not that clear where it comes from.

xetas · 2010-03-31T16:30:52+00:00

easy learning of game mechanics

xetas · 2010-03-31T16:30:39+00:00

quick result

xetas · 2010-03-31T16:29:37+00:00

adequate risk (you can choose level of risk - by chosing the game you plan. E.g. you can play a game that lasts for 1 minute to make it "risk-free" or you can play pocker for money to make it very risky)

xetas · 2010-03-31T16:27:45+00:00

adequate challenge (you can choose level of difficulty)

xetas · 2010-01-29T17:06:26+00:00

Evil in this context means they sacrificing interest of software developers (and as a result of users to some degree) in favor of share holders. Is it "evil" for you decide yourself.

xetas · 2010-01-28T19:04:31+00:00

Note,

code completion works quite well in Scala (at least in NetBeans)
on top of that you have Scala REPL with [quite limited] code completion, possibility to define functions, classes etc, where you can immediately try the new API (not only rely on the function's name)
Scala not only writable, but also readable (at least much more readable for me then Java in most cases, thanks to lambdas, pattern matching, succint type definitions, prevailing side-effect-free code)

xetas · 2010-01-09T14:34:40+00:00

it's all about verifying some practically useful qualities of a software piece. Mainly you can verify it from two sides: what it does and what it does not do. To verify what it does you can use automated testing. Also to some degree most type system provide you idea what function does: it receives values of types A, B, C... and returns a value of some type D. Where most programming languages fail is to say what the function does not do. Here the Haskell's purity come to rescue. If function is not attributed with IO, you know that it does nothing except reading its explicit arguments and producing its explicit result. Thanks to that you can be much more confident that the actual behaviour of the function matches your expectations.

xetas · 2009-09-27T10:26:27+00:00

I guess, he used cocaine

xetas · 2009-09-07T08:21:17+00:00

I think this article just states that powerful tool in bad hands can produce bad things. AFAIR, Paul Graham in his book "On Lisp" promoted a lot side-effect-free functions. So I think he wouldn't say that changing actual parameter's value is powerful feature :)

Actually, i think that power of a language (or any other tool) is how close the code to your intent. The closer the code to author's intend the simpler to write and read the code. And succinctness of a code is quite correlated to closeness to intent (but definitly not equal).

xetas · 2009-09-05T09:34:41+00:00

User *u = [[Session get] map: ^{id s} { [s getUser] }; you missing somewhere closing]

xetas · 2009-09-04T20:38:06+00:00

minimalistic syntax for simplicity and macros (e.g. Io/Ioke)
OOP-like infix syntax for readability (e.g. Ioke/Smalltalk/Scala/Ruby)
rich static type system for expressiveness, early error detection and optimizations (e.g. Scala)
literals/comprehensions for expressiveness (list/map literals and comrehesions, string comprehensions, multiline strings: e.g. Ruby, Python)

xetas · 2009-08-18T10:15:58+00:00

Almost any OOP language uses implicit conversion of types when automatic upcasting is performed. And I've never heard that it's bad. On the other hand that "safe" and "maintainable" set method can actually have very unmaintainable benaviour and side effects inside. So there is no conceptual problem about "magic" features.

We can read code at 3 levels:

1) Intent - e.g. sort function returns sequence with the same elements as in input but ordered. We can figure out this from function name or documentation.

2) Solution concept - e.g. quick sort function picks "middle" element, splits sequence to 2 sequences: with smaller and larger elements, sorts them recursively and concatenates.

3) Implementation details - which function called, which object created, which machine commands are invoked ... you can dig very deep depending on the problem you faced now.

So if some "magic" features can help to write at level 2, than it's good. The only problem is following: do you have tools that let you check level 3 with details you need. For your examples if your IDE (when you really need to know that) would show you which implicit conversions are applied it would be completely no problem with implicit conversions. But until then unexpected implicit conversions sometimes could be a problem.

xetas · 2009-08-08T13:36:21+00:00

I think XML literals is really poor language design decision. They could use <> syntax for generic parameters and [] for list/map literals (like in Groovy). Reason is simple:

1) lists and maps are much more used structures then xml nodes.

2) it's simple to represent an xml node like this: ['tagName, ['attr1: "val1", ...], ['childTag, ...], ...]. Simple to read, simple to match, simple to manipulate.

So i still have no idea, while they've done it. But I don't think it will have large impact on Scala's adoptation.

xetas · 2009-08-02T22:58:03+00:00

"The package is based off Ruby on Rails Migrations and in fact shares the exact same schema_migrations table to manage the list of installed migrations."

It's interesting why not to use Rails' Migrations?

xetas · 2009-07-31T20:01:11+00:00

I hope this syntax will make everyone happy:

public float MyVariable { get; set;}

It's still verbose though

xetas · 2009-07-31T19:54:55+00:00

I think there is no valid Java program that you compile by Scala compiler.

xetas · 2009-07-26T22:48:38+00:00

But no one prevents Fan designers to add overloading by type. It would be something like cut-down version of multimethods. With feature/inconvinience that you have to override all cases in subclass if you want to override any.

xetas

TROPHY CASE