Catch up on stories from the past week (and beyond) at the Slashdot story archive


Forgot your password?
Compare cell phone plans using Wirefly's innovative plan comparison tool ×

Comment Re:Lambda's plug poor OOP language design (Score 1) 380

Side note:

Ofc in the way how a button right now is implemented the inherited fields like title etc. are likely private and you need to call a setter ...

Some OOP languages allow one to call "set" behind the scenes using assignment notation. I personally find that a nice syntactic shortcut feature, especially for testing-stubs.

Comment Re:Lambda's plug poor OOP language design (Score 1) 380

I don't know why you are talking about chips.

They are orthogonal concepts and you can only very badly mimic lamdas with OO concepts and the opposite not at all ... Again: you clearly show that don't know much about the stuff you are talking about.

Show it, don't claim it. Can you present a use-case to demonstrate such? In other words, provide a practical (real world) example of something that lambda's noticeably improve upon compared to an OOP version of the same thing. (We'll try to ignore language-specific differences/limitations, but that's not always easy.)

Do you really [think] basically all new languages are introducing lamdas/closures like mad if they simply could 'improve' OO?

I do believe functional programming is in "fad mode" right now. Language designers are all me-too-ing.

Further, overhauling an OO model in existing languages without breaking existing apps may be harder than tacking on lambdas.

Comment Re:Could you gush a little more? (Score 1) 380

I believe the poster's comment was about the language itself and not code written in the language. You seem to be comparing Java coders to C# coders.

Microsoft did have existing Java implementations and code bases to learn from when designing C#, and by many accounts learned from Java's rough edges to incorporate the lessons into C#.

Comment Re:Lambda's plug poor OOP language design (Score 1) 380

I couldn't get it to do it smoothly, but if it can somehow be done, that's great, and emphasizes my original point that you don't need lambdas to associate actions with objects.

I'm not a Java expert by any stretch and didn't claim be. (I don't use it at work.) BUT, my original point is more about lambdas than Java.

Comment Re:Lambda's plug poor OOP language design (Score 1) 380

But if you could attach your own OnClick method to the button, only one method can be called when the user click on the button, which would be a huge problem for many gui objects.

Put the calls to the other ones in that method. Treat it as a stub method.

And I am not against a "listener registry" or whatever one wants to call it, it's just that a dev shouldn't have to deal directly with it for the vast majority of typical UI coding. Have a convenient front-door for the vast majority of "customers", and a back-door for specialized fiddling. You could stuff a hundred additional on-click events for that button into the listener registry if you wanted. A default on-click method doesn't prevent that. (Hopefully there is a priority code to control order of handling.)

Also, one could put a general event handler on the button's container, and do the other handlers that way, using reflection or environment info to know what widget and what action triggered it.

There are many options without having to deal with lambda's. Would you like to present a specific use-case to explore further?

(I've been trying to invent/define a table-oriented GUI engine that is mostly language-neutral. Most events can be handled using tablized attributes instead of imperatively coded behavior. Everyone's just used to hand-coded behavior out of industry habit. It's poor tool/labor factoring to re-invent a GUI engine for every different programming language. A good language-neutral GUI engine could be attached to any language.)

Comment Proponents [Re:Really?] (Score 1) 46

"If you tried [RoR], and cannot learn it, then programming just might not be for you"

I've seen too many similar statements from proponents of various frameworks/tools/languages/paradigms: "If you don't get X, you are stupid and should be flipping burgers."

After more than a decade of debating so called Golden Hammers and probing their justifications, I've concluded that people just vastly think differently and there are many ways to shave a cat (skinning them is too mean).

Some techniques just resonate with certain brains better. There is no reason to make it personal or mean.

I've met other Table Oriented Programming thinkers ("Tablizers"), and they love it also, but selling TOP to others has fallen flat.

They seem to prefer coding attributes (or what should be attributes) into what TO ME is verbose and hard-to-read code. But they LIKE reading that verbose code and even seem fast at it. Boggle. It's like Fred Flintstone preferring to stick with his feet-powered-car instead of getting a Honda. If Fred can get around well and quickly in his Footillac Deluxe, I guess I shouldn't care, as long as he doesn't force his car choice on me.

Hopefully each can find or make a shop where the other developers like and use your favorite tools also, and everybody is happy and productive with tools that fit their mind like a glove.

Sunshine, Unicorns, Rainbows, and YourFavStack

Peace! -Tablizer

Comment Re:Vs. Ion Drive [Re:points of interest] (Score 1) 406

Spewing ions is a problem: they're reaction mass and they have to be carried.

But the "power" in ion drives comes from the fast speed of the particles (ions), far quicker than rocket exhaust and near the speed of light. The weight of the material that gets converted into ions is relatively small, no?

Are you saying if a star-ship was built using an ion drive, it would have to carry a large chunk of stuff (relative to the ship) to eventually be ionized on the journey?

If the ship is 10% stuff to be ionized, and the ions spew out at almost the speed of light, then ionizing that chunk should make the ship be going roughly 10% of c when it's done, it seems.

Maybe I'm not considering some relativistic effects and stuck in Newtonian thinking?

Comment Re:Lambda's plug poor OOP language design (Score 1) 380

Sounds like that would break static typing

How so?

Only the syntax of the listener doodad is annoying, the design works well.

If you get used to it, a lot of things "works well". I found it fundamentally unnatural. The info for a given button should be together under a class-like grouping, something like the following pseudo-code:

buttonX = new Button {
  title="Click me";
  method onClick() {
    messageBox.display("Look Mom!");

Comment Vs. Ion Drive [Re:points of interest] (Score 1) 406

If it's so wimpy, why not use ion drives? I thought it was roughly 100x more efficient than ion drives (in tests), and that's why space-travel enthusiasts were excited about it. Your statement seems to say otherwise.

A key difference between EM and ion drives is that ion drives spew radiation to produce thrust while the EM drive allegedly doesn't. While that may be interesting from a physics perspective, it's not a practical issue from a space travel perspective because spewing radiation (ions) is not a significant problem.

In other words, it's not the apparent "something from nothing" aspect that excites travel enthusiasts, but the allegedly efficiency, because moving fast in space requires a hell of a lot of energy.

EMD titillates (or teases) physicists because of the perpetual-motion-machine-like qualities, but it titillates wannabe space-travelers because it's allegedly far more efficient than anything we have, meaning we could approach the speed of light without mountain-sized fuel tanks/reactors.

Comment On ColdFusion [Re:and they're abandoned in 10... (Score 1) 160

Actually, ColdFusion is still being sold, and has 2 or 3 open-source alternatives.

Its early selling point was easier web-page coding, and compared to what was available at the time, it was.

Then it became more known for making things simpler for HTML designers to integrate their markup templates with database data. And, it was and still is pretty good at that because you usually don't have to escape in and out of markup versus imperative code. In addition to the built-in CF tags, you can make custom tags for them also.

It's a tool that fits its niche pretty well.

Slashdot Top Deals

We all agree on the necessity of compromise. We just can't agree on when it's necessary to compromise. -- Larry Wall