Language:

en_US

switch to room list switch to menu My folders
Go to page: First ... 44 45 46 47 [48] 49 50 51 52 ... Last
[#] Mon Oct 31 2022 20:49:14 UTC from IGnatius T Foobar

[Reply] [ReplyQuoted] [Headers] [Print]

It had different goals at different times.

1. Originally its goal was to be a demostration of VM-based language technology.
It succeeded.

2. Its next goal was to supplant Windows+Intel as the primary way to deliver desktop applications. It failed.
("Network Computing" eventually succeeded, but Java would not be its primary component.)

3. With the advent of Enterprise Java Beans, its next goal was to become the cornerstone of enterprise architecture. It succeeded.

4. Its current goal is to be a vehicle with which Oracle can sue everyone who uses it and doesn't buy a license. It does not appear to be gaining a lot of traction here.

[#] Tue Nov 01 2022 00:07:55 UTC from Nurb432

[Reply] [ReplyQuoted] [Headers] [Print]

#4 ...... lol ( tho true )



[#] Tue Nov 01 2022 19:02:25 UTC from LoanShark

[Reply] [ReplyQuoted] [Headers] [Print]

"Do you know what the J in Java stands for? It stands for SLOW!"
-- old 1990's proverb

"In accepting the inevitable, one finds peace."
--Vulcan proverb

[#] Tue Nov 01 2022 19:03:11 UTC from LoanShark

[Reply] [ReplyQuoted] [Headers] [Print]

2022-10-27 16:59 from Nurb432
Ya it was a tradeoff to be 'universal' ( more or less )

I'm somewhat convinced that it was a consequence of Java's not-very-tightly-packed memory model.

[#] Tue Nov 01 2022 19:06:04 UTC from LoanShark

[Reply] [ReplyQuoted] [Headers] [Print]

4. Its current goal is to be a vehicle with which Oracle can sue
everyone who uses it and doesn't buy a license. It does not appear to

be gaining a lot of traction here.

Non Practicing Entities...

[#] Tue Nov 01 2022 20:35:48 UTC from Nurb432

[Reply] [ReplyQuoted] [Headers] [Print]

Funny thing is Python is almost 'run everywhere', even in web browsers now..   and it was around before Java ( just barely )

Everyone used to make fun of it in the old days, and its goals. Its still here. Its achieved them.



[#] Wed Nov 02 2022 15:48:50 UTC from IGnatius T Foobar

[Reply] [ReplyQuoted] [Headers] [Print]

C was considered "portable" back when all it did was read and write text to the screen and read and write files on disk. Compiling on a new architecture wasn't considered a problem. It still isn't.

It's the system libraries that make a difference, of course. A portable network API is pretty easy. A portable GUI isn't, especially with a headwind from entrenched native platform vendors.

Then leaf subsides to leaf, so Eden sank to grief, so dawn turns dusk to day...

Java failed on the client side because it offered a "meh" user experience.
It succeded as back end enterprise architecture because the user experience wasn't attached to the back end business logic. And obviously there were/are plenty of web sites that look great even though there is Java on the bottom tier.

Network Computing was the right idea but to attempt it with Java was the wrong implementation and delivered too soon. Once we had ubiquitous high speed Internet and mobile non-Windows devices, the demand for a portable client-side runtime skyrocketed, and the web browser vendors delivered. For the end user, JavaScript+HTML5 can now do everything Java originally promised, so we ended up in roughly the same place anyway.

And in the data center, Java has peaked and will now enjoy its golden years alongside (and on) mainframes, and other technologies that are still powerful and useful, but on which no one is developing any new applications. There is still plenty of work for people who are content to focus on technology that is in its golden years. Nothing gold can stay.

[#] Sun Nov 27 2022 19:54:19 UTC from Nurb432

Subject: Java

[Reply] [ReplyQuoted] [Headers] [Print]

"mmm that is some nice looking RAM you have there.  chomp chomp chomp."



[#] Thu Dec 01 2022 19:49:27 UTC from LoanShark

Subject: Re: Java

[Reply] [ReplyQuoted] [Headers] [Print]

2022-11-27 14:54 from Nurb432
Subject: Java
"mmm that is some nice looking RAM you have there.  chomp chomp
chomp."


Exactly the problem. I have an AWS Lambda that I wrote in Java, that just performs a few simple AWS API calls now, listing objects that might number about 50-100. It started to require 512MB RAM after a recent change. About half of that is compiled classes.

[#] Sun Dec 04 2022 20:45:28 UTC from IGnatius T Foobar

Subject: Re: Java

[Reply] [ReplyQuoted] [Headers] [Print]

Yow.  But since Lambda is billed by the number of requests and execution time, I guess you would optimize for run time at the expense of eating as much memory as possible.



[#] Sun Dec 04 2022 23:36:54 UTC from IGnatius T Foobar

[Reply] [ReplyQuoted] [Headers] [Print]

Geeze. Every time I go to do something in a client-side browser application that used to be difficult, I find that they've made it easy. Although it flies in the face of the wisdom which says "never throw the whole thing away and start over", this time around I haven't regretted it yet.

Sometime in the mid 2000's I wrote a drag-and-drop that included multi select and range select. Figuring out how to sort out the clicks, mousedowns, mouseups, ctrl and shift keys, all involved jumping through hoops and capturing keypress events and setting all sorts of flags to figure out what the user was trying to do. Now I findthat [ https://tinyurl.com/3rjf4npz ] every `onClick` event includes attributes that tell you whether the user was holding down any combination of ctrl, alt, and/or shift while clicking the mouse.

Why would anyone use "web frameworks" these days? The browser is so easy to write to now.

[#] Wed Dec 07 2022 21:09:02 UTC from LoanShark

Subject: Re: Java

[Reply] [ReplyQuoted] [Headers] [Print]

2022-12-04 15:45 from IGnatius T Foobar
Subject: Re: Java
Yow.  But since Lambda is billed by the number of requests and
execution time, I guess you would optimize for run time at the
expense of eating as much memory as possible.

The billing is multiplied by your memory setting.

[#] Wed Dec 07 2022 21:12:01 UTC from LoanShark

[Reply] [ReplyQuoted] [Headers] [Print]

Why would anyone use "web frameworks" these days? The browser is so

easy to write to now.

but ridiculously complex layers of abstraction that allow you to write "elegant" and "cool" code are the thing, man

god help you when they break.

[#] Wed Dec 07 2022 22:15:48 UTC from Nurb432

[Reply] [ReplyQuoted] [Headers] [Print]

Along the lines of complexity for the sake of complexity:

 

Since i'm not an official developer at the office i cant do 'code' ( earlier thread about this ) and have to let the dev team do it.  I have an "app" i am having written, its basically 3 simple crud sql queries, a web front end to those to display 3 fields in a grid layout ( list determined by who is logged in ) then 3 sql jobs to send mail and move some data around on a schedule. 

I gave them a breakdown of how to write it, almost to the code level. "if i was going to write this....."  even modified my DB so they wouldn't need a 'temp' table or anything and it can all be done in 2 tables, which i provide  ( ya my BA background was showing )

The first thing the dev team did was to write an API..     really?  

 



[#] Thu Dec 08 2022 04:38:01 UTC from IGnatius T Foobar

[Reply] [ReplyQuoted] [Headers] [Print]

but ridiculously complex layers of abstraction that allow you to write

"elegant" and "cool" code are the thing, man

Of course, and unfortunately it is true that memory is cheaper than developer time. And that's why we've been automating the same processes for half a century and consuming more and more resources doing it. At ${work} (where software development is only a small portion of what I do) I'll bring in a library or three if it saves some time, but I'm still hand coding anything that runs in the browser.

And yes, you *do* write the API first, because then the web UI can just use that. Nearly everything I build now is done as an API plus a user interface that causes the browser to emit API calls. That way when some other team wants to tie in (for me that usually means they're going to tie the portal into my system instead of forcing users to run my standalone UI) the API is already there and it's guaranteed to work. Everyone wins.

At home, things are different. If you're logged in using WebCit as of this writing, you're seeing code that's been around for over 25 years. It has outlived all of the libraries and components we used (Prototype, Scriptaculous, the free version of TinyMCE, etc). I intend for WebCit-NG to have a service lifetime of at least another 25 years. So far it's working beautifully -- every time I look at building a piece that was painful in the past, I find that the browser simply does it for you now. I like that. I tried Bootstrap;, and I tried W3.CSS -- but in the end I found that hand-coding HTML5+DOM+XHR+JS is just so easy these days, there's no point in wrapping it with someone else's library.

The obvious exception to all of this, of course, is if you have to support really old browsers. I am fortunately in a position where I can say that if you aren't on one of the evergreen browsers, you're very much out of luck (and you probably have bigger problems anyway).
But yes, if your users are in the public sector or some equally brain damaged environment, sure, go ahead and use a library that can deal with both IE11 and modern browsers. That ain't me.

[#] Thu Dec 08 2022 21:07:53 UTC from LoanShark

[Reply] [ReplyQuoted] [Headers] [Print]


We don't support IE here anymore either. It's getting way too long in the tooth. But there are some polyfills that can help run new code on an old browser.

[#] Thu Dec 08 2022 23:04:26 UTC from Nurb432

[Reply] [ReplyQuoted] [Headers] [Print]

For a real app, sure, but this is *3* queries..  I guess actually for the web 'interface' just 2.. read what is in the table, present 3 fields from it as editable and then push it back to the DB .. really that is it.

Wed Dec 07 2022 11:38:01 PM EST from IGnatius T Foobar
And yes, you *do* write the API first, 

 



[#] Thu Dec 08 2022 23:43:32 UTC from Nurb432

[Reply] [ReplyQuoted] [Headers] [Print]

grr 4 quires total.  was a typo.

 

1 - copy some data around ( triggered on a schedule, can be done on the sql server )

2 - send emails based on that copied data ( this is triggered on a schedule too, and is to be done on the sqlserver )

3 - read the copied data into a brain dead simple form ( grid )

4 - write changes from form back into db, overwriting the copied data

 

Its really that simple. I could do it in no time, but noooooo im not allowed to do that myself.  "rules"



[#] Fri Dec 09 2022 18:45:59 UTC from zelgomer

[Reply] [ReplyQuoted] [Headers] [Print]

My office has a similar framework obsessed culture that I only just recently was able to put my finger on. Historically I've always been on the other side of it--one guy or a small team are responsible for writing this framework, and the rest of us have to code within the bounds of it, and I was always butting heads with the framework guys because their apis sucked, or because they would force you into a model that didn't suit the problem space, and so I'd go out of bounds by accessing POSIX apis directly, etc., and make a bunch of people mad at me.

We started a new project recently with just me and a few other guys, and I said early on that all of those frameworks suck and we shouldn't be using them. Linux and C are our framework. Long story short, through arguments and revealing that they don't know how to write software, they have effectively beaten me into becoming a framework guy.

E.g., One guy wanted me to write a library to manage a thing, so I did. But his code is heavily multithreaded (for absolutely no good reason, but because he hooks up to yet another framework that uses a worker pool). I told him my context isn't thread safe, so he will need to serialize access to my manager, and he insisted it couldn't be done. There is no possible way he could design his code to access mine, because if he serializes then something taking too long could hold up other workers. I tried to explain to him how he could design a manager thread to proxy operations so that it all happens in the context of one thread, but he was worried about it slowing everything down. I told him access to the thing I'm managing is going to be serialized by the hardware, anyway, but that didn't land. Finally I gave up and told him forget it, I'll do it for you. Then everything I described to him that he should do, I did it for him behind the api. So now there's a whole bunch of complexity in my api that should have been evenly spread across the whole system, but his code is very light and simple, and now whenever there's a problem with it he can blame it on my api and send the bug my way.

I didn't even want it to be like this. Because there's only a few of us, I was hoping we could get away from this "this is my area and that's your area and I'm going to use this division of responsibility as a tactic to deflect bugs" mentality, but clearly that's not going to fly. So here we go, following all the same missteps that's made every other project I've ever worked on at this company horrible.

[#] Sat Dec 17 2022 19:43:54 UTC from IGnatius T Foobar

[Reply] [ReplyQuoted] [Headers] [Print]

I don't mind writing to a "framework" if it's the standard across a big complex system that spans everything the company does. For example, our portal is built with Bootstrap, and I wouldn't add a module to it that used something other than Bootstrap (or no framework at all). That would make it hard to maintain and upgrade. Furthermore, it would mean that no one except me would be able to do that maintenance.

As I mentioned elsewhere, frameworks have a resource cost but they reduce software development from an art to a craft.

That's part of why I get so excited about microservices. You build your microservice and expose interfaces to it, and then it's someone else's problem to figure out how to access it. Just about everything I've built in the last three years has been done as a service (usually in a container) with a self-contained web server and an API, and a very spartan UI layered on top that simply causes the browser to emit API calls. It goes into service as-is, and then later on the portal team writes to my API instead of linking away to the temporary UI.

Yes, there are "frameworks" on the back end as well. Lots of developers begin a project by loading up NodeJS and several gigamegs of libraries just to write a hundred lines of Hello World on top of it. We call these people "morons".

Go to page: First ... 44 45 46 47 [48] 49 50 51 52 ... Last